<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902"
     docName="draft-ietf-mpls-summary-frr-rsvpte-09" number="8796"
     category="std" updates="4090" obsoletes="" submissionType="IETF"
     consensus="true" xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 2.41.0 -->
  <front>

    <title abbrev="RSVP-TE Summary FRR">RSVP-TE Summary Fast Reroute
    Extensions for Label Switched Path (LSP) Tunnels</title>

  <seriesInfo name="RFC" value="8796"/>
    <author initials="M." surname="Taillon" fullname="Mike Taillon">
      <organization>Cisco Systems, Inc.</organization>
      <address>
        <email>mtaillon@cisco.com</email>
      </address>
    </author>
    <author initials="T." surname="Saad" fullname="Tarek Saad" role="editor">
      <organization>Juniper Networks</organization>
      <address>
        <email>tsaad@juniper.net</email>
      </address>
    </author>
    <author initials="R." surname="Gandhi" fullname="Rakesh Gandhi">
      <organization>Cisco Systems, Inc.</organization>
      <address>
        <email>rgandhi@cisco.com</email>
      </address>
    </author>
    <author initials="A." surname="Deshmukh" fullname="Abhishek Deshmukh">
      <organization>Juniper Networks</organization>
      <address>
        <email>adeshmukh@juniper.net</email>
      </address>
    </author>
    <author initials="M." surname="Jork" fullname="Markus Jork">
      <organization>128 Technology</organization>
      <address>
        <email>mjork@128technology.com</email>
      </address>
    </author>
    <author initials="V." surname="Beeram" fullname="Vishnu Pavan Beeram">
      <organization>Juniper Networks</organization>
      <address>
        <email>vbeeram@juniper.net</email>
      </address>
    </author>

    <date month="July" year="2020"/>

    <abstract>
      <t>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.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="introduction" numbered="true" toc="default">
      <name>Introduction</name>
      <t>The Fast Reroute (FRR) procedures defined in <xref target="RFC4090" format="default"/> 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.</t>
      <t>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)&nbsp;by the amount of FRR RSVP-TE processing
overhead following the link or node failure and (2)&nbsp;due to other control-plane
protocols (e.g., IGP) that undergo convergence on the same node at the
same time.</t>
      <t>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</t>

<ol>
<li>update the procedures defined in <xref target="RFC4090" format="default"/> for facility backup
protection, to enable the MP node to become aware of the PLR node's bypass
tunnel assignment group or groups.</li>
<li>allow FRR procedures between the PLR and
the MP nodes to be signaled and processed on one or more per-bypass tunnel
groups.</li>
</ol>
      <t>As defined in <xref target="RFC2961" format="default"/>, 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.</t>
    </section>
    <section anchor="conventions-used-in-this-document" numbered="true" toc="default">
      <name>Conventions Used in This Document</name>
      <section anchor="terminology" numbered="true" toc="default">
        <name>Terminology</name>
       <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
       "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
       "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
       "<bcp14>SHOULD NOT</bcp14>",
       "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
       "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
       are to be interpreted as described in BCP&nbsp;14
       <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
       when, they appear in all capitals, as shown here.</t>
      </section>
      <section anchor="acronyms-and-abbreviations" numbered="true" toc="default">
        <name>Acronyms and Abbreviations</name>
        <t>It is assumed that the reader is familiar with the terms and abbreviations used in
<xref target="RFC3209" format="default"/> and <xref target="RFC4090" format="default"/>.</t>
        <t>The following abbreviations are also used in this document:</t>

        <dl newline="false" spacing="normal">
          <dt>LSR:</dt><dd>Label Switching Router</dd>
          <dt>LER:</dt><dd>Label Edge Router</dd>
          <dt>MPLS:</dt><dd>Multiprotocol Label Switching</dd>
          <dt>LSP:</dt><dd>Label Switched Path</dd>
          <dt>MP:</dt><dd>Merge Point node as defined in <xref target="RFC4090" format="default"/></dd>
          <dt>PLR:</dt><dd>Point of Local Repair node as defined in <xref target="RFC4090" format="default"/></dd>
          <dt>FRR:</dt><dd>Fast Reroute as defined in <xref target="RFC4090" format="default"/></dd>
          <dt>B-SFRR-Ready:</dt><dd>Bypass Summary FRR Ready Extended ASSOCIATION object. Added
by the PLR node for each LSP protected by the bypass tunnel</dd>
          <dt>B-SFRR-Active:</dt><dd>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</dd>
          <dt>MTU:</dt><dd>Maximum Transmission Unit</dd>
        </dl>
      </section>
    </section>
    <section anchor="extensions-for-summary-frr-signaling" numbered="true"
   toc="default"> 
      <name>Extensions for Summary FRR Signaling</name>
      <t>The RSVP ASSOCIATION object is defined in <xref target="RFC4872" format="default"/> 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 <xref target="RFC6780" format="default"/>
to expand on the possible usage of the ASSOCIATION object and generalize the
definition of the Extended Association ID field.</t>
      <t>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&nbhy;SFRR-Active) associations.
</t>
      <t>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.</t>
      <t>A PLR node <bcp14>SHOULD</bcp14> assign the same Bypass_Group_Identifier to all
protected LSPs provided that the protected LSPs:</t>
      <ul spacing="normal">
        <li>share the same outgoing protected interface,</li>
        <li>are protected by the same bypass tunnel, and</li>
        <li>are assigned the same tunnel sender address that is used for
backup path identification after FRR as described in <xref target="RFC4090" format="default"/>.</li>
      </ul>
      <t>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.</t>
      <t>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.</t>
      <t>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.</t>
      <t>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.</t>
      <t>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.</t>
      <section anchor="sfrr-bypass-ready" numbered="true" toc="default">
        <name>B-SFRR-Ready Extended ASSOCIATION Object</name>
        <t>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.</t>
        <t>The Association Type, Association ID, and Association Source <bcp14>MUST</bcp14> be set as
defined in <xref target="RFC4872" format="default"/> for the ASSOCIATION
        object. More specifically:</t>
    <dl newline="true" spacing="normal">
        <dt>Association Source:</dt>
         <dd>The Association Source is set to an address of the PLR node.</dd>
        <dt>Association Type:</dt>
         <dd>A new Association Type is defined for B-SFRR-Ready as
        follows:</dd>
    </dl>
<table anchor="tab-1">
  <name>The B-SFRR-Ready Association Type</name>
  <thead>
    <tr>
      <th>Value</th>
      <th>Type</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>5</td>
      <td>Bypass Summary FRR Ready Association (B-SFRR-Ready)</td>
    </tr>
  </tbody>
</table>
        <t>The Extended ASSOCIATION object's Global Association Source <bcp14>MUST</bcp14> be set
according to the rules defined in <xref target="RFC6780" format="default"/>.</t>
        <t>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.</t>
        <section anchor="ipv4-b-sfrr-ready-extended-association-id" numbered="true" toc="default">
          <name>IPv4 B-SFRR-Ready Extended Association ID</name>
          <t>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:</t>
          <figure anchor="fig_IPv4_Extended_Association_ID">
            <name>The IPv4 Extended Association ID for B-SFRR-Ready</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
    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                                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork> </figure>

    <dl newline="false" spacing="normal">

    <dt>Bypass_Tunnel_ID:</dt><dd><t>16 bits</t>
     <t>The bypass tunnel identifier.</t></dd>

    <dt>Reserved:</dt><dd><t>16 bits</t>
     <t>Reserved for future use. <bcp14>MUST</bcp14> be set to zero when
     sending and ignored on receipt.</t></dd>

    <dt>Bypass_Source_IPv4_Address:</dt><dd><t>32 bits</t>
     <t>The bypass tunnel source IPv4 address.</t></dd>

    <dt>Bypass_Destination_IPv4_Address:</dt><dd><t>32 bits</t>
      <t>The bypass tunnel destination IPv4 address.</t></dd>

    <dt>Bypass_Group_Identifier:</dt><dd><t>32 bits</t>
    <t>The bypass tunnel group identifier that is assigned to the
       LSP.</t></dd>

    <dt>MESSAGE_ID:</dt><dd>A MESSAGE_ID object as defined by
<xref target="RFC2961"/>.</dd>
</dl>
        </section>
        <section anchor="ipv6-b-sfrr-ready-extended-association-id" numbered="true" toc="default">
          <name>IPv6 B-SFRR-Ready Extended Association ID</name>
          <t>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:</t>
          <figure anchor="fig_IPv6_Extended_Association_ID">
            <name>The IPv6 Extended Association ID for B-SFRR-Ready</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
    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                                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork> </figure>

    <dl newline="false" spacing="normal">
     <dt>Bypass_Tunnel_ID:</dt><dd><t>16 bits</t>
        <t>The bypass tunnel identifier.</t></dd>

     <dt>Reserved:</dt><dd><t>16 bits</t>
        <t>Reserved for future use. <bcp14>MUST</bcp14> be set to zero when sending
        and ignored on receipt.</t></dd>

     <dt>Bypass_Source_IPv6_Address:</dt><dd><t>128 bits</t>
        <t>The bypass tunnel source IPv6 address.</t></dd>

     <dt>Bypass_Destination_IPv6_Address:</dt><dd><t>128 bits</t>
        <t>The bypass tunnel destination IPv6 address.</t></dd>

     <dt>Bypass_Group_Identifier:</dt><dd><t>32 bits</t>
        <t>The bypass tunnel group identifier that is assigned to the
        LSP.</t></dd>

    <dt>MESSAGE_ID:</dt>
     <dd>A MESSAGE_ID object as defined by <xref target="RFC2961"/>.</dd>
</dl>
        </section>
        <section anchor="processing-rules-for-b-sfrr-ready-extended-association-object" numbered="true" toc="default">
          <name>Processing Rules for B-SFRR-Ready Extended ASSOCIATION Object</name>
          <t>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 <bcp14>MUST</bcp14> generate a MESSAGE_ID object
with Epoch and Message_Identifier set according to <xref target="RFC2961" format="default"/>. The MESSAGE_ID
object Flags <bcp14>MUST</bcp14> be cleared when transmitted by the PLR node and ignored
when received at the MP node.</t>
          <t>A PLR node <bcp14>MUST</bcp14> 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).</t>
          <t>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 <xref target="sig-prior-failure" format="default"> </xref>.</t>
          <t>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 <xref target="RFC2961" format="default"/>.
The MESSAGE_ID object Flags <bcp14>MUST</bcp14> be cleared when transmitted by the MP node and ignored
when received at the PLR node. A new Message_Identifier <bcp14>MUST</bcp14> be used to acknowledge an
updated PLR node's assignment.</t>
          <t>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 <bcp14>MUST</bcp14>
consider the protected LSP as not Summary FRR capable.</t>
          <t>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 <xref target="RFC2961" format="default"/>, 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.</t>
        </section>
      </section>
      <section anchor="sfrr-bypass-active" numbered="true" toc="default">
        <name>B-SFRR-Active Extended ASSOCIATION Object</name>
        <t>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&nbhy;capable protected LSPs that are being protected by the
bypass tunnel are being rerouted over the bypass tunnel.</t>
        <t>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).</t>
        <t>The Association Type, Association ID, and Association Source <bcp14>MUST</bcp14> be set as
defined in <xref target="RFC4872" format="default"/> for the ASSOCIATION object. More specifically:</t>

      <dl newline="true" spacing="normal">
        <dt>Association Source:</dt>
         <dd>The Association Source is set to an address of the PLR node.</dd>
        <dt>Association Type:</dt>
         <dd>A new Association Type is defined for B-SFRR-Active as follows:</dd>
      </dl>
<table anchor="tab-2">
  <name>The B-SFRR-Active Association Type</name>
  <thead>
    <tr>
      <th>Value</th>
      <th>Type</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>6</td>
      <td>Bypass Summary FRR Active Association (B-SFRR-Active)</td>
    </tr>
  </tbody>
</table>

        <dl newline="true" spacing="normal">
          <dt>Extended Association ID for B-SFRR-Active:</dt>
           <dd>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.</dd>
        </dl>
        <section anchor="V4_SFRR_ACTIVE" numbered="true" toc="default">
          <name>IPv4 B-SFRR-Active Extended Association ID</name>
          <t>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:</t>
          <figure anchor="fig_IPv4_SFRR_ACTIVE">
            <name>The IPv4 Extended Association ID for B-SFRR-Active</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
    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              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork> </figure>

        <dl newline="false" spacing="normal">
          <dt>Num-BGIDs:</dt><dd><t>16 bits</t>
           <t>Number of Bypass_Group_Identifier fields.</t></dd>
          <dt>Reserved:</dt><dd><t>16 bits</t>
           <t>Reserved for future use.</t></dd>
          <dt>Bypass_Group_Identifier:</dt><dd><t>32 bits each</t>
           <t>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 <bcp14>MAY</bcp14> be included.</t></dd>
          <dt>RSVP_HOP_Object:</dt><dd><t>Class 3, as defined by <xref
          target="RFC2205" format="default"/></t>
    <t>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.</t>
</dd>
          <dt>TIME_VALUES object:</dt><dd><t>Class 5, as defined by <xref target="RFC2205" format="default"/></t>
           <t>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.</t></dd>
        </dl>
        <dl newline="true" spacing="normal">
          <dt>IPv4 tunnel sender address:</dt>
           <dd>The IPv4 address that the PLR node sets to identify one or more
           backup paths as
described in <xref target="RFC4090" sectionFormat="of" section="6.1.1"/>. This address is applicable to all
groups identified by any Bypass_Group_Identifiers carried in the B-SFRR-Active
Extended Association ID.</dd>
        </dl>
        </section>
        <section anchor="V6_SFRR_ACTIVE" numbered="true" toc="default">
          <name>IPv6 B-SFRR-Active Extended Association ID</name>
          <t>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:</t>
          <figure anchor="fig_IPv6_SFRR_ACTIVE">
            <name>The IPv6 Extended Association ID for B-SFRR-Active</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
    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              +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork> </figure>
        <dl newline="false" spacing="normal">
          <dt>Num-BGIDs:</dt><dd><t>16 bits</t>
           <t>Number of Bypass_Group_Identifier fields.</t></dd>
          <dt>Reserved:</dt><dd><t>16 bits</t>
           <t>Reserved for future use.</t></dd>
          <dt>Bypass_Group_Identifier:</dt><dd><t>32 bits each</t>
           <t>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 <bcp14>MAY</bcp14> be included.</t></dd>
          <dt>RSVP_HOP_Object:</dt><dd><t>Class 3, as defined by <xref target="RFC2205" format="default"/></t>
           <t>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.</t></dd>
          <dt>TIME_VALUES object:</dt><dd><t>Class 5, as defined by <xref target="RFC2205" format="default"/></t>
           <t>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.</t></dd>
        </dl>
        <dl newline="true" spacing="normal">
          <dt>IPv6 tunnel sender address:</dt>
           <dd>The IPv6 address that the PLR node sets to identify one or more
           backup paths as
described in <xref target="RFC4090" sectionFormat="of" section="6.1.1"/>. This address is applicable to all
groups identified by any Bypass_Group_Identifiers carried in the B-SFRR-Active
Extended Association ID.</dd>
        </dl>
        </section>
      </section>
      <section anchor="sig-prior-failure" numbered="true" toc="default">
        <name>Signaling Procedures prior to Failure</name>
        <t>Before Summary FRR procedures can be used, a handshake <bcp14>MUST</bcp14> 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.</t>
        <t>The facility backup method introduced in <xref target="RFC4090" format="default"/> 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.</t>
        <t>When using the procedures defined in this document, the PLR node
        <bcp14>MUST</bcp14> 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. <xref target="RFC3209" sectionFormat="of" section="2.6"/> 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.</t>
        <section anchor="plr-signaling-procedure" numbered="true" toc="default">
          <name>PLR Signaling Procedure</name>
          <t>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.
</t>
          <t>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.</t>
          <t>To be a valid acknowledgment, the received B-SFRR-Ready Extended Association ID
contents within the RSVP Resv message of the protected LSP <bcp14>MUST</bcp14> 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).</t>
          <t>Note that when forwarding an RSVP Resv message upstream, the PLR node <bcp14>SHOULD</bcp14> 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.</t>
        </section>
        <section anchor="mp-signaling-procedure" numbered="true" toc="default">
          <name>MP Signaling Procedure</name>
          <t>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.</t>
          <t>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.</t>
          <t>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&nbhy;SFRR-Ready Extended Association IDs,
respectively.</t>
          <t>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 <xref target="RFC2961"
format="default"/> with the Flags cleared.</t>
          <t>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 <xref target="post-failure" format="default"> </xref>.</t>
          <t>When forwarding an RSVP Path message downstream, the MP node <bcp14>SHOULD</bcp14> 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.</t>
        </section>
      </section>
      <section anchor="post-failure" numbered="true" toc="default">
        <name>Signaling Procedures Post-Failure</name>
        <t>Upon detection of a fault (egress link or node failure), the PLR node will first
perform the object modification procedures described by <xref target="RFC4090" sectionFormat="of" section="6.4.3"/> 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 <bcp14>MUST</bcp14> be used.</t>
        <t>The PLR node <bcp14>MUST</bcp14> 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.</t>
        <t>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.</t>
        <section anchor="plr-sfrr" numbered="true" toc="default">
          <name>PLR Signaling Procedure</name>
          <t>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.</t>
          <t>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.</t>
          <t>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 <xref target="RFC6780" format="default"/>.</t>
          <t>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.</t>
        </section>
        <section anchor="mp-signaling-procedure-1" numbered="true" toc="default">
          <name>MP Signaling Procedure</name>
          <t>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.</t>
          <t>For each Summary FRR-capable LSP that is being merged, the MP first modifies the Path
state as follows:</t>
          <ol spacing="normal" type="1">
            <li>The RSVP_HOP object is copied from the RSVP_HOP_Object field in the
B-SFRR-Active Extended Association ID.</li>
            <li>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.</li>
            <li>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.</li>
            <li>The Explicit Route Object (ERO) is modified as per <xref target="RFC4090"
            sectionFormat="of" section="6.4.4"/>. Once the above modifications are completed, the MP node performs 
merge processing as per <xref target="RFC4090" format="default"/>.</li>
            <li>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.</li>
          </ol>
          <t>A failure during merge processing of any individual rerouted LSP <bcp14>MUST</bcp14>
result in an RSVP PathErr message.
</t>
          <t>An individual RSVP Resv message for each successfully merged Summary
FRR LSP is not signaled. The MP node <bcp14>SHOULD</bcp14> immediately use summary
refresh procedures to refresh the protected LSP Resv state.</t>
        </section>
      </section>
      <section anchor="refreshing-summary-frr-active-lsps" numbered="true" toc="default">
        <name>Refreshing Summary FRR Active LSPs</name>
        <t>The refreshing of Summary FRR Active LSPs is performed using summary
refresh as defined by <xref target="RFC2961" format="default"/>.</t>
      </section>
    </section>
    <section anchor="backwards-compatibility" numbered="true" toc="default">
      <name>Backwards Compatibility</name>
      <t>The (Extended) ASSOCIATION object is defined in <xref target="RFC4872" format="default"/> 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
<xref target="RFC2205" sectionFormat="of" section="3.10"/> regarding unknown-class objects.
Such nodes will ignore the object and forward it without any modification.</t>
    </section>
    <section anchor="security-considerations" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>This document updates an existing RSVP object -- the Extended
      ASSOCIATION object as described in <xref target="extensions-for-summary-frr-signaling"/>.
  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.</t>
      <t>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.</t>
      <t>Existing mechanisms for maintaining the integrity and authenticity of RSVP
messages <xref target="RFC2747" format="default"/> can be applied. Other considerations mentioned
in <xref target="RFC4090" format="default"/> and <xref target="RFC5920" format="default"/> also apply.</t>
    </section>
    <section anchor="iana-considerations" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>IANA maintains the "Generalized Multi-Protocol Label Switching
      (GMPLS) Signaling Parameters" registry. The "Association Type" subregistry is included
in this registry.</t>
      <t>This registry has been updated with the new
   Association Types for the Extended ASSOCIATION objects defined in this document
as follows:</t>

<table anchor="tab-3">
  <name>New Extended ASSOCIATION Object Association Types</name>
  <thead>
    <tr>
      <th>Value</th>
      <th>Name</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>5</td>
      <td>B-SFRR-Ready Association</td>
      <td><xref target="sfrr-bypass-ready"/></td>
    </tr>
    <tr>
      <td>6</td>
      <td>B-SFRR-Active Association</td>
      <td><xref target="sfrr-bypass-active"/></td>
    </tr>
  </tbody>
</table>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4090.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2961.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3209.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4872.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6780.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2205.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2747.xml"/>
      </references>
      <references>
        <name>Informative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5920.xml"/>
      </references>
    </references>
    <section anchor="acknowledgments" numbered="false" toc="default">
      <name>Acknowledgments</name>
      <t>The authors would like to thank <contact fullname="Alexander Okonnikov"/>, <contact fullname="Loa Andersson"/>, <contact fullname="Lou Berger"/>,
<contact fullname="Eric Osborne"/>, <contact fullname="Gregory Mirsky"/>,
and <contact fullname="Mach Chen"/> for reviewing and providing valuable
comments on this document.</t>
    </section>
    <section anchor="contributors" numbered="false" toc="default">
      <name>Contributors</name>
  <contact fullname="Nicholas Tan">
  <organization>Arista Networks</organization>
        <address>
          <postal>
            <street></street>
            <city></city>
            <region></region>
            <country></country>
          </postal>
          <email>ntan@arista.com</email>
        </address>
  </contact>
    </section>
  </back>
</rfc>
