Subject: draft-ietf-mpls-cr-ldp-03.txt, ER-Hop LSPID

From: "Atkinson, Stephen" <[email-masked]>
Date: Thu, 14 Oct 1999 18:05:53 -0400

I sent this message last week but didn't receive
any responses. Basically, I don't believe that
the statement "The result is a tunneled, or stacked
CR-LSP" (section 4.7.1 ER-Hop 4: LSPID), can
be accomplished as described.

Please see the comments I've inserted below.
Any explanation as to how a 'stacked CR-LSP' can
be created as described below, or agreement that
in fact more work is required in this area, would
be greatly appreciated.

Regards,
steve atkinson

> -----Original Message-----
> From: Peter Ashwood-Smith [mailto:[email-masked]]
> Sent: Friday, October 01, 1999 2:02 PM
> To: [email-masked]
> Subject: Re: CR-LDP: notification when preempted?
> 
> 
> Zhang, Jeffrey wrote:
> > 
> > Hi,
> > 
> > I assume that if an LSP is preempted, a notification would 
> be sent upstream,
> > but I can't find it stated in the spec.
> 
>   It would be a release/withdraw away from the LSR that has 
> decided to preemt it.
> If you decide to implement preemption before getting a 
> mapping back then
> you would send an abort/notification away from the LSR that 
> decides to 
> preempt. I'd recommend that you wait till the LSP gets its 
> mapping before
> preempting because it keeps things simple, and there is no 
> point preempting
> something that is not really up yet anyway. 
> 
> > Should it be included in the spec? It's useful to trigger 
> the ingress to try
> > to find an alternative path.
> 
>   Prepmption is no different than any other kind of failure. 
> You probably want 
> to try to reroute regardless of why you got released. 
> 
> > 
> > Another point that is not quite clear to me:
> > 
> > In the ER-HOP 4 (LSPID) case,
> > 
> >    If the LSPID Hop is not the last hop in an ER-TLV, the LSR must
> >    forward the remaining ER-TLV in a Label Request message, 
> using the
> >    CR-LSP specified by the LSPID, to the LSR that is the CR-LSP's
> >    egress. That LSR will continue processing of the CR-LSP Label
> >    Request Message.  The result is a tunneled, or stacked, CR-LSP.
> > 
> > Do we set up a peer session between the ingress and egress 
> of the LSP? If
> > not, when the LSP is broken, we need to treat it as if the 
> peer session went
> > down.
> 
>   No, the label request would propogate normally from LSR to 
> LSR but no
> ER processing would be required because you are still in the LSPID in 
> question. So no LSR peer session is required over the LSP you 
> are tunneling
> through.

If as the spec states "the result is a tunneled, or stacked, CR-LSP",
how can the LSR on the egress end of the tunnel, return a meaningful
label to the LSR on the ingress end, without a targeted session? If
the label request is "propagated normally from LSR to LSR", the label
mapping will be propagated likewise. The result would seem to be a
CR-LSP which runs parallel to (rather than tunneled thru) the CR-LSP
specified in the LSPID ER Hop. 

If it's true that a targeted session is necessary for creating stacked
CR-LSPs, another issue arises. When a label request is received
containing an LSPID ER Hop, how can the receiving LSR (which is ingress
for the LSPID) know the egress for the LSPID, and therefore determine
if a targeted session exists? If the CR-LSP (represented by the ER Hop
LSPID) were created using a Prefix or Opaque FEC the LSR won't know
the egress address, and therefore can't determine if a targeted session
exists.

In short, after reading the CR-LDP specification, I don't see how
the protocol will allow tunneled CR-LSPs to be created as described
under the ER-Hop LSPID section.

Is there some LDP method for propagating a label from the egress LSR
to the ingress LSR of a CR-LSP transparently (no targeted session)?

> One could do it with a stacked peer session too 
> although you'd
> loose the ability to to bandwidth reservations within the top 
> level tunnel
> if you don't process the request at the tandem hops. The spec 
> however does
> not preclude either approach and if my flu riddled brain is 
> working properly
> today I believe both ends could actually do it differently, 
> actually they
> WOULD do it differently anyway because a session over ONE LSP 
> is not possible
> and you need TWO LSPs to have a bidirectional stacked session.
> 
>   I agree its a somewhat vague and perhaps we should consider 
> some clarification 
> for the next version of the document.
> 
>   Cheers,
> 
>   Peter
>

---

From: "Bilel Jamoussi" <[email-masked]>
Date: Fri, 15 Oct 1999 10:37:05 -0500

Stephen,

Things are kinda hectic these days. Please see my reply below:

> >   No, the label request would propagate normally from LSR to
> > LSR but no
> CR-LSP which runs parallel to (rather than tunneled through) the CR-LSP

  Not if you don't change the label. The idea is that stacking can
be accomplished without having to have stacked sessions. For example
if I have LSP-id x.1 using labels 0.40 and 0.95 for two hops, eg:

         [A] --- 0.40 ---> [B] --- 0.95 ----> [C] 

  And then a label request comes along with ER hop of LSP-id x.1 the
request would propagate to [B] because it is following x.1, it would
arrive at [C] where it can no longer follow x.1 so off goes the request
to wherever the next ER hop takes it. Eventually a mapping comes back,
say with label 0.40. What now has to happen is that the mapping going
back to [A] has to use a shim label say #417 which it will not change
as the mapping goes back to [A]. Since we knew at A,B and C that we
were tunneling through x.1 on the forward going request we can mark
the state such that we don't allocate new labels for the reverse 
direction. The end result is that packets flowing would do this:

    ---> [A] --- 0.40/#417 -> [B] --> 0.95/#417 --> [C] --> 0.40 

   So, at [A] we know to push two labels, and at [C] we know to
pop two labels and map shim label #417 to the egress label 0.40. 

   This approach is far simpler than having a new LDP session over
the LSP and allows us to do bandwidth reservations etc. at [B] and [C]
which with a stacked session we could not easily do.

> under the ER-Hop LSPID section.

  The protocol specifies how you communicate with a peer, by changing
how/if you allocate labels you can implement stacking without changes
to the spec.

> to the ingress LSR of a CR-LSP transparently (no targeted session)?

  You would mark the state as requiring stacking when processing the 
label request, and read that state in the reverse direction to avoid
changing the label in the reverse flowing mapping.

Bilel. 

-----Original Message-----
From: Atkinson, Stephen [mailto:[email-masked]]
Sent: Thursday, October 14, 1999 6:06 PM
To: [email-masked]'
Cc: Atkinson, Stephen
Subject: draft-ietf-mpls-cr-ldp-03.txt, ER-Hop LSPID

Regards,
steve atkinson

---

From: "Zhang, Jeffrey" <[email-masked]>
Date: Mon, 18 Oct 1999 11:47:09 -0400

Eric,

After reading this one I finally figured out how it is done. Looks like the
following assumptions are made in the draft:

1. Label request/map messages do not necessarily require a session.
   Maybe this is already a fact that I missed?

2. There is another LSP from the egress to the ingress of the existing LSP
   to carry label mapping messages.

If you could make them clear in the document it would be great.

Thanks.

Jeffrey

> From: Eric Gray [mailto:[email-masked]]
> Sent: Saturday, October 16, 1999 1:13 PM
> To: Theimer Thomas
> Cc: Bilel Jamoussi; Multi-Protocol Label Switching WG
> Subject: Re: draft-ietf-mpls-cr-ldp-03.txt, ER-Hop LSPID
> 
> 
> Thomas,
> 
> 	We had thought of it along these lines:
> 
>     ---R1---R2-.                  .-R6---R7---
>                 \                /
>                  `-R3---R4---R5-'
> 
> If you want to tunnel labeled packets from R2 to R6 using an
> existing CR-LSP through R3, R4 and R5, you would have an ERO
> like this:
> 
>     R1, R2, CR-LSP-ID-1, R6, R7
> 
> R1, etc., would be node addresses and CR-LSP-ID-1 would be the
> ID of the explicitly routed LSP from R2 to R6.  Obviously, the
> explicitly routed LSP specified must exist.
> 
> While processing this ERO at R2, R2 would discover that the ERO
> hop left at the head of the remaining ERO after removing R2 from
> that position is an existing CR-LSP and the destination for that
> CR-LSP is also the next hop (R6) after the CR-LSP identified.
> 
> R2 must look for a next hop after the CR-LSP identified because,
> if there is no next hop, then R2 splices the current explicitly
> routed LSP into the CR-LSP identified and returns a Label Mapping
> (R2 has completed a local repair, for example).
> 
> Having noted that R6 is the next hop after the CR-LSP identified,
> and also the destination for that CR-LSP, R2 forwards the Label
> Request with R6 at the head of the ERO hop list.  The Label
> Mapping would be forwarded ON the CR-LSP identified, and would
> therefore be invisible to R3, R4 and R5.
> 
> This allows for the isolation you are speaking of (the hierarchical
> simplifications).  It also explains why the Label Mapping is left
> unchanged in returning along the reciprocal LSP from R6 to R2.  As
> explained in a separate mailing, such a reciprocal LSP must exist
> as well.
> 
> This is the model we had in mind when reviewing the current draft,
> and - as far as I can tell - this model is consistent with what is
> stated in the text.
> 
> 
> You wrote:
> > 
> > Bilel,
> > 
> > I must admit I am a little bit confused about this concept 
> of stacking LSPs.
> > Are you saying that when stacking LSP B on top of LSP A, 
> all the nodes along
> > LSP A need to know about LSP B ? They even have to allocate 
> bandwidth for
> > LSP B ? Even if initially no bandwidth/resources were 
> allocated to LSP A ?
> > 
> > I would have thought that only the ingress and egress nodes 
> of LSR A need to
> > handle these things, but not the intermediate transit 
> nodes. Isn't that the
> > idea behind a network hierarchy ? To hide complexity from 
> the lower levels
> > of your hierarchy ?
> > 
> > Perhaps you could explain the motivation behind your ideas ?
> > 
> > Regards,
> > 
> > Thomas
> > > From: Bilel Jamoussi [SMTP:[email-masked]]
> > > Sent: Friday, October 15, 1999 5:37 PM
> > > To:   'Atkinson, Stephen'; [email-masked]'
> > > Subject:      RE: draft-ietf-mpls-cr-ldp-03.txt, ER-Hop LSPID
> > >
> > > Stephen,
> > >

---

From: "Atkinson, Stephen" <[email-masked]>
Date: Mon, 18 Oct 1999 13:33:13 -0400

Hi Bilel,

Thanks for the response, I've inserted comments below.

Regards,
steve atkinson

> From: Bilel Jamoussi [mailto:[email-masked]]
> Sent: Friday, October 15, 1999 11:37 AM

Ok, I can see how this would work, two comments:

1. We are sending Generic Labels over an LDP session between
(possibly) "directly connected" peers. In the case of ATM these
session peers would be expecting VCI's as labels, not Generic
Labels. It's not intuitive that implementers would allow for
Generic Labels received on a session using ATM or FR labels.

2. Lets look at tearing down these CR-LSPs in the following
case 

   R1---R2              R6---R7
          \            /
           R3---R4---R5
                       \
                        R8---R9

Say we have two CR-LSPs,
LSPID-1: Ingress R2, Egress R6 and
LSPID-2: Ingress R2, Egress R8.

These two CR-LSPs are subsequently used as LSPID ER Hops in 
setting up two more CR-LSPs, LSPID-3, which uses LSPID-1
as an ER Hop, and LSPID-4 which uses LSPID-2 as an ER Hop.

The result can be that Both R6 and R8 return the same label "L1"
to R2. When the CR-LSPs 3 and 4 are torn down via either a Release
or Withdraw message, R4 won't know which CR-LSP is being
torn down since they both use the same label. R4 can
determine which CR-LSP is being torn down if the 
Release/Withdraw message contains the LSPID, but the
LSPID is optional.

I think it would be helpful if the cr-ldp spec elaborated with
examples on how labels are propagated when using LSPIDs as ER
Hops and on issues such as the two above.

---

From: "Atkinson, Stephen" <[email-masked]>
Date: Mon, 18 Oct 1999 17:51:41 -0400

Hi Eric,

I'm still unclear on your method for handling LSPID
ER Hops. I've inserted comments (questions) below.

Regards,
steve atkinson

> therefore be invisible to R3, R4 and R5.

Are you saying that the Label Request and Label Mapping messages
are forwarded on the data plane of the CR-LSP identified? If 
"The Label Mapping would be forwarded ON the CR-LSP identified",
what is the protocol stack which follows the label?

---

From: Eric Gray <[email-masked]>
Date: Tue, 19 Oct 1999 11:10:24 -0400

Liwen,

	I tried really hard not to get dragged into a
tedious E-Mail debate on this issue.  Oh well. :-)

	Please see comment below.

EG  >       However, there may be several CR-LSPs established between
EG  > R2 and R6 (different VPNs for example, or different levels of
QoS).
EG  > It should be the ingress LSR that is setting up the tunneled LSP
EG  > that decides which of these several LSPs between R2 and R6 is to
EG  > be used in tunneling the LSP that is currently being setup.

JZ  > Suppose there are several new LSPs to be setup, each using a
different LSP
JZ  > between R2 and R6. I assume one session is enough for all of them,
right?

JZ  > I am asking this question because the answer to it will answer
some of my
JZ  > previous questions - does the session need to follow the existing
LSPs, and
JZ  > do we need LSPs in the reverse direction?
JZ  >
JZ  > My understanding is, if one session is good enough, then the
session does
JZ  > not have to follow the existing LSPs (otherwise, which one does it
follow?
 
LW  > LDP runs directly on top of TCP, which means LDP msgs can be sent
through
LW  > any underline transport mechanisms. They can be hop-by-hop ip, or
LSPs.

A slight simplification.  There is the issue of whether or not the 
session is associated with a platform wide, or interface specific,
label space.

Note that, where there are multiple LSPs between two common end
points, it is less likely that a platform wide label space will
be used since this takes directly away from the scale advantage 
of using tunnels.  With a platform wide label space, each label 
can only be used once across all tunnels between the two tunnel
end stations.

---

From: "Bilel Jamoussi" <[email-masked]>
Date: Wed, 20 Oct 1999 00:15:57 -0500

Ok, It obvious from this thread that further clarification in the CRLDP
draft is needed on the LSPID hop.

Eric, Peter, and I discussed this issue and feel that the following text
should remove any ambiguity on how LSPID hops are treated in the stacked
case:

Replace the current last paragraph in Section 4.7.4 -

  "If the LSPID Hop is not the last hop in an ER-TLV, the LSR must
   forward the remaining ER-TLV in a Label Request message, using the
   CR-LSP specified by the LSPID, to the LSR that is the CR-LSP's
   egress. That LSR will continue processing of the CR-LSP Label
   Request Message.  The result is a tunneled, or stacked, CR-LSP."

- with -

  "If the LSPID Hop is not the last hop in an ER-TLV, the LSR must
   remove the LSP-ID Hop and forward the remaining ER-TLV in a 
   Label Request message using an LDP session established with
   the LSR that is the specified CR-LSP's egress.  That LSR will 
   continue processing of the CR-LSP Label Request Message.  The 
   result is a tunneled, or stacked, CR-LSP."

  "To support labels negotiated for tunneled CR-LSP segments, an 
   LDP session is required [1] between tunnel end points - possibly 
   using the existing CR-LSP.  Use of the existence of the CR-LSP 
   in lieu of a session, or other possible session-less approaches, 
   is FFS."

We feel that this change should close this issue.

Bilel.

-----Original Message-----
From: Atkinson, Stephen [mailto:[email-masked]]
Sent: Monday, October 18, 1999 1:33 PM
To: Jamoussi, Bilel [BL3:2001-I:EXCH]; Atkinson, Stephen; [email-masked]'
Subject: RE: draft-ietf-mpls-cr-ldp-03.txt, ER-Hop LSPID

Hi Bilel,

Regards,
steve atkinson

   R1---R2              R6---R7
          \            /
           R3---R4---R5
                       \
                        R8---R9

Say we have two CR-LSPs,