idnits 2.17.1 draft-wijnands-mpls-mldp-multi-topology-01.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 (November 26, 2020) is 1244 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) ** Obsolete normative reference: RFC 4379 (Obsoleted by RFC 8029) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 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: May 30, 2021 M. Mishra 6 A. Budhiraja 7 Cisco Systems, Inc. 8 Z. Zhang 9 Juniper Networks 10 A. Gulko 11 Edward Jones wealth management 12 November 26, 2020 14 mLDP Extensions for Multi-Topology Routing 15 draft-wijnands-mpls-mldp-multi-topology-01 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 May 30, 2021. 45 Copyright Notice 47 Copyright (c) 2020 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 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. Specification of Requirements . . . . . . . . . . . . . . . . 4 65 4. MT Scoped mLDP FECs . . . . . . . . . . . . . . . . . . . . . 4 66 4.1. MP FEC Extensions for MT . . . . . . . . . . . . . . . . 4 67 4.1.1. MP FEC Element . . . . . . . . . . . . . . . . . . . 5 68 4.1.2. MT IP Address Families . . . . . . . . . . . . . . . 5 69 4.1.3. MT MP FEC Element . . . . . . . . . . . . . . . . . . 6 70 4.2. Topology IDs . . . . . . . . . . . . . . . . . . . . . . 7 71 5. MT Multipoint Capability . . . . . . . . . . . . . . . . . . 7 72 6. MT Applicability on FEC-based features . . . . . . . . . . . 8 73 6.1. Typed Wildcard MP FEC Elements . . . . . . . . . . . . . 8 74 6.2. End-of-LIB . . . . . . . . . . . . . . . . . . . . . . . 9 75 7. Topology-Scoped Signaling and Forwarding . . . . . . . . . . 10 76 7.1. Upstream LSR selection . . . . . . . . . . . . . . . . . 10 77 7.2. Downstream forwarding interface selection . . . . . . . . 10 78 8. LSP Ping Extensions . . . . . . . . . . . . . . . . . . . . . 10 79 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 80 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 81 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 82 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 83 12.1. Normative References . . . . . . . . . . . . . . . . . . 12 84 12.2. Informative References . . . . . . . . . . . . . . . . . 13 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 87 1. Glossary 89 MT - Multi-Topology 91 MT-ID - Multi-Topology Identifier 92 MTR - Multi-Topology Routing 94 IGP - Interior Gateway Protocol 96 MP - Multipoint (P2MP or MP2MP) 98 LDP - Label Distribution Protocol 100 mLDP - Multipoint LDP 102 P2MP - Point-to-Multipoint 104 MP2MP - Multipoint-to-Multipoint 106 FEC - Forwarding Equivalence Class 108 LSP - Label Switched Path 110 FA - Flexible Algorithm 112 IPA - IGP Algorithm 114 2. Introduction 116 Multi-Topology Routing (MTR) is a technology to enable service 117 differentiation within an IP network. IGP protocols (OSPF and IS-IS) 118 and LDP have already been extended to support MTR. To support MTR, 119 an IGP maintains independent IP topologies, termed as "Multi- 120 Topologies" (MT), and computes/installs routes per topology. OSPF 121 extensions [RFC4915] and ISIS extensions [RFC5120] specify the MT 122 extensions under respective IGPs. To support IGP MT, similar LDP 123 extensions [RFC7307] have been specified to make LDP MT-aware and be 124 able to setup unicast Label Switched Paths (LSPs) along IGP MT 125 routing paths. 127 A more light weight mechanism to define constraint-based topologies 128 is Flexible Algorithm (FA) [I-D.hegdeppsenak-isis-sr-flex-algo]. FA 129 can be seen as creating a sub-topology within a topology using 130 defined topology constraints and computation algorithm. This can be 131 done within a MTR topology or just the default Topology. An instance 132 of such a sub-topology is identified by a 1 octet value as documented 133 in [I-D.hegdeppsenak-isis-sr-flex-algo]). Flexible Algorithm is a 134 mechanism to create a sub-topology, but in the future different 135 algorithms might be defined on how to achieve that. For that reason, 136 in the remainder of this document we'll refer to this as the IGP 137 Algorithm (IPA). 139 Multipoint LDP (mLDP) refers to extensions in LDP to setup multi- 140 point LSPs (point-to-multipoint (P2MP) or multipoint-to-multipoint 141 (MP2MP)), by means of set of extensions and procedures defined in 142 [RFC6388]. In order to deploy mLDP in a network that supports MTR 143 and FA, mLDP is required to become topology and algorithm aware. 144 This document specifies extensions to mLDP to support MTR/IPA such 145 that when building a Multi-Point LSPs it can follow a particular 146 topology and alogirthm. This means that the identifier for the 147 particular Topology to be used by mLDP have to become a two tuple 148 (MTR Topology Id, IGP Algorithm). 150 3. Specification of Requirements 152 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 153 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 154 document are to be interpreted as described in [RFC2119]. 156 In this document, these words will appear with that interpretation 157 only when in ALL CAPS. Lower case uses of these words are not to be 158 interpreted as carrying RFC-2119 significance. 160 4. MT Scoped mLDP FECs 162 As defined in [RFC7307], MPLS Multi-Topology Identifier (MT-ID) is an 163 identifier that is used to associate an LSP with a certain MTR 164 topology. In the context of MP LSPs, this identifier is part of the 165 mLDP FEC encoding so that LDP peers are able to setup an MP LSP via 166 their own defined MTR policy. In order to avoid conflicting MTR 167 policies for the same mLDP FEC, the MT-ID needs to be a part of the 168 FEC, so that different MT-ID values will result in unique MP-LSP FEC 169 elements. 171 The same applies to the IPA. The IPA needs to be encoded as part of 172 the mLDP FEC to create unique MP-LSPs and at the same time is used to 173 signal to mLDP (hop-by-hop) which Algorithm needs to be used to 174 create the MP-LSP. 176 Since the MT-ID and IPA are part of the FEC, they apply to all the 177 LDP messages that potentially include an mLDP FEC element. 179 4.1. MP FEC Extensions for MT 181 Following subsections propose the extensions to bind an mLDP FEC to a 182 topology. The mLDP MT extensions reuse some of the extensions 183 specified in [RFC7307]. 185 4.1.1. MP FEC Element 187 Base mLDP specification [RFC6388] defines MP FEC Element as follows: 189 0 1 2 3 190 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 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 | MP FEC type | Address Family | AF Length | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | Root Node Address | 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 | Opaque Length | Opaque Value | 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 198 ~ ~ 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 Figure 1: MP FEC Element Format [RFC6388] 203 Where "Root Node Address" encoding is as defined for given "Address 204 Family", and whose length (in octets) is specified by the "AF Length" 205 field. 207 To extend MP FEC elements for MT, the {MT-ID, IPA} is a tuple that is 208 relevant in the context of the root address of the MP LSP. The {MT- 209 ID, IPA} tuple determines in which (sub)-topology the root address 210 needs to be resolved. Since the {MT-ID, IPA} tuple should be 211 considered part of the mLDP FEC, the most natural place to encode 212 this tuple is as part of the root address. While encoding it, we 213 also propose to use "MT IP" Address Families as described in 214 following sub section. 216 4.1.2. MT IP Address Families 218 [RFC7307] has specified new address families, named "MT IP" and "MT 219 IPv6", to allow specification of an IP prefix within a topology 220 scope. In addition to using this address family for mLDP, we also 221 use 8 bits of the 16 bits Reserved field to encode the IGP Algorithm 222 (IPA) Registry. The resulting format of the data associated with 223 these new Address Families is as follows: 225 0 1 2 3 226 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 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | IPv4 Address | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | Reserved | IPA | MT-ID | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 0 1 2 3 234 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 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | IPv6 Address | 237 | | 238 | | 239 | | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | Reserved | IPA | MT-ID | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 Figure 2: Modified MT IP Address Families Data Format 246 Where: 248 IPv4/IPv6 Address: An IP address corresponding to "MT IP" and "MT 249 IPv6" address families respectively. 251 IPA: The IGP Algorithm, values are from the IGP Algorithm 252 registry. 254 Reserved: This 8-bit field MUST be zero. If a message is received 255 that includes a MT address family where the 8 bit Reserved value 256 is not zero, the message must be discarded. 258 4.1.3. MT MP FEC Element 260 By using extended MT IP Address Family, the resultant MT MP FEC 261 element is to be encoded as follows: 263 0 1 2 3 264 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 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | MP FEC type | AF (MT IP/ MT IPv6) | AF Length | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | Root Node Address | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | Reserved | IPA | MT-ID | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | Opaque Length | Opaque Value | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 274 ~ ~ 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 Figure 3: IP MT-Scoped MP FEC Element Format 279 In the context of this document, the applicable LDP FECs for MT mLDP 280 include: 282 o MP FEC Elements: 284 * P2MP (type 0x6) 286 * MP2MP-up (type 0x7) 288 * MP2MP-down (type 0x8) 290 o Typed Wildcard FEC Element (type 0x5) 292 In case of "Typed Wildcard FEC Element", the sub FEC Element type 293 MUST be one of the MP FECs listed above. 295 This specification allows the use of Topology-scoped mLDP FECs in LDP 296 label and notification messages, as applicable. 298 4.2. Topology IDs 300 This document assumes the same definitions and procedures associated 301 with MPLS MT-ID as defined in [RFC7307] specification. 303 5. MT Multipoint Capability 305 "MT Multipoint Capability" is a new LDP capability, defined in 306 accordance with LDP Capability definition guidelines [RFC5561], that 307 is to be advertised to its peers by an mLDP speaker to announce its 308 capability to support MTR and the procedures specified in this 309 document. This capability MAY be sent either in an Initialization 310 message at the session establishment time, or in a Capability message 311 dynamically during the lifetime of a session (only if "Dynamic 312 Announcement" capability [RFC5561] has been successfully negotiated 313 with the peer). 315 The format of this capability is as follows: 317 0 1 2 3 318 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 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 |U|F| MT Multipoint Cap.(IANA) | Length | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 |S| Reserved | 323 +-+-+-+-+-+-+-+-+ 325 Figure 4: MT Multipoint Capability TLV Format 327 Where: 329 U- and F-bits: MUST be 1 and 0, respectively, as per Section 3 of 330 LDP Capabilities [RFC5561]. 332 MT Multipoint Capaility: TLV type (IANA assigned). 334 Length: The length (in octets) of TLV. The value of this field 335 MUST be 1 as there is no Capability-specific data [RFC5561] that 336 follows in the TLV. 338 S-bit: Set to 1 to announce and 0 to withdraw the capability (as 339 per [RFC5561]. 341 An mLDP speaker that has successfully advertised and negotiated "MT 342 Multipoint" capability MUST support the following: 344 1. Topology-scoped mLDP FECs in LDP messages (Section 4.1) 346 2. Topology-scoped mLDP forwarding setup (Section 7) 348 6. MT Applicability on FEC-based features 350 6.1. Typed Wildcard MP FEC Elements 352 [RFC5918] extends base LDP and defines Typed Wildcard FEC Element 353 framework. Typed Wildcard FEC element can be used in any LDP message 354 to specify a wildcard operation for a given type of FEC. 356 The MT extensions proposed in document do not require any extension 357 in procedures for Typed Wildcard FEC Element support [RFC5918], and 358 these procedures apply as-is to Multipoint MT FEC wildcarding. Like 359 Typed Wildcard MT Prefix FEC Element, as defined in [RFC7307], the MT 360 extensions allow use of "MT IP" or "MT IPv6" in the Address Family 361 field of the Typed Wildcard MP FEC element in order to use wildcard 362 operations for MP FECs in the context of a given (sub)-topology as 363 identified by the MT-ID and IPA field. 365 This document proposes following format and encoding for a Typed 366 Wildcard MP FEC element: 368 0 1 2 3 369 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 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 |Typed Wcard (5)| Type = MP FEC | Len = 6 | AF = MT IP ..| 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 |... or MT IPv6 | Reserved | IPA | MT-ID | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 |MT ID (contd.) | 376 +-+-+-+-+-+-+-+-+ 378 Figure 5: Typed Wildcard MT MP FEC Element 380 Where: 382 Type: One of MP FEC Element type (P2MP, MP2MPup, MP2MP-down). 384 MT ID: MPLS MT ID 386 IPA: The IGP Algorithm, values are from the IGP Algorithm 387 registry. 389 The proposed format allows an LSR to perform wildcard MP FEC 390 operations under the scope of a (sub-)topology. 392 6.2. End-of-LIB 394 [RFC5919] specifies extensions and procedures that allows an LDP 395 speaker to signal its End-of-LIB (i.e. convergence) for a given FEC 396 type towards a peer. MT extensions for MP FEC do not require any 397 change in these procedures and they apply as-is to MT MP FEC 398 elements. This means that an MT mLDP speaker MAY signal its 399 convergence per (sub-)topology using MT Typed Wildcard MP FEC 400 element. 402 7. Topology-Scoped Signaling and Forwarding 404 Since the {MT-ID, IPA} tuple is part of an mLDP FEC, there is no need 405 to support the concept of multiple (sub-)topology forwarding tables 406 in mLDP. Each MP LSP will be unique due to the tuple being part of 407 the FEC. There is also no need to have specific label forwarding 408 tables per topology, and each MP LSP will have its own unique local 409 label in the table. However, In order to implement MTR in an mLDP 410 network, the selection procedures for upstream LSR and downstream 411 forwarding interface need be changed. 413 7.1. Upstream LSR selection 415 The procedures as described in RFC-6388 section-2.4.1.1 depend on the 416 best path to reach the root. When the {MT-ID, IPA} tuple is signaled 417 as part of the FEC, this tuple is used to select the (sub-)topology 418 that must be used to find the best path to the root address. Using 419 the next-hop from this best path, a LDP peer is selected following 420 the procedures as defined in [RFC6388]. 422 7.2. Downstream forwarding interface selection 424 The procedures as described in RFC-6388 section-2.4.1.2 describe how 425 a downstream forwarding interface is selected. In these procedures, 426 any interface leading to the downstream LDP neighbor can be 427 considered as candidate forwarding interface. When the {MT-ID, IPA} 428 tuple is part of the FEC, this is no longer true. An interface must 429 only be selected if it is part of the same (sub-)topology that was 430 signaled in the mLDP FEC element. Besides this restriction, the 431 other procedures in [RFC6388] apply. 433 8. LSP Ping Extensions 435 [RFC6425] defines procedures to detect data plane failures in 436 Multipoint MPLS LSPs. Section 3.1.2 of [RFC6425] defines new Sub- 437 Types and Sub-TLVs for Multipoint LDP FECs to be sent in "Target FEC 438 Stack" TLV of an MPLS echo request message [RFC4379]. 440 To support LSP ping for MT Multipoint LSPs, this document uses 441 existing sub-types "P2MP LDP FEC Stack" and "MP2MP LDP FEC Stack" 442 defined in [RFC6425]. The proposed extension is to specify "MT IP" 443 or "MT IPv6" in the "Address Family" field, set the "Address Length" 444 field to 8 (for MT IP) or 20 (for MT IPv6), and encode the sub-TLV 445 with additional {MT-ID, IPA} information as an extension to the "Root 446 LSR Address" field. The resultant format of sub-tlv is as follows: 448 0 1 2 3 449 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 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 |Address Family (MT IP/MT IPv6) | Address Length| | 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 453 ~ Root LSR Address (Cont.) ~ 454 | | 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 | Reserved | IPA | MT-ID | 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 | Opaque Length | Opaque Value ... | 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 460 ~ ~ 461 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 | | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 Figure 6: Multipoint LDP FEC Stack Sub-TLV Format for MT 467 The rules and procedures of using this new sub-TLV in an MPLS echo 468 request message are same as defined for P2MP/MP2MP LDP FEC Stack Sub- 469 TLV in [RFC6425] with only difference being that Root LSR address is 470 now (sub-)topology scoped. 472 9. Security Considerations 474 This extension to mLDP does not introduce any new security 475 considerations beyond that already apply to the base LDP 476 specification [RFC5036], base mLDP specification [RFC6388], and MPLS 477 security framework [RFC5920]. 479 10. IANA Considerations 481 This document defines a new LDP capability parameter TLV. IANA is 482 requested to assign the lowest available value after 0x0500 from "TLV 483 Type Name Space" in the "Label Distribution Protocol (LDP) 484 Parameters" registry within "Label Distribution Protocol (LDP) Name 485 Spaces" as the new code point for the LDP TLV code point. 487 +-----+------------------+---------------+-------------------------+ 488 |Value| Description | Reference | Notes/Registration Date | 489 +-----+------------------+---------------+-------------------------+ 490 | TBA | MT Multipoint | This document | | 491 | | Capability | | | 492 +-----+------------------+---------------+-------------------------+ 494 Figure 7: IANA Code Point 496 11. Acknowledgments 498 The authors would like to acknowledge Eric Rosen for his input on 499 this specification. 501 12. References 503 12.1. Normative References 505 [I-D.hegdeppsenak-isis-sr-flex-algo] 506 Psenak, P., Hegde, S., Filsfils, C., and A. Gulko, "ISIS 507 Segment Routing Flexible Algorithm", draft-hegdeppsenak- 508 isis-sr-flex-algo-02 (work in progress), February 2018. 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 USA 593 Email: mankamis@cisco.com 595 Anuj Budhiraja 596 Cisco Systems, Inc. 597 821 Alder Drive 598 Milpitas, CA 95035 599 USA 601 Email: abudhira@cisco.com 603 Zhaohui Zhang 604 Juniper Networks 605 10 Technology Park Dr. 606 Westford MA 01886 607 US 609 Email: zzhang@juniper.net 611 Arkadiy Gulko 612 Edward Jones wealth management 613 USA 615 Email: Arkadiy.gulko@edwardjones.com