MPLS Working Group IJ. Wijnands Internet-Draft Individual Updates: 7307 (if approved) M. Mishra (Editor) Intended status: Standards Track K. Raza Expires: 21 November 2024 Cisco Systems, Inc. Z. Zhang Juniper Networks A. Gulko Edward Jones wealth management 20 May 2024 mLDP Extensions for Multi-Topology Routing draft-ietf-mpls-mldp-multi-topology-09 Abstract Multi-Topology Routing (MTR) is a technology to enable service differentiation within an IP network. Flexible Algorithm (FA) is another mechanism of creating a sub-topology within a topology using defined topology constraints and computation algorithm. In order to deploy mLDP (Multipoint label distribution protocol) in a network that supports MTR, FA, or other methods of signaling non-default IGP algorithms, mLDP is required to become topology and algorithm aware. This document specifies extensions to mLDP to support MTR, with an algorithm, in order for Multipoint LSPs(Label Switched Paths) to follow a particular topology and algorithm. It updates [RFC7307] by allocating eight bits from a previously reserved field to be used as the IGP Algorithm (IPA) field. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 21 November 2024. Wijnands, et al. Expires 21 November 2024 [Page 1] Internet-Draft Multi-Topology mLDP May 2024 Copyright Notice Copyright (c) 2024 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) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Specification of Requirements . . . . . . . . . . . . . . . . 4 4. MT Scoped mLDP FECs . . . . . . . . . . . . . . . . . . . . . 4 4.1. MP FEC Extensions for MT . . . . . . . . . . . . . . . . 5 4.1.1. MP FEC Element . . . . . . . . . . . . . . . . . . . 5 4.1.2. MT IP Address Families . . . . . . . . . . . . . . . 6 4.1.3. MT MP FEC Element . . . . . . . . . . . . . . . . . . 6 4.2. Topology IDs . . . . . . . . . . . . . . . . . . . . . . 7 5. MT Multipoint Capability . . . . . . . . . . . . . . . . . . 8 6. MT Applicability on FEC-based features . . . . . . . . . . . 9 6.1. Typed Wildcard MP FEC Elements . . . . . . . . . . . . . 9 6.2. End-of-LIB . . . . . . . . . . . . . . . . . . . . . . . 10 7. Topology-Scoped Signaling and Forwarding . . . . . . . . . . 10 7.1. Upstream LSR selection . . . . . . . . . . . . . . . . . 10 7.2. Downstream forwarding interface selection . . . . . . . . 10 8. LSP Ping Extensions . . . . . . . . . . . . . . . . . . . . . 11 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 11 9.1. Cisco Systems . . . . . . . . . . . . . . . . . . . . . . 12 10. Security Considerations . . . . . . . . . . . . . . . . . . . 12 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 12. Contributor . . . . . . . . . . . . . . . . . . . . . . . . . 13 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 14.1. Normative References . . . . . . . . . . . . . . . . . . 13 14.2. Informative References . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 1. Glossary FA - Flexible Algorithm Wijnands, et al. Expires 21 November 2024 [Page 2] Internet-Draft Multi-Topology mLDP May 2024 FEC - Forwarding Equivalence Class IGP - Interior Gateway Protocol IPA - IGP Algorithm LDP - Label Distribution Protocol LSP - Label Switched Path mLDP - Multipoint LDP MP - Multipoint (P2MP or MP2MP) MP2MP - Multipoint-to-Multipoint MT - Multi-Topology MT-ID - Multi-Topology Identifier MTR - Multi-Topology Routing MVPN - Multicast over Virtual Private Network defined in section 2.3 of [RFC6513] P2MP - Point-to-Multipoint PMSI - Provider Multicast Service Interfaces [RFC6513] 2. Introduction Multi-Topology Routing (MTR) is a technology to enable service differentiation within an IP network. IGP protocols (OSPF and IS-IS) and LDP have already been extended to support MTR. To support MTR, an IGP maintains independent IP topologies, termed as "Multi- Topologies" (MT), and computes/installs routes per topology. OSPF extensions [RFC4915] and IS-IS extensions [RFC5120] specify the MT extensions under respective IGPs. To support IGP MT, similar LDP extensions [RFC7307] have been specified to make LDP MT-aware and be able to setup unicast Label Switched Paths (LSPs) along IGP MT routing paths. A more lightweight mechanism to define constraint-based topologies is the Flexible Algorithm (FA) [RFC9350]. FA can be seen as creating a sub-topology within a topology using defined topology constraints and computation algorithms. This can be done 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 documented in Wijnands, et al. Expires 21 November 2024 [Page 3] Internet-Draft Multi-Topology mLDP May 2024 [RFC9350]. A flexible Algorithm is a mechanism to create a sub- topology, but in the future, different algorithms might be defined for how to achieve that. For that reason, in the remainder of this document, we'll refer to this as the IGP Algorithm. The IGP Algorithm (IPA) Field Section 4.1.2 Section 6.1 is an 8-bit identifier for the algorithm. The permissible values are tracked in the IANA IGP Algorithm Types registry [IANA-IGP-ALGO-TYPES]. Throughout this document, the term Flexible Algorithm (FA) shall denote the process of generating a sub-topology and signaling it through Interior Gateway Protocol (IGP). However, it is essential to note that the procedures outlined in this document are not exclusively applicable to Flexible Algorithm but are extendable to any non-default algorithm as well. Multipoint LDP (mLDP) refers to extensions in LDP to setup multi- point LSPs (point-to-multipoint (P2MP) or multipoint-to-multipoint (MP2MP)), by means of a set of extensions and procedures defined in [RFC6388]. In order to deploy mLDP in a network that supports MTR and FA, mLDP is required to become topology and algorithm aware. This document specifies extensions to mLDP to support MTR/IGP Algorithm such that when building a Multi-Point LSPs it can follow a particular topology and algorithm. This means that the identifier for the particular topology to be used by mLDP have to become a 2-tuple (MTR Topology Id, IGP Algorithm). 3. Specification of Requirements 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. 4. MT Scoped mLDP FECs As defined in [RFC7307], MPLS Multi-Topology Identifier (MT-ID) is an identifier that is used to associate an LSP with a certain MTR topology. In the context of MP LSPs, this identifier is part of the mLDP FEC encoding so that LDP peers are able to setup an MP LSP via their own defined MTR policy. In order to avoid conflicting MTR policies for the same mLDP FEC, the MT-ID needs to be a part of the FEC, so that different MT-ID values will result in unique MP-LSP FEC elements. Wijnands, et al. Expires 21 November 2024 [Page 4] Internet-Draft Multi-Topology mLDP May 2024 The same applies to the IGP Algorithm. The IGP Algorithm needs to be encoded as part of the mLDP FEC to create unique MP-LSPs. The IGP Algorithm is also used to signal to mLDP (hop-by-hop) which Algorithm needs to be used to create the MP-LSP. Since the MT-ID and IGP Algorithm are part of the FEC, they apply to all the LDP messages that potentially include an mLDP FEC element. 4.1. MP FEC Extensions for MT The following subsections define the extensions to bind an mLDP FEC to a topology. These mLDP MT extensions reuse some of the extensions specified in [RFC7307]. 4.1.1. MP FEC Element Base mLDP specification [RFC6388] defines MP FEC Element 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MP FEC type | Address Family | AF Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Root Node Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Opaque Length | Opaque Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: MP FEC Element Format [RFC6388] Where the "Root Node Address" encoding is defined according to the given "Address Family" with its length (in octets) specified by the "AF Length" field. To extend MP FEC elements for MT, the {MT-ID, IPA} tuple is relevant in the context of the root address of the MP LSP. This tuple determines the (sub)-topology in which the root address needs to be resolved. As the {MT-ID, IPA} tuple should be considered part of the mLDP FEC, it is most naturally encoded as part of the root address. Wijnands, et al. Expires 21 November 2024 [Page 5] Internet-Draft Multi-Topology mLDP May 2024 4.1.2. MT IP Address Families [RFC7307] specifies new address families, named "MT IP" and "MT IPv6," to allow for the specification of an IP prefix within a topology scope. In addition to using these address families for mLDP, 8 bits of the 16-bit Reserved field are utilized to encode the IGP Algorithm. The resulting format of the data associated with these new Address Families 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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 MT IP Address Families Data Format Where: IPv4/IPv6 Address: An IP address corresponding to "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. 4.1.3. MT MP FEC Element By using the extended MT IP Address Family, the resulting MT MP FEC element should be encoded as follows: Wijnands, et al. Expires 21 November 2024 [Page 6] Internet-Draft Multi-Topology mLDP May 2024 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: IP MT-Scoped MP FEC Element Format 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 case of "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 label 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 Multipoint-to-Multipoint (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 Format" form of the respective FEC elements MUST be used in these two cases. 4.2. Topology IDs This document assumes the same definitions and procedures associated with MPLS MT-ID as specified in [RFC7307] specification. Wijnands, et al. Expires 21 November 2024 [Page 7] Internet-Draft Multi-Topology mLDP May 2024 5. MT Multipoint Capability The "MT Multipoint Capability" is a new LDP capability, defined in accordance with the LDP Capability definition guidelines outlined in [RFC5561]. An mLDP speaker advertises this capability to its peers to announce its support for MTR and the procedures specified 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: MT Multipoint Capability TLV Format Where: U- and F-bits: MUST be 1 and 0, respectively, as per Section 3 of LDP Capabilities [RFC5561]. MT Multipoint Capability: TLV type. Length: The length (in octets) of TLV. The value of this field MUST be 1 as there is no Capability-specific data [RFC5561] that follows in the TLV. 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 "MT Multipoint" capability MUST support the following: 1. Topology-scoped mLDP FECs in LDP messages (Section 4.1) 2. Topology-scoped mLDP forwarding setup (Section 7) Wijnands, et al. Expires 21 November 2024 [Page 8] Internet-Draft Multi-Topology mLDP May 2024 6. MT Applicability on FEC-based features 6.1. Typed Wildcard MP FEC Elements [RFC5918] extends base LDP and defines Typed Wildcard FEC Element framework. 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 Typed Wildcard FEC Element support [RFC5918], and these procedures apply as-is to Multipoint MT FEC wildcarding. Similar to 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 field. 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 (contd.) | +-+-+-+-+-+-+-+-+ Figure 5: Typed Wildcard MT MP FEC Element Where: Type: One of MP FEC Element type (P2MP, MP2MPup, MP2MP-down). MT ID: MPLS MT ID IPA: The IGP Algorithm The defined format allows an LSR to perform wildcard MP FEC operations under the scope of a (sub-)topology. Wijnands, et al. Expires 21 November 2024 [Page 9] Internet-Draft Multi-Topology mLDP May 2024 6.2. End-of-LIB [RFC5919] specifies extensions and procedures that allow an LDP speaker to signal its End-of-LIB 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-is 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. 7. 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 upstream LSR and downstream forwarding interface need to be changed. 7.1. Upstream LSR selection The procedures as described in RFC-6388 section-2.4.1.1 depend on the best path to reach the root. When the {MT-ID, IPA} tuple is signaled as part of the FEC, this tuple is 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, a LDP peer is selected following the procedures as defined in [RFC6388]. 7.2. Downstream forwarding interface selection The procedures as described in RFC-6388 section-2.4.1.2 describe how a downstream forwarding interface is selected. In these procedures, any interface leading to the downstream LDP neighbor can be considered as 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. Wijnands, et al. Expires 21 November 2024 [Page 10] Internet-Draft Multi-Topology mLDP May 2024 8. 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 "Target FEC Stack" TLV of an MPLS echo request message [RFC8029]. To support LSP ping for MT Multipoint 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 P2MP/MP2MP LDP FEC Stack Sub-TLV in [RFC6425]. The only difference is that the Root LSR address is now (sub-)topology scoped. 9. Implementation Status [Note to the RFC Editor - remove this section before publication, as well as remove the reference to [RFC7942] This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in [RFC7942] . The description of implementations in this section is intended to Wijnands, et al. Expires 21 November 2024 [Page 11] Internet-Draft Multi-Topology mLDP May 2024 assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist. According to [RFC7942] , "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit". 9.1. Cisco Systems The feature has been implemented on IOS-XR. * Organization: Cisco Systems * Implementation: Cisco systems IOS-XR has an implementation. Capability has been used from [RFC7307] and plan to update the value once IANA assigns new value. * Description: The implementation has been done. * Maturity Level: Product * Contact: mankamis@cisco.com 10. Security Considerations This extension to mLDP does not introduce any new security considerations beyond that already applied to the base LDP specification [RFC5036], LDP extensions for Multi-Topology specification [RFC7307] base mLDP specification [RFC6388], and MPLS security framework [RFC5920]. 11. IANA Considerations This document defines a new LDP capability parameter TLV. IANA is requested to assign the lowest available value after 0x0500 from "TLV Type Name Space" in the "Label Distribution Protocol (LDP) Parameters" registry within "Label Distribution Protocol (LDP) Name Spaces" as the new code point for the LDP TLV code point. Wijnands, et al. Expires 21 November 2024 [Page 12] Internet-Draft Multi-Topology mLDP May 2024 +-----+------------------+---------------+-------------------------+ |Value| Description | Reference | Notes/Registration Date | +-----+------------------+---------------+-------------------------+ | TBA | MT Multipoint | This document | | | | Capability | | | +-----+------------------+---------------+-------------------------+ Figure 7: IANA Code Point 12. Contributor Anuj Budhiraja Cisco systems 13. Acknowledgments The authors would like to acknowledge Eric Rosen for his input on this specification. 14. References 14.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC 4915, DOI 10.17487/RFC4915, June 2007, . [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)", RFC 5120, DOI 10.17487/RFC5120, February 2008, . [RFC6388] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B. Thomas, "Label Distribution Protocol Extensions for Point- to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", RFC 6388, DOI 10.17487/RFC6388, November 2011, . Wijnands, et al. Expires 21 November 2024 [Page 13] Internet-Draft Multi-Topology mLDP May 2024 [RFC6425] Saxena, S., Ed., Swallow, G., Ali, Z., Farrel, A., Yasukawa, S., and T. Nadeau, "Detecting Data-Plane Failures in Point-to-Multipoint MPLS - Extensions to LSP Ping", RFC 6425, DOI 10.17487/RFC6425, November 2011, . [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 2012, . [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, . [RFC7307] Zhao, Q., Raza, K., Zhou, C., Fang, L., Li, L., and D. King, "LDP Extensions for Multi-Topology", RFC 7307, DOI 10.17487/RFC7307, July 2014, . [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016, . [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., Aldrin, S., and M. Chen, "Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures", RFC 8029, DOI 10.17487/RFC8029, March 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC9350] Psenak, P., Ed., Hegde, S., Filsfils, C., Talaulikar, K., and A. Gulko, "IGP Flexible Algorithm", RFC 9350, DOI 10.17487/RFC9350, February 2023, . 14.2. Informative References [IANA-IGP-ALGO-TYPES] "IGP Algorithm Types", . Wijnands, et al. Expires 21 November 2024 [Page 14] Internet-Draft Multi-Topology mLDP May 2024 [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, October 2007, . [RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL. Le Roux, "LDP Capabilities", RFC 5561, DOI 10.17487/RFC5561, July 2009, . [RFC5918] Asati, R., Minei, I., and B. Thomas, "Label Distribution Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class (FEC)", RFC 5918, DOI 10.17487/RFC5918, August 2010, . [RFC5919] Asati, R., Mohapatra, P., Chen, E., and B. Thomas, "Signaling LDP Label Advertisement Completion", RFC 5919, DOI 10.17487/RFC5919, August 2010, . [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, . Authors' Addresses IJsbrand Wijnands Individual Email: ice@braindump.be Mankamana Mishra 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 Wijnands, et al. Expires 21 November 2024 [Page 15] Internet-Draft Multi-Topology mLDP May 2024 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 Wijnands, et al. Expires 21 November 2024 [Page 16]