Subject: RE: Doubts about MPLS-TE Mib

From: Apratim Mukherjee <[email-masked]>
Date: Tue, 31 Jul 2001 14:14:27 +0530

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:[email-masked]]
> Sent: 	Tuesday, July 31, 2001 4:49 AM
> To: 	[email-masked]'
> 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
>

---

From: David Charlap <[email-masked]>
Date: Tue, 31 Jul 2001 10:16:57 -0400

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