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