idnits 2.17.1 draft-ietf-mpls-spring-lsp-ping-13.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 17, 2017) is 2383 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 20, 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 17, 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-13 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 20, 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. How 471 the Responder uses the details in the SR-FEC Sub-TLV to perform the 472 validation is a local implementation matter. 474 7.2. FEC Stack Change sub-TLV 476 [RFC8029] defines a FEC Stack Change sub-TLV that a router must 477 include when the FEC stack changes. 479 The network node which advertised the Node Segment ID is responsible 480 for generating a FEC Stack Change sub-TLV with pop operation type for 481 Node Segment ID, regardless of whether penultimate hop popping (PHP) 482 is enabled or not. 484 The network node that is immediate downstream of the node which 485 advertised the Adjacency Segment ID is responsible for generating FEC 486 Stack Change sub-TLV for "POP" operation for Adjacency Segment ID. 488 7.3. Segment ID POP Operation 490 The forwarding semantic of Node Segment ID with PHP flag is 491 equivalent to usage of implicit Null in MPLS protocols. Adjacency 492 Segment ID is also similar in a sense that it can be thought of as 493 locally allocated segment that has PHP enabled destined for next hop 494 IGP adjacency node. Procedures described in Section 4.4 of [RFC8029] 495 relies on Stack-D and Stack-R explicitly having Implicit Null value. 496 Implementations SHOULD use Implicit Null for Node Segment ID PHP and 497 Adjacency Segment ID PHP cases. 499 7.4. Segment ID Check 501 This section modifies the procedure defined in Section 4.4.1 of 502 [RFC8029]. Step 4 defined in Section 4.4.1 of [RFC8029] is updated 503 as below: 505 4. If the label mapping for FEC is Implicit Null, set FEC-status 506 to 2 and proceed to step 4a. Otherwise, if the label mapping 507 for FEC is Label-L, proceed to step 4a. Otherwise, set 508 FEC-return-code to 10 ("Mapping for this FEC is not the given 509 label at stack-depth"), set FEC-status to 1, and return. 511 4a. Segment Routing IGP Prefix and Adjacency SID Validation: 513 If the Label-stack-depth is 0 and Target FEC Stack Sub-TLV at 514 FEC-stack-depth is 34 (IPv4 IGP-Prefix Segment ID), { 516 Set Best return code to 10, "Mapping for this FEC is not the 517 given label at stack-depth " if any below conditions 518 fail: 520 /* The responder LSR is to check if it is the egress of the 521 IPv4 IGP-Prefix Segment ID described in the Target FEC Stack 522 Sub-TLV, and if the FEC was advertised with the PHP bit 523 set.*/ 525 - Validate that Node Segment ID is advertised for IPv4 526 Prefix by IGP Protocol { 528 o When protocol field in received IPv4 IGP-Prefix 529 Segment ID Sub-TLV is 0, Use any locally enabled IGP 530 protocol. 532 o When protocol field in received IPv4 IGP-Prefix 533 Segment ID Sub-TLV is 1, Use OSPF as IGP protocol. 535 o When protocol field in received IPv4 IGP-Prefix 536 Segment ID Sub-TLV is 2, Use ISIS as IGP protocol. 538 o When protocol field in received IPv4 IGP-Prefix 539 Segment ID Sub-TLV is an unrecognized value, it MUST 540 be treated as Protocol value of 0. 542 } 544 - Validate that Node Segment ID is advertised with No-PHP 545 flag { 547 o When Protocol is OSPF, NP-flag defined in Section 5 of 548 [I-D.ietf-ospf-segment-routing-extensions] MUST be set 549 to 0. 551 o When Protocol is ISIS, P-Flag defined in Section 2.1 552 of [I-D.ietf-isis-segment-routing-extensions] MUST be 553 set to 0. 555 } 557 If it can be determined that no protocol associated with 558 Interface-I would have advertised FEC-Type at FEC-stack- 559 depth, Set Best return code to 12, "Protocol not associated 560 with interface at FEC stack-depth" and return. 562 set FEC-Status to 1, and return. 564 } 566 Else if the Label-stack-depth is greater than 0 and Target FEC 567 Stack Sub-TLV at FEC-stack-depth is 34 (IPv4 IGP-Prefix Segment 568 ID), { 570 Set Best return code to 10 if any below conditions fail: 572 - Validate that Node Segment ID is advertised for IPv4 573 Prefix by IGP Protocol { 575 o When protocol field in received IPv4 IGP-Prefix 576 Segment ID Sub-TLV is 0, Use any locally enabled IGP 577 protocol. 579 o When protocol field in received IPv4 IGP-Prefix 580 Segment ID Sub-TLV is 1, Use OSPF as IGP protocol. 582 o When protocol field in received IPv4 IGP-Prefix 583 Segment ID Sub-TLV is 2, Use ISIS as IGP protocol. 585 o When protocol field in received IPv4 IGP-Prefix 586 Segment ID Sub-TLV is an unrecognized value, it MUST 587 be treated as Protocol value of 0. 589 } 591 If it can be determined that no protocol associated with 592 Interface-I would have advertised FEC-Type at FEC-stack- 593 depth, Set Best return code to 12, "Protocol not associated 594 with interface at FEC stack-depth" and return. 596 set FEC-Status to 1, and return. 598 } 600 Else if the Label-stack-depth is 0 and Target FEC Sub-TLV at 601 FEC-stack-depth is 35 (IPv6 IGP-Prefix Segment ID), { 603 Set Best return code to 10 if any of the below conditions 604 fail: 606 /* The LSR needs to check if its being a tail-end for the 607 LSP and have the prefix advertised with PHP bit set*/ 609 - Validate that Node Segment ID is advertised for IPv6 610 Prefix by IGP Protocol { 612 o When protocol field in received IPv6 IGP-Prefix 613 Segment ID Sub-TLV is 0, Use any locally enabled IGP 614 protocol. 616 o When protocol field in received IPv6 IGP-Prefix 617 Segment ID Sub-TLV is 1, Use OSPF as IGP protocol. 619 o When protocol field in received IPv6 IGP-Prefix 620 Segment ID Sub-TLV is 2, Use ISIS as IGP protocol. 622 o When protocol field in received IPv6 IGP-Prefix 623 Segment ID Sub-TLV is an unrecognized value, it MUST 624 be treated as Protocol value of 0. 626 } 628 - Validate that Node Segment ID is advertised with No-PHP 629 flag. { 631 o When Protocol is OSPF, NP-flag defined in Section 5 of 632 [I-D.ietf-ospf-ospfv3-segment-routing-extensions] MUST 633 be set to 0. 635 o When Protocol is ISIS, P-Flag defined in Section 2.1 636 of [I-D.ietf-isis-segment-routing-extensions] MUST be 637 set to 0. 639 } 641 If it can be determined that no protocol associated with 642 Interface-I would have advertised FEC-Type at FEC-stack- 643 depth, Set Best return code to 12, "Protocol not associated 644 with interface at FEC stack-depth" and return. 646 set FEC-Status to 1, and return. 648 } 650 Else if the Label-stack-depth is greater than 0 and Target FEC 651 Sub-TLV at FEC-stack-depth is 35 (IPv6 IGP-Prefix Segment ID), 652 { 654 set Best return code to 10 if any below conditions fail: 656 - Validate that Node Segment ID is advertised for IPv4 657 Prefix by IGP Protocol { 659 o When protocol field in received IPv6 IGP-Prefix 660 Segment ID Sub-TLV is 0, Use any locally enabled IGP 661 protocol. 663 o When protocol field in received IPv6 IGP-Prefix 664 Segment ID Sub-TLV is 1, Use OSPF as IGP protocol. 666 o When protocol field in received IPv6 IGP-Prefix 667 Segment ID Sub-TLV is 2, Use ISIS as IGP protocol. 669 o When protocol field in received IPv6 IGP-Prefix 670 Segment ID Sub-TLV is an unrecognized value, it MUST 671 be treated as Protocol value of 0. 673 } 675 If it can be determined that no protocol associated with 676 Interface-I would have advertised FEC-Type at FEC-stack- 677 depth, Set Best return code to 12, "Protocol not associated 678 with interface at FEC stack-depth" and return. 680 set FEC-Status to 1, and return. 682 } 684 Else if the Target FEC sub-TLV at FEC-stack-depth is 36 (IGP- 685 Adjacency Segment ID), { 687 set Best return code to TBD1 (Section 10.3) if any below 688 conditions fail: 690 When the Adj. Type is 1 (Parallel Adjacency): 692 o Validate that Receiving Node Identifier is local IGP 693 identifier. 695 o Validate that IGP-Adjacency Segment ID is advertised 696 by Advertising Node Identifier of Protocol in local 697 IGP database { 699 * When protocol field in received IGP-Adjacency 700 Segment ID Sub-TLV is 0, Use any locally enabled 701 IGP protocol. 703 * When protocol field in received IGP-Adjacency 704 Segment ID Sub-TLV is 1, Use OSPF as IGP protocol. 706 * When protocol field in received IGP-Adjacency 707 Segment ID Sub-TLV is 2, Use ISIS as IGP protocol. 709 * When protocol field in received IGP-Adjacency 710 Segment ID Sub-TLV is an unrecognized value, it 711 MUST be treated as Protocol value of 0. 713 } 715 When the Adj. Type is 4 or 6 (IGP Adjacency or LAN 716 Adjacency): 718 o Validate that Remote Interface ID matches the local 719 identifier of the interface (Interface-I) on which the 720 packet was received. 722 o Validate that Receiving Node Identifier is local IGP 723 identifier. 725 o Validate that IGP-Adjacency Segment ID is advertised 726 by Advertising Node Identifier of Protocol in local 727 IGP database { 729 * When protocol field in received IGP-Adjacency 730 Segment ID Sub-TLV is 0, Use any locally enabled 731 IGP protocol. 733 * When protocol field in received IGP-Adjacency 734 Segment ID Sub-TLV is 1, Use OSPF as IGP protocol. 736 * When protocol field in received IGP-Adjacency 737 Segment ID Sub-TLV is 2, Use ISIS as IGP protocol. 739 * When protocol field in received IGP-Adjacency 740 Segment ID Sub-TLV is an unrecognized value, it 741 MUST be treated as Protocol value of 0. 743 } 745 set FEC-Status to 1, and return. 747 } 749 7.5. TTL Consideration for traceroute 751 LSP Traceroute operation can properly traverse every hop of Segment 752 Routing network for the Uniform Model as described in [RFC3443]. If 753 one or more LSRs employ a Short Pipe Model, as described in 754 [RFC3443], then LSP Traceroute may not be able to properly traverse 755 every hop of Segment Routing network due to the absence of TTL copy 756 operation when the outer label is popped. The Short Pipe is one of 757 the most commonly used models. The following TTL manipulation 758 technique MAY be used when the Short Pipe model is used. 760 When tracing a LSP according to the procedures in [RFC8029] the TTL 761 is incremented by one in order to trace the path sequentially along 762 the LSP. However when a source routed LSP has to be traced there are 763 as many TTLs as there are labels in the stack. The LSR that 764 initiates the traceroute SHOULD start by setting the TTL to 1 for the 765 tunnel in the LSP's label stack it wants to start the tracing from, 766 the TTL of all outer labels in the stack to the max value, and the 767 TTL of all the inner labels in the stack to zero. Thus a typical 768 start to the traceroute would have a TTL of 1 for the outermost label 769 and all the inner labels would have TTL 0. If the FEC Stack TLV is 770 included it should contain only those for the inner stacked tunnels. 771 The Return Code/Subcode and FEC Stack Change TLV should be used to 772 diagnose the tunnel as described in [RFC8029]. When the tracing of a 773 tunnel in the stack is complete, then the next tunnel in the stack 774 should be traced. The end of a tunnel can be detected from the 775 "Return Code" when it indicates that the responding LSR is an egress 776 for the stack at depth 1. Thus the traceroute procedures in 777 [RFC8029] can be recursively applied to traceroute a source routed 778 LSP. 780 8. Backward Compatibility with non Segment Routing devices 782 [I-D.ietf-spring-segment-routing-ldp-interop] describes how Segment 783 Routing operates in a network where SR-capable and non-SR-capable 784 nodes coexist. In such networks, there may not be any FEC mapping in 785 the responder, when the Initiator is SR-capable, while the responder 786 is not (or vice-versa). But this is not different from RSVP and LDP 787 interop scenarios. When LSP Ping is triggered, the responder will 788 set the FEC-return-code to Return 4, "Replying router has no mapping 789 for the FEC at stack-depth". 791 Similarly when a SR-capable node assigns Adj-SID for a non-SR-capable 792 node, LSP traceroute may fail as the non-SR-capable node is not aware 793 of "IGP Adjacency Segment ID" sub-TLV and may not reply with FEC 794 Stack change. This may result in any further downstream nodes to 795 reply back with Return-code as 4, "Replying router has no mapping for 796 the FEC at stack-depth". 798 9. IANA Considerations 800 9.1. New Target FEC Stack Sub-TLVs 802 IANA is requested to assign three new Sub-TLVs from "Sub-TLVs for TLV 803 Types 1, 16 and 21" sub-registry from the "Multi-Protocol Label 804 Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" 805 [IANA-MPLS-LSP-PING] registry. 807 Sub-Type Sub-TLV Name Reference 808 -------- ----------------- ------------ 809 34 IPv4 IGP-Prefix Segment ID Section 5.1 of this document 810 35 IPv6 IGP-Prefix Segment ID Section 5.2 of this document 811 36 IGP-Adjacency Segment ID Section 5.3 of this document 813 Note to the RFC Editor (please remove before publication): IANA has 814 made early allocation for sub-type 34, 35 and 35. The early 815 allocation expires 2018-09-15. 817 9.2. Protocol in the Segment ID sub-TLV 819 IANA is requested to create a new "Protocol in the Segment ID sub- 820 TLV" (see Section 5) registry under the "Multi-Protocol Label 821 Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" 822 registry. Code points in the range of 0-250 will be assigned by 823 Standards Action. The range of 251-254 are reserved for experimental 824 use and will not be assigned. The initial entries into the registry 825 will be: 827 Value Meaning Reference 828 ---------- ---------------- ------------ 829 0 Any IGP Protocol This document 830 1 OSPF This document 831 2 ISIS This document 833 9.3. Adjacency Type in the IGP-Adjacency Segment ID 835 IANA is requested to create a new "Adjacency Type in the IGP- 836 Adjacency Segment ID" (see Section 5.3) registry under the "Multi- 837 Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping 838 Parameters" registry. Code points in the range of 0-250 will be 839 assigned by Standards Action. The range of 251-254 are reserved for 840 experimental use and will not be assigned. The initial entries into 841 the registry will be: 843 Value Meaning 844 ---------- ---------------- 845 0 Unnumbered interface Adjacency 846 1 Parallel Adjacency 847 4 IPv4, non-parallel Adjacency 848 6 IPv6, non-parallel Adjacency 850 9.4. Protocol in Label Stack Sub-TLV of Downstream Detailed Mapping TLV 852 IANA is requested to create a new "Protocol in Label Stack Sub-TLV of 853 Downstream Detailed Mapping TLV" registry under the "Multi-Protocol 854 Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" 855 registry. Code points in the range of 0-250 will be assigned by 856 Standards Action. The range of 251-254 are reserved for experimental 857 use and will not be assigned. The initial entries into the registry 858 will be: 860 Value Meaning Reference 861 ---------- ---------------- ------------ 862 0 Unknown Section 3.4.1.2 of RFC8029 863 1 Static Section 3.4.1.2 of RFC8029 864 2 BGP Section 3.4.1.2 of RFC8029 865 3 LDP Section 3.4.1.2 of RFC8029 866 4 RSVP-TE Section 3.4.1.2 of RFC8029 867 5 OSPF Section 6 of this document 868 6 ISIS Section 6 of this document 869 7-250 Unassigned 870 251-254 Experimental use This document 871 255 Reserved This document 873 9.5. Return Code 875 IANA is requested to assign a new Return Code from the "Multi- 876 Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping 877 Parameters" in the 0-191 (Standards Action) range from the "Return 878 Codes" Sub-registry. 880 Value Meaning Reference 881 ---------- ----------------- ------------ 882 TBD1 Mapping for this FEC is not associated Section 7.4 of 883 with the incoming interface this document 885 10. Security Considerations 887 This document defines additional MPLS LSP Ping Sub-TLVs and follows 888 the mechanisms defined in [RFC8029]. All the security considerations 889 defined in [RFC8029] will be applicable for this document, and in 890 addition, they do not impose any additional security challenges to be 891 considered. 893 11. Acknowledgement 895 The authors would like to thank Stefano Previdi, Les Ginsberg, Balaji 896 Rajagopalan, Harish Sitaraman, Curtis Villamizar, Pranjal Dutta, 897 Lizhong Jin, Tom Petch, Victor Ji and Mustapha Aissaoui, Tony 898 Przygienda, Alexander Vainshtein and Deborah Brungard for their 899 review and comments. 901 The authors wold like to thank Loa Andersson for his comments and 902 recommendation to merge drafts. 904 12. Contributors 906 The following are key contributors to this document: 908 Hannes Gredler, RtBrick, Inc. 910 Tarek Saad, Cisco Systems, Inc. 912 Siva Sivabalan, Cisco Systems, Inc. 914 Balaji Rajagopalan, Juniper Networks 916 Faisal Iqbal, Cisco Systems, Inc. 918 13. References 920 13.1. Normative References 922 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 923 Requirement Levels", BCP 14, RFC 2119, 924 DOI 10.17487/RFC2119, March 1997, 925 . 927 [RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing 928 in Multi-Protocol Label Switching (MPLS) Networks", 929 RFC 3443, DOI 10.17487/RFC3443, January 2003, 930 . 932 [RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in 933 Support of Generalized Multi-Protocol Label Switching 934 (GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005, 935 . 937 [RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions 938 in Support of Generalized Multi-Protocol Label Switching 939 (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008, 940 . 942 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 943 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 944 Switched (MPLS) Data-Plane Failures", RFC 8029, 945 DOI 10.17487/RFC8029, March 2017, 946 . 948 13.2. Informative References 950 [I-D.ietf-isis-segment-routing-extensions] 951 Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., 952 Litkowski, S., Decraene, B., and j. jefftant@gmail.com, 953 "IS-IS Extensions for Segment Routing", draft-ietf-isis- 954 segment-routing-extensions-13 (work in progress), June 955 2017. 957 [I-D.ietf-ospf-ospfv3-segment-routing-extensions] 958 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 959 Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3 960 Extensions for Segment Routing", draft-ietf-ospf-ospfv3- 961 segment-routing-extensions-10 (work in progress), 962 September 2017. 964 [I-D.ietf-ospf-segment-routing-extensions] 965 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 966 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 967 Extensions for Segment Routing", draft-ietf-ospf-segment- 968 routing-extensions-19 (work in progress), August 2017. 970 [I-D.ietf-spring-segment-routing] 971 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 972 and R. Shakir, "Segment Routing Architecture", draft-ietf- 973 spring-segment-routing-12 (work in progress), June 2017. 975 [I-D.ietf-spring-segment-routing-ldp-interop] 976 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., and 977 S. Litkowski, "Segment Routing interworking with LDP", 978 draft-ietf-spring-segment-routing-ldp-interop-09 (work in 979 progress), September 2017. 981 [I-D.ietf-spring-segment-routing-mpls] 982 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 983 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 984 data plane", draft-ietf-spring-segment-routing-mpls-10 985 (work in progress), June 2017. 987 [IANA-MPLS-LSP-PING] 988 IANA, "Multi-Protocol Label Switching (MPLS) Label 989 Switched Paths (LSPs) Ping Parameters", 990 . 993 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 994 RFC 792, DOI 10.17487/RFC0792, September 1981, 995 . 997 Authors' Addresses 999 Nagendra Kumar (editor) 1000 Cisco Systems, Inc. 1001 7200-12 Kit Creek Road 1002 Research Triangle Park, NC 27709-4987 1003 US 1005 Email: naikumar@cisco.com 1007 Carlos Pignataro (editor) 1008 Cisco Systems, Inc. 1009 7200-11 Kit Creek Road 1010 Research Triangle Park, NC 27709-4987 1011 US 1013 Email: cpignata@cisco.com 1015 George Swallow 1016 Southend Technical Center 1018 Email: swallow.ietf@gmail.com 1019 Nobo Akiya 1020 Big Switch Networks 1022 Email: nobo.akiya.dev@gmail.com 1024 Sriganesh Kini 1025 Individual 1027 Email: sriganeshkini@gmail.com 1029 Mach(Guoyi) Chen 1030 Huawei 1032 Email: mach.chen@huawei.com