idnits 2.17.1 draft-kumarkini-mpls-spring-lsp-ping-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 02, 2014) is 3766 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.filsfils-rtgwg-segment-routing-use-cases' is defined on line 584, but no explicit reference was found in the text == Unused Reference: 'I-D.gredler-spring-mpls' is defined on line 599, but no explicit reference was found in the text == Unused Reference: 'RFC6424' is defined on line 619, but no explicit reference was found in the text == Unused Reference: 'RFC6291' is defined on line 625, but no explicit reference was found in the text == Unused Reference: 'RFC6425' is defined on line 629, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-gredler-spring-mpls-02 -- 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: 2 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 3 Internet-Draft G. Swallow 4 Intended status: Standards Track C. Pignataro 5 Expires: July 6, 2014 N. Akiya 6 Cisco Systems, Inc. 7 S. Kini 8 Ericsson 9 H. Gredler 10 Juniper Networks 11 M. Chen 12 Huawei 13 January 02, 2014 15 Label Switched Path (LSP) Ping/Trace for Segment Routing Networks Using 16 MPLS Dataplane 17 draft-kumarkini-mpls-spring-lsp-ping-00 19 Abstract 21 Segment Routing architecture leverages the source routing and 22 tunneling paradigm and can be directly applied to MPLS dataplane. A 23 node steers a packet through a controlled set of instructions called 24 segments, by prepending the packet with Segment Routing header. 26 The segment assignment and forwarding semantic nature of Segment 27 Routing raises additional consideration for connectivity verification 28 and fault isolation in LSP with Segment Routing architecture. This 29 document illustrates the problem and describe a mechanism to perform 30 LSP Ping and Traceroute on Segment Routing network over MPLS 31 dataplane. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on July 6, 2014. 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 69 3. Challenges with Existing mechanism . . . . . . . . . . . . . 3 70 3.1. Path validation in Segment Routing networks . . . . . . . 3 71 3.2. Service Label . . . . . . . . . . . . . . . . . . . . . . 4 72 4. Segment Routing Sub-TLV Format . . . . . . . . . . . . . . . 5 73 4.1. IPv4 Prefix Node Segment ID . . . . . . . . . . . . . . . 5 74 4.2. IPv6 Prefix Node Segment ID . . . . . . . . . . . . . . . 6 75 4.3. IGP Adjacency Segment ID . . . . . . . . . . . . . . . . 7 76 5. Extension to Downstream Mapping TLV . . . . . . . . . . . . . 9 77 6. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 9 78 6.1. FECs in Target FEC Stack TLV . . . . . . . . . . . . . . 9 79 6.2. FEC Stack Change TLV . . . . . . . . . . . . . . . . . . 10 80 6.3. PHP, Adjacency SID Pop, Implicit NULL . . . . . . . . . . 10 81 6.4. Segment Protocol Check . . . . . . . . . . . . . . . . . 10 82 6.5. TTL Consideration for traceroute . . . . . . . . . . . . 11 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 . . . . . . . . . . . . . . . . . . . . . . . . . 13 89 12.1. Normative References . . . . . . . . . . . . . . . . . . 13 90 12.2. Informative References . . . . . . . . . . . . . . . . . 14 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 93 1. Introduction 95 [I-D.filsfils-rtgwg-segment-routing] introduces and explains Segment 96 Routing architecture that leverages the source routing and tunneling 97 paradigm. A node steers a packet through a controlled set of 98 instructions called segments, by prepending the packet with SR 99 header. A detailed definition about Segment Routing architecture is 100 available in draft-filsfils-rtgwg-segment-routing and different use- 101 cases are discussed in draft-filsfils-rtgwg-segment-routing-use- 102 cases. 104 The Segment Routing architecture can be directly applied to MPLS 105 dataplane in a way that, the segment will be of 20-bits size and SR 106 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 MPLS-ping and MPLS-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 connectivity verification and fault isolation in Segment Routing 123 network. This document illustrates the problem and describe a 124 mechanism to perform LSP Ping and Traceroute on Segment Routing 125 network over MPLS dataplane. 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 connectivity 141 check and fault isolation in MPLS dataplane path with the use of 142 various Target FEC Stack Sub-TLV that are carried in MPLS Ping 143 packets and used by the responder for FEC validation. While it is 144 obvious that new Sub-TLVs need to be assigned, the unique nature of 145 Segment Routing architecture raises a need for additional machinery 146 for path 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 500x --> Node Segment ID for Router X 162 (Ex: 5006 is node segment ID for R6) 163 9axy --> Adj Segment ID from Router X to Y over link a 164 (Ex: 9136 is Adj segment ID from R3 to R6 via link 1) 166 The forwarding semantic of Adjacency segment is to pop the segment 167 and send the packet to a specific neighbor over a specific link. A 168 malfunctioning node may forward packets using Adjacency segment to 169 incorrect neighbor or over incorrect link. Exposed segment (after 170 incorrectly forwarded Adjacency segment) might still allow such 171 packet to traverse to intended destination, yet intended strict 172 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 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 9236 via link L1 while it is expected to be forwarded over 184 Link L2. 186 3.2. Service Label 188 One of the proposals for source routed LSPs is to include service 189 labels in the MPLS label stack. These service labels are used to 190 apply a service (as indicated by the service label) to the packet at 191 the intermediate LSRs along the explicit-route. Since these labels 192 are part of the MPLS label stack these have implications on MPLS OAM. 193 This document describes how the procedures of [RFC4379] can be 194 applied to in the absence of service-labels in Section xx. 195 Additional considerations for service labels are included in 196 Section yy and requires further discussion. 198 4. Segment Routing Sub-TLV Format 200 The format of the following FEC Sub-TLVs follows the philosophy of 201 Target FEC Stack TLV carrying FECs corresponding to each label in the 202 label stack. When operated with the procedures defined in [RFC4379], 203 this allows LSP ping/traceroute operations to function when Target 204 FEC Stack TLV contains more FECs than received label stack at 205 responder nodes. 207 Type Sub-Type Value Field 208 ---- -------- --------------- 209 1 TBD1 IPv4 Prefix Node Segment ID 210 TBD2 IPv6 Prefix Node Segment ID 211 TBD3 Adjacency Segment ID 213 Service Segments and FRR will be considered in future version. 215 4.1. IPv4 Prefix Node Segment ID 217 The format is as below: 219 0 1 2 3 220 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 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | IPv4 Prefix | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 |Prefix Length | Resv | Protocol | SID Length | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | Node Segment ID | 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | Reserved | | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 230 | Advertising Node Identifier | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 IPv4 Prefix 235 This field carries the IPv4 prefix to which the Node Segment ID is 236 assigned. 238 Prefix Length 240 One octet of prefix length in bits. 242 Protocol 244 Set to 1 if the IGP protocol is OSPF and 2 if IGP protocol is 245 ISIS. 247 SID Length 249 Set to 3 or 4 depending on the Segment ID. 251 Node Segment ID 253 This field carries the Node segment ID. If the SID Length is 3, 254 then the 20 rightmost bits represent the segment. If length is 4, 255 then the value represent a 32 bits Segment ID. 257 Advertising Node Identifier 259 Specifies the advertising node identifier. When Protocol is set 260 to 1, then the 32 rightmost bits represent OSPF Router ID and if 261 protocol is set to 2, this field carries 48 bit ISIS System ID. 263 4.2. IPv6 Prefix Node Segment ID 265 The format is as below: 267 0 1 2 3 268 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 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | | 271 | IPv6 Prefix | 272 | | 273 | | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 |Prefix Length | Resv | Protocol | SID Length | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | Node Segment ID | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | Reserved | | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 281 | Advertising Node Identifier | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 IPv6 Prefix 286 This field carries the IPv6 prefix to which the Node Segment ID is 287 assigned. 289 Prefix Length 291 One octet of prefix length in bits. 293 Protocol 295 Set to 1 if the IGP protocol is OSPF and 2 if IGP protocol is 296 ISIS. 298 SID Length 300 Set to 3 or 4 depending on the Segment ID. 302 Node Segment ID 304 This field carries the Node segment ID. If the SID Length is 3, 305 then the 20 rightmost bits represent the segment. If length is 4, 306 then the value represent a 32 bits Segment ID. 308 Advertising Node Identifier 310 Specifies the advertising node identifier. When Protocol is set 311 to 1, then the 32 rightmost bits represent OSPF Router ID and if 312 protocol is set to 2, this field carries 48 bit ISIS System ID. 314 4.3. IGP Adjacency Segment ID 316 The format is as below: 318 0 1 2 3 319 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 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | Local Interface ID | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | Remote Interface ID | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | Protocol | SID Length | | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 327 | Advertising Node Identifier | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | IGP Adjacency Segment ID | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 Local Interface ID 334 An identifier that is assigned by local LSR for a link on which 335 Adjacency SID is bound. If the Adj-SID represents parallel 336 adjacencies (Section 3.3.2.1 of 337 [I-D.filsfils-rtgwg-segment-routing]) this field MUST be set to 338 zero. 340 Remote Interface ID 342 An identifier that is assigned by remote LSR for a link on which 343 Adjacency SID is bound. If the Adj-SID represents parallel 344 adjacencies (Section 3.3.2.1 of 345 [I-D.filsfils-rtgwg-segment-routing]) this field MUST be set to 346 zero. 348 Protocol 350 Set to 1 if the IGP protocol is OSPF and 2 if IGP protocol is ISIS 352 SID Length 354 Set to 3 or 4 depending on the Segment ID. 356 Advertising Node Identifier 358 Specifies the advertising node identifier. When Protocol is set 359 to 1, then the 32 rightmost bits represent OSPF Router ID and if 360 protocol is set to 2, this field carries 48 bit ISIS System ID. 362 IGP Adjacency Segment ID 363 This field carries the adjacency segment ID. 365 5. Extension to Downstream Mapping TLV 367 In an echo reply, the Downstream Mapping TLV [RFC4379] is used to 368 report for each interface over which a FEC could be forwarded. For 369 an FEC, there are multiple protocols that may be used to distribute 370 label mapping. The "Protocol" field of the Downstream Mapping TLV is 371 used to return the protocol that is used to distribute a specific a 372 label. The following protocols are defined in section 3.2 of 373 [RFC4379]: 375 Protocol # Signaling Protocol 376 ---------- ------------------ 377 0 Unknown 378 1 Static 379 2 BGP 380 3 LDP 381 4 RSVP-TE 383 With segment routing, OSPF or ISIS can be used for label 384 distribution, this document adds two new protocols as follows: 386 Protocol # Signaling Protocol 387 ---------- ------------------ 388 5 OSPF 389 6 ISIS 391 6. Procedures 393 This section describes aspects of LSP ping/traceroute operations that 394 require further considerations beyond [RFC4379]. 396 6.1. FECs in Target FEC Stack TLV 398 When LSP echo request packets are generated by an initiator, FECs 399 carried in Target FEC Stack TLV may need to or desire to have 400 deviating contents. This document outlines expected Target FEC Stack 401 TLV construction mechanics by initiator for known scenarios. 403 Ping 405 Initiator MUST include FEC(s) corresponding to the destination 406 segment. 408 Initiator MAY include FECs corresponding to some or all of 409 segments imposed in the label stack by the initiator to 410 communicate the segments traversed. 412 Traceroute 414 Initiator MUST initially include FECs corresponding to all of 415 segments imposed in the label stack. 417 When a received echo reply contains FEC Stack Change TLV with 418 one or more of original segment(s) being popped, initiator MAY 419 remove corresponding FEC(s) from Target FEC Stack TLV in the 420 next (TTL+1) traceroute request. 422 When a received echo reply does not contain FEC Stack Change 423 TLV, initiator MUST NOT attempt to remove FEC(s) from Target 424 FEC Stack TLV in the next (TTL+1) traceroute request. Note 425 that Downstream Label field of DSMAP/DDMAP contains hints on 426 how initiator may be able to update the contents of next Target 427 FEC Stack TLV. However, such hints are ambiguous without full 428 understanding of PHP capabilities. 430 6.2. FEC Stack Change TLV 432 The network node which advertised the node segment ID is responsible 433 for generating FEC Stack Change TLV of &pop& operation for node 434 segment ID, regardless of if PHP is enabled or not. 436 The network node that is immediate downstream of the node which 437 advertised the adjacency segment ID is responsible for generating FEC 438 Stack Change TLV of &pop& operation for adjacency segment ID. 440 6.3. PHP, Adjacency SID Pop, Implicit NULL 442 Forwarding behavior of node segment ID PHP is equivalent to usage of 443 implicit Null in MPLS protocols that embraces downstream label 444 allocation scheme. Adjacency segment ID is also similar in a sense 445 that it can be thought as nexthop destined locally allocated segment 446 that has PHP enabled. Procedures described in Section 4.4 of 447 [RFC4379] relies on Stack-D and Stack-R explicitly having Implicit 448 Null value. It may simplify implementations to reuse Implicit Null 449 for node segment ID PHP and adjacency segment ID cases. However, it 450 is technically incorrect for Implicit Null value to externally 451 appear. Therefore, implicit Null MUST NOT be placed in Stack-D and 452 Interface and Label Stack TLV for node segment ID PHP and adjacency 453 segment ID cases. 455 6.4. Segment Protocol Check 457 If the Target FEC Sub-TLV at FEC-stack-depth is TBD1 (IPv4 Prefix 458 Node Segment ID), set Best return code to (error code TBD) if any 459 below conditions fail: 461 * Validate that Advertising Node Identifier of Protocol is a 462 local node. 464 * Validate that Node Segment ID is advertised for IPv4 Prefix by 465 the Protocol with Advertising Node Identifier. 467 * Validate that Node Segment ID is advertisement of PHP bit. 469 If the Target FEC Sub-TLV at FEC-stack-depth is TBD2 (IPv6 Prefix 470 Node Segment ID), set Best return code to (error code TBD) if any 471 below conditions fail: 473 * Validate that Advertising Node Identifier of Protocol is a 474 local node. 476 * Validate that Node Segment ID is advertised for IPv6 Prefix by 477 the Protocol with Advertising Node Identifier. 479 * Validate that Node Segment ID is advertised of PHP bit. 481 If the Target FEC sub-TLV at FEC-stack-depth is TBD3 (Adjacency 482 Segment ID), set Best return code to (error code TBD) if any below 483 conditions fail: 485 * Validate that Remote Interface ID matches the local identifier 486 of the interface on which the packet was received. 488 * Validate that IGP Adjacency SID is advertised by Advertising 489 Node Identifier of Protocol in local IGP database. 491 6.5. TTL Consideration for traceroute 493 LSP Traceroute operation can properly traverse every hop of Segment 494 Routing network in Uniform Model described in [RFC3443]. If one or 495 more LSRs employ Short Pipe Model described in [RFC3443], then LSP 496 Traceroute may not be able to properly traverse every hop of Segment 497 Routing network due to absence of TTL copy operation when outer label 498 is popped. In such scenario, following TTL manipulation technique 499 MAY be used. 501 When tracing a LSP according to the procedures in [RFC4379] the TTL 502 is incremented by one in order to trace the path sequentially along 503 the LSP. However when a source routed LSP has to be traced there are 504 as many TTLs as there are labels in the stack. The LSR that 505 initiates the traceroute SHOULD start by setting the TTL to 1 for the 506 tunnel in the LSP's label stack it wants to start the tracing from, 507 the TTL of all outer labels in the stack to the max value, and the 508 TTL of all the inner labels in the stack to zero. Thus a typical 509 start to the traceroute would have a TTL of 1 for the outermost label 510 and all the inner labels would have TTL 0. If the FEC Stack TLV is 511 included it should contain only those for the inner stacked tunnels. 512 The lack of an echo response or the Return Code/Subcode should be 513 used to diagnose the tunnel as described in [RFC4379]. When the 514 tracing of a tunnel in the stack is complete, then the next tunnel in 515 the stack should be traced. The end of a tunnel can be detected from 516 the "Return Code" when it indicates that the responding LSR is an 517 egress for the stack at depth 1. Thus the traceroute procedures in 518 [RFC4379] can be recursively applied to traceroute a source routed 519 LSP. 521 7. Issues with non-forwarding labels 523 Source stacking can be optionally used to apply services on the 524 packet at a LSR along the path, where a label in the stack is used to 525 trigger service application. A data plane failure detection and 526 isolation mechanism should provide its functionality without applying 527 these services. This is mandatory for services that are stateful, 528 though for stateless services [RFC4379] could be used as-is. It MAY 529 also provide a mechanism to detect and isolate faults within the 530 service function itself. 532 To prevent services from being applied to an "echo request" packet, 533 the TTL of service labels MUST be 0. However TTL processing rules of 534 a service label must be the same as any MPLS label. Due to this a 535 TTL of 0 in the service label would prevent the packet from being 536 forwarded beyond the LSR that provides the service. To avoid this 537 problem, the originator of the "echo request" must remove those 538 service labels from the stack up to the tunnel that is being 539 currently traced. In other words the ingress must remove all 540 service-labels above the label of the tunnel being currently traced, 541 but retain service labels below it when sending the echo request. 542 Note that load balancing may affect the path when the service labels 543 are removed, resulting in a newer path being traversed. However this 544 new path is potentially different only up to the LSR that provides 545 the service. Since this portion of the path was traced when the 546 tunnels above this tunnel in the stack were traced and followed the 547 exact path as the source routed LSP, this should not be a major 548 concern. Sometimes the newer path may have a problem that was not in 549 the original path resulting in a false positive. In such a case the 550 original path can be traversed by changing the label stack to reach 551 the intermediate LSR with labels that route along each hop 552 explicitly. 554 8. IANA Considerations 556 To be Updated. 558 9. Security Considerations 560 To be Updated. 562 10. Acknowledgement 564 The authors would like to thank Stefano Previdi for his review and 565 comments. 567 The authors wold like to thank Loa Andersson for his comments and 568 recommendation to merge drafts. 570 11. Contributing Authors 572 Tarek Saad 573 Cisco Systems 574 Email: tsaad@cisco.com 576 Siva Sivabalan 577 Cisco Systems 578 Email: msiva@cisco.com 580 12. References 582 12.1. Normative References 584 [I-D.filsfils-rtgwg-segment-routing-use-cases] 585 Filsfils, C., Francois, P., Previdi, S., Decraene, B., 586 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 587 Ytti, S., Henderickx, W., Tantsura, J., Kini, S., and E. 588 Crabbe, "Segment Routing Use Cases", draft-filsfils-rtgwg- 589 segment-routing-use-cases-02 (work in progress), October 590 2013. 592 [I-D.filsfils-rtgwg-segment-routing] 593 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 594 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 595 Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, 596 "Segment Routing Architecture", draft-filsfils-rtgwg- 597 segment-routing-01 (work in progress), October 2013. 599 [I-D.gredler-spring-mpls] 600 Gredler, H., Rekhter, Y., Jalil, L., and S. Kini, 601 "Supporting Source/Explicitly Routed Tunnels via Stacked 602 LSPs", draft-gredler-spring-mpls-02 (work in progress), 603 October 2013. 605 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 606 RFC 792, September 1981. 608 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 609 Requirement Levels", BCP 14, RFC 2119, March 1997. 611 [RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing 612 in Multi-Protocol Label Switching (MPLS) Networks", RFC 613 3443, January 2003. 615 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 616 Label Switched (MPLS) Data Plane Failures", RFC 4379, 617 February 2006. 619 [RFC6424] Bahadur, N., Kompella, K., and G. Swallow, "Mechanism for 620 Performing Label Switched Path Ping (LSP Ping) over MPLS 621 Tunnels", RFC 6424, November 2011. 623 12.2. Informative References 625 [RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, 626 D., and S. Mansfield, "Guidelines for the Use of the "OAM" 627 Acronym in the IETF", BCP 161, RFC 6291, June 2011. 629 [RFC6425] Saxena, S., Swallow, G., Ali, Z., Farrel, A., Yasukawa, 630 S., and T. Nadeau, "Detecting Data-Plane Failures in 631 Point-to-Multipoint MPLS - Extensions to LSP Ping", RFC 632 6425, November 2011. 634 Authors' Addresses 636 Nagendra Kumar 637 Cisco Systems, Inc. 638 7200 Kit Creek Road 639 Research Triangle Park, NC 27709 640 US 642 Email: naikumar@cisco.com 643 George Swallow 644 Cisco Systems, Inc. 645 1414 Massachusetts Ave 646 Boxborough, MA 01719 647 US 649 Email: swallow@cisco.com 651 Carlos Pignataro 652 Cisco Systems, Inc. 653 7200 Kit Creek Road 654 Research Triangle Park, NC 27709-4987 655 US 657 Email: cpignata@cisco.com 659 Nobo Akiya 660 Cisco Systems, Inc. 661 2000 Innovation Drive 662 Kanata, ON K2K 3E8 663 Canada 665 Email: nobo@cisco.com 667 Sriganesh Kini 668 Ericsson 670 Email: sriganesh.kini@ericsson.com 672 Hannes Gredler 673 Juniper Networks 675 Email: hannes@juniper.net 677 Mach(Guoyi) Chen 678 Huawei 680 Email: mach.chen@huawei.com