idnits 2.17.1 draft-xp-mpls-spring-lsp-ping-path-sid-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 (October 30, 2020) is 1264 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-03 == Outdated reference: A later version (-26) exists of draft-ietf-idr-segment-routing-te-policy-09 == Outdated reference: A later version (-09) exists of draft-ietf-idr-sr-policy-path-segment-01 == Outdated reference: A later version (-13) exists of draft-ietf-mpls-sr-epe-oam-00 == Outdated reference: A later version (-15) exists of draft-ietf-pce-segment-routing-policy-cp-01 == Outdated reference: A later version (-09) exists of draft-ietf-pce-sr-path-segment-01 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-08 == Outdated reference: A later version (-03) exists of draft-ietf-spring-sr-policy-yang-00 == Outdated reference: A later version (-06) exists of draft-lp-idr-sr-path-protection-00 Summary: 0 errors (**), 0 flaws (~~), 10 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: May 3, 2021 October 30, 2020 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-00 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 May 3, 2021. 34 Copyright Notice 36 Copyright (c) 2020 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 172 This field associates the SR Policy with an intent, the same as 173 defined in Section 2.1 of 174 [I-D.ietf-spring-segment-routing-policy]. The color is a 4-octet 175 numerical value. 177 Endpoint 179 This field identifies the endpoint of an SR Policy, the same as 180 defined in Section 2.1 of 181 [I-D.ietf-spring-segment-routing-policy]. The endpoint is a 182 4-octet IPv4 address or a 16-octet IPv6 address. 184 Protocol-Origin 186 This field identifies the component or protocol that originates or 187 signals the candidate path for an SR Policy, the same as defined 188 in Section 2.3 of [I-D.ietf-spring-segment-routing-policy]. The 189 protocol-origin is a 1-octet value that follows the recommendation 190 from Table 1 of Section 2.3 of 191 [I-D.ietf-spring-segment-routing-policy], which specifies value 10 192 for "PCEP", value 20 for "BGP SR Policy" and value 30 for "Via 193 Configuration". 195 Originator 197 This field identifies the node which provisioned or signaled the 198 candidate path for an SR Policy, the same as defined in 199 Section 2.4 of [I-D.ietf-spring-segment-routing-policy]. The 200 originator is a 20-octet numerical value formed by the 201 concatenation of the fields of the tuple , 202 among which ASN is a 4-octet number and node address is a 16-octet 203 value (an IPv6 address or an IPv4 address encoded in the lowest 4 204 octets). When Procotol-Origin is respectively "Via 205 Configuration", or "PCEP", or "BGP SR Policy", the values of ASN 206 and node address follow the specification in Section 2.4 of 207 [I-D.ietf-spring-segment-routing-policy]. 209 Discriminator 211 This field uniquely identifies a candidate path within the context 212 of an SR policy, the same as defined in Section 2.5 of 213 [I-D.ietf-spring-segment-routing-policy]. The discriminator is a 214 4-octet value. When Protocol-Origin is respectively "Via 215 Configuration", or "PCEP", or "BGP SR Policy", the value of 216 discriminator follows the specification in Section 2.5 of 217 [I-D.ietf-spring-segment-routing-policy]. 219 3.2. SR Segment List's Path SID 221 The format of SR Segment List's Path SID sub-TLV is as specified 222 below: 224 0 1 2 3 225 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 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | Type = TBD2 | Length | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 ~ Headend (4/16 octets) ~ 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | Color (4 octets) | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 ~ Endpoint (4/16 octets) ~ 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 |Protocol-Origin| Reserved | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | | 238 | | 239 | Originator (20 octets) | 240 | | 241 | | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | Discriminator (4 octets) | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | Segment-List-ID (4 octets) | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 Figure 2: SR Segment List's Path SID sub-TLV 250 Type 252 This field is set to the value (TBD2) which indicates that it's a 253 SR Segment List's Path SID sub-TLV. 255 Length 257 This field is set to the length of the sub-TLV's Value field in 258 octets. If Headend and Endpoint fields are in IPv4 address format 259 which is 4 octets long, it MUST be set to 44; If Headend and 260 Endpoint fields are in IPv6 address format which is 16 octets 261 long, it MUST be set to 68. 263 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 "List Identifier" defined in 322 Section 2.2 of [I-D.lp-idr-sr-path-protection]. The segment-list- 323 ID is a 4-octet identifier of the corresponding segment list. 325 4. Path-SID FEC Validation 327 The MPLS LSP Ping/Traceroute procedures MAY be initiated by the 328 headend of the Segment Routing path or a centralized topology-aware 329 data plane monitoring system as described in [RFC8403]. For the 330 Path-SID, the responder nodes that receive echo request and send echo 331 reply MUST be the endpoint of the Segment Routing path. 333 When an endpoint receives the LSP echo request packet with top FEC 334 being the Path-SID, it SHOULD perform validity checks on the content 335 of the Path-SID FEC sub-TLV. The basic length check should be 336 performed on the received FEC. 338 SR Candidate Path's Path SID 339 ------------------ 340 Length = 40 or 64 342 SR Segment List's Path SID 343 ------------------ 344 Length = 44 or 68 346 If a malformed FEC sub-TLV is received, then a return code of 1, 347 "Malformed echo request received" as defined in [RFC8029] SHOULD be 348 sent. The below section augments the section 7.4 of [RFC8287]. 350 4a. Segment Routing Path-SID Validation: 352 If the Label-stack-depth is 0 and the Target FEC Stack sub-TLV at 353 FEC-stack-depth is TBD1 (SR Candidate Path's Path SID sub-TLV), { 354 Set the Best-return-code to 10, "Mapping for this FEC is not 355 the given label at stack-depth " if any below conditions 356 fail: 358 + Validate that the Path Segment ID is signaled or provisioned 359 for the SR Candidate Path { 361 - When the Protocol-Origin field in the received SR 362 Candidate Path's Path SID sub-TLV is 10, "PCEP" is used 363 as the signaling protocol. And then validate that the 364 Path Segment ID matches with the tuples identifying the 365 SR Candidate Path within PCEP { 367 o Validate that the signaled headend defined in 368 [I-D.ietf-pce-segment-routing-policy-cp] and 369 [I-D.ietf-pce-sr-path-segment], for the Path SID, 370 matches with the headend field in the received SR 371 Candidate Path's Path SID sub-TLV. 373 o Validate that the signaled color defined in 374 [I-D.ietf-pce-segment-routing-policy-cp] and 375 [I-D.ietf-pce-sr-path-segment], for the Path SID, 376 matches with the color field in the received SR 377 Candidate Path's Path SID sub-TLV. 379 o Validate that the signaled end-point defined in 380 [I-D.ietf-pce-segment-routing-policy-cp] and 381 [I-D.ietf-pce-sr-path-segment], for the Path SID, 382 matches with the endpoint field in the received SR 383 Candidate Path's Path SID sub-TLV. 385 o Validate that the signaled both originator ASN and 386 originator address defined in 387 [I-D.ietf-pce-segment-routing-policy-cp] and 388 [I-D.ietf-pce-sr-path-segment], for the Path SID, 389 matches with the originator field in the received SR 390 Candidate Path's Path SID sub-TLV. 392 o Validate that the signaled discriminator defined in 393 [I-D.ietf-pce-segment-routing-policy-cp] and 394 [I-D.ietf-pce-sr-path-segment], for the Path SID, 395 matches with the discriminator field in the received 396 SR Candidate Path's Path SID sub-TLV. 398 } 400 - When the Protocol-Origin field in the received SR 401 Candidate Path's Path SID sub-TLV is 20, "BGP SR Policy" 402 is used as the signaling protocol. And then validate 403 that the Path Segment ID matches with the tuples 404 identifying the SR Candidate Path within BGP SR Policy { 406 o Validate that the signaled headend defined in 407 [I-D.ietf-idr-segment-routing-te-policy] and 408 [I-D.ietf-idr-sr-policy-path-segment], for the Path 409 SID, matches with the headend field in the received SR 410 Candidate Path's Path SID sub-TLV. 412 o Validate that the signaled policy color defined in 413 [I-D.ietf-idr-segment-routing-te-policy] and 414 [I-D.ietf-idr-sr-policy-path-segment], for the Path 415 SID, matches with the color field in the received SR 416 Candidate Path's Path SID sub-TLV. 418 o Validate that the signaled endpoint defined in 419 [I-D.ietf-idr-segment-routing-te-policy] and 420 [I-D.ietf-idr-sr-policy-path-segment], for the Path 421 SID, matches with the endpoint field in the received 422 SR Candidate Path's Path SID sub-TLV. 424 o Validate that the signaled both ASN and BGP Router-ID 425 defined in [I-D.ietf-idr-segment-routing-te-policy] 426 and [I-D.ietf-idr-sr-policy-path-segment], for the 427 Path SID, matches with the originator field in the 428 received SR Candidate Path's Path SID sub-TLV. 430 o Validate that the signaled distinguisher defined in 431 [I-D.ietf-idr-segment-routing-te-policy] and 432 [I-D.ietf-idr-sr-policy-path-segment], for the Path 433 SID, matches with the discriminator field in the 434 received SR Candidate Path's Path SID sub-TLV. 436 } 438 - When the Protocol-Origin field in the received SR 439 Candidate Path's Path SID sub-TLV is 30, "Via 440 Configuration" is used. And then validate that the Path 441 Segment ID matches with the tuples identifying the SR 442 Candidate Path within Configuration { 444 o Validate that the provisioned headend defined in 445 [I-D.ietf-spring-sr-policy-yang], for the Path SID, 446 matches with the headend field in the received SR 447 Candidate Path's Path SID sub-TLV. 449 o Validate that the provisioned color defined in 450 [I-D.ietf-spring-sr-policy-yang], for the Path SID, 451 matches with the color field in the received SR 452 Candidate Path's Path SID sub-TLV. 454 o Validate that the provisioned endpoint defined in 455 [I-D.ietf-spring-sr-policy-yang], for the Path SID, 456 matches with the endpoint field in the received SR 457 Candidate Path's Path SID sub-TLV. 459 o Validate that the provisioned originator defined in 460 [I-D.ietf-spring-sr-policy-yang], for the Path SID, 461 matches with the originator field in the received SR 462 Candidate Path's Path SID sub-TLV. 464 o Validate that the provisioned discriminator defined in 465 [I-D.ietf-spring-sr-policy-yang], for the Path SID, 466 matches with the discriminator field in the received 467 SR Candidate Path's Path SID sub-TLV. 469 } 471 } 473 If all the above validations have passed, set the return code 474 to 3 "Replying router is an egress for the FEC at stack-depth 475 ". 477 Set FEC-Status to 1 and return. 479 } 481 Else, if the Label-stack-depth is 0 and the Target FEC Stack sub- 482 TLV at FEC-stack-depth is TBD2 (SR Segment List's Path SID sub- 483 TLV), { 485 Set the Best-return-code to 10, "Mapping for this FEC is not 486 the given label at stack-depth " if any below conditions 487 fail: 489 + Validate that the Path Segment ID is signaled or provisioned 490 for the SR Segment List { 492 - When the Protocol-Origin field in the received SR Segment 493 List's Path SID sub-TLV is 10, "PCEP" is used as the 494 signaling protocol. And then validate that the Path 495 Segment ID matches with the tuples identifying the SR 496 Segment List within PCEP { 497 o Validate that the signaled headend defined in 498 [I-D.ietf-pce-segment-routing-policy-cp] and 499 [I-D.ietf-pce-sr-path-segment], for the Path SID, 500 matches with the headend field in the received SR 501 Segment List's Path SID sub-TLV. 503 o Validate that the signaled color 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 color field in the received SR 507 Segment List's Path SID sub-TLV. 509 o Validate that the signaled end-point 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 endpoint field in the received SR 513 Segment List's Path SID sub-TLV. 515 o Validate that the signaled both originator ASN and 516 originator address defined in 517 [I-D.ietf-pce-segment-routing-policy-cp] and 518 [I-D.ietf-pce-sr-path-segment], for the Path SID, 519 matches with the originator field in the received SR 520 Segment List's Path SID sub-TLV. 522 o Validate that the signaled discriminator 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 discriminator field in the received 526 SR Segment List's Path SID sub-TLV. 528 o Validate that the signaled Segment-List-ID by PCEP, 529 for the Path SID, matches with the Segment-List-ID 530 field in the received SR Segment List's Path SID sub- 531 TLV. 533 } 535 - When the Protocol-Origin field in the received SR Segment 536 List's Path SID sub-TLV is 20, "BGP SR Policy" is used as 537 the signaling protocol. And then validate that the Path 538 Segment ID matches with the tuples identifying the SR 539 Segment List within BGP SR Policy { 541 o Validate that the signaled headend defined in 542 [I-D.ietf-idr-segment-routing-te-policy] and 543 [I-D.ietf-idr-sr-policy-path-segment], for the Path 544 SID, matches with the headend field in the received SR 545 Segment List's Path SID sub-TLV. 547 o Validate that the signaled policy color 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 color field in the received SR 551 Segment List's Path SID sub-TLV. 553 o Validate that the signaled endpoint 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 endpoint field in the received 557 SR Segment List's Path SID sub-TLV. 559 o Validate that the signaled both ASN and BGP Router-ID 560 defined in [I-D.ietf-idr-segment-routing-te-policy] 561 and [I-D.ietf-idr-sr-policy-path-segment], for the 562 Path SID, matches with the originator field in the 563 received SR Segment List's Path SID sub-TLV. 565 o Validate that the signaled distinguisher defined in 566 [I-D.ietf-idr-segment-routing-te-policy] and 567 [I-D.ietf-idr-sr-policy-path-segment], for the Path 568 SID, matches with the discriminator field in the 569 received SR Segment List's Path SID sub-TLV. 571 o Validate that the signaled List Identifier defined in 572 [I-D.lp-idr-sr-path-protection], for the Path SID, 573 matches with the Segment-List-ID field in the received 574 SR Segment List's Path SID sub-TLV. 576 } 578 - When the Protocol-Origin field in the received SR Segment 579 List's Path SID sub-TLV is 30, "Via Configuration" is 580 used. And then validate that the Path Segment ID matches 581 with the tuples identifying the SR Segment List within 582 Configuration { 584 o Validate that the provisioned headend defined in 585 [I-D.ietf-spring-sr-policy-yang], for the Path SID, 586 matches with the headend field in the received SR 587 Segment List's Path SID sub-TLV. 589 o Validate that the provisioned color defined in 590 [I-D.ietf-spring-sr-policy-yang], for the Path SID, 591 matches with the color field in the received SR 592 Segment List's Path SID sub-TLV. 594 o Validate that the provisioned endpoint defined in 595 [I-D.ietf-spring-sr-policy-yang], for the Path SID, 596 matches with the endpoint field in the received SR 597 Segment List's Path SID sub-TLV. 599 o Validate that the provisioned originator defined in 600 [I-D.ietf-spring-sr-policy-yang], for the Path SID, 601 matches with the originator field in the received SR 602 Segment List's Path SID sub-TLV. 604 o Validate that the provisioned discriminator defined in 605 [I-D.ietf-spring-sr-policy-yang], for the Path SID, 606 matches with the discriminator field in the received 607 SR Segment List's Path SID sub-TLV. 609 o Validate that the provisioned Segment-List-ID through 610 Yang Model, for the Path SID, matches with the 611 Segment-List-ID field in the received SR Segment 612 List's Path SID sub-TLV. 614 } 616 } 618 If all the above validations have passed, set the return code 619 to 3 "Replying router is an egress for the FEC at stack-depth 620 ". 622 Set FEC-Status to 1 and return. 624 } 626 5. Security Considerations 628 This document does not raise any additional security issues beyond 629 those of the specifications referred to in the list of normative 630 references. 632 6. IANA Considerations 634 IANA is requested to assign two new sub-TLVs from the "sub-TLVs for 635 TLV Types 1, 16, and 21" subregistry of the "Multi-Protocol Label 636 Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" 637 registry [IANA]. 639 Sub-Type Sub-TLV Name Reference 640 -------- ----------------------------- ------------ 641 TBD1 SR Candidate Path's Path SID Section 3.1 642 TBD2 SR Segment List's Path SID Section 3.2 644 7. Acknowledgements 646 The authors would like to acknowledge Zhao Detao for his thorough 647 review and very helpful comments. 649 8. References 651 8.1. Normative References 653 [I-D.ietf-spring-mpls-path-segment] 654 Cheng, W., Li, H., Chen, M., Gandhi, R., and R. Zigler, 655 "Path Segment in MPLS Based Segment Routing Network", 656 draft-ietf-spring-mpls-path-segment-03 (work in progress), 657 September 2020. 659 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 660 Requirement Levels", BCP 14, RFC 2119, 661 DOI 10.17487/RFC2119, March 1997, 662 . 664 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 665 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 666 Switched (MPLS) Data-Plane Failures", RFC 8029, 667 DOI 10.17487/RFC8029, March 2017, 668 . 670 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 671 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 672 May 2017, . 674 [RFC8287] Kumar, N., Ed., Pignataro, C., Ed., Swallow, G., Akiya, 675 N., Kini, S., and M. Chen, "Label Switched Path (LSP) 676 Ping/Traceroute for Segment Routing (SR) IGP-Prefix and 677 IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data 678 Planes", RFC 8287, DOI 10.17487/RFC8287, December 2017, 679 . 681 [RFC8690] Nainar, N., Pignataro, C., Iqbal, F., and A. Vainshtein, 682 "Clarification of Segment ID Sub-TLV Length for RFC 8287", 683 RFC 8690, DOI 10.17487/RFC8690, December 2019, 684 . 686 8.2. Informative References 688 [I-D.ietf-idr-segment-routing-te-policy] 689 Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., 690 Rosen, E., Jain, D., and S. Lin, "Advertising Segment 691 Routing Policies in BGP", draft-ietf-idr-segment-routing- 692 te-policy-09 (work in progress), May 2020. 694 [I-D.ietf-idr-sr-policy-path-segment] 695 Li, C., Li, Z., Telecom, C., Cheng, W., and K. Talaulikar, 696 "SR Policy Extensions for Path Segment and Bidirectional 697 Path", draft-ietf-idr-sr-policy-path-segment-01 (work in 698 progress), August 2020. 700 [I-D.ietf-mpls-sr-epe-oam] 701 Hegde, S., Arora, K., Srivastava, M., Ninan, S., and X. 702 Xu, "Label Switched Path (LSP) Ping/Traceroute for Segment 703 Routing (SR) Egress Peer Engineering Segment Identifiers 704 (SIDs) with MPLS Data Planes", draft-ietf-mpls-sr-epe- 705 oam-00 (work in progress), June 2020. 707 [I-D.ietf-pce-segment-routing-policy-cp] 708 Koldychev, M., Sivabalan, S., Barth, C., Peng, S., and H. 709 Bidgoli, "PCEP extension to support Segment Routing Policy 710 Candidate Paths", draft-ietf-pce-segment-routing-policy- 711 cp-01 (work in progress), October 2020. 713 [I-D.ietf-pce-sr-path-segment] 714 Li, C., Chen, M., Cheng, W., Gandhi, R., and Q. Xiong, 715 "Path Computation Element Communication Protocol (PCEP) 716 Extension for Path Segment in Segment Routing (SR)", 717 draft-ietf-pce-sr-path-segment-01 (work in progress), May 718 2020. 720 [I-D.ietf-spring-segment-routing-policy] 721 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 722 P. Mattes, "Segment Routing Policy Architecture", draft- 723 ietf-spring-segment-routing-policy-08 (work in progress), 724 July 2020. 726 [I-D.ietf-spring-sr-policy-yang] 727 Raza, K., Sawaya, R., Shunwan, Z., Voyer, D., Durrani, M., 728 Matsushima, S., and V. Beeram, "YANG Data Model for 729 Segment Routing Policy", draft-ietf-spring-sr-policy- 730 yang-00 (work in progress), September 2020. 732 [I-D.lp-idr-sr-path-protection] 733 Yao, L. and S. Peng, "BGP extensions of SR policy for path 734 protection", draft-lp-idr-sr-path-protection-00 (work in 735 progress), October 2020. 737 [IANA] Internet Assigned Numbers Authority (IANA), "Multi- 738 Protocol Label Switching (MPLS) Label Switched Paths 739 (LSPs) Ping Parameters", . 742 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 743 Decraene, B., Litkowski, S., and R. Shakir, "Segment 744 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 745 July 2018, . 747 [RFC8403] Geib, R., Ed., Filsfils, C., Pignataro, C., Ed., and N. 748 Kumar, "A Scalable and Topology-Aware MPLS Data-Plane 749 Monitoring System", RFC 8403, DOI 10.17487/RFC8403, July 750 2018, . 752 Authors' Addresses 754 Xiao Min 755 ZTE Corp. 756 Nanjing 757 China 759 Email: xiao.min2@zte.com.cn 761 Peng Shaofu 762 ZTE Corp. 763 Nanjing 764 China 766 Email: peng.shaofu@zte.com.cn