idnits 2.17.1 draft-kumarkini-mpls-spring-lsp-ping-04.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 are 4 instances of too long lines in the document, the longest one being 52 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 30, 2015) is 3187 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) == Unused Reference: 'RFC6291' is defined on line 661, but no explicit reference was found in the text == Unused Reference: 'RFC6425' is defined on line 667, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-03 ** Obsolete normative reference: RFC 4379 (Obsoleted by RFC 8029) ** Obsolete normative reference: RFC 6424 (Obsoleted by RFC 8029) Summary: 3 errors (**), 0 flaws (~~), 4 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 31, 2016 Cisco Systems, Inc. 6 N. Akiya 7 Big Switch Networks 8 S. Kini 9 Ericsson 10 H. Gredler 11 Juniper Networks 12 M. Chen 13 Huawei 14 July 30, 2015 16 Label Switched Path (LSP) Ping/Trace for Segment Routing Networks Using 17 MPLS Dataplane 18 draft-kumarkini-mpls-spring-lsp-ping-04 20 Abstract 22 Segment Routing architecture leverages the source routing and 23 tunneling paradigms and can be directly applied to MPLS data plane. 24 A node steers a packet through a controlled set of instructions 25 called segments, by prepending the packet with a Segment Routing 26 header. 28 The segment assignment and forwarding semantic nature of Segment 29 Routing raises additional consideration for connectivity verification 30 and fault isolation in LSP with Segment Routing architecture. This 31 document illustrates the problem and describe a mechanism to perform 32 LSP Ping and Traceroute on Segment Routing network over MPLS data 33 plane. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on January 31, 2016. 51 Copyright Notice 53 Copyright (c) 2015 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 69 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 70 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 71 4. Challenges with Existing mechanism . . . . . . . . . . . . . 4 72 4.1. Path validation in Segment Routing networks . . . . . . . 4 73 4.2. Service Label . . . . . . . . . . . . . . . . . . . . . . 5 74 5. Segment ID sub-TLV . . . . . . . . . . . . . . . . . . . . . 5 75 5.1. IPv4 Prefix Node Segment ID . . . . . . . . . . . . . . . 5 76 5.2. IPv6 Prefix Node Segment ID . . . . . . . . . . . . . . . 6 77 5.3. IGP Adjacency Segment ID . . . . . . . . . . . . . . . . 7 78 6. Extension to Downstream Mapping TLV . . . . . . . . . . . . . 8 79 7. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 9 80 7.1. FECs in Target FEC Stack TLV . . . . . . . . . . . . . . 9 81 7.2. FEC Stack Change sub-TLV . . . . . . . . . . . . . . . . 10 82 7.3. Segment ID POP Operation . . . . . . . . . . . . . . . . 10 83 7.4. Segment ID Check . . . . . . . . . . . . . . . . . . . . 10 84 7.5. TTL Consideration for traceroute . . . . . . . . . . . . 12 85 8. Issues with non-forwarding labels . . . . . . . . . . . . . . 12 86 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 87 9.1. New Target FEC Stack Sub-TLVs . . . . . . . . . . . . . . 13 88 10. Security Considerations . . . . . . . . . . . . . . . . . . . 13 89 11. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 13 90 12. Contributing Authors . . . . . . . . . . . . . . . . . . . . 13 91 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 92 13.1. Normative References . . . . . . . . . . . . . . . . . . 14 93 13.2. Informative References . . . . . . . . . . . . . . . . . 15 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 96 1. Introduction 98 [I-D.ietf-spring-segment-routing] introduces and explains Segment 99 Routing architecture that leverages the source routing and tunneling 100 paradigms. A node steers a packet through a controlled set of 101 instructions called segments, by prepending the packet with Segment 102 Routing header. A detailed definition about Segment Routing 103 architecture is available in [I-D.ietf-spring-segment-routing] and 104 different use-cases are discussed in 105 [I-D.filsfils-spring-segment-routing-use-cases] 107 The Segment Routing architecture can be directly applied to MPLS data 108 plane in a way that, the Segment identifier (Segment ID) will be of 109 20-bits size and Segment Routing header is the label stack. 111 Multi Protocol Label Switching (MPLS) has defined in [RFC4379] a 112 simple and efficient mechanism to detect data plane failures in Label 113 Switched Paths (LSP) by specifying information to be carried in an 114 MPLS "echo request" and "echo reply" for the purposes of fault 115 detection and isolation, and mechanisms for reliably sending the echo 116 reply. The functionality is modeled after the ping/traceroute 117 paradigm (ICMP echo request [RFC0792]) and is typically referred to 118 as LSP ping and LSP traceroute. 120 Unlike LDP or RSVP which are the other well-known MPLS control plane 121 protocols, segment assignment in Segment Routing architecture is not 122 hop-by-hop basis. 124 This nature of Segment Routing raises additional consideration for 125 fault detection and isolation in Segment Routing network. This 126 document illustrates the problem and describe a mechanism to perform 127 LSP Ping and Traceroute on Segment Routing network over MPLS data 128 plane. 130 2. Requirements notation 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 134 document are to be interpreted as described in [RFC2119]. 136 3. Terminology 138 This document uses the terminologies defined in 139 [I-D.ietf-spring-segment-routing], [RFC4379], and so the readers are 140 expected to be familiar with the same. 142 4. Challenges with Existing mechanism 144 This document defines sub-TLVs for the Target FEC Stack TLV and 145 explains how they can be used to tackle below challenges. 147 4.1. Path validation in Segment Routing networks 149 [RFC4379] defines the OAM machinery that helps with fault detection 150 and isolation in MPLS dataplane path with the use of various Target 151 FEC Stack Sub-TLV that are carried in MPLS Echo Request packets and 152 used by the responder for FEC validation. While it is obvious that 153 new Sub-TLVs need to be assigned, the unique nature of Segment 154 Routing architecture raises a need for additional machinery for path 155 validation. This section discuss the challenges as below: 157 L1 158 +--------+ 159 | L2 | 160 R3-------R6 161 / \ 162 / \ 163 R1----R2 R7----R8 164 \ / 165 \ / 166 R4-------R5 168 Figure 1: Segment Routing network 170 The Node segment IDs for R1, R2, R3, R4, R5, R6, R7 and R8 are 5001, 5002, 5003, 5004, 5005, 5006, 5007, 5008 respectively. 172 9136 --> Adjacency Segment ID from R3 to R6 over link L1. 173 9236 --> Adjacency Segment ID from R3 to R6 over link L2. 174 9124 --> Adjacency segment ID from R2 to R4. 175 9123 --> Adjacency Segment ID from R2 to R3. 177 The forwarding semantic of Adjacency Segment ID is to pop the segment 178 ID and send the packet to a specific neighbor over a specific link. 179 A malfunctioning node may forward packets using Adjacency Segment ID 180 to incorrect neighbor or over incorrect link. Exposed segment ID 181 (after incorrectly forwarded Adjacency Segment ID) might still allow 182 such packet to reach the intended destination, although the intended 183 strict traversal has been broken. 185 Assume in above topology, R1 sends traffic with segment stack as 186 {9124, 5008} so that the path taken will be R1-R2-R4-R5-R7-R8. If 187 the Adjacency Segment ID 9124 is misprogrammed in R2 to send the 188 packet to R1 or R3, it will still be delivered to R8 but is not via 189 the expected path. 191 MPLS traceroute may help with detecting such deviation in above 192 mentioned scenario. However, in a different example, it may not be 193 helpful. For example if R3, due to misprogramming, forwards packet 194 with Adjacency Segment ID 9236 via link L1 while it is expected to be 195 forwarded over Link L2. 197 4.2. Service Label 199 A Segment ID can represent a service based instruction. An Segment 200 Routing header can have label stack entries where the label 201 represents a service to be applied along the path. Since these 202 labels are part of the label stack, they can influence the path taken 203 by a packet and consequently have implications on MPLS OAM. In 204 section 6.5 of this document, it is described how the procedures of 205 [RFC4379] can be applied to in the absence of service-labels in 206 Section 6.5. Additional considerations for service labels are 207 included in Section 7 and requires further discussion. 209 5. Segment ID sub-TLV 211 The format of the following Segment ID sub-TLVs follows the 212 philosophy of Target FEC Stack TLV carrying FECs corresponding to 213 each label in the label stack. When operated with the procedures 214 defined in [RFC4379], this allows LSP ping/traceroute operations to 215 function when Target FEC Stack TLV contains more FECs than received 216 label stack at responder nodes. 218 Three new sub-TLVs are defined for TLVs type 1, 16 and 21. 220 sub-Type Value Field 221 -------- --------------- 222 TBD1 IPv4 Prefix Node Segment ID 223 TBD2 IPv6 Prefix Node Segment ID 224 TBD3 Adjacency Segment ID 226 Service Segments and FRR will be considered in future version. 228 5.1. IPv4 Prefix Node Segment ID 230 The format is as below: 232 0 1 2 3 233 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 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | IPv4 Prefix | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 |Prefix Length | Protocol | Reserved | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 IPv4 Prefix 242 This field carries the IPv4 prefix to which the Node Segment ID is 243 assigned. If the prefix is shorter than 32 bits, trailing bits 244 SHOULD be set to zero. 246 Prefix Length 248 The Prefix Length field is one octet, it gives the length of the 249 prefix in bits (values can be 1 - 32). 251 Protocol 253 Set to 1 if the IGP protocol is OSPF and 2 if IGP protocol is 254 ISIS. 256 5.2. IPv6 Prefix Node Segment ID 258 The format is as below: 260 0 1 2 3 261 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 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | | 264 | IPv6 Prefix | 265 | | 266 | | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 |Prefix Length | Protocol | Reserved | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 IPv6 Prefix 272 This field carries the IPv6 prefix to which the Node Segment ID is 273 assigned. If the prefix is shorter than 128 bits, trailing bits 274 SHOULD be set to zero. 276 Prefix Length 278 The Prefix Length field is one octet, it gives the length of the 279 prefix in bits (values can be 1 - 128). 281 Protocol 283 Set to 1 if the IGP protocol is OSPF and 2 if IGP protocol is 284 ISIS. 286 5.3. IGP Adjacency Segment ID 288 The format is as below: 290 0 1 2 3 291 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 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | Adj. Type | Protocol | Reserved | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Local Interface ID (4 or 16 octets) | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | Remote Interface ID (4 or 16 octets) | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 ~ ~ 300 | Advertising Node Identifier (4 or 6 octets) | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 ~ ~ 303 | Receiving Node Identifier (4 or 6 octets) | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 Adj. Type 308 Set to 1, when the Adjacency Segment is Parallel Adjacency as 309 defined in section 3.5.1 of [I-D.ietf-spring-segment-routing]. 310 Set to 4, when the Adjacency segment is IPv4 based and is not a 311 parallel adjacency. Set to 6, when the Adjacency segment is IPv6 312 based and is not a parallel adjacency. 314 Protocol 316 Set to 1 if the IGP protocol is OSPF and 2 if IGP protocol is ISIS 318 Local Interface ID 320 An identifier that is assigned by local LSR for a link on which 321 Adjacency Segment ID is bound. This field is set to local link 322 address (IPv4 or IPv6). Incase of unnumbered, 32 bit link 323 identifier defined in [RFC4203], [RFC5307] is used. If the 324 Adjacency Segment ID represents parallel adjacencies 325 (Section 3.5.1 of [I-D.ietf-spring-segment-routing]) this field 326 MUST be set to zero. 328 Remote Interface ID 330 An identifier that is assigned by remote LSR for a link on which 331 Adjacency Segment ID is bound. This field is set to remote 332 (downstream neighbor) link address (IPv4 or IPv6). In case of 333 unnumbered, 32 bit link identifier defined in [RFC4203], [RFC5307] 334 is used. If the Adjacency Segment ID represents parallel 335 adjacencies (Section 3.5.1 of [I-D.ietf-spring-segment-routing]) 336 this field MUST be set to zero. 338 Advertising Node Identifier 340 Specifies the advertising node identifier. When Protocol is set 341 to 1, then the 32 rightmost bits represent OSPF Router ID and if 342 protocol is set to 2, this field carries 48 bit ISIS System ID. 344 Receiving Node Identifier 346 Specifies the downstream node identifier. When Protocol is set to 347 1, then the 32 rightmost bits represent OSPF Router ID and if 348 protocol is set to 2, this field carries 48 bit ISIS System ID. 350 6. Extension to Downstream Mapping TLV 352 In an echo reply, the Downstream Mapping TLV [RFC4379] is used to 353 report for each interface over which a FEC could be forwarded. For a 354 FEC, there are multiple protocols that may be used to distribute 355 label mapping. The "Protocol" field of the Downstream Mapping TLV is 356 used to return the protocol that is used to distribute a specific a 357 label. The following protocols are defined in section 3.2 of 358 [RFC4379]: 360 Protocol # Signaling Protocol 361 ---------- ------------------ 362 0 Unknown 363 1 Static 364 2 BGP 365 3 LDP 366 4 RSVP-TE 368 With segment routing, OSPF or ISIS can be used for label 369 distribution, this document adds two new protocols as follows: 371 Protocol # Signaling Protocol 372 ---------- ------------------ 373 5 OSPF 374 6 ISIS 376 7. Procedures 378 This section describes aspects of LSP Ping and traceroute operations 379 that require further considerations beyond [RFC4379]. 381 7.1. FECs in Target FEC Stack TLV 383 When LSP echo request packets are generated by an initiator, FECs 384 carried in Target FEC Stack TLV may need to have deviating contents. 385 This document outlines expected Target FEC Stack TLV construction 386 mechanics by initiator for known scenarios. 388 Ping 390 Initiator MUST include FEC(s) corresponding to the destination 391 segment. 393 Initiator MAY include FECs corresponding to some or all of 394 segments imposed in the label stack by the initiator to 395 communicate the segments traversed. 397 Traceroute 399 Initiator MUST initially include FECs corresponding to all of 400 segments imposed in the label stack. 402 When a received echo reply contains FEC Stack Change TLV with 403 one or more of original segment(s) being popped, initiator MAY 404 remove corresponding FEC(s) from Target FEC Stack TLV in the 405 next (TTL+1) traceroute request. 407 When a received echo reply does not contain FEC Stack Change 408 TLV, initiator MUST NOT attempt to remove FEC(s) from Target 409 FEC Stack TLV in the next (TTL+1) traceroute request. Note 410 that Downstream Label field of DSMAP/DDMAP contains hints on 411 how initiator may be able to update the contents of next Target 412 FEC Stack TLV. However, such hints are ambiguous without full 413 understanding of PHP capabilities. 415 7.2. FEC Stack Change sub-TLV 417 Section 3.3.1.3 of [RFC6424] defines a new sub-TLV that a router must 418 include when the FEC stack changes. 420 The network node which advertised the Node Segment ID is responsible 421 for generating FEC Stack Change sub-TLV of &pop& operation for Node 422 Segment ID, regardless of if PHP is enabled or not. 424 The network node that is immediate downstream of the node which 425 advertised the Adjacency Segment ID is responsible for generating FEC 426 Stack Change sub-TLV of &pop& operation for Adjacency Segment ID. 428 7.3. Segment ID POP Operation 430 The forwarding semantic of Node Segment ID with PHP flag is 431 equivalent to usage of implicit Null in MPLS protocols. Adjacency 432 Segment ID is also similar in a sense that it can be thought as next 433 hop destined locally allocated segment that has PHP enabled. 434 Procedures described in Section 4.4 of [RFC4379] relies on Stack-D 435 and Stack-R explicitly having Implicit Null value. It may simplify 436 implementations to reuse Implicit Null for Node Segment ID PHP and 437 Adjacency Segment ID cases. However, it is technically incorrect for 438 Implicit Null value to externally appear. Therefore, implicit Null 439 MUST NOT be placed in Stack-D and Interface and Label Stack TLV for 440 Node Segment ID PHP and Adjacency Segment ID cases. 442 7.4. Segment ID Check 444 If the Label-stack-depth is 0 and Target FEC Stack Sub-TLV at FEC- 445 stack-depth is TBD1 (IPv4 Prefix Node Segment ID), the responder 446 should set Best return code to 10 if any below conditions fail: /* 447 The responder LSR is to check if it is the egress of the IPv4 448 Prefix Node Segment ID described in the Target FEC Stack Sub-TLV, 449 and if the FEC was advertised with the PHP bit set.*/ 451 * Validate that Node Segment ID is advertised for IPv4 Prefix. 453 * Validate that Node Segment ID is advertisement of PHP bit. 455 If the Label-stack-depth is more than 0 and Target FEC Stack Sub- 456 TLV at FEC-stack-depth is TBD1 (IPv4 Prefix Node Segment ID), the 457 responder is to set Best return code to 10 if any below conditions 458 fail: 460 * Validate that Node Segment ID is advertised for IPv4 Prefix. 462 If the Label-stack-depth is 0 and Target FEC Sub-TLV at FEC-stack- 463 depth is TBD2 (IPv6 Prefix Node Segment ID), set Best return code 464 to 10 if any below conditions fail: /* The LSR needs to check if 465 its being a tail-end for the LSP and have the prefix advertised 466 with PHP bit set*/ 468 * Validate that Node Segment ID is advertised for IPv6 Prefix. 470 * Validate that Node Segment ID is advertised of PHP bit. 472 If the Label-stack-depth is 0 and Target FEC Sub-TLV at FEC-stack- 473 depth is TBD2 (IPv6 Prefix Node Segment ID), set Best return code 474 to 10 if any below conditions fail: 476 * Validate that Node Segment ID is advertised for IPv6 Prefix. 478 If the Label-stack-depth is 0 and Target FEC sub-TLV at FEC-stack- 479 depth is TBD3 (Adjacency Segment ID), set Best return code to 480 (error code TBD) if any below conditions fail: 482 When the Adj.Type is 1 (Parallel Adjacency): 484 + Validate that Receiving Node Identifier is local IGP 485 identifier. 487 + Validate that Adjacency Segment ID is advertised by 488 Advertising Node Identifier of Protocol in local IGP 489 database. 491 When the Adj.Type is 4 or 6: 493 + Validate that Remote Interface ID matches the local 494 identifier of the interface (Interface-I) on which the 495 packet was received. 497 + Validate that Receiving Node Identifier is local IGP 498 identifier. 500 + Validate that IGP Adjacency Segment ID is advertised by 501 Advertising Node Identifier of Protocol in local IGP 502 database. 504 7.5. TTL Consideration for traceroute 506 LSP Traceroute operation can properly traverse every hop of Segment 507 Routing network in Uniform Model described in [RFC3443]. If one or 508 more LSRs employ Short Pipe Model described in [RFC3443], then LSP 509 Traceroute may not be able to properly traverse every hop of Segment 510 Routing network due to absence of TTL copy operation when outer label 511 is popped. In such scenario, following TTL manipulation technique 512 MAY be used. 514 When tracing a LSP according to the procedures in [RFC4379] the TTL 515 is incremented by one in order to trace the path sequentially along 516 the LSP. However when a source routed LSP has to be traced there are 517 as many TTLs as there are labels in the stack. The LSR that 518 initiates the traceroute SHOULD start by setting the TTL to 1 for the 519 tunnel in the LSP's label stack it wants to start the tracing from, 520 the TTL of all outer labels in the stack to the max value, and the 521 TTL of all the inner labels in the stack to zero. Thus a typical 522 start to the traceroute would have a TTL of 1 for the outermost label 523 and all the inner labels would have TTL 0. If the FEC Stack TLV is 524 included it should contain only those for the inner stacked tunnels. 525 The lack of an echo response or the Return Code/Subcode should be 526 used to diagnose the tunnel as described in [RFC4379]. When the 527 tracing of a tunnel in the stack is complete, then the next tunnel in 528 the stack should be traced. The end of a tunnel can be detected from 529 the "Return Code" when it indicates that the responding LSR is an 530 egress for the stack at depth 1. Thus the traceroute procedures in 531 [RFC4379] can be recursively applied to traceroute a source routed 532 LSP. 534 8. Issues with non-forwarding labels 536 Source stacking can be optionally used to apply services on the 537 packet at a LSR along the path, where a label in the stack is used to 538 trigger service application. A data plane failure detection and 539 isolation mechanism should provide its functionality without applying 540 these services. This is mandatory for services that are stateful, 541 though for stateless services [RFC4379] could be used as-is. It MAY 542 also provide a mechanism to detect and isolate faults within the 543 service function itself. 545 To prevent services from being applied to an "echo request" packet, 546 the TTL of service labels MUST be 0. However TTL processing rules of 547 a service label must be the same as any MPLS label. Due to this a 548 TTL of 0 in the service label would prevent the packet from being 549 forwarded beyond the LSR that provides the service. To avoid this 550 problem, the originator of the "echo request" MUST NOT include the 551 service label in the label stack of an echo request above the tunnel 552 label of the tunnel that is being currently traced. In other words 553 the ingress must remove all service-labels above the label of the 554 tunnel being currently traced, but retain service labels below it 555 when sending the echo request. Note that load balancing may affect 556 the path when the service labels are removed, resulting in a newer 557 path being traversed. However this new path is potentially different 558 only up to the LSR that provides the service. Since this portion of 559 the path was traced when the tunnels above this tunnel in the stack 560 were traced and followed the exact path as the source routed LSP, 561 this should not be a major concern. Sometimes the newer path may 562 have a problem that was not in the original path resulting in a false 563 positive. In such a case the original path can be traversed by 564 changing the label stack to reach the intermediate LSR with labels 565 that route along each hop explicitly. 567 9. IANA Considerations 569 9.1. New Target FEC Stack Sub-TLVs 571 IANA is requested to assign 3 new Sub-TLVs from "Sub-TLVs for TLV 572 Types 1, 16 and 21" sub-registry. 574 Sub-Type Sub-TLV Name Reference 575 ---------- ----------------- ------------ 576 TBD1 IPv4 Prefix Node Segment ID Section 4.1 (this document) 577 TBD2 IPv6 Prefix Node Segment ID Section 4.2 (this document) 578 TBD3 Adjacency Segment ID Section 4.3 (this document) 580 10. Security Considerations 582 This document defines additional Sub-TLVs and follows the mechanism 583 defined in [RFC4379]. So all the security consideration defined in 584 [RFC4379] will be applicable for this document and in addition it 585 does not impose any security challenges to be considered. 587 11. Acknowledgement 589 The authors would like to thank Stefano Previdi, Les Ginsberg, Balaji 590 Rajagopalan and Harish Sitaraman for their review and comments. 592 The authors wold like to thank Loa Andersson for his comments and 593 recommendation to merge drafts. 595 12. Contributing Authors 597 Tarek Saad 598 Cisco Systems 599 Email: tsaad@cisco.com 600 Siva Sivabalan 601 Cisco Systems 602 Email: msiva@cisco.com 604 Balaji Rajagopalan 605 Juniper Networks 606 Email: balajir@juniper.net 608 13. References 610 13.1. Normative References 612 [I-D.filsfils-spring-segment-routing-use-cases] 613 Filsfils, C., Francois, P., Previdi, S., Decraene, B., 614 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 615 Ytti, S., Henderickx, W., Tantsura, J., Kini, S., and E. 616 Crabbe, "Segment Routing Use Cases", draft-filsfils- 617 spring-segment-routing-use-cases-01 (work in progress), 618 October 2014. 620 [I-D.ietf-spring-segment-routing] 621 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 622 and R. Shakir, "Segment Routing Architecture", draft-ietf- 623 spring-segment-routing-03 (work in progress), May 2015. 625 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 626 RFC 792, DOI 10.17487/RFC0792, September 1981, 627 . 629 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 630 Requirement Levels", BCP 14, RFC 2119, 631 DOI 10.17487/RFC2119, March 1997, 632 . 634 [RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing 635 in Multi-Protocol Label Switching (MPLS) Networks", 636 RFC 3443, DOI 10.17487/RFC3443, January 2003, 637 . 639 [RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in 640 Support of Generalized Multi-Protocol Label Switching 641 (GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005, 642 . 644 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 645 Label Switched (MPLS) Data Plane Failures", RFC 4379, 646 DOI 10.17487/RFC4379, February 2006, 647 . 649 [RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions 650 in Support of Generalized Multi-Protocol Label Switching 651 (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008, 652 . 654 [RFC6424] Bahadur, N., Kompella, K., and G. Swallow, "Mechanism for 655 Performing Label Switched Path Ping (LSP Ping) over MPLS 656 Tunnels", RFC 6424, DOI 10.17487/RFC6424, November 2011, 657 . 659 13.2. Informative References 661 [RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, 662 D., and S. Mansfield, "Guidelines for the Use of the "OAM" 663 Acronym in the IETF", BCP 161, RFC 6291, 664 DOI 10.17487/RFC6291, June 2011, 665 . 667 [RFC6425] Saxena, S., Ed., Swallow, G., Ali, Z., Farrel, A., 668 Yasukawa, S., and T. Nadeau, "Detecting Data-Plane 669 Failures in Point-to-Multipoint MPLS - Extensions to LSP 670 Ping", RFC 6425, DOI 10.17487/RFC6425, November 2011, 671 . 673 Authors' Addresses 675 Nagendra Kumar 676 Cisco Systems, Inc. 677 7200 Kit Creek Road 678 Research Triangle Park, NC 27709 679 US 681 Email: naikumar@cisco.com 683 George Swallow 684 Cisco Systems, Inc. 685 1414 Massachusetts Ave 686 Boxborough, MA 01719 687 US 689 Email: swallow@cisco.com 690 Carlos Pignataro 691 Cisco Systems, Inc. 692 7200 Kit Creek Road 693 Research Triangle Park, NC 27709-4987 694 US 696 Email: cpignata@cisco.com 698 Nobo Akiya 699 Big Switch Networks 701 Email: nobo.akiya.dev@gmail.com 703 Sriganesh Kini 704 Ericsson 706 Email: sriganesh.kini@ericsson.com 708 Hannes Gredler 709 Juniper Networks 711 Email: hannes@juniper.net 713 Mach(Guoyi) Chen 714 Huawei 716 Email: mach.chen@huawei.com