Signaling Optimization Objective and Bounded Metrics for MPLS Fast Reroute Backup LSP Tunnels
draft-deshmukh-mpls-frr-ext-02

MPLS Working Group                                           A. Deshmukh
Internet-Draft                                              V. P. Beeram
Intended status: Standards Track                                     HPE
Expires: 6 January 2027                                          T. Saad
                                                           Cisco Systems
                                                             5 July 2026

   Signaling Optimization Objective and Bounded Metrics for MPLS Fast
                       Reroute Backup LSP Tunnels
                     draft-deshmukh-mpls-frr-ext-02

Abstract

   This document introduces RSVP-TE signaling procedures that enable the
   head-end Label Switched Router (LSR) of a local-protection-desiring
   Label Switched Path (LSP) to influence the optimization objective and
   bounded metric constraints used for the path computation of a backup
   LSP tunnel at a Point of Local Repair (PLR).

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 6 January 2027.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Deshmukh, et al.         Expires 6 January 2027                 [Page 1]
Internet-Draft                MPLS FRR EXT                     July 2026

   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 Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
     1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
       1.2.1.  Local-Protection-Desiring LSP . . . . . . . . . . . .   3
       1.2.2.  Optimization Objective  . . . . . . . . . . . . . . .   3
       1.2.3.  Bounded Metric  . . . . . . . . . . . . . . . . . . .   4
   2.  Procedure at the Ingress  . . . . . . . . . . . . . . . . . .   4
   3.  Procedure at the PLR  . . . . . . . . . . . . . . . . . . . .   5
   4.  Protocol Extensions . . . . . . . . . . . . . . . . . . . . .   5
     4.1.  Path Message Format . . . . . . . . . . . . . . . . . . .   5
     4.2.  FAST_REROUTE_EXT Object . . . . . . . . . . . . . . . . .   6
       4.2.1.  Optimization Metric TLV . . . . . . . . . . . . . . .   6
       4.2.2.  Bounded Metric TLV  . . . . . . . . . . . . . . . . .   7
     4.3.  RRO IPv4/IPv6 Sub-Object Flag . . . . . . . . . . . . . .   8
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
     6.1.  FAST_REROUTE_EXT Object . . . . . . . . . . . . . . . . .   9
       6.1.1.  Metrics and Flags . . . . . . . . . . . . . . . . . .   9
     6.2.  Record Route Object Sub-object Flags: FRR_EXT
           Protection  . . . . . . . . . . . . . . . . . . . . . . .  10
     6.3.  Error Codes and Error Values  . . . . . . . . . . . . . .  11
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  11
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  12
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  12
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Introduction

   [RFC4090] defines RSVP-TE signaling procedures to establish backup
   label-switched path (LSP) tunnels for local repair of LSP tunnels.
   It introduces the FAST_REROUTE object, which allows the head-end
   Label Switched Router (LSR) of a local-protection-desiring LSP to
   signal the constraints used for the path computation of a backup LSP
   tunnel at each point of local repair (PLR).  The constraints carried
   in the FAST_REROUTE object are limited to priorities, affinities, hop

Deshmukh, et al.         Expires 6 January 2027                 [Page 2]
Internet-Draft                MPLS FRR EXT                     July 2026

   limit, and bandwidth.  Implementations rely on the local policy at
   the PLR to determine the optimization objective and other relevant
   constraints for computing the backup path.

   This document enhances the options available at the head-end LSR of a
   local-protection-desiring LSP to influence the path computation of
   the backup LSP tunnel at the PLR.  It introduces an extensible TLV-
   based RSVP object, FAST_REROUTE_EXT, for signaling the optimization
   objective and bounded metric constraints to be imposed on the backup
   LSP tunnel path computation.  The signaling procedures defined in
   this document are backward-compatible with implementations that only
   understand the FAST_REROUTE object.

   The criteria for determining the appropriate optimization objective
   and bounded metrics for the backup LSP tunnel paths are outside the
   scope of this document.

1.1.  Requirements Language

   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.

1.2.  Terminology

   The reader is expected to be familiar with the terminology used in
   [RFC3209] and [RFC4090].

1.2.1.  Local-Protection-Desiring LSP

   In this document, a local-protection-desiring LSP refers to an MPLS
   RSVP-TE LSP for which local protection is requested by signaling the
   FAST_REROUTE object in the Path message as specified in [RFC4090].

1.2.2.  Optimization Objective

   An optimization objective is typically represented as a quantifiable
   metric that an algorithm aims to optimize (minimize or maximize,
   depending on the metric type) when selecting a TE path.  For example,
   the optimization objective used in the backup path computation could
   be (but are not limited to) any of the following:

   *  Minimize the cumulative "IGP Metric" along the traversed path.

   *  Minimize the cumulative "TE Metric" along the traversed path.

Deshmukh, et al.         Expires 6 January 2027                 [Page 3]
Internet-Draft                MPLS FRR EXT                     July 2026

   *  Minimize the cumulative "Delay-Average" along the traversed path.

   *  Maximize the minimum "Unreserved Bandwidth" along the traversed
      path.

   In certain scenarios where the path computation is deemed a multi-
   parameter optimization problem and multiple optimization objectives
   are considered, a normalization weight may be required for each
   objective.

1.2.3.  Bounded Metric

   A bounded metric is a constraint parameter that is used to define a
   bound that a computed TE path must satisfy.  The bounded metric can
   be of path-scope or link-scope.  A path-scoped bounded metric is used
   when the bound is to be imposed on the cumulative metric associated
   with a path, while a link-scoped bounded metric is used when the
   bound is to be imposed on the metric associated with a link.  An
   example of a path-scoped bounded metric specification is to ensure
   that the cumulative "TE Metric" along the traversed path does not
   exceed 1000.  An example of a link-scoped bounded metric
   specification is to ensure that the "Delay Variation Threshold" on a
   traversed link does not exceed 15 ms.

2.  Procedure at the Ingress

   The optimization objective and/or the bounded metrics for the backup
   LSP MAY be specified at the ingress of the primary LSP via explicit
   configuration.  The user may explicitly specify whether the
   optimization objective and/or bounded metrics of the local-
   protection-desiring LSP are to be inherited by the backup LSP at the
   PLR, or whether different values are to be used.  If there is no such
   explicit configuration, the local PLR policy will dictate the
   optimization objective and the bounded metrics used for the backup
   LSP.

   If such explicit configuration is present, then the ingress of the
   primary LSP MUST signal an RSVP Path message with the
   FAST_REROUTE_EXT object.  The presence of the FAST_REROUTE_EXT object
   in the Path message serves as a companion to the FAST_REROUTE object
   and is deemed a request to the PLR to establish the backup path using
   the optimization objective and/or the specified bounded metrics.  The
   ingress MUST NOT include the FAST_REROUTE_EXT object in the Path
   message unless it also includes the FAST_REROUTE object.  When the
   ingress receives the corresponding Resv message, it can determine
   whether each PLR was able to honor the signaled request by checking
   whether the "FRR_EXT protection" flag in the Resv RRO sub-object for
   that PLR is set.

Deshmukh, et al.         Expires 6 January 2027                 [Page 4]
Internet-Draft                MPLS FRR EXT                     July 2026

3.  Procedure at the PLR

   A PLR that does not understand the FAST_REROUTE_EXT object MUST
   ignore the object in the Path message but forward it unexamined and
   unmodified.  The class number used for the object will ensure this
   behavior.  In such a scenario, the local policy on the PLR will
   dictate the optimization objective and bounded metrics for the backup
   path computation.

   A PLR that understands the FAST_REROUTE_EXT object but does not find
   the companion FAST_REROUTE object in the Path message MUST reject the
   Path message with the following error - {Policy Control Failure (2),
   Missing FAST_REROUTE object (TBA3)}. When computing the backup path,
   the bounded metrics specified in the FAST_REROUTE_EXT object MUST be
   treated as hard constraints that the computed path must satisfy.  The
   optimization objective is applied to select the best path among those
   that meet the bounded metric constraints.  A PLR that understands the
   FAST_REROUTE_EXT object but cannot satisfy the requested optimization
   objective and bounded metrics MAY fall back onto the optimization
   objective and bounded metrics dictated by local policy.  In such a
   scenario, the PLR MUST NOT set the "FRR_EXT protection" flag in the
   corresponding Resv RRO sub-object.  A PLR that understands the
   FAST_REROUTE_EXT object and successfully satisfies the requested
   optimization objective and bounded metrics MUST set the "FRR_EXT
   protection" flag in the corresponding Resv RRO sub-object.

4.  Protocol Extensions

4.1.  Path Message Format

   This document extends the Path message format defined in [RFC4090] as
   follows:

   <Path Message> ::= <Common Header> [ <INTEGRITY> ]
                      <SESSION> <RSVP_HOP>
                      <TIME_VALUES>
                      [ <EXPLICIT_ROUTE> ]
                      <LABEL_REQUEST>
                      [ <SESSION_ATTRIBUTE> ]
                      [ <POLICY_DATA> ... ]
                      <sender descriptor>
                      [ <FAST_REROUTE> ]
                      [ <FAST_REROUTE_EXT> ]

   The FAST_REROUTE_EXT object is optional and, when present, MUST
   appear after the FAST_REROUTE object.

Deshmukh, et al.         Expires 6 January 2027                 [Page 5]
Internet-Draft                MPLS FRR EXT                     July 2026

4.2.  FAST_REROUTE_EXT Object

   The FAST_REROUTE_EXT Object carries a set of TLVs.  It MAY be carried
   in an RSVP Path message.  It MUST carry at least one TLV when
   present.  It MUST always be accompanied by a FAST_REROUTE object in
   the RSVP Path message.

   Class-Num = TBA1 (Format - 11bbbbbb) C-Type = 1

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                            (TLVs)                           //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   *  TLVs

      -  Series of TLVs.

   Each TLV has the form:

    0                   1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------//----------------+
   |      Type     |     Length    |       (TLV contents)          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------//----------------+

   *  The Length field in the TLV contains the total length of the TLV
      in bytes, including the Type and Length fields.  The Length MUST
      be at least 4 and MUST be a multiple of 4.

4.2.1.  Optimization Metric TLV

   The Optimization Metric TLV carries the Metric-Type to be used in the
   optimization objective.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Type     |     Length    |  Metric Type  |   Weight      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   *  Type = 1 - Optimization Metric TLV

   *  Length = 4

Deshmukh, et al.         Expires 6 January 2027                 [Page 6]
Internet-Draft                MPLS FRR EXT                     July 2026

   *  Metric Type:

      -  1 IGP

      -  2 TE

      -  3 Unreserved-Bandwidth

      -  4 Delay-Minimum

      -  5 Delay-Average

      -  6 Delay-Maximum

   *  Weight: Metric Normalization Weight

   In some scenarios where multiple optimization objectives are desired,
   multiple Optimization Metric TLVs (each with a unique "Metric Type")
   MAY be packed into the FAST_REROUTE_EXT object.  In such scenarios,
   the weight field is used for normalizing different metrics.  When
   only one optimization objective is specified, the weight field is set
   to zero and is ignored.

   The optimization direction (minimize or maximize) is implicit based
   on the metric type.  For example, metrics such as IGP, TE, and Delay
   are minimized, while Unreserved-Bandwidth is maximized.

4.2.2.  Bounded Metric TLV

   The Bounded Metric TLV is used to carry the bound value for the
   specified Metric-Type.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Type     |     Length    |  Metric Type  |    Flags      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Metric Bound                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   *  Type = 2 Bounded Metric TLV

   *  Length = 8

   *  Metric Type:

      -  1 IGP

Deshmukh, et al.         Expires 6 January 2027                 [Page 7]
Internet-Draft                MPLS FRR EXT                     July 2026

      -  2 TE

      -  3 Unreserved-Bandwidth

      -  4 Delay-Minimum

      -  5 Delay-Average

      -  6 Delay-Maximum

      -  7 Delay-Variation-Threshold

   *  Flags (8 bits):

      -  L (bit 0): When set, indicates that the bound applies to
         individual links (link-scope).  When clear, indicates that the
         bound applies to the cumulative path metric (path-scope).

      -  Bits 1-7: Reserved.  MUST be set to zero on transmission and
         MUST be ignored on receipt.

   *  Metric Bound: Bounded metric value.  The units used and whether
      the bound is upper or lower depends on the metric-type.

   There can be more than one Bounded Metric TLV (each with a unique
   combination of Metric Type and L flag value) packed into the
   FAST_REROUTE_EXT object.  The Bounded Metric TLV, if present, MUST
   include a non-zero "Metric Bound" value.  If there is a desire to
   specify a metric-bound for the same metric that is being optimized
   for, then the expectation is that both Optimization Metric TLV and
   Bounded Metric TLV for the same metric type are included in the
   FAST_REROUTE_EXT object.  There MUST be at most one instance of the
   Bounded Metric TLV for each metric type with the same L flag (Link
   Scope) value.  If two or more instances of a Bounded Metric TLV with
   the same L flag value are present for a metric type, only the first
   instance is processed; subsequent instances MUST be ignored.  The
   presence of two Bounded Metric TLVs of the same type with a different
   value of the L flag is allowed.

4.3.  RRO IPv4/IPv6 Sub-Object Flag

   FRR_EXT protection: TBA2

   The PLR MUST set this bit in the Resv RRO IPv4/IPv6 sub-object when
   it has successfully satisfied the optimization objective and/or
   bounded metrics specified in the FAST_REROUTE_EXT object received in
   the corresponding Path message.  The PLR MUST NOT set this bit if the
   request was not satisfied.

Deshmukh, et al.         Expires 6 January 2027                 [Page 8]
Internet-Draft                MPLS FRR EXT                     July 2026

5.  Security Considerations

   The security considerations pertaining to the original RSVP protocol
   ([RFC2205], [RFC3209], and [RFC5920]) remain relevant.  When using
   RSVP cryptographic authentication [RFC2747], more robust algorithms
   such as HMAC-SHA256, HMAC-SHA384, or HMAC-SHA512 [RFC2104]
   [FIPS-180-4] SHOULD be used when computing the keyed message digest
   where possible.

6.  IANA Considerations

6.1.  FAST_REROUTE_EXT Object

   IANA maintains the Class Names, Class Numbers, and Class Types
   registries in the "RSVP parameters" registry group (see
   http://www.iana.org/assignments/rsvp-parameters/rsvp-parameters.xml
   (http://www.iana.org/assignments/rsvp-parameters/rsvp-
   parameters.xml)).  IANA is requested to extend these registries by
   adding a new Class Number (in the 11bbbbbb range) and assigning a new
   C-Type under this Class Number, as described below:

   Class Number     Class Name           Reference
      TBA1          FAST_REROUTE_EXT     This document

   Class Type of C-types - TBA1 FAST_REROUTE_EXT

   Value      Description            Reference
     1        FAST_REROUTE_EXT       This document

   IANA is requested to add a new sub-registry for "FAST_REROUTE_EXT
   TLVs" as shown below.  New registrations can be added via "IETF
   Review" [RFC8126].

   Type      Description            Reference
     1       Optimization Metric    This document
     2       Bounded Metric         This document

6.1.1.  Metrics and Flags

   IANA manages several registries as part of the 'Resource Reservation
   Protocol-Traffic Engineering (RSVP-TE) Parameters' registry located
   at http://www.iana.org/assignments/rsvp-te-parameters
   (http://www.iana.org/assignments/rsvp-te-parameters).  IANA is
   requested to extend this list of registries by adding three new
   registries - "FAST_REROUTE_EXT - Optimization Metric Types",
   "FAST_REROUTE_EXT - Bounded Metric Types", and "FAST_REROUTE_EXT -
   Bounded Metric TLV Flags" as shown below.  New registrations can be
   added via "IETF Review" [RFC8126].

Deshmukh, et al.         Expires 6 January 2027                 [Page 9]
Internet-Draft                MPLS FRR EXT                     July 2026

   FAST_REROUTE_EXT - Optimization Metric Types

   Value     Metric Type
    1        IGP
    2        TE
    3        Unreserved-Bandwidth
    4        Delay-Minimum
    5        Delay-Average
    6        Delay-Maximum

   FAST_REROUTE_EXT - Bounded Metric Types

   Value  Metric Type                Path   Link
                                     Scope  Scope
    1     IGP                        Y      Y
    2     TE                         Y      Y
    3     Unreserved-Bandwidth       Y      Y
    4     Delay-Minimum              Y      Y
    5     Delay-Average              Y      Y
    6     Delay-Maximum              Y      Y
    7     Delay-Variation-Threshold  N      Y

6.1.1.1.  Bounded Metric TLV Flags

   FAST_REROUTE_EXT - Bounded Metric TLV Flags

   Bit       Description            Reference
     0       L (Link-Scope)         This document
   1-7       Unassigned

6.2.  Record Route Object Sub-object Flags: FRR_EXT Protection

   IANA manages the 'Record Route Object Sub-object Flags' registry as
   part of the 'Resource Reservation Protocol-Traffic Engineering (RSVP-
   TE) Parameters' registry located at http://www.iana.org/assignments/
   rsvp-te-parameters (http://www.iana.org/assignments/rsvp-te-
   parameters).  IANA is requested to extend this registry by adding a
   new Flag as described below:

   Flag      Description            Reference
   TBA2      FRR_EXT protection     This document

Deshmukh, et al.         Expires 6 January 2027                [Page 10]
Internet-Draft                MPLS FRR EXT                     July 2026

6.3.  Error Codes and Error Values

   IANA maintains a registry called "Resource Reservation Protocol
   (RSVP) Parameters" with a subregistry called "Error Codes and
   Globally-Defined Error Value Sub-Codes".  Within this subregistry
   there is a definition of the "Policy Control Failure" error code with
   error code value 2.  The definition lists a number of error values
   that may be used with this error code.  IANA is requested to allocate
   a new value for use with this error code as described in this
   document.  The resulting entry in the registry should look as
   follows:

   Sub-Codes - 2 Policy Control Failure

   This Error Code has the following globally-defined Error Value sub-
   codes:

   Value      Description                       Reference
   TBA3       Missing FAST_REROUTE object       This document

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/rfc/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/rfc/rfc2205>.

   [RFC3209]  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
              and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
              Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
              <https://www.rfc-editor.org/rfc/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/rfc/rfc4090>.

   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", BCP 26,
              RFC 8126, DOI 10.17487/RFC8126, June 2017,
              <https://www.rfc-editor.org/rfc/rfc8126>.

Deshmukh, et al.         Expires 6 January 2027                [Page 11]
Internet-Draft                MPLS FRR EXT                     July 2026

   [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/rfc/rfc8174>.

7.2.  Informative References

   [FIPS-180-4]
              National Institute of Standards and Technology, "Secure
              Hash Standard", <https://nvlpubs.nist.gov/nistpubs/FIPS/
              NIST.FIPS.180-4.pdf> , August 2015.

   [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
              Hashing for Message Authentication", RFC 2104,
              DOI 10.17487/RFC2104, February 1997,
              <https://www.rfc-editor.org/rfc/rfc2104>.

   [RFC2747]  Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic
              Authentication", RFC 2747, DOI 10.17487/RFC2747, January
              2000, <https://www.rfc-editor.org/rfc/rfc2747>.

   [RFC5920]  Fang, L., Ed., "Security Framework for MPLS and GMPLS
              Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010,
              <https://www.rfc-editor.org/rfc/rfc5920>.

Acknowledgments

   The authors would like to thank Minjie Dai for his input from
   discussions.

   This document was prepared using kramdown.

Contributors

   Chandrasekar Ramachandran
   HPE
   Email: chandrasekar.ramachandran@hpe.com

   Colby Barth
   HPE
   Email: jonathan.barth@hpe.com

Authors' Addresses

   Abhishek Deshmukh
   HPE
   Email: abhishek.deshmukh@hpe.com

Deshmukh, et al.         Expires 6 January 2027                [Page 12]
Internet-Draft                MPLS FRR EXT                     July 2026

   Vishnu Pavan Beeram
   HPE
   Email: vishnupavan.ietf@gmail.com

   Tarek Saad
   Cisco Systems
   Email: tsaad.net@gmail.com

Deshmukh, et al.         Expires 6 January 2027                [Page 13]