doc: Add RFC documents

1 files changed, 955 insertions, 0 deletions

diff --git a/doc/rfc/rfc8149.txt b/doc/rfc/rfc8149.txt
new file mode 100644
index 0000000..20a789b
--- /dev/null
+++ b/doc/rfc/rfc8149.txt
@@ -0,0 +1,955 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                      T. Saad, Ed.
+Request for Comments: 8149                                R. Gandhi, Ed.
+Category: Standards Track                                         Z. Ali
+ISSN: 2070-1721                                      Cisco Systems, Inc.
+                                                              R. Venator
+                                      Defense Information Systems Agency
+                                                               Y. Kamite
+                                          NTT Communications Corporation
+                                                              April 2017
+
+
+          RSVP Extensions for Reoptimization of Loosely Routed
+  Point-to-Multipoint Traffic Engineering Label Switched Paths (LSPs)
+
+Abstract
+
+   The reoptimization of a Point-to-Multipoint (P2MP) Traffic
+   Engineering (TE) Label Switched Path (LSP) may be triggered based on
+   the need to reoptimize an individual source-to-leaf (S2L) sub-LSP or
+   a set of S2L sub-LSPs, both using the Sub-Group-based reoptimization
+   method, or the entire P2MP-TE LSP tree using the Make-Before-Break
+   (MBB) method.  This document discusses the application of the
+   existing mechanisms for path reoptimization of loosely routed Point-
+   to-Point (P2P) TE LSPs to the P2MP-TE LSPs, identifies issues in
+   doing so, and defines procedures to address them.  When reoptimizing
+   a large number of S2L sub-LSPs in a tree using the Sub-Group-based
+   reoptimization method, the S2L sub-LSP descriptor list may need to be
+   semantically fragmented.  This document defines the notion of a
+   fragment identifier to help recipient nodes unambiguously reconstruct
+   the fragmented S2L sub-LSP descriptor list.
+
+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
+   http://www.rfc-editor.org/info/rfc8149.
+
+
+
+
+
+
+
+Saad, et al.                 Standards Track                    [Page 1]
+
+RFC 8149               P2MP-TE Loosely Routed LSPs            April 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
+   (http://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 ....................................................3
+   2. Conventions Used in This Document ...............................4
+      2.1. Key Word Definitions .......................................4
+      2.2. Abbreviations ..............................................4
+      2.3. Terminology ................................................4
+   3. Overview ........................................................5
+      3.1. Loosely Routed Inter-domain P2MP-TE LSP Tree ...............5
+      3.2. Existing Mechanism for Tree-Based P2MP-TE LSP
+           Reoptimization .............................................6
+      3.3. Existing Mechanism for Sub-Group-Based P2MP-TE LSP
+           Reoptimization .............................................7
+   4. Signaling Extensions for Loosely Routed P2MP-TE LSP
+      Reoptimization ..................................................8
+      4.1. Tree-Based Reoptimization ..................................8
+      4.2. Sub-Group-Based Reoptimization Using Fragment Identifier ...9
+   5. Message and Object Definitions .................................11
+      5.1. "P2MP-TE Tree Re-evaluation Request" Flag .................11
+      5.2. "Preferable P2MP-TE Tree Exists" Path Error Sub-code ......11
+      5.3. Fragment Identifier for S2L Sub-LSP Descriptor ............11
+   6. Compatibility ..................................................12
+   7. IANA Considerations ............................................13
+      7.1. "P2MP-TE Tree Re-evaluation Request" Flag .................13
+      7.2. "Preferable P2MP-TE Tree Exists" Path Error Sub-code ......13
+      7.3. Fragment Identifier for S2L Sub-LSP Descriptor ............14
+   8. Security Considerations ........................................14
+   9. References .....................................................15
+      9.1. Normative References ......................................15
+      9.2. Informative References ....................................16
+   Acknowledgments ...................................................16
+   Authors' Addresses ................................................17
+
+
+
+
+Saad, et al.                 Standards Track                    [Page 2]
+
+RFC 8149               P2MP-TE Loosely Routed LSPs            April 2017
+
+
+1.  Introduction
+
+   This document defines Resource Reservation Protocol - Traffic
+   Engineering (RSVP-TE) [RFC2205] [RFC3209] signaling extensions for
+   reoptimizing loosely routed Point-to-Multipoint (P2MP) Traffic
+   Engineering (TE) Label Switched Paths (LSPs) [RFC4875] in a
+   Multiprotocol Label Switching (MPLS) or Generalized MPLS (GMPLS)
+   [RFC3473] network.
+
+   A P2MP-TE LSP is comprised of one or more source-to-leaf (S2L)
+   sub-LSPs.  A loosely routed P2MP-TE S2L sub-LSP is defined as one
+   whose path does not contain the full explicit route identifying each
+   node along the path to the egress node at the time of its signaling
+   by the ingress node.  Such an S2L sub-LSP is signaled with no
+   Explicit Route Object (ERO) [RFC3209], with an ERO that contains at
+   least one "loose next hop", or with an ERO that contains an abstract
+   node that identifies more than one node.  This is often the case with
+   inter-domain P2MP-TE LSPs where a Path Computation Element (PCE) is
+   not used [RFC5440].
+
+   As per [RFC4875], an ingress node may reoptimize the entire P2MP-TE
+   LSP tree by re-signaling all its S2L sub-LSPs using the
+   Make-Before-Break (MBB) method, or it may reoptimize an individual
+   S2L sub-LSP or a set of S2L sub-LSPs, i.e., an individual destination
+   or a set of destinations, both using the Sub-Group-based
+   reoptimization method.
+
+   [RFC4736] defines an RSVP signaling procedure for reoptimizing the
+   path(s) of loosely routed Point-to-Point (P2P) TE LSP(s).  The
+   mechanisms listed in [RFC4736] include a method for the ingress node
+   to trigger a new path re-evaluation request and a method for the
+   midpoint node to send a notification regarding the availability of a
+   preferred path.  This document discusses the application of those
+   mechanisms to the reoptimization of loosely routed P2MP-TE LSPs,
+   identifies issues in doing so, and defines procedures to address
+   them.
+
+   For reoptimizing a group of S2L sub-LSPs in a tree using the
+   Sub-Group-based reoptimization method, an S2L sub-LSP descriptor list
+   can be used to signal one or more S2L sub-LSPs in an RSVP message.
+   This RSVP message may need to be semantically fragmented when a large
+   number of S2L sub-LSPs are added to the descriptor list.  This
+   document defines the notion of a fragment identifier to help
+   recipient nodes unambiguously reconstruct the fragmented S2L sub-LSP
+   descriptor list.
+
+
+
+
+
+
+Saad, et al.                 Standards Track                    [Page 3]
+
+RFC 8149               P2MP-TE Loosely Routed LSPs            April 2017
+
+
+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", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+2.2.  Abbreviations
+
+   ABR: Area Border Router.
+
+   ERO: Explicit Route Object.
+
+   LSP: Label Switched Path.
+
+   LSR: Label Switching Router.
+
+   RRO: Record Route Object.
+
+   S2L sub-LSP: Source-to-leaf sub-LSP.
+
+   TE LSP: Traffic Engineering LSP.
+
+2.3.  Terminology
+
+   This document defines the following terms:
+
+   o  Ingress node: Head-end / source node of the TE LSP.
+
+   o  Egress node: Tail-end / destination node of the TE LSP.
+
+   It is assumed that the reader is also familiar with the terminology
+   in [RFC4736] and [RFC4875].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Saad, et al.                 Standards Track                    [Page 4]
+
+RFC 8149               P2MP-TE Loosely Routed LSPs            April 2017
+
+
+3.  Overview
+
+   [RFC4736] defines RSVP signaling extensions for reoptimizing loosely
+   routed P2P TE LSPs as follows:
+
+   o  A midpoint LSR that expands loose next hop(s) sends a solicited or
+      unsolicited PathErr with Notify error code 25 (as defined in
+      [RFC3209]), with sub-code 6 to indicate "Preferable Path Exists"
+      to the ingress node.
+
+   o  An ingress node triggers a path re-evaluation request at all
+      midpoint LSRs that expand loose next hop(s) by setting the "Path
+      Re-evaluation Request" flag (0x20) in the SESSION_ATTRIBUTES
+      object in the Path message.
+
+   o  The ingress node, upon receiving this PathErr with the Notify
+      error code (either solicited or unsolicited), initiates the
+      reoptimization of the LSP, using the MBB method with a different
+      LSP-ID.
+
+   The following sections discuss the issues that may arise when
+   applying the mechanisms defined in [RFC4736] for reoptimizing loosely
+   routed P2MP-TE LSPs.
+
+3.1.  Loosely Routed Inter-domain P2MP-TE LSP Tree
+
+   An example of a loosely routed inter-domain P2MP-TE LSP tree is shown
+   in Figure 1.  In this example, the P2MP-TE LSP tree consists of three
+   S2L sub-LSPs, to destinations (i.e., leafs) R10, R11, and R12 from
+   the ingress node (i.e., source) R1.  Nodes R2 and R5 are branch
+   nodes, and nodes ABR3, ABR4, ABR7, ABR8, and ABR9 are ABRs.  For the
+   S2L sub-LSP to destination R10, nodes ABR3, ABR7, and R10 are defined
+   as loose next hops.  For the S2L sub-LSP to destination R11, nodes
+   ABR3, ABR8, and R11 are defined as loose next hops.  For the S2L
+   sub-LSP to destination R12, nodes ABR4, ABR9, and R12 are defined as
+   loose next hops.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Saad, et al.                 Standards Track                    [Page 5]
+
+RFC 8149               P2MP-TE Loosely Routed LSPs            April 2017
+
+
+         <--area1--><--area0--><-area2->
+
+                              ABR7---R10
+                             /
+                            /
+                   ABR3---R5
+                  /         \
+                 /           \
+          R1---R2             ABR8---R11
+                 \
+                  \
+                   ABR4---R6
+                            \
+                             \
+                              ABR9---R12
+
+     Figure 1: Example of Loosely Routed Inter-domain P2MP-TE LSP Tree
+
+3.2.  Existing Mechanism for Tree-Based P2MP-TE LSP Reoptimization
+
+   The mechanisms defined in [RFC4736] can be easily applied to trigger
+   the reoptimization of an individual S2L sub-LSP or a group of S2L
+   sub-LSPs.  However, to apply those mechanisms for triggering the
+   reoptimization of a P2MP-TE LSP tree, an ingress node needs to send
+   path re-evaluation requests on all (typically hundreds) of the
+   S2L sub-LSPs, and the midpoint LSR needs to send PathErrs with the
+   Notify error code for all S2L sub-LSPs.  Such mechanisms may lead to
+   the following issues:
+
+   o  A midpoint LSR that expands loose next hop(s) may have to
+      accumulate the received path re-evaluation request(s) for all S2L
+      sub-LSPs (e.g., by using a wait timer) and interpret them as a
+      reoptimization request for the whole P2MP-TE LSP tree.  Otherwise,
+      a midpoint LSR may prematurely send a "Preferable Path Exists"
+      notification for one S2L sub-LSP or a subset of S2L sub-LSPs.
+
+   o  Similarly, the ingress node may have to heuristically determine
+      when to perform P2MP-TE LSP tree reoptimization and when to
+      perform S2L sub-LSP reoptimization.  For example, an
+      implementation may choose to delay reoptimization long enough to
+      allow all PathErrs to be received.  Such timer-based procedures
+      may produce undesired results.
+
+   o  The ingress node that receives (un)solicited PathErr(s) with the
+      Notify error code for one or more individual S2L sub-LSPs may
+      prematurely start reoptimizing the subset of S2L sub-LSPs.
+      However, as mentioned in [RFC4875], Section 14.2, such a
+      Sub-Group-based reoptimization procedure may result in data
+
+
+
+Saad, et al.                 Standards Track                    [Page 6]
+
+RFC 8149               P2MP-TE Loosely Routed LSPs            April 2017
+
+
+      duplication that can be avoided if the entire P2MP-TE LSP tree is
+      reoptimized using the MBB method with a different LSP-ID,
+      especially if the ingress node eventually receives PathErrs with
+      the Notify error code for all S2L sub-LSPs of the P2MP-TE
+      LSP tree.
+
+   In order to address the above-mentioned issues and to align the
+   reoptimization of P2MP-TE LSPs with P2P LSPs [RFC4736], a mechanism
+   is needed to trigger the reoptimization of the LSP tree by
+   re-signaling all S2L sub-LSPs with a different LSP-ID.  To meet this
+   requirement, this document defines RSVP-TE signaling extensions for
+   the ingress node to trigger the re-evaluation of the P2MP LSP tree on
+   every hop that has a next hop defined as a loose or abstract hop for
+   one or more S2L sub-LSP paths, and a midpoint LSR to signal to the
+   ingress node that a preferable LSP tree exists (compared to the
+   current path) or that the whole P2MP-TE LSP must be reoptimized
+   (because of maintenance required on the TE LSP path) (see
+   Section 4.1).
+
+3.3.  Existing Mechanism for Sub-Group-Based P2MP-TE LSP Reoptimization
+
+   Applying the procedures discussed in [RFC4736] in conjunction with
+   the Sub-Group-based reoptimization procedures ([RFC4875],
+   Section 14.2), an ingress node MAY trigger path re-evaluation
+   requests for a set of S2L sub-LSPs in a single Path message using an
+   S2L sub-LSP descriptor list.  Similarly, a midpoint LSR may send a
+   PathErr with Notify error code 25 and sub-code 6 ("Preferable Path
+   Exists") containing a list of S2L sub-LSPs transiting through the LSR
+   using an S2L sub-LSP descriptor list to notify the ingress node.
+   This method can be used for reoptimizing a sub-group of S2L sub-LSPs
+   within an LSP tree using the same LSP-ID.  This method can alleviate
+   the scaling issue associated with sending RSVP messages for
+   individual S2L sub-LSPs.  However, this procedure can lead to the
+   following issues when used to reoptimize the LSP tree:
+
+   o  A Path message that is intended to carry the path re-evaluation
+      request as defined in [RFC4736] with a full list of S2L sub-LSPs
+      in an S2L sub-LSP descriptor list will be decomposed at branching
+      LSRs, and only a subset of the S2L sub-LSPs that are routed over
+      the same next hop will be added in the descriptor list of the Path
+      message propagated to downstream midpoint LSRs.  Consequently,
+      when a preferable path exists at such midpoint LSRs, the PathErr
+      with the Notify error code can only include the subset of S2L
+      sub-LSPs traversing the LSR.  In this case, at the ingress node
+      there is no way to distinguish which mode of reoptimization to
+      invoke, i.e., Sub-Group-based reoptimization using the same LSP-ID
+      or tree-based reoptimization using a different LSP-ID.
+
+
+
+
+Saad, et al.                 Standards Track                    [Page 7]
+
+RFC 8149               P2MP-TE Loosely Routed LSPs            April 2017
+
+
+   o  An LSR may semantically fragment a large RSVP message (when a
+      combined message may not be large enough to fit all S2L sub-LSPs).
+      In this case, the ingress node may receive multiple PathErrs with
+      subsets of S2L sub-LSPs in each (due to either the combined Path
+      message getting fragmented or the combined PathErr message getting
+      fragmented) and would require additional logic to determine how to
+      reoptimize the LSP tree (for example, waiting for some time to
+      aggregate all possible PathErr messages before taking an action).
+      When fragmented, RSVP messages may arrive out of order, and the
+      receiver has no way of knowing the beginning and end of the S2L
+      sub-LSP list.
+
+   In order to address the above-mentioned issues caused by semantic
+   fragmentation of an RSVP message, this document defines a new
+   fragment identifier object for the S2L sub-LSP descriptor list when
+   combining a large number of S2L sub-LSPs in an RSVP message (see
+   Section 4.2).
+
+4.  Signaling Extensions for Loosely Routed P2MP-TE LSP Reoptimization
+
+4.1.  Tree-Based Reoptimization
+
+   To evaluate a P2MP-TE LSP tree on midpoint LSRs that expand loose
+   next hop(s), an ingress node MAY send a Path message with the
+   "P2MP-TE Tree Re-evaluation Request" flag set (bit number 14 in the
+   Attribute Flags TLV) as defined in this document.  The ingress node
+   selects one of the S2L sub-LSPs of the P2MP-TE LSP tree transiting a
+   midpoint LSR to trigger the re-evaluation request.  The ingress node
+   MAY send a re-evaluation request to each border LSR on the path of
+   the LSP tree.
+
+   A midpoint LSR that expands loose next hop(s) for one or more S2L
+   sub-LSP paths does the following upon receiving a Path message with
+   the "P2MP-TE Tree Re-evaluation Request" flag set:
+
+   o  The midpoint LSR MUST check for a preferable P2MP-TE LSP tree by
+      re-evaluating all S2L sub-LSPs that are expanded paths of the
+      loose next hops of the P2MP-TE LSP.
+
+   o  If a preferable P2MP-TE LSP tree is found, the midpoint LSR MUST
+      send to the ingress node an RSVP PathErr with Notify error code 25
+      [RFC3209] and sub-code 13 ("Preferable P2MP-TE Tree Exists)" as
+      defined in this document.  The midpoint LSR, in turn, SHOULD NOT
+      propagate the "P2MP-TE Tree Re-evaluation Request" flag in the
+      subsequent RSVP Path messages sent downstream for the re-evaluated
+      P2MP-TE LSP.
+
+
+
+
+
+Saad, et al.                 Standards Track                    [Page 8]
+
+RFC 8149               P2MP-TE Loosely Routed LSPs            April 2017
+
+
+   o  If no preferable tree for P2MP-TE LSPs can be found, the midpoint
+      LSR that expands loose next hop(s) for one or more S2L sub-LSP
+      paths MUST propagate the request downstream by setting the
+      "P2MP-TE Tree Re-evaluation Request" flag in the LSP_ATTRIBUTES
+      object of the RSVP Path message.
+
+   A midpoint LSR MAY send an unsolicited PathErr with the Notify error
+   code and the "Preferable P2MP-TE Tree Exists" sub-code to the ingress
+   node to notify the ingress node of a preferred P2MP-TE LSP tree when
+   it determines that it exists.  In this case, the midpoint LSR that
+   expands loose next hop(s) for one or more S2L sub-LSP paths selects
+   one of the S2L sub-LSPs of the P2MP-TE LSP tree to send this PathErr
+   message to the ingress node.  The midpoint LSR SHOULD consider how
+   frequently it chooses to send such a PathErr, considering that both
+   (1) a PathErr may be lost during its transit to the ingress node and
+   (2) the ingress node may choose not to reoptimize the LSP when such a
+   PathErr is received.
+
+   The sending of an RSVP PathErr with the Notify error code and the
+   "Preferable P2MP-TE Tree Exists" sub-code to the ingress node
+   notifies the ingress node of the existence of a preferable P2MP-TE
+   LSP tree, and upon receiving this PathErr, the ingress node SHOULD
+   trigger the reoptimization of the LSP, using the MBB method with a
+   different LSP-ID.
+
+4.2.  Sub-Group-Based Reoptimization Using Fragment Identifier
+
+   It might be preferable, as per [RFC4875], to reoptimize the entire
+   P2MP-TE LSP by re-signaling all of its S2L sub-LSPs (Section 14.1
+   ("Make-before-Break") in [RFC4875]) or to reoptimize an individual
+   S2L sub-LSP or a group of S2L sub-LSPs, i.e., an individual
+   destination or a group of destinations (Section 14.2
+   ("Sub-Group-Based Re-Optimization") in [RFC4875]), both using the
+   same LSP-ID.  For loosely routed S2L sub-LSPs, this can be achieved
+   by using the procedures defined in [RFC4736] to reoptimize one or
+   more S2L sub-LSPs of the P2MP-TE LSP.
+
+   An ingress node may trigger path re-evaluation requests using the
+   procedures defined in [RFC4736] for a set of S2L sub-LSPs by
+   combining multiple Path messages using an S2L sub-LSP descriptor list
+   [RFC4875].  An S2L sub-LSP descriptor list is created using a series
+   of S2L_SUB_LSP objects as defined in [RFC4875].  Similarly, a
+   midpoint LSR may send a PathErr with Notify error code 25 and
+   sub-code 6 ("Preferable Path Exists") containing a list of S2L
+   sub-LSPs transiting through the LSR using an S2L sub-LSP descriptor
+   list to notify the ingress node of preferable paths available.
+
+
+
+
+
+Saad, et al.                 Standards Track                    [Page 9]
+
+RFC 8149               P2MP-TE Loosely Routed LSPs            April 2017
+
+
+   The S2L_SUB_LSP_FRAG object defined in this document is optional,
+   with the following exceptions:
+
+   o  As per [RFC4875], Section 5.2.3 ("Transit Fragmentation of Path
+      State Information"), when a Path message is not large enough to
+      fit all S2L sub-LSPs in the descriptor list, an LSR may
+      semantically fragment the message.  In this case, the LSR MUST add
+      the S2L_SUB_LSP_FRAG object defined in this document for each
+      fragment in the S2L sub-LSP descriptor to be able to rebuild the
+      list from the received fragments that may arrive out of order.
+
+   o  In any other situation where an RSVP message needs to be
+      fragmented, an LSR MUST add the S2L_SUB_LSP_FRAG object for each
+      fragment in the S2L sub-LSP descriptor.
+
+   A midpoint LSR SHOULD wait to accumulate all S2L sub-LSPs before
+   attempting to re-evaluate a preferable path when a Path message for
+   "Path Re-evaluation Request" is received with the S2L_SUB_LSP_FRAG
+   object.  If a midpoint LSR does not receive all fragments of the Path
+   message (for example, when fragments are lost) within a configurable
+   time interval, it SHOULD trigger the re-evaluation of all S2L
+   sub-LSPs of the P2MP-TE LSP transiting on the node.  A midpoint LSR
+   MUST receive at least one fragment of the Path message to trigger
+   this behavior.
+
+   An ingress node SHOULD wait to accumulate all S2L sub-LSPs before
+   attempting to trigger reoptimization when a PathErr with the Notify
+   error code and the "Preferable Path Exists" sub-code is received with
+   an S2L_SUB_LSP_FRAG object.  If an ingress node does not receive all
+   fragments of the PathErr message (for example, when fragments are
+   lost) within a configurable time interval, it SHOULD trigger the
+   reoptimization of all S2L sub-LSPs of the P2MP-TE LSP transiting on
+   the midpoint node that had sent the PathErr message.  An ingress node
+   MUST receive at least one fragment of the PathErr message to trigger
+   this behavior.
+
+   The S2L_SUB_LSP_FRAG object defined in this document has a wider
+   applicability in addition to the P2MP-TE LSP reoptimization.  It can
+   also be used (in Path and Resv messages) to set up a new P2MP-TE LSP
+   and to send other PathErr messages as well as Path Tear and Resv Tear
+   messages for a set of S2L sub-LSPs.  This is outside the scope of
+   this document.
+
+
+
+
+
+
+
+
+
+Saad, et al.                 Standards Track                   [Page 10]
+
+RFC 8149               P2MP-TE Loosely Routed LSPs            April 2017
+
+
+5.  Message and Object Definitions
+
+5.1.  "P2MP-TE Tree Re-evaluation Request" Flag
+
+   In order to trigger a tree re-evaluation request, a new flag in the
+   Attribute Flags TLV of the LSP_ATTRIBUTES object [RFC5420] is defined
+   by this document:
+
+      Bit Number 14: "P2MP-TE Tree Re-evaluation Request" flag
+
+   The "P2MP-TE Tree Re-evaluation Request" flag is meaningful in a Path
+   message of a P2MP-TE S2L sub-LSP and is inserted by the ingress node
+   using the message format defined in [RFC6510].
+
+5.2.  "Preferable P2MP-TE Tree Exists" Path Error Sub-code
+
+   In order to indicate to an ingress node that a preferable P2MP-TE LSP
+   tree exists, the following new sub-code for PathErr messages with
+   Notify error code 25 [RFC3209] is defined by this document:
+
+      Sub-code 13: "Preferable P2MP-TE Tree Exists" sub-code
+
+   When a preferable path for a P2MP-TE LSP tree exists, the midpoint
+   LSR sends a solicited or unsolicited "Preferable P2MP-TE Tree Exists"
+   sub-code with a PathErr message with Notify error code 25 to the
+   ingress node of the P2MP-TE LSP.
+
+5.3.  Fragment Identifier for S2L Sub-LSP Descriptor
+
+   The S2L_SUB_LSP object [RFC4875] identifies a particular S2L sub-LSP
+   belonging to the P2MP-TE LSP.  An S2L sub-LSP descriptor list is
+   created using a series of S2L_SUB_LSP objects as defined in
+   [RFC4875].  The RSVP message may need to be semantically fragmented
+   [RFC4875] due to a large number of S2L sub-LSPs added in the
+   descriptor list, and such fragments may be received out of order.  To
+   be able to rebuild the fragmented S2L sub-LSP descriptor list
+   correctly, the following object is defined to identify the fragments:
+
+   S2L_SUB_LSP_FRAG: Class Number 204
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |          Length (8 bytes)     | Class Num 204 |   C-Type 1    |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |            Fragment ID        | Fragments Tot.| Fragment Num. |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+Saad, et al.                 Standards Track                   [Page 11]
+
+RFC 8149               P2MP-TE Loosely Routed LSPs            April 2017
+
+
+   Fragment ID: 16-bit integer in the range of 1 to 65535.
+
+      This value is incremented for each new RSVP message that needs to
+      be semantically fragmented.  The fragment ID is reset to 1 when it
+      reaches the maximum value of 65535.  The scope of the fragment ID
+      is limited to the RSVP message type (e.g., Path) carrying the
+      fragment.  In other words, fragment IDs do not have any
+      correlation between different RSVP message types (e.g., Path and
+      PathErr).  The receiver does not check to ensure that the
+      consecutive new RSVP messages (e.g., Path messages) are received
+      with fragment IDs incremented by 1.
+
+   Fragments Total: 8-bit integer in the range of 1 to 255.
+
+      This value indicates the number of fragments sent for the given
+      RSVP message.  This value MUST be the same in all fragmented RSVP
+      messages with a common fragment ID.
+
+   Fragment Number: 8-bit integer in the range of 1 to 255.
+
+      This value indicates the position of this fragment in the given
+      RSVP message.
+
+   The format of an S2L sub-LSP descriptor message is as follows:
+
+      <S2L sub-LSP descriptor> ::=
+                       [ <S2L_SUB_LSP_FRAG> ]
+                         <S2L_SUB_LSP>
+                       [ <P2MP SECONDARY_EXPLICIT_ROUTE> ]
+
+   The S2L_SUB_LSP_FRAG object is added before adding the S2L_SUB_LSP
+   object in the semantically fragmented RSVP message.
+
+6.  Compatibility
+
+   The LSP_ATTRIBUTES object has been defined in [RFC5420] and its
+   message formats in [RFC6510] with class numbers in the form 11bbbbbb,
+   which ensures compatibility with non-supporting nodes.  Per
+   [RFC2205], nodes not supporting this extension will ignore the new
+   flag defined for this object in this document and will forward it
+   without modification.
+
+   The S2L_SUB_LSP_FRAG object has been defined with class numbers in
+   the form 11bbbbbb, which ensures compatibility with non-supporting
+   nodes.  Per [RFC2205], nodes not supporting this object will ignore
+   the object and will forward it without modification.
+
+
+
+
+
+Saad, et al.                 Standards Track                   [Page 12]
+
+RFC 8149               P2MP-TE Loosely Routed LSPs            April 2017
+
+
+7.  IANA Considerations
+
+   IANA has performed the actions described below.
+
+7.1.  "P2MP-TE Tree Re-evaluation Request" Flag
+
+   IANA maintains the "Resource Reservation Protocol-Traffic Engineering
+   (RSVP-TE) Parameters" registry (see
+   <http://www.iana.org/assignments/rsvp-te-parameters>).  Per
+   Section 5.1 of this document, IANA has registered a new flag in the
+   "Attribute Flags" registry.  This new flag is defined for the
+   Attribute Flags TLV in the LSP_ATTRIBUTES object [RFC5420].
+
+   +-----+---------------+----------+----------+-----+-----+-----------+
+   | Bit | Name          | Attribute| Attribute| RRO | ERO | Reference |
+   | No  |               | Flags    | Flags    |     |     |           |
+   |     |               | Path     | Resv     |     |     |           |
+   +-----+---------------+----------+----------+-----+-----+-----------+
+   |     | P2MP-TE Tree  | Yes      | No       | No  | No  | This      |
+   | 14  | Re-evaluation |          |          |     |     | document  |
+   |     | Request       |          |          |     |     |           |
+   +-----+---------------+----------+----------+-----+-----+-----------+
+
+7.2.  "Preferable P2MP-TE Tree Exists" Path Error Sub-code
+
+   IANA maintains the "Resource Reservation Protocol (RSVP) Parameters"
+   registry (see <http://www.iana.org/assignments/rsvp-parameters>).
+   Per Section 5.2 of this document, IANA has registered a new error
+   code in the "Sub-Codes - 25 Notify Error" sub-registry of the "Error
+   Codes and Globally-Defined Error Value Sub-Codes" registry.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Saad, et al.                 Standards Track                   [Page 13]
+
+RFC 8149               P2MP-TE Loosely Routed LSPs            April 2017
+
+
+   As defined in [RFC3209], error code 25 in the ERROR_SPEC object
+   corresponds to a PathErr with the Notify error.  This document adds a
+   new "Preferable P2MP-TE Tree Exists" sub-code for this PathErr as
+   follows:
+
+   +----------+--------------------+---------+---------+-----------+
+   | Value    | Description        | PathErr | PathErr | Reference |
+   |          |                    | Code    | Name    |           |
+   +----------+--------------------+---------+---------+-----------+
+   |  13      | Preferable P2MP-TE | 25      | Notify  | This      |
+   |          | Tree Exists        |         | Error   | document  |
+   +----------+--------------------+---------+---------+-----------+
+
+7.3.  Fragment Identifier for S2L Sub-LSP Descriptor
+
+   IANA maintains the "Resource Reservation Protocol (RSVP) Parameters"
+   registry (see <http://www.iana.org/assignments/rsvp-parameters>).
+   Per Section 5.3 of this document, IANA has registered a new class
+   number in the "Class Names, Class Numbers, and Class Types" registry.
+
+   +-----------------+---------------------------+-----------------+
+   | Class Number    | Class Name                | Reference       |
+   +-----------------+---------------------------+-----------------+
+   | 204             | S2L_SUB_LSP_FRAG          | This document   |
+   +-----------------+---------------------------+-----------------+
+
+   IANA has also created the "Class Types or C-Types - 204
+   S2L_SUB_LSP_FRAG" registry and populated it as follows:
+
+   +-----------------+---------------------------+-----------------+
+   | Value           | Description               | Reference       |
+   +-----------------+---------------------------+-----------------+
+   | 1               | S2L_SUB_LSP_FRAG          | This document   |
+   +-----------------+---------------------------+-----------------+
+
+8.  Security Considerations
+
+   This document defines RSVP-TE signaling extensions to allow an
+   ingress node of a P2MP-TE LSP to request the re-evaluation of the LSP
+   tree downstream of a node and to allow a midpoint LSR to notify the
+   ingress node of the existence of a preferable tree by sending a
+   PathErr message.  As per [RFC4736], in the case of a P2MP-TE LSP S2L
+   sub-LSP spanning multiple domains, it may be desirable for a midpoint
+   LSR to modify the RSVP PathErr message to preserve confidentiality
+   across domains.
+
+
+
+
+
+
+Saad, et al.                 Standards Track                   [Page 14]
+
+RFC 8149               P2MP-TE Loosely Routed LSPs            April 2017
+
+
+   This document also defines a fragment identifier for the S2L sub-LSP
+   descriptor when combining a large number of S2L sub-LSPs in an RSVP
+   message and the message needs to be semantically fragmented.  The
+   introduction of the fragment identifier, by itself, introduces no
+   additional information to signaling.  For a general discussion on
+   security issues related to MPLS and GMPLS, see the MPLS/GMPLS
+   security framework [RFC5920].
+
+9.  References
+
+9.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,
+              <http://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, <http://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,
+              <http://www.rfc-editor.org/info/rfc3209>.
+
+   [RFC4736]  Vasseur, JP., Ed., Ikejiri, Y., and R. Zhang,
+              "Reoptimization of Multiprotocol Label Switching (MPLS)
+              Traffic Engineering (TE) Loosely Routed Label Switched
+              Path (LSP)", RFC 4736, DOI 10.17487/RFC4736,
+              November 2006, <http://www.rfc-editor.org/info/rfc4736>.
+
+   [RFC4875]  Aggarwal, R., Ed., Papadimitriou, D., Ed., and S.
+              Yasukawa, Ed., "Extensions to Resource Reservation
+              Protocol - Traffic Engineering (RSVP-TE) for
+              Point-to-Multipoint TE Label Switched Paths (LSPs)",
+              RFC 4875, DOI 10.17487/RFC4875, May 2007,
+              <http://www.rfc-editor.org/info/rfc4875>.
+
+   [RFC5420]  Farrel, A., Ed., Papadimitriou, D., Vasseur, JP., and A.
+              Ayyangarps, "Encoding of Attributes for MPLS LSP
+              Establishment Using Resource Reservation Protocol Traffic
+              Engineering (RSVP-TE)", RFC 5420, DOI 10.17487/RFC5420,
+              February 2009, <http://www.rfc-editor.org/info/rfc5420>.
+
+
+
+
+
+
+Saad, et al.                 Standards Track                   [Page 15]
+
+RFC 8149               P2MP-TE Loosely Routed LSPs            April 2017
+
+
+9.2.  Informative References
+
+   [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,
+              <http://www.rfc-editor.org/info/rfc3473>.
+
+   [RFC5440]  Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation
+              Element (PCE) Communication Protocol (PCEP)", RFC 5440,
+              DOI 10.17487/RFC5440, March 2009,
+              <http://www.rfc-editor.org/info/rfc5440>.
+
+   [RFC5920]  Fang, L., Ed., "Security Framework for MPLS and GMPLS
+              Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010,
+              <http://www.rfc-editor.org/info/rfc5920>.
+
+   [RFC6510]  Berger, L. and G. Swallow, "Resource Reservation Protocol
+              (RSVP) Message Formats for Label Switched Path (LSP)
+              Attributes Objects", RFC 6510, DOI 10.17487/RFC6510,
+              February 2012, <http://www.rfc-editor.org/info/rfc6510>.
+
+Acknowledgments
+
+   The authors would like to thank Loa Andersson, Sriganesh Kini, Curtis
+   Villamizar, Dimitri Papadimitriou, Nobo Akiya, Vishnu Pavan Beeram,
+   and Joel M. Halpern for reviewing this document and providing many
+   useful comments and suggestions.  The authors would also like to
+   thank Ling Zeng with Cisco Systems for implementing the mechanisms
+   defined in this document.  A special thanks to Adrian Farrel for his
+   thorough review of this document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Saad, et al.                 Standards Track                   [Page 16]
+
+RFC 8149               P2MP-TE Loosely Routed LSPs            April 2017
+
+
+Authors' Addresses
+
+   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
+
+
+   Robert H. Venator
+   Defense Information Systems Agency
+
+   Email: robert.h.venator.civ@mail.mil
+
+
+   Yuji Kamite
+   NTT Communications Corporation
+
+   Email: y.kamite@ntt.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Saad, et al.                 Standards Track                   [Page 17]
+