The MPLS WG Archive

[Eric Gray <EGray@zaffire.com>]

Kireeti,

	Please see embedded comments, below.

> ... <snip> ...
> 
> Hi Eric,
> 
> > 	I'm afraid that this doesn't help, too much,
> > in understanding how this might be done.  For one
> > thing, if the interface ID sub-object type you've
> > defined in the unnumbered draft (I am assuming you
> > refer to draft-kompella-mpls-unnum-00) is intended
> > to be used to identify LSPs, then it should maybe
> > have been defined as a larger than 16-bit field.
> 
> Yes, that's the draft.  If you really think that 65536 is
> too small, it's easy enough to make this a 24-bit number.

I've participated in a number of discussions in which
the point was made that the IETF community has a long
standing tradition of under-shooting on estimating the
size of a number space needed.

> 
> > 	For another, there's an issue with how an LSR
> > might interpret an IPv4 prefix in an ERO when there
> > are multiple routes to that prefix - including one
> > or more that traverse an LSP.  In fact, there is 
> > nothing to prevent having more than one LSP at any
> > LSR that extends toward an IPv4 prefix, is there?   
> 
> That applies as is to interfaces.  One could have several
> interfaces and/or LSPs identically numbered between two
> routers.  The fact that they are identically numbered means
> you don't care which one is used.  With in-band signaling,
> there is no issue; with out-of-band signaling, you'd need
> to bundle the links, and use the Link ID so both ends agree
> on which link to use.

Yes, this makes sense.

> 
> > 	So, I guess the question comes down to "is there
> > a reason why a user might want to force the path to
> > follow a particular LSP even when routing would prefer
> > a different path?"  I think the answer is yes.
> 
> I agree completely that choosing a path is necessary.
> a) Number the interfaces and LSPs distinctly; or
> b) Run unnumbered
> to force the path the way you choose.  Or
> 
> c) Bundle the interfaces and LSPs, and use the Link ID
> to make both ends use consistent links.
> 
> These approaches work for both interfaces and LSPs.  A
> session ID mechanism only works for LSPs; also, it isn't
> enough to extend RSVP EROs to include session IDs, you also
> need to carry the session ID in the IGP to be able to compute
> the paths you want to force (options a and b).

Okay, this makes the issues clearer.  I agree that -
if one is relying on routing protocol to develop the
ERO - then this would be needed.  I'm not sure that
this reliance on routing is assumed universally.

> 
> Question: what does a session ID offer that can't be done
> with an "interface index"?

Actually, there's an analogous operation in RSVP-TE used
to support re-routing of TE tunnels (section 2.5 of RSVP-TE).
The SENDER_TEMPLATE object for an LSP_TUNNEL_IPV4 is very
nearly identical to the LSP-ID object in CR-LDP.

The interface index would have the same effective size, if
the LSR processing the ERO is able to retain the IPv4 address 
from the ER Hop preceding the "interface index" sub-object in
the ERO being processed.  If this can be any of the LSR's 
valid IP addresses, then the "interface index" effective
size is increased by a factor of the number of IP addresses
of the processing LSR.

> 
> Kireeti.
>