Fast Reroute Extensions to RSVP-TE for LSP Tunnels
RFC 4090

Approval announcement
Draft of message to be sent after approval:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
    RFC Editor <rfc-editor@rfc-editor.org>, 
    mpls mailing list <mpls@lists.ietf.org>, 
    mpls chair <mpls-chairs@tools.ietf.org>
Subject: Protocol Action: 'Fast Reroute Extensions to RSVP-TE 
         for LSP Tunnels' to Proposed Standard 

The IESG has approved the following document:

- 'Fast Reroute Extensions to RSVP-TE for LSP Tunnels '
   <draft-ietf-mpls-rsvp-lsp-fastreroute-08.txt> as a Proposed Standard

This document is the product of the Multiprotocol Label Switching Working 
Group. 

The IESG contact persons are Alex Zinin and Ross Callon.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mpls-rsvp-lsp-fastreroute-08.txt

Technical Summary
 
   This document defines extensions to and describes the use of RSVP to
   establish backup label-switched path (LSP) tunnels for local repair
   of LSP tunnels.  These mechanisms enable the re-direction of traffic
   onto backup LSP tunnels in 10s of milliseconds in the event of a
   failure. Two methods are defined.  The one-to-one backup method creates
   detour LSPs for each protected LSP at each potential point of local
   repair.  The facility backup method creates a bypass tunnel to
   protect a potential failure point; by taking advantage of MPLS label
   stacking, this bypass tunnel can protect a set of protected LSPs that
   have similar backup constraints. Both methods can be used to protect
   links and nodes during network failure.  The described behavior and
   extensions to RSVP allow nodes to implement either or both methods
   and to interoperate in a mixed network.
 
Working Group Summary
 
   Several years before work began on this draft, operational networks
   had deployed two independent methods of doing fast reroute, called
   herein one-to-one backup and facility backup.  Vendors trying to
   support both methods were experiencing incompatiblity problems in
   attempting to produce a single implementation capable of
   interoperating with both.  There are technical tradeoffs between
   the methods.  However these tradeoffs are so topologically
   dependent, that the community has not converged on a single
   approach. Both methods are considered necessary to cover different
   topological scenarios.
 
Protocol Quality
 
  The specification has been reviewed for the IESG by Alex Zinin.