The MPLS WG Archive

[Yakov Rekhter <yakov@cisco.com>]

Markus,

> > 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
> 
> I thought I gave an answer to this question in my original message...
> That's just how RSVP works and on what it bases its authentication
> mechanism.

I would be curious to know whether the folks who use MPLS TE today
also use RSVP authentication mechanism (or plan to use it in the
near future).

Yakov.

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