idnits 2.17.1 draft-iqbal-spring-mpls-ping-algo-02.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC8287]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The Protocol field MUST be set 1 if the responder MUST perform FEC validation using OSPF as the IGP protocol and MT-ID is an OSPF Multi-Topology ID. Protocol is set to 2 if the responder MUST perform FEC validation using IS-IS as the IGP protocol, and the MT-ID is IS-IS Multi-Topology ID. Protocol MUST not be set to 0 when using Multi-Topology IPv4 IGP Prefix SID sub-TLV. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The Protocol field MUST be set 1 if the responder MUST perform FEC validation using OSPF as the IGP protocol and MT-ID is an OSPF Multi-Topology ID. Protocol is set to 2 if the responder MUST perform FEC validation using IS-IS as the IGP protocol, and the MT-ID is IS-IS Multi-Topology ID. Protocol MUST not be set to 0 when using Multi-Topology IPv6 IGP Prefix SID sub-TLV. == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 23, 2021) is 1158 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) == Unused Reference: 'I-D.ietf-spring-segment-routing-mpls' is defined on line 462, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-lsr-flex-algo-13 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group N. Nainar, Ed. 3 Internet-Draft Z. Ali 4 Updates: 8287 (if approved) C. Pignataro 5 Intended status: Standards Track Cisco 6 Expires: August 27, 2021 F. Iqbal 7 Arista Networks 8 D. Rathi 9 S. Hegde 10 Juniper Networks 11 February 23, 2021 13 LSP Ping/Traceroute for Prefix SID in Presence of Multi-Algorithm/Multi- 14 Topology Networks 15 draft-iqbal-spring-mpls-ping-algo-02 17 Abstract 19 [RFC8287] defines the extensions to MPLS LSP Ping and Traceroute for 20 Segment Routing IGP-Prefix and IGP-Adjacency Segment Identifier 21 (SIDs) with an MPLS data plane. The machinery defined in [RFC8287] 22 works well in single topology, single algorithm deployments where 23 each Prefix SID is only associated with a single IP prefix. In 24 multi-topology networks, or networks deploying multiple algorithms 25 for the same IP Prefix, MPLS echo request needs to carry additional 26 information in the Target FEC Stack sub-TLVs to properly validate IGP 27 Prefix SID. 29 This document updates [RFC8287] by modifying IPv4 and IPv6 IGP-Prefix 30 Segment ID FEC sub-TLVs to also include algorithm identification 31 while maintaining backwards compatibility. This document also 32 introduces new Target FEC Stack sub-TLVs for Prefix SID validation in 33 multi-topology networks. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at https://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on August 27, 2021. 51 Copyright Notice 53 Copyright (c) 2021 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (https://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 This document may contain material from IETF Documents or IETF 67 Contributions published or made publicly available before November 68 10, 2008. The person(s) controlling the copyright in some of this 69 material may not have granted the IETF Trust the right to allow 70 modifications of such material outside the IETF Standards Process. 71 Without obtaining an adequate license from the person(s) controlling 72 the copyright in such materials, this document may not be modified 73 outside the IETF Standards Process, and derivative works of it may 74 not be created outside the IETF Standards Process, except to format 75 it for publication as an RFC or to translate it into languages other 76 than English. 78 Table of Contents 80 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 81 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 82 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4 83 4. Algorithm Identification for IGP-Prefix SID Sub-TLVs . . . . 5 84 4.1. IPv4 IGP-Prefix Segment ID Sub-TLV . . . . . . . . . . . 5 85 4.2. IPv6 IGP-Prefix Segment ID Sub-TLV . . . . . . . . . . . 5 86 5. Multi-topology Support for IGP Prefix SID . . . . . . . . . . 6 87 5.1. Multi-topology IPv4 IGP-Prefix Segment ID Sub-TLV . . . . 6 88 5.2. Multi-Topology IPv6 IGP-Prefix Segment ID Sub-TLV . . . . 7 89 6. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 7 90 6.1. Single-Topology Networks . . . . . . . . . . . . . . . . 8 91 6.1.1. Initiator Node Procedures . . . . . . . . . . . . . . 8 92 6.1.2. Responder Node Procedures . . . . . . . . . . . . . . 8 93 6.2. Multi-Topology Networks . . . . . . . . . . . . . . . . . 8 94 6.2.1. Initiator Node Procedures . . . . . . . . . . . . . . 8 95 6.2.2. Responding Node Procedures . . . . . . . . . . . . . 9 96 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 97 7.1. New Target FEC tack Sub-TLV . . . . . . . . . . . . . . . 9 98 7.2. Algorithm in the Segment ID Sub-TLV . . . . . . . . . . . 9 99 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 100 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 101 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 102 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 103 11.1. Normative References . . . . . . . . . . . . . . . . . . 10 104 11.2. Informative References . . . . . . . . . . . . . . . . . 10 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 107 1. Introduction 109 [RFC8287] defines the extensions to MPLS LSP Ping and Traceroute for 110 Segment Routing IGP-Prefix SID and IGP-Adjacency SID with an MPLS 111 data plane. [RFC8287] proposes 3 Target FEC Stack Sub-TLVs to carry 112 this information. [I-D.ietf-lsr-flex-algo] introduces the concept of 113 Flexible Algorithm that allows IGPs (ISIS, OSPFv2 and OSPFv3) to 114 compute constraint-based path over an MPLS network. The constraint- 115 based paths enables the IGP of a router to associate one or more 116 Segment Routing Prefix-SID with a particular Flexible Algorithm, and 117 steer packets along the constraint-based paths. Multiple Flexible 118 Algorithms are assigned to the same IPv4/IPv6 Prefix while each 119 utilizing a different MPLS Prefix SID label. Similarly, operators 120 may deploy same IP prefix across multiple topologies in the network 121 using IGP Multi-topology ID (MT-ID). As Flexible-Algorithm based 122 deployments in particular, and multi-topology networks in general, 123 become more common, existing OAM machinery requires updates to 124 correctly diagnose network faults. 126 Segment Routing architecture [RFC8402] defines the context for IGP 127 Prefix SID as a unique tuple comprised of prefix, topology, and 128 algorithm>. Existing MPLS Ping/Traceroute machinery for SR Prefix 129 SIDs, defined in [RFC8287], carries prefix, prefix length, and IGP 130 protocol. To correctly identify and validate a Prefix-SID, the 131 validating device also requires algorithm and topology identification 132 to be supplied in the FEC Stack sub-TLV. This document extends SR- 133 IGP IPv4 and IPv6 Prefix SID FECs to validate a particular algorithm 134 in a single-topology network, while maintaining backwards 135 compatibility with existing implementations of [RFC8287]. It also 136 introduces new Target FEC Stack sub-TLVs to perform MPLS Ping and 137 Traceroute for IGP Prefix SIDs in multi-topology, multi-algorithm 138 deployments. 140 2. Conventions 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 144 document are to be interpreted as described in RFC 2119 [RFC2119]. 146 The term "Must Be Zero" (MBZ) is used in object descriptions for 147 reserved fields. These fields MUST be set to zero when sent and 148 ignored on receipt. 150 Since this document refers to the MPLS Time to Live (TTL) far more 151 frequently than the IP TTL, the authors have chosen the convention of 152 using the unqualified "TTL" to mean "MPLS TTL" and using "IP TTL" for 153 the TTL value in the IP header. 155 3. Motivation 157 In presence of multiple algorithms, a single IGP Prefix may be 158 associated with zero or more IGP Prefix SIDs in addition to the 159 default (Shortest Path First) Prefix SID. Each Prefix SID will have 160 a distinct Prefix SID label and may possibly have a distinct set of 161 next-hops based on associated constraint-based path calculation 162 criteria. This means that to reach the same destination, an non- 163 default algorithm IGP-Prefix SID may take a different path than 164 default IGP Prefix SID algorithm. 166 R3------R6 167 / \ 168 / \ 169 R1----R2 R7----R8 170 \ / 171 \ / 172 R4------R5 174 Figure above, which is a simplification of the diagram used in 175 [RFC8287] illustrates this point through an example. Node Segment 176 IDs for R1, R2, R3, R4, R5, R6, R7, and R8 for the default algorithm 177 are 5001, 5002, 5003, 5004, 5005, 5006, 5007, and 5008, respectively. 178 Nodes R1, R2, R4, R5, R7, and R8 also participate in Flexible 179 Algorithm 128. Their corresponding Node Segment IDs for the 180 algorithm are 5801, 5802, 5804, 5805, 5807, and 5808, respectively. 182 Now consider an MPLS LSP Traceroute request to validate the path to 183 reach node R8 through Flexible Algorithm 128. The TTL of the first 184 echo request packet expires at node R2 with incoming label 5808. 185 Node R2 attempts to validate IGP-Prefix SID Target FEC stack sub-TLV 186 from the echo request. However, this TFS sub-TLV does not contain 187 information identifying the algorithm. As a result, R2 will attempt 188 validation with default algorithm which expects the echo packet to 189 arrive with Prefix SID label 5008. The validation fails, and node R2 190 responds with error code 10 resulting in a false negative. 192 Carrying algorithm identification in the Target FEC Stack sub-TLV of 193 MPLS echo request will help avoid such false negatives. It will also 194 help detect forwarding deviations such as when the packet for a 195 particular destination is incorrectly forwarded to a device that is 196 participating in the default algo but does not participate in a given 197 Flexible Algorithm. 199 The above problem statement can also be extended to apply in Multi- 200 Topology networks. In such networks, the Target FEC Stack sub-TLV 201 MUST carry Multi-Topology ID (MT-ID) in addition to prefix, its 202 length, IGP identification, and algorithm. 204 4. Algorithm Identification for IGP-Prefix SID Sub-TLVs 206 Section 5 of [RFC8287] defines 3 different Segment ID Sub-TLVs that 207 will be included in Target FEC Stack TLV defined in [RFC8029]. This 208 section updates IPv4 IGP-Prefix Segment ID Sub-TLV and IPv6 IGP- 209 Prefix Segment ID Sub-TLV to also include an additional field 210 identifying the algorithm. 212 4.1. IPv4 IGP-Prefix Segment ID Sub-TLV 214 The Sub-TLV format for IPv4 IGP-Prefix Segment ID MUST be set as 215 shown in the below TLV format: 217 0 1 2 3 218 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 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | IPv4 prefix | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 |Prefix Length | Protocol | Algo | Reserved | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 Algo field MUST be set to 0 if the default algorithm is used. Algo 226 field is set to 1 if Strict Shortest Path First (Strict-SPF) 227 algorithm is used. For Flex-Algo, the Algo field MUST be set with 228 the algorithm value (values can be 128-255). 230 4.2. IPv6 IGP-Prefix Segment ID Sub-TLV 232 The Sub-TLV format for IPv6 IGP-Prefix Segment ID MUST be set as 233 shown in the below TLV format: 235 0 1 2 3 236 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 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | | 239 | | 240 | IPv6 prefix | 241 | | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 |Prefix Length | Protocol | Algo | Reserved | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 Algo field MUST be set to 0 if the default algorithm is used. Algo 247 field is set to 1 if Strict Shortest Path First (Strict-SPF) 248 algorithm is used. For Flex-Algo, the Algo field MUST be set with 249 the algorithm value (values can be 128-255). 251 5. Multi-topology Support for IGP Prefix SID 253 IGP Prefix SID TLVs defined above assume a single-topology network 254 for path validation. For Multi-Topology networks, this section 255 introduces new Multi-Topology IGP IPv4 Prefix SID and Multi-Topology 256 IGP IPv6 Prefix SID sub-TLVs in the Target FEC Stack TLV of MPLS echo 257 request. These sub-TLVs carry MT-ID for OSPF and IS-IS protocols as 258 specified in [RFC4915] and [RFC5120] respectively. 260 5.1. Multi-topology IPv4 IGP-Prefix Segment ID Sub-TLV 262 The Sub-TLV format for Multi-topology IPv4 IGP-Prefix Segment ID MUST 263 be set as shown in the below TLV format: 265 0 1 2 3 266 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 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | IPv4 prefix | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 |Prefix Length | Protocol | Algo | Reserved | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | MT-ID | MBZ | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 MT-ID identifies the Multi-Topology ID associated with the Prefix 276 SID. MT-ID is set in trailing 12 bits of the field when the Protocol 277 is set to IS-IS. Leading 4-bits of the MT-ID MUST be all zeroes for 278 IS-IS. MT-ID is set to trailing 8 bits when the protocol is 279 specified as OSPF. The leading octet MUST be set to all zeroes for 280 OSPF. MBZ MUST be set to all zeroes. 282 The Protocol field MUST be set 1 if the responder MUST perform FEC 283 validation using OSPF as the IGP protocol and MT-ID is an OSPF Multi- 284 Topology ID. Protocol is set to 2 if the responder MUST perform FEC 285 validation using IS-IS as the IGP protocol, and the MT-ID is IS-IS 286 Multi-Topology ID. Protocol MUST not be set to 0 when using Multi- 287 Topology IPv4 IGP Prefix SID sub-TLV. 289 5.2. Multi-Topology IPv6 IGP-Prefix Segment ID Sub-TLV 291 The Sub-TLV format for IPv6 IGP-Prefix Segment ID MUST be set as 292 shown in the below TLV format: 294 0 1 2 3 295 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 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | | 298 | | 299 | IPv6 prefix | 300 | | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 |Prefix Length | Protocol | Algo | Reserved | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | MT-ID | MBZ | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 MT-ID identifies the Multi-Topology ID associated with the Prefix 308 SID. MT-ID is set in trailing 12 bits of the field when the Protocol 309 is set to IS-IS. Leading 4-bits of the MT-ID MUST be all zeroes for 310 IS-IS. MT-ID is trailing 8 bits when the protocol is specified as 311 OSPF. The leading octet MUST be set to all zeroes for OSPF. MBZ 312 MUST be set to all zeroes. 314 The Protocol field MUST be set 1 if the responder MUST perform FEC 315 validation using OSPF as the IGP protocol and MT-ID is an OSPF Multi- 316 Topology ID. Protocol is set to 2 if the responder MUST perform FEC 317 validation using IS-IS as the IGP protocol, and the MT-ID is IS-IS 318 Multi-Topology ID. Protocol MUST not be set to 0 when using Multi- 319 Topology IPv6 IGP Prefix SID sub-TLV. 321 6. Procedures 323 The below section describes LSP Ping and Traceroute procedures beyond 324 the text specified in LSP 326 6.1. Single-Topology Networks 328 An array of network operators may deploy flexible algorithms in their 329 network for constraint-based shortest paths, without deploying multi- 330 topology. The updated FEC definitions for IGP Prefix SID allows 331 operator to achieve LSP Ping and Traceroute in these networks while 332 maintaining backwards compatibility with existing devices in the 333 network. Below text highlights the handling procedures and initiator 334 and responder for the updated FEC definitions. 336 6.1.1. Initiator Node Procedures 338 A node initiating LSP echo request packet for the Node Segment ID 339 MUST identify and include the algorithm associated with the IGP 340 Prefix SID in the Target FEC Stack sub-TLV. If the initiating node 341 is not aware of the algorithm, the default algorithm (id 0) of 342 Shortest Path First is assumed. 344 6.1.2. Responder Node Procedures 346 This section updates the procedures defined in Section 7.4 of 347 [RFC8287] for IPv4/IPv6 IGP Prefix SID FEC. If the algorithm is 0, 348 the procedures from [RFC8287] do not require any change. For any 349 other algorithm value, if the responding node is validating the FEC 350 stack, it MUST also validate the IGP Prefix SID advertisement for the 351 algorithm defined in Algo field. 353 If the responding node is including IGP Prefix SID FEC in the FEC 354 stack due to FEC Stack Change operation, it MUST also include 355 algorithm associated with the Prefix SID. 357 6.2. Multi-Topology Networks 359 In presence of Multi-Topology networks, the operators can use the new 360 Multi-Topology IGP IPv4/IPv6 Prefix SID FEC definitions to achieve 361 path validation and fault isolation. Below text describes handling 362 procedures for Multi-Topology networks for initiator and responder. 363 The procedures defined in [RFC8287] are still applicable and the text 364 below updates them instead of replacing them. 366 6.2.1. Initiator Node Procedures 368 A node initiating LSP echo request packet for Single-Topology network 369 MAY use Multi-Topology IGP IPv4/IPv6 Prefix SID defined above. A 370 node initiating LSP echo request for Multi-Topology networks MUST use 371 Multi-Topology IGP IPv4/IPv6 Prefix SID defined above. The node MUST 372 identify and include both the IGP MT-ID and the algorithm associated 373 with the IGP prefix SID in addition to prefix, prefix length, and the 374 protocol. If the initiating node is not aware of the algorithm, the 375 default algorithm (id 0) of Shortest Path First is assumed. The 376 protocol MUST be set to 1 if the responding node is running OSPF, and 377 2 if the responding node is running IS-IS. 379 6.2.2. Responding Node Procedures 381 This section updates the procedures defined in Section 7.4 of 382 [RFC8287] for Multi-Topology IPv4/IPv6 IGP Prefix SID FEC. Upon 383 reception of the sub-TLV, responding node MUST validate that Protocol 384 field is not 0 to correctly parse MT-ID. In addition to procedures 385 defined in [RFC8287], if responding node is validating the FEC Stack, 386 it MUST validate the IGP Prefix SID advertisement for the algorithm 387 and the MT-ID described in the incoming FEC sub-TLV. 389 If the responding node is including Multi-Topology IGP Prefix SID FEC 390 in the FEC stack due to a FEC Stack Change operation, it MUST also 391 include the algorithm and MT-ID associated with the Prefix SID, and 392 set the Protocol to 1 or 2, based on the corresponding IGP. 394 7. IANA Considerations 396 7.1. New Target FEC tack Sub-TLV 398 IANA is requested to assign two new Sub-TLVs from "Sub-TLVs for TLV 399 Types 1, 16 and 21" sub-registry from the "Multi-Protocol Label 400 Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" (IANA- 401 MPLS-LSP-PING) registry. 403 Sub-Type Sub-TLV Name Reference 404 ---------- ----------------- ------------ 405 TBD1 Multi-topology IPv4 IGP-Prefix Segment ID This document 406 TBD2 Multi-topology IPv6 IGP-Prefix Segment ID This document 408 7.2. Algorithm in the Segment ID Sub-TLV 410 IANA is requested to create a new "Algorithm in the Segment ID Sub- 411 TLV" registry under the "Multi-Protocol Label Switching (MPLS) Label 412 Switched Paths (LSPs) Ping Parameters" registry. The initial entries 413 are requested as below: 415 Value Meaning Reference 416 ---------- ----------------- ------------ 417 0 Default Algorithm This document 418 1 Strict Shortest Path First (Strict-SPF) This document 420 8. Security Considerations 422 This document updates [RFC8287] and does not introduce any security 423 considerations. 425 9. Acknowledgements 427 TBA. 429 10. Contributors 431 TBA 433 11. References 435 11.1. Normative References 437 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 438 Requirement Levels", BCP 14, RFC 2119, 439 DOI 10.17487/RFC2119, March 1997, 440 . 442 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 443 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 444 Switched (MPLS) Data-Plane Failures", RFC 8029, 445 DOI 10.17487/RFC8029, March 2017, 446 . 448 [RFC8287] Kumar, N., Ed., Pignataro, C., Ed., Swallow, G., Akiya, 449 N., Kini, S., and M. Chen, "Label Switched Path (LSP) 450 Ping/Traceroute for Segment Routing (SR) IGP-Prefix and 451 IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data 452 Planes", RFC 8287, DOI 10.17487/RFC8287, December 2017, 453 . 455 11.2. Informative References 457 [I-D.ietf-lsr-flex-algo] 458 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 459 A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- 460 algo-13 (work in progress), October 2020. 462 [I-D.ietf-spring-segment-routing-mpls] 463 Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., 464 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 465 data plane", draft-ietf-spring-segment-routing-mpls-22 466 (work in progress), May 2019. 468 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 469 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 470 RFC 4915, DOI 10.17487/RFC4915, June 2007, 471 . 473 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 474 Topology (MT) Routing in Intermediate System to 475 Intermediate Systems (IS-ISs)", RFC 5120, 476 DOI 10.17487/RFC5120, February 2008, 477 . 479 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 480 Decraene, B., Litkowski, S., and R. Shakir, "Segment 481 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 482 July 2018, . 484 Authors' Addresses 486 Nagendra Kumar (editor) 487 Cisco Systems, Inc. 489 Email: naikumar@cisco.com 491 Zafar Ali 492 Cisco Systems, Inc. 494 Email: zali@cisco.com 496 Carlos Pignataro 497 Cisco Systems, Inc. 499 Email: cpignata@cisco.com 501 Faisal Iqbal 502 Arista Networks 504 Email: faisal.ietf@gmail.com 506 Deepti 507 Juniper Networks Inc. 509 Email: deeptir@juniper.net 510 Shraddha 511 Juniper Networks Inc. 513 Email: shraddha@juniper.net