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

From: Theimer Thomas <[email-masked]>
Date: Fri, 15 Oct 1999 18:16:50 +0200

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
> -----Original Message-----
> 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,
> 
> 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.
> 
> > 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. 
>

---

From: Eric Gray <[email-masked]>
Date: Sat, 16 Oct 1999 13:12:45 -0400

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.