RFC 9658

Multipoint LDP Extensions for Multi-Topology Routing

📅 published October 2024, from ietf

RFC 9658: Multipoint LDP Extensions for Multi-Topology Routing 🎀

okay bestie, let's get into it ✨ this one is a standards track doc from the IETF, published October 2024 🦋

Authors: IJ. Wijnands (Individual), M. Mishra, Ed. (Cisco Systems, Inc.), K. Raza (Cisco Systems, Inc.), Z. Zhang (Juniper Networks), and A. Gulko (Edward Jones) 💜

Updates: RFC 7307 🌸 this doc takes eight bits from a field that used to be reserved in RFC 7307 and turns them into an "IPA" field 🔥

The ISSN is 2070-1721 and the status is Standards Track 💅

Abstract

okay so Multi-Topology Routing (MTR) is basically how you give different kinds of traffic their own lane inside an IP network, aka service differentiation 🛣️✨ the Flexible Algorithm (FA) is another way to carve out a sub-topology inside a topology, using topology constraints and computation algorithms 🧩

now, if you wanna run Multipoint LDP (mLDP) on a network that does MTR, FA, or any other way of signaling non-default IGP Algorithms (IPAs), mLDP has to become topology and algorithm aware 👑 this doc adds the extensions that make that happen, so when mLDP builds a multipoint LSP, it can follow a specific topology and algorithm 💖

it also updates RFC 7307 by grabbing eight bits from a previously reserved field and using them as the "IPA" field 🎀

Status of This Memo

this is a Standards Track doc 💅 it's a product of the IETF and it represents IETF community consensus. it got public review and the IESG approved it for publication 🫶

if you want more info on Internet Standards, check out Section 2 of RFC 7841 🌈

current status, errata, and feedback info lives at https://www.rfc-editor.org/info/rfc9658 ✨

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

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as of the publication date. please actually read those, they spell out your rights 🙈 also, any Code Components pulled out of this doc have to include Revised BSD License text (see Section 4.e of the Trust Legal Provisions), and they come without warranty as described in that license 💀

Table of Contents

1. Introduction 2. Terminology 2.1. Abbreviations 2.2. Specification of Requirements 3. MT-Scoped mLDP FECs 3.1. MP FEC Extensions for MT 3.1.1. MP FEC Element 3.1.2. MT IP Address Families 3.1.3. MT MP FEC Element 3.2. Topology IDs 4. MT Multipoint Capability 5. MT Applicability on FEC-Based Features 5.1. Typed Wildcard MP FEC Elements 5.2. End-of-LIB 6. Topology-Scoped Signaling and Forwarding 6.1. Upstream LSR Selection 6.2. Downstream Forwarding Interface Selection 7. LSP Ping Extensions 8. Security Considerations 9. IANA Considerations 10. References 10.1. Normative References 10.2. Informative References Contributors Acknowledgments Authors' Addresses

1. Introduction 🌸

okay so MTR is the same service-differentiation idea from the abstract 🛣️ IGPs like OSPF and IS-IS already got MTR extensions, and LDP got them too 💅 an IGP keeps separate IP topologies called "Multi-Topologies" (or "MTs") and computes and installs routes for each one. the OSPF bits are in [RFC4915], the IS-IS bits are in [RFC5120], and the LDP ones are in [RFC7307], which lets LDP set up unicast LSPs along IGP MT routing paths ✨

Flexible Algorithm (FA) is the lighter-weight option for constraint-based topologies, defined in [RFC9350] 🧚 it's another way to make a sub-topology inside a topology, and it can live inside an MTR topology or the default one 🌈 an FA instance is identified by a 1-octet value, per [RFC9350] 🔥

FA is a mechanism for making sub-topologies right now, but later on other algorithms could show up for the same job 👑 so the rest of this doc calls the whole thing "IGP Algorithm" or "IPA" 💖 the "IPA" field (see Sections 3.1.2 and 5.1) is an 8-bit identifier for the algorithm, and the allowed values are tracked in the "IGP Algorithm Types" registry [IANA-IGP] 🦋

when this doc says "Flexible Algorithm" (or "FA"), it means the process of generating a sub-topology and signaling it through the IGP 🫶 BUT the procedures here aren't only for FA. they can be extended to any non-default algorithm too 💜

"Multipoint LDP" (or "mLDP") is LDP's set of extensions for setting up multipoint LSPs, meaning point-to-multipoint (P2MP) or multipoint-to-multipoint (MP2MP) ones, described in [RFC6388] 🎀 to run mLDP on a network doing MTR and FA, mLDP needs to become topology and algorithm aware ✨ this doc makes that happen, so when building multipoint LSPs, mLDP can follow a particular topology and algorithm 💅 which means the identifier for the topology mLDP uses has to become a 2-tuple {MTR Topology Id, IPA} 🌟

2. Terminology

2.1. Abbreviations

okay here's your cheat sheet 📝

  • FA: Flexible Algorithm 🧚
  • FEC: Forwarding Equivalence Class 💖
  • IGP: Interior Gateway Protocol 🛣️
  • IPA: IGP Algorithm 👑
  • LDP: Label Distribution Protocol 🦋
  • LSP: Label Switched Path 🌸
  • mLDP: Multipoint LDP ✨
  • MP: Multipoint 💜
  • MP2MP: Multipoint-to-Multipoint 🫶
  • MT: Multi-Topology 🌈
  • MT-ID: Multi-Topology Identifier 🎀
  • MTR: Multi-Topology Routing 🔥
  • MVPN: Multicast VPN in Section 2.3 of [RFC6513] 💅
  • P2MP: Point-to-Multipoint 🍓
  • PMSI: Provider Multicast Service Interfaces [RFC6513] 🧚

2.2. Specification of Requirements

okay this part is the key-words bit, and it's important 🙈 the words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be read as described in BCP 14 [RFC2119] [RFC8174], but only when they're written in all capitals, exactly like that 💀 lowercase ones are just regular English 😭

3. MT-Scoped mLDP FECs

so [RFC7307] says an MPLS Multi-Topology Identifier (MT-ID) ties an LSP to a particular MTR topology 🛣️ for MP LSPs, that MT-ID becomes part of the mLDP FEC encoding, so LDP peers can build an MP LSP according to their own MTR policy 💖 to avoid conflicting MTR policies for the same mLDP FEC, the MT-ID has to be part of the FEC, which means different MT-ID values give you unique MP-LSP FEC elements 👑

same deal for the IPA 🦋 it has to be encoded in the mLDP FEC to make unique MP LSPs. the IPA also tells mLDP (hop-by-hop) which algorithm to use when creating the MP LSP 🫶

since the MT-ID and IPA are part of the FEC, they apply to every LDP message that might carry an mLDP FEC element 🌈

3.1. MP FEC Extensions for MT

these subsections define the extensions that bind an mLDP FEC to a topology 🎀 they reuse some of the extensions from [RFC7307] ✨

3.1.1. MP FEC Element

the base mLDP spec ([RFC6388]) defines the MP FEC element like this 💅

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | MP FEC type   |       Address Family          |    AF Length  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Root Node Address                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Opaque Length              |       Opaque Value            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 1: MP FEC Element Format

the "Root Node Address" field gets encoded according to the "Address Family" field, and its length in octets is given by the "AF Length" field 🌸

to extend MP FEC elements for MT, the {MT-ID, IPA} tuple matters in the context of the MP LSP's root address 🧚 that tuple decides which (sub-)topology the root address has to be resolved in 🔥 since {MT-ID, IPA} is part of the mLDP FEC, it's most naturally encoded as part of the root address 💖

3.1.2. MT IP Address Families

[RFC7307] introduces two new address families, "MT IP" and "MT IPv6", so you can specify an IP prefix within a topology scope 🛣️ for mLDP, these families are used together with a change: 8 bits of the 16-bit "Reserved" field that RFC 7307 described now get used to encode the IPA 👑 the data for these families ends up looking like this 🦋

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     IPv4 Address                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Reserved   |      IPA      |        MT-ID                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     IPv6 Address                              |
   |                                                               |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Reserved   |      IPA      |        MT-ID                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          Figure 2: Modified Format for MT IP Address Families

where 📝

  • IPv4 Address and IPv6 Address: the IP address for the "MT IP" and "MT IPv6" address families, respectively 🌈
  • IPA: the IGP Algorithm 🧚
  • Reserved: this 8-bit field MUST be zero on transmission and MUST be ignored on receipt 💀
⚠️ bestie, read that Reserved line twice. Reserved MUST be zero when you send it and MUST be ignored when you receive it 🫶

That's the end of part 1! 🌈 more parts are coming, so stay tuned, bestie 💖

3.1.3. MT MP FEC Element

Okay bestie, this is where the MT-Scoped MP FEC element gets its actual shape 🦋✨ When you're using the extended "MT IP" address family, the resulting MT-Scoped MP FEC element should be encoded like this:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | MP FEC type   |  AF (MT IP/ MT IPv6)          |    AF Length  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Root Node Address                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Reserved   |      IPA      |        MT-ID                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Opaque Length              |       Opaque Value            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         Figure 3: Format for an IP MT-Scoped MP FEC Element

In the context of this document, the applicable LDP FECs for MT mLDP ([RFC6388]) include:

  • MP FEC elements:
    • P2MP (type 0x6)
    • MP2MP-up (type 0x7)
    • MP2MP-down (type 0x8)
  • Typed Wildcard FEC Element (type 0x5 defined in [RFC5918])

In the case of the Typed Wildcard FEC Element, the FEC element type MUST be one of the MP FECs listed above. 💅

This specification allows the use of topology-scoped mLDP FECs in LDP labels and notification messages, as applicable. 🌸

[RFC6514] defines the PMSI tunnel attribute for MVPN and specifies that:

  • when the Tunnel Type is set to mLDP P2MP LSP, the Tunnel Identifier is a P2MP FEC element, and
  • when the Tunnel Type is set to mLDP MP2MP LSP, the Tunnel Identifier is an MP2MP FEC element.

When the extension defined in this specification is in use, the IP MT-Scoped MP FEC element form of the respective FEC elements MUST be used in these two cases. 🎀

3.2. Topology IDs

This document assumes the same definitions and procedures associated with MPLS MT-ID as specified in [RFC7307]. 🧚

4. MT Multipoint Capability ✨

The "MT Multipoint" capability is a brand new LDP capability, defined following the LDP capability definition guidelines in [RFC5561]. An mLDP speaker advertises this capability to its peers to announce its support for MTR and the procedures in this document. This capability MAY be sent either in an Initialization message at session establishment or dynamically during the session's lifetime via a Capability message, provided that the "Dynamic Announcement" capability from [RFC5561] has been successfully negotiated with the peer. 🦋

The format of this capability is as follows:

    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|  MT Multipoint Capability |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |S| Reserved    |
   +-+-+-+-+-+-+-+-+

        Figure 4: Format for the MT Multipoint Capability TLV

Where:

  • U and F bits: MUST be 1 and 0, respectively, as per Section 3 of [RFC5561].
  • MT Multipoint Capability: The TLV type.
  • Length: This field specifies the length of the TLV in octets. The value of this field MUST be 1, as there is no capability-specific data [RFC5561] following the TLV.
  • S bit: Set to 1 to announce and 0 to withdraw the capability (as per [RFC5561]).

An mLDP speaker that has successfully advertised and negotiated the "MT Multipoint" capability MUST support the following:

  1. Topology-scoped mLDP FECs in LDP messages (Section 3.1)
  2. Topology-scoped mLDP forwarding setup (Section 6)

5. MT Applicability on FEC-Based Features

5.1. Typed Wildcard MP FEC Elements

[RFC5918] extends the base LDP and defines the Typed Wildcard FEC Element framework. A Typed Wildcard FEC Element can be used in any LDP message to specify a wildcard operation for a given type of FEC.

The MT extensions defined in this document do not require any extension to procedures for support of the Typed Wildcard FEC Element [RFC5918], and these procedures apply as is to Multipoint MT FEC wildcarding. Similar to the Typed Wildcard MT Prefix FEC element, as defined in [RFC7307], the MT extensions allow the use of "MT IP" or "MT IPv6" in the "Address Family" field of the Typed Wildcard MP FEC Element. This is done in order to use wildcard operations for MP FECs in the context of a given (sub-)topology as identified by the "MT-ID" and "IPA" fields. 🌈

This document defines the following format and encoding for a Typed Wildcard MP FEC Element:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Typed Wcard (5)| Type = MP FEC |   Len = 6     |  AF = MT IP ..|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |... or MT IPv6 |    Reserved   |      IPA      |     MT-ID     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |MT-ID (cont.)  |
   +-+-+-+-+-+-+-+-+

      Figure 5: Format for the Typed Wildcard MT MP FEC Element

Where:

  • Type: One of the MP FEC element types (P2MP, MP2MP-up, or MP2MP-down)
  • MT-ID: MPLS MT-ID
  • IPA: The IGP Algorithm

The defined format allows a Label Switching Router (LSR) to perform wildcard MP FEC operations under the scope of a (sub-)topology. 🫶

5.2. End-of-LIB

[RFC5919] specifies extensions and procedures that allow an LDP speaker to signal its End-of-LIB (Label Information Base) for a given FEC type to a peer. By leveraging the End-of-LIB message, LDP ensures that label distribution remains consistent and reliable, even during network disruptions or maintenance activities. The MT extensions for MP FEC do not require any modifications to these procedures and apply as they are to MT MP FEC elements. Consequently, an MT mLDP speaker MAY signal its convergence per (sub-)topology using the MT Typed Wildcard MP FEC Element. 💜

6. Topology-Scoped Signaling and Forwarding

Since the {MT-ID, IPA} tuple is part of an mLDP FEC, there is no need to support the concept of multiple (sub-)topology forwarding tables in mLDP. Each MP LSP will be unique due to the tuple being part of the FEC. There is also no need to have specific label forwarding tables per topology, and each MP LSP will have its own unique local label in the table. However, in order to implement MTR in an mLDP network, the selection procedures for an upstream LSR and a downstream forwarding interface need to be changed. 🍓

6.1. Upstream LSR Selection

The procedures described in Section 2.4.1.1 of [RFC6388] depend on the best path to reach the root. When the {MT-ID, IPA} tuple is signaled as part of the FEC, the tuple is also used to select the (sub-)topology that must be used to find the best path to the root address. Using the next-hop from this best path, an LDP peer is selected following the procedures defined in [RFC6388]. 🧭

6.2. Downstream Forwarding Interface Selection

Section 2.4.1.2 of [RFC6388] describes the procedures for how a downstream forwarding interface is selected. In these procedures, any interface leading to the downstream LDP neighbor can be considered to be a candidate forwarding interface. When the {MT-ID, IPA} tuple is part of the FEC, this is no longer true. An interface MUST only be selected if it is part of the same (sub-)topology that was signaled in the mLDP FEC element. Besides this restriction, the other procedures in [RFC6388] apply. 🚦

7. LSP Ping Extensions

[RFC6425] defines procedures to detect data plane failures in multipoint MPLS LSPs. Section 3.1.2 of [RFC6425] defines new sub-types and sub-TLVs for Multipoint LDP FECs to be sent in the "Target FEC Stack" TLV of an MPLS Echo Request message [RFC8029]. 🔍

To support LSP ping for MT MP LSPs, this document uses existing sub-types "P2MP LDP FEC Stack" and "MP2MP LDP FEC Stack" defined in [RFC6425]. The LSP ping extension is to specify "MT IP" or "MT IPv6" in the "Address Family" field, set the "Address Length" field to 8 (for MT IP) or 20 (for MT IPv6), and encode the sub-TLV with additional {MT-ID, IPA} information as an extension to the "Root LSR Address" field. The resultant format of sub-TLV is as follows:

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |Address Family (MT IP/MT IPv6) | Address Length|               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
    ~                   Root LSR Address (Cont.)                    ~
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Reserved   |      IPA      |        MT-ID                  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |        Opaque Length          |         Opaque Value ...      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
    ~                                                               ~
    |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           Figure 6: Multipoint LDP FEC Stack Sub-TLV Format for MT

The rules and procedures of using this new sub-TLV in an MPLS Echo Request message are the same as defined for the P2MP/MP2MP LDP FEC Stack sub-TLV in [RFC6425]. The only difference is that the "Root LSR Address" field is now (sub-)topology scoped. 🎀

8. Security Considerations

This extension to mLDP does not introduce any new security considerations beyond what is already applied to the base LDP specification [RFC5036], the LDP extensions for Multi-Topology specification [RFC7307], the base mLDP specification [RFC6388], and the MPLS security framework specification [RFC5920]. 🔐

9. IANA Considerations

This document defines a new LDP capability parameter TLV called the "MT Multipoint Capability". IANA has assigned the value 0x0510 from the "TLV Type Name Space" registry in the "Label Distribution Protocol (LDP) Parameters" group as the new code point. 👑

  +========+===============+===========+=========================+
  | Value  | Description   | Reference | Notes/Registration Date |
  +========+===============+===========+=========================+
  | 0x0510 | MT Multipoint | RFC 9658  |                         |
  |        | Capability    |           |                         |
  +--------+---------------+-----------+-------------------------+

                   Table 1: MT Multipoint Capability

10. References

10.1. Normative References 📚💖

Okay bestie, these are the references the spec needs you to have read before you can actually implement anything 🤓✨

10.2. Informative References 🦋

These ones are the extra reading for when you want the bigger picture 🌸

Contributors 🎀

Big shoutout to our contributor, who helped make this whole spec happen 🫶

Anuj Budhiraja
Cisco Systems

Acknowledgments 🌈

The authors wanted to thank Eric Rosen for his input on this specification 💜

Authors' Addresses 💅

Here's who wrote it and how to reach them, slay 🧚

IJsbrand Wijnands
Individual
Email: ice@braindump.be


Mankamana Mishra (editor)
Cisco Systems, Inc.
821 Alder Drive
Milpitas, CA 95035
United States of America
Email: mankamis@cisco.com


Kamran Raza
Cisco Systems, Inc.
2000 Innovation Drive
Kanata ON K2K-3E8
Canada
Email: skraza@cisco.com


Zhaohui Zhang
Juniper Networks
10 Technology Park Dr.
Westford, MA 01886
United States of America
Email: zzhang@juniper.net


Arkadiy Gulko
Edward Jones Wealth Management
United States of America
Email: Arkadiy.gulko@edwardjones.com
📦 where this page comes from