idnits 2.17.1 draft-wijnands-mpls-mldp-multi-topology-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (25 October 2021) is 907 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-26) exists of draft-ietf-lsr-flex-algo-17 ** Obsolete normative reference: RFC 4379 (Obsoleted by RFC 8029) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group IJ. Wijnands 3 Internet-Draft Individual 4 Intended status: Standards Track K. Raza 5 Expires: 28 April 2022 M. Mishra 6 A. Budhiraja 7 Cisco Systems, Inc. 8 Z. Zhang 9 Juniper Networks 10 A. Gulko 11 Edward Jones wealth management 12 25 October 2021 14 mLDP Extensions for Multi-Topology Routing 15 draft-wijnands-mpls-mldp-multi-topology-03 17 Abstract 19 Multi-Topology Routing (MTR) is a technology to enable service 20 differentiation within an IP network. Flexible Algorithm (FA) is 21 another mechanism of creating a sub-topology within a topology using 22 defined topology constraints and computation algorithm. In order to 23 deploy mLDP in a network that supports MTR and/or FA, mLDP is 24 required to become topology and FA aware. This document specifies 25 extensions to mLDP to support MTR with FA such that when building a 26 Multi-Point LSPs it can follow a particular topology and algorithm. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on 28 April 2022. 45 Copyright Notice 47 Copyright (c) 2021 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 52 license-info) in effect on the date of publication of this document. 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. Code Components 55 extracted from this document must include Simplified BSD License text 56 as described in Section 4.e of the Trust Legal Provisions and are 57 provided without warranty as described in the Simplified BSD License. 59 Table of Contents 61 1. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Specification of Requirements . . . . . . . . . . . . . . . . 4 64 4. MT Scoped mLDP FECs . . . . . . . . . . . . . . . . . . . . . 4 65 4.1. MP FEC Extensions for MT . . . . . . . . . . . . . . . . 4 66 4.1.1. MP FEC Element . . . . . . . . . . . . . . . . . . . 5 67 4.1.2. MT IP Address Families . . . . . . . . . . . . . . . 5 68 4.1.3. MT MP FEC Element . . . . . . . . . . . . . . . . . . 6 69 4.2. Topology IDs . . . . . . . . . . . . . . . . . . . . . . 7 70 5. MT Multipoint Capability . . . . . . . . . . . . . . . . . . 8 71 6. MT Applicability on FEC-based features . . . . . . . . . . . 9 72 6.1. Typed Wildcard MP FEC Elements . . . . . . . . . . . . . 9 73 6.2. End-of-LIB . . . . . . . . . . . . . . . . . . . . . . . 10 74 7. Topology-Scoped Signaling and Forwarding . . . . . . . . . . 10 75 7.1. Upstream LSR selection . . . . . . . . . . . . . . . . . 10 76 7.2. Downstream forwarding interface selection . . . . . . . . 10 77 8. LSP Ping Extensions . . . . . . . . . . . . . . . . . . . . . 10 78 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 79 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 80 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 81 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 82 12.1. Normative References . . . . . . . . . . . . . . . . . . 12 83 12.2. Informative References . . . . . . . . . . . . . . . . . 13 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 86 1. Glossary 88 MT - Multi-Topology 90 MT-ID - Multi-Topology Identifier 92 MTR - Multi-Topology Routing 94 IGP - Interior Gateway Protocol 96 MP - Multipoint (P2MP or MP2MP) 97 LDP - Label Distribution Protocol 99 mLDP - Multipoint LDP 101 P2MP - Point-to-Multipoint 103 MP2MP - Multipoint-to-Multipoint 105 FEC - Forwarding Equivalence Class 107 LSP - Label Switched Path 109 FA - Flexible Algorithm 111 IPA - IGP Algorithm 113 2. Introduction 115 Multi-Topology Routing (MTR) is a technology to enable service 116 differentiation within an IP network. IGP protocols (OSPF and IS-IS) 117 and LDP have already been extended to support MTR. To support MTR, 118 an IGP maintains independent IP topologies, termed as "Multi- 119 Topologies" (MT), and computes/installs routes per topology. OSPF 120 extensions [RFC4915] and ISIS extensions [RFC5120] specify the MT 121 extensions under respective IGPs. To support IGP MT, similar LDP 122 extensions [RFC7307] have been specified to make LDP MT-aware and be 123 able to setup unicast Label Switched Paths (LSPs) along IGP MT 124 routing paths. 126 A more light weight mechanism to define constraint-based topologies 127 is Flexible Algorithm (FA) [I-D.ietf-lsr-flex-algo]. FA can be seen 128 as creating a sub-topology within a topology using defined topology 129 constraints and computation algorithm. This can be done within a MTR 130 topology or just the default Topology. An instance of such a sub- 131 topology is identified by a 1 octet value as documented in 132 [I-D.ietf-lsr-flex-algo]). Flexible Algorithm is a mechanism to 133 create a sub-topology, but in the future different algorithms might 134 be defined on how to achieve that. For that reason, in the remainder 135 of this document we'll refer to this as the IGP Algorithm (IPA). 137 Multipoint LDP (mLDP) refers to extensions in LDP to setup multi- 138 point LSPs (point-to-multipoint (P2MP) or multipoint-to-multipoint 139 (MP2MP)), by means of set of extensions and procedures defined in 140 [RFC6388]. In order to deploy mLDP in a network that supports MTR 141 and FA, mLDP is required to become topology and algorithm aware. 142 This document specifies extensions to mLDP to support MTR/IPA such 143 that when building a Multi-Point LSPs it can follow a particular 144 topology and alogirthm. This means that the identifier for the 145 particular Topology to be used by mLDP have to become a two tuple 146 (MTR Topology Id, IGP Algorithm). 148 3. Specification of Requirements 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 152 document are to be interpreted as described in [RFC2119]. 154 In this document, these words will appear with that interpretation 155 only when in ALL CAPS. Lower case uses of these words are not to be 156 interpreted as carrying RFC-2119 significance. 158 4. MT Scoped mLDP FECs 160 As defined in [RFC7307], MPLS Multi-Topology Identifier (MT-ID) is an 161 identifier that is used to associate an LSP with a certain MTR 162 topology. In the context of MP LSPs, this identifier is part of the 163 mLDP FEC encoding so that LDP peers are able to setup an MP LSP via 164 their own defined MTR policy. In order to avoid conflicting MTR 165 policies for the same mLDP FEC, the MT-ID needs to be a part of the 166 FEC, so that different MT-ID values will result in unique MP-LSP FEC 167 elements. 169 The same applies to the IPA. The IPA needs to be encoded as part of 170 the mLDP FEC to create unique MP-LSPs and at the same time is used to 171 signal to mLDP (hop-by-hop) which Algorithm needs to be used to 172 create the MP-LSP. 174 Since the MT-ID and IPA are part of the FEC, they apply to all the 175 LDP messages that potentially include an mLDP FEC element. 177 4.1. MP FEC Extensions for MT 179 Following subsections propose the extensions to bind an mLDP FEC to a 180 topology. The mLDP MT extensions reuse some of the extensions 181 specified in [RFC7307]. 183 4.1.1. MP FEC Element 185 Base mLDP specification [RFC6388] defines MP FEC Element as follows: 187 0 1 2 3 188 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 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | MP FEC type | Address Family | AF Length | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 | Root Node Address | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | Opaque Length | Opaque Value | 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 196 ~ ~ 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 Figure 1: MP FEC Element Format [RFC6388] 201 Where "Root Node Address" encoding is as defined for given "Address 202 Family", and whose length (in octets) is specified by the "AF Length" 203 field. 205 To extend MP FEC elements for MT, the {MT-ID, IPA} is a tuple that is 206 relevant in the context of the root address of the MP LSP. The {MT- 207 ID, IPA} tuple determines in which (sub)-topology the root address 208 needs to be resolved. Since the {MT-ID, IPA} tuple should be 209 considered part of the mLDP FEC, the most natural place to encode 210 this tuple is as part of the root address. While encoding it, we 211 also propose to use "MT IP" Address Families as described in 212 following sub section. 214 4.1.2. MT IP Address Families 216 [RFC7307] has specified new address families, named "MT IP" and "MT 217 IPv6", to allow specification of an IP prefix within a topology 218 scope. In addition to using this address family for mLDP, we also 219 use 8 bits of the 16 bits Reserved field to encode the IGP Algorithm 220 (IPA) Registry. The resulting format of the data associated with 221 these new Address Families is as follows: 223 0 1 2 3 224 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 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | IPv4 Address | 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | Reserved | IPA | MT-ID | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 0 1 2 3 232 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 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | IPv6 Address | 235 | | 236 | | 237 | | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | Reserved | IPA | MT-ID | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 Figure 2: Modified MT IP Address Families Data Format 244 Where: 246 IPv4/IPv6 Address: An IP address corresponding to "MT IP" and "MT 247 IPv6" address families respectively. 249 IPA: The IGP Algorithm, values are from the IGP Algorithm 250 registry. 252 Reserved: This 8-bit field MUST be zero. If a message is received 253 that includes a MT address family where the 8 bit Reserved value 254 is not zero, the message must be discarded. 256 4.1.3. MT MP FEC Element 258 By using extended MT IP Address Family, the resultant MT MP FEC 259 element is to be encoded as follows: 261 0 1 2 3 262 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 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | MP FEC type | AF (MT IP/ MT IPv6) | AF Length | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | Root Node Address | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | Reserved | IPA | MT-ID | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | Opaque Length | Opaque Value | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 272 ~ ~ 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 Figure 3: IP MT-Scoped MP FEC Element Format 277 In the context of this document, the applicable LDP FECs for MT mLDP 278 include: 280 * MP FEC Elements: 282 - P2MP (type 0x6) 284 - MP2MP-up (type 0x7) 286 - MP2MP-down (type 0x8) 288 * Typed Wildcard FEC Element (type 0x5) 290 In case of "Typed Wildcard FEC Element", the sub FEC Element type 291 MUST be one of the MP FECs listed above. 293 This specification allows the use of Topology-scoped mLDP FECs in LDP 294 label and notification messages, as applicable. 296 4.2. Topology IDs 298 This document assumes the same definitions and procedures associated 299 with MPLS MT-ID as defined in [RFC7307] specification. 301 5. MT Multipoint Capability 303 "MT Multipoint Capability" is a new LDP capability, defined in 304 accordance with LDP Capability definition guidelines [RFC5561], that 305 is to be advertised to its peers by an mLDP speaker to announce its 306 capability to support MTR and the procedures specified in this 307 document. This capability MAY be sent either in an Initialization 308 message at the session establishment time, or in a Capability message 309 dynamically during the lifetime of a session (only if "Dynamic 310 Announcement" capability [RFC5561] has been successfully negotiated 311 with the peer). 313 The format of this capability is as follows: 315 0 1 2 3 316 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 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 |U|F| MT Multipoint Cap.(IANA) | Length | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 |S| Reserved | 321 +-+-+-+-+-+-+-+-+ 323 Figure 4: MT Multipoint Capability TLV Format 325 Where: 327 U- and F-bits: MUST be 1 and 0, respectively, as per Section 3 of 328 LDP Capabilities [RFC5561]. 330 MT Multipoint Capaility: TLV type (IANA assigned). 332 Length: The length (in octets) of TLV. The value of this field 333 MUST be 1 as there is no Capability-specific data [RFC5561] that 334 follows in the TLV. 336 S-bit: Set to 1 to announce and 0 to withdraw the capability (as 337 per [RFC5561]. 339 An mLDP speaker that has successfully advertised and negotiated "MT 340 Multipoint" capability MUST support the following: 342 1. Topology-scoped mLDP FECs in LDP messages (Section 4.1) 344 2. Topology-scoped mLDP forwarding setup (Section 7) 346 6. MT Applicability on FEC-based features 348 6.1. Typed Wildcard MP FEC Elements 350 [RFC5918] extends base LDP and defines Typed Wildcard FEC Element 351 framework. Typed Wildcard FEC element can be used in any LDP message 352 to specify a wildcard operation for a given type of FEC. 354 The MT extensions proposed in document do not require any extension 355 in procedures for Typed Wildcard FEC Element support [RFC5918], and 356 these procedures apply as-is to Multipoint MT FEC wildcarding. Like 357 Typed Wildcard MT Prefix FEC Element, as defined in [RFC7307], the MT 358 extensions allow use of "MT IP" or "MT IPv6" in the Address Family 359 field of the Typed Wildcard MP FEC element in order to use wildcard 360 operations for MP FECs in the context of a given (sub)-topology as 361 identified by the MT-ID and IPA field. 363 This document proposes following format and encoding for a Typed 364 Wildcard MP FEC element: 366 0 1 2 3 367 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 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 |Typed Wcard (5)| Type = MP FEC | Len = 6 | AF = MT IP ..| 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 |... or MT IPv6 | Reserved | IPA | MT-ID | 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 |MT ID (contd.) | 374 +-+-+-+-+-+-+-+-+ 376 Figure 5: Typed Wildcard MT MP FEC Element 378 Where: 380 Type: One of MP FEC Element type (P2MP, MP2MPup, MP2MP-down). 382 MT ID: MPLS MT ID 384 IPA: The IGP Algorithm, values are from the IGP Algorithm 385 registry. 387 The proposed format allows an LSR to perform wildcard MP FEC 388 operations under the scope of a (sub-)topology. 390 6.2. End-of-LIB 392 [RFC5919] specifies extensions and procedures that allows an LDP 393 speaker to signal its End-of-LIB (i.e. convergence) for a given FEC 394 type towards a peer. MT extensions for MP FEC do not require any 395 change in these procedures and they apply as-is to MT MP FEC 396 elements. This means that an MT mLDP speaker MAY signal its 397 convergence per (sub-)topology using MT Typed Wildcard MP FEC 398 element. 400 7. Topology-Scoped Signaling and Forwarding 402 Since the {MT-ID, IPA} tuple is part of an mLDP FEC, there is no need 403 to support the concept of multiple (sub-)topology forwarding tables 404 in mLDP. Each MP LSP will be unique due to the tuple being part of 405 the FEC. There is also no need to have specific label forwarding 406 tables per topology, and each MP LSP will have its own unique local 407 label in the table. However, In order to implement MTR in an mLDP 408 network, the selection procedures for upstream LSR and downstream 409 forwarding interface need to be changed. 411 7.1. Upstream LSR selection 413 The procedures as described in RFC-6388 section-2.4.1.1 depend on the 414 best path to reach the root. When the {MT-ID, IPA} tuple is signaled 415 as part of the FEC, this tuple is used to select the (sub-)topology 416 that must be used to find the best path to the root address. Using 417 the next-hop from this best path, a LDP peer is selected following 418 the procedures as defined in [RFC6388]. 420 7.2. Downstream forwarding interface selection 422 The procedures as described in RFC-6388 section-2.4.1.2 describe how 423 a downstream forwarding interface is selected. In these procedures, 424 any interface leading to the downstream LDP neighbor can be 425 considered as candidate forwarding interface. When the {MT-ID, IPA} 426 tuple is part of the FEC, this is no longer true. An interface must 427 only be selected if it is part of the same (sub-)topology that was 428 signaled in the mLDP FEC element. Besides this restriction, the 429 other procedures in [RFC6388] apply. 431 8. LSP Ping Extensions 433 [RFC6425] defines procedures to detect data plane failures in 434 Multipoint MPLS LSPs. Section 3.1.2 of [RFC6425] defines new Sub- 435 Types and Sub-TLVs for Multipoint LDP FECs to be sent in "Target FEC 436 Stack" TLV of an MPLS echo request message [RFC4379]. 438 To support LSP ping for MT Multipoint LSPs, this document uses 439 existing sub-types "P2MP LDP FEC Stack" and "MP2MP LDP FEC Stack" 440 defined in [RFC6425]. The proposed extension is to specify "MT IP" 441 or "MT IPv6" in the "Address Family" field, set the "Address Length" 442 field to 8 (for MT IP) or 20 (for MT IPv6), and encode the sub-TLV 443 with additional {MT-ID, IPA} information as an extension to the "Root 444 LSR Address" field. The resultant format of sub-tlv is as follows: 446 0 1 2 3 447 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 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 |Address Family (MT IP/MT IPv6) | Address Length| | 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 451 ~ Root LSR Address (Cont.) ~ 452 | | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | Reserved | IPA | MT-ID | 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 | Opaque Length | Opaque Value ... | 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 458 ~ ~ 459 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 | | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 Figure 6: Multipoint LDP FEC Stack Sub-TLV Format for MT 465 The rules and procedures of using this new sub-TLV in an MPLS echo 466 request message are same as defined for P2MP/MP2MP LDP FEC Stack Sub- 467 TLV in [RFC6425] with only difference being that Root LSR address is 468 now (sub-)topology scoped. 470 9. Security Considerations 472 This extension to mLDP does not introduce any new security 473 considerations beyond that already apply to the base LDP 474 specification [RFC5036], base mLDP specification [RFC6388], and MPLS 475 security framework [RFC5920]. 477 10. IANA Considerations 479 This document defines a new LDP capability parameter TLV. IANA is 480 requested to assign the lowest available value after 0x0500 from "TLV 481 Type Name Space" in the "Label Distribution Protocol (LDP) 482 Parameters" registry within "Label Distribution Protocol (LDP) Name 483 Spaces" as the new code point for the LDP TLV code point. 485 +-----+------------------+---------------+-------------------------+ 486 |Value| Description | Reference | Notes/Registration Date | 487 +-----+------------------+---------------+-------------------------+ 488 | TBA | MT Multipoint | This document | | 489 | | Capability | | | 490 +-----+------------------+---------------+-------------------------+ 492 Figure 7: IANA Code Point 494 11. Acknowledgments 496 The authors would like to acknowledge Eric Rosen for his input on 497 this specification. 499 12. References 501 12.1. Normative References 503 [I-D.ietf-lsr-flex-algo] 504 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 505 A. Gulko, "IGP Flexible Algorithm", Work in Progress, 506 Internet-Draft, draft-ietf-lsr-flex-algo-17, 6 July 2021, 507 . 510 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 511 Requirement Levels", BCP 14, RFC 2119, 512 DOI 10.17487/RFC2119, March 1997, 513 . 515 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 516 Label Switched (MPLS) Data Plane Failures", RFC 4379, 517 DOI 10.17487/RFC4379, February 2006, 518 . 520 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 521 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 522 RFC 4915, DOI 10.17487/RFC4915, June 2007, 523 . 525 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 526 Topology (MT) Routing in Intermediate System to 527 Intermediate Systems (IS-ISs)", RFC 5120, 528 DOI 10.17487/RFC5120, February 2008, 529 . 531 [RFC6388] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B. 532 Thomas, "Label Distribution Protocol Extensions for Point- 533 to-Multipoint and Multipoint-to-Multipoint Label Switched 534 Paths", RFC 6388, DOI 10.17487/RFC6388, November 2011, 535 . 537 [RFC6425] Saxena, S., Ed., Swallow, G., Ali, Z., Farrel, A., 538 Yasukawa, S., and T. Nadeau, "Detecting Data-Plane 539 Failures in Point-to-Multipoint MPLS - Extensions to LSP 540 Ping", RFC 6425, DOI 10.17487/RFC6425, November 2011, 541 . 543 [RFC7307] Zhao, Q., Raza, K., Zhou, C., Fang, L., Li, L., and D. 544 King, "LDP Extensions for Multi-Topology", RFC 7307, 545 DOI 10.17487/RFC7307, July 2014, 546 . 548 12.2. Informative References 550 [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., 551 "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, 552 October 2007, . 554 [RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL. 555 Le Roux, "LDP Capabilities", RFC 5561, 556 DOI 10.17487/RFC5561, July 2009, 557 . 559 [RFC5918] Asati, R., Minei, I., and B. Thomas, "Label Distribution 560 Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class 561 (FEC)", RFC 5918, DOI 10.17487/RFC5918, August 2010, 562 . 564 [RFC5919] Asati, R., Mohapatra, P., Chen, E., and B. Thomas, 565 "Signaling LDP Label Advertisement Completion", RFC 5919, 566 DOI 10.17487/RFC5919, August 2010, 567 . 569 [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS 570 Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, 571 . 573 Authors' Addresses 575 IJsbrand Wijnands 576 Individual 578 Email: ice@braindump.be 579 Kamran Raza 580 Cisco Systems, Inc. 581 2000 Innovation Drive 582 Kanata ON K2K-3E8 583 Canada 585 Email: skraza@cisco.com 587 Mankamana Mishra 588 Cisco Systems, Inc. 589 821 Alder Drive 590 Milpitas, CA 95035 591 United States of America 593 Email: mankamis@cisco.com 595 Anuj Budhiraja 596 Cisco Systems, Inc. 597 821 Alder Drive 598 Milpitas, CA 95035 599 United States of America 601 Email: abudhira@cisco.com 603 Zhaohui Zhang 604 Juniper Networks 605 10 Technology Park Dr. 606 Westford, MA 01886 607 United States of America 609 Email: zzhang@juniper.net 611 Arkadiy Gulko 612 Edward Jones wealth management 613 United States of America 615 Email: Arkadiy.gulko@edwardjones.com