The MPLS WG Archive

[Lou Berger <lberger@labn.net>]

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

Lou

At 01:08 PM 9/28/00, Jonathan Lang wrote:
>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:lberger@labn.net]
> > Sent: Thursday, September 28, 2000 9:26 AM
> > To: Markus Jork
> > Cc: mpls@UU.NET; 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
> >