Subject: CR-LDP: notification when preempted?

From: "Zhang, Jeffrey" <[email-masked]>
Date: Fri, 1 Oct 1999 12:06:19 -0400

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.

Should it be included in the spec? It's useful to trigger the ingress to try
to find an alternative path.

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.

Thanks.

Jeffrey

---

From: "Peter Ashwood-Smith" <[email-masked]>
Date: Fri, 01 Oct 1999 14:01:43 -0400

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

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

> not, when the LSP is broken, we need to treat it as if the peer session went

  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. 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: "Long Cheng" <[email-masked]>
Date: Thu, 14 Oct 1999 10:12:54 -0700

Does merge/non-merge capability of has any significance
on its Loop handling mechanism? 

In section 2.8 of draft-ietf-mpls-ldp-06.txt, it seems that 
a non-merge capable LSR must include a Path Vector 
when forwarding a label request/mapping message, while a 
merge capable LSR needs not to do so.
Why?

Thanks,

Long Cheng
[email-masked]