Subject: RE: MPLS and fast reroute.

From: "David Allan" <[email-masked]>
Date: Thu, 8 Jun 2000 08:05:48 -0500

IMHO only in a simple case "look thog, fiber go dark", which can only deal
with gross physical defects, and I have predefined recovery strategies (such
as the virtual ring proposals the group has entertained).

Dave

> -----Original Message-----
> From:	Juan Diego Otero [SMTP:[email-masked]]
> Sent:	Thursday, June 08, 2000 6:20 AM
> To:	[email-masked]
> Subject:	MPLS and fast reroute.
> 
> Hi,
> 
> In IEEE Communications Magazine (December 1999), there is an article
> written
> by Tony Li called "MPLS and the Evolving Internet Architecture". In page
> 41,
> talking about fast reroute, Tony says: "...MPLS can also be used in a
> manner very similar to synchronous optical network (SONET), where no
> signaling is necessary to perform the protection switching of the LSP.
> This
> results in restoration times competitive with SONET." My question is:
> 
> Can anybody explain me how MPLS can be used as SONET in
> switching a LSP after a faliure, with no signaling?
> 
> Thanks a lot.
> 
> Diego Otero
> UPC (Universitat Politècnica de Catalunya)
>

---

From: Danny McPherson <[email-masked]>
Date: Thu, 08 Jun 2000 23:47:41 -0600

[snip]
From: Danny McPherson <[email-masked]>
Reply-To: [email-masked]
Subject: Re: MPLS and fast reroute. 
Date: Thu, 08 Jun 2000 21:57:37 -0600
Sender: [email-masked]

> I guess my point is misunderstood. SONET protection switching uses dedicated
> overhead bytes for signaling and end-to-end coordination. This is why SONET
> protection is fast and deterministic. MPLS uses message-based signaling to
> coordinate protection switching. With only best effort IP, there is no way you
> can guarantee to deliver these signaling messages on time. So there has to be
> infrastructure to treat these signaling messages specially. This is why I
> mentioned QoS.

Yangguang,
You're missing the point.  When using local protection the backup path is 
PRECALCULATED.  Therefore, a switch only requires failure propagation [and 
subsequent detection] of the failure by the egress interface associated with
the path in the local LSR.  There are no real-time signalling messages to 
be lost with local-protection, it occurs only within the local LSR.  Given, 
re-optimization may be desirable at the head-end, but not necessarily, and
certainly not within even IGP convergence timeframes.  

The benefit of an approach such as this in comparison to SONET APS is that 
with APS the protection infrastructure has traditionally been unusable, while 
MPLS-based restoration and TE provide a considerable amount of granularity for
other [preemptable] traffic to use the protect path under normal conditions,
as well as in additon to failure modes, if capacity is available.  If the
protection schema supports statistical multiplexing capabilities that aren't
available with SONET APS, it becomes that much more desirable to service 
providers.

IGPs also must converge when using SONET APS to protect against router 
failures
(i.e., routers connecting to ADM trib ports to provide local protection).  
This
often results in a considerable amount of non-forwarding time, with failure
detection alone introducing a significant delay, not to mention propagation 
delay
associated with routing protocol messages required for adjacency establishment 
between the new pair of interfaces/routers, and even delay introduced by path
calculation throttles over the networks as a result of near back-to-back link
state packets being flooded to report both initial failures and new links.

> MPLS doesn't need to mimic SONET protection, which so far are almost ring-based.

You're referring here only to the "network" application for APS.  It's commonly
used to protect against router failures as well.

> MPLS can use these ring protection ideas, but it should focus on mesh-based.

See above.

To reiterate Curtis's earlier comment, this has all been discussed here before.
A quick look over the mailing list archives, as well as the cited drafts, 
should
provide additional insight.

- -danny

------- End of Forwarded Message

---

From: George Frank <[email-masked]>
Date: Thu, 8 Jun 2000 11:40:53 -0700

Also see draft-makam-mpls-recovery-frmwrk-00.txt,
among others. Searching for 'recovery' or something
similar on the I-D web site turns up several
drafts.

george

> From: Curtis Villamizar [mailto:[email-masked]]
> Sent: Thursday, June 08, 2000 8:01 AM
> To: Juan Diego Otero
> Cc: [email-masked]
> In message <[email-masked]>, Juan Diego 
> Otero writes:
> > Hi,
> > 
> > UPC (Universitat Politecnica de Catalunya)
> 
> 
> See draft-ietf-mpls-rsvp-lsp-tunnel-05.txt.  The feature is known as
> local-protect in MPLS.
> 
> At each potential point of failure a backup path is created ahead of
> time.  On the LSR the spare outsegment is programmed (the hardware is
> set up) but the insegment points to the primary outsegment.  When the
> failure is detected by the interface egressing the LSR, a message is
> sent to all other interfaces.  Each interface reprograms the insegment
> (makes a table entry change) that points the insegment at the backup
> path.  This can be accomplished in about the same time required to do
> SONET restoration.
> 
> There is more information in draft-swallow-rsvp-bypass-label-00.txt,
> though this provides a means of using one LSP to backup multiple LSP
> that take the same recovery path.  It does provide additional insight
> into how this works.  You can also check the mailing list archives for
> discussion of "local protect" or "fast reroute".
> 
> Curtis
>

---

From: Danny McPherson <[email-masked]>
Date: Thu, 08 Jun 2000 21:57:37 -0600

Yangguang,

IGPs also must converge when using SONET APS to protect against router failures 
(i.e., routers connecting to ADM trib ports to provide local protection).  This 
often results in a considerable amount of non-forwarding time, with failure
detection alone introducing a significant delay, not to mention propagation delay
associated with routing protocol messages required for adjacency establishment 
between the new pair of interfaces/routers, and even delay introduced by path
calculation throttles over the networks as a result of near back-to-back link
state packets being flooded to report both initial failures and new links.

See above.

To reiterate Curtis's earlier comment, this has all been discussed here before.
A quick look over the mailing list archives, as well as the cited drafts, should
provide additional insight.

-danny

---

From: "Waldo, Michael (Michael)" <[email-masked]>
Date: Fri, 9 Jun 2000 10:46:14 -0400

>	available with SONET APS, it becomes that much more desirable to
service 

The protection infrastructure in SONET is usable (I'm not sure what was
meant by "traditionally") for some SONET protection schemes. BLSR and linear
1:1 SONET APS protection protocols/networks allow for preemptable traffic to
be carried over the protection channels. It's been defined in the SONET
standards, and the SONET products that I have worked on, supported this
capability.

-Waldo