The MPLS WG Archive

[Jonathan Lang <jplang@calient.net>]

Lou,
  As we've discussed before, latency is clearly an issue.  Imagine a fiber
cut where 80+ wavelengths are affected...
  Why would you want intermediate nodes processing messages that aren't
intended for them?

-Jonathan

> -----Original Message-----
> From: Lou Berger [mailto:lberger@labn.net]
> Sent: Thursday, September 28, 2000 10:15 AM
> To: Jonathan Lang
> Cc: 'Lou Berger'; Markus Jork; mpls@UU.NET; Adrian Farrel
> Subject: RE: Multi-LSP Notify in GMPLS 
> 
> 
> 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
> > >
>