Subject: RE: Doubts about MPLS-TE Mib

From: "Lipovetsky, Sergey" <[email-masked]>
Date: Tue, 31 Jul 2001 20:39:35 +0200

Hi David,

Thank you for your clarification of RSVP details. It always helps a lot.

Here are comments on this thread.
RFC2205 states "RSVP defines a "session" to be a data flow with a particular
destination and transport-layer protocol." My understanding is that it is
not different for RSVP-TE and a session object relates to the destination.
TunnelId is a part of the session object and probably also relates to the
destination. If this is true TunnelId should be locally unique to the egress
node and a pair [egress address, TunnelId] should uniquely identify an RSVP
session.

However, there is a problem with TunnelId allocation on the ingress node in
this case.

The requirements to set Extended tunnel ID to a non-zero value to guarantee
session uniqueness, when TunnelId is allocated by the ingress node prevents
from merging LSPs having the same egress node but different ingress nodes.
What is wrong here?

Thanks,
Sergey

> -----Original Message-----
> From: David Charlap [mailto:[email-masked]]
> Sent: Tuesday, July 31, 2001 4:17 PM
> To: [email-masked]'
> 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
>

---

From: David Charlap <[email-masked]>
Date: Tue, 31 Jul 2001 18:53:28 -0400

"Lipovetsky, Sergey" wrote:
> RFC2205 states "RSVP defines a "session" to be a data flow with a
> particular destination and transport-layer protocol." My
> understanding is that it is not different for RSVP-TE and a session
> object relates to the destination.

The SESSION object is not the same for RSVP and RSVP-TE.

In RSVP, the SESSION object consists of a 3-tuple consisting of
destination address, destination L4-protocol, and destination port
number.  In RSVP-TE, the SESSION object is a 3-tuple consisting of
egress address, tunnel ID and extended tunnel ID.

In either case, the data in the SESSION object is what uniquely
identifies the session, and nothing else does.

> TunnelId is a part of the session object and probably also relates
> to the destination. If this is true TunnelId should be locally
> unique to the egress node and a pair [egress address, TunnelId]
> should uniquely identify an RSVP session.

You're exchanging cause and effect here.  The data in the SESSION object
is what defines a session.  If two different LSPs are signaled with Path
messages containing identical SESSION objects, then they are in the same
session.  Period.  It doesn't matter what the user may or may not have
wanted.

Because tunnel ID can not be globally synchronized without using means
beyond the scope of RSVP-TE, the extended tunnel ID was created.  It can
either be zero, in the case where resource sharing among different
senders is desired, or it can be set to a globally unique value
(preferrably the sender's IP address) in the case where such resource
sharing is not desired.

> However, there is a problem with TunnelId allocation on the ingress
> node in this case.
> 
> The requirements to set Extended tunnel ID to a non-zero value to
> guarantee session uniqueness, when TunnelId is allocated by the
> ingress node prevents from merging LSPs having the same egress node
> but different ingress nodes.
> What is wrong here?

You are assuming that guaranteeing session uniqueness is something that
everybody always wants.  This is an invalid assumption.  There are
situations where it is desirable and there are situations where it is
not.

There are situations where an operator may explicitly want two different
LSPs from different senders to share resources.  The only way to signal
this is by using a zero value for extended tunnel ID.

-- David