idnits 2.17.1 draft-xp-mpls-spring-lsp-ping-path-sid-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 (May 17, 2021) is 1069 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-04 == Outdated reference: A later version (-26) exists of draft-ietf-idr-segment-routing-te-policy-11 == Outdated reference: A later version (-09) exists of draft-ietf-idr-sr-policy-path-segment-03 == Outdated reference: A later version (-13) exists of draft-ietf-mpls-sr-epe-oam-03 == Outdated reference: A later version (-11) exists of draft-ietf-pce-multipath-00 == Outdated reference: A later version (-15) exists of draft-ietf-pce-segment-routing-policy-cp-04 == Outdated reference: A later version (-09) exists of draft-ietf-pce-sr-path-segment-03 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-11 == 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-00 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: November 18, 2021 May 17, 2021 7 Label Switched Path (LSP) Ping/Traceroute for Segment Routing (SR) Path 8 Segment Identifiers (SIDs) with MPLS Data Planes 9 draft-xp-mpls-spring-lsp-ping-path-sid-01 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 November 18, 2021. 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 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 54 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Path Segment ID Sub-TLV . . . . . . . . . . . . . . . . . . . 3 56 3.1. SR Candidate Path's Path SID . . . . . . . . . . . . . . 3 57 3.2. SR Segment List's Path SID . . . . . . . . . . . . . . . 6 58 4. Path-SID FEC Validation . . . . . . . . . . . . . . . . . . . 8 59 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 60 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 61 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 62 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 63 8.1. Normative References . . . . . . . . . . . . . . . . . . 15 64 8.2. Informative References . . . . . . . . . . . . . . . . . 16 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 67 1. Introduction 69 Path Segment is a type of SR segment, which is used to identify an SR 70 path. Path Segment in MPLS based segment routing network is defined 71 in [I-D.ietf-spring-mpls-path-segment]. 73 When Path Segment is used, it's inserted by the ingress node of the 74 SR path, and then processed by the egress node of the SR path. The 75 position of Path Segment Label within the MPLS label stack is 76 immediately following the segment list of the SR path. Note that the 77 Path Segment would not be popped up until it reaches the egress node. 79 This document provides Target Forwarding Equivalence Class (FEC) 80 stack TLV definitions for Path-SIDs. Procedures for LSP Ping and 81 Traceroute as defined in [RFC8287] and [RFC8690] are applicable to 82 Path-SIDs as well. 84 2. Conventions 86 2.1. Requirements Language 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 90 "OPTIONAL" in this document are to be interpreted as described in BCP 91 14 [RFC2119] [RFC8174] when, and only when, they appear in all 92 capitals, as shown here. 94 2.2. Terminology 96 This document uses the terminology defined in [RFC8402] and 97 [RFC8029], readers are expected to be familiar with those terms. 99 3. Path Segment ID Sub-TLV 101 Analogous to what's defined in Section 5 of [RFC8287] and Section 4 102 of [I-D.ietf-mpls-sr-epe-oam], two new sub-TLVs are defined for the 103 Target FEC Stack TLV (Type 1), the Reverse-Path Target FEC Stack TLV 104 (Type 16), and the Reply Path TLV (Type 21). 106 Sub-Type Sub-TLV Name 107 -------- ----------------------------- 108 TBD1 SR Candidate Path's Path SID 109 TBD2 SR Segment List's Path SID 111 As specified in Section 3 of [I-D.ietf-idr-sr-policy-path-segment], 112 the Path Segment can be used to identify an SR path (specified by SID 113 list) or an SR candidate path, so two different Target FEC sub-TLVs 114 need to be defined for Path Segment ID. When a Path Segment is used 115 to identify an SR path, then the Target FEC sub-TLV of SR Segment 116 List's Path SID would be used to validate the control plane to 117 forwarding plane synchronization for this Path-SID; When a Path 118 Segment is used to identify an SR candidate path, then the Target FEC 119 sub-TLV of SR Candidate Path's Path SID would be used to validate the 120 control plane to forwarding plane synchronization for this Path-SID. 122 3.1. SR Candidate Path's Path SID 124 The format of SR Candidate Path's Path SID sub-TLV is as specified 125 below: 127 0 1 2 3 128 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 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 | Type = TBD1 | Length | 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 ~ Headend (4/16 octets) ~ 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 | Color (4 octets) | 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 ~ Endpoint (4/16 octets) ~ 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 |Protocol-Origin| Reserved | 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 | | 141 | | 142 | Originator (20 octets) | 143 | | 144 | | 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 | Discriminator (4 octets) | 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 Figure 1: SR Candidate Path's Path SID sub-TLV 151 Type 153 This field is set to the value (TBD1) which indicates that it's a 154 SR Candidate Path's Path SID sub-TLV. 156 Length 158 This field is set to the length of the sub-TLV's Value field in 159 octets. If Headend and Endpoint fields are in IPv4 address format 160 which is 4 octets long, it MUST be set to 40; If Headend and 161 Endpoint fields are in IPv6 address format which is 16 octets 162 long, it MUST be set to 64. 164 Headend 166 This field identifies the headend of an SR Policy, the same as 167 defined in Section 2.1 of 168 [I-D.ietf-spring-segment-routing-policy]. The headend is a 169 4-octet IPv4 address or a 16-octet IPv6 address. 171 Color 173 This field associates the SR Policy with an intent, the same as 174 defined in Section 2.1 of 176 [I-D.ietf-spring-segment-routing-policy]. The color is a 4-octet 177 numerical value. 179 Endpoint 181 This field identifies the endpoint of an SR Policy, the same as 182 defined in Section 2.1 of 183 [I-D.ietf-spring-segment-routing-policy]. The endpoint is a 184 4-octet IPv4 address or a 16-octet IPv6 address. 186 Protocol-Origin 188 This field identifies the component or protocol that originates or 189 signals the candidate path for an SR Policy, the same as defined 190 in Section 2.3 of [I-D.ietf-spring-segment-routing-policy]. The 191 protocol-origin is a 1-octet value that follows the recommendation 192 from Table 1 of Section 2.3 of 193 [I-D.ietf-spring-segment-routing-policy], which specifies value 10 194 for "PCEP", value 20 for "BGP SR Policy" and value 30 for "Via 195 Configuration". 197 Originator 199 This field identifies the node which provisioned or signaled the 200 candidate path for an SR Policy, the same as defined in 201 Section 2.4 of [I-D.ietf-spring-segment-routing-policy]. The 202 originator is a 20-octet numerical value formed by the 203 concatenation of the fields of the tuple , 204 among which ASN is a 4-octet number and node address is a 16-octet 205 value (an IPv6 address or an IPv4 address encoded in the lowest 4 206 octets). When Procotol-Origin is respectively "Via 207 Configuration", or "PCEP", or "BGP SR Policy", the values of ASN 208 and node address follow the specification in Section 2.4 of 209 [I-D.ietf-spring-segment-routing-policy]. 211 Discriminator 213 This field uniquely identifies a candidate path within the context 214 of an SR policy, the same as defined in Section 2.5 of 215 [I-D.ietf-spring-segment-routing-policy]. The discriminator is a 216 4-octet value. When Protocol-Origin is respectively "Via 217 Configuration", or "PCEP", or "BGP SR Policy", the value of 218 discriminator follows the specification in Section 2.5 of 219 [I-D.ietf-spring-segment-routing-policy]. 221 3.2. SR Segment List's Path SID 223 The format of SR Segment List's Path SID sub-TLV is as specified 224 below: 226 0 1 2 3 227 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 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | Type = TBD2 | Length | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 ~ Headend (4/16 octets) ~ 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | Color (4 octets) | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 ~ Endpoint (4/16 octets) ~ 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 |Protocol-Origin| Reserved | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | | 240 | | 241 | Originator (20 octets) | 242 | | 243 | | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | Discriminator (4 octets) | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | Segment-List-ID (4 octets) | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 Figure 2: SR Segment List's Path SID sub-TLV 252 Type 254 This field is set to the value (TBD2) which indicates that it's a 255 SR Segment List's Path SID sub-TLV. 257 Length 259 This field is set to the length of the sub-TLV's Value field in 260 octets. If Headend and Endpoint fields are in IPv4 address format 261 which is 4 octets long, it MUST be set to 44; If Headend and 262 Endpoint fields are in IPv6 address format which is 16 octets 263 long, it MUST be set to 68. 265 Headend 267 This field identifies the headend of an SR Policy, the same as 268 defined in Section 2.1 of 270 [I-D.ietf-spring-segment-routing-policy]. The headend is a 271 4-octet IPv4 address or a 16-octet IPv6 address. 273 Color 275 This field associates the SR Policy with an intent, the same as 276 defined in Section 2.1 of 277 [I-D.ietf-spring-segment-routing-policy]. The color is a 4-octet 278 numerical value. 280 Endpoint 282 This field identifies the endpoint of an SR Policy, the same as 283 defined in Section 2.1 of 284 [I-D.ietf-spring-segment-routing-policy]. The endpoint is a 285 4-octet IPv4 address or a 16-octet IPv6 address. 287 Protocol-Origin 289 This field identifies the component or protocol that originates or 290 signals the candidate path for an SR Policy, the same as defined 291 in Section 2.3 of [I-D.ietf-spring-segment-routing-policy]. The 292 protocol-origin is a 1-octet value that follows the recommendation 293 from Table 1 of Section 2.3 of 294 [I-D.ietf-spring-segment-routing-policy], which specifies value 10 295 for "PCEP", value 20 for "BGP SR Policy" and value 30 for "Via 296 Configuration". 298 Originator 300 This field identifies the node which provisioned or signaled the 301 candidate path for an SR Policy, the same as defined in 302 Section 2.4 of [I-D.ietf-spring-segment-routing-policy]. The 303 originator is a 20-octet numerical value formed by the 304 concatenation of the fields of the tuple , 305 among which ASN is a 4-octet number and node address is a 16-octet 306 value (an IPv6 address or an IPv4 address encoded in the lowest 4 307 octets). When Procotol-Origin is respectively "Via 308 Configuration", or "PCEP", or "BGP SR Policy", the values of ASN 309 and node address follow the specification in Section 2.4 of 310 [I-D.ietf-spring-segment-routing-policy]. 312 Discriminator 314 This field uniquely identifies a candidate path within the context 315 of an SR policy, the same as defined in Section 2.5 of 316 [I-D.ietf-spring-segment-routing-policy]. The discriminator is a 317 4-octet value. When Protocol-Origin is respectively "Via 318 Configuration", or "PCEP", or "BGP SR Policy", the value of 319 discriminator follows the specification in Section 2.5 of 320 [I-D.ietf-spring-segment-routing-policy]. 322 Segment-List-ID 324 This field identifies an SR path within the context of a candidate 325 path of an SR Policy, the same as "Path ID" defined in Section 4.2 326 of [I-D.ietf-pce-multipath], or "List Identifier" defined in 327 Section 2.2 of [I-D.lp-idr-sr-path-protection]. The segment-list- 328 ID is a 4-octet identifier of the corresponding segment list. 330 4. Path-SID FEC Validation 332 The MPLS LSP Ping/Traceroute procedures MAY be initiated by the 333 headend of the Segment Routing path or a centralized topology-aware 334 data plane monitoring system as described in [RFC8403]. For the 335 Path-SID, the responder nodes that receive echo request and send echo 336 reply MUST be the endpoint of the Segment Routing path. 338 When an endpoint receives the LSP echo request packet with top FEC 339 being the Path-SID, it SHOULD perform validity checks on the content 340 of the Path-SID FEC sub-TLV. The basic length check should be 341 performed on the received FEC. 343 SR Candidate Path's Path SID 344 ------------------ 345 Length = 40 or 64 347 SR Segment List's Path SID 348 ------------------ 349 Length = 44 or 68 351 If a malformed FEC sub-TLV is received, then a return code of 1, 352 "Malformed echo request received" as defined in [RFC8029] SHOULD be 353 sent. The below section augments the section 7.4 of [RFC8287]. 355 4a. Segment Routing Path-SID Validation: 357 If the Label-stack-depth is 0 and the Target FEC Stack sub-TLV at 358 FEC-stack-depth is TBD1 (SR Candidate Path's Path SID sub-TLV), { 360 Set the Best-return-code to 10, "Mapping for this FEC is not 361 the given label at stack-depth " if any below conditions 362 fail: 364 + Validate that the Path Segment ID is signaled or provisioned 365 for the SR Candidate Path { 366 - When the Protocol-Origin field in the received SR 367 Candidate Path's Path SID sub-TLV is 10, "PCEP" is used 368 as the signaling protocol. And then validate that the 369 Path Segment ID matches with the tuple identifying the SR 370 Candidate Path within PCEP { 372 o Validate that the signaled headend defined in 373 [I-D.ietf-pce-segment-routing-policy-cp] and 374 [I-D.ietf-pce-sr-path-segment], for the Path SID, 375 matches with the headend field in the received SR 376 Candidate Path's Path SID sub-TLV. 378 o Validate that the signaled color defined in 379 [I-D.ietf-pce-segment-routing-policy-cp] and 380 [I-D.ietf-pce-sr-path-segment], for the Path SID, 381 matches with the color field in the received SR 382 Candidate Path's Path SID sub-TLV. 384 o Validate that the signaled end-point defined in 385 [I-D.ietf-pce-segment-routing-policy-cp] and 386 [I-D.ietf-pce-sr-path-segment], for the Path SID, 387 matches with the endpoint field in the received SR 388 Candidate Path's Path SID sub-TLV. 390 o Validate that the signaled both originator ASN and 391 originator address defined in 392 [I-D.ietf-pce-segment-routing-policy-cp] and 393 [I-D.ietf-pce-sr-path-segment], for the Path SID, 394 matches with the originator field in the received SR 395 Candidate Path's Path SID sub-TLV. 397 o Validate that the signaled discriminator defined in 398 [I-D.ietf-pce-segment-routing-policy-cp] and 399 [I-D.ietf-pce-sr-path-segment], for the Path SID, 400 matches with the discriminator field in the received 401 SR Candidate Path's Path SID sub-TLV. 403 } 405 - When the Protocol-Origin field in the received SR 406 Candidate Path's Path SID sub-TLV is 20, "BGP SR Policy" 407 is used as the signaling protocol. And then validate 408 that the Path Segment ID matches with the tuple 409 identifying the SR Candidate Path within BGP SR Policy { 411 o Validate that the signaled headend defined in 412 [I-D.ietf-idr-segment-routing-te-policy] and 413 [I-D.ietf-idr-sr-policy-path-segment], for the Path 414 SID, matches with the headend field in the received SR 415 Candidate Path's Path SID sub-TLV. 417 o Validate that the signaled policy color defined in 418 [I-D.ietf-idr-segment-routing-te-policy] and 419 [I-D.ietf-idr-sr-policy-path-segment], for the Path 420 SID, matches with the color field in the received SR 421 Candidate Path's Path SID sub-TLV. 423 o Validate that the signaled endpoint defined in 424 [I-D.ietf-idr-segment-routing-te-policy] and 425 [I-D.ietf-idr-sr-policy-path-segment], for the Path 426 SID, matches with the endpoint field in the received 427 SR Candidate Path's Path SID sub-TLV. 429 o Validate that the signaled both ASN and BGP Router-ID 430 defined in [I-D.ietf-idr-segment-routing-te-policy] 431 and [I-D.ietf-idr-sr-policy-path-segment], for the 432 Path SID, matches with the originator field in the 433 received SR Candidate Path's Path SID sub-TLV. 435 o Validate that the signaled distinguisher defined in 436 [I-D.ietf-idr-segment-routing-te-policy] and 437 [I-D.ietf-idr-sr-policy-path-segment], for the Path 438 SID, matches with the discriminator field in the 439 received SR Candidate Path's Path SID sub-TLV. 441 } 443 - When the Protocol-Origin field in the received SR 444 Candidate Path's Path SID sub-TLV is 30, "Via 445 Configuration" is used. And then validate that the Path 446 Segment ID matches with the tuple identifying the SR 447 Candidate Path within Configuration { 449 o Validate that the provisioned headend defined in 450 [I-D.ietf-spring-sr-policy-yang], for the Path SID, 451 matches with the headend field in the received SR 452 Candidate Path's Path SID sub-TLV. 454 o Validate that the provisioned color defined in 455 [I-D.ietf-spring-sr-policy-yang], for the Path SID, 456 matches with the color field in the received SR 457 Candidate Path's Path SID sub-TLV. 459 o Validate that the provisioned endpoint defined in 460 [I-D.ietf-spring-sr-policy-yang], for the Path SID, 461 matches with the endpoint field in the received SR 462 Candidate Path's Path SID sub-TLV. 464 o Validate that the provisioned originator defined in 465 [I-D.ietf-spring-sr-policy-yang], for the Path SID, 466 matches with the originator field in the received SR 467 Candidate Path's Path SID sub-TLV. 469 o Validate that the provisioned discriminator defined in 470 [I-D.ietf-spring-sr-policy-yang], for the Path SID, 471 matches with the discriminator field in the received 472 SR Candidate Path's Path SID sub-TLV. 474 } 476 } 478 If all the above validations have passed, set the return code 479 to 3 "Replying router is an egress for the FEC at stack-depth 480 ". 482 Set FEC-Status to 1 and return. 484 } 486 Else, if the Label-stack-depth is 0 and the Target FEC Stack sub- 487 TLV at FEC-stack-depth is TBD2 (SR Segment List's Path SID sub- 488 TLV), { 490 Set the Best-return-code to 10, "Mapping for this FEC is not 491 the given label at stack-depth " if any below conditions 492 fail: 494 + Validate that the Path Segment ID is signaled or provisioned 495 for the SR Segment List { 497 - When the Protocol-Origin field in the received SR Segment 498 List's Path SID sub-TLV is 10, "PCEP" is used as the 499 signaling protocol. And then validate that the Path 500 Segment ID matches with the tuple identifying the SR 501 Segment List within PCEP { 503 o Validate that the signaled headend defined in 504 [I-D.ietf-pce-segment-routing-policy-cp] and 505 [I-D.ietf-pce-sr-path-segment], for the Path SID, 506 matches with the headend field in the received SR 507 Segment List's Path SID sub-TLV. 509 o Validate that the signaled color defined in 510 [I-D.ietf-pce-segment-routing-policy-cp] and 511 [I-D.ietf-pce-sr-path-segment], for the Path SID, 512 matches with the color field in the received SR 513 Segment List's Path SID sub-TLV. 515 o Validate that the signaled end-point defined in 516 [I-D.ietf-pce-segment-routing-policy-cp] and 517 [I-D.ietf-pce-sr-path-segment], for the Path SID, 518 matches with the endpoint field in the received SR 519 Segment List's Path SID sub-TLV. 521 o Validate that the signaled both originator ASN and 522 originator address defined in 523 [I-D.ietf-pce-segment-routing-policy-cp] and 524 [I-D.ietf-pce-sr-path-segment], for the Path SID, 525 matches with the originator field in the received SR 526 Segment List's Path SID sub-TLV. 528 o Validate that the signaled discriminator defined in 529 [I-D.ietf-pce-segment-routing-policy-cp] and 530 [I-D.ietf-pce-sr-path-segment], for the Path SID, 531 matches with the discriminator field in the received 532 SR Segment List's Path SID sub-TLV. 534 o Validate that the signaled Path ID defined in 535 [I-D.ietf-pce-multipath], for the Path SID, matches 536 with the Segment-List-ID field in the received SR 537 Segment List's Path SID sub-TLV. 539 } 541 - When the Protocol-Origin field in the received SR Segment 542 List's Path SID sub-TLV is 20, "BGP SR Policy" is used as 543 the signaling protocol. And then validate that the Path 544 Segment ID matches with the tuple identifying the SR 545 Segment List within BGP SR Policy { 547 o Validate that the signaled headend defined in 548 [I-D.ietf-idr-segment-routing-te-policy] and 549 [I-D.ietf-idr-sr-policy-path-segment], for the Path 550 SID, matches with the headend field in the received SR 551 Segment List's Path SID sub-TLV. 553 o Validate that the signaled policy color defined in 554 [I-D.ietf-idr-segment-routing-te-policy] and 555 [I-D.ietf-idr-sr-policy-path-segment], for the Path 556 SID, matches with the color field in the received SR 557 Segment List's Path SID sub-TLV. 559 o Validate that the signaled endpoint defined in 560 [I-D.ietf-idr-segment-routing-te-policy] and 561 [I-D.ietf-idr-sr-policy-path-segment], for the Path 562 SID, matches with the endpoint field in the received 563 SR Segment List's Path SID sub-TLV. 565 o Validate that the signaled both ASN and BGP Router-ID 566 defined in [I-D.ietf-idr-segment-routing-te-policy] 567 and [I-D.ietf-idr-sr-policy-path-segment], for the 568 Path SID, matches with the originator field in the 569 received SR Segment List's Path SID sub-TLV. 571 o Validate that the signaled distinguisher defined in 572 [I-D.ietf-idr-segment-routing-te-policy] and 573 [I-D.ietf-idr-sr-policy-path-segment], for the Path 574 SID, matches with the discriminator field in the 575 received SR Segment List's Path SID sub-TLV. 577 o Validate that the signaled List Identifier defined in 578 [I-D.lp-idr-sr-path-protection], for the Path SID, 579 matches with the Segment-List-ID field in the received 580 SR Segment List's Path SID sub-TLV. 582 } 584 - When the Protocol-Origin field in the received SR Segment 585 List's Path SID sub-TLV is 30, "Via Configuration" is 586 used. And then validate that the Path Segment ID matches 587 with the tuple identifying the SR Segment List within 588 Configuration { 590 o Validate that the provisioned headend defined in 591 [I-D.ietf-spring-sr-policy-yang], for the Path SID, 592 matches with the headend field in the received SR 593 Segment List's Path SID sub-TLV. 595 o Validate that the provisioned color defined in 596 [I-D.ietf-spring-sr-policy-yang], for the Path SID, 597 matches with the color field in the received SR 598 Segment List's Path SID sub-TLV. 600 o Validate that the provisioned endpoint defined in 601 [I-D.ietf-spring-sr-policy-yang], for the Path SID, 602 matches with the endpoint field in the received SR 603 Segment List's Path SID sub-TLV. 605 o Validate that the provisioned originator defined in 606 [I-D.ietf-spring-sr-policy-yang], for the Path SID, 607 matches with the originator field in the received SR 608 Segment List's Path SID sub-TLV. 610 o Validate that the provisioned discriminator defined in 611 [I-D.ietf-spring-sr-policy-yang], for the Path SID, 612 matches with the discriminator field in the received 613 SR Segment List's Path SID sub-TLV. 615 o Validate that the provisioned Segment-List-ID through 616 Yang Model, for the Path SID, matches with the 617 Segment-List-ID field in the received SR Segment 618 List's Path SID sub-TLV. 620 } 622 } 624 If all the above validations have passed, set the return code 625 to 3 "Replying router is an egress for the FEC at stack-depth 626 ". 628 Set FEC-Status to 1 and return. 630 } 632 5. Security Considerations 634 This document does not raise any additional security issues beyond 635 those of the specifications referred to in the list of normative 636 references. 638 6. IANA Considerations 640 IANA is requested to assign two new sub-TLVs from the "sub-TLVs for 641 TLV Types 1, 16, and 21" subregistry of the "Multi-Protocol Label 642 Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" 643 registry [IANA]. 645 Sub-Type Sub-TLV Name Reference 646 -------- ----------------------------- ------------ 647 TBD1 SR Candidate Path's Path SID Section 3.1 648 TBD2 SR Segment List's Path SID Section 3.2 650 7. Acknowledgements 652 The authors would like to acknowledge Zhao Detao for his thorough 653 review and very helpful comments. 655 The authors would like to acknowledge Yao Liu for very helpful 656 discussion with her. 658 8. References 660 8.1. Normative References 662 [I-D.ietf-spring-mpls-path-segment] 663 Cheng, W., Li, H., Chen, M., Gandhi, R., and R. Zigler, 664 "Path Segment in MPLS Based Segment Routing Network", 665 draft-ietf-spring-mpls-path-segment-04 (work in progress), 666 April 2021. 668 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 669 Requirement Levels", BCP 14, RFC 2119, 670 DOI 10.17487/RFC2119, March 1997, 671 . 673 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 674 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 675 Switched (MPLS) Data-Plane Failures", RFC 8029, 676 DOI 10.17487/RFC8029, March 2017, 677 . 679 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 680 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 681 May 2017, . 683 [RFC8287] Kumar, N., Ed., Pignataro, C., Ed., Swallow, G., Akiya, 684 N., Kini, S., and M. Chen, "Label Switched Path (LSP) 685 Ping/Traceroute for Segment Routing (SR) IGP-Prefix and 686 IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data 687 Planes", RFC 8287, DOI 10.17487/RFC8287, December 2017, 688 . 690 [RFC8690] Nainar, N., Pignataro, C., Iqbal, F., and A. Vainshtein, 691 "Clarification of Segment ID Sub-TLV Length for RFC 8287", 692 RFC 8690, DOI 10.17487/RFC8690, December 2019, 693 . 695 8.2. Informative References 697 [I-D.ietf-idr-segment-routing-te-policy] 698 Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., 699 Rosen, E., Jain, D., and S. Lin, "Advertising Segment 700 Routing Policies in BGP", draft-ietf-idr-segment-routing- 701 te-policy-11 (work in progress), November 2020. 703 [I-D.ietf-idr-sr-policy-path-segment] 704 Li, C., Li, Z., Chen, H., Cheng, W., and K. Talaulikar, 705 "SR Policy Extensions for Path Segment and Bidirectional 706 Path", draft-ietf-idr-sr-policy-path-segment-03 (work in 707 progress), March 2021. 709 [I-D.ietf-mpls-sr-epe-oam] 710 Hegde, S., Arora, K., Srivastava, M., Ninan, S., and X. 711 Xu, "Label Switched Path (LSP) Ping/Traceroute for Segment 712 Routing (SR) Egress Peer Engineering Segment Identifiers 713 (SIDs) with MPLS Data Planes", draft-ietf-mpls-sr-epe- 714 oam-03 (work in progress), April 2021. 716 [I-D.ietf-pce-multipath] 717 Koldychev, M., Sivabalan, S., Saad, T., Beeram, V. P., 718 Bidgoli, H., Yadav, B., and S. Peng, "PCEP Extensions for 719 Signaling Multipath Information", draft-ietf-pce- 720 multipath-00 (work in progress), May 2021. 722 [I-D.ietf-pce-segment-routing-policy-cp] 723 Koldychev, M., Sivabalan, S., Barth, C., Peng, S., and H. 724 Bidgoli, "PCEP extension to support Segment Routing Policy 725 Candidate Paths", draft-ietf-pce-segment-routing-policy- 726 cp-04 (work in progress), March 2021. 728 [I-D.ietf-pce-sr-path-segment] 729 Li, C., Chen, M., Cheng, W., Gandhi, R., and Q. Xiong, 730 "Path Computation Element Communication Protocol (PCEP) 731 Extension for Path Segment in Segment Routing (SR)", 732 draft-ietf-pce-sr-path-segment-03 (work in progress), 733 February 2021. 735 [I-D.ietf-spring-segment-routing-policy] 736 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 737 P. Mattes, "Segment Routing Policy Architecture", draft- 738 ietf-spring-segment-routing-policy-11 (work in progress), 739 April 2021. 741 [I-D.ietf-spring-sr-policy-yang] 742 Raza, K., Sawaya, R., Shunwan, Z., Voyer, D., Durrani, M., 743 Matsushima, S., and V. P. Beeram, "YANG Data Model for 744 Segment Routing Policy", draft-ietf-spring-sr-policy- 745 yang-01 (work in progress), April 2021. 747 [I-D.lp-idr-sr-path-protection] 748 Yao, L. and P. Shaofu, "BGP extensions of SR policy for 749 path protection", draft-lp-idr-sr-path-protection-00 (work 750 in progress), October 2020. 752 [IANA] Internet Assigned Numbers Authority (IANA), "Multi- 753 Protocol Label Switching (MPLS) Label Switched Paths 754 (LSPs) Ping Parameters", . 757 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 758 Decraene, B., Litkowski, S., and R. Shakir, "Segment 759 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 760 July 2018, . 762 [RFC8403] Geib, R., Ed., Filsfils, C., Pignataro, C., Ed., and N. 763 Kumar, "A Scalable and Topology-Aware MPLS Data-Plane 764 Monitoring System", RFC 8403, DOI 10.17487/RFC8403, July 765 2018, . 767 Authors' Addresses 769 Xiao Min 770 ZTE Corp. 771 Nanjing 772 China 774 Phone: +86 25 88013062 775 Email: xiao.min2@zte.com.cn 777 Peng Shaofu 778 ZTE Corp. 779 Nanjing 780 China 782 Email: peng.shaofu@zte.com.cn