RFC 8577

Signaling RSVP-TE Tunnels on a Shared MPLS Forwarding Plane

📅 published April 2019, from ietf

Signaling RSVP-TE Tunnels on a Shared MPLS Forwarding Plane 🦋

okay bestie, this is RFC 8577, a Standards Track doc from the IETF (the group that writes the rules for how the internet talks to itself 🌐). It was published in April 2019 and its ISSN is 2070-1721. The authors are H. Sitaraman and V. Beeram from Juniper Networks, T. Parikh from Verizon, and T. Saad from Cisco Systems. It's a proper standard, not just an idea someone had in the shower 💅. The header doesn't list any Obsoletes or Updates entries, so nothing gets replaced or patched by it (at least not according to that header 🙈).

Abstract ✨

so the problem is that RSVP-TE networks keep getting bigger 📈, and that means more Label Switched Paths (LSPs) on each router. People have already come up with ways to handle the control-plane state (the stuff the router remembers about its paths) 🧠. But none of that touches the number of labels a transit Label Switching Router (LSR) has to hold in its forwarding plane, and that number is tied to how many LSPs pass through or end at the router. Ugh, the real bottleneck 😭.

this doc fixes that by letting the label space stop being the limit on control-plane scaling. It brings in preinstalled 'per-TE link labels' that many RSVP-TE LSPs can share when they cross the same TE links 🫶. The forwarding-plane state drops a lot, so a huge pile of LSPs fits. And it basically mixes what's good about RSVP-TE's control plane with the simplicity of the Segment Routing (SR) MPLS forwarding plane. It's giving smart and efficient 🔥.

Status of This Memo ✨

this is an Internet Standards Track document 💖.

It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG) 👑. For more on Internet Standards, check Section 2 of RFC 7841.

Info about the current status, any errata, and how to send feedback lives at https://www.rfc-editor.org/info/rfc8577 🌸.

Copyright (c) 2019 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 in effect on the date it was published. Please actually read these, because they spell out your rights and restrictions for this doc 🙏. Code Components pulled out of this document must include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Simplified BSD License says.

Table of Contents 📚

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
  2.1.  Requirements Language . . . . . . . . . . . . . . . . . .   6
3.  Allocation of TE Link Labels  . . . . . . . . . . . . . . . .   6
4.  Segment Routed RSVP-TE Tunnel Setup . . . . . . . . . . . . .   6
5.  Delegating Label Stack Imposition . . . . . . . . . . . . . .   8
  5.1.  Stacking at the Ingress . . . . . . . . . . . . . . . . .   8
    5.1.1.  Stack to Reach Delegation Hop . . . . . . . . . . . .   9
    5.1.2.  Stack to Reach Egress . . . . . . . . . . . . . . . .  10
  5.2.  Explicit Delegation . . . . . . . . . . . . . . . . . . .  11
  5.3.  Automatic Delegation  . . . . . . . . . . . . . . . . . .  11
    5.3.1.  Effective Transport Label-Stack Depth (ETLD)  . . . .  11
6.  Mixing TE Link Labels and Regular Labels in an RSVP-TE Tunnel  13
7.  Construction of Label Stacks  . . . . . . . . . . . . . . . .  14
8.  Facility Backup Protection  . . . . . . . . . . . . . . . . .  14
  8.1.  Link Protection . . . . . . . . . . . . . . . . . . . . .  14
9.  Protocol Extensions . . . . . . . . . . . . . . . . . . . . .  15
  9.1.  Requirements  . . . . . . . . . . . . . . . . . . . . . .  15
  9.2.  Attribute Flags TLV: TE Link Label  . . . . . . . . . . .  16
  9.3.  RRO Label Sub-object Flag: TE Link Label  . . . . . . . .  16
  9.4.  Attribute Flags TLV: LSI-D  . . . . . . . . . . . . . . .  16
  9.5.  RRO Label Sub-object Flag: Delegation Label . . . . . . .  17
  9.6.  Attributes Flags TLV: LSI-D-S2E . . . . . . . . . . . . .  17
  9.7.  Attributes TLV: ETLD  . . . . . . . . . . . . . . . . . .  18
10. OAM Considerations  . . . . . . . . . . . . . . . . . . . . .  18
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  19
  11.1.  Attribute Flags: TE Link Label, LSI-D, LSI-D-S2E . . . .  19
  11.2.  Attribute TLV: ETLD  . . . . . . . . . . . . . . . . . .  19
  11.3.  Record Route Label Sub-object Flags: TE Link Label,
         Delegation Label . . . . . . . . . . . . . . . . . . . .  20
  11.4.  Error Codes and Error Values . . . . . . . . . . . . . .  20
12. Security Considerations . . . . . . . . . . . . . . . . . . .  20
13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  21
  13.1.  Normative References . . . . . . . . . . . . . . . . . .  21
  13.2.  Informative References . . . . . . . . . . . . . . . . .  22
Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  23
Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  23
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  24

1. Introduction 🌈

okay so RSVP-TE [RFC3209] control planes can get way better at scaling if you follow the guidelines and mechanisms in [RFC2961] and [RFC8370] 💅. But those docs don't change the forwarding-plane state, which stays the same and grows in direct proportion to the total number of Label Switched Paths (LSPs) the control plane supports. Not ideal, bestie 😬.

this doc describes a mechanism that stops the size of the platform-specific label space on a Label Switching Router (LSR) from being the thing that holds back how far control-plane scaling can go on that node 🚀.

the big idea is preinstalled 'per-TE link labels' that an LSR allocates 🧚. Each one is installed in the MPLS forwarding plane with a 'pop' operation, plus an instruction to forward the packet over the TE link. The LSR advertises the label in the Label object of a Resv message as LSPs get set up. The labels also get recorded hop by hop in the Record Route Object (RRO) of the Resv message as it moves through the network. Then the ingress Label Edge Router (LER) builds and pushes a stack of labels [RFC3031] using the labels it got from the RRO. These 'TE link labels' can be shared by any MPLS RSVP-TE LSPs that cross the same TE link. It's so clean 😭✨.

this forwarding-plane behavior fits into the MPLS architecture [RFC3031]. It matches what you get from Segment Routing (SR) [RFC8402] when you use an MPLS forwarding plane and a series of adjacency segments [SEG-ROUTING]. So this work basically pairs the feature benefits of the RSVP-TE control plane with the simplicity of the SR MPLS forwarding plane 💜.

RSVP-TE on a shared MPLS forwarding plane gives you these benefits:

  1. Shared labels: The transit label on a TE link is shared among the RSVP-TE tunnels that traverse the link, and it's used no matter what the ingress and egress of the LSPs are 🦋.
  2. Faster LSP setup time: No forwarding-plane state has to be programmed during LSP setup and teardown, so LSPs get provisioned and deprovisioned faster 🏃‍♀️💨.
  3. Hitless rerouting: New transit labels aren't needed during make-before-break (MBB) when the new LSP instance takes the exact same path as the old one. That saves the ingress LER and the services using the tunnel from having to update the forwarding plane with new tunnel labels, so MBB events are faster too 🌸. MBB events happen pretty often in networks that use the 'auto-bandwidth' feature on RSVP-TE LSPs, which monitors bandwidth use and adjusts LSP bandwidth on a schedule ⏰.
  4. Mix-and-match labels: Both 'TE link labels' and regular labels can be used on transit hops for one RSVP-TE tunnel (see Section 6). That keeps things backward compatible with transit LSRs that hand out regular labels in Resv messages 🫶.

No extra routing protocol extensions are needed to support things like bandwidth admission control, LSP priorities, preemption, and auto-bandwidth on this shared MPLS forwarding plane 🙌. This doc also talks about how Fast Reroute [RFC4090] via facility backup link protection, using regular bypass tunnels, can work on this forwarding plane 🛡️.

the signaling procedures and extensions in this document do not apply to Point to Multipoint (P2MP) RSVP-TE tunnels. so don't try it there, bestie 🙅‍♀️.

2. Terminology 🍓

these are the terms used in this document:

TE link label: an incoming label at an LSR that the LSR pops, with the packet then forwarded over a specific outgoing TE link to a neighbor.

Shared MPLS forwarding plane: an MPLS forwarding plane where every participating LSR uses TE link labels on every LSP.

Segment Routed RSVP-TE tunnel: an MPLS RSVP-TE tunnel that asks for a shared MPLS forwarding plane at every hop of the LSP. The matching LSPs are called "Segment Routed RSVP-TE LSPs" 💅.

Delegation hop: a transit hop of a Segment Routed RSVP-TE LSP that gets picked to help impose the label stack in situations where the ingress LER can't impose the full label stack by itself. A Segment Routed RSVP-TE LSP can have more than one delegation hop along its path 🌟.

Delegation label: a label assigned at the delegation hop to represent a set of labels that will get pushed at that hop 🎀.

2.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. so if they're not in all caps, they're just regular words, no cap 🙃.

An LSR that takes part in a shared MPLS forwarding plane MUST allocate a unique TE link label for each TE link. When an LSR sees a TE link label at the top of the label stack, it MUST pop the label and forward the packet over the TE link to the downstream neighbor on the RSVP-TE tunnel. that's the core rule, periodt 💅✨.

Multiple TE link labels MAY be allocated for the TE link to accommodate tunnels that request protection 🛡️.

Implementations that keep per-label bandwidth accounting at each hop must aggregate the reservations made for all the LSPs using the shared TE link label. this is a big one for the bookkeeping, bestie 📊💜.

4. Segment Routed RSVP-TE Tunnel Setup 🎀

okay so this section walks through how RSVP-TE signaling works when you set up a tunnel on a shared MPLS forwarding plane 🦋. We're using this sample topology to explain it, and the numbers at each node are TE link labels. When one of those labels is on top of the stack, it means "pop me and send the packet out on the TE link to the neighbor" 💅

    +---+100  +---+150  +---+200  +---+250  +---+
    | A |-----| B |-----| C |-----| D |-----| E |
    +---+     +---+     +---+     +---+     +---+
      |110      |450      |550      |650      |850
      |         |         |         |         |
      |         |400      |500      |600      |800
      |       +---+     +---+     +---+     +---+
      +-------| F |-----|G  |-----|H  |-----|I  |
              +---+300  +---+350  +---+700  +---+

Figure 1: Sample Topology -- TE Link Labels

Let's look at two tunnels 👀

  • RSVP-TE tunnel T1: from A to E on path A-B-C-D-E
  • RSVP-TE tunnel T2: from F to E on path F-B-C-D-E

Both of them share the TE links B-C, C-D, and D-E, so they're basically sisters 🫶

RSVP-TE gets used to signal tunnel T1 (using the TE link label attributes flag defined in Section 9.2). When LSR D gets the Resv message from the egress LER E, it checks the next-hop TE link (D-E) and hands over the TE link label (250) in the Resv message for the tunnel, putting the label value in the Label object. It also gives the TE link label (250) in the Label sub-object carried in the RRO, and it sets the TE link label flag as defined in Section 9.3. ✨

Same energy from the others! LSR C provides the TE link label (200) for TE link C-D, and LSR B provides the TE link label (150) for TE link B-C 🌸

For tunnel T2, the transit LSRs hand out the same TE link labels they gave for T1, since the links B-C, C-D, and D-E are common to both LSPs. Efficient and iconic 💜

The ingress LERs (A and F) push the same stack of labels (from top of stack to bottom of stack) {150, 200, 250} for tunnels T1 and T2, respectively 🧚

Worth noting: a transit LSR does not swap the top TE link label on an incoming packet (the label it advertised in the Resv message it sent). All it has to do is pop the top label and forward the packet. Literally that's it 😭

The values in the Label sub-objects in the RRO are what the ingress LERs care about when they build the label stack to impose on packets 🍓

Now say there's another tunnel T3 from F to I on path F-B-C-D-E-I. It would also share TE links B-C, C-D, and D-E, and it traverses link E-I. The label stack used by F would be {150, 200, 250, 850}. So no matter where the LSPs start and end, they share labels at the shared hops in the shared MPLS forwarding plane. Main character energy for the whole forwarding plane 👑

There MAY be a local operator policy at the ingress LER that affects the maximum depth of the label stack that can be pushed for a Segment Routed RSVP-TE tunnel. Before signaling the LSP, the ingress LER may figure out that it can't push a label stack with one label per hop along the path. Sometimes the ingress LER doesn't have enough info to make that call at all. In those cases, the LER SHOULD adopt the techniques described in Section 5. 🫶

5. Delegating Label Stack Imposition 🦋

One or more transit LSRs can help the ingress LER out by imposing part of the label stack the path needs, like a group project where everyone does a piece 🧚 Take the example in Figure 2: there's an RSVP-TE tunnel from A to L on path A-B-C-D-E-F-G-H-I-J-K-L. The LSP is too long for LER A to impose the full stack by itself, so it gets help from delegation hops LSR D and LSR I, who each impose parts of the stack 💅

Each delegation hop allocates a delegation label to stand in for a set of labels that will get pushed at that hop. When a packet shows up at a delegation hop LSR with a delegation label, the LSR pops that label, pushes a set of labels, and then forwards the packet 🌈

                                   1250d
    +---+100p  +---+150p  +---+200p  +---+250p  +---+300p  +---+
    | A |------| B |------| C |------| D |------| E |------| F |
    +---+      +---+      +---+      +---+      +---+      +---+
                                                             |350p
                                                             |
                                   1500d                     |
    +---+  600p+---+  550p+---+  500p+---+  450p+---+  400p+---+
    | L |------| K |------| J |------| I |------| H |------+ G +
    +---+      +---+      +---+      +---+      +---+      +---+

           Notation: <Label>p - TE link label
                      <Label>d - Delegation label

                Figure 2: Delegating Label Stack Imposition

Figure 2: Delegating Label Stack Imposition

5.1. Stacking at the Ingress 💖

When delegation labels are involved, the ingress can pick between two stacking approaches. Section 7 explains how the label stack can be built 🎀

5.1.1. Stack to Reach Delegation Hop 🧁

In this approach, the stack the ingress pushes carries a set of labels that will take the packet to the first delegation hop. Here, the set of labels represented by a delegation label at a given delegation hop includes the matching delegation label from the next delegation hop. That means this delegation label can only be shared among LSPs that go to the same egress and traverse the same downstream path. Very exclusive, very specific 🙈

Figure 3 shows this approach. The delegation label 1250 stands for the stack {300, 350, 400, 450, 1500}, and the delegation label 1500 stands for the label stack {550, 600}.

    +---+               +---+               +---+
    | A |-----.....-----| D |-----.....-----| I |-----.....
    +---+               +---+               +---+

                   Pop 1250 &           Pop 1500 &
     Push                Push                Push
    ......              ......              ......
    : 150:        1250->: 300:        1500->: 550:
    : 200:              : 350:              : 600:
    :1250:              : 400:              ......
    ......              : 450:
                        :1500:
                        ......

Figure 3: Stack to Reach Delegation Hop

With this approach, the ingress LER A pushes {150, 200, 1250} for the tunnel in Figure 2. At LSR D, the delegation label 1250 gets popped, and {300, 350, 400, 450, 1500} gets pushed. At LSR I, the delegation label 1500 gets popped, and the remaining set of labels {550, 600} gets pushed. Stack handoff, slay 💅

5.1.2. Stack to Reach Egress 🌸

In this approach, the stack the ingress pushes carries a set of labels that takes the packet all the way to the egress, so all the delegation labels are part of the stack. Here, the set of labels represented by a delegation label at a given delegation hop does not include the matching delegation label from the next delegation hop. So this delegation label can be shared by all LSPs that traverse the segment between the two delegation hops 🦋

The downside is that the number of hops the LSP can traverse is limited by the label stack push limit of the ingress 😭

Figure 4 shows this approach. The delegation label 1250 stands for the stack {300, 350, 400, 450}, and the delegation label 1500 stands for the label stack {550, 600}.

    +---+               +---+               +---+
    | A |-----.....-----| D |-----.....-----| I |-----.....
    +---+               +---+               +---+

                   Pop 1250 &           Pop 1500 &
     Push                Push                Push
    ......              ......              ......
    : 150:        1250->: 300:        1500->: 550:
    : 200:              : 350:              : 600:
    :1250:              : 400:              ......
    :1500:              : 450:
    ......              ......
                        |1500|
                        ......

Figure 4: Stack to Reach Egress

With this approach, the ingress LER A pushes {150, 200, 1250, 1500} for the tunnel in Figure 2. At LSR D, the delegation label 1250 gets popped, and {300, 350, 400, 450} gets pushed. At LSR I, the delegation label 1500 gets popped, and the remaining set of labels {550, 600} gets pushed. The signaling extension the ingress needs to indicate which stacking approach it picked is defined in Section 9.6. 🎀

5.2. Explicit Delegation 👑

In this delegation option, the ingress LER can explicitly delegate one or more specific transit LSRs to handle pushing labels for a certain number of their downstream hops. To pick the delegation hops accurately, the ingress needs to know the label stack depth push limit (the total number of MPLS labels that can be imposed, including all service/transport/special labels) of each transit LSR before it starts the signaling sequence. How the ingress or the controller (the one hosting the path computation element) learns that info is outside the scope of this document. The Base MPLS Imposition MSD (BMI-MSD) advertisement, specified in [RFC8491], is an example of such a mechanism. 🧠

The signaling extension the ingress LER needs to explicitly delegate one or more specific transit hops is defined in Section 9.4. The extension the delegation hop needs to indicate that the recorded label is a delegation label is defined in Section 9.5. 💖

5.3. Automatic Delegation 🧚

In this approach, the ingress LER lets the downstream LSRs automatically pick suitable delegation hops during the initial signaling sequence. The ingress doesn't need to know up front the label stack depth push limit of each transit LSR. This approach SHOULD be used if there are loose hops [RFC3209] in the explicit route. The delegation hops get picked based on a per-hop signaled attribute called the Effective Transport Label-Stack Depth (ETLD), which we'll get into in the next section 🌈

5.3.1. Effective Transport Label-Stack Depth (ETLD) 🧚

okay so the ETLD gets signaled as a per-hop recorded attribute in the Path message [RFC7570]. Think of it as a little countdown ⏳. When automatic delegation is requested, the ingress MUST populate the ETLD with the maximum number of transport labels that it can potentially send to its downstream hop. Then that value gets decremented at each successive hop. 💅

If a node is reached and it's determined that this hop cannot support automatic delegation, then it MUST NOT use TE link labels and uses regular labels instead. 🙈 If a node is reached where the ETLD set from the previous hop is 1, then that node MUST select itself as the delegation hop. Same vibe if a node is reached and it's determined that this hop cannot receive more than one transport label: that node MUST select itself as the delegation hop. 🦋

If there's a node, or a sequence of nodes, along the path of the LSP that don't support ETLD, then the immediate hop that does support ETLD MUST select itself as the delegation hop. 🫶 The ETLD MUST be decremented at each non-delegation transit hop by either 1 or some appropriate number based on the local policy. For example, picture a transit node with a local policy that tells it to take the label stack read limit into account when decrementing the ETLD. With that policy, the ETLD is decremented in a way that the transit hop never gets more labels in the stack than it can read. Iconic behavior, honestly 👑

At each delegation hop, the ETLD MUST be reset to the maximum number of transport labels that the hop can send, and the ETLD decrements start all over again at each successive hop until either a new delegation hop is selected or the egress is reached. So by the time the Path message reaches the egress, all delegation hops are selected. ✨ During the Resv processing, at each delegation hop, a suitable delegation label is selected (either an existing label gets reused or a new label is allocated) and recorded in the Resv message. 🎀

Let's look at Figure 5. Say ingress LER A can push up to three transport labels, while the remaining nodes can push up to five. Ingress LER A signals the initial Path message with ETLD set to 3. The ETLD value gets adjusted at each successive hop and signaled downstream, as shown. By the time the Path message reaches egress LER L, LSRs D and I are automatically selected as delegation hops. 🌸

          ETLD:3    ETLD:2    ETLD:1    ETLD:5    ETLD:4
          ----->    ----->    ----->    ----->    ----->
                                    1250d
      +---+100p +---+150p +---+200p +---+250p +---+300p +---+
      | A |-----| B |-----| C |-----| D |-----| E |-----| F |  ETLD:3
      +---+     +---+     +---+     +---+     +---+     +---+    |
                                                          |350p  |
                                                          |      |
                                    1500d                 |      |
      +---+ 600p+---+ 550p+---+ 500p+---+ 450p+---+ 400p+---+    v
      | L |-----| K |-----| J |-----| I |-----| H |-----+ G +
      +---+     +---+     +---+     +---+     +---+     +---+

          ETLD:3    ETLD:4    ETLD:5    ETLD:1    ETLD:2
          <-----    <-----    <-----    <-----    <-----

                              Figure 5: ETLD

When an LSP that requests automatic delegation also requests facility backup protection [RFC4090], the ingress or the delegation hop MUST account for the bypass tunnel's label(s) when populating the ETLD. 🔥 So when a regular bypass tunnel is used to protect the facility, the ETLD populated on these nodes is one less than what gets populated for a corresponding unprotected LSP. 🧠

The signaling extension for the ingress LER to request automatic delegation is defined in Section 9.4. The extension for signaling the ETLD is defined in Section 9.7. The extension the delegation hop needs in order to indicate that the recorded label is a delegation label is defined in Section 9.5. 💜

Labels can be mixed across transit hops in a single MPLS RSVP-TE LSP. ✨ Certain LSRs can use TE link labels while others use regular labels. The ingress can construct a label stack appropriately based on what type of label is recorded from every transit LSR. 💅

                             (#)       (#)
    +---+100  +---+150  +---+200  +---+250  +---+
    | A |-----| B |-----| C |-----| D |-----| E |
    +---+     +---+     +---+     +---+     +---+
      |110      |450      |550      |650      |850
      |         |         |         |         |
      |         |400      |500      |600      |800
      |       +---+     +---+     +---+     +---+
      +-------| F |-----|G  |-----|H  |-----|I  |
              +---+300  +---+350  +---+700  +---+

            Notation: (#) denotes regular labels
                       Other labels are TE link labels

      Figure 6: Sample Topology -- TE Link Labels and Regular Labels

If the transit LSR allocates a regular label to be sent upstream in the Resv, then the label operation at the LSR is a swap to the label received from the downstream LSR. 🔄 If the transit LSR is using a TE link label to be sent upstream in the Resv, then the label operation at the LSR is a pop and forward, regardless of any label received from the downstream LSR. 🦋 There's no change in the behavior of a penultimate hop popping (PHP) LSR [RFC3031]. 🌈

Section 7 explains how the label stack can be constructed. For example, the LSP from A to I using path A-B-C-D-E-I will use a label stack of {150, 200}. 🧚

7. Construction of Label Stacks 🧱

The ingress LER or delegation hop MUST check the type of label received from each transit hop, as recorded in the RRO in the Resv message, and generate the appropriate label stack to reach the next delegation hop or the egress. 👑

The following logic is used by the node constructing the label stack:

  • Each RRO label sub-object MUST be processed starting with the label sub-object from the first downstream hop. 🎀
  • Any label provided by the first downstream hop MUST always be pushed on the label stack, regardless of the label type.
  • If the label type is a TE link label, then any label from the next downstream hop MUST also be pushed on the constructed label stack. 🦋
  • If the label type is a regular label, then any label from the next downstream hop MUST NOT be pushed on the constructed label stack. 🙅‍♀️
  • If the label type is a delegation label, then the type of stacking approach chosen by the ingress for this LSP (Section 5.1) MUST be used to determine how the delegation labels are pushed in the label stack. 💖

8. Facility Backup Protection 🛡️

The following section describes how link protection works with facility backup protection [RFC4090], using regular bypass tunnels for the Segment Routed RSVP-TE tunnels. 🌸 The procedures for supporting node protection are not discussed in this document. The use of Segment Routed bypass tunnels for providing facility protection is left for further study. 🔭

To provide link protection at a Point of Local Repair (PLR) with a shared MPLS forwarding plane, the LSR MUST allocate a separate TE link label for the TE link that will be used for RSVP-TE tunnels that request link protection from the ingress. ✨ No signaling extensions are required to support link protection for RSVP-TE tunnels over the shared MPLS forwarding plane. 🫶

At each LSR, link-protected TE link labels can be allocated for each TE link, and a link-protecting facility backup LSP can be created to protect the TE link. The link-protected TE link label can be sent by the LSR for LSPs requesting link protection over the specific TE link. Since the facility backup terminates at the next hop (merge point), the incoming label on the packet will be what the merge point expects. 💅

Consider the network shown in Figure 7. LSR B can install a facility backup LSP for the link-protected TE link label 151. When the TE link B-C is up, LSR B will pop 151 and send the packet to C. If the TE link B-C is down, the LSR can pop 151 and send the packet via the facility backup to C. 🛟

         101(*)     151(*)     201(*)     251(*)
    +---+100   +---+150   +---+200   +---+250   +---+
    | A |------| B |------| C |------| D |------| E |
    +---+      +---+      +---+      +---+      +---+
      |110       |450       |550       |650       |850
      |          |          |          |          |
      |          |400       |500       |600       |800
      |        +---+      +---+      +---+      +---+
      +--------| F |------|G  |------|H  |------|I  |
               +---+300   +---+350   +---+700   +---+

     Notation: (*) denotes link-protected TE link labels

                    Figure 7: Link Protection Topology

9. Protocol Extensions 🧩

9.1. Requirements 📋

The functionality discussed in this document imposes the following requirements on the signaling protocol. 💖

  • The ingress of the LSP needs to have the ability to mandate/request the use and recording of TE link labels at all hops along the path of the LSP.
  • When the use of TE link labels is mandated/requested for the path:
    • the node recording the TE link label needs to have the ability to indicate whether the recorded label is a TE link label.
    • the ingress needs to have the ability to delegate label stack imposition by:
      • explicitly mandating specific hops to be delegation hops, or
      • requesting automatic delegation.
    • When explicit delegation is mandated or automatic delegation is requested:
      • the ingress needs to have the ability to indicate the chosen stacking approach, and
      • the delegation hop needs to have the ability to indicate that the recorded label is a delegation label. 🌈

Bit Number 16: TE Link Label

The presence of this flag in the LSP_ATTRIBUTES/LSP_REQUIRED_ATTRIBUTES object [RFC5420] of a Path message indicates that the ingress has requested/mandated the use and recording of TE link labels at all hops along the path of this LSP. 🦋 When a node that recognizes this flag but does not cater to the mandate because of local policy receives a Path message carrying the LSP_REQUIRED_ATTRIBUTES object with this flag set, it MUST send a PathErr message with an error code of 'Routing Problem (24)' and an error value of 'TE link label usage failure (70)'. 🚨 A transit hop that caters to this request/mandate MUST also check for the presence of other Attribute Flags introduced in this document (Sections 9.4 and 9.6) and process them as specified. 🔍 An ingress LER that sets this bit MUST also set the "label recording desired" flag [RFC3209] in the SESSION_ATTRIBUTE object. 🎀

Flag (0x02): TE Link Label

The presence of this flag indicates that the recorded label is a TE link label. This flag MUST be used by a node only if the use and recording of TE link labels are requested/mandated for the LSP. 💜

9.4. Attribute Flags TLV: LSI-D ✨

Bit Number 17: Label Stack Imposition - Delegation (LSI-D) 💖

Automatic Delegation: okay so if this flag shows up in the LSP_ATTRIBUTES object of a Path message, it means the ingress asked for automatic delegation of label stack imposition 💅. This flag MUST be set in the LSP_ATTRIBUTES object of a Path message only if the use and recording of TE link labels are requested/mandated for this LSP 🎀. If the transit hop doesn't support this flag, it MUST NOT use TE link labels and will use regular labels instead. And if the use of TE link labels was mandated in the LSP_REQUIRED_ATTRIBUTES object, it MUST send a PathErr message with an error code of 'Routing Problem (24)' and an error value of 'TE link label usage failure (70)'. Bestie, that's a whole meltdown moment 😭

Explicit Delegation: this one lives in the HOP_ATTRIBUTES sub-object [RFC7570] of an Explicit Route Object (ERO) in the Path message 🧚. When it's there, it says the hop identified by the preceding IPv4 or IPv6 or Unnumbered Interface ID sub-object was picked as an explicit delegation hop 🦋. The HOP_ATTRIBUTES sub-object carrying this flag MUST have the R (Required) bit set. This flag MUST be set in the HOP_ATTRIBUTES sub-object of an ERO object in the Path message only if the use and recording of TE link labels are requested/mandated for this LSP. If the hop recognizes this flag but can't comply with the mandate because of local policy, it MUST send a PathErr message with an error code of 'Routing Problem (24)' and an error value of 'Label stack imposition failure (71)'. Not the vibe being rejected by policy 💀

9.5. RRO Label Sub-object Flag: Delegation Label 🌸

Flag (0x04): Delegation Label

The presence of this flag tells you the recorded label is a delegation label 🍓. This flag MUST be used by a node only if the use and recording of TE link labels and delegation are requested/mandated for the LSP. Main character energy, but only when it's actually asked for 👑

9.6. Attributes Flags TLV: LSI-D-S2E 🌈

Bit Number 18: Label Stack Imposition - Delegation - Stack to Reach Egress (LSI-D-S2E)

The presence of this flag in the LSP_ATTRIBUTES object of a Path message means the ingress chose the "Stack to reach egress" approach for stacking 🦋. The absence of this flag in the LSP_ATTRIBUTES object of a Path message means the ingress chose the "Stack to reach delegation hop" approach instead ✨. This flag MUST be set in the LSP_ATTRIBUTES object of a Path message only if the use and recording of TE link labels and delegation are requested/mandated for this LSP. If the transit hop can't support the "Stack to reach egress" approach, it MUST send a PathErr message with an error code of 'Routing Problem (24)' and an error value of 'Label stack imposition failure (71)' 🙈

9.7. Attributes TLV: ETLD 💜

The ETLD Attributes TLV is laid out in Figure 8, and its Attribute TLV Type is 6 🧚

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Reserved                              |     ETLD      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 8: The ETLD Attributes TLV

When this TLV shows up in the HOP_ATTRIBUTES sub-object of an RRO object in the Path message, it says the hop identified by the preceding IPv4 or IPv6 or Unnumbered Interface ID sub-object supports automatic delegation 🫶. This attribute MUST be used only if the use and recording of TE link labels are requested/mandated and automatic delegation is requested for the LSP.

The ETLD field tells you the effective number of transport labels that this hop (based on where it sits in the path) can potentially send to its downstream hop 📈. It MUST be set to a non-zero value.

The Reserved field is saved for future specification ✨. It SHOULD be set to zero on transmission and MUST be ignored on receipt, so future versions stay compatible. Future-proofing is everything 💅

10. OAM Considerations 🔥

MPLS LSP ping and traceroute [RFC8029] are applicable for Segment Routed RSVP-TE tunnels 🦋. The existing procedures let the label stack imposed at a delegation hop get reported back in the Label Stack Sub-TLV in the MPLS echo reply for traceroute. Debugging, but make it iconic 🔍

11. IANA Considerations 🎀

IANA manages the 'Attribute Flags' subregistry as part of the 'Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Parameters' registry, located at <http://www.iana.org/assignments/ rsvp-te-parameters>. This document introduces three new Attribute Flags 🌸

Bit  Name              Attribute   Attribute  RRO ERO Reference
No                     Flags Path  Flags Resv

16   TE Link Label     Yes         No         No  No  [RFC8577],
                                                     Section 9.2

17   LSI-D             Yes         No         No  Yes [RFC8577],
                                                     Section 9.4

18   LSI-D-S2E         Yes         No         No  No  [RFC8577],
                                                     Section 9.6

11.2. Attribute TLV: ETLD

IANA manages the "Attribute TLV Space" registry as part of the 'Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Parameters' registry, located at <http://www.iana.org/assignments/ rsvp-te-parameters>. This document introduces a new Attribute TLV 🧚

Type  Name  Allowed on     Allowed on    Allowed on  Reference
            LSP_ATTRIBUTES LSP_REQUIRED  LSP Hop
                           _ATTRIBUTES   Attributes

6     ETLD      No               No         Yes       [RFC8577],
                                                      Section 9.7

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>. Before this document, this registry didn't include Label Sub-object Flags 🙃. This document adds a new subregistry for Label Sub-object Flags, shown below ✨

   Flag  Name                    Reference

   0x1   Global Label            [RFC3209]
   0x02  TE Link Label           [RFC8577], Section 9.3
   0x04  Delegation Label        [RFC8577], Section 9.5

11.4. 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" 📚. Inside that subregistry is a definition of the "Routing Problem" Error Code (24). The definition lists a number of error values that can be used with this error code. IANA has allocated further error values for use with this Error Code, as described in this document. The resulting entry in the registry looks like this 💖

   24  Routing Problem                             [RFC3209]

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

    70 = TE link label usage failure        [RFC8577]
    71 = Label stack imposition failure     [RFC8577]

12. Security Considerations 🚨

This document does not introduce new security issues 🛡️. The security considerations pertaining to the original RSVP protocol [RFC2205] and RSVP-TE [RFC3209], and those described in [RFC5920], remain relevant. Okay, so this isn't a new threat, but the old ones are still very much on the table, so keep your guard up 🔐 No cap, don't skip this part 💀

13. References 📖

13.1. Normative References

13.2. Informative References

Acknowledgements 🙏✨

okay bestie, the authors wanna give a huge shoutout to Adrian Farrel, Kireeti Kompella, Markus Jork, and Ross Callon for their input from discussions 🫶 Adrian Farrel also reviewed the draft and suggested text that made things way clearer and easier to read 💅

Contributors 🌸

these people contributed to this document, periodt:

Raveendra Torvi
Juniper Networks
Email: rtorvi@juniper.net

Chandra Ramachandran
Juniper Networks
Email: csekar@juniper.net

George Swallow
Email: swallow.ietf@gmail.com

Authors' Addresses 🦋

and here's where you can find the authors, who are lowkey all over Juniper, Verizon, and Cisco 💜

Harish Sitaraman
Juniper Networks
1133 Innovation Way
Sunnyvale, CA  94089
United States of America

Email: harish.ietf@gmail.com


Vishnu Pavan Beeram
Juniper Networks
10 Technology Park Drive
Westford, MA  01886
United States of America

Email: vbeeram@juniper.net


Tejal Parikh
Verizon
400 International Parkway
Richardson, TX  75081
United States of America

Email: tejal.parikh@verizon.com


Tarek Saad
Cisco Systems
2000 Innovation Drive
Kanata, Ontario  K2K 3E8
Canada

Email: tsaad.net@gmail.com
📦 where this page comes from