RFC 8320

LDP Extensions to Support Maximally Redundant Trees

📅 published February 2018, from ietf

LDP Extensions to Support Maximally Redundant Trees 🦋

okay bestie, this is RFC 8320 💖 It's a Standards Track doc from the IETF (ISSN 2070-1721), dated February 2018. A. Atlas, K. Tiruveedhula, and C. Bowers are the authors, with Bowers listed at Juniper Networks. J. Tantsura is writing as an individual, and IJ. Wijnands is at Cisco Systems, Inc. The title block doesn't list any RFCs that it obsoletes or updates 🧚

Abstract ✨

okay so this doc adds extensions to the Label Distribution Protocol (LDP) so you can set up Label Switched Paths (LSPs) for Maximally Redundant Trees (MRTs) 🌸 The big use case is unicast and multicast IP/LDP Fast Reroute, which the doc calls "MRT-FRR" 🔥

The only new protocol extension to LDP is the ability to advertise an MRT Capability 💅 The doc describes that extension and how Label Switching Routers (LSRs) and Label Edge Routers (LERs) are expected to behave when they advertise it 🫶

MRT-FRR uses the LDP multi-topology extensions, so three multi-topology IDs were allocated from the MPLS MT-ID space 👑

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 📚

For the current status, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc8320 ✨

Copyright (c) 2018 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 stand on the publication date. Please read these carefully, because they spell out your rights and restrictions 🙈 Any Code Components pulled out of this document must include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License describes 💀

Table of Contents 🍓

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   5
3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
4.  Overview of LDP Signaling Extensions for MRT  . . . . . . . .   6
  4.1.  MRT Capability Advertisement  . . . . . . . . . . . . . .   6
    4.1.1.  Interaction of MRT Capability and MT Capability . . .   7
    4.1.2.  Interaction of LDP MRT Capability with IPv4 and IPv6    8
  4.2.  Use of the Rainbow MRT MT-ID  . . . . . . . . . . . . . .   8
  4.3.  MRT-Blue and MRT-Red FECs . . . . . . . . . . . . . . . .   8
  4.4.  Interaction of MRT-Related LDP Advertisements with the
        MRT Topology and Computations . . . . . . . . . . . . . .   9
5.  LDP MRT FEC Advertisements  . . . . . . . . . . . . . . . . .  10
  5.1.  MRT-Specific Behavior . . . . . . . . . . . . . . . . . .  10
    5.1.1.  ABR Behavior and Use of the Rainbow FEC . . . . . . .  10
    5.1.2.  Proxy-Node Attachment Router Behavior . . . . . . . .  11
  5.2.  LDP Protocol Procedures in the Context of MRT Label
        Distribution  . . . . . . . . . . . . . . . . . . . . . .  12
    5.2.1.  LDP Peer in RFC 5036  . . . . . . . . . . . . . . . .  12
    5.2.2.  Next Hop in RFC 5036  . . . . . . . . . . . . . . . .  13
    5.2.3.  Egress LSR in RFC 5036  . . . . . . . . . . . . . . .  13
    5.2.4.  Use of Rainbow FEC to Satisfy Label Mapping Existence
            Requirements in RFC 5036  . . . . . . . . . . . . . .  15
    5.2.5.  Validating FECs in the Routing Table  . . . . . . . .  15
    5.2.6.  Recognizing New FECs  . . . . . . . . . . . . . . . .  15
    5.2.7.  Not Propagating Rainbow FEC Label Mappings  . . . . .  15
6.  Security Considerations . . . . . . . . . . . . . . . . . . .  16
7.  Potential Restrictions on MRT-Related MT-ID Values Imposed by
    RFC 6420  . . . . . . . . . . . . . . . . . . . . . . . . . .  16
8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  17
9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  18
  9.1.  Normative References  . . . . . . . . . . . . . . . . . .  18
  9.2.  Informative References  . . . . . . . . . . . . . . . . .  19
Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  21
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  21

1. Introduction ✨

this doc describes the LDP signaling extensions and the behavior needed to support the architecture for how IP/LDP Fast Reroute can use MRTs [RFC7812] 🦋 It gives a quick look at the MRT-FRR architecture, focused on the parts that matter most for LDP signaling. The full description and spec of MRT-FRR architecture is in [RFC7812] 📚

At least one common standardized algorithm is required to be deployed, so that routers computing MRTs all come up with the same MRTs. The MRT Lowpoint algorithm, explained and fully documented in [RFC7811], is one example 🧠 LDP depends on an IGP to compute MRTs and alternates. OSPF extensions are defined in [OSPF-MRT], and IS-IS extensions are defined in [IS-IS-MRT] 💅

MRT can also protect multicast traffic signaled via PIM or Multipoint LDP (mLDP), using either global protection or local protection as described in [ARCH] 🌸 An MRT path can give node protection for mLDP traffic through the mechanisms in [RFC7715], and an MRT path can also give link protection for mLDP traffic 🫶

For each destination, IP/LDP Fast Reroute with MRT (MRT-FRR) creates two alternate destination-based trees that are separate from the shortest-path forwarding used during stable operation 🔥 LDP uses the multi-topology extensions [RFC7307] to signal Forwarding Equivalency Classes (FECs) for these two sets of forwarding trees, MRT-Blue and MRT-Red 💙❤️

To create MRT paths and support IP/LDP Fast Reroute, LDP needs a new capability extension 👑 An LDP implementation that supports MRT MUST also follow the rules in this document for originating and managing MRT-related FECs, as indicated by their multi-topology ID 🎀 Network reconvergence is described in [RFC7812], and the worst-case network convergence time can be flooded via the extension in [PARAM-SYNC] ⏱️

IP/LDP Fast Reroute using MRTs can provide 100% coverage for link and node failures in an arbitrary network topology, as long as the failure doesn't partition the network 🤯 It can also be deployed incrementally. An MRT Island is made of connected supporting routers, and the MRTs are computed inside that island 🏝️

2. 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 💖

3. Terminology 📖

okay, some of the terms from [RFC7812] are repeated here so it's easier to read 🫶 For a fuller list, check Section 3 of [RFC7812] 🔍

Redundant Trees (RTs): a pair of trees where the path from any node X to the root R along the first tree is node-disjoint with the path from that same node X to the root along the second tree. Redundant trees can always be computed in 2-connected graphs 🌿

Maximally Redundant Trees (MRTs): a pair of trees where the path from any node X to the root R along the first tree and the path from that same node X to the root along the second tree share the minimum number of nodes and the minimum number of links. Each shared node is a cut-vertex, and any shared links are cut-links. In graphs that aren't 2-connected, RTs can't be computed, but MRTs can 🙌 They're maximally redundant in the sense that they're as redundant as possible given the constraints of the network graph ✨

MRT-Red: one of the two MRTs. It's used to describe the associated forwarding topology and MPLS Multi-Topology Identifier (MT-ID) ❤️

MRT-Blue: the other one of the two MRTs. It's used to describe the associated forwarding topology and MPLS MT-ID 💙

Rainbow MRT: it's handy to have an MPLS MT-ID that refers to the multiple MRT forwarding topologies and to the default forwarding topology. This is called the "Rainbow MRT MPLS MT-ID," and LDP uses it to reduce signaling and to allow the same label to always be advertised to all peers for the same (MT-ID, Prefix) 🌈

MRT Island: the set of routers that support a particular MRT Profile, plus the links connecting them that support MRT 🏝️

Island Border Router (IBR): a router in the MRT Island that is connected to a router outside the MRT Island, where both are in a common area or level 🚧

Island Neighbor (IN): a router that is not in the MRT Island but is adjacent to an IBR and in the same area/level as that IBR 👯

There are a few places in this document where the construction red(blue) FEC is used to cover the red FEC case and the blue FEC case, each on its own. For example, take this sentence: "When the ABR requires best-area behavior for a red(blue) FEC, it MUST withdraw any existing label mappings advertisements for the corresponding Rainbow FEC and advertise label mappings for the red(blue) FEC." You read it as applying to red FECs first, and then you read it again as applying to blue FECs 💅

4. Overview of LDP Signaling Extensions for MRT 🗺️

Routers need to know which of their LDP neighbors support MRT 👀 That's communicated through the MRT Capability Advertisement. Supporting MRT covers several different aspects of behavior, listed below 💜

  1. Sending and receiving multi-topology FEC elements, as defined in [RFC7307] 📬
  2. Understanding the Rainbow MRT MT-ID and applying the associated labels to all relevant MT-IDs 🌈
  3. Advertising the Rainbow MRT FEC to the appropriate neighbors for the appropriate prefix 📣
  4. If acting as LDP egress for a prefix in the default topology, also acting as egress for that same prefix in MRT-Red and MRT-Blue 🏁
  5. For a FEC learned from a neighbor that doesn't support MRT, originating FECs for MRT-Red and MRT-Blue with the same prefix. This MRT Island egress behavior supports an MRT Island that doesn't include all routers in the area/level 🏝️

okay that's the front half 🫶 more parts are coming, so don't go anywhere, bestie 💅✨

4.1. MRT Capability Advertisement 🎀

okay so the MRT Capability Parameter TLV is defined by following the LDP Capability definition guidelines in [RFC5561] 💖

The LDP MRT Capability can be advertised during LDP session initialization or after the LDP session is already up ✨ When it's advertised, it means the LSR supports the procedures for setting up the MRT-Blue and MRT-Red Label Switched Paths (LSPs) that are detailed in this document 🦋 If the peer hasn't advertised the MRT Capability, that tells you the LSR doesn't support MRT procedures 💀

If a router advertises the LDP MRT Capability to its peer but the peer hasn't advertised the MRT Capability, then the router MUST NOT advertise MRT-related FEC-label bindings to that peer 🙈 not the vibe, so don't do it!

Here's what the MRT Capability Parameter looks like 🧚

   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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |U|F| MRT Capability (0x050E)   |      Length (= 1)             |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |S| Reserved    |
  +-+-+-+-+-+-+-+-+

                      MRT Capability TLV Format

Here's what each piece does 💅

  • U-bit: The unknown TLV bit MUST be 1. A router that doesn't recognize the MRT Capability TLV will silently ignore it and process the rest of the message as if the unknown TLV never existed 🫶
  • F-bit: The forward unknown TLV bit MUST be 0, as required by Section 3 of [RFC5561] 🌸
  • MRT Capability: 0x050E ✨
  • Length: The length (in octets) of the TLV. Its value is 1 🍓
  • S-bit: The State bit MUST be 1 if it's used in the LDP Initialization message. It MAY be set to 0 or 1 in the dynamic Capability message to advertise or withdraw the capability, respectively, as described in [RFC5561] 🔥

4.1.1. Interaction of MRT Capability and MT Capability

okay this one is a big deal 😭 An LSR advertising the LDP MRT Capability MUST also advertise the LDP Multi-Topology (MT) Capability. If an LSR negotiates the LDP MRT Capability with an LDP neighbor without also negotiating the LDP MT Capability, the LSR MUST behave as if the LDP MRT Capability was not negotiated. It also responds with the "MRT Capability negotiated without MT Capability" status code in the LDP Notification message (defined in the document) 👑 The E-bit of this Notification should be set to 0 to show that it's an Advisory Notification. The LDP session SHOULD NOT be terminated, bestie, so don't nuke the whole session 🥺

4.1.2. Interaction of LDP MRT Capability with IPv4 and IPv6

the MRT LDP Capability Advertisement does not distinguish between IPv4 and IPv6 address families 🌈 An LSR that advertises the MRT LDP Capability is expected to advertise MRT-related FEC-label bindings for the same address families it advertises shortest-path FEC-label bindings for. So an LSR advertising the MRT LDP Capability and shortest-path FEC-label bindings for IPv4 only (or IPv6 only) would be expected to advertise MRT-related FEC-label bindings for IPv4 only (or IPv6 only) 🦋 And if an LSR advertises the MRT LDP Capability and shortest-path FEC-label bindings for BOTH IPv4 and IPv6, it's expected to advertise MRT-related FEC-label bindings for BOTH IPv4 and IPv6 too. In this scenario, advertising MRT-related FEC-label bindings only for IPv4 (or only for IPv6) is not supported. not it, periodt 💀✨

4.2. Use of the Rainbow MRT MT-ID 🌸

Section 10.1 of [RFC7812] describes why an Area Border Router (ABR) needs different neighbors to use different MPLS labels when they send traffic to the ABR for the same FEC 🧚 There's a more detailed discussion of the Rainbow MRT MT-ID in Section 5.1.1.

Another use for the Rainbow MRT MT-ID is for an LSR to send the Rainbow MRT MT-ID with an IMPLICIT_NULL label, which signals penultimate-hop-popping for all three types of FECs (shortest path, red, and blue) 💅 The EXPLICIT_NULL label advertised using the Rainbow MRT MT-ID applies to all types of FECs in the same way. Just know that advertising the implicit or explicit null label for all three FEC types is only really useful when the FEC refers to the LSR itself 👑 See Section 5.2.3 for more details.

The value of the Rainbow MRT MPLS MT-ID (3945) was assigned by IANA from the MPLS MT-ID space 🎀

4.3. MRT-Blue and MRT-Red FECs 🦋

To get MRT support in LDP, the MT Prefix FEC is used 💖 [RFC7812] defines the Default MRT Profile. Section 8 specifies the values in the "MPLS Multi-Topology Identifiers" registry for the MRT-Red and MRT-Blue MPLS MT-IDs associated with the Default MRT Profile (3946 and 3947) ✨

As described in Section 8.1 of [RFC7812], when a new MRT Profile is defined, new and unique values should be allocated from the "MPLS Multi-Topology Identifiers" registry, matching the MRT-Red and MRT-Blue MT-ID values for that new MRT Profile 🌈

The MT Prefix FEC encoding is defined in [RFC7307], and it's used without alteration for advertising label mappings for MRT-Blue, MRT-Red, and Rainbow MRT FECs 🫶

[RFC7811] and [RFC7812] describe how the MRT topology is created from information in IGP advertisements 🍓 The MRT topology and computations rely on IGP advertisements. The presence or absence of MRT-related LDP advertisements doesn't affect the MRT topology or the MRT-Red and MRT-Blue next hops computed for that topology. Main character energy, the IGP is in charge here 👑

Let's say you've got a network where all nodes run the MRT IGP extensions to figure out the MRT topology, which is then used to compute MRT-Red and MRT-Blue next hops 💜 The network operator also sets the nodes up to exchange MRT-related LDP advertisements so they can distribute MPLS labels for those MRT next hops. Now suppose a misconfiguration on one particular link means the MRT-related LDP advertisements aren't being properly exchanged over that link 😭 Since the MRT-related IGP advertisements for that link are still being distributed, the link stays in the MRT topology and computations. In this scenario, there will be missing MPLS forwarding entries for paths that use the misconfigured link 💀

This is basically the same situation as normal LDP advertisements and IGP advertisements for shortest-path forwarding 🙈 Turning off the distribution of labels for normal shortest-path FECs on a link doesn't change the topology that the Shortest Path First (SPF) algorithm runs on in the IGP.

"LDP IGP Synchronization" [RFC5443] deals with the LDP topology not matching the IGP topology by advertising the maximum IGP cost on links where LDP isn't fully operational 🔥 That makes the IGP topology match the LDP topology. As described in Section 7.3.1 of [RFC7812], MRT is designed to be compatible with the LDP IGP synchronization mechanism 🦋 When the IGP advertises the maximum cost on a link where LDP isn't fully operational, that link is excluded from MRT Island formation, which stops the MRT algorithm from creating any paths using that link ✨

5. LDP MRT FEC Advertisements ✨

This section describes how and when labels for MRT-Red and MRT-Blue FECs are advertised 💖 To provide protection paths that the point of local repair can use right away when a failure happens, the associated LSPs need to be created before the failure occurs 🫶

In this section, the term "shortest-path FEC" refers to the usual FEC associated with the shortest-path destination-based forwarding tree for a given prefix, as determined by the IGP 🌈 The terms "red FEC" and "blue FEC" refer to FECs associated with the MRT-Red and MRT-Blue destination-based forwarding trees for a given prefix, as determined by a particular MRT algorithm 🧚

First we'll go over the label distribution behavior that's specific to MRT 💅 Then we'll cover the correct interpretation of several important concepts in [RFC5036] in the context of MRT FEC label distribution 👑

[RFC5036] specifies two Label Distribution Control Modes (Independent and Ordered), two Label Retention Modes (Conservative and Liberal), and two Label Advertisement Modes (Downstream Unsolicited and Downstream on Demand) 🎀 The current specification for LDP MRT requires that the same Label Distribution Control, Label Retention, and Label Advertisement modes be used for the shortest-path FECs and the MRT FECs. no mixing and matching, bestie 🔥

5.1. MRT-Specific Behavior 💅

5.1.1. ABR Behavior and Use of the Rainbow FEC 🌈

Okay bestie, so Section 10.1 of [RFC7812] explains why an ABR needs different neighbors to use different MPLS labels when they send traffic to the ABR for the same FEC 🫶. The way to pull that off with the Rainbow MRT MT-ID is explained in full detail in [RFC7812], so here's a quick recap ✨ To those LDP peers in the same area as the best route to the destination, the ABR advertises two different labels, one for the MRT-Red forwarding tree and one for the MRT-Blue forwarding tree, for the destination. An LDP peer that gets these advertisements forwards MRT traffic to the ABR using those two labels, depending on the FEC of the traffic. We call this "best-area advertising and forwarding behavior," which is identical to normal MRT behavior 💅

For all other LDP peers supporting MRT, the ABR advertises a FEC-label binding for the FEC, which is in the Rainbow MRT MT-ID, with the label that corresponds to that FEC in the default forwarding tree for the destination. An LDP peer that gets this advertisement forwards MRT traffic to the ABR using this label, for both MRT-Red and MRT-Blue traffic 🦋 We call this "non-best-area advertising and forwarding behavior."

The use of the Rainbow-FEC by the ABR for non-best-area advertisements is RECOMMENDED. An ABR MAY advertise the label for the default topology in separate MRT-Blue and MRT-Red advertisements. An LSR advertising the MRT Capability MUST recognize the Rainbow MRT MT-ID and associate the advertised label with the specific prefix with the MRT-Red and MRT-Blue MT-IDs associated with all MRT Profiles that advertise LDP as the forwarding mechanism 🌸

Due to changes in topology or configuration, an ABR and a given LDP peer may need to transition from best-area advertising and forwarding behavior to non-best-area behavior for a given destination, and vice versa. When the ABR requires best-area behavior for a red(blue) FEC, it MUST withdraw any existing label mappings advertisements for the corresponding Rainbow FEC and advertise label mappings for the red(blue) FEC. When the ABR requires non-best-area behavior for a red(blue) FEC, it MUST withdraw any existing label mappings for both red and blue FECs and advertise label mappings for the corresponding Rainbow FEC label-binding. Plot twist, the ABR has to switch things up cleanly 🔄

In this transition, an ABR should never advertise a red(blue) FEC before withdrawing the corresponding Rainbow FEC (or vice versa). However, should this situation occur, the expected behavior of an LSR receiving these conflicting advertisements is defined as follows:

  • If an LSR receives a label mapping advertisement for a Rainbow FEC from an MRT LDP peer while it still retains a label mapping for the corresponding red or blue FEC, the LSR MUST continue to use the label mapping for the red or blue FEC, and it MUST send a Label Release message corresponding to the Rainbow FEC label advertisement. 🙈
  • If an LSR receives a label mapping advertisement for a red or blue FEC while it still retains a label mapping for the corresponding Rainbow FEC, the LSR MUST continue to use the label mapping for the Rainbow FEC, and it MUST send a Label Release message corresponding to the red or blue FEC label advertisement. 💀

5.1.2. Proxy-Node Attachment Router Behavior 🦋

Section 11.2 of [RFC7812] covers how MRT provides FRR protection for multi-homed prefixes using calculations that involve a named proxy-node. This covers the scenario where a prefix is originated by a router in the same area as the MRT Island, but outside of the MRT Island. It also covers the scenario of a prefix being advertised by multiple routers in the MRT Island 👑

In the named proxy-node calculation, each multi-homed prefix is represented by a conceptual proxy-node that is attached to two real proxy-node attachment routers. (A single proxy-node attachment router is allowed in the case of a prefix advertised by a same area router outside of the MRT Island, which is singly connected to the MRT Island.) All routers in the MRT Island perform the same calculations to determine the same two proxy-node attachment routers for each multi-homed prefix. Section 5.9 of [RFC7811] describes the procedure for identifying one proxy-node attachment router as "red" and one as "blue" with respect to the multi-homed prefix, and computing the MRT red and blue next hops to reach those red and blue proxy-node attachment routers 🧚

In terms of LDP behavior, a red proxy-node attachment router for a given prefix MUST originate a label mapping for the red FEC for that prefix, while the blue proxy-node attachment router for a given prefix MUST originate a label mapping for the blue FEC for that prefix. If the red(blue) proxy-node attachment router is an Island Border Router (IBR), then when it receives a packet with the label corresponding to the red(blue) FEC for a prefix, it MUST forward the packet to the Island Neighbor (IN) whose cost was used in the selection of the IBR as a proxy-node attachment router. The IBR MUST swap the incoming label for the outgoing label corresponding to the shortest-path FEC for the prefix advertised by the IN. In the case where the IN does not support LDP, the IBR MUST pop the incoming label and forward the packet to the IN 🍓

If the proxy-node attachment router is not an IBR, then the packet MUST be removed from the MRT forwarding topology and sent along the interface(s) that caused the router to advertise the prefix. This interface might be out of the area/level/AS 🌈

5.2. LDP Protocol Procedures in the Context of MRT Label Distribution 🎀

[RFC5036] specifies the LDP label distribution procedures for shortest-path FECs. In general, the same procedures can be applied to the distribution of label mappings for red and blue FECs, provided that the procedures are interpreted in the context of MRT FEC label distribution. The correct interpretation of several important concepts in [RFC5036] in the context of MRT FEC label distribution is provided below 💜

5.2.1. LDP Peer in RFC 5036 👯

In the context of distributing label mappings for red and blue FECs, we restrict the LDP peer in [RFC5036] to mean LDP peers for which the LDP MRT Capability has been negotiated. In order to make this distinction clear, in this document we will use the term "MRT LDP peer" to refer to an LDP peer for which the LDP MRT Capability has been negotiated ✨

5.2.2. Next Hop in RFC 5036 🧭

Several procedures in [RFC5036] use the next hop of a (shortest-path) FEC to determine behavior. The next hop of the shortest-path FEC is based on the shortest-path forwarding tree to the prefix associated with the FEC. When the procedures of [RFC5036] are used to distribute label mapping for red and blue FECs, the next hop for the red(blue) FEC is based on the MRT-Red(Blue) forwarding tree to the prefix associated with the FEC.

For example, Appendix A.1.7 of [RFC5036] specifies the response by an LSR to a change in the next hop for a FEC. For a shortest-path FEC, the next hop may change as the result of the LSR running a shortest-path computation on a modified IGP topology database. For the red and blue FECs, the red and blue next hops may change as the result of the LSR running a particular MRT algorithm on a modified IGP topology database 🌊

As another example, Section 2.6.1.2 of [RFC5036] specifies that when an LSR is using LSP Ordered Control, it may initiate the transmission of a label mapping only for a (shortest-path) FEC for which it has a label mapping for the FEC next hop, or for which the LSR is the egress. The FEC next hop for a shortest-path FEC is based on the shortest-path forwarding tree to the prefix associated with the FEC. In the context of distributing MRT LDP labels, this procedure is understood to mean the following. When an LSR is using LSP Ordered Control, it may initiate the transmission of a label mapping only for a red(blue) FEC for which it has a label mapping for the red(blue) FEC next hop, or for which the LSR is the egress. The red or blue FEC next hop is based on the MRT-Red or Blue forwarding tree to the prefix associated with the FEC 🫶

5.2.3. Egress LSR in RFC 5036 🚪

Procedures in [RFC5036] related to Ordered Control label distribution mode rely on whether or not an LSR may act as an egress LSR for a particular FEC in order to determine whether or not the LSR may originate a label mapping for that FEC. The status of being an egress LSR for a particular FEC is also used in the loop detection procedures described in [RFC5036]. Section 2.6.1.2 of [RFC5036] specifies the conditions under which an LSR may act as an egress LSR with respect to a particular (shortest-path) FEC:

  1. The (shortest-path) FEC refers to the LSR itself (including one of its directly attached interfaces).
  2. The next hop router for the (shortest-path) FEC is outside of the Label Switching Network.
  3. (Shortest-path) FEC elements are reachable by crossing a routing domain boundary.

The conditions for determining an egress LSR with respect to a red or blue FEC need to be modified. An LSR may act as an egress LSR with respect to a particular red(blue) FEC under any of the following conditions:

  1. The prefix associated with the red(blue) FEC refers to the LSR itself (including one of its directly attached interfaces).
  2. The LSR is the red(blue) proxy-node attachment router with respect to the multi-homed prefix associated with the red(blue) FEC. This includes the degenerate case of a single red and blue proxy-node attachment router for a single-homed prefix.
  3. The LSR is an ABR AND the MRT LDP peer requires non-best-area advertising and forwarding behavior for the prefix associated with the FEC.

Note that condition 3 scopes an LSR's status as an egress LSR with respect to a particular FEC to a particular MRT LDP peer. Therefore, the condition "Is LSR egress for FEC?" that occurs in several procedures in [RFC5036] needs to be interpreted as "Is LSR egress for FEC with respect to Peer?" 🔍

Also note that there is no explicit condition that allows an LSR to be classified as an egress LSR with respect to a red or blue FEC based only on the primary next hop for the shortest-path FEC not supporting LDP or not supporting LDP MRT Capability. These situations are covered by the proxy-node attachment router and ABR conditions (conditions 2 and 3). In particular, an Island Border Router is not the egress LSR for a red(blue) FEC unless it is also the red(blue) proxy-node attachment router for that FEC. Lowkey a very specific rule, but it matters 🥹

Also note that, in general, a proxy-node attachment router for a given prefix should not advertise an implicit or explicit null label for the corresponding red or blue FEC, even though it may be an egress LSR for the shortest-path FEC. In general, the proxy-node attachment router needs to forward red or blue traffic for that prefix to a particular loop-free island neighbor, which may be different from the shortest-path next hop. The proxy-node attachment router needs to receive the red or blue traffic with a non-null label to correctly forward it 💅 periodt.

5.2.4. Use of Rainbow FEC to Satisfy Label Mapping Existence Requirements in RFC 5036 ✨

Okay bestie, a bunch of procedures in [RFC5036] need the LSR to check whether it already got and kept a label mapping for a FEC from the next hop 🧐 If an LSR got and kept a label mapping for the Rainbow FEC from an ABR, that Rainbow mapping counts as the existence check for the matching red and blue FECs 💖 So for MRT LDP label distribution, the question gets tweaked to: "Has LSR previously received and retained a label mapping for the red(blue) FEC (or the corresponding Rainbow FEC) from the red(blue) next hop?" 🦋

For example, this lets an LSR that already holds a label mapping for the Rainbow FEC send label mappings for the corresponding red and blue FECs when it's running in Ordered Control label distribution mode 🎀 Iykyk 💅

5.2.5. Validating FECs in the Routing Table

So in [RFC5036], an LSR uses its routing table to validate prefixes tied to shortest-path FECs 🗺️ For instance, Section 3.5.7.1 of [RFC5036] says "an LSR receiving a Label Mapping message from a downstream LSR for a Prefix SHOULD NOT use the label for forwarding unless its routing table contains an entry that exactly matches the FEC Element." 🙈 For MRT FECs, a red or blue FEC element matches a routing table entry when the corresponding shortest-path FEC element matches one. Main character validation 👑

5.2.6. Recognizing New FECs

Appendix A.1.6 of [RFC5036] covers how an LSR responds to the "Recognize New FEC" event, which happens when an LSR learns a new (shortest-path) FEC via the routing table 🌈 In the MRT world, if the MRT LDP Capability has been enabled, then whenever an LSR learns a new shortest-path FEC, the LSR should generate "Recognize New FEC" events for the corresponding Red and Blue FECS too, on top of the usual "Recognize New FEC" event for the shortest-path FEC ✨

5.2.7. Not Propagating Rainbow FEC Label Mappings

A label mapping for the Rainbow FEC should only be originated by an ABR under the conditions described in Section 5.1.1. A neighbor of the ABR that receives a label mapping for the Rainbow FEC MUST NOT propagate a label mapping for that Rainbow FEC. 🚫 Basically, the Rainbow mapping stays put and does not get passed along, no exceptions bestie 🙅‍♀️

6. Security Considerations 🔒

Okay, this part is serious, so listen up 😭 The labels distributed by the extensions in this document create additional forwarding paths that do not follow shortest-path routes. The transit label swapping operations that define these alternative forwarding paths are set up during normal operations, before any failure ever happens. That means a malicious packet with an appropriate label, injected into the network from a compromised location, would be forwarded to a destination along a non-shortest path 💀 When this technology is deployed, a network security design should not rely on assumptions that potentially malicious traffic only follows shortest paths. Do not build your security around that assumption, fr fr 🚨

It should be noted that creating non-shortest forwarding paths is not unique to MRT 🫶 For example, RSVP-TE [RFC3209] can be used to construct forwarding paths that do not follow the shortest path. So this isn't a one-off, it's a whole vibe across the Internet 🌸

As we talked about in the intro, MRT isn't just for unicast forwarding. It can also be used to provide disjoint trees for multicast traffic distribution 🌳 For PIM, this happens by using the MRT red and blue next hops as the PIM Reverse Path Forwarding (RPF) topology, which is the collection of routes PIM uses to do the RPF operation when building source trees 🧚 The PIM Multi-Topology ID (MT-ID) Join Attribute defined in Section 5.2 of [RFC6420] can be used to establish MRT-based multicast distribution trees. [RFC6420] limits the values of the PIM MT-ID to 1 through 4095 🔢

For the purpose of reducing management overhead and simplifying troubleshooting, it's really desirable to use the same numerical value for the PIM MT-ID as for the MPLS MT-ID, for both multicast and unicast applications using MRT routes built from the same MRT Profile 💅 To make this simplification possible, the MPLS MT-ID values assigned in this document fall in the range 1 through 4095. The "MPLS Multi-Topology Identifiers" registry reflects this by listing the values from 3948 through 3995 as MRT-related MPLS MT-ID values 📋 That gives 51 MRT-related MPLS MT-ID values that can be directly mapped to PIM MT-ID values, which fits 25 MRT Profiles with red and blue MT-ID pairs, plus one extra for the Rainbow MPLS MT-ID value 🌈 [RFC7307] designates the MT-ID range 6-3995 as "Unassigned for future IGP topologies". As shown in the IANA Considerations, the guidance for the range 3948-3995 has been changed to "Unassigned (for future MRT-related values)" ✨

8. IANA Considerations 📚

IANA has allocated a value for the new LDP Capability TLV from the "Label Distribution Protocol (LDP) Parameters" registry under "TLV Type Name Space": MRT Capability TLV (0x050E). 🎉

Value          Description         Reference     Notes / Reg. Date
-------------  ------------------  ------------  -----------------
0x050E         MRT Capability TLV  RFC 8320

IANA has also allocated a value for the new LDP Status Code from the "Label Distribution Protocol (LDP) Parameters" registry under "Status Code Name Space": MRT Capability negotiated without MT Capability (0x00000034). The Status Code E-bit is set to 0. 💖

Value         E  Description         Reference      Notes / Reg. Date
------------- -  ------------------  ------------   -----------------
0x00000034    0  MRT Capability      RFC 8320
                 negotiated without
                 MT Capability

IANA has allocated three values from the "MPLS Multi-Topology Identifiers" registry [RFC7307] 🦋

   3945  Rainbow MRT MPLS MT-ID

   3946  Default Profile MRT-Red MPLS MT-ID

   3947  Default Profile MRT-Blue MPLS MT-ID

Also, IANA changed the Purpose field of the "MPLS Multi-Topology Identifiers" registry for MT-ID range 3948-3995 to "Unassigned (for future MRT-related values)". The registration procedure for the entire registry remains Standards Action [RFC8126]. Here's the current registry, bestie 👀

Value         Purpose                                    Reference
------------  ----------------------                     ------------
0             Default/standard topology                  [RFC7307]
1             IPv4 in-band management                    [RFC7307]
2             IPv6 routing topology                      [RFC7307]
3             IPv4 multicast topology                    [RFC7307]
4             IPv6 multicast topology                    [RFC7307]
5             IPv6 in-band management                    [RFC7307]
6-3944        Unassigned (for future IGP topologies)
3945          Rainbow MRT MPLS MT-ID                      RFC 8320
3946          Default Profile MRT-Red MPLS MT-ID          RFC 8320
3947          Default Profile MRT-Blue MPLS MT-ID         RFC 8320
3948-3995     Unassigned (for future MRT-related values)  RFC 8320
3996-4095     Reserved for Experimental Use              [RFC7307]
4096-65534    Unassigned (for MPLS topologies)
65535         Wildcard Topology                          [RFC7307]

9. References 📖

9.1. Normative References

9.2. Informative References

  • [ARCH] Atlas, A., Kebler, R., Wijnands, IJ., Csaszar, A., and G. Envedi, "An Architecture for Multicast Protection Using Maximally Redundant Trees", Work in Progress, draft-atlas-rtgwg-mrt-mc-arch-02, July 2013.
  • [IS-IS-MRT] Li, Z., Wu, N., Zhao, Q., Atlas, A., Bowers, C., and J. Tantsura, "Intermediate System to Intermediate System (IS-IS) Extensions for Maximally Redundant Trees (MRTs)", Work in Progress, draft-ietf-isis-mrt-03, June 2017.
  • [OSPF-MRT] Atlas, A., Hegde, S., Bowers, C., Tantsura, J., and Z. Li, "OSPF Extensions to Support Maximally Redundant Trees", Work in Progress, draft-ietf-ospf-mrt-03, June 2017.
  • [PARAM-SYNC] Bryant, S., Atlas, A., and C. Bowers, "Routing Timer Parameter Synchronization", Work in Progress, draft-ietf-rtgwg-routing-timer-param-sync-00, October 2017.
  • [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>.
  • [RFC5443] Jork, M., Atlas, A., and L. Fang, "LDP IGP Synchronization", RFC 5443, DOI 10.17487/RFC5443, March 2009, <https://www.rfc-editor.org/info/rfc5443>.
  • [RFC7715] Wijnands, IJ., Ed., Raza, K., Atlas, A., Tantsura, J., and Q. Zhao, "Multipoint LDP (mLDP) Node Protection", RFC 7715, DOI 10.17487/RFC7715, January 2016, <https://www.rfc-editor.org/info/rfc7715>.

Acknowledgements 💜

The authors would like to thank Ross Callon, Loa Andersson, Stewart Bryant, Mach Chen, Greg Mirsky, Uma Chunduri, and Tony Przygienda for their comments and suggestions 🫶

Authors' Addresses ✨

okay bestie, this is where you can find the whole squad 🫶 five people wrote this thing, and here's how to reach each of them so you can slide into their inbox (professionally, obvs 💅)

Alia Atlas 👑 from Juniper Networks, based in Westford, MA:

Alia Atlas
Juniper Networks
10 Technology Park Drive
Westford, MA  01886
United States of America

Email: akatlas@juniper.net

Kishore Tiruveedhula 🌸 also from Juniper Networks, same Westford, MA office:

Kishore Tiruveedhula
Juniper Networks
10 Technology Park Drive
Westford, MA  01886
United States of America

Email: kishoret@juniper.net

Chris Bowers 🦋 with Juniper Networks, but at the Sunnyvale, CA location:

Chris Bowers
Juniper Networks
1194 N. Mathilda Ave.
Sunnyvale, CA  94089
United States of America

Email: cbowers@juniper.net

Jeff Tantsura 🧚 writing as an Individual, so no company on the badge, just the United States of America and an email:

Jeff Tantsura
Individual
United States of America

Email: jefftant.ietf@gmail.com

IJsbrand Wijnands 💜 from Cisco Systems, Inc. Only the affiliation and email were listed for this one:

IJsbrand Wijnands
Cisco Systems, Inc.

Email: ice@cisco.com
📦 where this page comes from