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

From: "Zhang, Jeffrey" <[email-masked]>
Date: Fri, 15 Oct 1999 09:07:00 -0400

Steve,

I agree with you.

1. a targeted session is needed for the label stacking (unless we could
distribute
   labels w/o sessions - see #2).

   Peter pointed out that the existing LSP is unidirectional but a session
   needs bi-directional communication. However, does the session have to
follow
   LSPs at all? Could not it be simply over traditional IP?

   As for finding the egress point of the existing LSP, it is probably not a
big
   issue - since the ingress point of the new LSP specified to use the
existing one,
   there must be some arrangements across the network for the ingress point
of the
   existing one to know the egress.

2. you mentioned:

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

   How about using label attribute to pass the new label?

3. An interesting point that Peter mentioned was the ability to do bandwidth
   reservations within the top level tunnel. Does this mean that if the
existing
   one already has 100 units reserved, it will carve out a portion, say 60
units,
   for the new one, or will another 60 be reserved in addition to the
existing 100?

   In either case, how does scheduling make sure that the new one only get
60 units?

Jeffrey

> -----Original Message-----
> From: Atkinson, Stephen [mailto:[email-masked]]

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

snip ...

> > Zhang, Jeffrey wrote:

snip ...

> > > 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: Eric Gray <[email-masked]>
Date: Fri, 15 Oct 1999 09:40:48 -0400

>    LSPs at all? Could not it be simply over traditional IP?

Probably not.  The labels themselves cannot be 'stacked' over
IP (at least, not now and not in a standard way), so you need
some way to be reasonably certain that the target of your LSP
tunnel is in the same MPLS domain.  Having a targeted hello
adjacency with, and LSP to, that LSR is one way to do this. 
Using a protocol message which would not be forwarded beyond
an MPLS domain is another.

> ...

--
Eric Gray