Subject: RE: Doubts about MPLS-TE Mib

From: "Lipovetsky, Sergey" <[email-masked]>
Date: Wed, 1 Aug 2001 07:45:30 +0200

Hi David,

> > 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.
> 
> 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.
> 

I agree.

> > 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.
> 

I fully agree.

> 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.
> 

How can we say that tunnel ID is locally unique to the ingress node in this
case?
This is true only when the extended tunnel ID is not zero.
 
If the extended tunnel ID is zero, some global synchronization is required. 
Actually this synchronization is not so global, because only tunnel IDs for
the same egress node
require synchronization.
Can we say that tunnel ID is local unique to the egress node in this case?

This is different from CR-LDP, where lspid is really locally unique to the
ingress node
and does not require any synchronization.

> > 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.
> 

I agree. I probably was not clear here.

---

From: David Charlap <[email-masked]>
Date: Wed, 01 Aug 2001 10:19:26 -0400

"Lipovetsky, Sergey" wrote:
> 
> How can we say that tunnel ID is locally unique to the ingress
> node in this case?

Because RSVP has no mechanism for synchronizing tunnel IDs across the
network.  Therefore the value is, by definition, only locally unique. 
This should be obvious.

> This is true only when the extended tunnel ID is not zero.

The uniqueness of tunnel ID is not affected by the value of other fields
in the SESSION object.

You seem to be confusing the tunnel ID with the entirity of the SESSION
object.

> If the extended tunnel ID is zero, some global synchronization is

It would be a good idea, but the protocol does not provide for any
mechanism.  And RSVP will work just fine with or without said
synchronization.  Your requirement is nothing more than wishful
thinking.

> Can we say that tunnel ID is local unique to the egress node in this

I don't see what your preoccupation with this is.  You seem die-hard
determined to change the RSVP spec such that it fits the MPLS-TE MIB.

> This is different from CR-LDP, where lspid is really locally unique
> to the ingress node and does not require any synchronization.

CR-LDP doesn't allow two LSPs to share resources either, so the entire
argument is moot there.

-- David