The MPLS WG Archive

[John Drake <jdrake@calient.net>]

Curtis,

The intent of the Notify is to keep everything undisturbed while restoration
occurs.  In your example, a failure of a lambda  would be communicated to
the lambda LSP endpoints with a Notify.  The endpoints could then switch
over to an alternate path, if M:N path protection was being used, or else
establish a new LSP.  One of the other benefits of Notify is that since the
original LSP has not been torn down, segments of it can be reused for the
new LSP via the RSVP make before break capability.

Also, we will eventually be doing multi-area TE, and relying on IGP flooding
will not work in that context.

Thanks,

John

-----Original Message-----
From: Curtis Villamizar [mailto:curtis@workhorse.fictitious.org]
Sent: Friday, September 29, 2000 6:15 AM
To: Markus Jork
Cc: Jonathan Lang; 'Lou Berger'; mpls@UU.NET; Adrian Farrel
Subject: Re: Multi-LSP Notify in GMPLS 



In message <200009281815.e8SIF8400475@mailhost.avici.com>, Markus Jork
writes:
> Jonathan,
> 
> > 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.
> 
> Markus


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