Subject: RE: Doubts about MPLS-TE Mib

From: Apratim Mukherjee <[email-masked]>
Date: Tue, 31 Jul 2001 21:00:19 +0530

Hi David,

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.

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.

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 .
 How can this be prevented if TunnelId has a local significance and the same
tunnelId could be generated at two ingresses for different tunnels ?

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 ?

Thanks
Apratim

> ----------
> From: 	David Charlap[SMTP:[email-masked]]
> Sent: 	Tuesday, July 31, 2001 7:46 PM
> To: 	[email-masked]'
> Subject: 	Re: Doubts about MPLS-TE Mib
> 
> Apratim Mukherjee wrote:
> > 
> > If TunnelId is to distinguish between two sessions having the same
> > egress, then TunnelId should have a globally significant value in a
> > MPLS domain
> 
> And how do you propose to do this?  Require a global server that can
> dish out unique tunnel IDs, perhaps?  Requiring that tunnel ID be
> globally unique is not possible without adding so much overhead that
> nobody will use it.
> 
> In RSVP-TE, _ALL_ of the values in a session object (Address, tunnel ID
> and extended tunnel ID) are required to uniquely specify a session. 
> Extended tunnel ID is required because there is no reasonable way to
> ensure uniqueness of the tunnel ID field.
> 
> The only reason CR-LDP doesn't also have this problem is because CR-LDP
> incorporates the sender address as part of the LSP ID.
> 
> > 1 ) Doubt here : Where does the TunnelId come from then ?
> 
> Tunnel ID is only locally unique to the ingress node.
> 
> > 2) If TunnelId HAS a globally significant value , then why do we
> > need an Extended Tunnel Id ?
> 
> Your assumption is wrong.  It is not globally significant.  The extended
> tunnel ID is required to make the entire session object globally unique.
> 
> You can't just blindly assume that extended tunnel ID will match the
> sender address, because a zero value (meaning "don't care", needed for
> sharing resources between two LSPs from different senders) is legal.
> 
> > [ If the administrator wants to tie a tunnel to an Ingress , all he
> > has to do is to make sure that no other tunnel in the domain has
> > the same TunnelId.]
> 
> Easier said than done.  The only way an administrator can guarantee this
> is if every single LSP in the network is manually configured.  This is
> not always going to be true.
> 
> > If TunnelId is locally assigned at a node , then Extended Tunnel Id
> > MUST be set to the ingress IP address to be able to distinguish it
> > from some tunnel being made at another ingress with same tunnel id.
> 
> Unless it is intended that this LSP will share resources with another
> LSP terminating on the same node.
> 
> > ( possible since tunnel id is being locally decided ).
> > However this means that one tunnel CANNOT have two lsps belonging
> > to the same tunnel originating at two ingresses and exiting from
> > the same egress.
> 
> There is no reason why you can not have this.  That is specifically what
> the zero value for extended tunnel ID is meant for.
> 
> -- David
>

---

From: David Charlap <[email-masked]>
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.

> 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