The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2001-Jul> msg00551



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

Doubts about MPLS-TE Mib

  • From: David Charlap <david.charlap@marconi.com>
  • Date: Tue, 31 Jul 2001 12:01:29 -0400

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