The MPLS WG Archive

[Apratim Mukherjee <ApratimM@netbrahma.com>]

Hi ,

If TunnelId is to distinguish between two sessions having the same egress ,
then TunnelId should have a globally significant value in a MPLS domain ,
i.e. TunnelId cannot be same as TunnelIndex since TunnelIndex has a locally
assigned value (equal to TunnelIndexNextFree when a new tunnel is being
formed ). 
1 ) Doubt here : Where does the TunnelId come from then ? 

2) If TunnelId HAS a globally significant value , then why do we need an
Extended Tunnel Id ?
[ 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.]

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 . ( 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 . 
3)  Is this an implicit assumption for traffic engineered tunnels in a MPLS
domain ?

Thanks ,
Apratim 



> ----------
> From: 	David Charlap[SMTP:david.charlap@marconi.com]
> Sent: 	Tuesday, July 31, 2001 4:49 AM
> To: 	'mpls@uu.net'
> Subject: 	Re: Doubts about MPLS-TE Mib
> 
> >> You can see both fields at transit nodes: look at the tunnel
> >> entry and the RSVP MIB for that session.
> > 
> > Aha.  That is certainly an answer.
> 
> Unfortunately, there is no RSVP-TE MIB, even in draft form.
> 
> True, you can take the MIB from RFC 2209 and tweak it for the new fields
> used by RSVP-TE, but you necessarily end up with a private MIB, not a
> standard.
> 
> A while back, I asked about an RSVP-TE MIB and was told that it is
> unnecessary because the MPLS TE-MIB presents all the same information. 
> Unfortunately, this turned out not to be true.
> 
> -- David
>