The MPLS WG Archive

["Feng, Mark" <m_feng@trillium.com>]

> -----Original Message-----
> From: David Charlap [mailto:david.charlap@marconi.com]
> Sent: Tuesday, July 31, 2001 3:59 PM
> To: Feng, Mark
> Cc: 'mpls@uu.net'
> Subject: Re: Doubts about MPLS-TE Mib
> 
> 
> "Feng, Mark" wrote:
> > 
> > IMO, tunnel Id has "global" significance, within some particular
> > MPLS domain, synonym to well-known ports in classical RSVP. I think
> > that it is unlikely the operator will assign a LSP some tunnel Id
> > without knowing what other potential ingress routers might share
> > the resources.
> 
> If an operator is going to hand-assign tunnel IDs, yes.  And in this
> situation, the operator can choose whether multiple LSPs sharing the
> tunnel ID should share resources or not by directing the 
> switch to use a
> zero or non-zero value for extended tunnel ID
> 
> It is also possible for an ingress router to automatically create LSPs
> based on topology information of some kind.  In which case, the tunnel
> IDs would be automatically generated.  Of course, in this situation,
> resource sharing would be a bad thing, and so a non-zero 
> value would be
> used for extended tunnel ID.
>

I agree fully. What I was trying to say is, if "sharing" is desired, the
operator really needs to have some "global" knowledge of the tunnel IDs;
otherwise, he/she might get a nasty surprise.
 
> > Also, the fact that the egress router is the one who decides what
> > style to use implies that some out-of-band mechanism is used to
> > ensure the proper operation between the ingress routers and the
> > egress routers.
> 
> No.  RSVP has always been egress driven.  The egress router is free to
> try and reserve with any style it wants, and using any amount of
> resources it wants.  This is all perfectly legal and part of 
> the design
> of RSVP.
> 
> Of course, a router that completely ignores the information 
> requested in
> the Path message is one that nobody will be interested in buying.  But
> it does mean that two Paths in the same session, requesting different
> reservation styles and different amounts of resources will 
> not result in
> any kind of self-contradictory state.
> 

I agree with this as well:-). My point was, the egress router needs to base
on some kind of criteria to decide the style. That is outside the scope of
RSVP. Like you said, if the egress router completely ignore the information
in the Path messages, the product might not be that appealing.
 
> > The only reason I can think of to have the tunnel Id and extended
> > tunnel Id is to tailor different needs. For example, there might be
> > some pre-determined mechanism to assign the tunnel Id at each
> > ingress router. If one router decides not to join the sharing,
> > though it is assinged a particular tunnel Id, it can add its own IP
> > in the extended tunnel Id, to exclude itself in the sharing.
> 
> This is one possible scenario.  There are others as well.
> 

I agree again. It is meant for an example.

> -- David
>