Subject: RE: Multi-LSP Notify in GMPLS

From: Jonathan Lang <[email-masked]>
Date: Thu, 28 Sep 2000 10:08:22 -0700

Lou,
  You are correct that you don't have agreement with your co-authors on
removing the Notify.  The Notify message is a new general notification
procedure that is NOT restricted to be sent to a source/destination node and
should not be processed by intermediate nodes.  These features are desirable
for restoration/protection among other things.

Thanks,
Jonathan

> -----Original Message-----
> From: Lou Berger [mailto:[email-masked]]
> Sent: Thursday, September 28, 2000 9:26 AM
> To: Markus Jork
> Cc: [email-masked]; Adrian Farrel
> Subject: Re: Multi-LSP Notify in GMPLS 
> 
> 
> See below.
> 
> At 12:01 PM 9/28/00, Markus Jork wrote:
> >Adrian,
> >
> >it seems to me the invention of the Notify message in GMPLS was not
> >such a great idea. It's only purpose is to reduce the latency of
> >error message delivery back to the LSP ingress. So instead of the
> >slow path forwarding of the PathErr message by the router software
> >you now get fast path forwarding of the Notify message by the router
> >hardware.  Does this gain justify the circumvention of RSVP's
authentication
> >mechanism (RFC 2747)? RSVP security is based on message authentication
> >between neighbors but the Notify message is not send hop-by-hop
> >through neighboring routers that are configured to trust each other.
> >You now also point this out in your rewrite of section 5.1.1.
> >
> >There is also no discussion of backwards compatibility.
> >In your modified version of section 5, you write:
> >
> >    The Notify message does not replace existing error messages, but may
> >    initially be sent instead of existing error messages where the intent
> >    is that the Notify recipient should take remedial action before the
> >    network has recourse to the normal error processing.
> >
> >Because the Notify message is sent instead of a regular PathErr
> >message, a node that receives the Notify but does not support it
> >will not get any error indication from RSVP signalling at all!
> 
> I think it's worth pointing out that Adrian's version differs 
> from the most recent draft, which says "The Notify message does not
replace 
> existing error messages. "  I think any attempt to replace base RSVP
messages with a 
> notify would be misguided.  I don't know if this is what Adrian meant to 
> imply.  (Although this is one reading of the his text.)
> 
> >I suggest to remove the Notify message from the GMPLS draft.
> 
> This would be fine with me particularly since a PathErr 
> message doesn't modify state.  (I'm sure some of my co-authors will
disagree 
> with me on dropping it.)
> 
> Lou
> 
> >If not, the "Security Considerations" section needs to be updated:
> >the Notify message *does* introduce new security issues.
> >
> >Markus
>

---

From: Lou Berger <[email-masked]>
Date: Thu, 28 Sep 2000 13:15:01 -0400

Why do you care if intermediate nodes process the notify?  Is it just 
intermediate node processing vs. forwarding latency?

Lou

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 28 Sep 2000 16:09:39 -0400

> for restoration/protection among other things.

A path-error would also propogate to the ingress of a LSP and is seen
by the controlling entity for each hop of the LSP, including a LSC
LSP.  So we've not adding any capability.

Curtis