The MPLS WG Archive

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

I am not sure I understand the message here. 

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

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.

- Mark

> -----Original Message-----
> From: David Charlap [mailto:david.charlap@marconi.com]
> Sent: Tuesday, July 31, 2001 9:01 AM
> To: 'mpls@uu.net'
> Subject: Re: Doubts about MPLS-TE Mib
> 
> 
> Apratim Mukherjee wrote:
> > 
> > So its now clear that TunnelId has a local significance only . Also
> > Extended Tunnel Id can be 0 if the intention is to have multiple
> > ingresses to a tunnel.
> 
> Correct.  Keeping in mind that "tunnel" in this context is using the
> RSVP definition of multiple LSPs that share a common session. 
>  Which is
> not the definition used by other MPLS documents.
> 
> > I1 -----------|
> >               I
> >               |-----------LSR--------------------------------- E
> >               |
> > I2 -----------|
> > 
> > Say that a tunnel is created from I1 to E with Extended Tunnel Id
> > 0.  Also , a DIFFERENT tunnel has to be created between I2 to E
> > with Extended Tunnel Id . (i.e. both the tunnels have other ingress
> > points besides I1 and I2).  Also assume that that the SE desired
> > flag is on.
> 
> Are both using extended tunnel ID of 0?  Your text isn't 
> clear on that. 
> If one uses 0, and the other uses its IP address, then the 
> two LSPs are
> in different sessions and are independant from one another.
> 
> The rest of your text reads as if you meant to say that both use
> extended tunnel ID of 0, which is what I'll assume from here on.
> 
> > Now at the LSR , the session object for the path messages MAY be
> > same since Tunnel Ids are locally assigned . That is (EgressIP in
> > Path Message from I1 =EgressIp in Path Message from I2 = E,
> > TunnelId in Path Message from I1 =TunnelId in Path Message from
> > I2 = x , ExtendedTunnelId in Path Message from I1 =ExtendedTunnelId
> > in Path Message from I2 = 0)
> > Hence , the two SESSIONs will get MERGED at the LSR , i.e , the
> > path states corresponding to the two path messages will be in the
> > SAME session.  This results in unwanted behaviour e.g. if styles
> > are different , then second path message will be dropped or
> > reservations can get merged for the two different styles is style
> > is SE for both .
> 
> If both I1 and I2 independantly choose their tunnel ID, then this can
> definitely happen.  The two will end up sharing resources.  If this is
> unacceptible, then they shouldn't use zero for extended tunnel ID.
> 
> Style conflict is not an issue.  It is the egress (E) which 
> chooses the
> style.  If it chooses SE for one LSP, it will have to use SE for all
> other LSPs in the session.  If it chooses FF, then it will 
> have to do so
> for all LSPs in the session.
> 
> Note that the "SE requested" flag is advisory.  The egress router is
> free to ignore it.  If one LSP is requesting SE style and one is not,
> there is no inherent conflict.  The egress router will simply 
> ignore one
> or the other.
> 
> > How can this be prevented if TunnelId has a local significance and
> > the same tunnelId could be generated at two ingresses for different
> > tunnels ?
> 
> Presumably, the decision to use zero for an extended tunnel 
> ID would be
> deliberate, for the explicit purpose of sharing resources 
> between LSPs. 
> It would be bordering on madness to make the zero value a router's
> default (or only) behavior!
> 
> Since no operator would want LSPs randomly sharing resources with each
> other, he would obviously want to take steps to ensure that two LSPs
> will only use the same tunnel ID when they are intended to share
> resources with each other, and at no other time.  This may be 
> via manual
> configuration of the ingress routers or through some out of band
> management tool.
> 
> The operator would also have enough common sense to use a non-zero
> extended tunnel ID for all LSPs that should not be sharing their
> resources with anyone else.
> 
> > I feel that if TunnelId has a local significance , then it must be
> > mandatory for ExtendedTunnelId to contain the Ip address and
> > multipoint to point tunnels should not be allowed . Or am i missing
> > something here ?
> 
> Your claim of "mandatory" implies that you also want to 
> forbid resource
> sharing between LSPs from different ingress routers.  I am saying that
> this sharing can be a desirable feature, if properly managed.
> 
> Note that "local significance" for tunnel ID does not imply "randomly
> generated".  And it does not preclude the use of some mechanism beyond
> the scope of the signaling protocol for keeping them organizzed.  The
> use of an extended tunnel ID of zero does not mandate random haphazard
> sharing of all resources in the network!
> 
> -- David
>