The MPLS WG Archive

[Apratim Mukherjee <ApratimM@netbrahma.com>]

Hi David,

So its now clear that TunnelId has a local significance only . Also Extended
Tunnel Id can be 0 if the intention is to have multiple ingresses to a
tunnel.

I1 -----------|
              I
 	  |-----------LSR--------------------------------- E
	  |
I2 -----------|

Say that a tunnel is created from I1 to E with Extended Tunnel Id 0.
Also , a DIFFERENT tunnel has to be created between I2 to E with Extended
Tunnel Id . (i.e. both the tunnels have other ingress points besides I1 and
I2).
Also assume that that the SE desired flag is on.

Now at the LSR , the session object for the path messages MAY be same since
Tunnel Ids are locally assigned . That is 
(EgressIP in Path Message from I1 =EgressIp in Path Message from I2 = E ,
TunnelId in Path Message from I1 =TunnelId in Path Message from I2 = x ,
ExtendedTunnelId in Path Message from I1 =ExtendedTunnelId in Path Message
from I2 = 0) 
Hence , the two SESSIONs will get MERGED at the LSR , i.e , the path states
corresponding to the two path messages will be in the SAME session .
This results in unwanted behaviour e.g. if styles are different , then
second path message will be dropped or reservations can get merged for the
two different styles is style is SE for both .
 How can this be prevented if TunnelId has a local significance and the same
tunnelId could be generated at two ingresses for different tunnels ?

I feel that if TunnelId has a local significance , then it must be mandatory
for ExtendedTunnelId to contain the Ip address and multipoint to point
tunnels should not be allowed . Or am i missing something here ?

Thanks
Apratim


> ----------
> From: 	David Charlap[SMTP:david.charlap@marconi.com]
> Sent: 	Tuesday, July 31, 2001 7:46 PM
> To: 	'mpls@uu.net'
> Subject: 	Re: Doubts about MPLS-TE Mib
> 
> Apratim Mukherjee wrote:
> > 
> > If TunnelId is to distinguish between two sessions having the same
> > egress, then TunnelId should have a globally significant value in a
> > MPLS domain
> 
> And how do you propose to do this?  Require a global server that can
> dish out unique tunnel IDs, perhaps?  Requiring that tunnel ID be
> globally unique is not possible without adding so much overhead that
> nobody will use it.
> 
> In RSVP-TE, _ALL_ of the values in a session object (Address, tunnel ID
> and extended tunnel ID) are required to uniquely specify a session. 
> Extended tunnel ID is required because there is no reasonable way to
> ensure uniqueness of the tunnel ID field.
> 
> The only reason CR-LDP doesn't also have this problem is because CR-LDP
> incorporates the sender address as part of the LSP ID.
> 
> > 1 ) Doubt here : Where does the TunnelId come from then ?
> 
> Tunnel ID is only locally unique to the ingress node.
> 
> > 2) If TunnelId HAS a globally significant value , then why do we
> > need an Extended Tunnel Id ?
> 
> Your assumption is wrong.  It is not globally significant.  The extended
> tunnel ID is required to make the entire session object globally unique.
> 
> You can't just blindly assume that extended tunnel ID will match the
> sender address, because a zero value (meaning "don't care", needed for
> sharing resources between two LSPs from different senders) is legal.
> 
> > [ If the administrator wants to tie a tunnel to an Ingress , all he
> > has to do is to make sure that no other tunnel in the domain has
> > the same TunnelId.]
> 
> Easier said than done.  The only way an administrator can guarantee this
> is if every single LSP in the network is manually configured.  This is
> not always going to be true.
> 
> > If TunnelId is locally assigned at a node , then Extended Tunnel Id
> > MUST be set to the ingress IP address to be able to distinguish it
> > from some tunnel being made at another ingress with same tunnel id.
> 
> Unless it is intended that this LSP will share resources with another
> LSP terminating on the same node.
> 
> > ( possible since tunnel id is being locally decided ).
> > However this means that one tunnel CANNOT have two lsps belonging
> > to the same tunnel originating at two ingresses and exiting from
> > the same egress.
> 
> There is no reason why you can not have this.  That is specifically what
> the zero value for extended tunnel ID is meant for.
> 
> -- David
>