--- 1/draft-ietf-mpls-rsvp-lsp-fastreroute-02.txt	2006-02-05 00:42:32.000000000 +0100
+++ 2/draft-ietf-mpls-rsvp-lsp-fastreroute-03.txt	2006-02-05 00:42:32.000000000 +0100
@@ -1,22 +1,22 @@
 
 Internet Draft                               Ping Pan, Ed  (Ciena Corp)
-Expires: Aug 2003                        Der-Hwa Gan (Juniper Networks)
+Expires: Dec 2003                        Der-Hwa Gan (Juniper Networks)
                                         George Swallow  (Cisco Systems)
                                   Jean Philippe Vasseur (Cisco Systems)
                                           Dave Cooper (Global Crossing)
                                          Alia Atlas, Ed (Avici Systems)
                                             Markus Jork (Avici Systems)
 
            Fast Reroute Extensions to RSVP-TE for LSP Tunnels
 
-              draft-ietf-mpls-rsvp-lsp-fastreroute-02.txt
+              draft-ietf-mpls-rsvp-lsp-fastreroute-03.txt
 
 Status of this Memo
 
    This document is an Internet-Draft and is in full conformance with
    all provisions of Section 10 of RFC2026.
 
    Internet-Drafts are working documents of the Internet Engineering
    Task Force (IETF), its areas, and its working groups.  Note that
    other groups may also distribute working documents as Internet-
    Drafts.
@@ -43,20 +43,50 @@
    Two methods are defined here.  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.
 
+0.  Background
+
+   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.
+
+   This draft rationalizes the RSVP signaling for both methods such
+   that any implementation can recognize all FRR requests and clearly
+   respond, either positively if they are capable of performing the
+   method, or with a clear error such that requester is informed and
+   can seek alternate means of backup.  This draft also allows a
+   single implementation to support both methods, thereby providing a
+   range of capabilities.  Thus the described behavior and extensions
+   to RSVP allow LERs and LSRs to implement either or both methods.
+
+   While the two methods could in principle be used in a single
+   network, it is expected that operators will continue to choose to
+   deploy either one or the other.  The goal of this draft is to
+   standardize the RSVP signaling such that either a network with LSRs
+   that implement both methods or an network composed of some LSRs
+   that support one method and others that support both, can properly
+   signal among those LSRs to achieve fast restoration through the
+   chosen method.
+
 Contents
 
     1  Introduction   .............................................  4
     2  Terminology  ...............................................  4
     3  Local Repair Techniques  ...................................  6
        3.1  One-to-one Backup  ....................................  6
        3.2  Facility Backup  ......................................  7
     4  RSVP Extensions  ...........................................  8
      4.1  FAST_REROUTE Object  ....................................  8
      4.2  DETOUR Object  .......................................... 11