doc: Add RFC documents

1 files changed, 952 insertions, 0 deletions

diff --git a/doc/rfc/rfc8796.txt b/doc/rfc/rfc8796.txt
new file mode 100644
index 0000000..0943407
--- /dev/null
+++ b/doc/rfc/rfc8796.txt
@@ -0,0 +1,952 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                        M. Taillon
+Request for Comments: 8796                           Cisco Systems, Inc.
+Updates: 4090                                               T. Saad, Ed.
+Category: Standards Track                               Juniper Networks
+ISSN: 2070-1721                                                R. Gandhi
+                                                     Cisco Systems, Inc.
+                                                             A. Deshmukh
+                                                        Juniper Networks
+                                                                 M. Jork
+                                                          128 Technology
+                                                               V. Beeram
+                                                        Juniper Networks
+                                                               July 2020
+
+
+ RSVP-TE Summary Fast Reroute Extensions for Label Switched Path (LSP)
+                                Tunnels
+
+Abstract
+
+   This document updates RFC 4090 for the Resource Reservation Protocol
+   (RSVP) Traffic Engineering (TE) procedures defined for facility
+   backup protection.  The updates include extensions that reduce the
+   amount of signaling and processing that occurs during Fast Reroute
+   (FRR); as a result, scalability when undergoing FRR convergence after
+   a link or node failure is improved.  These extensions allow the RSVP
+   message exchange between the Point of Local Repair (PLR) and the
+   Merge Point (MP) nodes to be independent of the number of protected
+   Label Switched Paths (LSPs) traversing between them when facility
+   bypass FRR protection is used.  The signaling extensions are fully
+   backwards compatible with nodes that do not support them.
+
+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/rfc8796.
+
+Copyright Notice
+
+   Copyright (c) 2020 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.
+
+Table of Contents
+
+   1.  Introduction
+   2.  Conventions Used in This Document
+     2.1.  Terminology
+     2.2.  Acronyms and Abbreviations
+   3.  Extensions for Summary FRR Signaling
+     3.1.  B-SFRR-Ready Extended ASSOCIATION Object
+       3.1.1.  IPv4 B-SFRR-Ready Extended Association ID
+       3.1.2.  IPv6 B-SFRR-Ready Extended Association ID
+       3.1.3.  Processing Rules for B-SFRR-Ready Extended ASSOCIATION
+               Object
+     3.2.  B-SFRR-Active Extended ASSOCIATION Object
+       3.2.1.  IPv4 B-SFRR-Active Extended Association ID
+       3.2.2.  IPv6 B-SFRR-Active Extended Association ID
+     3.3.  Signaling Procedures prior to Failure
+       3.3.1.  PLR Signaling Procedure
+       3.3.2.  MP Signaling Procedure
+     3.4.  Signaling Procedures Post-Failure
+       3.4.1.  PLR Signaling Procedure
+       3.4.2.  MP Signaling Procedure
+     3.5.  Refreshing Summary FRR Active LSPs
+   4.  Backwards Compatibility
+   5.  Security Considerations
+   6.  IANA Considerations
+   7.  References
+     7.1.  Normative References
+     7.2.  Informative References
+   Acknowledgments
+   Contributors
+   Authors' Addresses
+
+1.  Introduction
+
+   The Fast Reroute (FRR) procedures defined in [RFC4090] describe the
+   mechanisms for the Point of Local Repair (PLR) to reroute traffic and
+   signaling of a protected RSVP-TE Label Switched Path (LSP) onto the
+   bypass tunnel in the event of a TE link or node failure.  Such
+   signaling procedures are performed individually for each affected
+   protected LSP.  This may eventually lead to control-plane scalability
+   and latency issues on the PLR and/or the Merge Point (MP) nodes due
+   to limited memory and CPU processing resources.  This condition is
+   exacerbated when the failure affects a large number of protected LSPs
+   that traverse the same PLR and MP nodes.
+
+   For example, in a large-scale deployment of RSVP-TE LSPs, a single
+   Label Switching Router (LSR) acting as a PLR node may host tens of
+   thousands of protected RSVP-TE LSPs egressing the same protected link
+   and also act as an MP node for a similar number of LSPs that ingress
+   on the same link.  In the event of the failure of the link or
+   neighbor node, the RSVP-TE control plane of the node (when acting as
+   a PLR node) becomes busy rerouting protected LSPs over the bypass
+   tunnel(s) in one direction and (when acting as an MP node) becomes
+   busy merging RSVP states from signaling received over bypass tunnels
+   for one or more LSPs in the reverse direction.  Subsequently, the
+   head-end Label Edge Routers (LERs) that are notified of the local
+   repair at any downstream LSRs will attempt to (re)converge the
+   affected RSVP-TE LSPs onto newly computed paths -- possibly
+   traversing the same previously affected LSR(s).  As a result, the
+   RSVP-TE control plane becomes overwhelmed (1) by the amount of FRR
+   RSVP-TE processing overhead following the link or node failure and
+   (2) due to other control-plane protocols (e.g., IGP) that undergo
+   convergence on the same node at the same time.
+
+   Today, each protected RSVP-TE LSP is signaled individually over the
+   bypass tunnel after FRR.  The changes introduced in this document
+   allow the PLR node to assign multiple protected LSPs to a bypass
+   tunnel group and to communicate this assignment to the MP, such that
+   upon failure, the signaling over the bypass tunnel happens on one or
+   more bypass tunnel groups.  This document defines new extensions that
+
+   1.  update the procedures defined in [RFC4090] for facility backup
+       protection, to enable the MP node to become aware of the PLR
+       node's bypass tunnel assignment group or groups.
+
+   2.  allow FRR procedures between the PLR and the MP nodes to be
+       signaled and processed on one or more per-bypass tunnel groups.
+
+   As defined in [RFC2961], summary refresh procedures use MESSAGE_ID to
+   refresh the RSVP Path and Resv states to help with scaling.  The
+   Summary FRR procedures introduced in this document build on those
+   concepts to allow the MESSAGE_ID(s) to be exchanged on one or more
+   per-bypass tunnel assignment groups and continue to use summary
+   refresh procedures while reducing the amount of messaging that occurs
+   after rerouting signaling over the bypass tunnel post-FRR.
+
+2.  Conventions Used in This Document
+
+2.1.  Terminology
+
+   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.  Acronyms and Abbreviations
+
+   It is assumed that the reader is familiar with the terms and
+   abbreviations used in [RFC3209] and [RFC4090].
+
+   The following abbreviations are also used in this document:
+
+   LSR:  Label Switching Router
+
+   LER:  Label Edge Router
+
+   MPLS:  Multiprotocol Label Switching
+
+   LSP:  Label Switched Path
+
+   MP:  Merge Point node as defined in [RFC4090]
+
+   PLR:  Point of Local Repair node as defined in [RFC4090]
+
+   FRR:  Fast Reroute as defined in [RFC4090]
+
+   B-SFRR-Ready:  Bypass Summary FRR Ready Extended ASSOCIATION object.
+      Added by the PLR node for each LSP protected by the bypass tunnel
+
+   B-SFRR-Active:  Bypass Summary FRR Active Extended ASSOCIATION
+      object.  Used to notify the MP node that one or more groups of
+      protected LSPs have been rerouted over the associated bypass
+      tunnel
+
+   MTU:  Maximum Transmission Unit
+
+3.  Extensions for Summary FRR Signaling
+
+   The RSVP ASSOCIATION object is defined in [RFC4872] as a means to
+   associate LSPs with each other.  For example, in the context of one
+   or more GMPLS-controlled LSPs, the ASSOCIATION object is used to
+   associate a recovery LSP with the LSP(s) it is protecting.  The
+   Extended ASSOCIATION object is introduced in [RFC6780] to expand on
+   the possible usage of the ASSOCIATION object and generalize the
+   definition of the Extended Association ID field.
+
+   This document defines the use of the Extended ASSOCIATION object to
+   carry the Summary FRR information and associate the protected LSP or
+   LSPs with the bypass tunnel that protects them.  Two new Association
+   Types for the Extended ASSOCIATION object, and new Extended
+   Association IDs, are defined in this document to describe the Bypass
+   Summary FRR Ready (B-SFRR-Ready) and Bypass Summary FRR Active
+   (B-SFRR-Active) associations.
+
+   The PLR node creates and manages the Summary FRR LSP groups
+   (identified by Bypass_Group_Identifiers) and shares the group
+   identifiers with the MP via signaling.
+
+   A PLR node SHOULD assign the same Bypass_Group_Identifier to all
+   protected LSPs provided that the protected LSPs:
+
+   *  share the same outgoing protected interface,
+
+   *  are protected by the same bypass tunnel, and
+
+   *  are assigned the same tunnel sender address that is used for
+      backup path identification after FRR as described in [RFC4090].
+
+   This minimizes the number of bypass tunnel Summary FRR groups and
+   optimizes the amount of signaling that occurs between the PLR and the
+   MP nodes after FRR.
+
+   A PLR node that supports Summary FRR procedures adds an Extended
+   ASSOCIATION object with a B-SFRR-Ready Extended Association ID in the
+   RSVP Path message of the protected LSP.  The PLR node adds the
+   protected LSP Bypass_Group_Identifier, information from the assigned
+   bypass tunnel, and a MESSAGE_ID object into the B-SFRR-Ready Extended
+   Association ID.  The MP uses the information contained in the
+   received B-SFRR-Ready Extended Association ID to refresh and merge
+   the protected LSP Path state after FRR occurs.
+
+   An MP node that supports Summary FRR procedures adds the B-SFRR-Ready
+   Extended ASSOCIATION object and respective Extended Association ID in
+   the RSVP Resv message of the protected LSP to acknowledge the PLR's
+   bypass tunnel assignment and provide the MESSAGE_ID object that the
+   MP node will use to refresh the protected LSP Resv state after FRR
+   occurs.
+
+   The MP maintains the PLR node group assignments learned from
+   signaling and acknowledges the group assignments to the PLR node via
+   signaling.  Once the PLR node receives the group assignment
+   acknowledgment from the MP, the FRR signaling can proceed based on
+   Summary FRR procedures as described in this document.
+
+   The B-SFRR-Active Extended ASSOCIATION object with Extended
+   Association ID is sent by the PLR node after activating the Summary
+   FRR procedures.  The B-SFRR-Active Extended ASSOCIATION object with
+   Extended Association ID is sent within the RSVP Path message of the
+   bypass tunnel to inform the MP node that one or more groups of
+   protected LSPs protected by the bypass tunnel are now being rerouted
+   over the bypass tunnel.
+
+3.1.  B-SFRR-Ready Extended ASSOCIATION Object
+
+   The Extended ASSOCIATION object is populated using the rules defined
+   below to associate a protected LSP with the bypass tunnel that is
+   protecting it when Summary FRR procedures are enabled.
+
+   The Association Type, Association ID, and Association Source MUST be
+   set as defined in [RFC4872] for the ASSOCIATION object.  More
+   specifically:
+
+   Association Source:
+      The Association Source is set to an address of the PLR node.
+
+   Association Type:
+      A new Association Type is defined for B-SFRR-Ready as follows:
+
+      +=======+=====================================================+
+      | Value | Type                                                |
+      +=======+=====================================================+
+      | 5     | Bypass Summary FRR Ready Association (B-SFRR-Ready) |
+      +-------+-----------------------------------------------------+
+
+                 Table 1: The B-SFRR-Ready Association Type
+
+   The Extended ASSOCIATION object's Global Association Source MUST be
+   set according to the rules defined in [RFC6780].
+
+   The B-SFRR-Ready Extended Association ID is populated by the PLR node
+   when performing Bypass Summary FRR Ready association for a protected
+   LSP.  The rules governing its population are described in the
+   subsequent sections.
+
+3.1.1.  IPv4 B-SFRR-Ready Extended Association ID
+
+   The IPv4 Extended Association ID for the B-SFRR-Ready Association
+   Type is carried inside the IPv4 Extended ASSOCIATION object and 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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |         Bypass_Tunnel_ID      |           Reserved            |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                Bypass_Source_IPv4_Address                     |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                Bypass_Destination_IPv4_Address                |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                Bypass_Group_Identifier                        |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                MESSAGE_ID                                     |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+        Figure 1: The IPv4 Extended Association ID for B-SFRR-Ready
+
+   Bypass_Tunnel_ID:  16 bits
+
+      The bypass tunnel identifier.
+
+   Reserved:  16 bits
+
+      Reserved for future use.  MUST be set to zero when sending and
+      ignored on receipt.
+
+   Bypass_Source_IPv4_Address:  32 bits
+
+      The bypass tunnel source IPv4 address.
+
+   Bypass_Destination_IPv4_Address:  32 bits
+
+      The bypass tunnel destination IPv4 address.
+
+   Bypass_Group_Identifier:  32 bits
+
+      The bypass tunnel group identifier that is assigned to the LSP.
+
+   MESSAGE_ID:  A MESSAGE_ID object as defined by [RFC2961].
+
+3.1.2.  IPv6 B-SFRR-Ready Extended Association ID
+
+   The IPv6 Extended Association ID for the B-SFRR-Ready Association
+   Type is carried inside the IPv6 Extended ASSOCIATION object and 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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |         Bypass_Tunnel_ID      |           Reserved            |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                                                               |
+      +                                                               +
+      |                                                               |
+      +                Bypass_Source_IPv6_Address                     +
+      |                                                               |
+      +                                                               +
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                                                               |
+      +                                                               +
+      |                                                               |
+      +                Bypass_Destination_IPv6_Address                +
+      |                                                               |
+      +                                                               +
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                Bypass_Group_Identifier                        |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                MESSAGE_ID                                     |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+        Figure 2: The IPv6 Extended Association ID for B-SFRR-Ready
+
+   Bypass_Tunnel_ID:  16 bits
+
+      The bypass tunnel identifier.
+
+   Reserved:  16 bits
+
+      Reserved for future use.  MUST be set to zero when sending and
+      ignored on receipt.
+
+   Bypass_Source_IPv6_Address:  128 bits
+
+      The bypass tunnel source IPv6 address.
+
+   Bypass_Destination_IPv6_Address:  128 bits
+
+      The bypass tunnel destination IPv6 address.
+
+   Bypass_Group_Identifier:  32 bits
+
+      The bypass tunnel group identifier that is assigned to the LSP.
+
+   MESSAGE_ID:  A MESSAGE_ID object as defined by [RFC2961].
+
+3.1.3.  Processing Rules for B-SFRR-Ready Extended ASSOCIATION Object
+
+   A PLR node assigns a bypass tunnel and Bypass_Group_Identifier for
+   each protected LSP.  The same Bypass_Group_Identifier is used for the
+   set of protected LSPs that share the same bypass tunnel, traverse the
+   same egress link, and are not already rerouted.  The PLR node MUST
+   generate a MESSAGE_ID object with Epoch and Message_Identifier set
+   according to [RFC2961].  The MESSAGE_ID object Flags MUST be cleared
+   when transmitted by the PLR node and ignored when received at the MP
+   node.
+
+   A PLR node MUST generate a new Message_Identifier each time the
+   contents of the B-SFRR-Ready Extended Association ID change (e.g.,
+   when the PLR node changes the bypass tunnel assignment).
+
+   A PLR node notifies the MP node of the bypass tunnel assignment via
+   adding a B-SFRR-Ready Extended ASSOCIATION object and Extended
+   Association ID in the RSVP Path message for the protected LSP, using
+   the procedures described in Section 3.3.
+
+   An MP node acknowledges the assignment to the PLR node by signaling
+   the B-SFRR-Ready Extended ASSOCIATION object and Extended Association
+   ID within the RSVP Resv message of the protected LSP.  With the
+   exception of the MESSAGE_ID object, all other fields from the
+   received B-SFRR-Ready Extended Association ID in the RSVP Path
+   message are copied into the B-SFRR-Ready Extended Association ID to
+   be added in the Resv message.  The MESSAGE_ID object is set according
+   to [RFC2961].  The MESSAGE_ID object Flags MUST be cleared when
+   transmitted by the MP node and ignored when received at the PLR node.
+   A new Message_Identifier MUST be used to acknowledge an updated PLR
+   node's assignment.
+
+   A PLR node considers the protected LSP as Summary FRR capable only if
+   all the fields in the B-SFRR-Ready Extended Association ID that are
+   sent in the RSVP Path message match the fields received in the RSVP
+   Resv message (with the exception of the MESSAGE_ID).  If the fields
+   do not match or if the B-SFRR-Ready Extended ASSOCIATION object is
+   absent in a subsequent refresh, the PLR node MUST consider the
+   protected LSP as not Summary FRR capable.
+
+   A race condition may arise for a previously Summary FRR-capable
+   protected LSP when the MP node triggers a refresh that does not
+   contain the B-SFRR-Ready Extended ASSOCIATION object, while at the
+   same time the PLR triggers Summary FRR procedures due to a fault
+   occurring concurrently.  In this case, it is possible that the PLR
+   triggers Summary FRR procedures on the protected LSP before it can
+   receive and process the refresh from the MP node.  As a result, the
+   MP will receive an Srefresh with a Message_Identifier that is not
+   associated with any state.  As per [RFC2961], this results in the MP
+   generating an Srefresh NACK for this Message_Identifier and sending
+   it back to the PLR.  The PLR processes the Srefresh NACK, replays the
+   full Path state associated with the Message_Identifier, and
+   subsequently recovers from this condition.
+
+3.2.  B-SFRR-Active Extended ASSOCIATION Object
+
+   The Extended ASSOCIATION object for the B-SFRR-Active Association
+   Type is populated by a PLR node to indicate to the MP node (the
+   bypass tunnel destination) that one or more groups of Summary
+   FRR-capable protected LSPs that are being protected by the bypass
+   tunnel are being rerouted over the bypass tunnel.
+
+   The B-SFRR-Active Extended ASSOCIATION object is carried in the RSVP
+   Path message of the bypass tunnel and signaled downstream towards the
+   MP (the bypass tunnel destination).
+
+   The Association Type, Association ID, and Association Source MUST be
+   set as defined in [RFC4872] for the ASSOCIATION object.  More
+   specifically:
+
+   Association Source:
+      The Association Source is set to an address of the PLR node.
+
+   Association Type:
+      A new Association Type is defined for B-SFRR-Active as follows:
+
+     +=======+=======================================================+
+     | Value | Type                                                  |
+     +=======+=======================================================+
+     | 6     | Bypass Summary FRR Active Association (B-SFRR-Active) |
+     +-------+-------------------------------------------------------+
+
+                Table 2: The B-SFRR-Active Association Type
+
+   Extended Association ID for B-SFRR-Active:
+      The B-SFRR-Active Extended Association ID is populated by the PLR
+      node for the Bypass Summary FRR Active association.  The rules to
+      populate the Extended Association ID in this case are described
+      below.
+
+3.2.1.  IPv4 B-SFRR-Active Extended Association ID
+
+   The IPv4 Extended Association ID for the B-SFRR-Active Association
+   Type is carried inside the IPv4 Extended ASSOCIATION object and 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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |            Num-BGIDs          |          Reserved             |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                       Bypass_Group_Identifier                 |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                               :                               |
+      //                              :                              //
+      |                               :                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                       Bypass_Group_Identifier                 |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      //                      RSVP_HOP_Object                        //
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      //                      TIME_VALUES                            //
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                       IPv4 tunnel sender address              |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+        Figure 3: The IPv4 Extended Association ID for B-SFRR-Active
+
+   Num-BGIDs:  16 bits
+
+      Number of Bypass_Group_Identifier fields.
+
+   Reserved:  16 bits
+
+      Reserved for future use.
+
+   Bypass_Group_Identifier:  32 bits each
+
+      A Bypass_Group_Identifier that was previously signaled by the PLR
+      using the Extended ASSOCIATION object in the B-SFRR-Ready Extended
+      Association ID.  One or more Bypass_Group_Identifiers MAY be
+      included.
+
+   RSVP_HOP_Object:  Class 3, as defined by [RFC2205]
+
+      Replacement RSVP_HOP object to be applied to all LSPs associated
+      with each of the following Bypass_Group_Identifiers.  This
+      corresponds to C-Type = 1 for IPv4 RSVP_HOP.
+
+   TIME_VALUES object:  Class 5, as defined by [RFC2205]
+
+      Replacement TIME_VALUES object to be applied to all LSPs
+      associated with each of the preceding Bypass_Group_Identifiers
+      after receiving the B-SFRR-Active Extended ASSOCIATION object.
+
+   IPv4 tunnel sender address:
+      The IPv4 address that the PLR node sets to identify one or more
+      backup paths as described in Section 6.1.1 of [RFC4090].  This
+      address is applicable to all groups identified by any
+      Bypass_Group_Identifiers carried in the B-SFRR-Active Extended
+      Association ID.
+
+3.2.2.  IPv6 B-SFRR-Active Extended Association ID
+
+   The IPv6 Extended Association ID for the B-SFRR-Active Association
+   Type is carried inside the IPv6 Extended ASSOCIATION object and 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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |            Num-BGIDs          |          Reserved             |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                       Bypass_Group_Identifier                 |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                               :                               |
+      //                              :                              //
+      |                               :                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                       Bypass_Group_Identifier                 |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      //                      RSVP_HOP_Object                        //
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      //                      TIME_VALUES                            //
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                                                               |
+      +                                                               +
+      |                                                               |
+      +                       IPv6 tunnel sender address              +
+      |                                                               |
+      +                                                               +
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+        Figure 4: The IPv6 Extended Association ID for B-SFRR-Active
+
+   Num-BGIDs:  16 bits
+
+      Number of Bypass_Group_Identifier fields.
+
+   Reserved:  16 bits
+
+      Reserved for future use.
+
+   Bypass_Group_Identifier:  32 bits each
+
+      A Bypass_Group_Identifier that was previously signaled by the PLR
+      using the Extended ASSOCIATION object in the B-SFRR-Ready Extended
+      Association ID.  One or more Bypass_Group_Identifiers MAY be
+      included.
+
+   RSVP_HOP_Object:  Class 3, as defined by [RFC2205]
+
+      Replacement RSVP_HOP object to be applied to all LSPs associated
+      with each of the following Bypass_Group_Identifiers.  This
+      corresponds to C-Type = 2 for IPv6 RSVP_HOP.
+
+   TIME_VALUES object:  Class 5, as defined by [RFC2205]
+
+      Replacement TIME_VALUES object to be applied to all LSPs
+      associated with each of the following Bypass_Group_Identifiers
+      after receiving the B-SFRR-Active Extended ASSOCIATION object.
+
+   IPv6 tunnel sender address:
+      The IPv6 address that the PLR node sets to identify one or more
+      backup paths as described in Section 6.1.1 of [RFC4090].  This
+      address is applicable to all groups identified by any
+      Bypass_Group_Identifiers carried in the B-SFRR-Active Extended
+      Association ID.
+
+3.3.  Signaling Procedures prior to Failure
+
+   Before Summary FRR procedures can be used, a handshake MUST be
+   completed between the PLR and MP nodes.  This handshake is performed
+   using the Extended ASSOCIATION object that carries the B-SFRR-Ready
+   Extended Association ID in both the RSVP Path and Resv messages of
+   the protected LSP.
+
+   The facility backup method introduced in [RFC4090] takes advantage of
+   MPLS label stacking (the PLR node imposes additional MPLS labels
+   post-FRR) to allow rerouting of protected traffic over the backup
+   path.  The backup path may have stricter MTU requirements; due to
+   label stacking at the PLR node, the protected traffic may exceed the
+   backup path MTU.  It is assumed that the operator engineers their
+   network to allow rerouting of protected traffic and the additional
+   label stacking at the PLR node in order to not exceed the backup path
+   MTU.
+
+   When using the procedures defined in this document, the PLR node MUST
+   ensure that the bypass tunnel assignment can satisfy the protected
+   LSP MTU requirements post-FRR.  This prevents any packets from being
+   dropped due to exceeding the MTU size of the backup path after
+   traffic is rerouted onto the bypass tunnel post-failure.  Section 2.6
+   of [RFC3209] describes a mechanism to determine whether a node needs
+   to fragment or drop a packet when it exceeds the path MTU discovered
+   using RSVP signaling on the primary LSP path.  A PLR can leverage the
+   RSVP-discovered path MTU on the backup and primary LSP paths to
+   ensure that the MTU is not exceeded before or after rerouting the
+   protected traffic onto the bypass tunnel.
+
+3.3.1.  PLR Signaling Procedure
+
+   The B-SFRR-Ready Extended ASSOCIATION object is added by each PLR
+   node in the RSVP Path message of the protected LSP to record the
+   bypass tunnel assignment.  This object is updated every time the PLR
+   node updates the bypass tunnel assignment.  This results in
+   triggering an RSVP Path change message.
+
+   Upon receiving an RSVP Resv message with a B-SFRR-Ready Extended
+   ASSOCIATION object, the PLR node checks to see if the expected
+   subobjects from the B-SFRR-Ready Extended Association ID are present.
+   If present, the PLR node determines if the MP has acknowledged the
+   current PLR node's assignment.
+
+   To be a valid acknowledgment, the received B-SFRR-Ready Extended
+   Association ID contents within the RSVP Resv message of the protected
+   LSP MUST match the latest B-SFRR-Ready Extended ASSOCIATION object
+   and Association ID contents that the PLR node had sent within the
+   RSVP Path message (with the exception of the MESSAGE_ID).
+
+   Note that when forwarding an RSVP Resv message upstream, the PLR node
+   SHOULD remove any/all B-SFRR-Ready Extended ASSOCIATION objects whose
+   Bypass_Source_IPv4_Address or Bypass_Source_IPv6_Address field
+   matches any of the PLR node addresses.
+
+3.3.2.  MP Signaling Procedure
+
+   Upon receiving an RSVP Path message with a B-SFRR-Ready Extended
+   ASSOCIATION object, an MP node processes all (there may be multiple
+   PLR nodes for a single MP node) B-SFRR-Ready Extended ASSOCIATION
+   objects that have the MP node address as the bypass destination
+   address in the Extended Association ID.
+
+   The MP node first ensures the existence of the bypass tunnel and that
+   the Bypass_Group_Identifier is not already FRR Active.  That is, an
+   LSP cannot join a group that is already FRR rerouted.
+
+   The MP node builds a mirrored Summary FRR group database per PLR node
+   by associating the Bypass_Source_IPv4_Address or
+   Bypass_Source_IPv6_Address that is carried in the IPv4 or IPv6
+   B-SFRR-Ready Extended Association IDs, respectively.
+
+   The MESSAGE_ID is extracted and recorded for the protected LSP Path
+   state.  The MP node signals a B-SFRR-Ready Extended ASSOCIATION
+   object and Extended Association ID in the RSVP Resv message of the
+   protected LSP.  With the exception of the MESSAGE_ID objects, all
+   other fields of the received B-SFRR-Ready Extended ASSOCIATION object
+   in the RSVP Path message are copied into the B-SFRR-Ready Extended
+   ASSOCIATION object to be added in the Resv message.  The MESSAGE_ID
+   object is set according to [RFC2961] with the Flags cleared.
+
+   Note that an MP may receive more than one RSVP Path message with the
+   B-SFRR-Ready Extended ASSOCIATION object from one or more different
+   upstream PLR nodes.  In this case, the MP node is expected to save
+   all the received MESSAGE_IDs received from the different upstream PLR
+   nodes.  After a failure, the MP node determines and activates the
+   state(s) associated with the Bypass_Group_Identifier(s) received in
+   the RSVP Path message containing the B-SFRR-Active Extended
+   ASSOCIATION object that is signaled over the bypass tunnel from the
+   PLR node, as described in Section 3.4.
+
+   When forwarding an RSVP Path message downstream, the MP node SHOULD
+   remove any/all B-SFRR-Ready Extended ASSOCIATION objects whose
+   Bypass_Destination_IPv4_Address or Bypass_Destination_IPv6_Address
+   field matches any of the MP node addresses.
+
+3.4.  Signaling Procedures Post-Failure
+
+   Upon detection of a fault (egress link or node failure), the PLR node
+   will first perform the object modification procedures described by
+   Section 6.4.3 of [RFC4090] for all affected protected LSPs.  For the
+   Summary FRR-capable LSPs that are assigned to the same bypass tunnel,
+   a common RSVP_HOP and SENDER_TEMPLATE MUST be used.
+
+   The PLR node MUST signal non-Summary FRR-capable LSPs over the bypass
+   tunnel before signaling the Summary FRR-capable LSPs.  This is needed
+   to allow for the case where the PLR node recently changed a bypass
+   assignment and the MP has not processed the change yet.
+
+   The B-SFRR-Active Extended ASSOCIATION object is sent within the RSVP
+   Path message of the bypass tunnel to reroute the RSVP state of
+   Summary FRR-capable LSPs.
+
+3.4.1.  PLR Signaling Procedure
+
+   After a failure event, when using the Summary FRR path signaling
+   procedures, an individual RSVP Path message is not signaled for each
+   Summary FRR LSP.  Instead, to reroute Summary FRR LSPs via the bypass
+   tunnel, the PLR node adds the B-SFRR-Active Extended ASSOCIATION
+   object in the RSVP Path message of the RSVP session of the bypass
+   tunnel.
+
+   The RSVP_HOP_Object field in the B-SFRR-Active Extended Association
+   ID is set to a common object that will be applied to all LSPs
+   associated with the Bypass_Group_Identifiers that are carried in the
+   B-SFRR-Active Extended Association ID.
+
+   The PLR node adds the Bypass_Group_Identifier(s) of any group or
+   groups that have common group attributes, including the tunnel sender
+   address, to the same B-SFRR-Active Extended Association ID.  Note
+   that multiple ASSOCIATION objects, each carrying a B-SFRR-Active
+   Extended Association ID, can be carried within a single RSVP Path
+   message of the bypass tunnel and sent towards the MP as described in
+   [RFC6780].
+
+   Any previously received MESSAGE_IDs from the MP are activated on the
+   PLR.  As a result, the PLR starts sending Srefresh messages
+   containing the specific Message_Identifier(s) for the states to be
+   refreshed.
+
+3.4.2.  MP Signaling Procedure
+
+   Upon receiving an RSVP Path message with a B-SFRR-Active Extended
+   ASSOCIATION object, the MP performs normal merge point processing for
+   each protected LSP associated with each Bypass_Group_Identifier, as
+   if it had received an individual RSVP Path message for that LSP.
+
+   For each Summary FRR-capable LSP that is being merged, the MP first
+   modifies the Path state as follows:
+
+   1.  The RSVP_HOP object is copied from the RSVP_HOP_Object field in
+       the B-SFRR-Active Extended Association ID.
+
+   2.  The TIME_VALUES object is copied from the TIME_VALUES field in
+       the B-SFRR-Active Extended Association ID.  The TIME_VALUES
+       object contains the refresh period of the PLR node, and it is
+       used to generate periodic refreshes.  The TIME_VALUES object
+       carried in the B-SFRR-Active Extended Association ID matches the
+       one that would have been exchanged in a full Path message sent to
+       the MP after the failure when no Summary FRR procedures are used.
+
+   3.  The tunnel sender address field in the SENDER_TEMPLATE object is
+       copied from the tunnel sender address field of the B-SFRR-Active
+       Extended Association ID.
+
+   4.  The Explicit Route Object (ERO) is modified as per Section 6.4.4
+       of [RFC4090].  Once the above modifications are completed, the MP
+       node performs merge processing as per [RFC4090].
+
+   5.  Any previously received MESSAGE_IDs from the PLR node are
+       activated.  The MP is allowed to send Srefresh messages
+       containing the specific Message_Identifier(s) for the states to
+       be refreshed.
+
+   A failure during merge processing of any individual rerouted LSP MUST
+   result in an RSVP PathErr message.
+
+   An individual RSVP Resv message for each successfully merged Summary
+   FRR LSP is not signaled.  The MP node SHOULD immediately use summary
+   refresh procedures to refresh the protected LSP Resv state.
+
+3.5.  Refreshing Summary FRR Active LSPs
+
+   The refreshing of Summary FRR Active LSPs is performed using summary
+   refresh as defined by [RFC2961].
+
+4.  Backwards Compatibility
+
+   The (Extended) ASSOCIATION object is defined in [RFC4872] with a
+   class number in the form 11bbbbbb, where b=0 or 1.  This ensures
+   compatibility with nodes that do not provide support, in accordance
+   with the procedures specified in Section 3.10 of [RFC2205] regarding
+   unknown-class objects.  Such nodes will ignore the object and forward
+   it without any modification.
+
+5.  Security Considerations
+
+   This document updates an existing RSVP object -- the Extended
+   ASSOCIATION object as described in Section 3.  Thus, in the event of
+   the interception of a signaling message, slightly more information
+   could be deduced about the state of the network than was previously
+   the case.
+
+   When using the procedures defined in this document, FRR signaling for
+   rerouting of the states of one or more protected LSPs onto the bypass
+   tunnel can be performed on a group of protected LSPs with a single
+   RSVP message.  This allows an intruder to potentially impact and
+   manipulate a set of protected LSPs that are assigned to the same
+   bypass tunnel group.  Note that such an attack is possible even
+   without the mechanisms defined in this document, albeit at an extra
+   cost resulting from the excessive per-LSP signaling that will occur.
+
+   Existing mechanisms for maintaining the integrity and authenticity of
+   RSVP messages [RFC2747] can be applied.  Other considerations
+   mentioned in [RFC4090] and [RFC5920] also apply.
+
+6.  IANA Considerations
+
+   IANA maintains the "Generalized Multi-Protocol Label Switching
+   (GMPLS) Signaling Parameters" registry.  The "Association Type"
+   subregistry is included in this registry.
+
+   This registry has been updated with the new Association Types for the
+   Extended ASSOCIATION objects defined in this document as follows:
+
+            +=======+===========================+=============+
+            | Value | Name                      | Reference   |
+            +=======+===========================+=============+
+            | 5     | B-SFRR-Ready Association  | Section 3.1 |
+            +-------+---------------------------+-------------+
+            | 6     | B-SFRR-Active Association | Section 3.2 |
+            +-------+---------------------------+-------------+
+
+                  Table 3: New Extended ASSOCIATION Object
+                             Association Types
+
+7.  References
+
+7.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>.
+
+   [RFC2747]  Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic
+              Authentication", RFC 2747, DOI 10.17487/RFC2747, January
+              2000, <https://www.rfc-editor.org/info/rfc2747>.
+
+   [RFC2961]  Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F.,
+              and S. Molendini, "RSVP Refresh Overhead Reduction
+              Extensions", RFC 2961, DOI 10.17487/RFC2961, April 2001,
+              <https://www.rfc-editor.org/info/rfc2961>.
+
+   [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>.
+
+   [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>.
+
+   [RFC4872]  Lang, J.P., Ed., Rekhter, Y., Ed., and D. Papadimitriou,
+              Ed., "RSVP-TE Extensions in Support of End-to-End
+              Generalized Multi-Protocol Label Switching (GMPLS)
+              Recovery", RFC 4872, DOI 10.17487/RFC4872, May 2007,
+              <https://www.rfc-editor.org/info/rfc4872>.
+
+   [RFC6780]  Berger, L., Le Faucheur, F., and A. Narayanan, "RSVP
+              ASSOCIATION Object Extensions", RFC 6780,
+              DOI 10.17487/RFC6780, October 2012,
+              <https://www.rfc-editor.org/info/rfc6780>.
+
+   [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>.
+
+7.2.  Informative References
+
+   [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>.
+
+Acknowledgments
+
+   The authors would like to thank Alexander Okonnikov, Loa Andersson,
+   Lou Berger, Eric Osborne, Gregory Mirsky, and Mach Chen for reviewing
+   and providing valuable comments on this document.
+
+Contributors
+
+   Nicholas Tan
+   Arista Networks
+
+   Email: ntan@arista.com
+
+
+Authors' Addresses
+
+   Mike Taillon
+   Cisco Systems, Inc.
+
+   Email: mtaillon@cisco.com
+
+
+   Tarek Saad (editor)
+   Juniper Networks
+
+   Email: tsaad@juniper.net
+
+
+   Rakesh Gandhi
+   Cisco Systems, Inc.
+
+   Email: rgandhi@cisco.com
+
+
+   Abhishek Deshmukh
+   Juniper Networks
+
+   Email: adeshmukh@juniper.net
+
+
+   Markus Jork
+   128 Technology
+
+   Email: mjork@128technology.com
+
+
+   Vishnu Pavan Beeram
+   Juniper Networks
+
+   Email: vbeeram@juniper.net