RFC 9705

Refresh-Interval Independent RSVP Fast Reroute Facility Protection

📅 published March 2025, from ietf

RFC 9705 💖 Refresh-Interval Independent RSVP Fast Reroute Facility Protection

Okay bestie, let's get into it 🎀 This one's RFC 9705, and it's a Standards Track document from the IETF (ISSN 2070-1721) dated March 2025. The authors are C. Ramachandran (Juniper Networks, Inc.), T. Saad (Cisco Systems, Inc.), and D. Pacella (Verizon, Inc.). It updates RFC 4090 🦋 The title block doesn't list anything it obsoletes.

   1.  Introduction
     1.1.  Motivation
   2.  Abbreviations and Terminology
     2.1.  Abbreviations
     2.2.  Terminology
   3.  Problem Description
   4.  Solution Aspects
     4.1.  Requirement for RFC 4090 Capable Nodes to Advertise the
           RI-RSVP Capability
     4.2.  Signaling Handshake Between PLR and MP
       4.2.1.  PLR Behavior
       4.2.2.  Remote Signaling Adjacency
       4.2.3.  MP Behavior
       4.2.4.  "Remote" State on MP
     4.3.  Impact of Failures on LSP State
       4.3.1.  Non-MP Behavior
       4.3.2.  LP-MP Behavior
       4.3.3.  NP-MP Behavior
       4.3.4.  Behavior of a Router That Is Both the LP-MP and NP-MP
     4.4.  Conditional PathTear
       4.4.1.  Sending the Conditional PathTear
       4.4.2.  Processing the Conditional PathTear
       4.4.3.  CONDITIONS Object
     4.5.  Remote State Teardown
       4.5.1.  PLR Behavior on Local Repair Failure
       4.5.2.  PLR Behavior on Resv RRO Change
       4.5.3.  LSP Preemption During Local Repair
         4.5.3.1.  Preemption on LP-MP After PHOP Link Failure
         4.5.3.2.  Preemption on NP-MP After PHOP Link Failure
     4.6.  Backward Compatibility Procedures
       4.6.1.  Detecting Support for Refresh-Interval Independent RSVP
               FRR
       4.6.2.  Procedures for Backward Compatibility
         4.6.2.1.  Lack of Support on Downstream Nodes
         4.6.2.2.  Lack of Support on Upstream Nodes
         4.6.2.3.  Incremental Deployment
     4.7.  Consequences of Advertising RI-RSVP Without RI-RSVP-FRR
   5.  Security Considerations
   6.  IANA Considerations
     6.1.  CONDITIONS Object
   7.  References
     7.1.  Normative References
     7.2.  Informative References
   Acknowledgements
   Contributors
   Authors' Addresses

Abstract ✨

Okay so the RSVP-TE Fast Reroute (FRR) extensions in RFC 4090 give you two local repair techniques for rerouting Label Switched Path (LSP) traffic over backup tunnels that are set up in advance 🌸 The facility backup method lets one or more LSPs going through a connected link or node get protected by a bypass tunnel. The many-to-one thing about local repair is seriously attractive from a scalability point of view 😭

This document lists the facility backup procedures in RFC 4090 that depend on refresh timeouts, which makes that method refresh-interval dependent. The RSVP-TE extensions in this document make those procedures refresh-interval independent, so the method works with the Refresh-Interval Independent RSVP (RI-RSVP) capability from RFC 8370 💅 That's why this document updates RFC 4090, so it can support the RI-RSVP capability specified in RFC 8370.

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.

You can find info about the current status of this document, any errata, and how to give feedback on it at https://www.rfc-editor.org/info/rfc9705 🔗

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

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they're in effect on the date this document was published. Please read these carefully, because they explain your rights and restrictions with respect to this document. Code Components pulled out of this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Revised BSD License 🫶

This document may contain material from IETF Documents or IETF Contributions that were published or made publicly available before November 10, 2008. The people controlling the copyright in some of that material may not have granted the IETF Trust the right to allow modifications of it outside the IETF Standards Process. Unless you get an adequate license from the people controlling the copyright in those materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process. The exceptions are formatting it for publication as an RFC or translating it into languages other than English 🌈

1. Introduction 🧚

RSVP-TE relies on periodic refreshes of RSVP messages to synchronize and maintain the states related to the Label Switched Path (LSP) along the reserved path. If refresh messages stop coming, the LSP-related states get deleted automatically. Relying on periodic refreshes and refresh timeouts is a scalability problem. The number of RSVP-TE LSPs a router has to maintain keeps growing in service provider networks, so implementations need to be able to handle that growth in LSP scale 📈

[RFC2961] specifies mechanisms that remove the reliance on periodic refreshes and refresh timeouts for RSVP messages. They let a router stretch the message refresh interval to values much longer than the default 30 seconds defined in [RFC2205]. However, the protocol extensions in [RFC4090] for supporting Fast Reroute (FRR) using bypass tunnels implicitly rely on short refresh timeouts to clean up stale states 👀

To get rid of the reliance on refresh timeouts, routers should be able to tell unambiguously when a particular LSP state should be deleted. In FRR scenarios that use bypass tunnels [RFC4090], some extra explicit teardown messages are needed. The Refresh-Interval Independent RSVP-TE FRR (RI-RSVP-FRR) extensions specified in this document are the procedures that make LSP state cleanup happen. They're essential for supporting the RI-RSVP capability for FRR using bypass tunnels from [RFC4090] 💜

1.1. Motivation 💭

Base RSVP [RFC2205] keeps state by generating RSVP Path and Resv refresh messages. Refresh messages are used both to synchronize state between RSVP neighbors and to recover from lost RSVP messages. Using refresh messages to cover so many possible failures has caused a bunch of operational problems 😩

  • One problem is RSVP control plane scaling, because Path and Resv messages get refreshed periodically.
  • Another problem is the reliability and latency of RSVP signaling.
  • A third problem is how long it takes to clean up stale state after a tear message gets lost. For more on these problems, see Section 1 of [RFC2961].

These problems hurt RSVP control plane scalability, and RSVP-TE [RFC3209] inherited them from standard RSVP. The procedures in [RFC2961] fix the problems above. They do this by removing the dependency on refreshes for state synchronization and for recovering from lost RSVP messages, and also by removing the dependency on refresh timeouts for stale state cleanup. Implementing those procedures lets implementations improve RSVP-TE control plane scalability ✨ For more details on removing the dependency on refresh timeouts for stale state cleanup, check out Section 3 of [RFC8370].

Here's the catch: the facility backup protection procedures in [RFC4090] don't fully deal with stale state cleanup, because they still depend on refresh timeouts for it 🙈 The updated facility backup protection procedures in this document, combined with RSVP-TE Scaling Techniques [RFC8370], get rid of that dependency on refresh timeouts for stale state cleanup.

The procedures in this document assume reliable delivery of RSVP messages, as specified in [RFC2961]. That means [RFC2961] is a prerequisite for this document 🎀

2. Abbreviations and Terminology 🌸

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. So those capital words are the ones with real weight 💅

You're also expected to know the terminology in [RFC2205], [RFC3209], [RFC4090], [RFC4558], [RFC8370], and [RFC8796] 📚

2.1. Abbreviations 🔤

  • PHOP: Previous-Hop (can refer to a router or node along the LSP)
  • PPHOP: Previous-Previous-Hop (can refer to a router or node along the LSP)
  • NHOP: Next-Hop (can refer to a router or node along the LSP)
  • NNHOP: Next-Next-Hop (can refer to a router or node along the LSP)
  • PLR: Point of Local Repair (can refer to a router as defined in [RFC4090])
  • MP: Merge Point (can refer to a router as defined in [RFC4090])
  • LP-MP: Link-Protecting Merge Point (can refer to a router or node at the tail of a Link-Protecting bypass tunnel)
  • NP-MP: Node-Protecting Merge Point (can refer to a router or node at the tail of a Node-Protecting bypass tunnel)
  • PSB: Path State Block
  • RSB: Reservation State Block
  • RRO: Record Route Object (as defined in [RFC3209])
  • TED: Traffic Engineering Database
  • RI-RSVP: Refresh-Interval Independent RSVP (the set of procedures defined in Section 3 of [RFC8370] to get rid of RSVP's reliance on periodic message refreshes)
  • RI-RSVP-FRR: Refresh-Interval Independent RSVP-TE FRR (the set of procedures defined in this document to get rid of RSVP's reliance on periodic message refreshes when supporting facility backup protection [RFC4090])

2.2. Terminology 🧠

  • B-SFRR-Ready: Bypass Summary FRR Ready Extended ASSOCIATION object as defined in [RFC8796] and added by the PLR for each protected LSP
  • Conditional PathTear: A PathTear message that suggests the receiving downstream router keep the path state if that router is an NP-MP 🫣
  • Remote PathTear: A PathTear message sent from a PLR to the MP to delete the LSP state on the MP, used when the PLR hadn't previously sent the backup path state reliably
  • LSP state: The combination of the "path state" kept as a PSB and the "reservation state" kept as an RSB forms an individual LSP state on an RSVP-TE speaker 🦄

3. Problem Description 🎀

Okay bestie, look at Figure 1 🦋. Picture a whole bunch of LSPs going from A to D and hopping through B and C. The refresh interval is set to something on the order of minutes, and refresh reduction extensions are turned on on every router 💅.

                                 E
                               /   \
                              /     \
                             /       \
                            /         \
                           /           \
                          /             \
                         A ----- B ----- C ----- D
                                 \             /
                                  \           /
                                   \         /
                                    \       /
                                     \     /
                                      \   /
                                        F

                         Figure 1: Example Topology

Now add node protection for the LSPs. Here's how each router is covering for the others 🫶:

  • A has node protection through the bypass A -> E -> C. A is the PLR and C is the NP-MP.
  • B has node protection through the bypass B -> F -> D. B is the PLR and D is the NP-MP.
  • C has link protection through the bypass C -> B -> F -> D. C is the PLR and D is the LP-MP.

Now the drama 😭. The B-C link fails. Under normal conditions, this is the order of events everyone expects for every protected LSP:

  • Step 1. B does a local repair and redirects LSP traffic over the bypass B -> F -> D.
  • Step 2. B also creates a backup state for the LSP and triggers the sending of a backup LSP state to D over the bypass B -> F -> D.
  • Step 3. D receives the backup LSP states and merges the backups with the protected LSPs.
  • Step 4. The link on C that the LSP states were refreshed over has failed, so C stops getting state refreshes. The protected LSP states on C time out, and C sends teardown messages for all LSPs. Since each router should consider itself an MP, C only times out the state after waiting an additional duration equal to the refresh timeout.

[RFC4090] describes this sequence 📖, but ngl there are a few gaps where no mechanism has been explicitly specified 😬:

  • If the protected LSP on C times out before D receives signaling for the backup LSP, D gets a PathTear from C before it hears about the backup LSP, so D deletes the LSP state. At scale, this could happen even with the default refresh time.
  • If C keeps its state until the timeout after the link fails, a long refresh interval can leave a big pile of stale state on C. But if C deletes the state and sends a PathTear to D when the link fails, D deletes its state too, and the LSP is gone. D needs a reliable way to figure out whether it is an MP to fix this 💀.
  • If head-end A tries to tear down the LSP after Step 1 but before Step 2, B might get the teardown message before Step 2 and delete the LSP state from its state database. If B deletes its state without informing D, a long refresh interval could cause a (large) buildup of stale state on D.
  • If B fails to perform a local repair in Step 1, B deletes the LSP state from its state database without informing D. With a long refresh interval, this could cause a (large) buildup of stale state on D.

The purpose of this document is to solve these problems so it becomes practical to scale up to a large number of protected LSPs in the network 🚀.

4. Solution Aspects ✨

The solution has five parts 👑:

  1. Use the MP determination mechanism specified in RSVP-TE Summary FRR [RFC8796], which lets the PLR signal the availability of local protection to the MP. Also introduce PLR and MP procedures to establish a Node-ID-based Hello session between the PLR and the MP, which detects router failures and determines capability. See Section 4.2 of this document for more details. This part reuses some of the extensions defined in [RFC8796] and [RFC8370], and the subsequent subsections list the extensions from these documents that are used here.
  2. Handle upstream link or node failures by cleaning up LSP states if the node has not found itself to be an MP through the MP determination mechanism. See Section 4.3 of this document for more details.
  3. Introduce extensions that let a router send a teardown message to the downstream router, so the receiving router can conditionally delete its local LSP state. See Section 4.4 of this document for more details.
  4. Enhance facility backup protection by letting a PLR send a teardown message directly to the MP, without requiring the PLR to either have a working bypass LSP or have already signaled the backup LSP state. See Section 4.5 of this document for more details.
  5. Introduce extensions so these procedures stay backward compatible with routers along the LSP running implementations that do not support them. See Section 4.6 of this document for more details.

4.1. Requirement for RFC 4090 Capable Nodes to Advertise the RI-RSVP Capability

A node supporting facility backup protection [RFC4090] MUST NOT set the RI-RSVP flag (I-bit) defined in Section 3.1 of [RFC8370] unless it supports all the extensions specified in the rest of this document. So this document updates [RFC4090] by defining extensions and additional procedures over facility backup protection [RFC4090], so it can advertise the RI-RSVP capability [RFC8370]. However, if a node supporting facility backup protection [RFC4090] does set the RI-RSVP capability (I-bit) but doesn't support all the extensions in the rest of this document, it may result in lingering stale states because of the long refresh intervals recommended by [RFC8370]. This can also disrupt normal Fast Reroute (FRR) operations. Section 4.7 of this document delves into this in detail 🙈.

4.2. Signaling Handshake Between PLR and MP

4.2.1. PLR Behavior

As per the facility backup procedures [RFC4090], when an LSP becomes operational on a node and the "local protection desired" flag is set in the SESSION_ATTRIBUTE object carried in the Path message for that LSP, the node tries to make local protection available for the LSP.

  • If the "node protection desired" flag is set, the node tries to become a PLR by attempting to create an NP-bypass LSP to the NNHOP node, avoiding the NHOP node on a protected LSP. If node protection couldn't be made available, the node tries to create an LP-bypass LSP to the NHOP node, avoiding only the link that the protected LSP takes to reach the NHOP.
  • If the "node protection desired" flag is not set, the PLR tries to create an LP-bypass LSP to the NHOP node, avoiding the link that the protected LSP takes to reach the NHOP.

With regard to the PLR procedures above, which are specified in [RFC4090], this document specifies these additional procedures to support RI-RSVP [RFC8370]:

  • While selecting the destination address of the bypass LSP, the PLR MUST select the router ID of the NNHOP or NHOP node from the Node-ID sub-object included in the RRO carried in the most recent Resv message corresponding to the LSP. If the MP has not included a Node-ID sub-object in the Resv RRO, and the PLR and the MP are in the same area, the PLR may utilize the TED to determine the router ID corresponding to the interface address that the MP included in the RRO. If the NP-MP in a different IGP area has not included a Node-ID sub-object in the RRO, the PLR MUST execute backward compatibility procedures as if the downstream nodes along the LSP do not support the extensions defined in this document (see Section 4.6.2.1).
  • The PLR MUST also include its router ID in a Node-ID sub-object in the RRO carried in any subsequent Path message corresponding to the LSP. While doing so, the PLR MUST include the Node-ID sub-object after including its IPv4/IPv6 address or unnumbered interface ID sub-object.
  • In parallel to the attempt to create an NP-bypass or an LP-bypass, the PLR MUST initiate a Node-ID-based Hello session to the NNHOP or NHOP node, respectively, along the LSP to establish the RSVP-TE signaling adjacency. This Hello session is used to detect MP node failure as well as to determine the capability of the MP node. The PLR MUST conclude that the MP supports the refresh-interval independent FRR procedures defined in this document if the MP has set the I-bit in the CAPABILITY object [RFC8370] carried in the Hello message corresponding to the Node-ID-based Hello session. If the MP has not sent Node-ID-based Hello messages, or has not set the I-bit in the CAPABILITY object [RFC8370], then the PLR MUST execute backward compatibility procedures defined in Section 4.6.2.1 of this document.
  • When the PLR associates a bypass with a protected LSP, it MUST include a B-SFRR-Ready Extended ASSOCIATION object [RFC8796] and trigger a Path message to be sent for the LSP. If a B-SFRR-Ready Extended ASSOCIATION object is included in the Path message corresponding to the LSP, the encoding and object ordering rules specified in RSVP-TE Summary FRR [RFC8796] MUST be followed. In addition to those rules, the PLR MUST set the Association Source in the object to its Node-ID address.

4.2.2. Remote Signaling Adjacency

A Node-ID-based RSVP-TE Hello session is one in which a Node-ID is used in the source and the destination address fields of RSVP Hello messages [RFC4558]. This document extends Node-ID-based RSVP Hello sessions to track the state of any RSVP-TE neighbor that is not directly connected by at least one interface. In order to apply Node-ID-based RSVP-TE Hello sessions between any two routers that are not immediate neighbors, the router that supports the extensions defined in this document MUST set the TTL to 255 in all outgoing Node-ID-based Hello messages exchanged between the PLR and the MP. The default hello interval for this Node-ID Hello session MUST be set to the default specified in RSVP-TE Scaling Techniques [RFC8370].

In the rest of this document, the terms "signaling adjacency" and "remote signaling adjacency" refer specifically to the RSVP-TE signaling adjacency. 💜

4.2.3. MP Behavior ✨

okay so bestie, this is where the merge point (MP) gets its glow-up 💅 With regard to the MP procedures in [RFC4090], this document adds some extra steps to support RI-RSVP as defined in [RFC8370] 🦋

Every node along an LSP that supports the extensions in this document MUST also put its router ID in the Node-ID sub-object of the RRO carried in the Resv message for that LSP 🌸 If the PLR didn't include a Node-ID sub-object in the RRO carried in the Path message AND the PLR is in a different IGP area, then the router MUST NOT run the MP procedures in this document for those LSPs 🙈 Instead, it MUST run the backward compatibility procedures in Section 4.6.2.2 of this document, as if the upstream nodes on the LSP don't support the extensions in this document. It's giving "pretend the new stuff isn't there" 💀

When a node gets a Path message, it should figure out two things:

  • whether the message has a B-SFRR-Ready Extended ASSOCIATION object with its own address as the bypass destination address, and
  • whether it has an operational Node-ID signaling adjacency with the Association Source.

The node MUST run the backward compatibility procedures in Section 4.6.2.2 of this document if any of these are true:

  • the PLR didn't include the B-SFRR-Ready Extended ASSOCIATION object,
  • there's no operational Node-ID signaling adjacency with the PLR (identified by the Association Source address), or
  • the PLR didn't advertise the RI-RSVP capability in its Node-ID-based Hello messages.

If a matching B-SFRR-Ready Extended ASSOCIATION object shows up in the Path message AND there's an operational remote Node-ID signaling adjacency with the PLR (the Association Source) that advertised the RI-RSVP capability (I-bit) [RFC8370], then the node MUST consider itself the MP for the PLR 👑 The matching and ordering rules for Bypass Summary FRR Extended Association from RSVP-TE Summary FRR [RFC8796] MUST be followed by implementations that support this document. Main character energy, honestly 🔥

  • If a matching Bypass Summary FRR Extended Association object is included by the PPHOP node of an LSP AND a matching Node-ID signaling adjacency exists with the PPHOP node, then the router MUST conclude it is the NP-MP.
  • If a matching Bypass Summary FRR Extended Association object is included by the PHOP node of an LSP AND a matching Node-ID signaling adjacency exists with the PHOP node, then the router MUST conclude it is the LP-MP.

4.2.4. "Remote" State on MP 🧚

Once a router figures out it's the MP for a PLR running refresh-interval independent FRR procedures (as described in the section just before this one), it MUST create a remote path state for the LSP 💜 The only difference between the "remote" path state and the LSP state is the RSVP_HOP object. In a "remote" path state, the RSVP_HOP object holds the address the PLR uses to send Node-ID Hello messages to the MP.

The MP MUST consider the "remote" path state for the LSP automatically deleted if:

  • the MP later gets a Path message for the LSP with no matching B-SFRR-Ready Extended ASSOCIATION object for the PLR's IP address in the Path RRO,
  • the Node-ID signaling adjacency with the PLR goes down,
  • the MP gets backup LSP signaling for the LSP from the PLR,
  • the MP gets a PathTear for the LSP, or
  • the MP deletes the LSP state because of a local policy or an exception event.

The whole point of "remote" path state is to let the PLR explicitly tear down the path and reservation states for the LSP, by sending a tear message for the "remote" path state. That kind of message is called a "Remote" PathTear 🦋

The scenarios where a "Remote" PathTear gets used are described in Section 4.5 of this document.

4.3. Impact of Failures on LSP State 💔

This section describes the procedures that must be executed when different kinds of failures happen, by nodes along the path of the LSP. The procedures that must be executed when RSVP signaling adjacency failures are detected do not affect the RSVP-TE graceful restart mechanisms [RFC3473] [RFC5063]. If a node running these procedures is acting as a helper for a neighboring router, then the signaling adjacency with that neighbor only gets declared as failed after the grace period extended to the neighbor by this helper node is taken into account 🫶

Node failures are detected from the state of Node-ID Hello sessions with immediate neighbors. RSVP-TE Scaling Techniques [RFC8370] recommends that each node set up Node-ID Hello sessions with all of its immediate neighbors ✨ A failure of a non-immediate PLR or MP is detected from the state of the remote signaling adjacency set up according to Section 4.2.2 of this document.

4.3.1. Non-MP Behavior 🙅‍♀️

When a router detects PHOP link or PHOP node failure for an LSP AND the router is not an MP for that LSP, then it MUST send a Conditional PathTear (see Section 4.4 of this document) and delete the PSB and RSB states for the LSP 😭

4.3.2. LP-MP Behavior 🌈

When the PHOP link for an LSP fails on a router that is an LP-MP for that LSP, the LP-MP MUST retain the PSB and RSB states for the LSP until any of these happens:

  • the Node-ID signaling adjacency with the PHOP PLR goes down,
  • the MP gets a normal or "Remote" PathTear for its PSB, or
  • the MP gets a ResvTear for its RSB.

When a router that's an LP-MP for an LSP detects PHOP node failure from the Node-ID signaling adjacency state, the LP-MP MUST send a normal PathTear and delete the PSB and RSB states for the LSP 💅

4.3.3. NP-MP Behavior 🍓

When a router that's an NP-MP for an LSP detects PHOP link failure or PHOP node failure from the Node-ID signaling adjacency, the router MUST retain the PSB and RSB states for the LSP until any of these happens:

  • the remote Node-ID signaling adjacency with the PPHOP PLR goes down,
  • the MP gets a normal or "Remote" PathTear for its PSB, or
  • the MP gets a ResvTear for its RSB.

When a router that's an NP-MP for an LSP does NOT detect the PHOP link or PHOP node failure, but DOES receive a Conditional PathTear from the PHOP node, then the router MUST retain the PSB and RSB states for the LSP until any of these happens:

  • the remote Node-ID signaling adjacency with the PPHOP PLR goes down,
  • the MP gets a normal or "Remote" PathTear for its PSB, or
  • the MP gets a ResvTear for its RSB.

Getting a Conditional PathTear from the PHOP node won't affect the "remote" state from the PPHOP PLR. Note that the PHOP node must have sent the Conditional PathTear because it wasn't an MP for the LSP (see Section 4.3.1 of this document).

Okay, let's walk through the example topology in Figure 1 🗺️ We assume C and D are the NP-MPs for PLRs A and B, respectively. Now, when the A-B link fails, B deletes the LSP state, because B isn't an MP and its PHOP link has failed (this behavior is required for unprotected LSPs; see Section 4.3.1 of this document). In the data plane, B has to delete the label forwarding entry for the LSP. So if B's downstream nodes C and D keep their state, it wouldn't be correct for D to keep assuming it's the NP-MP for PLR B 🙈

Here's how D stops thinking it's the NP-MP for B and deletes the matching "remote" path state:

  1. When C gets a Conditional PathTear from B, it decides to keep the LSP state, because it's the NP-MP for PLR A. It also checks whether PHOP B had earlier signaled node protection availability. Since B had signaled NP availability by including the B-SFRR-Ready Extended ASSOCIATION object, C removes the B-SFRR-Ready Extended ASSOCIATION object whose Association Source is set to B from the Path message, and triggers a Path to D.
  2. When D gets the Path message, it realizes it's no longer the NP-MP for B, so it deletes the matching "remote" path state. D doesn't propagate the Path any further down, because the only change is that the B-SFRR-Ready Extended ASSOCIATION object for Association Source B isn't in the Path message anymore 🦋

4.3.4. Behavior of a Router That Is Both the LP-MP and NP-MP 👑

A router can be the LP-MP AND the NP-MP at the same time, for the PHOP and PPHOP nodes of an LSP, respectively. If the PHOP link fails on a node like that, the node MUST retain the PSB and RSB states for the LSP until any of these happens:

  • both Node-ID signaling adjacencies with the PHOP and PPHOP nodes go down,
  • the MP gets a normal or "Remote" PathTear for its PSB, or
  • the MP gets a ResvTear for its RSB.

If a router that's both an LP-MP and an NP-MP detects PHOP node failure, then the node MUST retain the PSB and RSB states for the LSP until any of these happens:

  • the remote Node-ID signaling adjacency with the PPHOP PLR goes down,
  • the MP gets a normal or "Remote" PathTear for its PSB, or
  • the MP gets a ResvTear for its RSB.

4.4. Conditional PathTear 🎀

In the example in Section 4.3.3 of this document, B deletes the PSB and RSB states for the LSP once it detects its PHOP link has gone down, because B isn't an MP. If B sent a normal PathTear, then C would delete the LSP state right away 😱 To avoid that, there should be some way for B to tell C that B doesn't need the receiving node to unconditionally delete the LSP state immediately. So B MUST add a new optional CONDITIONS object to the PathTear. The CONDITIONS object is defined in Section 4.4.3 of this document. If node C understands the new object too, then C MUST NOT delete the LSP state if it's an NP-MP. Bestie, this is the whole trick ✨

4.4.1. Sending the Conditional PathTear 📮

A router that isn't an MP for an LSP MUST delete the PSB and RSB states for the LSP if the PHOP link or the PHOP Node-ID signaling adjacency goes down (see Section 4.3.1 of this document). The router MUST send a Conditional PathTear if these are also true:

  • the ingress has requested node protection for the LSP, and
  • no PathTear is received from the upstream node.

4.4.2. Processing the Conditional PathTear 💖

okay so when a router that is not an NP-MP receives a Conditional PathTear, it MUST delete the PSB and RSB states for that LSP and treat the Conditional PathTear like a normal PathTear 💅. Specifically, it MUST NOT pass the Conditional PathTear downstream. Instead, it removes the optional object and sends a normal PathTear downstream 🦋.

now the NP-MP is giving main character energy 👑. When a node that is an NP-MP receives a Conditional PathTear, it MUST NOT delete the LSP state 🙈. It MUST check whether the PHOP node had previously included the B-SFRR-Ready Extended ASSOCIATION object in the Path. If the PHOP did include it before, then the node processing the Conditional PathTear from the PHOP MUST remove the corresponding object and trigger a Path downstream ✨.

and if a Conditional PathTear comes from a neighbor that has not advertised support (refer to Section 4.6 of this document) for the new procedures in this doc, the node MUST consider the message as a normal PathTear 💀. It MUST propagate the normal PathTear downstream and delete the LSP state. no notes, just vibes 🫶.

4.4.3. CONDITIONS Object 🎀

any implementation that doesn't support a Conditional PathTear needs to ignore the new object, but still process the message as a normal PathTear without generating any error 🧚. That's why the Class-Num of the new object follows the pattern 10bbbbbb, where "b" represents a bit 🌈. (The behavior for objects of this type is specified in Section 3.10 of [RFC2205].)

the new object is called the "CONDITIONS" object, and it'll specify the conditions under which default processing rules of the RSVP-TE message MUST be invoked 🦋.

it has the following format:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Length               |  Class        |     C-type    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Flags (Reserved)                           |M|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 2: CONDITIONS Object
  • Class: 135
  • C-type: 1
  • Flags: 32 bit field
  • M: Bit 31 is the Merge-point condition (M) bit. If the M bit is set to 1, then the PathTear message MUST be processed according to the receiver router role, i.e., if the receiving router is an MP or not for the LSP. If it is not set, then the PathTear message MUST be processed as a normal PathTear message for the LSP.

Bits 0-30 are reserved. They MUST be set to zero on transmission and MUST be ignored on receipt 🍓.

4.5. Remote State Teardown ✨

okay picture this 🧚. If the ingress wants to tear down the LSP because of a management event while the LSP is being locally repaired at a transit PLR, it would not be desirable to wait until backup LSP signaling finishes before cleaning up state 😭. So in this case, the PLR MUST send a "Remote" PathTear message that tells the MP to delete the PSB and RSB states for the LSP. The TTL in the "Remote" PathTear message MUST be set to 255. Doing this enables LSP state cleanup while the LSP is being locally repaired, which is so iconic 👑.

consider node C in the example topology (Figure 1). Say C has gone down and node B locally repairs the LSP:

  1. Ingress A gets a management event to tear down the LSP.
  2. A sends a normal PathTear for the LSP to B.
  3. Assume B has not initiated the backup signaling for the LSP during local repair. To enable LSP state cleanup, B sends a "Remote" PathTear with the destination IP address set to that of the node D used in the Node-ID signaling adjacency with D, and the RSVP_HOP object containing the local address used in the Node-ID signaling adjacency.
  4. B then deletes the PSB and RSB states for the LSP.
  5. On D, there would be a remote signaling adjacency with B, so D accepts the "Remote" PathTear and deletes the PSB and RSB states for the LSP 🫶.

4.5.1. PLR Behavior on Local Repair Failure 💅

if local repair fails on the PLR after a failure, the PLR MUST send a "Remote" PathTear to the MP. The point of this is to clean up LSP state from the PLR all the way to the egress 🧹. When the MP receives the PathTear, it MUST delete the states corresponding to the LSP and also propagate the PathTear downstream. That way, state cleanup happens on every downstream node up to the LSP egress. Note that in the case of link protection, the PathTear MUST be directed to the LP-MP's Node-ID IP address rather than the NHOP interface address ⭐.

4.5.2. PLR Behavior on Resv RRO Change 🦋

when a PLR that has already made NP available for an LSP notices a change in the RRO carried in the Resv message, and that change shows its former NP-MP is no longer on the LSP's path, then the router MUST send a "Remote" PathTear directly to its former NP-MP. Yikes, the drama 💀.

in the example topology in Figure 1, let's say node A has made node protection available for an LSP, and C has concluded it is the NP-MP for PLR A. When the B-C link fails, C (implementing the procedure in Section 4.3.4 of this document) keeps the states for the LSP until one of the following happens:

  • the remote Node-ID signaling adjacency with A goes down, or
  • a PathTear or a ResvTear is received for its PSB or RSB, respectively.

if B has also made node protection available, B will eventually complete backup LSP signaling with its NP-MP D and trigger a Resv to A with the RRO changed 🌸. The new RRO of the LSP carried in that Resv will not contain C. When A processes the Resv message with a new RRO that doesn't contain C, its former NP-MP, A, sends a "Remote" PathTear to C. When C receives the "Remote" PathTear for its PSB state, C sends a normal PathTear downstream to D and deletes both the PSB and RSB states for the LSP. Since D has already received backup LSP signaling from B, D keeps the control plane and forwarding states for the LSP 🎀.

4.5.3. LSP Preemption During Local Repair ⭐

if an LSP gets preempted on an LP-MP after its PHOP link has already failed, but the backup LSP hasn't been signaled yet as part of the local repair procedure, then the node MUST send a normal PathTear and delete both the PSB and RSB states for the LSP. The LP-MP kept the LSP state expecting the PLR to start backup LSP signaling. Preemption would bring the LSP down, and the node wouldn't be an LP-MP anymore, so it has to clean up the LSP state 🧼.

if an LSP gets preempted on an NP-MP after its PHOP link has already failed, but the backup LSP hasn't been signaled yet, then the node MUST send a normal PathTear and delete the PSB and RSB states for the LSP. The NP-MP kept the LSP state expecting the PLR to start backup LSP signaling. Preemption would bring the LSP down, and the node wouldn't be an NP-MP anymore, so it has to clean up LSP state 🧹.

let's run this through the B-C link going down on the same example topology (Figure 1). Since C is the NP-MP for PLR A, C keeps the LSP state.

  1. The LSP gets preempted on C.
  2. C deletes the RSB state for the LSP. However, C can't send a PathErr or a ResvTear to PLR A, because the backup LSP hasn't been signaled yet.
  3. C was only keeping state after the PHOP node failure because it was an NP-MP. So C sends a normal PathTear to D and also deletes its PSB state. D also deletes the PSB and RSB states when it receives a PathTear from C.
  4. B starts backup LSP signaling to D. However, since D doesn't have the LSP state, it rejects the backup LSP Path message and sends a PathErr to B.
  5. B deletes its reservation and sends a ResvTear to A 😭.

4.6. Backward Compatibility Procedures 🌈

"Refresh-Interval Independent RSVP FRR" and "RI-RSVP-FRR" refer to the set of procedures defined in this document that get rid of the reliance on periodic refreshes ✨. The extensions proposed in RSVP-TE Summary FRR [RFC8796] might apply to implementations that don't support RI-RSVP-FRR. On the other hand, the RI-RSVP-FRR extensions for LSP state cleanup, namely Conditional and "Remote" PathTears, need support from one-hop and two-hop neighboring nodes along the LSP 🫶. So procedures in the LSP state cleanup category MUST NOT be turned on if any node involved in node protection FRR (i.e., the PLR, the MP, and the intermediate node in the case of NP) doesn't support RI-RSVP-FRR extensions. Note that for LSPs requesting link protection, only the PLR and the LP-MP MUST support the extensions 🧚.

4.6.1. Detecting Support for Refresh-Interval Independent RSVP FRR 🔍

an implementation supporting RI-RSVP-FRR extensions MUST set the RI-RSVP Capable flag in the CAPABILITY object carried in Hello messages, as specified in RSVP-TE Scaling Techniques [RFC8370]. If an implementation doesn't set the flag, even though it supports RI-RSVP-FRR extensions, then its neighbors will view the node as any node that doesn't support the extensions 🙈.

  • As nodes supporting the RI-RSVP-FRR extensions initiate Node-ID-based signaling adjacency with all immediate neighbors, a node on the path of a protected LSP can determine whether its PHOP and NHOP neighbors support RI-RSVP-FRR enhancements.
  • As nodes supporting the RI-RSVP-FRR extensions also initiate Node-ID-based signaling adjacency with the NNHOP along the path of the LSP requesting node protection (see Section 4.2.1 of this document), each node along the LSP can determine whether its NNHOP node supports RI-RSVP-FRR enhancements. If the NNHOP (a) does not reply to remote Node-ID Hello messages, or (b) does not set the RI-RSVP flag in the CAPABILITY object carried in its Node-ID Hello messages, then the node acting as the PLR can conclude that NNHOP doesn't support RI-RSVP-FRR extensions.
  • If node protection is requested for an LSP, and (a) the PPHOP node hasn't included a matching B-SFRR-Ready Extended ASSOCIATION object in its Path messages, (b) the PPHOP node hasn't initiated remote Node-ID Hello messages, or (c) the PPHOP node doesn't set the RI-RSVP flag in the CAPABILITY object carried in its Node-ID Hello messages, then the node MUST conclude that the PLR doesn't support RI-RSVP-FRR extensions 💖.

4.6.2. Procedures for Backward Compatibility 🎀

every node that supports RI-RSVP-FRR MUST support the procedures defined in this section, so that backward compatibility works for those subsets of LSPs that also traverse nodes that don't support RI-RSVP-FRR 🌸.

4.6.2.1. Lack of Support on Downstream Nodes 💅

Okay, so let's talk about what happens going downstream 🦋 Here's the procedure:

  • If a node finds that the NHOP node along the LSP does not support the RI-RSVP-FRR extensions, then the node MUST reduce the "refresh period" in the TIME_VALUES object carried in the Path messages to the default short refresh interval.
  • If node protection is requested for the LSP and the NNHOP node along the LSP does not support the RI-RSVP-FRR extensions, then the node MUST reduce the "refresh period" in the TIME_VALUES object carried in the Path messages to the default short refresh interval.

If a node reduces the refresh time using the above procedures, it MUST NOT send any "Remote" PathTear or Conditional PathTear message to the downstream node. 🙅‍♀️ Not allowed, bestie!

Consider the example topology in Figure 1. If C does not support the RI-RSVP-FRR extensions, then:

  • A and B reduce the refresh time to the default short refresh interval of 30 seconds and trigger a Path message. ✨
  • If B is not an MP and if the PHOP link of B fails, B cannot send a Conditional PathTear to C but times out the PSB state from A normally. Note that B can only normally time out the PSB state A if A did not set the long refresh in the TIME_VALUES object carried in the Path messages sent earlier. 💀 The vibe is "wait, it only works if A didn't go long-refresh," so be careful!

4.6.2.2. Lack of Support on Upstream Nodes 🌸

Now the upstream direction, which has its own set of rules 👑

  • If a node finds that the PHOP node along the LSP does not support the RI-RSVP-FRR extensions, then the node MUST reduce the "refresh period" in the TIME_VALUES object carried in the Resv messages to the default short refresh interval.
  • If node protection is requested for the LSP and the PHOP node along the LSP does not support the RI-RSVP-FRR extensions, then the node MUST reduce the "refresh period" in the TIME_VALUES object carried in the Path messages to the default short refresh interval (thus, the NHOP can use compatible values when sending a Resv). 🫶 That's the NHOP being a good friend and matching the vibe!
  • If node protection is requested for the LSP and the PPHOP node does not support the RI-RSVP-FRR extensions, then the node MUST reduce the "refresh period" in the TIME_VALUES object carried in the Resv messages to the default short refresh interval.
  • If the node reduces the refresh time using the above procedures, it MUST NOT execute MP procedures specified in Section 4.3 of this document. 🙈 No MP procedures for you!

4.6.2.3. Incremental Deployment 🧚

The backward compatibility procedures from the previous subsections mean that a router supporting the RI-RSVP-FRR extensions in this document can apply the procedures either in the downstream or upstream direction of an LSP. It all depends on whether the routers downstream or upstream in the LSP are capable 🌈

  • RI-RSVP-FRR extensions and procedures are enabled for downstream Path, PathTear, and ResvErr messages corresponding to an LSP if link protection is requested for the LSP and the NHOP node supports the extensions.
  • RI-RSVP-FRR extensions and procedures are enabled for downstream Path, PathTear, and ResvErr messages corresponding to an LSP if node protection is requested for the LSP and both NHOP and NNHOP nodes support the extensions.
  • RI-RSVP-FRR extensions and procedures are enabled for upstream PathErr, Resv, and ResvTear messages corresponding to an LSP if link protection is requested for the LSP and the PHOP node supports the extensions.
  • RI-RSVP-FRR extensions and procedures are enabled for upstream PathErr, Resv, and ResvTear messages corresponding to an LSP if node protection is requested for the LSP and both PHOP and PPHOP nodes support the extensions.

For example, say an implementation supporting the RI-RSVP-FRR extensions in this document is deployed on all routers in one particular region of the network, and all the LSPs in the network request node protection. Then the FRR extensions will only be applied to the LSP segments that traverse that region. ✨ This helps with incremental deployment and lets you reap the benefits of the extensions in whichever parts of the network support them. Iconic, honestly 👑

4.7. Consequences of Advertising RI-RSVP Without RI-RSVP-FRR 🚨

If a node supporting facility backup protection [RFC4090] sets the RI-RSVP capability (I-bit) but doesn't support the RI-RSVP-FRR extensions, because of an implementation bug or configuration error, then it leaves room for stale state to linger around for an inordinate period of time, or for disruption of normal FRR operations (see Section 3 of this document). Let's look at the example topology (Figure 1) from this document 👀

  • Assume node B does set the RI-RSVP capability in its Node-ID-based Hello messages even though it does not support RI-RSVP-FRR extensions. When B detects the failure of its PHOP link along an LSP, it will not send a Conditional PathTear to C as required by the RI-RSVP-FRR procedures. If B simply leaves the LSP state without deleting, then B may end up holding on to the stale state until the (long) refresh timeout. 😭
  • Instead of node B, assume node C does set the RI-RSVP capability in its Node-ID-based Hello messages even though it does not support RI-RSVP-FRR extensions. When B detects the failure of its PHOP link along an LSP, it will send a Conditional PathTear to C as required by the RI-RSVP-FRR procedures. However, C would not recognize the condition encoded in the PathTear and end up tearing down the LSP. 💔 Not ideal!
  • Assume node B does set the RI-RSVP capability in its Node-ID-based Hello messages even though it does not support RI-RSVP-FRR extensions. In addition, assume local repair is about to commence on node B for an LSP that has only requested link protection, meaning B has not initiated the backup LSP signaling for the LSP. If node B receives a normal PathTear at this time from ingress A because of a management event initiated on A, then B simply deletes the LSP state without sending a Remote PathTear to the LP-MP C. So C may end up holding on to the stale state until the (long) refresh timeout. 🥺

5. Security Considerations 💀

The security considerations for the original RSVP protocol ([RFC2205], [RFC3209], and [RFC5920]) still apply, and they are NOT optional vibes, bestie 🔒 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. Pick the strong ones!

This document extends the applicability of Node-ID-based Hello sessions between immediate neighbors. The Node-ID-based Hello session between the PLR and the NP-MP may require the two routers to exchange Hello messages with a non-immediate neighbor. So the implementations SHOULD provide the option to configure either a specific neighbor or a global Node-ID authentication key to authenticate messages received from Node-ID neighbors. The network administrator SHOULD utilize this option to enable RSVP-TE routers to authenticate Node-ID Hello messages received with a TTL greater than 1. Implementations SHOULD also provide the option to specify a limit on the number of Node-ID-based Hello sessions that can be established on a router supporting the extensions defined in this document. Lock it down! 🔥

6. IANA Considerations 🌈

6.1. CONDITIONS Object 🎀

IANA maintains the "Class Names, Class Numbers, and Class Types" registry in the "RSVP Parameters" registry group (see http://www.iana.org/assignments/rsvp-parameters/). IANA has extended these registries by adding a new Class Number (in the 10bbbbbb range) and assigning a new C-Type under this Class Number, as described below (see Section 4.4.3). New Class Type values for Class Name "CONDITIONS" can be added via "IETF Review" [RFC8126]. 📋

              +==============+============+===========+
              | Class Number | Class Name | Reference |
              +==============+============+===========+
              | 135          | CONDITIONS | RFC 9705  |
              +--------------+------------+-----------+

                 Table 1: Class Names, Class Numbers,
                           and Class Types

                 +=======+=============+===========+
                 | Value | Description | Reference |
                 +=======+=============+===========+
                 | 1     | CONDITIONS  | RFC 9705  |
                 +-------+-------------+-----------+

                   Table 2: Class Types or C-Types
                           - 135 CONDITIONS

IANA has added a subregistry called "CONDITIONS Object Flags" as shown below. New registrations can be added via "IETF Review" [RFC8126]. 🦋

       +============+==============+=============+===========+
       | Bit Number | 32-Bit Value | Name        | Reference |
       +============+==============+=============+===========+
       | 0-30       |              | Unassigned  |           |
       +------------+--------------+-------------+-----------+
       | 31         | 0x0001       | Merge-point | RFC 9705  |
       +------------+--------------+-------------+-----------+

                   Table 3: CONDITIONS Object Flags

7. References 📚

7.1. Normative References 📚

okay bestie, this is the receipts section 🧾✨ these are the RFCs you need to have read before this one makes any sense, no cap 💅

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119,
           DOI 10.17487/RFC2119, March 1997,
           <https://www.rfc-editor.org/info/rfc2119>.

[RFC2205]  Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
           Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
           Functional Specification", RFC 2205, DOI 10.17487/RFC2205,
           September 1997, <https://www.rfc-editor.org/info/rfc2205>.

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

[RFC2961]  Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F.,
           and S. Molendini, "RSVP Refresh Overhead Reduction
           Extensions", RFC 2961, DOI 10.17487/RFC2961, April 2001,
           <https://www.rfc-editor.org/info/rfc2961>.

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

[RFC3473]  Berger, L., Ed., "Generalized Multi-Protocol Label
           Switching (GMPLS) Signaling Resource ReserVation Protocol-
           Traffic Engineering (RSVP-TE) Extensions", RFC 3473,
           DOI 10.17487/RFC3473, January 2003,
           <https://www.rfc-editor.org/info/rfc3473>.

[RFC4090]  Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast
           Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
           DOI 10.17487/RFC4090, May 2005,
           <https://www.rfc-editor.org/info/rfc4090>.

[RFC4558]  Ali, Z., Rahman, R., Prairie, D., and D. Papadimitriou,
           "Node-ID Based Resource Reservation Protocol (RSVP) Hello:
           A Clarification Statement", RFC 4558,
           DOI 10.17487/RFC4558, June 2006,
           <https://www.rfc-editor.org/info/rfc4558>.

[RFC5063]  Satyanarayana, A., Ed. and R. Rahman, Ed., "Extensions to
           GMPLS Resource Reservation Protocol (RSVP) Graceful
           Restart", RFC 5063, DOI 10.17487/RFC5063, October 2007,
           <https://www.rfc-editor.org/info/rfc5063>.

[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/info/rfc8126>.

[RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
           2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
           May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8370]  Beeram, V., Ed., Minei, I., Shakir, R., Pacella, D., and
           T. Saad, "Techniques to Improve the Scalability of RSVP-TE
           Deployments", RFC 8370, DOI 10.17487/RFC8370, May 2018,
           <https://www.rfc-editor.org/info/rfc8370>.

[RFC8796]  Taillon, M., Saad, T., Ed., Gandhi, R., Deshmukh, A.,
           Jork, M., and V. Beeram, "RSVP-TE Summary Fast Reroute
           Extensions for Label Switched Path (LSP) Tunnels",
           RFC 8796, DOI 10.17487/RFC8796, July 2020,
           <https://www.rfc-editor.org/info/rfc8796>.

7.2. Informative References 🌸

these ones are the extra reading, the "ooh tell me more" section 🧚 they're not required to get the main vibe, but they're so worth a look

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

[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/info/rfc2104>.

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

Acknowledgements 🫶

okay the thank-yous are so sweet 🥹 we're so grateful to Yakov Rekhter for sharing the idea and for reviewing the whole document super thoroughly 🙌 huge thanks also to Raveendra Torvi and Yimin Shen for their comments and inputs on the early versions, and to Alexander Okonnikov for reviewing and commenting on the document 💜

Contributors 💜

these are the girlies who helped build it, with their affiliations and emails 🦋

Ina Minei
Google, Inc.
Email: inaminei@google.com


Markus Jork
Juniper Networks, Inc.
Email: mjork@juniper.net


Harish Sitaraman
Individual Contributor
Email: harish.ietf@gmail.com


Vishnu Pavan Beeram
Juniper Networks, Inc.
Email: vbeeram@juniper.net


Ebben Aries
Juniper Networks, Inc.
Email: exa@juniper.com


Mike Taillon
Cisco Systems, Inc.
Email: mtaillon@cisco.com

Authors' Addresses 🦋

and these are the authors, so you know exactly who to slide into the DMs 🫶💅

Chandra Ramachandran
Juniper Networks, Inc.
Email: csekar@juniper.net


Tarek Saad
Cisco Systems, Inc.
Email: tsaad@cisco.com


Dante Pacella
Verizon, Inc.
Email: dante.j.pacella@verizon.com
📦 where this page comes from