idnits 2.17.1 draft-kumarkini-mpls-spring-lsp-ping-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 45 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 04, 2014) is 3583 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.gredler-spring-mpls' is defined on line 606, but no explicit reference was found in the text == Unused Reference: 'RFC6291' is defined on line 632, but no explicit reference was found in the text == Unused Reference: 'RFC6425' is defined on line 636, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-filsfils-spring-segment-routing-03 == Outdated reference: A later version (-01) exists of draft-filsfils-spring-segment-routing-use-cases-00 -- Possible downref: Normative reference to a draft: ref. 'I-D.gredler-spring-mpls' ** Obsolete normative reference: RFC 4379 (Obsoleted by RFC 8029) ** Obsolete normative reference: RFC 6424 (Obsoleted by RFC 8029) Summary: 3 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 3 Internet-Draft G. Swallow 4 Intended status: Standards Track C. Pignataro 5 Expires: January 5, 2015 N. Akiya 6 Cisco Systems, Inc. 7 S. Kini 8 Ericsson 9 H. Gredler 10 Juniper Networks 11 M. Chen 12 Huawei 13 July 04, 2014 15 Label Switched Path (LSP) Ping/Trace for Segment Routing Networks Using 16 MPLS Dataplane 17 draft-kumarkini-mpls-spring-lsp-ping-01 19 Abstract 21 Segment Routing architecture leverages the source routing and 22 tunneling paradigms and can be directly applied to MPLS data plane. 23 A node steers a packet through a controlled set of instructions 24 called segments, by prepending the packet with Segment Routing 25 header. 27 The segment assignment and forwarding semantic nature of Segment 28 Routing raises additional consideration for connectivity verification 29 and fault isolation in LSP with Segment Routing architecture. This 30 document illustrates the problem and describe a mechanism to perform 31 LSP Ping and Traceroute on Segment Routing network over MPLS data 32 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 http://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 January 5, 2015. 50 Copyright Notice 52 Copyright (c) 2014 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 (http://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 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 69 3. Challenges with Existing mechanism . . . . . . . . . . . . . 3 70 3.1. Path validation in Segment Routing networks . . . . . . . 4 71 3.2. Service Label . . . . . . . . . . . . . . . . . . . . . . 5 72 4. Segment ID sub-TLV . . . . . . . . . . . . . . . . . . . . . 5 73 4.1. IPv4 Prefix Node Segment ID . . . . . . . . . . . . . . . 5 74 4.2. IPv6 Prefix Node Segment ID . . . . . . . . . . . . . . . 7 75 4.3. IGP Adjacency Segment ID . . . . . . . . . . . . . . . . 8 76 5. Extension to Downstream Mapping TLV . . . . . . . . . . . . . 9 77 6. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 9 78 6.1. FECs in Target FEC Stack TLV . . . . . . . . . . . . . . 10 79 6.2. FEC Stack Change sub-TLV . . . . . . . . . . . . . . . . 10 80 6.3. Segment ID POP Operation . . . . . . . . . . . . . . . . 11 81 6.4. Segment ID Check . . . . . . . . . . . . . . . . . . . . 11 82 6.5. TTL Consideration for traceroute . . . . . . . . . . . . 12 83 7. Issues with non-forwarding labels . . . . . . . . . . . . . . 12 84 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 85 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 86 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 13 87 11. Contributing Authors . . . . . . . . . . . . . . . . . . . . 13 88 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 89 12.1. Normative References . . . . . . . . . . . . . . . . . . 14 90 12.2. Informative References . . . . . . . . . . . . . . . . . 14 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 93 1. Introduction 95 [I-D.filsfils-spring-segment-routing] introduces and explains Segment 96 Routing architecture that leverages the source routing and tunneling 97 paradigms. A node steers a packet through a controlled set of 98 instructions called segments, by prepending the packet with Segment 99 Routing header. A detailed definition about Segment Routing 100 architecture is available in [I-D.filsfils-spring-segment-routing] 101 and different use-cases are discussed in 102 [I-D.filsfils-spring-segment-routing-use-cases] 104 The Segment Routing architecture can be directly applied to MPLS data 105 plane in a way that, the Segment identifier (Segment ID) will be of 106 20-bits size and SR header is the label stack. 108 Multi Protocol Label Switching (MPLS) has defined in [RFC4379] a 109 simple and efficient mechanism to detect data plane failures in Label 110 Switched Paths (LSP) by specifying information to be carried in an 111 MPLS "echo request" and "echo reply" for the purposes of fault 112 detection and isolation, and mechanisms for reliably sending the echo 113 reply. The functionality is modeled after the ping/traceroute 114 paradigm (ICMP echo request [RFC0792]) and is typically referred to 115 as LSP ping and LSP traceroute. 117 Unlike LDP or RSVP which are the other well-known MPLS control plane 118 protocols, segment assignment in Segment Routing architecture is not 119 hop-by-hop basis. 121 This nature of Segment Routing raises additional consideration for 122 fault detection and isolation in Segment Routing network. This 123 document illustrates the problem and describe a mechanism to perform 124 LSP Ping and Traceroute on Segment Routing network over MPLS data 125 plane. 127 2. Requirements notation 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in [RFC2119]. 133 3. Challenges with Existing mechanism 135 This document defines Target FEC Stack sub-TLVs and explains how they 136 can be used to tackle below challenges. 138 3.1. Path validation in Segment Routing networks 140 [RFC4379] defines the OAM machinery that helps with fault detection 141 and isolation in MPLS dataplane path with the use of various Target 142 FEC Stack Sub-TLV that are carried in MPLS Echo Request packets and 143 used by the responder for FEC validation. While it is obvious that 144 new Sub-TLVs need to be assigned, the unique nature of Segment 145 Routing architecture raises a need for additional machinery for path 146 validation. This section discuss the challenges as below: 148 L1 149 +--------+ 150 | L2 | 151 R3-------R6 152 / \ 153 / \ 154 R1----R2 R7----R8 155 \ / L3 156 \ / 157 R4-------R5 159 Figure 1: Segment Routing network 161 {5001, 5002, 5003, 5004, 5005, 5006, 5007, 5008} --> Node Segment ID for R1, R2, R3 R4, R5 R6, R7, R8 respectively. 163 9136 --> Adjacency Segment ID from R3 to R6 over link L1. 164 9236 --> Adjacency Segment ID from R3 to R6 over link L1. 166 The forwarding semantic of Adjacency Segment ID is to pop the segment 167 ID and send the packet to a specific neighbor over a specific link. 168 A malfunctioning node may forward packets using Adjacency Segment ID 169 to incorrect neighbor or over incorrect link. Exposed segment ID 170 (after incorrectly forwarded Adjacency Segment ID) might still allow 171 such packet to reach the intended destination, although the intended 172 strict traversal has been broken. 174 Assume in above topology, R1 sends traffic with segment stack as 175 {9124, 5007, 9378} so that the path taken will be R1-R2-R4-R5-R7-R8. 176 If the Adjacency Segment ID 9124 is misprogrammed in R2 to send the 177 packet to R1 or R3, it will still be delivered to R8 but is not via 178 the expected path. 180 MPLS traceroute may help with detecting such deviation in above 181 mentioned scenario. However, in a different example, it may not be 182 helpful if R3, due to misprogramming, forwards packet with Adjacency 183 Segment ID 9236 via link L1 while it is expected to be forwarded over 184 Link L2. 186 3.2. Service Label 188 A Segment ID can represent a service based instruction. An SR header 189 can have label stack entries where the label represents a service to 190 be applied along the path. Since these labels are part of the label 191 stack, they can influence the path taken by a packet and consequently 192 have implications on MPLS OAM. This document describes how the 193 procedures of [RFC4379] can be applied to in the absence of service- 194 labels in Section 6.5. Additional considerations for service labels 195 are included in Section 7 and requires further discussion. 197 4. Segment ID sub-TLV 199 The format of the following Segment ID sub-TLVs follows the 200 philosophy of Target FEC Stack TLV carrying FECs corresponding to 201 each label in the label stack. When operated with the procedures 202 defined in [RFC4379], this allows LSP ping/traceroute operations to 203 function when Target FEC Stack TLV contains more FECs than received 204 label stack at responder nodes. 206 Three new sub-TLVs are defined for TLVs type 1, 16 and 21. 208 sub-Type Value Field 209 -------- --------------- 210 TBD1 IPv4 Prefix Node Segment ID 211 TBD2 IPv6 Prefix Node Segment ID 212 TBD3 Adjacency Segment ID 214 Service Segments and FRR will be considered in future version. 216 4.1. IPv4 Prefix Node Segment ID 218 The format is as below: 220 0 1 2 3 221 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 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | IPv4 Prefix | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 |Prefix Length | Resv | Protocol | SID Length | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | Node Segment ID | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | Reserved | | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 231 | Advertising Node Identifier | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 IPv4 Prefix 236 This field carries the IPv4 prefix to which the Node Segment ID is 237 assigned. 239 Prefix Length 241 The Prefix Length field is one octet, it gives the length of the 242 prefix in bits (values can be 1 - 32). 244 Protocol 246 Set to 1 if the IGP protocol is OSPF and 2 if IGP protocol is 247 ISIS. 249 SID Length 251 Set to 3 or 4 depending on the Segment ID. 253 Node Segment ID 255 This field carries the Node segment ID. If the SID Length is 3, 256 then the 20 rightmost bits represent the segment. If length is 4, 257 then the value represent a 32 bits Segment ID. 259 Advertising Node Identifier 261 Specifies the advertising node identifier. When Protocol is set 262 to 1, then the 32 rightmost bits represent OSPF Router ID and if 263 protocol is set to 2, this field carries 48 bit ISIS System ID. 265 4.2. IPv6 Prefix Node Segment ID 267 The format is as below: 269 0 1 2 3 270 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 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | | 273 | IPv6 Prefix | 274 | | 275 | | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 |Prefix Length | Resv | Protocol | SID Length | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | Node Segment ID | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | Reserved | | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 283 | Advertising Node Identifier | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 IPv6 Prefix 288 This field carries the IPv6 prefix to which the Node Segment ID is 289 assigned. 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 IGP protocol is OSPF and 2 if IGP protocol is 299 ISIS. 301 SID Length 303 Set to 3 or 4 depending on the Segment ID. 305 Node Segment ID 307 This field carries the Node segment ID. If the SID Length is 3, 308 then the 20 rightmost bits represent the Segment ID. If length is 309 4, then the value represent a 32 bits Segment ID. 311 Advertising Node Identifier 313 Specifies the advertising node identifier. When Protocol is set 314 to 1, then the 32 rightmost bits represent OSPF Router ID and if 315 protocol is set to 2, this field carries 48 bit ISIS System ID. 317 4.3. IGP Adjacency Segment ID 319 The format is as below: 321 0 1 2 3 322 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 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | Local Interface ID | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | Remote Interface ID | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | Protocol | SID Length | | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 330 | Advertising Node Identifier | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | IGP Adjacency Segment ID | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 Local Interface ID 337 An identifier that is assigned by local LSR for a link on which 338 Adjacency Segment ID is bound. If the Adjacency Segment ID 339 represents parallel adjacencies (Section 3.3.2.1 of 340 [I-D.filsfils-spring-segment-routing]) this field MUST be set to 341 zero. 343 Remote Interface ID 345 An identifier that is assigned by remote LSR for a link on which 346 Adjacency Segment ID is bound. If the Adjacency Segment ID 347 represents parallel adjacencies (Section 3.3.2.1 of 348 [I-D.filsfils-spring-segment-routing]) this field MUST be set to 349 zero. 351 Protocol 353 Set to 1 if the IGP protocol is OSPF and 2 if IGP protocol is ISIS 355 SID Length 356 Set to 3 or 4 depending on the Segment ID. 358 Advertising Node Identifier 360 Specifies the advertising node identifier. When Protocol is set 361 to 1, then the 32 rightmost bits represent OSPF Router ID and if 362 protocol is set to 2, this field carries 48 bit ISIS System ID. 364 IGP Adjacency Segment ID 366 This field carries the Adjacency Segment ID. If the SID Length is 367 3, then the 20 rightmost bits represent the Segment ID. If length 368 is 4, then the value represent a 32 bits Segment ID 370 5. Extension to Downstream Mapping TLV 372 In an echo reply, the Downstream Mapping TLV [RFC4379] is used to 373 report for each interface over which a FEC could be forwarded. For a 374 FEC, there are multiple protocols that may be used to distribute 375 label mapping. The "Protocol" field of the Downstream Mapping TLV is 376 used to return the protocol that is used to distribute a specific a 377 label. The following protocols are defined in section 3.2 of 378 [RFC4379]: 380 Protocol # Signaling Protocol 381 ---------- ------------------ 382 0 Unknown 383 1 Static 384 2 BGP 385 3 LDP 386 4 RSVP-TE 388 With segment routing, OSPF or ISIS can be used for label 389 distribution, this document adds two new protocols as follows: 391 Protocol # Signaling Protocol 392 ---------- ------------------ 393 5 OSPF 394 6 ISIS 396 6. Procedures 398 This section describes aspects of LSP Ping and traceroute operations 399 that require further considerations beyond [RFC4379]. 401 6.1. FECs in Target FEC Stack TLV 403 When LSP echo request packets are generated by an initiator, FECs 404 carried in Target FEC Stack TLV may need to or desire to have 405 deviating contents. This document outlines expected Target FEC Stack 406 TLV construction mechanics by initiator for known scenarios. 408 Ping 410 Initiator MUST include FEC(s) corresponding to the destination 411 segment. 413 Initiator MAY include FECs corresponding to some or all of 414 segments imposed in the label stack by the initiator to 415 communicate the segments traversed. 417 Traceroute 419 Initiator MUST initially include FECs corresponding to all of 420 segments imposed in the label stack. 422 When a received echo reply contains FEC Stack Change TLV with 423 one or more of original segment(s) being popped, initiator MAY 424 remove corresponding FEC(s) from Target FEC Stack TLV in the 425 next (TTL+1) traceroute request. 427 When a received echo reply does not contain FEC Stack Change 428 TLV, initiator MUST NOT attempt to remove FEC(s) from Target 429 FEC Stack TLV in the next (TTL+1) traceroute request. Note 430 that Downstream Label field of DSMAP/DDMAP contains hints on 431 how initiator may be able to update the contents of next Target 432 FEC Stack TLV. However, such hints are ambiguous without full 433 understanding of PHP capabilities. 435 6.2. FEC Stack Change sub-TLV 437 Section 3.3.1.3 of [RFC6424] defines a new sub-TLV that a router must 438 include when the FEC stack changes. 440 The network node which advertised the Node Segment ID is responsible 441 for generating FEC Stack Change sub-TLV of &pop& operation for Node 442 Segment ID, regardless of if PHP is enabled or not. 444 The network node that is immediate downstream of the node which 445 advertised the Adjacency Segment ID is responsible for generating FEC 446 Stack Change sub-TLV of &pop& operation for Adjacency Segment ID. 448 6.3. Segment ID POP Operation 450 The forwarding semantic of Node Segment ID with PHP flag is 451 equivalent to usage of implicit Null in MPLS protocols. Adjacency 452 Segment ID is also similar in a sense that it can be thought as next 453 hop destined locally allocated segment that has PHP enabled. 454 Procedures described in Section 4.4 of [RFC4379] relies on Stack-D 455 and Stack-R explicitly having Implicit Null value. It may simplify 456 implementations to reuse Implicit Null for Node Segment ID PHP and 457 Adjacency Segment ID cases. However, it is technically incorrect for 458 Implicit Null value to externally appear. Therefore, implicit Null 459 MUST NOT be placed in Stack-D and Interface and Label Stack TLV for 460 Node Segment ID PHP and Adjacency Segment ID cases. 462 6.4. Segment ID Check 464 If the Target FEC Stack Sub-TLV at FEC-stack-depth is TBD1 (IPv4 465 Prefix Node Segment ID), the responder SHOULD set Best return code 466 to (error code TBD) if any below conditions fail: 468 * Validate that Advertising Node Identifier of Protocol is a 469 local node. 471 * Validate that Node Segment ID is advertised for IPv4 Prefix by 472 the Protocol with Advertising Node Identifier. 474 * Validate that Node Segment ID is advertisement of PHP bit. 476 If the Target FEC Sub-TLV at FEC-stack-depth is TBD2 (IPv6 Prefix 477 Node Segment ID), set Best return code to (error code TBD) if any 478 below conditions fail: 480 * Validate that Advertising Node Identifier of Protocol is a 481 local node. 483 * Validate that Node Segment ID is advertised for IPv6 Prefix by 484 the Protocol with Advertising Node Identifier. 486 * Validate that Node Segment ID is advertised of PHP bit. 488 If the Target FEC sub-TLV at FEC-stack-depth is TBD3 (Adjacency 489 Segment ID), set Best return code to (error code TBD) if any below 490 conditions fail: 492 * Validate that Remote Interface ID matches the local identifier 493 of the interface on which the packet was received. 495 * Validate that IGP Adjacency Segment ID is advertised by 496 Advertising Node Identifier of Protocol in local IGP database. 498 6.5. TTL Consideration for traceroute 500 LSP Traceroute operation can properly traverse every hop of Segment 501 Routing network in Uniform Model described in [RFC3443]. If one or 502 more LSRs employ Short Pipe Model described in [RFC3443], then LSP 503 Traceroute may not be able to properly traverse every hop of Segment 504 Routing network due to absence of TTL copy operation when outer label 505 is popped. In such scenario, following TTL manipulation technique 506 MAY be used. 508 When tracing a LSP according to the procedures in [RFC4379] the TTL 509 is incremented by one in order to trace the path sequentially along 510 the LSP. However when a source routed LSP has to be traced there are 511 as many TTLs as there are labels in the stack. The LSR that 512 initiates the traceroute SHOULD start by setting the TTL to 1 for the 513 tunnel in the LSP's label stack it wants to start the tracing from, 514 the TTL of all outer labels in the stack to the max value, and the 515 TTL of all the inner labels in the stack to zero. Thus a typical 516 start to the traceroute would have a TTL of 1 for the outermost label 517 and all the inner labels would have TTL 0. If the FEC Stack TLV is 518 included it should contain only those for the inner stacked tunnels. 519 The lack of an echo response or the Return Code/Subcode should be 520 used to diagnose the tunnel as described in [RFC4379]. When the 521 tracing of a tunnel in the stack is complete, then the next tunnel in 522 the stack should be traced. The end of a tunnel can be detected from 523 the "Return Code" when it indicates that the responding LSR is an 524 egress for the stack at depth 1. Thus the traceroute procedures in 525 [RFC4379] can be recursively applied to traceroute a source routed 526 LSP. 528 7. Issues with non-forwarding labels 530 Source stacking can be optionally used to apply services on the 531 packet at a LSR along the path, where a label in the stack is used to 532 trigger service application. A data plane failure detection and 533 isolation mechanism should provide its functionality without applying 534 these services. This is mandatory for services that are stateful, 535 though for stateless services [RFC4379] could be used as-is. It MAY 536 also provide a mechanism to detect and isolate faults within the 537 service function itself. 539 To prevent services from being applied to an "echo request" packet, 540 the TTL of service labels MUST be 0. However TTL processing rules of 541 a service label must be the same as any MPLS label. Due to this a 542 TTL of 0 in the service label would prevent the packet from being 543 forwarded beyond the LSR that provides the service. To avoid this 544 problem, the originator of the "echo request" MUST NOT include the 545 service label in the label stack of an echo request above the tunnel 546 label of the tunnel that is being currently traced. In other words 547 the ingress must remove all service-labels above the label of the 548 tunnel being currently traced, but retain service labels below it 549 when sending the echo request. Note that load balancing may affect 550 the path when the service labels are removed, resulting in a newer 551 path being traversed. However this new path is potentially different 552 only up to the LSR that provides the service. Since this portion of 553 the path was traced when the tunnels above this tunnel in the stack 554 were traced and followed the exact path as the source routed LSP, 555 this should not be a major concern. Sometimes the newer path may 556 have a problem that was not in the original path resulting in a false 557 positive. In such a case the original path can be traversed by 558 changing the label stack to reach the intermediate LSR with labels 559 that route along each hop explicitly. 561 8. IANA Considerations 563 To be Updated. 565 9. Security Considerations 567 To be Updated. 569 10. Acknowledgement 571 The authors would like to thank Stefano Previdi for his review and 572 comments. 574 The authors wold like to thank Loa Andersson for his comments and 575 recommendation to merge drafts. 577 11. Contributing Authors 579 Tarek Saad 580 Cisco Systems 581 Email: tsaad@cisco.com 583 Siva Sivabalan 584 Cisco Systems 585 Email: msiva@cisco.com 587 12. References 589 12.1. Normative References 591 [I-D.filsfils-spring-segment-routing] 592 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 593 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 594 Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, 595 "Segment Routing Architecture", draft-filsfils-spring- 596 segment-routing-03 (work in progress), June 2014. 598 [I-D.filsfils-spring-segment-routing-use-cases] 599 Filsfils, C., Francois, P., Previdi, S., Decraene, B., 600 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 601 Ytti, S., Henderickx, W., Tantsura, J., Kini, S., and E. 602 Crabbe, "Segment Routing Use Cases", draft-filsfils- 603 spring-segment-routing-use-cases-00 (work in progress), 604 March 2014. 606 [I-D.gredler-spring-mpls] 607 Gredler, H., Rekhter, Y., Jalil, L., Kini, S., and X. Xu, 608 "Supporting Source/Explicitly Routed Tunnels via Stacked 609 LSPs", draft-gredler-spring-mpls-06 (work in progress), 610 May 2014. 612 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 613 RFC 792, September 1981. 615 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 616 Requirement Levels", BCP 14, RFC 2119, March 1997. 618 [RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing 619 in Multi-Protocol Label Switching (MPLS) Networks", RFC 620 3443, January 2003. 622 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 623 Label Switched (MPLS) Data Plane Failures", RFC 4379, 624 February 2006. 626 [RFC6424] Bahadur, N., Kompella, K., and G. Swallow, "Mechanism for 627 Performing Label Switched Path Ping (LSP Ping) over MPLS 628 Tunnels", RFC 6424, November 2011. 630 12.2. Informative References 632 [RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, 633 D., and S. Mansfield, "Guidelines for the Use of the "OAM" 634 Acronym in the IETF", BCP 161, RFC 6291, June 2011. 636 [RFC6425] Saxena, S., Swallow, G., Ali, Z., Farrel, A., Yasukawa, 637 S., and T. Nadeau, "Detecting Data-Plane Failures in 638 Point-to-Multipoint MPLS - Extensions to LSP Ping", RFC 639 6425, November 2011. 641 Authors' Addresses 643 Nagendra Kumar 644 Cisco Systems, Inc. 645 7200 Kit Creek Road 646 Research Triangle Park, NC 27709 647 US 649 Email: naikumar@cisco.com 651 George Swallow 652 Cisco Systems, Inc. 653 1414 Massachusetts Ave 654 Boxborough, MA 01719 655 US 657 Email: swallow@cisco.com 659 Carlos Pignataro 660 Cisco Systems, Inc. 661 7200 Kit Creek Road 662 Research Triangle Park, NC 27709-4987 663 US 665 Email: cpignata@cisco.com 667 Nobo Akiya 668 Cisco Systems, Inc. 669 2000 Innovation Drive 670 Kanata, ON K2K 3E8 671 Canada 673 Email: nobo@cisco.com 675 Sriganesh Kini 676 Ericsson 678 Email: sriganesh.kini@ericsson.com 679 Hannes Gredler 680 Juniper Networks 682 Email: hannes@juniper.net 684 Mach(Guoyi) Chen 685 Huawei 687 Email: mach.chen@huawei.com