idnits 2.17.1 draft-ietf-mpls-spring-lsp-ping-12.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 16, 2017) is 2377 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 (-25) exists of draft-ietf-isis-segment-routing-extensions-13 == Outdated reference: A later version (-23) exists of draft-ietf-ospf-ospfv3-segment-routing-extensions-10 == Outdated reference: A later version (-27) exists of draft-ietf-ospf-segment-routing-extensions-19 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-12 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-ldp-interop-09 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-mpls-10 Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Work group N. Kumar, Ed. 3 Internet-Draft C. Pignataro, Ed. 4 Intended status: Standards Track Cisco 5 Expires: April 19, 2018 G. Swallow 6 Southend Technical Center 7 N. Akiya 8 Big Switch Networks 9 S. Kini 10 Individual 11 M. Chen 12 Huawei 13 October 16, 2017 15 Label Switched Path (LSP) Ping/Traceroute for Segment Routing IGP Prefix 16 and Adjacency SIDs with MPLS Data-plane 17 draft-ietf-mpls-spring-lsp-ping-12 19 Abstract 21 A Segment Routing architecture leverages source routing and tunneling 22 paradigms and can be directly applied to use of a Multi Protocol 23 Label Switching (MPLS) data plane. A node steers a packet through a 24 controlled set of instructions called segments, by prepending the 25 packet with a Segment Routing header. 27 The segment assignment and forwarding semantic nature of Segment 28 Routing raises additional consideration for connectivity verification 29 and fault isolation for an LSP within a Segment Routing architecture. 30 This document illustrates the problem and defines extensions to 31 perform LSP Ping and Traceroute for Segment Routing IGP Prefix and 32 Adjacency SIDs with an MPLS data plane. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on April 19, 2018. 50 Copyright Notice 52 Copyright (c) 2017 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 1.1. Coexistence of SR-Capable and Non-SR-Capable Node 69 Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 4 70 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 71 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 4. Challenges with Existing mechanisms . . . . . . . . . . . . . 4 73 4.1. Path validation in Segment Routing networks . . . . . . . 4 74 5. Segment ID sub-TLV . . . . . . . . . . . . . . . . . . . . . 5 75 5.1. IPv4 IGP-Prefix Segment ID . . . . . . . . . . . . . . . 6 76 5.2. IPv6 IGP-Prefix Segment ID . . . . . . . . . . . . . . . 7 77 5.3. IGP-Adjacency Segment ID . . . . . . . . . . . . . . . . 8 78 6. Extension to Downstream Detailed Mapping TLV . . . . . . . . 9 79 7. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 10 80 7.1. FECs in Target FEC Stack TLV . . . . . . . . . . . . . . 10 81 7.2. FEC Stack Change sub-TLV . . . . . . . . . . . . . . . . 11 82 7.3. Segment ID POP Operation . . . . . . . . . . . . . . . . 11 83 7.4. Segment ID Check . . . . . . . . . . . . . . . . . . . . 11 84 7.5. TTL Consideration for traceroute . . . . . . . . . . . . 17 85 8. Backward Compatibility with non Segment Routing devices . . . 17 86 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 87 9.1. New Target FEC Stack Sub-TLVs . . . . . . . . . . . . . . 18 88 9.2. Protocol in the Segment ID sub-TLV . . . . . . . . . . . 18 89 9.3. Adjacency Type in the IGP-Adjacency Segment ID . . . . . 19 90 9.4. Protocol in Label Stack Sub-TLV of Downstream Detailed 91 Mapping TLV . . . . . . . . . . . . . . . . . . . . . . . 19 92 9.5. Return Code . . . . . . . . . . . . . . . . . . . . . . . 19 93 10. Security Considerations . . . . . . . . . . . . . . . . . . . 20 94 11. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 20 95 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20 96 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 97 13.1. Normative References . . . . . . . . . . . . . . . . . . 20 98 13.2. Informative References . . . . . . . . . . . . . . . . . 21 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 101 1. Introduction 103 "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures" 104 [RFC8029] defines a simple and efficient mechanism to detect data 105 plane failures in Label Switched Paths (LSP) by specifying 106 information to be carried in an MPLS "echo request" and "echo reply" 107 for the purposes of fault detection and isolation. Mechanisms for 108 reliably sending the echo reply are defined. The functionality 109 defined in [RFC8029] is modeled after the ping/traceroute paradigm 110 (ICMP echo request [RFC0792]) and is typically referred to as LSP 111 ping and LSP traceroute. [RFC8029] supports hierarchical and 112 stitching LSPs. 114 [I-D.ietf-spring-segment-routing] introduces and describes a Segment 115 Routing architecture that leverages the source routing and tunneling 116 paradigms. A node steers a packet through a controlled set of 117 instructions called segments, by prepending the packet with Segment 118 Routing header. A detailed definition of the Segment Routing 119 architecture is available in [I-D.ietf-spring-segment-routing]. 121 As described in [I-D.ietf-spring-segment-routing] and 122 [I-D.ietf-spring-segment-routing-mpls], the Segment Routing 123 architecture can be directly applied to an MPLS data plane, the 124 Segment identifier (Segment ID) will be of 20-bits size and the 125 Segment Routing header is the label stack. Consequently, the 126 mechanics of data place validation of [RFC8029] can be directly 127 applied to SR MPLS. 129 Unlike LDP or RSVP which are the other well-known MPLS control plane 130 protocols, the basis of segment ID assignment in Segment Routing 131 architecture is not always on a hop-by-hop basis. Depending on the 132 type of segment ID, the assignment can be unique to the node or 133 within a domain. 135 This nature of Segment Routing raises additional considerations for 136 validation of fault detection and isolation in a Segment Routing 137 network. This document illustrates the problem and describes a 138 mechanism to perform LSP Ping and Traceroute for Segment Routing IGP 139 Prefix and Adjacency SIDs within an MPLS data plane. 141 1.1. Coexistence of SR-Capable and Non-SR-Capable Node Scenarios 143 [I-D.ietf-spring-segment-routing-ldp-interop] describes how Segment 144 Routing operates in a network where SR-capable and non-SR-capable 145 nodes coexist. In such a network, one or more SR-based LSPs and non- 146 SR-based LSPs are stitched together to achieve an end-to-end LSP. 147 This is similar to a network where LDP and RSVP nodes coexist and the 148 mechanism defined in Section 4.5.2 of [RFC8029] is applicable for LSP 149 Ping and Trace. 151 Section 8 of this document explains one of the potential gaps that is 152 specific to SR-Capable and non-SR-capable node scenarios and explains 153 how the existing mechanism defined in [RFC8029] handles it. 155 2. Requirements notation 157 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 158 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 159 document are to be interpreted as described in [RFC2119]. 161 3. Terminology 163 This document uses the terminologies defined in 164 [I-D.ietf-spring-segment-routing], [RFC8029], readers are expected to 165 be familiar with it. 167 4. Challenges with Existing mechanisms 169 The following example describes the challenges with using the current 170 MPLS OAM mechanisms on a Segment Routing network. 172 4.1. Path validation in Segment Routing networks 174 [RFC8029] defines the MPLS OAM mechanisms that help with fault 175 detection and isolation for an MPLS data-plane path by the use of 176 various Target FEC Stack Sub-TLVs that are carried in MPLS Echo 177 Request packets and used by the responder for FEC validation. While 178 it is obvious that new Sub-TLVs need to be assigned for Segment 179 Routing, the unique nature of the Segment Routing architecture raises 180 the need for additional operational considerations for path 181 validation. This section discusses the challenges as below: 183 L1 184 +--------+ 185 | L2 | 186 R3-------R6 187 / \ 188 / \ 189 R1----R2 R7----R8 190 \ / 191 \ / 192 R4-------R5 194 Figure 1: Segment Routing network 196 The Node Segment IDs for R1, R2, R3, R4, R5, R6, R7 and R8 are 5001, 197 5002, 5003, 5004, 5005, 5006, 5007, 5008 respectively. 199 9136 --> Adjacency Segment ID from R3 to R6 over link L1. 200 9236 --> Adjacency Segment ID from R3 to R6 over link L2. 201 9124 --> Adjacency segment ID from R2 to R4. 202 9123 --> Adjacency Segment ID from R2 to R3. 204 The forwarding semantic of Adjacency Segment ID is to pop the Segment 205 ID and send the packet to a specific neighbor over a specific link. 206 A malfunctioning node may forward packets using Adjacency Segment ID 207 to an incorrect neighbor or over an incorrect link. The exposed 208 Segment ID (of an incorrectly forwarded Adjacency Segment ID) might 209 still allow such packet to reach the intended destination, although 210 the intended strict traversal has been broken. 212 Assume in above topology, R1 sends traffic with segment stack as 213 {9124, 5008} so that the path taken will be R1-R2-R4-R5-R7-R8. If 214 the Adjacency Segment ID 9124 is misprogrammed in R2 to send the 215 packet to R1 or R3, the packet may still be delivered to R8 (if the 216 nodes are configured with same SRGB) but is not via the expected 217 path. 219 MPLS traceroute may help with detecting such a deviation in the above 220 mentioned scenario. However, in a different example, it may not be 221 helpful. For example if R3, due to misprogramming, forwards a packet 222 with Adjacency Segment ID 9236 via link L1, while it is expected to 223 be forwarded over Link L2. 225 5. Segment ID sub-TLV 227 The format of the following Segment ID sub-TLVs follows the 228 philosophy of Target FEC Stack TLV carrying FECs corresponding to 229 each label in the label stack. When operated with the procedures 230 defined in [RFC8029], this allows LSP ping/traceroute operations to 231 function when Target FEC Stack TLV contains more FECs than received 232 label stack at responder nodes. 234 Three new sub-TLVs are defined for Target FEC Stack TLVs (Type 1), 235 Reverse-Path Target FEC Stack TLV (Type 16) and Reply Path TLV (Type 236 21). 238 sub-Type Value Field 239 -------- --------------- 240 34 IPv4 IGP-Prefix Segment ID 241 35 IPv6 IGP-Prefix Segment ID 242 36 IGP-Adjacency Segment ID 244 See Section 9.2 for the registry for the Protocol field specified 245 wihtin these sub-TLVs. 247 5.1. IPv4 IGP-Prefix Segment ID 249 The IPv4 IGP-Prefix Segment ID is defined in 250 [I-D.ietf-spring-segment-routing]. The format is as specified below: 252 0 1 2 3 253 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 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | IPv4 Prefix | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 |Prefix Length | Protocol | Reserved | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 IPv4 Prefix 262 This field carries the IPv4 prefix to which the Segment ID is 263 assigned. In case of Anycast Segment ID, this field will carry 264 IPv4 Anycast address. If the prefix is shorter than 32 bits, 265 trailing bits SHOULD be set to zero. 267 Prefix Length 269 The Prefix Length field is one octet, it gives the length of the 270 prefix in bits (values can be 1 - 32). 272 Protocol 273 Set to 1, if the Responder MUST perform FEC validation using OSPF 274 as IGP protocol. Set to 2, if the Responder MUST perform Egress 275 FEC validation using ISIS as IGP protocol. Set to 0, if Responder 276 can use any IGP protocol for Egress FEC validation. 278 Reserved 280 MUST be set to 0 on send, and MUST be ignored on receipt. 282 5.2. IPv6 IGP-Prefix Segment ID 284 The IPv6 IGP-Prefix Segment ID is defined in 285 [I-D.ietf-spring-segment-routing]. The format is as specified below: 287 0 1 2 3 288 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 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | | 291 | IPv6 Prefix | 292 | | 293 | | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 |Prefix Length | Protocol | Reserved | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 IPv6 Prefix 300 This field carries the IPv6 prefix to which the Segment ID is 301 assigned. In case of Anycast Segment ID, this field will carry 302 IPv4 Anycast address. If the prefix is shorter than 128 bits, 303 trailing bits SHOULD be set to zero. 305 Prefix Length 307 The Prefix Length field is one octet, it gives the length of the 308 prefix in bits (values can be 1 - 128). 310 Protocol 312 Set to 1, if the Responder MUST perform FEC validation using OSPF 313 as IGP protocol. Set to 2, if the Responder MUST perform Egress 314 FEC validation using ISIS as IGP protocol. Set to 0, if Responder 315 can use any IGP protocol for Egress FEC validation. 317 Reserved 318 MUST be set to 0 on send, and MUST be ignored on receipt. 320 5.3. IGP-Adjacency Segment ID 322 This Sub-TLV is applicable for any IGP-Adjacency defined in 323 [I-D.ietf-spring-segment-routing]. The format is as specified below: 325 0 1 2 3 326 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 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | Adj. Type | Protocol | Reserved | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 ~ ~ 331 | Local Interface ID (4 or 16 octets) | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 ~ ~ 334 | Remote Interface ID (4 or 16 octets) | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 ~ ~ 337 | Advertising Node Identifier (4 or 6 octets) | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 ~ ~ 340 | Receiving Node Identifier (4 or 6 octets) | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 Adj. Type (Adjacency Type) 345 Set to 1, when the Adjacency Segment is Parallel Adjacency as 346 defined in [I-D.ietf-spring-segment-routing]. Set to 4, when the 347 Adjacency segment is IPv4 based and is not a parallel adjacency. 348 Set to 6, when the Adjacency segment is IPv6 based and is not a 349 parallel adjacency. Set to 0, when the Adjacency segment is over 350 unnumbered interface. 352 Protocol 354 Set to 1, if the Responder MUST perform FEC validation using OSPF 355 as IGP protocol. Set to 2, if the Responder MUST perform Egress 356 FEC validation using ISIS as IGP protocol. Set to 0, if Responder 357 can use any IGP protocol for Egress FEC validation. 359 Reserved 361 MUST be set to 0 on send, and MUST be ignored on receipt. 363 Local Interface ID 364 An identifier that is assigned by the local LSR for a link to 365 which Adjacency Segment ID is bound. This field is set to a local 366 link address (IPv4 or IPv6). For IPv4, this field is 4 octets; 367 for IPv6, this field is 16 octets. In case of unnumbered, this 368 field is 4 octets and includes a 32 bit link identifier as defined 369 in [RFC4203], [RFC5307]. If the Adjacency Segment ID represents 370 parallel adjacencies ([I-D.ietf-spring-segment-routing]), this 371 field is 4 octets and MUST be set to 4 octets of zeroes. 373 Remote Interface ID 375 An identifier that is assigned by remote LSR for a link on which 376 Adjacency Segment ID is bound. This field is set to remote 377 (downstream neighbor) link address (IPv4 or IPv6). For IPv4, this 378 field is 4 octets; for IPv6, this field is 16 oct ets. In case of 379 unnumbered, this field is 4 octets and includes a 32 bit link 380 identifier as defined in [RFC4203], [RFC5307]. If the Adjacency 381 Segment ID represents parallel adjacencies 382 ([I-D.ietf-spring-segment-routing]), this field is 4 octets and 383 MUST be set to 4 octets of zeroes. 385 Advertising Node Identifier 387 It specifies the advertising node identifier. When Protocol is 388 set to 1, then this field is 4 octets and carries the 32-bit OSPF 389 Router ID; if Protocol is set to 2, then this field is 6 octets 390 and carries the 48-bit ISIS System ID; if Protocol is set to 0, 391 then this field is 4 octets, and MUST be set to zero. 393 Receiving Node Identifier 395 It specifies the downstream node identifier. When Protocol is set 396 to 1, then this field is 4 octets and carries the 32-bit OSPF 397 Router ID; if Protocol is set to 2, then this field is 6 octets 398 and carries the 48-bit ISIS System ID; if Protocol is set to 0, 399 then this field is 4 octets, and MUST be set to zero. 401 6. Extension to Downstream Detailed Mapping TLV 403 In an echo reply, the Downstream Detailed Mapping TLV [RFC8029] is 404 used to report for each interface over which a FEC could be 405 forwarded. For a FEC, there are multiple protocols that may be used 406 to distribute label mapping. The "Protocol" field of the Downstream 407 Detailed Mapping TLV is used to return the protocol that is used to 408 distribute the label carried in "Downstream Label" field. The 409 following protocols are defined in [RFC8029]: 411 Protocol # Signaling Protocol 412 ---------- ------------------ 413 0 Unknown 414 1 Static 415 2 BGP 416 3 LDP 417 4 RSVP-TE 419 With segment routing, OSPF or ISIS can be used for label 420 distribution, this document adds two new protocols as follows: 422 Protocol # Signaling Protocol 423 ---------- ------------------ 424 5 OSPF 425 6 ISIS 427 See Section 9.4. 429 7. Procedures 431 This section describes aspects of LSP Ping and traceroute operations 432 that require further considerations beyond [RFC8029]. 434 7.1. FECs in Target FEC Stack TLV 436 When LSP echo request packets are generated by an initiator, FECs 437 carried in the Target FEC Stack TLV may need to differ to support a 438 Segment Routing architecture. The following defines Target FEC Stack 439 TLV construction mechanics by an initiator for Segment Routing 440 scenarios. 442 Ping 444 Initiator MUST include FEC(s) corresponding to the destination 445 segment. 447 Initiator MAY include FECs corresponding to some or all of 448 segments imposed in the label stack by the initiator to 449 communicate the segments traversed. 451 Traceroute 453 Initiator MUST initially include FECs corresponding to all of 454 segments imposed in the label stack. 456 When a received echo reply contains FEC Stack Change TLV with 457 one or more of original segment(s) being popped, initiator MAY 458 remove corresponding FEC(s) from Target FEC Stack TLV in the 459 next (TTL+1) traceroute request as defined in Section 4.6 of 460 [RFC8029]. 462 When a received echo reply does not contain FEC Stack Change 463 TLV, initiator MUST NOT attempt to remove FEC(s) from Target 464 FEC Stack TLV in the next (TTL+1) traceroute request. 466 As defined in [I-D.ietf-ospf-segment-routing-extensions] and 467 [I-D.ietf-isis-segment-routing-extensions], Prefix SID can be 468 advertised as absolute value, index or as range. In any of these 469 cases, Initiator MUST derive the Prefix mapped to the Prefix SID and 470 use it in IGP-Prefix Segment ID defined in Section 5.1 and 5.2. 472 7.2. FEC Stack Change sub-TLV 474 [RFC8029] defines a FEC Stack Change sub-TLV that a router must 475 include when the FEC stack changes. 477 The network node which advertised the Node Segment ID is responsible 478 for generating a FEC Stack Change sub-TLV with pop operation type for 479 Node Segment ID, regardless of whether penultimate hop popping (PHP) 480 is enabled or not. 482 The network node that is immediate downstream of the node which 483 advertised the Adjacency Segment ID is responsible for generating FEC 484 Stack Change sub-TLV for "POP" operation for Adjacency Segment ID. 486 7.3. Segment ID POP Operation 488 The forwarding semantic of Node Segment ID with PHP flag is 489 equivalent to usage of implicit Null in MPLS protocols. Adjacency 490 Segment ID is also similar in a sense that it can be thought of as 491 locally allocated segment that has PHP enabled destined for next hop 492 IGP adjacency node. Procedures described in Section 4.4 of [RFC8029] 493 relies on Stack-D and Stack-R explicitly having Implicit Null value. 494 It may simplify implementations to reuse Implicit Null for Node 495 Segment ID PHP and Adjacency Segment ID cases. 497 7.4. Segment ID Check 499 This section modifies the procedure defined in Section 4.4.1 of 500 [RFC8029]. Step 4 defined in Section 4.4.1 of [RFC8029] is updated 501 as below: 503 4. If the label mapping for FEC is Implicit Null, set FEC-status 504 to 2 and proceed to step 4a. Otherwise, if the label mapping 505 for FEC is Label-L, proceed to step 4a. Otherwise, set 506 FEC-return-code to 10 ("Mapping for this FEC is not the given 507 label at stack-depth"), set FEC-status to 1, and return. 509 4a. Segment Routing IGP Prefix and Adjacency SID Validation: 511 If the Label-stack-depth is 0 and Target FEC Stack Sub-TLV at 512 FEC-stack-depth is 34 (IPv4 IGP-Prefix Segment ID), { 514 Set Best return code to 10, "Mapping for this FEC is not the 515 given label at stack-depth " if any below conditions 516 fail: 518 /* The responder LSR is to check if it is the egress of the 519 IPv4 IGP-Prefix Segment ID described in the Target FEC Stack 520 Sub-TLV, and if the FEC was advertised with the PHP bit 521 set.*/ 523 - Validate that Node Segment ID is advertised for IPv4 524 Prefix by IGP Protocol { 526 o When protocol field in received IPv4 IGP-Prefix 527 Segment ID Sub-TLV is 0, Use any locally enabled IGP 528 protocol. 530 o When protocol field in received IPv4 IGP-Prefix 531 Segment ID Sub-TLV is 1, Use OSPF as IGP protocol. 533 o When protocol field in received IPv4 IGP-Prefix 534 Segment ID Sub-TLV is 2, Use ISIS as IGP protocol. 536 o When protocol field in received IPv4 IGP-Prefix 537 Segment ID Sub-TLV is an unrecognized value, it MUST 538 be treated as Protocol value of 0. 540 } 542 - Validate that Node Segment ID is advertised with No-PHP 543 flag { 545 o When Protocol is OSPF, NP-flag defined in Section 5 of 546 [I-D.ietf-ospf-segment-routing-extensions] MUST be set 547 to 0. 549 o When Protocol is ISIS, P-Flag defined in Section 2.1 550 of [I-D.ietf-isis-segment-routing-extensions] MUST be 551 set to 0. 553 } 555 If it can be determined that no protocol associated with 556 Interface-I would have advertised FEC-Type at FEC-stack- 557 depth, Set Best return code to 12, "Protocol not associated 558 with interface at FEC stack-depth" and return. 560 set FEC-Status to 1, and return. 562 } 564 Else if the Label-stack-depth is greater than 0 and Target FEC 565 Stack Sub-TLV at FEC-stack-depth is 34 (IPv4 IGP-Prefix Segment 566 ID), { 568 Set Best return code to 10 if any below conditions fail: 570 - Validate that Node Segment ID is advertised for IPv4 571 Prefix by IGP Protocol { 573 o When protocol field in received IPv4 IGP-Prefix 574 Segment ID Sub-TLV is 0, Use any locally enabled IGP 575 protocol. 577 o When protocol field in received IPv4 IGP-Prefix 578 Segment ID Sub-TLV is 1, Use OSPF as IGP protocol. 580 o When protocol field in received IPv4 IGP-Prefix 581 Segment ID Sub-TLV is 2, Use ISIS as IGP protocol. 583 o When protocol field in received IPv4 IGP-Prefix 584 Segment ID Sub-TLV is an unrecognized value, it MUST 585 be treated as Protocol value of 0. 587 } 589 If it can be determined that no protocol associated with 590 Interface-I would have advertised FEC-Type at FEC-stack- 591 depth, Set Best return code to 12, "Protocol not associated 592 with interface at FEC stack-depth" and return. 594 set FEC-Status to 1, and return. 596 } 598 Else if the Label-stack-depth is 0 and Target FEC Sub-TLV at 599 FEC-stack-depth is 35 (IPv6 IGP-Prefix Segment ID), { 601 Set Best return code to 10 if any of the below conditions 602 fail: 604 /* The LSR needs to check if its being a tail-end for the 605 LSP and have the prefix advertised with PHP bit set*/ 607 - Validate that Node Segment ID is advertised for IPv6 608 Prefix by IGP Protocol { 610 o When protocol field in received IPv6 IGP-Prefix 611 Segment ID Sub-TLV is 0, Use any locally enabled IGP 612 protocol. 614 o When protocol field in received IPv6 IGP-Prefix 615 Segment ID Sub-TLV is 1, Use OSPF as IGP protocol. 617 o When protocol field in received IPv6 IGP-Prefix 618 Segment ID Sub-TLV is 2, Use ISIS as IGP protocol. 620 o When protocol field in received IPv6 IGP-Prefix 621 Segment ID Sub-TLV is an unrecognized value, it MUST 622 be treated as Protocol value of 0. 624 } 626 - Validate that Node Segment ID is advertised with No-PHP 627 flag. { 629 o When Protocol is OSPF, NP-flag defined in Section 5 of 630 [I-D.ietf-ospf-ospfv3-segment-routing-extensions] MUST 631 be set to 0. 633 o When Protocol is ISIS, P-Flag defined in Section 2.1 634 of [I-D.ietf-isis-segment-routing-extensions] MUST be 635 set to 0. 637 } 639 If it can be determined that no protocol associated with 640 Interface-I would have advertised FEC-Type at FEC-stack- 641 depth, Set Best return code to 12, "Protocol not associated 642 with interface at FEC stack-depth" and return. 644 set FEC-Status to 1, and return. 646 } 648 Else if the Label-stack-depth is greater than 0 and Target FEC 649 Sub-TLV at FEC-stack-depth is 35 (IPv6 IGP-Prefix Segment ID), 650 { 652 set Best return code to 10 if any below conditions fail: 654 - Validate that Node Segment ID is advertised for IPv4 655 Prefix by IGP Protocol { 657 o When protocol field in received IPv6 IGP-Prefix 658 Segment ID Sub-TLV is 0, Use any locally enabled IGP 659 protocol. 661 o When protocol field in received IPv6 IGP-Prefix 662 Segment ID Sub-TLV is 1, Use OSPF as IGP protocol. 664 o When protocol field in received IPv6 IGP-Prefix 665 Segment ID Sub-TLV is 2, Use ISIS as IGP protocol. 667 o When protocol field in received IPv6 IGP-Prefix 668 Segment ID Sub-TLV is an unrecognized value, it MUST 669 be treated as Protocol value of 0. 671 } 673 If it can be determined that no protocol associated with 674 Interface-I would have advertised FEC-Type at FEC-stack- 675 depth, Set Best return code to 12, "Protocol not associated 676 with interface at FEC stack-depth" and return. 678 set FEC-Status to 1, and return. 680 } 682 Else if the Target FEC sub-TLV at FEC-stack-depth is 36 (IGP- 683 Adjacency Segment ID), { 685 set Best return code to TBD1 (Section 10.3) if any below 686 conditions fail: 688 When the Adj. Type is 1 (Parallel Adjacency): 690 o Validate that Receiving Node Identifier is local IGP 691 identifier. 693 o Validate that IGP-Adjacency Segment ID is advertised 694 by Advertising Node Identifier of Protocol in local 695 IGP database { 697 * When protocol field in received IGP-Adjacency 698 Segment ID Sub-TLV is 0, Use any locally enabled 699 IGP protocol. 701 * When protocol field in received IGP-Adjacency 702 Segment ID Sub-TLV is 1, Use OSPF as IGP protocol. 704 * When protocol field in received IGP-Adjacency 705 Segment ID Sub-TLV is 2, Use ISIS as IGP protocol. 707 * When protocol field in received IGP-Adjacency 708 Segment ID Sub-TLV is an unrecognized value, it 709 MUST be treated as Protocol value of 0. 711 } 713 When the Adj. Type is 4 or 6 (IGP Adjacency or LAN 714 Adjacency): 716 o Validate that Remote Interface ID matches the local 717 identifier of the interface (Interface-I) on which the 718 packet was received. 720 o Validate that Receiving Node Identifier is local IGP 721 identifier. 723 o Validate that IGP-Adjacency Segment ID is advertised 724 by Advertising Node Identifier of Protocol in local 725 IGP database { 727 * When protocol field in received IGP-Adjacency 728 Segment ID Sub-TLV is 0, Use any locally enabled 729 IGP protocol. 731 * When protocol field in received IGP-Adjacency 732 Segment ID Sub-TLV is 1, Use OSPF as IGP protocol. 734 * When protocol field in received IGP-Adjacency 735 Segment ID Sub-TLV is 2, Use ISIS as IGP protocol. 737 * When protocol field in received IGP-Adjacency 738 Segment ID Sub-TLV is an unrecognized value, it 739 MUST be treated as Protocol value of 0. 741 } 743 set FEC-Status to 1, and return. 745 } 747 7.5. TTL Consideration for traceroute 749 LSP Traceroute operation can properly traverse every hop of Segment 750 Routing network for the Uniform Model as described in [RFC3443]. If 751 one or more LSRs employ a Short Pipe Model, as described in 752 [RFC3443], then LSP Traceroute may not be able to properly traverse 753 every hop of Segment Routing network due to the absence of TTL copy 754 operation when the outer label is popped. The Short Pipe is one of 755 the most commonly used models. The following TTL manipulation 756 technique MAY be used when the Short Pipe model is used. 758 When tracing a LSP according to the procedures in [RFC8029] the TTL 759 is incremented by one in order to trace the path sequentially along 760 the LSP. However when a source routed LSP has to be traced there are 761 as many TTLs as there are labels in the stack. The LSR that 762 initiates the traceroute SHOULD start by setting the TTL to 1 for the 763 tunnel in the LSP's label stack it wants to start the tracing from, 764 the TTL of all outer labels in the stack to the max value, and the 765 TTL of all the inner labels in the stack to zero. Thus a typical 766 start to the traceroute would have a TTL of 1 for the outermost label 767 and all the inner labels would have TTL 0. If the FEC Stack TLV is 768 included it should contain only those for the inner stacked tunnels. 769 The Return Code/Subcode and FEC Stack Change TLV should be used to 770 diagnose the tunnel as described in [RFC8029]. When the tracing of a 771 tunnel in the stack is complete, then the next tunnel in the stack 772 should be traced. The end of a tunnel can be detected from the 773 "Return Code" when it indicates that the responding LSR is an egress 774 for the stack at depth 1. Thus the traceroute procedures in 775 [RFC8029] can be recursively applied to traceroute a source routed 776 LSP. 778 8. Backward Compatibility with non Segment Routing devices 780 [I-D.ietf-spring-segment-routing-ldp-interop] describes how Segment 781 Routing operates in a network where SR-capable and non-SR-capable 782 nodes coexist. In such networks, there may not be any FEC mapping in 783 the responder, when the Initiator is SR-capable, while the responder 784 is not (or vice-versa). But this is not different from RSVP and LDP 785 interop scenarios. When LSP Ping is triggered, the responder will 786 set the FEC-return-code to Return 4, "Replying router has no mapping 787 for the FEC at stack-depth". 789 Similarly when a SR-capable node assigns Adj-SID for a non-SR-capable 790 node, LSP traceroute may fail as the non-SR-capable node is not aware 791 of "IGP Adjacency Segment ID" sub-TLV and may not reply with FEC 792 Stack change. This may result in any further downstream nodes to 793 reply back with Return-code as 4, "Replying router has no mapping for 794 the FEC at stack-depth". 796 9. IANA Considerations 798 9.1. New Target FEC Stack Sub-TLVs 800 IANA is requested to assign three new Sub-TLVs from "Sub-TLVs for TLV 801 Types 1, 16 and 21" sub-registry from the "Multi-Protocol Label 802 Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" 803 [IANA-MPLS-LSP-PING] registry. 805 Sub-Type Sub-TLV Name Reference 806 -------- ----------------- ------------ 807 34 IPv4 IGP-Prefix Segment ID Section 5.1 of this document 808 35 IPv6 IGP-Prefix Segment ID Section 5.2 of this document 809 36 IGP-Adjacency Segment ID Section 5.3 of this document 811 Note to the RFC Editor (please remove before publication): IANA has 812 made early allocation for sub-type 34, 35 and 35. The early 813 allocation expires 2018-09-15. 815 9.2. Protocol in the Segment ID sub-TLV 817 IANA is requested to create a new "Protocol in the Segment ID sub- 818 TLV" (see Section 5) registry under the "Multi-Protocol Label 819 Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" 820 registry. Code points in the range of 0-250 will be assigned by 821 Standards Action. The range of 251-254 are reserved for experimental 822 use and will not be assigned. The initial entries into the registry 823 will be: 825 Value Meaning Reference 826 ---------- ---------------- ------------ 827 0 Any IGP Protocol This document 828 1 OSPF This document 829 2 ISIS This document 831 9.3. Adjacency Type in the IGP-Adjacency Segment ID 833 IANA is requested to create a new "Adjacency Type in the IGP- 834 Adjacency Segment ID" (see Section 5.3) registry under the "Multi- 835 Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping 836 Parameters" registry. Code points in the range of 0-250 will be 837 assigned by Standards Action. The range of 251-254 are reserved for 838 experimental use and will not be assigned. The initial entries into 839 the registry will be: 841 Value Meaning 842 ---------- ---------------- 843 0 Unnumbered interface Adjacency 844 1 Parallel Adjacency 845 4 IPv4, non-parallel Adjacency 846 6 IPv6, non-parallel Adjacency 848 9.4. Protocol in Label Stack Sub-TLV of Downstream Detailed Mapping TLV 850 IANA is requested to create a new "Protocol in Label Stack Sub-TLV of 851 Downstream Detailed Mapping TLV" registry under the "Multi-Protocol 852 Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" 853 registry. Code points in the range of 0-250 will be assigned by 854 Standards Action. The range of 251-254 are reserved for experimental 855 use and will not be assigned. The initial entries into the registry 856 will be: 858 Value Meaning Reference 859 ---------- ---------------- ------------ 860 0 Unknown Section 3.4.1.2 of RFC8029 861 1 Static Section 3.4.1.2 of RFC8029 862 2 BGP Section 3.4.1.2 of RFC8029 863 3 LDP Section 3.4.1.2 of RFC8029 864 4 RSVP-TE Section 3.4.1.2 of RFC8029 865 5 OSPF Section 6 of this document 866 6 ISIS Section 6 of this document 867 7-250 Unassigned 868 251-254 Experimental use This document 869 255 Reserved This document 871 9.5. Return Code 873 IANA is requested to assign a new Return Code from the "Multi- 874 Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping 875 Parameters" in the 0-191 (Standards Action) range from the "Return 876 Codes" Sub-registry. 878 Value Meaning Reference 879 ---------- ----------------- ------------ 880 TBD1 Mapping for this FEC is not associated Section 7.4 of 881 with the incoming interface this document 883 10. Security Considerations 885 This document defines additional MPLS LSP Ping Sub-TLVs and follows 886 the mechanisms defined in [RFC8029]. All the security considerations 887 defined in [RFC8029] will be applicable for this document, and in 888 addition, they do not impose any additional security challenges to be 889 considered. 891 11. Acknowledgement 893 The authors would like to thank Stefano Previdi, Les Ginsberg, Balaji 894 Rajagopalan, Harish Sitaraman, Curtis Villamizar, Pranjal Dutta, 895 Lizhong Jin, Tom Petch, Victor Ji and Mustapha Aissaoui, Tony 896 Przygienda, Alexander Vainshtein and Deborah Brungard for their 897 review and comments. 899 The authors wold like to thank Loa Andersson for his comments and 900 recommendation to merge drafts. 902 12. Contributors 904 The following are key contributors to this document: 906 Hannes Gredler, RtBrick, Inc. 908 Tarek Saad, Cisco Systems, Inc. 910 Siva Sivabalan, Cisco Systems, Inc. 912 Balaji Rajagopalan, Juniper Networks 914 Faisal Iqbal, Cisco Systems, Inc. 916 13. References 918 13.1. Normative References 920 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 921 Requirement Levels", BCP 14, RFC 2119, 922 DOI 10.17487/RFC2119, March 1997, 923 . 925 [RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing 926 in Multi-Protocol Label Switching (MPLS) Networks", 927 RFC 3443, DOI 10.17487/RFC3443, January 2003, 928 . 930 [RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in 931 Support of Generalized Multi-Protocol Label Switching 932 (GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005, 933 . 935 [RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions 936 in Support of Generalized Multi-Protocol Label Switching 937 (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008, 938 . 940 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 941 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 942 Switched (MPLS) Data-Plane Failures", RFC 8029, 943 DOI 10.17487/RFC8029, March 2017, 944 . 946 13.2. Informative References 948 [I-D.ietf-isis-segment-routing-extensions] 949 Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., 950 Litkowski, S., Decraene, B., and j. jefftant@gmail.com, 951 "IS-IS Extensions for Segment Routing", draft-ietf-isis- 952 segment-routing-extensions-13 (work in progress), June 953 2017. 955 [I-D.ietf-ospf-ospfv3-segment-routing-extensions] 956 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 957 Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3 958 Extensions for Segment Routing", draft-ietf-ospf-ospfv3- 959 segment-routing-extensions-10 (work in progress), 960 September 2017. 962 [I-D.ietf-ospf-segment-routing-extensions] 963 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 964 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 965 Extensions for Segment Routing", draft-ietf-ospf-segment- 966 routing-extensions-19 (work in progress), August 2017. 968 [I-D.ietf-spring-segment-routing] 969 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 970 and R. Shakir, "Segment Routing Architecture", draft-ietf- 971 spring-segment-routing-12 (work in progress), June 2017. 973 [I-D.ietf-spring-segment-routing-ldp-interop] 974 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., and 975 S. Litkowski, "Segment Routing interworking with LDP", 976 draft-ietf-spring-segment-routing-ldp-interop-09 (work in 977 progress), September 2017. 979 [I-D.ietf-spring-segment-routing-mpls] 980 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 981 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 982 data plane", draft-ietf-spring-segment-routing-mpls-10 983 (work in progress), June 2017. 985 [IANA-MPLS-LSP-PING] 986 IANA, "Multi-Protocol Label Switching (MPLS) Label 987 Switched Paths (LSPs) Ping Parameters", 988 . 991 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 992 RFC 792, DOI 10.17487/RFC0792, September 1981, 993 . 995 Authors' Addresses 997 Nagendra Kumar (editor) 998 Cisco Systems, Inc. 999 7200-12 Kit Creek Road 1000 Research Triangle Park, NC 27709-4987 1001 US 1003 Email: naikumar@cisco.com 1005 Carlos Pignataro (editor) 1006 Cisco Systems, Inc. 1007 7200-11 Kit Creek Road 1008 Research Triangle Park, NC 27709-4987 1009 US 1011 Email: cpignata@cisco.com 1013 George Swallow 1014 Southend Technical Center 1016 Email: swallow.ietf@gmail.com 1017 Nobo Akiya 1018 Big Switch Networks 1020 Email: nobo.akiya.dev@gmail.com 1022 Sriganesh Kini 1023 Individual 1025 Email: sriganeshkini@gmail.com 1027 Mach(Guoyi) Chen 1028 Huawei 1030 Email: mach.chen@huawei.com