idnits 2.17.1 draft-wijnands-mpls-mldp-multi-topology-00.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 (March 5, 2018) is 2243 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 K. Raza 4 Intended status: Standards Track Cisco Systems, Inc. 5 Expires: September 6, 2018 Z. Zhang 6 Juniper Networks 7 A. Gulko 8 Thomson Reuters 9 March 5, 2018 11 mLDP Extensions for Multi-Topology Routing 12 draft-wijnands-mpls-mldp-multi-topology-00.txt 14 Abstract 16 Multi-Topology Routing (MTR) is a technology to enable service 17 differentiation within an IP network. Flexible Algorithm (FA) is 18 another mechanism of creating a sub-topology within a topology using 19 defined topology constraints and computation algorithm. In order to 20 deploy mLDP in a network that supports MTR and/or FA, mLDP is 21 required to become topology and FA aware. This document specifies 22 extensions to mLDP to support MTR with FA such that when building a 23 Multi-Point LSPs it can follow a particular topology and algorithm. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on September 6, 2018. 42 Copyright Notice 44 Copyright (c) 2018 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Specification of Requirements . . . . . . . . . . . . . . . . 4 62 4. MT Scoped mLDP FECs . . . . . . . . . . . . . . . . . . . . . 4 63 4.1. MP FEC Extensions for MT . . . . . . . . . . . . . . . . 4 64 4.1.1. MP FEC Element . . . . . . . . . . . . . . . . . . . 4 65 4.1.2. MT IP Address Families . . . . . . . . . . . . . . . 5 66 4.1.3. MT MP FEC Element . . . . . . . . . . . . . . . . . . 6 67 4.2. Topology IDs . . . . . . . . . . . . . . . . . . . . . . 7 68 5. MT Multipoint Capability . . . . . . . . . . . . . . . . . . 7 69 6. MT Applicability on FEC-based features . . . . . . . . . . . 8 70 6.1. Typed Wildcard MP FEC Elements . . . . . . . . . . . . . 8 71 6.2. End-of-LIB . . . . . . . . . . . . . . . . . . . . . . . 9 72 7. Topology-Scoped Signaling and Forwarding . . . . . . . . . . 10 73 7.1. Upstream LSR selection . . . . . . . . . . . . . . . . . 10 74 7.2. Downstream forwarding interface selection . . . . . . . . 10 75 8. LSP Ping Extensions . . . . . . . . . . . . . . . . . . . . . 10 76 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 77 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 78 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 79 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 80 12.1. Normative References . . . . . . . . . . . . . . . . . . 12 81 12.2. Informative References . . . . . . . . . . . . . . . . . 13 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 84 1. Glossary 86 MT - Multi-Topology 88 MT-ID - Multi-Topology Identifier 90 MTR - Multi-Topology Routing 92 IGP - Interior Gateway Protocol 94 MP - Multipoint (P2MP or MP2MP) 96 LDP - Label Distribution Protocol 97 mLDP - Multipoint LDP 99 P2MP - Point-to-Multipoint 101 MP2MP - Multipoint-to-Multipoint 103 FEC - Forwarding Equivalence Class 105 LSP - Label Switched Path 107 FA - Flexible Algorithm 109 IPA - IGP Algorithm 111 2. Introduction 113 Multi-Topology Routing (MTR) is a technology to enable service 114 differentiation within an IP network. IGP protocols (OSPF and IS-IS) 115 and LDP have already been extended to support MTR. To support MTR, 116 an IGP maintains independent IP topologies, termed as "Multi- 117 Topologies" (MT), and computes/installs routes per topology. OSPF 118 extensions [RFC4915] and ISIS extensions [RFC5120] specify the MT 119 extensions under respective IGPs. To support IGP MT, similar LDP 120 extensions [RFC7307] have been specified to make LDP MT-aware and be 121 able to setup unicast Label Switched Paths (LSPs) along IGP MT 122 routing paths. 124 A more light weight mechanism to define constraint-based topologies 125 is Flexible Algorithm (FA) [I-D.hegdeppsenak-isis-sr-flex-algo]. FA 126 can be seen as creating a sub-topology within a topology using 127 defined topology constraints and computation algorithm. This can be 128 done within a MTR topology or just the default Topology. An instance 129 of such a sub-topology is identified by a 1 octet value as documented 130 in [I-D.hegdeppsenak-isis-sr-flex-algo]). Flexible Algorithm is a 131 mechanism to create a sub-topology, but in the future different 132 algorithms might be defined on how to achieve that. For that reason, 133 in the remainder of this document we'll refer to this as the IGP 134 Algorithm (IPA). 136 Multipoint LDP (mLDP) refers to extensions in LDP to setup multi- 137 point LSPs (point-to-multipoint (P2MP) or multipoint-to-multipoint 138 (MP2MP)), by means of set of extensions and procedures defined in 139 [RFC6388]. In order to deploy mLDP in a network that supports MTR 140 and FA, mLDP is required to become topology and algorithm aware. 141 This document specifies extensions to mLDP to support MTR/IPA such 142 that when building a Multi-Point LSPs it can follow a particular 143 topology and alogirthm. This means that the identifier for the 144 particular Topology to be used by mLDP have to become a two tuple 145 (MTR Topology Id, IGP Algorithm). 147 3. Specification of Requirements 149 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 150 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 151 document are to be interpreted as described in [RFC2119]. 153 In this document, these words will appear with that interpretation 154 only when in ALL CAPS. Lower case uses of these words are not to be 155 interpreted as carrying RFC-2119 significance. 157 4. MT Scoped mLDP FECs 159 As defined in [RFC7307], MPLS Multi-Topology Identifier (MT-ID) is an 160 identifier that is used to associate an LSP with a certain MTR 161 topology. In the context of MP LSPs, this identifier is part of the 162 mLDP FEC encoding so that LDP peers are able to setup an MP LSP via 163 their own defined MTR policy. In order to avoid conflicting MTR 164 policies for the same mLDP FEC, the MT-ID needs to be a part of the 165 FEC, so that different MT-ID values will result in unique MP-LSP FEC 166 elements. 168 The same applies to the IPA. The IPA needs to be encoded as part of 169 the mLDP FEC to create unique MP-LSPs and at the same time is used to 170 signal to mLDP (hop-by-hop) which Algorithm needs to be used to 171 create the MP-LSP. 173 Since the MT-ID and IPA are part of the FEC, they apply to all the 174 LDP messages that potentially include an mLDP FEC element. 176 4.1. MP FEC Extensions for MT 178 Following subsections propose the extensions to bind an mLDP FEC to a 179 topology. The mLDP MT extensions reuse some of the extensions 180 specified in [RFC7307]. 182 4.1.1. MP FEC Element 184 Base mLDP specification [RFC6388] defines MP FEC Element as follows: 186 0 1 2 3 187 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 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | MP FEC type | Address Family | AF Length | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | Root Node Address | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | Opaque Length | Opaque Value | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 195 ~ ~ 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 Figure 1: MP FEC Element Format [RFC6388] 200 Where "Root Node Address" encoding is as defined for given "Address 201 Family", and whose length (in octets) is specified by the "AF Length" 202 field. 204 To extend MP FEC elements for MT, the {MT-ID, IPA} is a tuple that is 205 relevant in the context of the root address of the MP LSP. The {MT- 206 ID, IPA} tuple determines in which (sub)-topology the root address 207 needs to be resolved. Since the {MT-ID, IPA} tuple should be 208 considered part of the mLDP FEC, the most natural place to encode 209 this tuple is as part of the root address. While encoding it, we 210 also propose to use "MT IP" Address Families as described in 211 following sub section. 213 4.1.2. MT IP Address Families 215 [RFC7307] has specified new address families, named "MT IP" and "MT 216 IPv6", to allow specification of an IP prefix within a topology 217 scope. In addition to using this address family for mLDP, we also 218 use 8 bits of the 16 bits Reserved field to encode the IGP Algorithm 219 (IPA) Registry. The resulting format of the data associated with 220 these new Address Families is as follows: 222 0 1 2 3 223 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 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | IPv4 Address | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | Reserved | IPA | MT-ID | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 0 1 2 3 231 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 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | IPv6 Address | 234 | | 235 | | 236 | | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | Reserved | IPA | MT-ID | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 Figure 2: Modified MT IP Address Families Data Format 243 Where: 245 IPv4/IPv6 Address: An IP address corresponding to "MT IP" and "MT 246 IPv6" address families respectively. 248 IPA: The IGP Algorithm, values are from the IGP Algorithm 249 registry. 251 Reserved: This 8-bit field MUST be zero. If a message is received 252 that includes a MT address family where the 8 bit Reserved value 253 is not zero, the message must be discarded. 255 4.1.3. MT MP FEC Element 257 By using extended MT IP Address Family, the resultant MT MP FEC 258 element is to be encoded as follows: 260 0 1 2 3 261 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 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | MP FEC type | AF (MT IP/ MT IPv6) | AF Length | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | Root Node Address | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | Reserved | IPA | MT-ID | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | Opaque Length | Opaque Value | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 271 ~ ~ 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 Figure 3: IP MT-Scoped MP FEC Element Format 276 In the context of this document, the applicable LDP FECs for MT mLDP 277 include: 279 o MP FEC Elements: 281 * P2MP (type 0x6) 283 * MP2MP-up (type 0x7) 285 * MP2MP-down (type 0x8) 287 o Typed Wildcard FEC Element (type 0x5) 289 In case of "Typed Wildcard FEC Element", the sub FEC Element type 290 MUST be one of the MP FECs listed above. 292 This specification allows the use of Topology-scoped mLDP FECs in LDP 293 label and notification messages, as applicable. 295 4.2. Topology IDs 297 This document assumes the same definitions and procedures associated 298 with MPLS MT-ID as defined in [RFC7307] specification. 300 5. MT Multipoint Capability 302 "MT Multipoint Capability" is a new LDP capability, defined in 303 accordance with LDP Capability definition guidelines [RFC5561], that 304 is to be advertised to its peers by an mLDP speaker to announce its 305 capability to support MTR and the procedures specified in this 306 document. This capability MAY be sent either in an Initialization 307 message at the session establishment time, or in a Capability message 308 dynamically during the lifetime of a session (only if "Dynamic 309 Announcement" capability [RFC5561] has been successfully negotiated 310 with the peer). 312 The format of this capability is as follows: 314 0 1 2 3 315 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 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 |U|F| MT Multipoint Cap.(IANA) | Length | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 |S| Reserved | 320 +-+-+-+-+-+-+-+-+ 322 Figure 4: MT Multipoint Capability TLV Format 324 Where: 326 U- and F-bits: MUST be 1 and 0, respectively, as per Section 3 of 327 LDP Capabilities [RFC5561]. 329 MT Multipoint Capaility: TLV type (IANA assigned). 331 Length: The length (in octets) of TLV. The value of this field 332 MUST be 1 as there is no Capability-specific data [RFC5561] that 333 follows in the TLV. 335 S-bit: Set to 1 to announce and 0 to withdraw the capability (as 336 per [RFC5561]. 338 An mLDP speaker that has successfully advertised and negotiated "MT 339 Multipoint" capability MUST support the following: 341 1. Topology-scoped mLDP FECs in LDP messages (Section 4.1) 343 2. Topology-scoped mLDP forwarding setup (Section 7) 345 6. MT Applicability on FEC-based features 347 6.1. Typed Wildcard MP FEC Elements 349 [RFC5918] extends base LDP and defines Typed Wildcard FEC Element 350 framework. Typed Wildcard FEC element can be used in any LDP message 351 to specify a wildcard operation for a given type of FEC. 353 The MT extensions proposed in document do not require any extension 354 in procedures for Typed Wildcard FEC Element support [RFC5918], and 355 these procedures apply as-is to Multipoint MT FEC wildcarding. Like 356 Typed Wildcard MT Prefix FEC Element, as defined in [RFC7307], the MT 357 extensions allow use of "MT IP" or "MT IPv6" in the Address Family 358 field of the Typed Wildcard MP FEC element in order to use wildcard 359 operations for MP FECs in the context of a given (sub)-topology as 360 identified by the MT-ID and IPA field. 362 This document proposes following format and encoding for a Typed 363 Wildcard MP FEC element: 365 0 1 2 3 366 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 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 |Typed Wcard (5)| Type = MP FEC | Len = 6 | AF = MT IP ..| 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 |... or MT IPv6 | Reserved | IPA | MT-ID | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 |MT ID (contd.) | 373 +-+-+-+-+-+-+-+-+ 375 Figure 5: Typed Wildcard MT MP FEC Element 377 Where: 379 Type: One of MP FEC Element type (P2MP, MP2MPup, MP2MP-down). 381 MT ID: MPLS MT ID 383 IPA: The IGP Algorithm, values are from the IGP Algorithm 384 registry. 386 The proposed format allows an LSR to perform wildcard MP FEC 387 operations under the scope of a (sub-)topology. 389 6.2. End-of-LIB 391 [RFC5919] specifies extensions and procedures that allows an LDP 392 speaker to signal its End-of-LIB (i.e. convergence) for a given FEC 393 type towards a peer. MT extensions for MP FEC do not require any 394 change in these procedures and they apply as-is to MT MP FEC 395 elements. This means that an MT mLDP speaker MAY signal its 396 convergence per (sub-)topology using MT Typed Wildcard MP FEC 397 element. 399 7. Topology-Scoped Signaling and Forwarding 401 Since the {MT-ID, IPA} tuple is part of an mLDP FEC, there is no need 402 to support the concept of multiple (sub-)topology forwarding tables 403 in mLDP. Each MP LSP will be unique due to the tuple being part of 404 the FEC. There is also no need to have specific label forwarding 405 tables per topology, and each MP LSP will have its own unique local 406 label in the table. However, In order to implement MTR in an mLDP 407 network, the selection procedures for upstream LSR and downstream 408 forwarding interface need be changed. 410 7.1. Upstream LSR selection 412 The procedures as described in RFC-6388 section-2.4.1.1 depend on the 413 best path to reach the root. When the {MT-ID, IPA} tuple is signaled 414 as part of the FEC, this tuple is used to select the (sub-)topology 415 that must be used to find the best path to the root address. Using 416 the next-hop from this best path, a LDP peer is selected following 417 the procedures as defined in [RFC6388]. 419 7.2. Downstream forwarding interface selection 421 The procedures as described in RFC-6388 section-2.4.1.2 describe how 422 a downstream forwarding interface is selected. In these procedures, 423 any interface leading to the downstream LDP neighbor can be 424 considered as candidate forwarding interface. When the {MT-ID, IPA} 425 tuple is part of the FEC, this is no longer true. An interface must 426 only be selected if it is part of the same (sub-)topology that was 427 signaled in the mLDP FEC element. Besides this restriction, the 428 other procedures in [RFC6388] apply. 430 8. LSP Ping Extensions 432 [RFC6425] defines procedures to detect data plane failures in 433 Multipoint MPLS LSPs. Section 3.1.2 of [RFC6425] defines new Sub- 434 Types and Sub-TLVs for Multipoint LDP FECs to be sent in "Target FEC 435 Stack" TLV of an MPLS echo request message [RFC4379]. 437 To support LSP ping for MT Multipoint LSPs, this document uses 438 existing sub-types "P2MP LDP FEC Stack" and "MP2MP LDP FEC Stack" 439 defined in [RFC6425]. The proposed extension is to specify "MT IP" 440 or "MT IPv6" in the "Address Family" field, set the "Address Length" 441 field to 8 (for MT IP) or 20 (for MT IPv6), and encode the sub-TLV 442 with additional {MT-ID, IPA} information as an extension to the "Root 443 LSR Address" field. The resultant format of sub-tlv is as follows: 445 0 1 2 3 446 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 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 |Address Family (MT IP/MT IPv6) | Address Length| | 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 450 ~ Root LSR Address (Cont.) ~ 451 | | 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 | Reserved | IPA | MT-ID | 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 | Opaque Length | Opaque Value ... | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 457 ~ ~ 458 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 | | 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 Figure 6: Multipoint LDP FEC Stack Sub-TLV Format for MT 464 The rules and procedures of using this new sub-TLV in an MPLS echo 465 request message are same as defined for P2MP/MP2MP LDP FEC Stack Sub- 466 TLV in [RFC6425] with only difference being that Root LSR address is 467 now (sub-)topology scoped. 469 9. Security Considerations 471 This extension to mLDP does not introduce any new security 472 considerations beyond that already apply to the base LDP 473 specification [RFC5036], base mLDP specification [RFC6388], and MPLS 474 security framework [RFC5920]. 476 10. IANA Considerations 478 This document defines a new LDP capability parameter TLV. IANA is 479 requested to assign the lowest available value after 0x0500 from "TLV 480 Type Name Space" in the "Label Distribution Protocol (LDP) 481 Parameters" registry within "Label Distribution Protocol (LDP) Name 482 Spaces" as the new code point for the LDP TLV code point. 484 +-----+------------------+---------------+-------------------------+ 485 |Value| Description | Reference | Notes/Registration Date | 486 +-----+------------------+---------------+-------------------------+ 487 | TBA | MT Multipoint | This document | | 488 | | Capability | | | 489 +-----+------------------+---------------+-------------------------+ 491 Figure 7: IANA Code Point 493 11. Acknowledgments 495 The authors would like to acknowledge Eric Rosen for his input on 496 this specification. 498 12. References 500 12.1. Normative References 502 [I-D.hegdeppsenak-isis-sr-flex-algo] 503 Psenak, P., Hegde, S., Filsfils, C., and A. Gulko, "ISIS 504 Segment Routing Flexible Algorithm", draft-hegdeppsenak- 505 isis-sr-flex-algo-02 (work in progress), February 2018. 507 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 508 Requirement Levels", BCP 14, RFC 2119, 509 DOI 10.17487/RFC2119, March 1997, 510 . 512 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 513 Label Switched (MPLS) Data Plane Failures", RFC 4379, 514 DOI 10.17487/RFC4379, February 2006, 515 . 517 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 518 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 519 RFC 4915, DOI 10.17487/RFC4915, June 2007, 520 . 522 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 523 Topology (MT) Routing in Intermediate System to 524 Intermediate Systems (IS-ISs)", RFC 5120, 525 DOI 10.17487/RFC5120, February 2008, 526 . 528 [RFC6388] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B. 529 Thomas, "Label Distribution Protocol Extensions for Point- 530 to-Multipoint and Multipoint-to-Multipoint Label Switched 531 Paths", RFC 6388, DOI 10.17487/RFC6388, November 2011, 532 . 534 [RFC6425] Saxena, S., Ed., Swallow, G., Ali, Z., Farrel, A., 535 Yasukawa, S., and T. Nadeau, "Detecting Data-Plane 536 Failures in Point-to-Multipoint MPLS - Extensions to LSP 537 Ping", RFC 6425, DOI 10.17487/RFC6425, November 2011, 538 . 540 [RFC7307] Zhao, Q., Raza, K., Zhou, C., Fang, L., Li, L., and D. 541 King, "LDP Extensions for Multi-Topology", RFC 7307, 542 DOI 10.17487/RFC7307, July 2014, 543 . 545 12.2. Informative References 547 [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., 548 "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, 549 October 2007, . 551 [RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL. 552 Le Roux, "LDP Capabilities", RFC 5561, 553 DOI 10.17487/RFC5561, July 2009, 554 . 556 [RFC5918] Asati, R., Minei, I., and B. Thomas, "Label Distribution 557 Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class 558 (FEC)", RFC 5918, DOI 10.17487/RFC5918, August 2010, 559 . 561 [RFC5919] Asati, R., Mohapatra, P., Chen, E., and B. Thomas, 562 "Signaling LDP Label Advertisement Completion", RFC 5919, 563 DOI 10.17487/RFC5919, August 2010, 564 . 566 [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS 567 Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, 568 . 570 Authors' Addresses 571 IJsbrand Wijnands 572 Cisco Systems, Inc. 573 De kleetlaan 6a 574 Diegem 1831 575 Belgium 577 Email: ice@cisco.com 579 Kamran Raza 580 Cisco Systems, Inc. 581 2000 Innovation Drive 582 Kanata, ON K2K-3E8 583 Canada 585 Email: skraza@cisco.com 587 Zhaohui Zhang 588 Juniper Networks 589 10 Technology Park Dr. 590 Westford MA 01886 591 US 593 Email: zzhang@juniper.net 595 Arkadiy Gulko 596 Thomson Reuters 597 195 Broadway 598 New York NY 10007 599 USA 601 Email: arkadiy.gulko@thomsonreuters.com