Subject: RE: Doubts about MPLS-TE Mib

From: "Feng, Mark" <[email-masked]>
Date: Tue, 31 Jul 2001 11:28:13 -0700

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

---

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

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

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

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

-- David