idnits 2.17.1 draft-xp-mpls-spring-lsp-ping-path-sid-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 : ---------------------------------------------------------------------------- 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 (16 November 2021) is 885 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 (-22) exists of draft-ietf-spring-mpls-path-segment-05 == Outdated reference: A later version (-26) exists of draft-ietf-idr-segment-routing-te-policy-13 == Outdated reference: A later version (-09) exists of draft-ietf-idr-sr-policy-path-segment-04 == Outdated reference: A later version (-13) exists of draft-ietf-mpls-sr-epe-oam-04 == Outdated reference: A later version (-11) exists of draft-ietf-pce-multipath-03 == Outdated reference: A later version (-15) exists of draft-ietf-pce-segment-routing-policy-cp-06 == Outdated reference: A later version (-09) exists of draft-ietf-pce-sr-path-segment-04 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-14 == Outdated reference: A later version (-03) exists of draft-ietf-spring-sr-policy-yang-01 == Outdated reference: A later version (-06) exists of draft-lp-idr-sr-path-protection-01 Summary: 0 errors (**), 0 flaws (~~), 11 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group X. Min 3 Internet-Draft P. Shaofu 4 Intended status: Standards Track ZTE Corp. 5 Expires: 20 May 2022 16 November 2021 7 Label Switched Path (LSP) Ping for Segment Routing (SR) Path Segment 8 Identifiers (SIDs) with MPLS Data Planes 9 draft-xp-mpls-spring-lsp-ping-path-sid-02 11 Abstract 13 Path Segment is a type of SR segment, which is used to identify an SR 14 path. This document provides Target Forwarding Equivalence Class 15 (FEC) stack TLV definitions for Path Segment Identifiers. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on 20 May 2022. 34 Copyright Notice 36 Copyright (c) 2021 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 41 license-info) in effect on the date of publication of this document. 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. Code Components 44 extracted from this document must include Simplified BSD License text 45 as described in Section 4.e of the Trust Legal Provisions and are 46 provided without warranty as described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 53 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Path Segment ID Sub-TLV . . . . . . . . . . . . . . . . . . . 3 55 3.1. SR Candidate Path's Path SID . . . . . . . . . . . . . . 3 56 3.2. SR Segment List's Path SID . . . . . . . . . . . . . . . 6 57 4. Path-SID FEC Validation . . . . . . . . . . . . . . . . . . . 8 58 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 59 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 60 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 61 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 62 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 63 8.2. Informative References . . . . . . . . . . . . . . . . . 13 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 66 1. Introduction 68 Path Segment is a type of SR segment, which is used to identify an SR 69 path. Path Segment in MPLS based segment routing network is defined 70 in [I-D.ietf-spring-mpls-path-segment]. 72 When Path Segment is used, it's inserted by the ingress node of the 73 SR path, and then processed by the egress node of the SR path. The 74 position of Path Segment Label within the MPLS label stack is 75 immediately following the segment list of the SR path. Note that the 76 Path Segment would not be popped up until it reaches the egress node. 78 This document provides Target Forwarding Equivalence Class (FEC) 79 stack TLV definitions for Path-SIDs. Procedures for LSP Ping as 80 defined in [RFC8287] and [RFC8690] are applicable to Path-SIDs as 81 well. 83 2. Conventions 85 2.1. Requirements Language 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 89 "OPTIONAL" in this document are to be interpreted as described in BCP 90 14 [RFC2119] [RFC8174] when, and only when, they appear in all 91 capitals, as shown here. 93 2.2. Terminology 95 This document uses the terminology defined in [RFC8402] and 96 [RFC8029], readers are expected to be familiar with those terms. 98 3. Path Segment ID Sub-TLV 100 Analogous to what's defined in Section 5 of [RFC8287] and Section 4 101 of [I-D.ietf-mpls-sr-epe-oam], two new sub-TLVs are defined for the 102 Target FEC Stack TLV (Type 1), the Reverse-Path Target FEC Stack TLV 103 (Type 16), and the Reply Path TLV (Type 21). 105 Sub-Type Sub-TLV Name 106 -------- ----------------------------- 107 TBD1 SR Candidate Path's Path SID 108 TBD2 SR Segment List's Path SID 110 As specified in Section 3 of [I-D.ietf-idr-sr-policy-path-segment], 111 the Path Segment can be used to identify an SR path (specified by SID 112 list) or an SR candidate path, so two different Target FEC sub-TLVs 113 need to be defined for Path Segment ID. When a Path Segment is used 114 to identify an SR path, then the Target FEC sub-TLV of SR Segment 115 List's Path SID would be used to validate the control plane to 116 forwarding plane synchronization for this Path-SID; When a Path 117 Segment is used to identify an SR candidate path, then the Target FEC 118 sub-TLV of SR Candidate Path's Path SID would be used to validate the 119 control plane to forwarding plane synchronization for this Path-SID. 120 Note that the two new Target FEC sub-TLVs are mutual exclusive and 121 they wouldn't be present in one message simultaneously. 123 3.1. SR Candidate Path's Path SID 125 The format of SR Candidate Path's Path SID sub-TLV is as specified 126 below: 128 0 1 2 3 129 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 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 | Type = TBD1 | Length | 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 ~ Headend (4/16 octets) ~ 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 | Color (4 octets) | 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 ~ Endpoint (4/16 octets) ~ 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 |Protocol-Origin| Reserved | 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 | | 142 | | 143 | Originator (20 octets) | 144 | | 145 | | 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | Discriminator (4 octets) | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 Figure 1: SR Candidate Path's Path SID sub-TLV 152 Type 154 This field is set to the value (TBD1) which indicates that it's a 155 SR Candidate Path's Path SID sub-TLV. 157 Length 159 This field is set to the length of the sub-TLV's Value field in 160 octets. If Headend and Endpoint fields are in IPv4 address format 161 which is 4 octets long, it MUST be set to 40; If Headend and 162 Endpoint fields are in IPv6 address format which is 16 octets 163 long, it MUST be set to 64. 165 Headend 167 This field identifies the headend of an SR Policy, the same as 168 defined in Section 2.1 of 169 [I-D.ietf-spring-segment-routing-policy]. The headend is a 170 4-octet IPv4 address or a 16-octet IPv6 address. 172 Color 173 This field associates the SR Policy with an intent, the same as 174 defined in Section 2.1 of 175 [I-D.ietf-spring-segment-routing-policy]. The color is a 4-octet 176 numerical value. 178 Endpoint 180 This field identifies the endpoint of an SR Policy, the same as 181 defined in Section 2.1 of 182 [I-D.ietf-spring-segment-routing-policy]. The endpoint is a 183 4-octet IPv4 address or a 16-octet IPv6 address. 185 Protocol-Origin 187 This field identifies the component or protocol that originates or 188 signals the candidate path for an SR Policy, the same as defined 189 in Section 2.3 of [I-D.ietf-spring-segment-routing-policy]. The 190 protocol-origin is a 1-octet value that follows the recommendation 191 from Table 1 of Section 2.3 of 192 [I-D.ietf-spring-segment-routing-policy], which specifies value 10 193 for "PCEP", value 20 for "BGP SR Policy" and value 30 for "Via 194 Configuration". 196 Originator 198 This field identifies the node which provisioned or signaled the 199 candidate path for an SR Policy, the same as defined in 200 Section 2.4 of [I-D.ietf-spring-segment-routing-policy]. The 201 originator is a 20-octet numerical value formed by the 202 concatenation of the fields of the tuple , 203 among which ASN is a 4-octet number and node address is a 16-octet 204 value (an IPv6 address or an IPv4 address encoded in the lowest 4 205 octets). When Procotol-Origin is respectively "Via 206 Configuration", or "PCEP", or "BGP SR Policy", the values of ASN 207 and node address follow the specification in Section 2.4 of 208 [I-D.ietf-spring-segment-routing-policy]. 210 Discriminator 212 This field uniquely identifies a candidate path within the context 213 of an SR policy, the same as defined in Section 2.5 of 214 [I-D.ietf-spring-segment-routing-policy]. The discriminator is a 215 4-octet value. When Protocol-Origin is respectively "Via 216 Configuration", or "PCEP", or "BGP SR Policy", the value of 217 discriminator follows the specification in Section 2.5 of 218 [I-D.ietf-spring-segment-routing-policy]. 220 3.2. SR Segment List's Path SID 222 The format of SR Segment List's Path SID sub-TLV is as specified 223 below: 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 | Type = TBD2 | Length | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 ~ Headend (4/16 octets) ~ 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | Color (4 octets) | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 ~ Endpoint (4/16 octets) ~ 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 |Protocol-Origin| Reserved | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | | 239 | | 240 | Originator (20 octets) | 241 | | 242 | | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | Discriminator (4 octets) | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | Segment-List-ID (4 octets) | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 Figure 2: SR Segment List's Path SID sub-TLV 251 Type 253 This field is set to the value (TBD2) which indicates that it's a 254 SR Segment List's Path SID sub-TLV. 256 Length 258 This field is set to the length of the sub-TLV's Value field in 259 octets. If Headend and Endpoint fields are in IPv4 address format 260 which is 4 octets long, it MUST be set to 44; If Headend and 261 Endpoint fields are in IPv6 address format which is 16 octets 262 long, it MUST be set to 68. 264 Headend 265 This field identifies the headend of an SR Policy, the same as 266 defined in Section 2.1 of 267 [I-D.ietf-spring-segment-routing-policy]. The headend is a 268 4-octet IPv4 address or a 16-octet IPv6 address. 270 Color 272 This field associates the SR Policy with an intent, the same as 273 defined in Section 2.1 of 274 [I-D.ietf-spring-segment-routing-policy]. The color is a 4-octet 275 numerical value. 277 Endpoint 279 This field identifies the endpoint of an SR Policy, the same as 280 defined in Section 2.1 of 281 [I-D.ietf-spring-segment-routing-policy]. The endpoint is a 282 4-octet IPv4 address or a 16-octet IPv6 address. 284 Protocol-Origin 286 This field identifies the component or protocol that originates or 287 signals the candidate path for an SR Policy, the same as defined 288 in Section 2.3 of [I-D.ietf-spring-segment-routing-policy]. The 289 protocol-origin is a 1-octet value that follows the recommendation 290 from Table 1 of Section 2.3 of 291 [I-D.ietf-spring-segment-routing-policy], which specifies value 10 292 for "PCEP", value 20 for "BGP SR Policy" and value 30 for "Via 293 Configuration". 295 Originator 297 This field identifies the node which provisioned or signaled the 298 candidate path for an SR Policy, the same as defined in 299 Section 2.4 of [I-D.ietf-spring-segment-routing-policy]. The 300 originator is a 20-octet numerical value formed by the 301 concatenation of the fields of the tuple , 302 among which ASN is a 4-octet number and node address is a 16-octet 303 value (an IPv6 address or an IPv4 address encoded in the lowest 4 304 octets). When Procotol-Origin is respectively "Via 305 Configuration", or "PCEP", or "BGP SR Policy", the values of ASN 306 and node address follow the specification in Section 2.4 of 307 [I-D.ietf-spring-segment-routing-policy]. 309 Discriminator 310 This field uniquely identifies a candidate path within the context 311 of an SR policy, the same as defined in Section 2.5 of 312 [I-D.ietf-spring-segment-routing-policy]. The discriminator is a 313 4-octet value. When Protocol-Origin is respectively "Via 314 Configuration", or "PCEP", or "BGP SR Policy", the value of 315 discriminator follows the specification in Section 2.5 of 316 [I-D.ietf-spring-segment-routing-policy]. 318 Segment-List-ID 320 This field identifies an SR path within the context of a candidate 321 path of an SR Policy, the same as "Path ID" defined in Section 4.2 322 of [I-D.ietf-pce-multipath], or "List Identifier" defined in 323 Section 2.2 of [I-D.lp-idr-sr-path-protection]. The segment-list- 324 ID is a 4-octet identifier of the corresponding segment list. 326 4. Path-SID FEC Validation 328 The MPLS LSP Ping procedures MAY be initiated by the headend of the 329 Segment Routing path or a centralized topology-aware data plane 330 monitoring system as described in [RFC8403]. For the Path-SID, the 331 responder nodes that receive echo request and send echo reply MUST be 332 the endpoint of the Segment Routing path. 334 When an endpoint receives the LSP echo request packet with top FEC 335 being the Path-SID, it SHOULD perform validity checks on the content 336 of the Path-SID FEC sub-TLV. The basic length check should be 337 performed on the received FEC. 339 SR Candidate Path's Path SID 340 ------------------ 341 Length = 40 or 64 343 SR Segment List's Path SID 344 ------------------ 345 Length = 44 or 68 347 If a malformed FEC sub-TLV is received, then a return code of 1, 348 "Malformed echo request received" as defined in [RFC8029] SHOULD be 349 sent. The below section augments the section 7.4 of [RFC8287]. 351 4a. Segment Routing Path-SID Validation: 353 If the Label-stack-depth is 0 and the Target FEC Stack sub-TLV at 354 FEC-stack-depth is TBD1 (SR Candidate Path's Path SID sub-TLV), { 355 - Set the Best-return-code to 10, "Mapping for this FEC is not 356 the given label at stack-depth " if any below conditions 357 fail: 359 o Validate that the Path Segment ID is signaled or provisioned 360 for the SR Candidate Path { 362 + When the Protocol-Origin field in the received SR 363 Candidate Path's Path SID sub-TLV is 10, "PCEP" is used 364 as the signaling protocol. And then validate that the 365 Path Segment ID matches with the tuple identifying the SR 366 Candidate Path within PCEP { 368 * Validate that the signaled headend, color, end-point, 369 originator ASN, originator address and discriminator 370 defined in [I-D.ietf-pce-segment-routing-policy-cp] 371 and [I-D.ietf-pce-sr-path-segment], for the Path SID, 372 matches with the corresponding fields in the received 373 SR Candidate Path's Path SID sub-TLV. 375 } 377 + When the Protocol-Origin field in the received SR 378 Candidate Path's Path SID sub-TLV is 20, "BGP SR Policy" 379 is used as the signaling protocol. And then validate 380 that the Path Segment ID matches with the tuple 381 identifying the SR Candidate Path within BGP SR Policy { 383 * Validate that the signaled headend, policy color, 384 endpoint, ASN, BGP Router-ID and distinguisher defined 385 in [I-D.ietf-idr-segment-routing-te-policy] and 386 [I-D.ietf-idr-sr-policy-path-segment], for the Path 387 SID, matches with the corresponding fields in the 388 received SR Candidate Path's Path SID sub-TLV. 390 } 392 + When the Protocol-Origin field in the received SR 393 Candidate Path's Path SID sub-TLV is 30, "Via 394 Configuration" is used. And then validate that the Path 395 Segment ID matches with the tuple identifying the SR 396 Candidate Path within Configuration { 398 * Validate that the provisioned headend, color, 399 endpoint, originator and discriminator defined in 400 [I-D.ietf-spring-sr-policy-yang], for the Path SID, 401 matches with the corresponding fields in the received 402 SR Candidate Path's Path SID sub-TLV. 404 } 406 } 408 - If all the above validations have passed, set the return code 409 to 3 "Replying router is an egress for the FEC at stack-depth 410 ". 412 - Set FEC-Status to 1 and return. 414 } 416 Else, if the Label-stack-depth is 0 and the Target FEC Stack sub- 417 TLV at FEC-stack-depth is TBD2 (SR Segment List's Path SID sub- 418 TLV), { 420 - Set the Best-return-code to 10, "Mapping for this FEC is not 421 the given label at stack-depth " if any below conditions 422 fail: 424 o Validate that the Path Segment ID is signaled or provisioned 425 for the SR Segment List { 427 + When the Protocol-Origin field in the received SR Segment 428 List's Path SID sub-TLV is 10, "PCEP" is used as the 429 signaling protocol. And then validate that the Path 430 Segment ID matches with the tuple identifying the SR 431 Segment List within PCEP { 433 * Validate that the signaled headend, color, end-point, 434 originator ASN, originator address and discriminator 435 defined in [I-D.ietf-pce-segment-routing-policy-cp] 436 and [I-D.ietf-pce-sr-path-segment], and the signaled 437 Path ID defined in [I-D.ietf-pce-multipath], for the 438 Path SID, matches with the corresponding fields in the 439 received SR Segment List's Path SID sub-TLV. 441 } 443 + When the Protocol-Origin field in the received SR Segment 444 List's Path SID sub-TLV is 20, "BGP SR Policy" is used as 445 the signaling protocol. And then validate that the Path 446 Segment ID matches with the tuple identifying the SR 447 Segment List within BGP SR Policy { 449 * Validate that the signaled headend, policy color, 450 endpoint, ASN, BGP Router-ID and distinguisher defined 451 in [I-D.ietf-idr-segment-routing-te-policy] and 453 [I-D.ietf-idr-sr-policy-path-segment], and the 454 signaled List Identifier defined in 455 [I-D.lp-idr-sr-path-protection], for the Path SID, 456 matches with the headend field in the received SR 457 Segment List's Path SID sub-TLV. 459 } 461 + When the Protocol-Origin field in the received SR Segment 462 List's Path SID sub-TLV is 30, "Via Configuration" is 463 used. And then validate that the Path Segment ID matches 464 with the tuple identifying the SR Segment List within 465 Configuration { 467 * Validate that the provisioned headend, color, 468 endpoint, originator, discriminator and Segment-List- 469 ID defined in [I-D.ietf-spring-sr-policy-yang], for 470 the Path SID, matches with the corresponding fields in 471 the received SR Segment List's Path SID sub-TLV. 473 } 475 } 477 - If all the above validations have passed, set the return code 478 to 3 "Replying router is an egress for the FEC at stack-depth 479 ". 481 - Set FEC-Status to 1 and return. 483 } 485 5. Security Considerations 487 This document does not raise any additional security issues beyond 488 those of the specifications referred to in the list of normative 489 references. 491 6. IANA Considerations 493 IANA is requested to assign two new sub-TLVs from the "sub-TLVs for 494 TLV Types 1, 16, and 21" subregistry of the "Multi-Protocol Label 495 Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" 496 registry [IANA]. 498 Sub-Type Sub-TLV Name Reference 499 -------- ----------------------------- ------------ 500 TBD1 SR Candidate Path's Path SID Section 3.1 501 TBD2 SR Segment List's Path SID Section 3.2 503 7. Acknowledgements 505 The authors would like to acknowledge Zhao Detao for his thorough 506 review and very helpful comments. 508 The authors would like to acknowledge Liu Yao for very helpful 509 discussion with her. 511 8. References 513 8.1. Normative References 515 [I-D.ietf-spring-mpls-path-segment] 516 Cheng, W., Li, H., Chen, M., Gandhi, R., and R. Zigler, 517 "Path Segment in MPLS Based Segment Routing Network", Work 518 in Progress, Internet-Draft, draft-ietf-spring-mpls-path- 519 segment-05, 21 August 2021, 520 . 523 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 524 Requirement Levels", BCP 14, RFC 2119, 525 DOI 10.17487/RFC2119, March 1997, 526 . 528 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 529 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 530 Switched (MPLS) Data-Plane Failures", RFC 8029, 531 DOI 10.17487/RFC8029, March 2017, 532 . 534 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 535 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 536 May 2017, . 538 [RFC8287] Kumar, N., Ed., Pignataro, C., Ed., Swallow, G., Akiya, 539 N., Kini, S., and M. Chen, "Label Switched Path (LSP) 540 Ping/Traceroute for Segment Routing (SR) IGP-Prefix and 541 IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data 542 Planes", RFC 8287, DOI 10.17487/RFC8287, December 2017, 543 . 545 [RFC8690] Nainar, N., Pignataro, C., Iqbal, F., and A. Vainshtein, 546 "Clarification of Segment ID Sub-TLV Length for RFC 8287", 547 RFC 8690, DOI 10.17487/RFC8690, December 2019, 548 . 550 8.2. Informative References 552 [I-D.ietf-idr-segment-routing-te-policy] 553 Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., 554 Rosen, E., Jain, D., and S. Lin, "Advertising Segment 555 Routing Policies in BGP", Work in Progress, Internet- 556 Draft, draft-ietf-idr-segment-routing-te-policy-13, 7 June 557 2021, . 560 [I-D.ietf-idr-sr-policy-path-segment] 561 Li, C., Li, Z., Yin, Y., Cheng, W., and K. Talaulikar, "SR 562 Policy Extensions for Path Segment and Bidirectional 563 Path", Work in Progress, Internet-Draft, draft-ietf-idr- 564 sr-policy-path-segment-04, 8 July 2021, 565 . 568 [I-D.ietf-mpls-sr-epe-oam] 569 Hegde, S., Arora, K., Srivastava, M., Ninan, S., and X. 570 Xu, "Label Switched Path (LSP) Ping/Traceroute for Segment 571 Routing (SR) Egress Peer Engineering Segment Identifiers 572 (SIDs) with MPLS Data Planes", Work in Progress, Internet- 573 Draft, draft-ietf-mpls-sr-epe-oam-04, 8 November 2021, 574 . 577 [I-D.ietf-pce-multipath] 578 Koldychev, M., Sivabalan, S., Saad, T., Beeram, V. P., 579 Bidgoli, H., Yadav, B., and S. Peng, "PCEP Extensions for 580 Signaling Multipath Information", Work in Progress, 581 Internet-Draft, draft-ietf-pce-multipath-03, 25 October 582 2021, . 585 [I-D.ietf-pce-segment-routing-policy-cp] 586 Koldychev, M., Sivabalan, S., Barth, C., Peng, S., and H. 587 Bidgoli, "PCEP extension to support Segment Routing Policy 588 Candidate Paths", Work in Progress, Internet-Draft, draft- 589 ietf-pce-segment-routing-policy-cp-06, 22 October 2021, 590 . 593 [I-D.ietf-pce-sr-path-segment] 594 Li, C., Chen, M., Cheng, W., Gandhi, R., and Q. Xiong, 595 "Path Computation Element Communication Protocol (PCEP) 596 Extension for Path Segment in Segment Routing (SR)", Work 597 in Progress, Internet-Draft, draft-ietf-pce-sr-path- 598 segment-04, 12 August 2021, 599 . 602 [I-D.ietf-spring-segment-routing-policy] 603 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 604 P. Mattes, "Segment Routing Policy Architecture", Work in 605 Progress, Internet-Draft, draft-ietf-spring-segment- 606 routing-policy-14, 25 October 2021, 607 . 610 [I-D.ietf-spring-sr-policy-yang] 611 Raza, K., Sawaya, R., Shunwan, Z., Voyer, D., Durrani, M., 612 Matsushima, S., and V. P. Beeram, "YANG Data Model for 613 Segment Routing Policy", Work in Progress, Internet-Draft, 614 draft-ietf-spring-sr-policy-yang-01, 7 April 2021, 615 . 618 [I-D.lp-idr-sr-path-protection] 619 Yao, L. and P. Shaofu, "BGP Extensions of SR Policy for 620 Path Protection", Work in Progress, Internet-Draft, draft- 621 lp-idr-sr-path-protection-01, 19 May 2021, 622 . 625 [IANA] Internet Assigned Numbers Authority (IANA), "Multi- 626 Protocol Label Switching (MPLS) Label Switched Paths 627 (LSPs) Ping Parameters", . 630 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 631 Decraene, B., Litkowski, S., and R. Shakir, "Segment 632 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 633 July 2018, . 635 [RFC8403] Geib, R., Ed., Filsfils, C., Pignataro, C., Ed., and N. 636 Kumar, "A Scalable and Topology-Aware MPLS Data-Plane 637 Monitoring System", RFC 8403, DOI 10.17487/RFC8403, July 638 2018, . 640 Authors' Addresses 642 Xiao Min 643 ZTE Corp. 644 Nanjing 645 China 647 Phone: +86 25 88013062 648 Email: xiao.min2@zte.com.cn 650 Peng Shaofu 651 ZTE Corp. 652 Nanjing 653 China 655 Email: peng.shaofu@zte.com.cn