Subject: RE: Multi-LSP Notify in GMPLS

From: Adrian Farrel <[email-masked]>
Date: Fri, 29 Sep 2000 12:51:04 +0100

>>Note that whether intermediate nodes process the message is a 
>>distinct issue from whether the message traces the LSP 
>>hop-by-hop or goes along a completely different path.
>
>Care to elaborate on the importance of this issue?

Lou,
I just want to separate the discussions.

I don't think it is a big deal if every LSR on the path of a Notify passes
the message through software.  I just think it a shame not to offer the
facility for a switch to fast-path the message (i.e. not remove it from
forwarding hardware) if it is capable.  Thus I would be happy with Notify
targeted at some remote node and router alert NOT set.  It is then up to the
individual switch how optimally it processes the packets.

I believe it is important to allow a Notify to not retrace the path of the
LSP.  This allows a Notify to be routed around a fialure (2nd order failure
- so perhaps not too important).  It also allows a Notify to be sent to some
other entirely distinct node (widening the purpose of Notify from simple
protection switching).

Adrian

---

From: Lou Berger <[email-masked]>
Date: Fri, 29 Sep 2000 16:23:22 -0400

>other entirely distinct node (widening the purpose of Notify from simple

Why is this important?  If there's such a failure, the node upstream of the 
failure can (and should) generate the error (and Notify).

Lou

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 29 Sep 2000 16:38:21 -0400

In message <[email-masked]>, Adrian F
arrel writes:
> - so perhaps not too important).

Non-issue.  See my prior response.

> It also allows a Notify to be sent to some

Isn't that what SNMP TRAPs are for?

> Adrian

Curtis

---

From: Ben Mack-Crane <[email-masked]>
Date: Fri, 29 Sep 2000 15:53:49 -0500

Adrian,

In our work on MPLS recovery and protection switching we
recognized the following concern:

If the Notify is not constrained to retrace the path of the
LSP (upstream) and instead follows an IP layer forwarding path,
there is the possibility that it will run into the same fault
it is trying to report.  This could either cause it to be lost
entirely or delayed until IP routing converges (perhaps
much more delay than hop-by-hop forwarding in software).

What are your thoughts on this?

Regards,
Ben