Subject: RE: CR-LDP: notification when preempted?

From: "Atkinson, Stephen" <[email-masked]>
Date: Fri, 8 Oct 1999 16:32:32 -0400

Hi Peter,

Some comments below on LSPID ER Hops.

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
>