idnits 2.17.1 draft-ietf-mpls-spring-lsp-ping-05.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 (August 17, 2017) is 2443 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 (-15) exists of draft-ietf-spring-segment-routing-12 == Outdated reference: A later version (-25) exists of draft-ietf-isis-segment-routing-extensions-13 == Outdated reference: A later version (-27) exists of draft-ietf-ospf-segment-routing-extensions-18 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-ldp-interop-08 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-mpls-10 Summary: 0 errors (**), 0 flaws (~~), 6 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: February 18, 2018 G. Swallow 6 Individual 7 N. Akiya 8 Big Switch Networks 9 S. Kini 10 Individual 11 H. Gredler 12 RtBrick Inc 13 M. Chen 14 Huawei 15 August 17, 2017 17 Label Switched Path (LSP) Ping/Traceroute for Segment Routing Networks 18 with MPLS Data-plane 19 draft-ietf-mpls-spring-lsp-ping-05 21 Abstract 23 Segment Routing architecture leverages the source routing and 24 tunneling paradigms and can be directly applied to MPLS data plane. 25 A node steers a packet through a controlled set of instructions 26 called segments, by prepending the packet with a Segment Routing 27 header. 29 The segment assignment and forwarding semantic nature of Segment 30 Routing raises additional consideration for connectivity verification 31 and fault isolation in LSP with Segment Routing architecture. This 32 document illustrates the problem and describe a mechanism to perform 33 LSP Ping and Traceroute on Segment Routing network over MPLS data 34 plane. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at http://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on February 18, 2018. 53 Copyright Notice 55 Copyright (c) 2017 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 71 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 72 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 4. Challenges with Existing mechanism . . . . . . . . . . . . . 4 74 4.1. Path validation in Segment Routing networks . . . . . . . 4 75 4.2. Service Label . . . . . . . . . . . . . . . . . . . . . . 5 76 5. Segment ID sub-TLV . . . . . . . . . . . . . . . . . . . . . 6 77 5.1. IPv4 IGP-Prefix Segment ID . . . . . . . . . . . . . . . 6 78 5.2. IPv6 IGP-Prefix Segment ID . . . . . . . . . . . . . . . 7 79 5.3. IGP-Adjacency Segment ID . . . . . . . . . . . . . . . . 8 80 6. Extension to Downstream Detailed Mapping TLV . . . . . . . . 9 81 7. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 10 82 7.1. FECs in Target FEC Stack TLV . . . . . . . . . . . . . . 10 83 7.2. FEC Stack Change sub-TLV . . . . . . . . . . . . . . . . 10 84 7.3. Segment ID POP Operation . . . . . . . . . . . . . . . . 11 85 7.4. Segment ID Check . . . . . . . . . . . . . . . . . . . . 11 86 7.5. TTL Consideration for traceroute . . . . . . . . . . . . 14 87 8. Issues with non-forwarding labels . . . . . . . . . . . . . . 15 88 9. Backward Compatibility with non Segment Routing devices . . . 15 89 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 90 10.1. New Target FEC Stack Sub-TLVs . . . . . . . . . . . . . 15 91 10.2. Protocol in Label Stack Sub-TLV of Downstream Detailed 92 Mapping TLV . . . . . . . . . . . . . . . . . . . . . . 16 93 10.3. Return Code . . . . . . . . . . . . . . . . . . . . . . 16 94 11. Security Considerations . . . . . . . . . . . . . . . . . . . 17 95 12. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 17 96 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17 97 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 98 14.1. Normative References . . . . . . . . . . . . . . . . . . 17 99 14.2. Informative References . . . . . . . . . . . . . . . . . 18 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 102 1. Introduction 104 [I-D.ietf-spring-segment-routing] introduces and explains Segment 105 Routing architecture that leverages the source routing and tunneling 106 paradigms. A node steers a packet through a controlled set of 107 instructions called segments, by prepending the packet with Segment 108 Routing header. A detailed definition about Segment Routing 109 architecture is available in [I-D.ietf-spring-segment-routing] 111 As defined in [I-D.ietf-spring-segment-routing] and 112 [I-D.ietf-spring-segment-routing-mpls], the Segment Routing 113 architecture can be directly applied to MPLS data plane in a way 114 that, the Segment identifier (Segment ID) will be of 20-bits size and 115 Segment Routing header is the label stack. 117 "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures" 118 [RFC8029] defines a simple and efficient mechanism to detect data 119 plane failures in Label Switched Paths (LSP) by specifying 120 information to be carried in an MPLS "echo request" and "echo reply" 121 for the purposes of fault detection and isolation. Mechanisms for 122 reliably sending the echo reply are defined. The functionality 123 defined in [RFC8029] is modeled after the ping/traceroute paradigm 124 (ICMP echo request [RFC0792]) and is typically referred to as LSP 125 ping and LSP traceroute. [RFC8029] supports hierarchal and stitching 126 LSPs. 128 Unlike LDP or RSVP which are the other well-known MPLS control plane 129 protocols, the basis of segment ID assignment in Segment Routing 130 architecture is not hop-by-hop always. Depending on the type of 131 segment ID, the assignment can be unique to the node or within the 132 domain. 134 This nature of Segment Routing raises additional consideration for 135 fault detection and isolation in Segment Routing network. This 136 document illustrates the problem and describe a mechanism to perform 137 LSP Ping and Traceroute on Segment Routing network over MPLS data 138 plane. 140 2. Requirements notation 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 144 document are to be interpreted as described in [RFC2119]. 146 3. Terminology 148 This document uses the terminologies defined in 149 [I-D.ietf-spring-segment-routing], [RFC8029], and so the readers are 150 expected to be familiar with the same. 152 4. Challenges with Existing mechanism 154 This document defines sub-TLVs for the Target Forwarding Equivalence 155 Class (FEC) Stack TLV and explains how they can be used to tackle 156 below challenges. 158 4.1. Path validation in Segment Routing networks 160 [RFC8029] defines the OAM machinery that helps with fault detection 161 and isolation in MPLS data-plane path with the use of various Target 162 FEC Stack Sub-TLV that are carried in MPLS Echo Request packets and 163 used by the responder for FEC validation. While it is obvious that 164 new Sub-TLVs need to be assigned, the unique nature of Segment 165 Routing architecture raises a need for additional machinery for path 166 validation. This section discusses the challenges as below: 168 L1 169 +--------+ 170 | L2 | 171 R3-------R6 172 / \ 173 / \ 174 R1----R2 R7----R8 175 \ / 176 \ / 177 R4-------R5 179 Figure 1: Segment Routing network 181 The Node Segment IDs for R1, R2, R3, R4, R5, R6, R7 and R8 are 5001, 182 5002, 5003, 5004, 5005, 5006, 5007, 5008 respectively. 184 9136 --> Adjacency Segment ID from R3 to R6 over link L1. 185 9236 --> Adjacency Segment ID from R3 to R6 over link L2. 186 9124 --> Adjacency segment ID from R2 to R4. 187 9123 --> Adjacency Segment ID from R2 to R3. 189 The forwarding semantic of Adjacency Segment ID is to pop the segment 190 ID and send the packet to a specific neighbor over a specific link. 191 A malfunctioning node may forward packets using Adjacency Segment ID 192 to incorrect neighbor or over incorrect link. Exposed segment ID 193 (after incorrectly forwarded Adjacency Segment ID) might still allow 194 such packet to reach the intended destination, although the intended 195 strict traversal has been broken. 197 Assume in above topology, R1 sends traffic with segment stack as 198 {9124, 5008} so that the path taken will be R1-R2-R4-R5-R7-R8. If 199 the Adjacency Segment ID 9124 is misprogrammed in R2 to send the 200 packet to R1 or R3, it will still be delivered to R8 but is not via 201 the expected path. 203 MPLS traceroute may help with detecting such deviation in above 204 mentioned scenario. However, in a different example, it may not be 205 helpful. For example if R3, due to misprogramming, forwards packet 206 with Adjacency Segment ID 9236 via link L1 while it is expected to be 207 forwarded over Link L2. 209 4.2. Service Label 211 A Segment ID can represent a service based instruction. A Segment 212 Routing header can have label stack entries where the label 213 represents a service to be applied along the path. Since these 214 labels are part of the label stack, they can influence the path taken 215 by a packet and consequently have implications on MPLS OAM. Service 216 Label is left for future study. 218 5. Segment ID sub-TLV 220 The format of the following Segment ID sub-TLVs follows the 221 philosophy of Target FEC Stack TLV carrying FECs corresponding to 222 each label in the label stack. When operated with the procedures 223 defined in [RFC8029], this allows LSP ping/traceroute operations to 224 function when Target FEC Stack TLV contains more FECs than received 225 label stack at responder nodes. 227 Three new sub-TLVs are defined for Target FEC Stack TLVs (Type 1), 228 Reverse-Path Target FEC Stack TLV (Type 16) and Reply Path TLV (Type 229 21). 231 sub-Type Value Field 232 -------- --------------- 233 34 IPv4 IGP-Prefix Segment ID 234 35 IPv6 IGP-Prefix Segment ID 235 36 IGP-Adjacency Segment ID 237 Service Segments and FRR will be considered in future version. 239 5.1. IPv4 IGP-Prefix Segment ID 241 The format is as below: 243 0 1 2 3 244 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 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | IPv4 Prefix | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 |Prefix Length | Protocol | Reserved | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 IPv4 Prefix 253 This field carries the IPv4 prefix to which the Segment ID is 254 assigned. In case of Anycast Segment ID, this field will carry 255 IPv4 Anycast address. If the prefix is shorter than 32 bits, 256 trailing bits SHOULD be set to zero. 258 Prefix Length 259 The Prefix Length field is one octet, it gives the length of the 260 prefix in bits (values can be 1 - 32). 262 Protocol 264 Set to 1, if the Responder MUST perform FEC validation using OSPF 265 as IGP protocol. Set to 2, if the Responder MUST perform Egress 266 FEC validation using ISIS as IGP protocol. Set to 0, if Responder 267 can use any IGP protocol for Egress FEC validation. 269 5.2. IPv6 IGP-Prefix Segment ID 271 The format is as below: 273 0 1 2 3 274 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 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | | 277 | IPv6 Prefix | 278 | | 279 | | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 |Prefix Length | Protocol | Reserved | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 IPv6 Prefix 286 This field carries the IPv6 prefix to which the Segment ID is 287 assigned. In case of Anycast Segment ID, this field will carry 288 IPv4 Anycast address. If the prefix is shorter than 128 bits, 289 trailing bits SHOULD be set to zero. 291 Prefix Length 293 The Prefix Length field is one octet, it gives the length of the 294 prefix in bits (values can be 1 - 128). 296 Protocol 298 Set to 1, if the Responder MUST perform FEC validation using OSPF 299 as IGP protocol. Set to 2, if the Responder MUST perform Egress 300 FEC validation using ISIS as IGP protocol. Set to 0, if Responder 301 can use any IGP protocol for Egress FEC validation. 303 5.3. IGP-Adjacency Segment ID 305 The format is as below: 307 0 1 2 3 308 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 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | Adj. Type | Protocol | Reserved | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | Local Interface ID (4 or 16 octets) | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | Remote Interface ID (4 or 16 octets) | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 ~ ~ 317 | Advertising Node Identifier (4 or 6 octets) | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 ~ ~ 320 | Receiving Node Identifier (4 or 6 octets) | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 Adj. Type (Adjacency Type) 325 Set to 1, when the Adjacency Segment is Parallel Adjacency as 326 defined in Section 3.5.1 of [I-D.ietf-spring-segment-routing]. 327 Set to 4, when the Adjacency segment is IPv4 based and is not a 328 parallel adjacency. Set to 6, when the Adjacency segment is IPv6 329 based and is not a parallel adjacency. Set to 0, when the 330 Adjacency segment is over unnumbered interface. 332 Protocol 334 Set to 1, if the Responder MUST perform FEC validation using OSPF 335 as IGP protocol. Set to 2, if the Responder MUST perform Egress 336 FEC validation using ISIS as IGP protocol. Set to 0, if Responder 337 can use any IGP protocol for Egress FEC validation. 339 Local Interface ID 341 An identifier that is assigned by local LSR for a link on which 342 Adjacency Segment ID is bound. This field is set to local link 343 address (IPv4 or IPv6). Incase of unnumbered, 32 bit link 344 identifier defined in [RFC4203], [RFC5307] is used. If the 345 Adjacency Segment ID represents parallel adjacencies 346 (Section 3.5.1 of [I-D.ietf-spring-segment-routing]) this field 347 MUST be set to 4 bytes of zero. 349 Remote Interface ID 351 An identifier that is assigned by remote LSR for a link on which 352 Adjacency Segment ID is bound. This field is set to remote 353 (downstream neighbor) link address (IPv4 or IPv6). In case of 354 unnumbered, 32 bit link identifier defined in [RFC4203], [RFC5307] 355 is used. If the Adjacency Segment ID represents parallel 356 adjacencies (Section 3.5.1 of [I-D.ietf-spring-segment-routing]) 357 this field MUST be set to 4 bytes of zero. 359 Advertising Node Identifier 361 Specifies the advertising node identifier. When Protocol is set 362 to 1, then the 32 rightmost bits represent OSPF Router ID and if 363 protocol is set to 2, this field carries 48 bit ISIS System ID. 365 Receiving Node Identifier 367 Specifies the downstream node identifier. When Protocol is set to 368 1, then the 32 rightmost bits represent OSPF Router ID and if 369 protocol is set to 2, this field carries 48 bit ISIS System ID. 371 6. Extension to Downstream Detailed Mapping TLV 373 In an echo reply, the Downstream Mapping TLV [RFC8029] is used to 374 report for each interface over which a FEC could be forwarded. For a 375 FEC, there are multiple protocols that may be used to distribute 376 label mapping. The "Protocol" field of the Downstream Detailed 377 Mapping TLV is used to return the protocol that is used to distribute 378 a specific a label. The following protocols are defined in 379 Section 3.4.1.2 of [RFC8029]: 381 Protocol # Signaling Protocol 382 ---------- ------------------ 383 0 Unknown 384 1 Static 385 2 BGP 386 3 LDP 387 4 RSVP-TE 389 With segment routing, OSPF or ISIS can be used for label 390 distribution, this document adds two new protocols as follows: 392 Protocol # Signaling Protocol 393 ---------- ------------------ 394 5 OSPF 395 6 ISIS 397 7. Procedures 399 This section describes aspects of LSP Ping and traceroute operations 400 that require further considerations beyond [RFC8029]. 402 7.1. FECs in Target FEC Stack TLV 404 When LSP echo request packets are generated by an initiator, FECs 405 carried in Target FEC Stack TLV may need to have deviating contents. 406 This document outlines expected Target FEC Stack TLV construction 407 mechanics by initiator for known scenarios. 409 Ping 411 Initiator MUST include FEC(s) corresponding to the destination 412 segment. 414 Initiator MAY include FECs corresponding to some or all of 415 segments imposed in the label stack by the initiator to 416 communicate the segments traversed. 418 Traceroute 420 Initiator MUST initially include FECs corresponding to all of 421 segments imposed in the label stack. 423 When a received echo reply contains FEC Stack Change TLV with 424 one or more of original segment(s) being popped, initiator MAY 425 remove corresponding FEC(s) from Target FEC Stack TLV in the 426 next (TTL+1) traceroute request as defined in Section 4.6 of 427 [RFC8029]. 429 When a received echo reply does not contain FEC Stack Change 430 TLV, initiator MUST NOT attempt to remove FEC(s) from Target 431 FEC Stack TLV in the next (TTL+1) traceroute request. 433 7.2. FEC Stack Change sub-TLV 435 Section 3.4.1.3 of [RFC8029] defines FEC Stack Change sub-TLV that a 436 router must include when the FEC stack changes. 438 The network node which advertised the Node Segment ID is responsible 439 for generating FEC Stack Change sub-TLV of pop operation for Node 440 Segment ID, regardless of if PHP is enabled or not. 442 The network node that is immediate downstream of the node which 443 advertised the Adjacency Segment ID is responsible for generating FEC 444 Stack Change sub-TLV of &pop& operation for Adjacency Segment ID. 446 7.3. Segment ID POP Operation 448 The forwarding semantic of Node Segment ID with PHP flag is 449 equivalent to usage of implicit Null in MPLS protocols. Adjacency 450 Segment ID is also similar in a sense that it can be thought as next 451 hop destined locally allocated segment that has PHP enabled. 452 Procedures described in Section 4.4 of [RFC8029] relies on Stack-D 453 and Stack-R explicitly having Implicit Null value. It may simplify 454 implementations to reuse Implicit Null for Node Segment ID PHP and 455 Adjacency Segment ID cases. 457 7.4. Segment ID Check 459 This section updates the procedure defined in Step 6 of Section 4.4. 460 of [RFC8029] 462 If the Label-stack-depth is 0 and Target FEC Stack Sub-TLV at FEC- 463 stack-depth is 34 (IPv4 IGP-Prefix Segment ID), the responder 464 should set Best return code to 10, "Mapping for this FEC is not 465 the given label at stack-depth " if any below conditions 466 fail: 468 /* The responder LSR is to check if it is the egress of the IPv4 469 IGP-Prefix Segment ID described in the Target FEC Stack Sub-TLV, 470 and if the FEC was advertised with the PHP bit set.*/ 472 * Validate that Node Segment ID is advertised for IPv4 Prefix by 473 IGP Protocol{ 475 + When protocol field in received IPv4 IGP-Prefix Segment ID 476 Sub-TLV is 0, Use any locally enabled IGP protocol. 478 + When protocol field in received IPv4 IGP-Prefix Segment ID 479 Sub-TLV is 1, Use OSPF as IGP protocol. 481 + When protocol field in received IPv4 IGP-Prefix Segment ID 482 Sub-TLV is 2, Use ISIS as IGP protocol. 484 } 486 * Validate that Node Segment ID is advertised with No-PHP flag { 488 + When Protocol is OSPF, NP-flag defined in Section 5 of 489 [I-D.ietf-ospf-segment-routing-extensions] should be set to 490 0. 492 + When Protocol is ISIS, P-Flag defined in Section 2.1 of 493 [I-D.ietf-isis-segment-routing-extensions] should be set to 494 0. 496 } 498 If the Label-stack-depth is more than 0 and Target FEC Stack Sub- 499 TLV at FEC-stack-depth is 34 (IPv4 IGP-Prefix Segment ID), the 500 responder is to set Best return code to 10 if any below conditions 501 fail: 503 * Validate that Node Segment ID is advertised for IPv4 Prefix by 504 IGP Protocol{ 506 + When protocol field in received IPv4 IGP-Prefix Segment ID 507 Sub-TLV is 0, Use any locally enabled IGP protocol. 509 + When protocol field in received IPv4 IGP-Prefix Segment ID 510 Sub-TLV is 1, Use OSPF as IGP protocol. 512 + When protocol field in received IPv4 IGP-Prefix Segment ID 513 Sub-TLV is 2, Use ISIS as IGP protocol. 515 } 517 If the Label-stack-depth is 0 and Target FEC Sub-TLV at FEC-stack- 518 depth is 35 (IPv6 IGP-Prefix Segment ID), set Best return code to 519 10 if any below conditions fail: 521 /* The LSR needs to check if its being a tail-end for the LSP and 522 have the prefix advertised with PHP bit set*/ 524 * Validate that Node Segment ID is advertised for IPv6 Prefix by 525 IGP Protocol{ 527 + When protocol field in received IPv6 IGP-Prefix Segment ID 528 Sub-TLV is 0, Use any locally enabled IGP protocol. 530 + When protocol field in received IPv6 IGP-Prefix Segment ID 531 Sub-TLV is 1, Use OSPF as IGP protocol. 533 + When protocol field in received IPv6 IGP-Prefix Segment ID 534 Sub-TLV is 2, Use ISIS as IGP protocol. 536 } 538 * Validate that Node Segment ID is advertised of PHP bit. 540 If the Label-stack-depth is more than 0 and Target FEC Sub-TLV at 541 FEC-stack-depth is 35 (IPv6 IGP-Prefix Segment ID), set Best 542 return code to 10 if any below conditions fail: 544 * Validate that Node Segment ID is advertised for IPv4 Prefix by 545 IGP Protocol{ 547 + When protocol field in received IPv4 IGP-Prefix Segment ID 548 Sub-TLV is 0, Use any locally enabled IGP protocol. 550 + When protocol field in received IPv4 IGP-Prefix Segment ID 551 Sub-TLV is 1, Use OSPF as IGP protocol. 553 + When protocol field in received IPv4 IGP-Prefix Segment ID 554 Sub-TLV is 2, Use ISIS as IGP protocol. 556 } 558 If the Label-stack-depth is 0 and Target FEC sub-TLV at FEC-stack- 559 depth is 36 (Adjacency Segment ID), set Best return code to TBD7 560 (Section 10.3) if any below conditions fail: 562 When the Adj. Type is 1 (Parallel Adjacency): 564 + Validate that Receiving Node Identifier is local IGP 565 identifier. 567 + Validate that Adjacency Segment ID is advertised by 568 Advertising Node Identifier of Protocol in local IGP 569 database { 571 - When protocol field in received IPv4 IGP-Prefix Segment 572 ID Sub-TLV is 0, Use any locally enabled IGP protocol. 574 - When protocol field in received IPv4 IGP-Prefix Segment 575 ID Sub-TLV is 1, Use OSPF as IGP protocol. 577 - When protocol field in received IPv4 IGP-Prefix Segment 578 ID Sub-TLV is 2, Use ISIS as IGP protocol. 580 } 582 When the Adj. Type is 4 or 6: 584 + Validate that Remote Interface ID matches the local 585 identifier of the interface (Interface-I) on which the 586 packet was received. 588 + Validate that Receiving Node Identifier is local IGP 589 identifier. 591 + Validate that IGP-Adjacency Segment ID is advertised by 592 Advertising Node Identifier of Protocol in local IGP 593 database { 595 - When protocol field in received IPv4 IGP-Prefix Segment 596 ID Sub-TLV is 0, Use any locally enabled IGP protocol. 598 - When protocol field in received IPv4 IGP-Prefix Segment 599 ID Sub-TLV is 1, Use OSPF as IGP protocol. 601 - When protocol field in received IPv4 IGP-Prefix Segment 602 ID Sub-TLV is 2, Use ISIS as IGP protocol. 604 } 606 7.5. TTL Consideration for traceroute 608 LSP Traceroute operation can properly traverse every hop of Segment 609 Routing network in Uniform Model described in [RFC3443]. If one or 610 more LSRs employ Short Pipe Model described in [RFC3443], then LSP 611 Traceroute may not be able to properly traverse every hop of Segment 612 Routing network due to absence of TTL copy operation when outer label 613 is popped. Short Pipe being the most commonly used model. The 614 following TTL manipulation technique MAY be used when Short Pipe 615 model is used. 617 When tracing a LSP according to the procedures in [RFC8029] the TTL 618 is incremented by one in order to trace the path sequentially along 619 the LSP. However when a source routed LSP has to be traced there are 620 as many TTLs as there are labels in the stack. The LSR that 621 initiates the traceroute SHOULD start by setting the TTL to 1 for the 622 tunnel in the LSP's label stack it wants to start the tracing from, 623 the TTL of all outer labels in the stack to the max value, and the 624 TTL of all the inner labels in the stack to zero. Thus a typical 625 start to the traceroute would have a TTL of 1 for the outermost label 626 and all the inner labels would have TTL 0. If the FEC Stack TLV is 627 included it should contain only those for the inner stacked tunnels. 628 The Return Code/Subcode and FEC Stack Change TLV should be used to 629 diagnose the tunnel as described in [RFC8029]. When the tracing of a 630 tunnel in the stack is complete, then the next tunnel in the stack 631 should be traced. The end of a tunnel can be detected from the 632 "Return Code" when it indicates that the responding LSR is an egress 633 for the stack at depth 1. Thus the traceroute procedures in 634 [RFC8029] can be recursively applied to traceroute a source routed 635 LSP. 637 8. Issues with non-forwarding labels 639 Source stacking can be optionally used to apply services on the 640 packet at a LSR along the path, where a label in the stack is used to 641 trigger service application. A data plane failure detection and 642 isolation mechanism should provide its functionality without applying 643 these services. This is mandatory for services that are stateful, 644 though for stateless services [RFC8029] could be used as-is. It MAY 645 also provide a mechanism to detect and isolate faults within the 646 service function itself. 648 How a node treats Service label is outside the scope of this document 649 and will be included in this or a different document later. 651 9. Backward Compatibility with non Segment Routing devices 653 [I-D.ietf-spring-segment-routing-ldp-interop] describes how Segment 654 Routing operates in network where SR-capable and non-SR-capable nodes 655 coexist. In such networks, there may not be any FEC mapping in the 656 responder when the Initiator is SR-capable while the responder is not 657 (or vice-versa). But this is not different from RSVP and LDP interop 658 scenarios. When LSP Ping is triggered, the responder will set the 659 FEC-return-code to Return 4, "Replying router has no mapping for the 660 FEC at stack-depth". 662 Similarly when SR-capable node assigns Adj-SID for non-SR-capable 663 node, LSP traceroute may fail as the non-SR-capable node is not aware 664 of "IGP Adjacency Segment ID" sub-TLV and may not reply with FEC 665 Stack change. This may result in any further downstream nodes to 666 reply back with Return-code as 4, "Replying router has no mapping for 667 the FEC at stack-depth". 669 10. IANA Considerations 671 10.1. New Target FEC Stack Sub-TLVs 673 IANA is requested to assign three new Sub-TLVs from "Sub-TLVs for TLV 674 Types 1, 16 and 21" sub-registry from the "Multi-Protocol Label 675 Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" 676 [IANA-MPLS-LSP-PING] registry. 678 Sub-Type Sub-TLV Name Reference 679 -------- ----------------- ------------ 680 34 IPv4 IGP-Prefix Segment ID Section 5.1 of this document 681 35 IPv6 IGP-Prefix Segment ID Section 5.2 of this document 682 36 IGP-Adjacency Segment ID Section 5.3 of this document 684 10.2. Protocol in Label Stack Sub-TLV of Downstream Detailed Mapping 685 TLV 687 IANA is requested to create a new "Protocol" registry under the 688 "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) 689 Ping Parameters" registry. Code points in the range of 0-250 will be 690 assigned by Standards Action. The range of 251-254 are reserved for 691 experimental use and will not be assigned. The initial entries into 692 the registry will be. 694 Value Meaning Reference 695 ---------- ---------------- ------------ 696 0 Unknown Section 3.4.1.2 of RFC8029 697 1 Static Section 3.4.1.2 of RFC8029 698 2 BGP Section 3.4.1.2 of RFC8029 699 3 LDP Section 3.4.1.2 of RFC8029 700 4 RSVP-TE Section 3.4.1.2 of RFC8029 701 5 OSPF Section 6 of this document 702 6 ISIS Section 6 of this document 703 7-250 Unassigned 704 251-254 Experimental use This document 705 255 Reserved This document 707 10.3. Return Code 709 IANA is requested to assign a new Return Code from the "Multi- 710 Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping 711 Parameters" in "Return Codes" Sub-registry. 713 Value Meaning Reference 714 ---------- ----------------- ------------ 715 TBD7 Mapping for this FEC is not associated Section 7.4 of 716 with the incoming interface this document 718 Note to the RFC Editor (please remove before publication): IANA has 719 made early allocation for sub-type 34, 35 and 35. The early 720 allocation expires 2017-09-15. 722 11. Security Considerations 724 This document defines additional Sub-TLVs and follows the mechanism 725 defined in [RFC8029]. So all the security consideration defined in 726 [RFC8029] will be applicable for this document and in addition it 727 does not impose any security challenges to be considered. 729 12. Acknowledgement 731 The authors would like to thank Stefano Previdi, Les Ginsberg, Balaji 732 Rajagopalan, Harish Sitaraman, Curtis Villamizar, Pranjal Dutta, 733 Lizhong Jin, Tom Petch, Victor Ji and Mustapha Aissaoui for their 734 review and comments. 736 The authors wold like to thank Loa Andersson for his comments and 737 recommendation to merge drafts. 739 13. Contributors 741 The following are key contributors to this document: 743 Tarek Saad, Cisco Systems, Inc. 745 Siva Sivabalan, Cisco Systems, Inc. 747 Balaji Rajagopalan, Juniper Networks 749 Faisal Iqbal, Cisco Systems, Inc. 751 14. References 753 14.1. Normative References 755 [I-D.ietf-spring-segment-routing] 756 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 757 and R. Shakir, "Segment Routing Architecture", draft-ietf- 758 spring-segment-routing-12 (work in progress), June 2017. 760 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 761 Requirement Levels", BCP 14, RFC 2119, 762 DOI 10.17487/RFC2119, March 1997, 763 . 765 [RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing 766 in Multi-Protocol Label Switching (MPLS) Networks", 767 RFC 3443, DOI 10.17487/RFC3443, January 2003, 768 . 770 [RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in 771 Support of Generalized Multi-Protocol Label Switching 772 (GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005, 773 . 775 [RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions 776 in Support of Generalized Multi-Protocol Label Switching 777 (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008, 778 . 780 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 781 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 782 Switched (MPLS) Data-Plane Failures", RFC 8029, 783 DOI 10.17487/RFC8029, March 2017, 784 . 786 14.2. Informative References 788 [I-D.ietf-isis-segment-routing-extensions] 789 Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., 790 Litkowski, S., Decraene, B., and j. jefftant@gmail.com, 791 "IS-IS Extensions for Segment Routing", draft-ietf-isis- 792 segment-routing-extensions-13 (work in progress), June 793 2017. 795 [I-D.ietf-ospf-segment-routing-extensions] 796 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 797 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 798 Extensions for Segment Routing", draft-ietf-ospf-segment- 799 routing-extensions-18 (work in progress), July 2017. 801 [I-D.ietf-spring-segment-routing-ldp-interop] 802 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., and 803 S. Litkowski, "Segment Routing interworking with LDP", 804 draft-ietf-spring-segment-routing-ldp-interop-08 (work in 805 progress), June 2017. 807 [I-D.ietf-spring-segment-routing-mpls] 808 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 809 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 810 data plane", draft-ietf-spring-segment-routing-mpls-10 811 (work in progress), June 2017. 813 [IANA-MPLS-LSP-PING] 814 IANA, "Multi-Protocol Label Switching (MPLS) Label 815 Switched Paths (LSPs) Ping Parameters", 816 . 819 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 820 RFC 792, DOI 10.17487/RFC0792, September 1981, 821 . 823 Authors' Addresses 825 Nagendra Kumar (editor) 826 Cisco Systems, Inc. 827 7200-12 Kit Creek Road 828 Research Triangle Park, NC 27709-4987 829 US 831 Email: naikumar@cisco.com 833 Carlos Pignataro (editor) 834 Cisco Systems, Inc. 835 7200-11 Kit Creek Road 836 Research Triangle Park, NC 27709-4987 837 US 839 Email: cpignata@cisco.com 841 George Swallow 842 Individual 844 Email: swallow.ietf@gmail.com 846 Nobo Akiya 847 Big Switch Networks 849 Email: nobo.akiya.dev@gmail.com 851 Sriganesh Kini 852 Individual 854 Email: sriganeshkini@gmail.com 856 Hannes Gredler 857 RtBrick Inc 859 Email: hannes@rtbrick.com 860 Mach(Guoyi) Chen 861 Huawei 863 Email: mach.chen@huawei.com