Subject: RE: Multi-LSP Notify in GMPLS

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

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:[email-masked]]
> Sent: Thursday, September 28, 2000 10:15 AM
> To: Jonathan Lang
> Cc: 'Lou Berger'; Markus Jork; [email-masked]; 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:[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 14:02:40 -0400

>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

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

---

From: Markus Jork <[email-masked]>
Date: Thu, 28 Sep 2000 14:15:08 -0400

Jonathan,

>   Why would you want intermediate nodes processing messages that aren't

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.

Markus

---

From: Yakov Rekhter <[email-masked]>
Date: Thu, 28 Sep 2000 11:52:22 -0700

Markus,

> That's just how RSVP works and on what it bases its authentication

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.

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 29 Sep 2000 09:15:02 -0400

> That's just how RSVP works and on what it bases its authentication

Both happen.  RSVP tears go out and the IGP advertises the loss of an
adjacency.

The hierarchy of tunnels can have an impact on restoration.  In the
optical domain, if the lambdas are in use a number of LSC tunnels have
been set up and over these a number of PSC-1 tunnels have been set up.

The 80+ RSVP tear messages go to the ingress of those tunnels and the
IGP advertisement goes out to declare the LSC hop down.  If there is
restoration in the optical domain, at the ingress or at any midpoint,
the LSC tunnels remain up.  Any PSC tunnels that use the LSC tunnels
rather than rely on the optical hop by hop are unaffected.

If there is no restoration in the optical domain, the PSC-1 tunnel may
provide restoration through some means such as having a backup path.
Alternately the PSC tunnel may reroute at the time of failure if the
(rather long by SONET standards) restoration time of this method is
acceptable to the traffic that is tunneled through it.

If the PSC-1 tunnel can be restored the tunnels that go through it are
unaffected.

By unaffected here I hean that no rerouting occurred at that level in
the hierarchy (for example a PSC-2 tunnel was not rerouted).  Some
loss occurred if a fiber was cut and restored no matter how it gets
restored.

The last thing you want to happen is to notify each of the thousands
of MPLS edge to edge tunnels that go through those 80+ fibers.  The
lower down in the hierarchy that the restoration occurs the better.
Ideally it impacts 80+ tunnels and no more.  The Notify doesn't really
help much because optimizing at that level misses the point.

Curtis