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

From: Eric Gray <[email-masked]>
Date: Wed, 20 Oct 1999 16:07:54 -0400

Steve,

	Strictly my opinion.
	
	This might be considered at the level of implementation
detail that should not be included in a protocol spec.  It is 
good that it is discussed, but this sort of thing is something 
that people will be able to figure out.

	Thanks for bringing it up.

You wrote:
> 
> Hi Bilel,
> 
> While the modified text you supplied below makes handling
> LSPID ER Hops clearer, I think it would be helpful
> to point out the restrictions inherent in this method.
> 
> The Ingress LSR for the tunnel can only know the tunnel's
> egress address (and therefore know which LDP session to
> forward on) in two ways, (1) the tunnel was setup using
> a Host FEC, or (2) the tunnel was setup with a CR-LSP
> FEC (which the CR spec recommends using) but the last
> ER Hop in the explicit route was an IPv4 Prefix with a
> "PreLen" of 32.
> 
> In all other cases the ingress LSR for the tunnel does not
> know the egress address. Note the two cases above only work
> if the tunnel wasn't extended, which section 4.8.2 of the
> CR spec allows. Also, case 2 only works if the Ingress
> LSR looks at the last ER Hop in the list. The idea of
> looking to the end of the ER Hop list to determine
> egress is not covered by section 4.8 for processing
> the Explicit Route TLV.
> 
> Do you think it would help clarify the spec further by
> pointing out these limitations?
> 
> Regards,
> steve atkinson
> 
> >-----Original Message-----
> >From: Bilel Jamoussi [mailto:[email-masked]]
> >Sent: Wednesday, October 20, 1999 1:16 AM
> >To: 'Atkinson, Stephen'; [email-masked]'
> >Cc: 'Eric Gray'; Peter Ashwood-Smith
> >Subject: RE: draft-ietf-mpls-cr-ldp-03.txt, ER-Hop LSPID
> >
> >
> >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,
> >
> >Thanks for the response, I've inserted comments below.
> >
> >Regards,
> >steve atkinson
> >
> >> -----Original Message-----
> >> From: Bilel Jamoussi [mailto:[email-masked]]
> >> Sent: Friday, October 15, 1999 11:37 AM
> >> To: 'Atkinson, Stephen'; [email-masked]'
> >> Subject: RE: draft-ietf-mpls-cr-ldp-03.txt, ER-Hop LSPID
> >>
> >>
> >> 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
> >> > > 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
> >> through) the CR-LSP
> >> > specified in the LSPID ER Hop.
> >>
> >>   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.
> >
> >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.
> >
> >>
> >> > 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.
> >>
> >>   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.
> >>
> >> >
> >> > 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)?
> >>
> >>   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
> >>
> >>
> >> 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: "Atkinson, Stephen" <[email-masked]>
Date: Wed, 20 Oct 1999 15:18:40 -0400

Hi Bilel,

Regards,
steve atkinson