The MPLS WG Archive

[Lou Berger <lberger@labn.net>]

At 01:52 PM 9/28/00, Jonathan Lang wrote:
>Lou,
>   As we've discussed before, latency is clearly an issue.  Imagine a fiber
>cut where 80+ wavelengths are affected...

Jonathan,

IMO Curtis (at least I think it was Curtis) gave you a valid answer here, 
i.e., let routing propagate this information.

>   Why would you want intermediate nodes processing messages that aren't
>intended for them?

How do you know which node is the "intended node"?

Lou

BTW it's okay for us to disagree here, we just need to id consensus...

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