Subject: generalized MPLS signaling question

From: "Kullberg, Alan" <[email-masked]>
Date: Wed, 16 Aug 2000 10:57:19 -0400

I have a question regarding the generalized MPLS signaling draft.

     A                   B
      \                 /
       \               /
        1------2------3

In the above picture, LSRs A and B are at the edges of an optical
network, and LSRs 1, 2, and 3 are optical switches.  LSR-A has
previously setup 2 Lambda LSPs to LSR-B.  LSR-A then wants to
"label stack" on one of those Lambdas to LSR-B by requesting a
timeslot from one of the Lambda LSPs.  When LSR-A sends a
REQUEST/PATH message to LSR-B, how do LSR-A and LSR-B coordinate
the timeslot allocation so that LSR-A sends the data in the
timeslot on the correct Lambda?  Assume that signaling occurs
out of band.

It seems that LSR-A needs to send some indication to LSR-B, like
the 6-octet LSPID of the corresponding Lambda LSP, so that LSR-B
allocates a timeslot from the correct Lambda.

Thanks,

Alan

---

From: Kireeti Kompella <[email-masked]>
Date: Wed, 16 Aug 2000 09:15:55 -0700 (PDT)

> how do LSR-A and LSR-B coordinate
> timeslot on the correct Lambda?

Using the ERO.  Each lambda (actually, lambda-switched path) is
uniquely identified, either by an IP address or by an "interface"
index as defined in the unnumbered draft.

Kireeti.

---

From: "Kullberg, Alan" <[email-masked]>
Date: Wed, 16 Aug 2000 13:42:26 -0400

Eric,

Unfortunately, the LSPID ER Hop type from CR-LDP doesn't
help in this case because the LSPID ER Hop is removed
before sending the REQUEST message.  See 4.7.4/crldp-03.

Alan

> -----Original Message-----
> From: Eric Gray [mailto:[email-masked]]
> Sent: Wednesday, August 16, 2000 12:57 PM
> To: 'Kireeti Kompella'
> Cc: Eric Gray; [email-masked]; [email-masked]
> Subject: RE: generalized MPLS signaling question
> 
> 
> Kireeti,
> 
> 	Hi.
> 
> 	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.
> Since LSPs may be extended to large numbers of 
> LSRs either directly or indirectly connected, the
> number of interface IDs needed may be arbitrarily 
> large.
> 
> 	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?   
> And, although it may make sense to use an LSP that 
> directly connects the current LSR to a remote next 
> hop associated with the IPv4 prefix specified in an 
> ERO, if you cannot explicitly identify the LSP, the 
> local routing engine may decide to use another route.  
> This would appear to defeat the purpose of using the 
> ERO.
> 
> 	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, using
> Alan's specific example as a case in point, so the
> next question is - "how do we force this behavior?"
> 
> 	In CR-LDP, there is an explicit LSPID Hop type.
> Perhaps there should be a "Session" sub-object for 
> RSVP-TE?
> 
> 	Thanks!
> 
> > -----Original Message-----
> > From: Kireeti Kompella [mailto:[email-masked]]
> > Sent: Wednesday, August 16, 2000 9:16 AM
> > To: [email-masked]; [email-masked]
> > Subject: Re: generalized MPLS signaling question
> > 
> >

---

From: Eric Gray <[email-masked]>
Date: Wed, 16 Aug 2000 11:14:06 -0700

Alan,

	Been a while (one or two weeks) since I looked
at that.  Possibly there is some ambiguity (I am not
trying to say that CR-LDP has the answer), but the
next phrase (fter the one that says you have to lose
the LSP-ID Hop) says that you forward the Request
message on a session associated with that (CR-)LSP.
This makes it considerably less ambiguous than if -
say - you forward a signaling message based on a 
routing look-up for the IPv4 prefix specified as the
next ER Hop in the ERO.

	I believe that what Kireeti suggest will work
in many implementations since - as he says - the IP
address uniquely identifies the LSP.  However, it is
an IP address and therefore likely to match a route
table entry.  If the implementation injects the IP
address of the LSP as a host route into the routing
table (I don't recall if this behavior is specified),
then the LSP will be the longest match.  Then, as
long as there are not two host routes to that same IP 
address, there should be no ambiguity.

	But this fits snugly under the heading of a "neat
trick" and it would be clearer and less likely to cause
trouble down the road if some mechanism were used to
specify an LSP explicitly.

> From: Kullberg, Alan [mailto:[email-masked]]
> Sent: Wednesday, August 16, 2000 10:42 AM
> To: 'Eric Gray'; 'Kireeti Kompella'
> Cc: [email-masked]

---

From: Kireeti Kompella <[email-masked]>
Date: Wed, 16 Aug 2000 11:07:08 -0700 (PDT)

Hi Eric,

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

> 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 signalling,
there is no issue; with out-of-band signalling, you'd need
to bundle the links, and use the Link ID so both ends agree
on which link to use.

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

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

Kireeti.

---

From: Eric Gray <[email-masked]>
Date: Wed, 16 Aug 2000 11:48:50 -0700

Kireeti,

	Please see embedded comments, below.

> ... <snip> ...

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.

> you don't care which one is used.  With in-band signaling,
> there is no issue; with out-of-band signaling, you'd need

Yes, this makes sense.

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

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

---

From: Kireeti Kompella <[email-masked]>
Date: Wed, 16 Aug 2000 11:49:54 -0700 (PDT)

Hi Eric,

> specify an LSP explicitly.

Actually, if you really want to choose ("force") the path,
you'd use strict hops.  If LSPs/interfaces are uniquely
numbered, there isn't (shouldn't be!) any ambiguity.

Kireeti.

---

From: "Kullberg, Alan" <[email-masked]>
Date: Wed, 16 Aug 2000 16:44:31 -0400

Kireeti,

> Sent: Wednesday, August 16, 2000 12:16 PM

Let's assume the lambda-switched paths are unnumbered and are assigned
"interface" indices as per the unnumbered draft.  When LSR-B receives
an ERO with the "Interface ID" subobject, how is the association made
with the correct lambda-switched path for timeslot allocation?

Alan

---

From: Kireeti Kompella <[email-masked]>
Date: Wed, 16 Aug 2000 14:17:25 -0700 (PDT)

Hi Alan,

> with the correct lambda-switched path for timeslot allocation?

Excellent question.  The implicit assumption was that with out-of-band
signalling, some other means of identifying the links is used (e.g., a
variant of LMP).  I.e., LSR-A knows (per the ERO) which FA
(lambda-switched path) to use.  LSR-A and LSR-B have already identified
the links (e.g., with some variant of LMP).  LSR-A then sends the Path
message with a Link ID object (from the bundling document) to let LSR-B
know which FA LSR-A wants to use.

However, this is not altogether satisfactory (variant of LMP, etc).
An alternate solution is being worked on.

Kireeti.

---

From: Eric Gray <[email-masked]>
Date: Wed, 16 Aug 2000 15:01:25 -0700

Kireeti,

	Please see embedded comment.

> Sent: Wednesday, August 16, 2000 11:50 AM
> To: [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]

I agree that this should work.  I also like the
approach of not having a different answer for
MPLS and other link types.

What I can't seem to find is where it is made
clear that an LSR would necessarily find this 
one unique IP address route.  As I said earlier, 
it makes sense, but I don't think we can get 
away with not specifying something explicitly 
because it makes sense.  Lots of things make 
sense.

I looked through the following drafts: 	

	draft-kompella-mpls-optical-00.txt
	draft-kompella-mpls-bundle-02.txt
	draft-kompella-lsp-hierarchy-00.txt
	draft-kompella-mpls-unnum-00.txt

I was looking for something that said something
like:

"When processing an ERO, if a forwarding adjacency
 has an IP address that exactly matches the address
 in the ERO sub-object (in the case of RSVP-TE), 
 the LSP being established is expected to traverse
 the forwarding adjacency LSP using label stacking.

"If the ERO's next sub-object is an interface index
 sub-object and there is a corresponding unnumbered
 forwarding adjacency with a matching interface index,
 the LSP being established is expected to traverse
 the forwarding adjacency LSP using label stacking."

If something like this exists already, can you point
it out?

In fairness, you could argue that this is implied if
the forwarding adjacency is advertised into an IGP.
But advertising a forwarding adjacency into a specific
IGP is not mandated in any of the drafts noted above.
Yet, I assume that - if the LSP initiator somehow got
a hold of the IP address for such a FA-LSP - we would
still want the corresponding LSP used.  If not, then
this is not clear either.

Thanks!

---

From: "Kullberg, Alan" <[email-masked]>
Date: Thu, 17 Aug 2000 09:30:54 -0400

Hi Kireeti,

Thanks for the response.  The "variant of LMP" to which you
refer sounds overly complicated for the problem to be solved.
Perhaps that's why you are seeking an alternate solution.
Does the solution involve a new Object/TLV to travel in the
PATH/REQUEST message to aid in communicating to LSR-B the binding
between the FA-LSP and the PATH/REQUEST?  In my earlier email,
I suggested that the 6 octet LSPID (from CR-LDP) could serve
this purpose just fine.  To be specific, in the PATH/REQUEST
message from LSR-A to LSR-B that is requesting timeslot(s) be
assigned from the FA-LSP (lambda), a new TLV is included that
carries the LSPID corresponding to the FA-LSP that is to be
used for stacking.

Alan

> Sent: Wednesday, August 16, 2000 5:17 PM
> To: [email-masked]; [email-masked]; [email-masked]