doc: Add RFC documents

1 files changed, 1347 insertions, 0 deletions

diff --git a/doc/rfc/rfc8271.txt b/doc/rfc/rfc8271.txt
new file mode 100644
index 0000000..61ca398
--- /dev/null
+++ b/doc/rfc/rfc8271.txt
@@ -0,0 +1,1347 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                        M. Taillon
+Request for Comments: 8271                                  T. Saad, Ed.
+Updates: 4090                                             R. Gandhi, Ed.
+Category: Standards Track                                         Z. Ali
+ISSN: 2070-1721                                      Cisco Systems, Inc.
+                                                               M. Bhatia
+                                                                   Nokia
+                                                            October 2017
+
+
+    Updates to the Resource Reservation Protocol for Fast Reroute of
+         Traffic Engineering GMPLS Label Switched Paths (LSPs)
+
+Abstract
+
+   This document updates the Resource Reservation Protocol - Traffic
+   Engineering (RSVP-TE) Fast Reroute (FRR) procedures defined in RFC
+   4090 to support Packet Switch Capable (PSC) Generalized Multiprotocol
+   Label Switching (GMPLS) Label Switched Paths (LSPs).  These updates
+   allow the coordination of a bidirectional bypass tunnel assignment
+   protecting a common facility in both forward and reverse directions
+   of a co-routed bidirectional LSP.  In addition, these updates enable
+   the redirection of bidirectional traffic onto bypass tunnels that
+   ensure the co-routing of data paths in the forward and reverse
+   directions after FRR and avoid RSVP soft-state timeout in the control
+   plane.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc8271.
+
+
+
+
+
+
+
+
+
+
+
+Taillon, et al.              Standards Track                    [Page 1]
+
+RFC 8271                  FRR for TE GMPLS LSPs             October 2017
+
+
+Copyright Notice
+
+   Copyright (c) 2017 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (https://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Taillon, et al.              Standards Track                    [Page 2]
+
+RFC 8271                  FRR for TE GMPLS LSPs             October 2017
+
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
+   2.  Conventions Used in This Document . . . . . . . . . . . . . .   5
+     2.1.  Key Word Definitions  . . . . . . . . . . . . . . . . . .   5
+     2.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   5
+     2.3.  Abbreviations . . . . . . . . . . . . . . . . . . . . . .   6
+   3.  Fast Reroute for Unidirectional GMPLS LSPs  . . . . . . . . .   6
+   4.  Bypass Tunnel Assignment for Bidirectional GMPLS LSPs . . . .   7
+     4.1.  Bidirectional GMPLS Bypass Tunnel Direction . . . . . . .   7
+     4.2.  Merge Point Labels  . . . . . . . . . . . . . . . . . . .   7
+     4.3.  Merge Point Addresses . . . . . . . . . . . . . . . . . .   7
+     4.4.  RRO IPv4/IPv6 Subobject Flags . . . . . . . . . . . . . .   8
+     4.5.  Bidirectional Bypass Tunnel Assignment Coordination . . .   8
+       4.5.1.  Bidirectional Bypass Tunnel Assignment Signaling
+               Procedure . . . . . . . . . . . . . . . . . . . . . .   8
+       4.5.2.  One-to-One Bidirectional Bypass Tunnel Assignment . .  10
+       4.5.3.  Multiple Bidirectional Bypass Tunnel Assignments  . .  10
+   5.  Fast Reroute for Bidirectional GMPLS LSPs with In-Band
+       Signaling . . . . . . . . . . . . . . . . . . . . . . . . . .  11
+     5.1.  Link Protection for Bidirectional GMPLS LSPs  . . . . . .  12
+       5.1.1.  Behavior after Link Failure . . . . . . . . . . . . .  13
+       5.1.2.  Revertive Behavior after Fast Reroute . . . . . . . .  13
+     5.2.  Node Protection for Bidirectional GMPLS LSPs  . . . . . .  13
+       5.2.1.  Behavior after Link Failure . . . . . . . . . . . . .  14
+       5.2.2.  Behavior after Link Failure to Restore Co-routing . .  14
+       5.2.3.  Revertive Behavior after Fast Reroute . . . . . . . .  16
+       5.2.4.  Behavior after Node Failure . . . . . . . . . . . . .  16
+     5.3.  Unidirectional Link Failures  . . . . . . . . . . . . . .  16
+   6.  Fast Reroute For Bidirectional GMPLS LSPs with Out-of-Band
+       Signaling . . . . . . . . . . . . . . . . . . . . . . . . . .  17
+   7.  Message and Object Definitions  . . . . . . . . . . . . . . .  17
+     7.1.  BYPASS_ASSIGNMENT Subobject . . . . . . . . . . . . . . .  17
+     7.2.  FRR Bypass Assignment Error Notify Message  . . . . . . .  19
+   8.  Compatibility . . . . . . . . . . . . . . . . . . . . . . . .  20
+   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  20
+   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  21
+     10.1.  BYPASS_ASSIGNMENT Subobject  . . . . . . . . . . . . . .  21
+     10.2.  FRR Bypass Assignment Error Notify Message . . . . . . .  21
+   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  22
+     11.1.  Normative References . . . . . . . . . . . . . . . . . .  22
+     11.2.  Informative References . . . . . . . . . . . . . . . . .  23
+   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  23
+   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  24
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  24
+
+
+
+
+
+
+Taillon, et al.              Standards Track                    [Page 3]
+
+RFC 8271                  FRR for TE GMPLS LSPs             October 2017
+
+
+1.  Introduction
+
+   Packet Switch Capable (PSC) Traffic Engineering (TE) Label Switched
+   Paths (LSPs) can be set up using Generalized Multiprotocol Label
+   Switching (GMPLS) signaling procedures specified in [RFC3473] for
+   both unidirectional and bidirectional tunnels.  The GMPLS signaling
+   allows sending and receiving the RSVP messages in-band with the data
+   traffic or out-of-band over a separate control channel.  Fast Reroute
+   (FRR) [RFC4090] has been widely deployed in the packet TE networks
+   today and is desirable for TE GMPLS LSPs.  Using FRR methods also
+   allows the leveraging of existing mechanisms for failure detection
+   and restoration in deployed networks.
+
+   The FRR procedures defined in [RFC4090] describe the behavior of the
+   Point of Local Repair (PLR) to reroute traffic and signaling onto the
+   bypass tunnel in the event of a failure for protected LSPs.  Those
+   procedures are applicable to the unidirectional protected LSPs
+   signaled using either RSVP-TE [RFC3209] or GMPLS procedures
+   [RFC3473].  When using the FRR procedures defined in [RFC4090] with
+   co-routed bidirectional GMPLS LSPs, it is desired that same PLR and
+   Merge Point (MP) pairs are selected in each direction and that both
+   PLR and MP assign the same bidirectional bypass tunnel.  This
+   document updates the FRR procedures defined in [RFC4090] to
+   coordinate the bidirectional bypass tunnel assignment and to exchange
+   MP labels between upstream and downstream PLRs of the protected
+   co-routed bidirectional LSP.
+
+   When using FRR procedures with co-routed bidirectional GMPLS LSPs, it
+   is possible in some cases for the RSVP signaling refreshes to stop
+   reaching certain nodes along the protected LSP path after the PLRs
+   finish rerouting of the signaling messages.  This can occur after a
+   failure event when using node protection bypass tunnels.  As shown in
+   Figure 2, this is possible even with selecting the same bidirectional
+   bypass tunnels in both directions and the same PLR and MP pairs.
+   This is caused by the asymmetry of paths that may be taken by the
+   bidirectional LSP's signaling in the forward and reverse directions
+   due to upstream and downstream PLRs independently triggering FRR.  In
+   such cases, after FRR, the RSVP soft-state timeout causes the
+   protected bidirectional LSP to be torn down, with subsequent traffic
+   loss.
+
+   Protection State Coordination Protocol [RFC6378] is applicable to FRR
+   [RFC4090] for local protection of co-routed bidirectional LSPs in
+   order to minimize traffic disruptions in both directions.  However,
+   this does not address the above-mentioned problem of RSVP soft-state
+   timeout that can occur in the control plane.
+
+
+
+
+
+Taillon, et al.              Standards Track                    [Page 4]
+
+RFC 8271                  FRR for TE GMPLS LSPs             October 2017
+
+
+   This document defines a solution to the RSVP soft-state timeout issue
+   by providing mechanisms in the control plane to complement the FRR
+   procedures of [RFC4090].  This solution allows the RSVP soft state
+   for co-routed, protected bidirectional GMPLS LSPs to be maintained in
+   the control plane and enables co-routing of the traffic paths in the
+   forward and reverse directions after FRR.
+
+   The procedures defined in this document apply to PSC TE co-routed,
+   protected bidirectional LSPs and co-routed bidirectional FRR bypass
+   tunnels both signaled by GMPLS.  Unless otherwise specified in this
+   document, the FRR procedures defined in [RFC4090] are not modified by
+   this document.  The FRR mechanism for associated bidirectional GMPLS
+   LSPs where two unidirectional GMPLS LSPs are bound together by using
+   association signaling [RFC7551] is outside the scope of this
+   document.
+
+2.  Conventions Used in This Document
+
+2.1.  Key Word Definitions
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in
+   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+   capitals, as shown here.
+
+2.2.  Terminology
+
+   The reader is assumed to be familiar with the terminology in
+   [RFC2205], [RFC3209], [RFC3471], [RFC3473], and [RFC4090].
+
+   Downstream PLR: Downstream Point of Local Repair
+      The PLR that locally detects a failure in the downstream direction
+      of the traffic flow and reroutes traffic in the same direction of
+      the protected bidirectional LSP RSVP Path signaling.  A downstream
+      PLR has a corresponding downstream MP.
+
+   Downstream MP: Downstream Merge Point
+      The LSR where one or more backup tunnels rejoin the path of the
+      protected LSP in the downstream direction of the traffic flow.
+      The same LSR can be both a downstream MP and an upstream PLR
+      simultaneously.
+
+   Upstream PLR: Upstream Point of Local Repair
+      The PLR that locally detects a failure in the upstream direction
+      of the traffic flow and reroutes traffic in the opposite direction
+      of the protected bidirectional LSP RSVP Path signaling.  An
+      upstream PLR has a corresponding upstream MP.
+
+
+
+Taillon, et al.              Standards Track                    [Page 5]
+
+RFC 8271                  FRR for TE GMPLS LSPs             October 2017
+
+
+   Upstream MP: Upstream Merge Point
+      The LSR where one or more backup tunnels rejoin the path of the
+      protected LSP in the upstream direction of the traffic flow.  The
+      same LSR can be both an upstream MP and a downstream PLR
+      simultaneously.
+
+   Point of Remote Repair (PRR)
+      A downstream MP that assumes the role of upstream PLR upon
+      receiving the protected LSP's rerouted Path message and triggers
+      reroute of traffic and signaling in the upstream direction of the
+      traffic flow using the procedures described in this document.
+
+2.3.  Abbreviations
+
+   GMPLS: Generalized Multiprotocol Label Switching
+
+   LSP: Label Switched Path
+
+   LSR: Label Switching Router
+
+   MP: Merge Point
+
+   MPLS: Multiprotocol Label Switching
+
+   PLR: Point of Local Repair
+
+   PSC: Packet Switch Capable
+
+   RSVP: Resource Reservation Protocol
+
+   TE: Traffic Engineering
+
+3.  Fast Reroute for Unidirectional GMPLS LSPs
+
+   The FRR procedures defined in [RFC4090] for RSVP-TE signaling
+   [RFC3209] are equally applicable to the unidirectional protected LSPs
+   signaled using GMPLS [RFC3473] and are not modified by the updates
+   defined in this document except for the following:
+
+   When using the GMPLS out-of-band signaling [RFC3473], after a link
+   failure event, the RSVP messages are not rerouted over the bypass
+   tunnel by the downstream PLR but instead are rerouted over a control
+   channel to the downstream MP.
+
+
+
+
+
+
+
+
+Taillon, et al.              Standards Track                    [Page 6]
+
+RFC 8271                  FRR for TE GMPLS LSPs             October 2017
+
+
+4.  Bypass Tunnel Assignment for Bidirectional GMPLS LSPs
+
+   This section describes signaling procedures for FRR bidirectional
+   bypass tunnel assignment for GMPLS signaled PSC co-routed
+   bidirectional TE LSPs for both in-band and out-of-band signaling.
+
+4.1.  Bidirectional GMPLS Bypass Tunnel Direction
+
+   This document defines procedures where bidirectional GMPLS bypass
+   tunnels are signaled in the same direction as the protected GMPLS
+   LSPs.  In other words, the bidirectional GMPLS bypass tunnels
+   originate on the downstream PLRs and terminate on the corresponding
+   downstream MPs.  As the originating downstream PLR has the policy
+   information about the locally provisioned bypass tunnels, it always
+   initiates the bypass tunnel assignment.  The bidirectional GMPLS
+   bypass tunnels originating from the upstream PLRs and terminating on
+   the corresponding upstream MPs are outside the scope of this
+   document.
+
+4.2.  Merge Point Labels
+
+   To correctly reroute data traffic over a node protection bypass
+   tunnel, the downstream and upstream PLRs have to know, in advance,
+   the downstream and upstream MP labels of the protected LSP so that
+   data in the forward and reverse directions can be redirected through
+   the bypass tunnel after FRR, respectively.
+
+   [RFC4090] defines procedures for the downstream PLR to obtain the
+   protected LSP's downstream MP label from recorded labels in the
+   RECORD_ROUTE Object (RRO) of the RSVP Resv message received at the
+   downstream PLR.
+
+   To obtain the upstream MP label, the procedures specified in
+   [RFC4090] are used to record the upstream MP label in the RRO of the
+   RSVP Path message of the protected LSP.  The upstream PLR obtains the
+   upstream MP label from the recorded labels in the RRO of the received
+   RSVP Path message.
+
+4.3.  Merge Point Addresses
+
+   To correctly assign a bidirectional bypass tunnel, the downstream and
+   upstream PLRs have to know, in advance, the downstream and upstream
+   MP addresses.
+
+   [RFC4561] defines procedures for the downstream PLR to obtain the
+   protected LSP's downstream MP address from the recorded Node-IDs in
+   the RRO of the RSVP Resv message received at the downstream PLR.
+
+
+
+
+Taillon, et al.              Standards Track                    [Page 7]
+
+RFC 8271                  FRR for TE GMPLS LSPs             October 2017
+
+
+   To obtain the upstream MP address, the procedures specified in
+   [RFC4561] are used to record upstream MP Node-ID in the RRO of the
+   RSVP Path message of the protected LSP.  The upstream PLR obtains the
+   upstream MP address from the recorded Node-IDs in the RRO of the
+   received RSVP Path message.
+
+4.4.  RRO IPv4/IPv6 Subobject Flags
+
+   RRO IPv4/IPv6 subobject flags are defined in [RFC4090], Section 4.4
+   and are equally applicable to the FRR procedure for the protected
+   bidirectional GMPLS LSPs.
+
+   The procedures defined in [RFC4090] are used by the downstream PLR to
+   signal the IPv4/IPv6 subobject flags upstream in the RRO of the RSVP
+   Resv message of the protected LSP.  Similarly, those procedures are
+   used by the downstream PLR to signal the IPv4/IPv6 subobject flags
+   downstream in the RRO of the RSVP Path message of the protected LSP.
+
+4.5.  Bidirectional Bypass Tunnel Assignment Coordination
+
+   This document defines signaling procedures and a new
+   BYPASS_ASSIGNMENT subobject in the RSVP RECORD_ROUTE Object (RRO)
+   used to coordinate the bidirectional bypass tunnel assignment between
+   the downstream and upstream PLRs.
+
+4.5.1.  Bidirectional Bypass Tunnel Assignment Signaling Procedure
+
+   It is desirable to coordinate the bidirectional bypass tunnel
+   selected at the downstream and upstream PLRs so that the rerouted
+   traffic flows on co-routed paths after FRR.  To achieve this, a new
+   RSVP subobject is defined for RRO that identifies a bidirectional
+   bypass tunnel that is assigned at a downstream PLR to protect a
+   bidirectional LSP.
+
+   When the procedures defined in this document are in use, the
+   BYPASS_ASSIGNMENT subobject MUST be added by each downstream PLR in
+   the RSVP Path RRO message of the GMPLS signaled bidirectional
+   protected LSP to record the downstream bidirectional bypass tunnel
+   assignment.  This subobject is sent in the RSVP Path RRO message
+   every time the downstream PLR assigns or updates the bypass tunnel
+   assignment.  The downstream PLR can assign a bypass tunnel when
+   processing the first Path message of the protected LSP as long as it
+   has a topological view of the downstream MP and the traversed path
+   information in the Explicit Route Object (ERO).  For the protected
+   LSP where the downstream MP cannot be determined from the first Path
+   message (e.g., when using loose hops in the ERO), the downstream PLR
+   needs to wait for the Resv message with RRO in order to assign a
+   bypass tunnel.  However, in both cases, the downstream PLR cannot
+
+
+
+Taillon, et al.              Standards Track                    [Page 8]
+
+RFC 8271                  FRR for TE GMPLS LSPs             October 2017
+
+
+   update the data plane until it receives Resv messages containing the
+   MP labels.
+
+   The upstream PLR (downstream MP) simply reflects the bypass tunnel
+   assignment in the reverse direction.  The absence of the
+   BYPASS_ASSIGNMENT subobject in Path RRO means that the relevant node
+   or interface is not protected by a bidirectional bypass tunnel.
+
+   Hence, the upstream PLR need not assign a bypass tunnel in the
+   reverse direction.
+
+   When the BYPASS_ASSIGNMENT subobject is added in the Path RRO:
+
+   o  The IPv4 or IPv6 subobject containing the Node-ID address MUST
+      also be added [RFC4561].  The Node-ID address MUST match the
+      source address of the bypass tunnel selected for this protected
+      LSP.
+
+   o  The BYPASS_ASSIGNMENT subobject MUST be added immediately after
+      the Node-ID address.
+
+   o  The Label subobject MUST also be added [RFC3209].
+
+   The rules for adding an IPv4 or IPv6 Interface address subobject and
+   Unnumbered Interface ID subobject as specified in [RFC3209] and
+   [RFC4090] are not modified by the above procedure.  The options
+   specified in Section 6.1.3 in [RFC4990] are also applicable as long
+   as the above-mentioned rules are followed when using the FRR
+   procedures defined in this document.
+
+   An upstream PLR (downstream MP) SHOULD check all BYPASS_ASSIGNMENT
+   subobjects in the Path RRO to see if the destination address in the
+   BYPASS_ASSIGNMENT matches the address of the upstream PLR.  For each
+   BYPASS_ASSIGNMENT subobject that matches, the upstream PLR looks for
+   a tunnel that has a source address matching the downstream PLR that
+   inserted the BYPASS_ASSIGNMENT, as indicated by the Node-ID address
+   and the same Tunnel ID as indicated in the BYPASS_ASSIGNMENT.  The
+   RRO can contain multiple addresses to identify a node.  However, the
+   upstream PLR relies on the Node-ID address preceding the
+   BYPASS_ASSIGNMENT subobject for identifying the bypass tunnel.  If
+   the bypass tunnel is not found, the upstream PLR SHOULD send a Notify
+   message [RFC3473] with Error Code "FRR Bypass Assignment Error"
+   (value 44) and Sub-code "Bypass Tunnel Not Found" (value 1) to the
+   downstream PLR.  Upon receiving this error, the downstream PLR SHOULD
+   remove the bypass tunnel assignment and select an alternate bypass
+   tunnel if one available.  The RRO containing BYPASS_ASSIGNMENT
+   subobject(s) is then simply forwarded downstream in the RSVP Path
+   message.
+
+
+
+Taillon, et al.              Standards Track                    [Page 9]
+
+RFC 8271                  FRR for TE GMPLS LSPs             October 2017
+
+
+   A downstream PLR may add, remove, or change the bypass tunnel
+   assignment for a protected LSP resulting in the addition, removal, or
+   modification of the BYPASS_ASSIGNMENT subobject in the Path RRO,
+   respectively.  In this case, the downstream PLR SHOULD generate a
+   modified Path message and forward it downstream.  The downstream MP
+   SHOULD check the RRO in the received Path message and update the
+   bypass tunnel assignment in the reverse direction accordingly.
+
+4.5.2.  One-to-One Bidirectional Bypass Tunnel Assignment
+
+   The bidirectional bypass tunnel assignment coordination procedure
+   defined in this document can be used for both the facility backup
+   described in Section 3.2 of [RFC4090] and the one-to-one backup
+   described in Section 3.1 of [RFC4090].  As specified in Section 4.2
+   of [RFC4090], the DETOUR object can be used in the one-to-one backup
+   method to identify the detour LSPs.  In the one-to-one backup method,
+   if the bypass tunnel is already in use at the upstream PLR, it SHOULD
+   send a Notify message [RFC3473] with Error Code "FRR Bypass
+   Assignment Error" (value 44) and Sub-code "One-to-One Bypass Already
+   in Use" (value 2) to the downstream PLR.  Upon receiving this error,
+   the downstream PLR SHOULD remove the bypass tunnel assignment and
+   select an alternate bypass tunnel if one is available.
+
+4.5.3.  Multiple Bidirectional Bypass Tunnel Assignments
+
+   The upstream PLR may receive multiple bypass tunnel assignments for a
+   protected LSP from different downstream PLRs, leading to an
+   asymmetric bypass tunnel assignment as shown in the following two
+   examples.
+
+   As shown in Examples 1 and 2, for the protected bidirectional GMPLS
+   LSP R4-R5-R6, the upstream PLR R6 receives multiple bypass tunnel
+   assignments, one from downstream PLR R4 for node protection and one
+   from downstream PLR R5 for link protection.  In Example 1, R6 prefers
+   the link protection bypass tunnel from downstream PLR R5, whereas, in
+   Example 2, R6 prefers the node protection bypass tunnel from
+   downstream PLR R4.
+
+                       +------->>-------+
+                      /           +->>--+ \
+                     /           /       \ \
+                    /           /         \ \
+                  [R4]--->>---[R5]--->>---[R6]
+                   PATH ->      \         /
+                                 \       /
+                                  +-<<--+
+
+         Example 1: Link Protection Is Preferred on Downstream MP
+
+
+
+Taillon, et al.              Standards Track                   [Page 10]
+
+RFC 8271                  FRR for TE GMPLS LSPs             October 2017
+
+
+                       +------->>--------+
+                      /           +->>--+ \
+                     /           /       \ \
+                    /           /         \ \
+                  [R4]--->>---[R5]--->>---[R6]
+
+                    \ PATH ->               /
+                     \                     /
+                      \                   /
+                       +-------<<--------+
+
+         Example 2: Node Protection Is Preferred on Downstream MP
+
+   The asymmetry of bypass tunnel assignments can be avoided by using
+   the flags in the SESSION_ATTRIBUTE object defined in Section 4.3 of
+   [RFC4090].  In particular, the "node protection desired" flag is
+   signaled by the head-end node to request node protection bypass
+   tunnels.  When this flag is set, both downstream PLR and upstream PLR
+   nodes assign node protection bypass tunnels as shown in Example 2.
+   When the "node protection desired" flag is not set, the downstream
+   PLR nodes may only signal the link protection bypass tunnels avoiding
+   the asymmetry of bypass tunnel assignments shown in Example 1.
+
+   When multiple bypass tunnel assignments are received, the upstream
+   PLR SHOULD send a Notify message [RFC3473] with Error Code "FRR
+   Bypass Assignment Error" (value 44) and Sub-code "Bypass Assignment
+   Cannot Be Used" (value 0) to the downstream PLR to indicate that it
+   cannot use the bypass tunnel assignment in the reverse direction.
+   Upon receiving this error, the downstream PLR MAY remove the bypass
+   tunnel assignment and select an alternate bypass tunnel if one is
+   available.
+
+   If multiple bypass tunnel assignments are present on the upstream PLR
+   R6 at the time of a failure, any resulted asymmetry gets corrected
+   using the procedure for restoring co-routing after FRR as specified
+   in Section 5.2.2.
+
+5.  Fast Reroute for Bidirectional GMPLS LSPs with In-Band Signaling
+
+   When a bidirectional bypass tunnel is used after a link failure, the
+   following procedure is followed when using the in-band signaling:
+
+   o  The downstream PLR reroutes protected LSP traffic and RSVP Path
+      signaling over the bidirectional bypass tunnel using the
+      procedures defined in [RFC4090].  The RSVP Path messages are
+      modified as described in Section 6.4.3 of [RFC4090].
+
+
+
+
+
+Taillon, et al.              Standards Track                   [Page 11]
+
+RFC 8271                  FRR for TE GMPLS LSPs             October 2017
+
+
+   o  The upstream PLR reroutes protected LSP traffic upon detecting the
+      link failure or upon receiving an RSVP Path message over the
+      bidirectional bypass tunnel.
+
+   o  The upstream PLR also reroutes protected LSP RSVP Resv signaling
+      after receiving the modified RSVP Path message over the
+      bidirectional bypass tunnel.  The upstream PLR uses the procedure
+      defined in Section 7 of [RFC4090] to detect that RSVP Path
+      messages have been rerouted over the bypass tunnel by the
+      downstream PLR.  The upstream PLR does not modify the RSVP Resv
+      message before sending it over the bypass tunnel.
+
+   The above procedure allows both traffic and RSVP signaling to flow on
+   symmetric paths in the forward and reverse directions of a protected
+   bidirectional GMPLS LSP.  The following sections describe the
+   handling for link protection and node protection bypass tunnels.
+
+5.1.  Link Protection for Bidirectional GMPLS LSPs
+
+                                                       <- RESV
+            [R1]----[R2]----[R3]-----x-----[R4]----[R5]----[R6]
+             PATH ->          \             /
+                               \           /
+                                +<<----->>+
+                                     T3
+                                  PATH ->
+                                  <- RESV
+
+                 Protected LSP:  {R1-R2-R3-R4-R5-R6}
+                 R3's Bypass T3: {R3-R4}
+
+        Figure 1: Flow of RSVP Signaling after Link Failure and FRR
+
+   Consider the TE network shown in Figure 1.  Assume that every link in
+   the network is protected with a link protection bypass tunnel (e.g.,
+   bypass tunnel T3).  For the protected co-routed bidirectional LSP
+   whose head-end is on node R1 and tail-end is on node R6, each
+   traversed node (a potential PLR) assigns a link protection co-routed
+   bidirectional bypass tunnel.
+
+
+
+
+
+
+
+
+
+
+
+
+Taillon, et al.              Standards Track                   [Page 12]
+
+RFC 8271                  FRR for TE GMPLS LSPs             October 2017
+
+
+5.1.1.  Behavior after Link Failure
+
+   Consider the link R3-R4 on the protected LSP path failing.  The
+   downstream PLR R3 and upstream PLR R4 independently trigger fast
+   reroute to redirect traffic onto bypass tunnel T3 in the forward and
+   reverse directions.  The downstream PLR R3 also reroutes RSVP Path
+   messages onto the bypass tunnel T3 using the procedures described in
+   [RFC4090].  The upstream PLR R4 reroutes RSVP Resv messages onto the
+   reverse bypass tunnel T3 upon receiving an RSVP Path message over
+   bypass tunnel T3.
+
+5.1.2.  Revertive Behavior after Fast Reroute
+
+   The revertive behavior defined in [RFC4090], Section 6.5.2, is
+   applicable to the link protection of bidirectional GMPLS LSPs.  When
+   using the local revertive mode, after the link R3-R4 (in Figure 1) is
+   restored, following node behaviors apply:
+
+   o  The downstream PLR R3 starts sending the Path messages and traffic
+      flow of the protected LSP over the restored link and stops sending
+      them over the bypass tunnel.
+
+   o  The upstream PLR R4 starts sending the traffic flow of the
+      protected LSP over the restored link and stops sending it over the
+      bypass tunnel.
+
+   o  When upstream PLR R4 receives the protected LSP Path messages over
+      the restored link, if not already done, it starts sending Resv
+      messages and traffic flow of the protected LSP over the restored
+      link and stops sending them over the bypass tunnel.
+
+5.2.  Node Protection for Bidirectional GMPLS LSPs
+
+                              T1
+                        +<<------->>+
+                       /             \
+                      /               \          <- RESV
+            [R1]----[R2]----[R3]--x--[R4]----[R5]----[R6]
+             PATH ->          \               /
+                               \             /
+                                +<<------->>+
+                                      T2
+
+                 Protected LSP:  {R1-R2-R3-R4-R5-R6}
+                 R3's Bypass T2: {R3-R5}
+                 R4's Bypass T1: {R4-R2}
+
+        Figure 2: Flow of RSVP Signaling after Link Failure and FRR
+
+
+
+Taillon, et al.              Standards Track                   [Page 13]
+
+RFC 8271                  FRR for TE GMPLS LSPs             October 2017
+
+
+   Consider the TE network shown in Figure 2.  Assume that every link in
+   the network is protected with a node protection bypass tunnel.  For
+   the protected co-routed bidirectional LSP whose head-end is on node
+   R1 and tail-end is on node R6, each traversed node (a potential PLR)
+   assigns a node protection co-routed bidirectional bypass tunnel.
+
+   The solution introduces two phases for invoking FRR procedures by the
+   PLR after the link failure.  The first phase comprises of FRR
+   procedures to fast reroute data traffic onto bypass tunnels in the
+   forward and reverse directions.  The second phase restores the
+   co-routing of signaling and data traffic in the forward and reverse
+   directions after the first phase.
+
+5.2.1.  Behavior after Link Failure
+
+   Consider a link R3-R4 (in Figure 2) on the protected LSP path
+   failing.  The downstream PLR R3 and upstream PLR R4 independently
+   trigger fast reroute procedures to redirect the protected LSP traffic
+   onto respective bypass tunnels T2 and T1 in the forward and reverse
+   directions.  The downstream PLR R3 also reroutes RSVP Path messages
+   over the bypass tunnel T2 using the procedures described in
+   [RFC4090].  Note, at this point, that node R4 stops receiving RSVP
+   Path refreshes for the protected bidirectional LSP while protected
+   traffic continues to flow over bypass tunnels.  As node R4 does not
+   receive Path messages over bypass tunnel T1, it does not reroute RSVP
+   Resv messages over the reverse bypass tunnel T1.
+
+5.2.2.  Behavior after Link Failure to Restore Co-routing
+
+   The downstream MP R5 that receives the rerouted protected LSP RSVP
+   Path message through the bypass tunnel, in addition to the regular MP
+   processing defined in [RFC4090], gets promoted to a Point of Remote
+   Repair (PRR) role and performs the following actions to restore
+   co-routing signaling and data traffic over the same path in the
+   reverse direction:
+
+   o  Finds the bypass tunnel in the reverse direction that terminates
+      on the downstream PLR R3.  Note: the downstream PLR R3's address
+      can be extracted from the "IPV4 tunnel sender address" in the
+      SENDER_TEMPLATE Object of the protected LSP (see [RFC4090],
+      Section 6.1.1).
+
+   o  If the reverse bypass tunnel is found and the protected LSP
+      traffic is not already rerouted over the found bypass tunnel T2,
+      the PRR R5 activates FRR reroute procedures to direct traffic over
+      the found bypass tunnel T2 in the reverse direction.  In addition,
+      the PRR R5 also reroutes RSVP Resv over the bypass tunnel T2 in
+      the reverse direction.  This can happen when the downstream PLR
+
+
+
+Taillon, et al.              Standards Track                   [Page 14]
+
+RFC 8271                  FRR for TE GMPLS LSPs             October 2017
+
+
+      has changed the bypass tunnel assignment but the upstream PLR has
+      not yet processed the updated Path RRO and programmed the data
+      plane when link failure occurs.
+
+   o  If the reverse bypass tunnel is not found, the PRR R5 immediately
+      tears down the protected LSP.
+
+                                                 <- RESV
+            [R1]----[R2]----[R3]--X--[R4]----[R5]----[R6]
+             PATH ->          \               /
+                               \             /
+                                +<<------->>+
+
+     Bypass Tunnel T2
+
+        traffic + signaling
+
+                  Protected LSP:  {R1-R2-R3-R4-R5-R6}
+                  R3's Bypass T2: {R3-R5}
+
+    Figure 3: Flow of RSVP Signaling after FRR and Restoring Co-routing
+
+   Figure 3 describes the path taken by the traffic and signaling after
+   restoring co-routing of data and signaling in the forward and reverse
+   paths described above.  Node R4 will stop receiving the Path and Resv
+   messages and it will timeout the RSVP soft state.  However, this will
+   not cause the LSP to be torn down.  RSVP signaling at node R2 is not
+   affected by the FRR and restoring co-routing.
+
+   If downstream MP R5 receives multiple RSVP Path messages through
+   multiple bypass tunnels (e.g., as a result of multiple failures), the
+   PRR SHOULD identify a bypass tunnel that terminates on the farthest
+   downstream PLR along the protected LSP path (closest to the protected
+   bidirectional LSP head-end) and activate the reroute procedures
+   mentioned above.
+
+5.2.2.1.  Restoring Co-routing in Data Plane after Link Failure
+
+   The downstream MP (upstream PLR) MAY optionally support restoring
+   co-routing in the data plane as follows.  If the downstream MP has
+   assigned a bidirectional bypass tunnel, as soon as the downstream MP
+   receives the protected LSP packets on the bypass tunnel, it MAY
+   switch the upstream traffic on to the bypass tunnel.  In order to
+   identify the protected LSP packets through the bypass tunnel,
+   Penultimate Hop Popping (PHP) of the bypass tunnel MUST be disabled.
+   The downstream MP checks whether the protected LSP signaling is
+   rerouted over the found bypass tunnel, and if not, it performs the
+   signaling procedure described in Section 5.2.2.
+
+
+
+Taillon, et al.              Standards Track                   [Page 15]
+
+RFC 8271                  FRR for TE GMPLS LSPs             October 2017
+
+
+5.2.3.  Revertive Behavior after Fast Reroute
+
+   The revertive behavior defined in [RFC4090], Section 6.5.2, is
+   applicable to the node protection of bidirectional GMPLS LSPs.  When
+   using the local revertive mode, after the link R3-R4 (in Figures 2
+   and 3) is restored, the following node behaviors apply:
+
+   o  The downstream PLR R3 starts sending the Path messages and traffic
+      flow of the protected LSP over the restored link and stops sending
+      them over the bypass tunnel.
+
+   o  The upstream PLR R4 (when the protected LSP is present) starts
+      sending the traffic flow of the protected LSP over the restored
+      link towards downstream PLR R3 and forwarding the Path messages
+      towards PRR R5 and stops sending the traffic over the bypass
+      tunnel.
+
+   o  When upstream PLR R4 receives the protected LSP Path messages over
+      the restored link, if not already done, the node R4 (when the
+      protected LSP is present) starts sending Resv messages and traffic
+      flow over the restored link towards downstream PLR R3 and
+      forwarding the Path messages towards PRR R5 and stops sending them
+      over the bypass tunnel.
+
+   o  When PRR R5 receives the protected LSP Path messages over the
+      restored path, it starts sending Resv messages and traffic flow
+      over the restored path and stops sending them over the bypass
+      tunnel.
+
+5.2.4.  Behavior after Node Failure
+
+   Consider the node R4 (in Figure 3) on the protected LSP path failing.
+   The downstream PLR R3 and upstream PLR R5 independently trigger fast
+   reroute procedures to redirect the protected LSP traffic onto bypass
+   tunnel T2 in forward and reverse directions.  The downstream PLR R3
+   also reroutes RSVP Path messages over the bypass tunnel T2 using the
+   procedures described in [RFC4090].  The upstream PLR R5 reroutes RSVP
+   Resv signaling after receiving the modified RSVP Path message over
+   the bypass tunnel T2.
+
+5.3.  Unidirectional Link Failures
+
+   Unidirectional link failures can result in the traffic flowing on
+   asymmetric paths in the forward and reverse directions.  In addition,
+   unidirectional link failures can cause RSVP soft-state timeout in the
+   control plane in some cases.  As an example, if the unidirectional
+   link failure is in the upstream direction (from R4 to R3 in Figures 1
+   and 2), the downstream PLR (node R3) can stop receiving the Resv
+
+
+
+Taillon, et al.              Standards Track                   [Page 16]
+
+RFC 8271                  FRR for TE GMPLS LSPs             October 2017
+
+
+   messages of the protected LSP from the upstream PLR (node R4 in
+   Figures 1 and 2) and this can cause RSVP soft-state timeout to occur
+   on the downstream PLR (node R3).
+
+   A unidirectional link failure in the downstream direction (from R3 to
+   R4 in Figures 1 and 2), does not cause RSVP soft-state timeout when
+   using the FRR procedures defined in this document, since the upstream
+   PLR (node R4 in Figure 1 and node R5 in Figure 2) triggers the
+   procedure to restore co-routing (defined in Section 5.2.2) after
+   receiving RSVP Path messages of the protected LSP over the bypass
+   tunnel from the downstream PLR (node R3 in Figures 1 and 2).
+
+6.  Fast Reroute For Bidirectional GMPLS LSPs with Out-of-Band Signaling
+
+   When using the GMPLS out-of-band signaling [RFC3473], after a link
+   failure event, the RSVP messages are not rerouted over the
+   bidirectional bypass tunnel by the downstream and upstream PLRs but
+   are instead rerouted over the control channels to the downstream and
+   upstream MPs, respectively.
+
+   The RSVP soft-state timeout after FRR as described in Section 5.2 is
+   equally applicable to the GMPLS out-of-band signaling as the RSVP
+   signaling refreshes can stop reaching certain nodes along the
+   protected LSP path after the downstream and upstream PLRs finish
+   rerouting of the signaling messages.  However, unlike with the
+   in-band signaling, unidirectional link failures as described in
+   Section 5.3 do not result in soft-state timeout with GMPLS out-of-
+   band signaling.  Apart from this, the FRR procedure described in
+   Section 5 is equally applicable to the GMPLS out-of-band signaling.
+
+7.  Message and Object Definitions
+
+7.1.  BYPASS_ASSIGNMENT Subobject
+
+   The BYPASS_ASSIGNMENT subobject is used to inform the downstream MP
+   of the bypass tunnel being assigned by the PLR.  This can be used to
+   coordinate the bypass tunnel assignment for the protected LSP by the
+   downstream and upstream PLRs in the forward and reverse directions
+   respectively prior or after the failure occurrence.
+
+   This subobject SHOULD be inserted into the Path RRO by the downstream
+   PLR.  It SHOULD NOT be inserted into an RRO by a node that is not a
+   downstream PLR.  It MUST NOT be changed by downstream LSRs and MUST
+   NOT be added to a Resv RRO.
+
+
+
+
+
+
+
+Taillon, et al.              Standards Track                   [Page 17]
+
+RFC 8271                  FRR for TE GMPLS LSPs             October 2017
+
+
+   The BYPASS_ASSIGNMENT IPv4 subobject in RRO has the following format:
+
+        0                   1                   2                   3
+      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |    Type: 38   |     Length    |      Bypass Tunnel ID         |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |               IPv4 Bypass Destination Address                 |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+              Figure 4: BYPASS ASSIGNMENT IPv4 RRO Subobject
+
+      Type
+
+          Downstream Bypass Assignment.  Value is 38.
+
+      Length
+
+          The Length contains the total length of the subobject in
+          bytes, including the Type and Length fields.  The length is 8
+          bytes.
+
+      Bypass Tunnel ID
+
+          The bypass tunnel identifier (16 bits).
+
+      Bypass Destination Address
+
+          The bypass tunnel IPv4 destination address.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Taillon, et al.              Standards Track                   [Page 18]
+
+RFC 8271                  FRR for TE GMPLS LSPs             October 2017
+
+
+   The BYPASS_ASSIGNMENT IPv6 subobject in RRO has the following format:
+
+        0                   1                   2                   3
+      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |    Type: 39   |     Length    |      Bypass Tunnel ID         |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |                                                               |
+     +                                                               +
+     |               IPv6 Bypass Destination Address                 |
+     +                          (16 bytes)                           +
+     |                                                               |
+     +                                                               +
+     |                                                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+              Figure 5: BYPASS_ASSIGNMENT IPv6 RRO Subobject
+
+      Type
+
+          Downstream Bypass Assignment.  Value is 39.
+
+      Length
+
+          The Length contains the total length of the subobject in
+          bytes, including the Type and Length fields.  The length is 20
+          bytes.
+
+      Bypass Tunnel ID
+
+          The bypass tunnel identifier (16 bits).
+
+      Bypass Destination Address
+
+          The bypass tunnel IPv6 destination address.
+
+7.2.  FRR Bypass Assignment Error Notify Message
+
+   New Error Code "FRR Bypass Assignment Error" (value 44) and its sub-
+   codes are defined for the ERROR_SPEC Object (C-Type 6) [RFC2205] in
+   this document, that is carried by the Notify message (Type 21)
+   defined in [RFC3473] Section 4.3.  This Error message is sent by the
+   upstream PLR to the downstream PLR to notify a bypass assignment
+   error.  In the Notify message, the IP destination address is set to
+   the node address of the downstream PLR that had initiated the bypass
+   assignment.  In the ERROR_SPEC Object, the IP address is set to the
+
+
+
+
+
+Taillon, et al.              Standards Track                   [Page 19]
+
+RFC 8271                  FRR for TE GMPLS LSPs             October 2017
+
+
+   node address of the upstream PLR that detected the bypass assignment
+   error.  This Error MUST NOT be sent in a Path Error message.  This
+   Error does not cause the protected LSP to be torn down.
+
+8.  Compatibility
+
+   New RSVP subobject BYPASS_ASSIGNMENT is defined for the RECORD_ROUTE
+   Object in this document that is carried in the RSVP Path message.
+   Per [RFC3209], nodes not supporting this subobject will ignore the
+   subobject but forward it without modification.  As described in
+   Section 7, this subobject is not carried in the RSVP Resv message and
+   is ignored by sending the Notify message for "FRR Bypass Assignment
+   Error" (with Sub-code "Bypass Assignment Cannot Be Used") defined in
+   this document.  Nodes not supporting the Notify message defined in
+   this document will ignore it but forward it without modification.
+
+9.  Security Considerations
+
+   This document introduces a new BYPASS_ASSIGNMENT subobject for the
+   RECORD_ROUTE Object that is carried in an RSVP signaling message.
+   Thus, in the event of the interception of a signaling message, more
+   information about the LSP's fast reroute protection can be deduced
+   than was previously the case.  This is judged to be a very minor
+   security risk as this information is already available by other
+   means.  If an MP does not find a matching bypass tunnel with given
+   source and destination addresses locally, it ignores the
+   BYPASS_ASSIGNMENT subobject.  Due to this, security risks introduced
+   by inserting a random address in this subobject is minimal.  The
+   Notify message for the "FRR Bypass Assignment Error" defined in this
+   document does not result in tear-down of the protected LSP and does
+   not affect service.
+
+   Security considerations for RSVP-TE and GMPLS signaling extensions
+   are covered in [RFC3209] and [RFC3473].  Further, general
+   considerations for securing RSVP-TE in MPLS-TE and GMPLS networks can
+   be found in [RFC5920].  This document updates the mechanisms defined
+   in [RFC4090], which also discusses related security measures that are
+   also applicable to this document.  As specified in [RFC4090], a PLR
+   and its selected merge point trust RSVP messages received from each
+   other.  The security considerations pertaining to the original RSVP
+   protocol [RFC2205] also remain relevant to the updates in this
+   document.
+
+
+
+
+
+
+
+
+
+Taillon, et al.              Standards Track                   [Page 20]
+
+RFC 8271                  FRR for TE GMPLS LSPs             October 2017
+
+
+10.  IANA Considerations
+
+10.1.  BYPASS_ASSIGNMENT Subobject
+
+   IANA manages the "Resource Reservation Protocol (RSVP) Parameters"
+   registry (see <http://www.iana.org/assignments/rsvp-parameters>).
+   IANA has assigned a value for the new BYPASS_ASSIGNMENT subobject in
+   the "Class Type 21 ROUTE_RECORD - Type 1 Route Record" registry.
+
+   This document introduces a new subobject for the RECORD_ROUTE Object:
+
+   +------+----------------------+------------+------------+-----------+
+   | Type | Description          | Carried in | Carried in | Reference |
+   |      |                      | Path       | Resv       |           |
+   +------+----------------------+------------+------------+-----------+
+   | 38   | BYPASS_ASSIGNMENT    | Yes        | No         | RFC 8271  |
+   |      | IPv4 subobject       |            |            |           |
+   |      |                      |            |            |           |
+   | 39   | BYPASS_ASSIGNMENT    | Yes        | No         | RFC 8271  |
+   |      | IPv6 subobject       |            |            |           |
+   +------+----------------------+------------+------------+-----------+
+
+10.2.  FRR Bypass Assignment Error Notify Message
+
+   IANA maintains the "Resource Reservation Protocol (RSVP) Parameters"
+   registry (see <http://www.iana.org/assignments/rsvp-parameters>).
+   The "Error Codes and Globally-Defined Error Value Sub-Codes"
+   subregistry is included in this registry.
+
+   This registry has been extended for the new Error Code and Sub-codes
+   defined in this document as follows:
+
+   o  Error Code 44: FRR Bypass Assignment Error
+
+   o  Sub-code 0: Bypass Assignment Cannot Be Used
+
+   o  Sub-code 1: Bypass Tunnel Not Found
+
+   o  Sub-code 2: One-to-One Bypass Already in Use
+
+
+
+
+
+
+
+
+
+
+
+
+Taillon, et al.              Standards Track                   [Page 21]
+
+RFC 8271                  FRR for TE GMPLS LSPs             October 2017
+
+
+11.  References
+
+11.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <https://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC2205]  Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
+              Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
+              Functional Specification", RFC 2205, DOI 10.17487/RFC2205,
+              September 1997, <https://www.rfc-editor.org/info/rfc2205>.
+
+   [RFC3209]  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
+              and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
+              Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
+              <https://www.rfc-editor.org/info/rfc3209>.
+
+   [RFC3473]  Berger, L., Ed., "Generalized Multi-Protocol Label
+              Switching (GMPLS) Signaling Resource ReserVation Protocol-
+              Traffic Engineering (RSVP-TE) Extensions", RFC 3473,
+              DOI 10.17487/RFC3473, January 2003,
+              <https://www.rfc-editor.org/info/rfc3473>.
+
+   [RFC4090]  Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast
+              Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
+              DOI 10.17487/RFC4090, May 2005,
+              <https://www.rfc-editor.org/info/rfc4090>.
+
+   [RFC4561]  Vasseur, J., Ed., Ali, Z., and S. Sivabalan, "Definition
+              of a Record Route Object (RRO) Node-Id Sub-Object",
+              RFC 4561, DOI 10.17487/RFC4561, June 2006,
+              <https://www.rfc-editor.org/info/rfc4561>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Taillon, et al.              Standards Track                   [Page 22]
+
+RFC 8271                  FRR for TE GMPLS LSPs             October 2017
+
+
+11.2.  Informative References
+
+   [RFC3471]  Berger, L., Ed., "Generalized Multi-Protocol Label
+              Switching (GMPLS) Signaling Functional Description",
+              RFC 3471, DOI 10.17487/RFC3471, January 2003,
+              <https://www.rfc-editor.org/info/rfc3471>.
+
+   [RFC4990]  Shiomoto, K., Papneja, R., and R. Rabbat, "Use of
+              Addresses in Generalized Multiprotocol Label Switching
+              (GMPLS) Networks", RFC 4990, DOI 10.17487/RFC4990,
+              September 2007, <https://www.rfc-editor.org/info/rfc4990>.
+
+   [RFC5920]  Fang, L., Ed., "Security Framework for MPLS and GMPLS
+              Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010,
+              <https://www.rfc-editor.org/info/rfc5920>.
+
+   [RFC6378]  Weingarten, Y., Ed., Bryant, S., Osborne, E., Sprecher,
+              N., and A. Fulignoli, Ed., "MPLS Transport Profile (MPLS-
+              TP) Linear Protection", RFC 6378, DOI 10.17487/RFC6378,
+              October 2011, <https://www.rfc-editor.org/info/rfc6378>.
+
+   [RFC7551]  Zhang, F., Ed., Jing, R., and R. Gandhi, Ed., "RSVP-TE
+              Extensions for Associated Bidirectional Label Switched
+              Paths (LSPs)", RFC 7551, DOI 10.17487/RFC7551, May 2015,
+              <https://www.rfc-editor.org/info/rfc7551>.
+
+Acknowledgements
+
+   The authors would like to thank George Swallow for many useful
+   comments and suggestions.  The authors would like to thank Lou Berger
+   for the guidance on this work and for providing review comments.  The
+   authors would also like to thank Nobo Akiya, Loa Andersson, Matt
+   Hartley, Himanshu Shah, Gregory Mirsky, Mach Chen, Vishnu Pavan
+   Beeram, and Alia Atlas for reviewing this document and providing
+   valuable comments.  A special thanks to Adrian Farrel for his
+   thorough review of this document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Taillon, et al.              Standards Track                   [Page 23]
+
+RFC 8271                  FRR for TE GMPLS LSPs             October 2017
+
+
+Contributors
+
+   Frederic Jounay
+   Orange
+   Switzerland
+
+   Email: frederic.jounay@salt.ch
+
+
+   Lizhong Jin
+   Shanghai
+   China
+
+   Email: lizho.jin@gmail.com
+
+Authors' Addresses
+
+   Mike Taillon
+   Cisco Systems, Inc.
+
+   Email: mtaillon@cisco.com
+
+
+   Tarek Saad (editor)
+   Cisco Systems, Inc.
+
+   Email: tsaad@cisco.com
+
+
+   Rakesh Gandhi (editor)
+   Cisco Systems, Inc.
+
+   Email: rgandhi@cisco.com
+
+
+   Zafar Ali
+   Cisco Systems, Inc.
+
+   Email: zali@cisco.com
+
+
+   Manav Bhatia
+   Nokia
+   Bangalore, India
+
+   Email: manav.bhatia@nokia.com
+
+
+
+
+
+Taillon, et al.              Standards Track                   [Page 24]
+