rfc9658v2.txt   rfc9658.txt 
Internet Engineering Task Force (IETF) IJ. Wijnands Internet Engineering Task Force (IETF) IJ. Wijnands
Request for Comments: 9658 Individual Request for Comments: 9658 Individual
Updates: 7307 M. Mishra, Ed. Updates: 7307 M. Mishra, Ed.
Category: Standards Track K. Raza Category: Standards Track K. Raza
ISSN: 2070-1721 Cisco Systems, Inc. ISSN: 2070-1721 Cisco Systems, Inc.
Z. Zhang Z. Zhang
Juniper Networks Juniper Networks
A. Gulko A. Gulko
Edward Jones Edward Jones
September 2024 October 2024
Multipoint LDP Extensions for Multi-Topology Routing Multipoint LDP Extensions for Multi-Topology Routing
Abstract Abstract
Multi-Topology Routing (MTR) is a technology that enables service Multi-Topology Routing (MTR) is a technology that enables service
differentiation within an IP network. The Flexible Algorithm (FA) is differentiation within an IP network. The Flexible Algorithm (FA) is
another mechanism for creating a sub-topology within a topology using another mechanism for creating a sub-topology within a topology using
defined topology constraints and computation algorithms. In order to defined topology constraints and computation algorithms. In order to
deploy Multipoint LDP (mLDP) in a network that supports MTR, FA, or deploy Multipoint LDP (mLDP) in a network that supports MTR, FA, or
other methods of signaling non-default IGP Algorithms (IPAs), mLDP is other methods of signaling non-default IGP Algorithms (IPAs), mLDP is
required to become topology and algorithm aware. This document required to become topology and algorithm aware. This document
specifies extensions to mLDP to support the use of MTR/IPAs such specifies extensions to mLDP to support the use of MTR/IPAs such
that, when building multipoint Label Switched Paths (LSPs), it can that, when building multipoint Label Switched Paths (LSPs), the MTR/
follow a particular topology and algorithm. This document updates IPAs can follow a particular topology and algorithm. This document
RFC 7307 by allocating eight bits from a previously reserved field to updates RFC 7307 by allocating eight bits from a previously reserved
be used as the "IPA" field. field to be used as the "IPA" field.
Status of This Memo Status of This Memo
This is an Internet Standards Track document. This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has (IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841. Internet Standards is available in Section 2 of RFC 7841.
skipping to change at line 106 skipping to change at line 106
(see [RFC5120]) specify the MT extensions under respective IGPs. To (see [RFC5120]) specify the MT extensions under respective IGPs. To
support IGP MT, similar LDP extensions (see [RFC7307]) have been support IGP MT, similar LDP extensions (see [RFC7307]) have been
specified to make LDP be MT aware and to be able to set up unicast specified to make LDP be MT aware and to be able to set up unicast
Label Switched Paths (LSPs) along IGP MT routing paths. Label Switched Paths (LSPs) along IGP MT routing paths.
A more lightweight mechanism to define constraint-based topologies is A more lightweight mechanism to define constraint-based topologies is
the Flexible Algorithm (FA) (see [RFC9350]). The FA is another the Flexible Algorithm (FA) (see [RFC9350]). The FA is another
mechanism for creating a sub-topology within a topology using defined mechanism for creating a sub-topology within a topology using defined
topology constraints and computation algorithms. This can be done topology constraints and computation algorithms. This can be done
within an MTR topology or the default topology. An instance of such within an MTR topology or the default topology. An instance of such
a sub-topology is identified by a 1-octet value (Flex-Algorithm) as a sub-topology is identified by a 1-octet value (Flexible Algorithm)
documented in [RFC9350]. At the time of writing, an FA is a as documented in [RFC9350]. At the time of writing, an FA is a
mechanism to create a sub-topology; in the future, different mechanism to create a sub-topology; in the future, different
algorithms might be defined for this purpose. Therefore, in the algorithms might be defined for this purpose. Therefore, in the
remainder of this document, we'll refer to this as the "IGP remainder of this document, we'll refer to this as the "IGP
Algorithm" or "IPA". The "IPA" field (see Sections 3.1.2 and 5.1) is Algorithm" or "IPA". The "IPA" field (see Sections 3.1.2 and 5.1) is
an 8-bit identifier for the algorithm. The permissible values are an 8-bit identifier for the algorithm. The permissible values are
tracked in the "IGP Algorithm Types" registry [IANA-IGP-ALGO-TYPES]. tracked in the "IGP Algorithm Types" registry [IANA-IGP-ALGO-TYPES].
Throughout this document, the term "Flexible Algorithm" (or "FA") Throughout this document, the term "Flexible Algorithm" (or "FA")
shall denote the process of generating a sub-topology and signaling shall denote the process of generating a sub-topology and signaling
it through the IGP. However, it is essential to note that the it through the IGP. However, it is essential to note that the
skipping to change at line 200 skipping to change at line 200
LDP messages that potentially include an mLDP FEC element. LDP messages that potentially include an mLDP FEC element.
3.1. MP FEC Extensions for MT 3.1. MP FEC Extensions for MT
The following subsections define the extensions to bind an mLDP FEC The following subsections define the extensions to bind an mLDP FEC
to a topology. These mLDP MT extensions reuse some of the extensions to a topology. These mLDP MT extensions reuse some of the extensions
specified in [RFC7307]. specified in [RFC7307].
3.1.1. MP FEC Element 3.1.1. MP FEC Element
The base mLDP specification ([RFC6388]) defines the MP FEC Element as The base mLDP specification ([RFC6388]) defines the MP FEC element as
follows: follows:
0 1 2 3 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 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 | | MP FEC type | Address Family | AF Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Root Node Address | | Root Node Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque Length | Opaque Value | | Opaque Length | Opaque Value |
skipping to change at line 291 skipping to change at line 291
| Opaque Length | Opaque Value | | Opaque Length | Opaque Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
~ ~ ~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Data Format for an IP MT-Scoped MP FEC Element Figure 3: Data Format for an IP MT-Scoped MP FEC Element
In the context of this document, the applicable LDP FECs for MT mLDP In the context of this document, the applicable LDP FECs for MT mLDP
([RFC6388]) include: ([RFC6388]) include:
* MP FEC Elements: * MP FEC elements:
- P2MP (type 0x6) - P2MP (type 0x6)
- MP2MP-up (type 0x7) - MP2MP-up (type 0x7)
- MP2MP-down (type 0x8) - MP2MP-down (type 0x8)
* Typed Wildcard FEC Element (type 0x5 defined in [RFC5918]) * Typed Wildcard FEC Element (type 0x5 defined in [RFC5918])
In the case of the Typed Wildcard FEC Element, the FEC Element type In the case of the Typed Wildcard FEC Element, the FEC element type
MUST be one of the MP FECs listed above. MUST be one of the MP FECs listed above.
This specification allows the use of topology-scoped mLDP FECs in LDP This specification allows the use of topology-scoped mLDP FECs in LDP
labels and notification messages, as applicable. labels and notification messages, as applicable.
[RFC6514] defines the PMSI tunnel attribute for MVPN and specifies [RFC6514] defines the PMSI tunnel attribute for MVPN and specifies
that: that:
* when the Tunnel Type is set to mLDP P2MP LSP, the Tunnel * when the Tunnel Type is set to mLDP P2MP LSP, the Tunnel
Identifier is a P2MP FEC Element, and Identifier is a P2MP FEC element, and
* when the Tunnel Type is set to mLDP MP2MP LSP, the Tunnel * when the Tunnel Type is set to mLDP MP2MP LSP, the Tunnel
Identifier is an MP2MP FEC Element. Identifier is an MP2MP FEC element.
When the extension defined in this specification is in use, the IP 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 MT-Scoped MP FEC element form of the respective FEC elements MUST be
used in these two cases. used in these two cases.
3.2. Topology IDs 3.2. Topology IDs
This document assumes the same definitions and procedures associated This document assumes the same definitions and procedures associated
with MPLS MT-ID as specified in [RFC7307]. with MPLS MT-ID as specified in [RFC7307].
4. MT Multipoint Capability 4. MT Multipoint Capability
The "MT Multipoint" capability is a new LDP capability, defined in The "MT Multipoint" capability is a new LDP capability, defined in
skipping to change at line 375 skipping to change at line 375
1. Topology-scoped mLDP FECs in LDP messages (Section 3.1) 1. Topology-scoped mLDP FECs in LDP messages (Section 3.1)
2. Topology-scoped mLDP forwarding setup (Section 6) 2. Topology-scoped mLDP forwarding setup (Section 6)
5. MT Applicability on FEC-Based Features 5. MT Applicability on FEC-Based Features
5.1. Typed Wildcard MP FEC Elements 5.1. Typed Wildcard MP FEC Elements
[RFC5918] extends the base LDP and defines the Typed Wildcard FEC [RFC5918] extends the base LDP and defines the Typed Wildcard FEC
Element framework. A Typed Wildcard FEC element can be used in any 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. LDP message to specify a wildcard operation for a given type of FEC.
The MT extensions defined in this document do not require any The MT extensions defined in this document do not require any
extension to procedures for support of the Typed Wildcard FEC Element extension to procedures for support of the Typed Wildcard FEC Element
[RFC5918], and these procedures apply as is to Multipoint MT FEC [RFC5918], and these procedures apply as is to Multipoint MT FEC
wildcarding. Similar to the Typed Wildcard MT Prefix FEC Element, as wildcarding. Similar to the Typed Wildcard MT Prefix FEC element, as
defined in [RFC7307], the MT extensions allow the use of "MT IP" or 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 "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 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 FECs in the context of a given (sub-)topology as identified by the
"MT-ID" and "IPA" fields. "MT-ID" and "IPA" fields.
This document defines the following format and encoding for a Typed This document defines the following format and encoding for a Typed
Wildcard MP FEC element: Wildcard MP FEC Element:
0 1 2 3 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 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 ..| |Typed Wcard (5)| Type = MP FEC | Len = 6 | AF = MT IP ..|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|... or MT IPv6 | Reserved | IPA | MT-ID | |... or MT IPv6 | Reserved | IPA | MT-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|MT-ID (cont.) | |MT-ID (cont.) |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 5: Data Format for the Typed Wildcard MT MP FEC Element Figure 5: Data Format for the Typed Wildcard MT MP FEC Element
Where: Where:
Type: One of the MP FEC Element types (P2MP, MP2MP-up, or MP2MP- Type: One of the MP FEC element types (P2MP, MP2MP-up, or MP2MP-
down) down)
MT-ID: MPLS MT-ID MT-ID: MPLS MT-ID
IPA: The IGP Algorithm IPA: The IGP Algorithm
The defined format allows a Label Switching Router (LSR) to perform The defined format allows a Label Switching Router (LSR) to perform
wildcard MP FEC operations under the scope of a (sub-)topology. wildcard MP FEC operations under the scope of a (sub-)topology.
5.2. End-of-LIB 5.2. End-of-LIB
[RFC5919] specifies extensions and procedures that allow an LDP [RFC5919] specifies extensions and procedures that allow an LDP
speaker to signal its End-of-LIB (Label Information Base) for a given 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 FEC type to a peer. By leveraging the End-of-LIB message, LDP
ensures that label distribution remains consistent and reliable, even ensures that label distribution remains consistent and reliable, even
during network disruptions or maintenance activities. The MT during network disruptions or maintenance activities. The MT
extensions for MP FEC do not require any modifications to these extensions for MP FEC do not require any modifications to these
procedures and apply as they are to MT MP FEC elements. procedures and apply as they are to MT MP FEC elements.
Consequently, an MT mLDP speaker MAY signal its convergence per Consequently, an MT mLDP speaker MAY signal its convergence per
(sub-)topology using the MT Typed Wildcard MP FEC element. (sub-)topology using the MT Typed Wildcard MP FEC Element.
6. Topology-Scoped Signaling and Forwarding 6. Topology-Scoped Signaling and Forwarding
Since the {MT-ID, IPA} tuple is part of an mLDP FEC, there is no need 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 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 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 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 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 label in the table. However, in order to implement MTR in an mLDP
network, the selection procedures for an upstream LSR and a network, the selection procedures for an upstream LSR and a
 End of changes. 15 change blocks. 
19 lines changed or deleted 19 lines changed or added

This html diff was produced by rfcdiff 1.48.