idnits 2.17.1 draft-wijnands-mpls-mldp-multi-topology-04.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 (7 March 2022) is 780 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-18 ** 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: 8 September 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 7 March 2022 14 mLDP Extensions for Multi-Topology Routing 15 draft-wijnands-mpls-mldp-multi-topology-04 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 8 September 2022. 45 Copyright Notice 47 Copyright (c) 2022 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 Revised BSD License text as 56 described in Section 4.e of the Trust Legal Provisions and are 57 provided without warranty as described in the Revised 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 SHOULD be zero. 254 4.1.3. MT MP FEC Element 256 By using extended MT IP Address Family, the resultant MT MP FEC 257 element is to be encoded as follows: 259 0 1 2 3 260 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 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | MP FEC type | AF (MT IP/ MT IPv6) | AF Length | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | Root Node Address | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | Reserved | IPA | MT-ID | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | Opaque Length | Opaque Value | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 270 ~ ~ 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 Figure 3: IP MT-Scoped MP FEC Element Format 275 In the context of this document, the applicable LDP FECs for MT mLDP 276 include: 278 * MP FEC Elements: 280 - P2MP (type 0x6) 282 - MP2MP-up (type 0x7) 284 - MP2MP-down (type 0x8) 286 * Typed Wildcard FEC Element (type 0x5) 288 In case of "Typed Wildcard FEC Element", the sub FEC Element type 289 MUST be one of the MP FECs listed above. 291 This specification allows the use of Topology-scoped mLDP FECs in LDP 292 label and notification messages, as applicable. 294 4.2. Topology IDs 296 This document assumes the same definitions and procedures associated 297 with MPLS MT-ID as defined in [RFC7307] specification. 299 5. MT Multipoint Capability 301 "MT Multipoint Capability" is a new LDP capability, defined in 302 accordance with LDP Capability definition guidelines [RFC5561], that 303 is to be advertised to its peers by an mLDP speaker to announce its 304 capability to support MTR and the procedures specified in this 305 document. This capability MAY be sent either in an Initialization 306 message at the session establishment time, or in a Capability message 307 dynamically during the lifetime of a session (only if "Dynamic 308 Announcement" capability [RFC5561] has been successfully negotiated 309 with the peer). 311 The format of this capability is as follows: 313 0 1 2 3 314 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 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 |U|F| MT Multipoint Cap.(IANA) | Length | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 |S| Reserved | 319 +-+-+-+-+-+-+-+-+ 321 Figure 4: MT Multipoint Capability TLV Format 323 Where: 325 U- and F-bits: MUST be 1 and 0, respectively, as per Section 3 of 326 LDP Capabilities [RFC5561]. 328 MT Multipoint Capaility: TLV type (IANA assigned). 330 Length: The length (in octets) of TLV. The value of this field 331 MUST be 1 as there is no Capability-specific data [RFC5561] that 332 follows in the TLV. 334 S-bit: Set to 1 to announce and 0 to withdraw the capability (as 335 per [RFC5561]. 337 An mLDP speaker that has successfully advertised and negotiated "MT 338 Multipoint" capability MUST support the following: 340 1. Topology-scoped mLDP FECs in LDP messages (Section 4.1) 342 2. Topology-scoped mLDP forwarding setup (Section 7) 344 6. MT Applicability on FEC-based features 346 6.1. Typed Wildcard MP FEC Elements 348 [RFC5918] extends base LDP and defines Typed Wildcard FEC Element 349 framework. Typed Wildcard FEC element can be used in any LDP message 350 to specify a wildcard operation for a given type of FEC. 352 The MT extensions proposed in document do not require any extension 353 in procedures for Typed Wildcard FEC Element support [RFC5918], and 354 these procedures apply as-is to Multipoint MT FEC wildcarding. Like 355 Typed Wildcard MT Prefix FEC Element, as defined in [RFC7307], the MT 356 extensions allow use of "MT IP" or "MT IPv6" in the Address Family 357 field of the Typed Wildcard MP FEC element in order to use wildcard 358 operations for MP FECs in the context of a given (sub)-topology as 359 identified by the MT-ID and IPA field. 361 This document proposes following format and encoding for a Typed 362 Wildcard MP FEC element: 364 0 1 2 3 365 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 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 |Typed Wcard (5)| Type = MP FEC | Len = 6 | AF = MT IP ..| 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 |... or MT IPv6 | Reserved | IPA | MT-ID | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 |MT ID (contd.) | 372 +-+-+-+-+-+-+-+-+ 374 Figure 5: Typed Wildcard MT MP FEC Element 376 Where: 378 Type: One of MP FEC Element type (P2MP, MP2MPup, MP2MP-down). 380 MT ID: MPLS MT ID 382 IPA: The IGP Algorithm, values are from the IGP Algorithm 383 registry. 385 The proposed format allows an LSR to perform wildcard MP FEC 386 operations under the scope of a (sub-)topology. 388 6.2. End-of-LIB 390 [RFC5919] specifies extensions and procedures that allows an LDP 391 speaker to signal its End-of-LIB (i.e. convergence) for a given FEC 392 type towards a peer. MT extensions for MP FEC do not require any 393 change in these procedures and they apply as-is to MT MP FEC 394 elements. This means that an MT mLDP speaker MAY signal its 395 convergence per (sub-)topology using MT Typed Wildcard MP FEC 396 element. 398 7. Topology-Scoped Signaling and Forwarding 400 Since the {MT-ID, IPA} tuple is part of an mLDP FEC, there is no need 401 to support the concept of multiple (sub-)topology forwarding tables 402 in mLDP. Each MP LSP will be unique due to the tuple being part of 403 the FEC. There is also no need to have specific label forwarding 404 tables per topology, and each MP LSP will have its own unique local 405 label in the table. However, In order to implement MTR in an mLDP 406 network, the selection procedures for upstream LSR and downstream 407 forwarding interface need to be changed. 409 7.1. Upstream LSR selection 411 The procedures as described in RFC-6388 section-2.4.1.1 depend on the 412 best path to reach the root. When the {MT-ID, IPA} tuple is signaled 413 as part of the FEC, this tuple is used to select the (sub-)topology 414 that must be used to find the best path to the root address. Using 415 the next-hop from this best path, a LDP peer is selected following 416 the procedures as defined in [RFC6388]. 418 7.2. Downstream forwarding interface selection 420 The procedures as described in RFC-6388 section-2.4.1.2 describe how 421 a downstream forwarding interface is selected. In these procedures, 422 any interface leading to the downstream LDP neighbor can be 423 considered as candidate forwarding interface. When the {MT-ID, IPA} 424 tuple is part of the FEC, this is no longer true. An interface must 425 only be selected if it is part of the same (sub-)topology that was 426 signaled in the mLDP FEC element. Besides this restriction, the 427 other procedures in [RFC6388] apply. 429 8. LSP Ping Extensions 431 [RFC6425] defines procedures to detect data plane failures in 432 Multipoint MPLS LSPs. Section 3.1.2 of [RFC6425] defines new Sub- 433 Types and Sub-TLVs for Multipoint LDP FECs to be sent in "Target FEC 434 Stack" TLV of an MPLS echo request message [RFC4379]. 436 To support LSP ping for MT Multipoint LSPs, this document uses 437 existing sub-types "P2MP LDP FEC Stack" and "MP2MP LDP FEC Stack" 438 defined in [RFC6425]. The proposed extension is to specify "MT IP" 439 or "MT IPv6" in the "Address Family" field, set the "Address Length" 440 field to 8 (for MT IP) or 20 (for MT IPv6), and encode the sub-TLV 441 with additional {MT-ID, IPA} information as an extension to the "Root 442 LSR Address" field. The resultant format of sub-tlv is as follows: 444 0 1 2 3 445 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 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 |Address Family (MT IP/MT IPv6) | Address Length| | 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 449 ~ Root LSR Address (Cont.) ~ 450 | | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | Reserved | IPA | MT-ID | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | Opaque Length | Opaque Value ... | 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 456 ~ ~ 457 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 | | 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 Figure 6: Multipoint LDP FEC Stack Sub-TLV Format for MT 463 The rules and procedures of using this new sub-TLV in an MPLS echo 464 request message are same as defined for P2MP/MP2MP LDP FEC Stack Sub- 465 TLV in [RFC6425] with only difference being that Root LSR address is 466 now (sub-)topology scoped. 468 9. Security Considerations 470 This extension to mLDP does not introduce any new security 471 considerations beyond that already apply to the base LDP 472 specification [RFC5036], base mLDP specification [RFC6388], and MPLS 473 security framework [RFC5920]. 475 10. IANA Considerations 477 This document defines a new LDP capability parameter TLV. IANA is 478 requested to assign the lowest available value after 0x0500 from "TLV 479 Type Name Space" in the "Label Distribution Protocol (LDP) 480 Parameters" registry within "Label Distribution Protocol (LDP) Name 481 Spaces" as the new code point for the LDP TLV code point. 483 +-----+------------------+---------------+-------------------------+ 484 |Value| Description | Reference | Notes/Registration Date | 485 +-----+------------------+---------------+-------------------------+ 486 | TBA | MT Multipoint | This document | | 487 | | Capability | | | 488 +-----+------------------+---------------+-------------------------+ 490 Figure 7: IANA Code Point 492 11. Acknowledgments 494 The authors would like to acknowledge Eric Rosen for his input on 495 this specification. 497 12. References 499 12.1. Normative References 501 [I-D.ietf-lsr-flex-algo] 502 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 503 A. Gulko, "IGP Flexible Algorithm", Work in Progress, 504 Internet-Draft, draft-ietf-lsr-flex-algo-18, 25 October 505 2021, . 508 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 509 Requirement Levels", BCP 14, RFC 2119, 510 DOI 10.17487/RFC2119, March 1997, 511 . 513 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 514 Label Switched (MPLS) Data Plane Failures", RFC 4379, 515 DOI 10.17487/RFC4379, February 2006, 516 . 518 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 519 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 520 RFC 4915, DOI 10.17487/RFC4915, June 2007, 521 . 523 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 524 Topology (MT) Routing in Intermediate System to 525 Intermediate Systems (IS-ISs)", RFC 5120, 526 DOI 10.17487/RFC5120, February 2008, 527 . 529 [RFC6388] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B. 530 Thomas, "Label Distribution Protocol Extensions for Point- 531 to-Multipoint and Multipoint-to-Multipoint Label Switched 532 Paths", RFC 6388, DOI 10.17487/RFC6388, November 2011, 533 . 535 [RFC6425] Saxena, S., Ed., Swallow, G., Ali, Z., Farrel, A., 536 Yasukawa, S., and T. Nadeau, "Detecting Data-Plane 537 Failures in Point-to-Multipoint MPLS - Extensions to LSP 538 Ping", RFC 6425, DOI 10.17487/RFC6425, November 2011, 539 . 541 [RFC7307] Zhao, Q., Raza, K., Zhou, C., Fang, L., Li, L., and D. 542 King, "LDP Extensions for Multi-Topology", RFC 7307, 543 DOI 10.17487/RFC7307, July 2014, 544 . 546 12.2. Informative References 548 [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., 549 "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, 550 October 2007, . 552 [RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL. 553 Le Roux, "LDP Capabilities", RFC 5561, 554 DOI 10.17487/RFC5561, July 2009, 555 . 557 [RFC5918] Asati, R., Minei, I., and B. Thomas, "Label Distribution 558 Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class 559 (FEC)", RFC 5918, DOI 10.17487/RFC5918, August 2010, 560 . 562 [RFC5919] Asati, R., Mohapatra, P., Chen, E., and B. Thomas, 563 "Signaling LDP Label Advertisement Completion", RFC 5919, 564 DOI 10.17487/RFC5919, August 2010, 565 . 567 [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS 568 Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, 569 . 571 Authors' Addresses 573 IJsbrand Wijnands 574 Individual 575 Email: ice@braindump.be 576 Kamran Raza 577 Cisco Systems, Inc. 578 2000 Innovation Drive 579 Kanata ON K2K-3E8 580 Canada 581 Email: skraza@cisco.com 583 Mankamana Mishra 584 Cisco Systems, Inc. 585 821 Alder Drive 586 Milpitas, CA 95035 587 United States of America 588 Email: mankamis@cisco.com 590 Anuj Budhiraja 591 Cisco Systems, Inc. 592 821 Alder Drive 593 Milpitas, CA 95035 594 United States of America 595 Email: abudhira@cisco.com 597 Zhaohui Zhang 598 Juniper Networks 599 10 Technology Park Dr. 600 Westford, MA 01886 601 United States of America 602 Email: zzhang@juniper.net 604 Arkadiy Gulko 605 Edward Jones wealth management 606 United States of America 607 Email: Arkadiy.gulko@edwardjones.com