idnits 2.17.1 draft-ietf-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 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 (October 31, 2016) is 2733 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 698, but no explicit reference was found in the text == Unused Reference: 'RFC6425' is defined on line 704, but no explicit reference was found in the text == Outdated reference: A later version (-25) exists of draft-ietf-isis-segment-routing-extensions-09 == Outdated reference: A later version (-27) exists of draft-ietf-ospf-segment-routing-extensions-10 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-09 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-ldp-interop-04 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-mpls-05 ** Obsolete normative reference: RFC 4379 (Obsoleted by RFC 8029) ** Obsolete normative reference: RFC 6424 (Obsoleted by RFC 8029) Summary: 3 errors (**), 0 flaws (~~), 8 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: May 4, 2017 Cisco Systems, Inc. 6 N. Akiya 7 Big Switch Networks 8 S. Kini 9 Individual 10 H. Gredler 11 Juniper Networks 12 M. Chen 13 Huawei 14 October 31, 2016 16 Label Switched Path (LSP) Ping/Trace for Segment Routing Networks Using 17 MPLS Dataplane 18 draft-ietf-mpls-spring-lsp-ping-01 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 May 4, 2017. 51 Copyright Notice 53 Copyright (c) 2016 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 IGP-Prefix Segment ID . . . . . . . . . . . . . . . 5 76 5.2. IPv6 IGP-Prefix 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 . . . . . . . . . . . . . . 13 86 9. Backward Compatibility with non Segment Routing devices . . . 13 87 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 88 10.1. New Target FEC Stack Sub-TLVs . . . . . . . . . . . . . 13 89 11. Security Considerations . . . . . . . . . . . . . . . . . . . 14 90 12. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 14 91 13. Contributing Authors . . . . . . . . . . . . . . . . . . . . 14 92 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 93 14.1. Normative References . . . . . . . . . . . . . . . . . . 14 94 14.2. Informative References . . . . . . . . . . . . . . . . . 16 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 97 1. Introduction 99 [I-D.ietf-spring-segment-routing] introduces and explains Segment 100 Routing architecture that leverages the source routing and tunneling 101 paradigms. A node steers a packet through a controlled set of 102 instructions called segments, by prepending the packet with Segment 103 Routing header. A detailed definition about Segment Routing 104 architecture is available in [I-D.ietf-spring-segment-routing] 106 As defined in [I-D.ietf-spring-segment-routing-mpls], the Segment 107 Routing architecture can be directly applied to MPLS data plane in a 108 way that, the Segment identifier (Segment ID) will be of 20-bits size 109 and Segment Routing header is the label stack. 111 "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures" 112 [RFC4379] defines a simple and efficient mechanism to detect data 113 plane failures in Label Switched Paths (LSP) by specifying 114 information to be carried in an MPLS "echo request" and "echo reply" 115 for the purposes of fault detection and isolation. Mechanisms for 116 reliably sending the echo reply are defined. The functionality 117 defined in [RFC4379]is modeled after the ping/traceroute paradigm 118 (ICMP echo request [RFC0792]) and is typically referred to as LSP 119 ping and LSP traceroute. [RFC6424] updates [RFC4379] to support 120 hierarchal and stitching LSPs. 122 Unlike LDP or RSVP which are the other well-known MPLS control plane 123 protocols, segment assignment in Segment Routing architecture is not 124 hop-by-hop basis. 126 This nature of Segment Routing raises additional consideration for 127 fault detection and isolation in Segment Routing network. This 128 document illustrates the problem and describe a mechanism to perform 129 LSP Ping and Traceroute on Segment Routing network over MPLS data 130 plane. 132 2. Requirements notation 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 136 document are to be interpreted as described in [RFC2119]. 138 3. Terminology 140 This document uses the terminologies defined in 141 [I-D.ietf-spring-segment-routing], [RFC4379], and so the readers are 142 expected to be familiar with the same. 144 4. Challenges with Existing mechanism 146 This document defines sub-TLVs for the Target FEC Stack TLV and 147 explains how they can be used to tackle below challenges. 149 4.1. Path validation in Segment Routing networks 151 [RFC4379] defines the OAM machinery that helps with fault detection 152 and isolation in MPLS dataplane path with the use of various Target 153 FEC Stack Sub-TLV that are carried in MPLS Echo Request packets and 154 used by the responder for FEC validation. While it is obvious that 155 new Sub-TLVs need to be assigned, the unique nature of Segment 156 Routing architecture raises a need for additional machinery for path 157 validation. This section discuss the challenges as below: 159 L1 160 +--------+ 161 | L2 | 162 R3-------R6 163 / \ 164 / \ 165 R1----R2 R7----R8 166 \ / 167 \ / 168 R4-------R5 170 Figure 1: Segment Routing network 172 The Node segment IDs for R1, R2, R3, R4, R5, R6, R7 and R8 are 5001, 5002, 5003, 5004, 5005, 5006, 5007, 5008 respectively. 174 9136 --> Adjacency Segment ID from R3 to R6 over link L1. 175 9236 --> Adjacency Segment ID from R3 to R6 over link L2. 176 9124 --> Adjacency segment ID from R2 to R4. 177 9123 --> Adjacency Segment ID from R2 to R3. 179 The forwarding semantic of Adjacency Segment ID is to pop the segment 180 ID and send the packet to a specific neighbor over a specific link. 181 A malfunctioning node may forward packets using Adjacency Segment ID 182 to incorrect neighbor or over incorrect link. Exposed segment ID 183 (after incorrectly forwarded Adjacency Segment ID) might still allow 184 such packet to reach the intended destination, although the intended 185 strict traversal has been broken. 187 Assume in above topology, R1 sends traffic with segment stack as 188 {9124, 5008} so that the path taken will be R1-R2-R4-R5-R7-R8. If 189 the Adjacency Segment ID 9124 is misprogrammed in R2 to send the 190 packet to R1 or R3, it will still be delivered to R8 but is not via 191 the expected path. 193 MPLS traceroute may help with detecting such deviation in above 194 mentioned scenario. However, in a different example, it may not be 195 helpful. For example if R3, due to misprogramming, forwards packet 196 with Adjacency Segment ID 9236 via link L1 while it is expected to be 197 forwarded over Link L2. 199 4.2. Service Label 201 A Segment ID can represent a service based instruction. An Segment 202 Routing header can have label stack entries where the label 203 represents a service to be applied along the path. Since these 204 labels are part of the label stack, they can influence the path taken 205 by a packet and consequently have implications on MPLS OAM. Service 206 Label is left for future study. 208 5. Segment ID sub-TLV 210 The format of the following Segment ID sub-TLVs follows the 211 philosophy of Target FEC Stack TLV carrying FECs corresponding to 212 each label in the label stack. When operated with the procedures 213 defined in [RFC4379], this allows LSP ping/traceroute operations to 214 function when Target FEC Stack TLV contains more FECs than received 215 label stack at responder nodes. 217 Three new sub-TLVs are defined for Target FEC Stack TLVs (Type 1), 218 Reverse-Path Target FEC Stack TLV (Type 16) and Reply Path TLV (Type 219 21). 221 sub-Type Value Field 222 -------- --------------- 223 34 IPv4 IGP-Prefix Segment ID 224 35 IPv6 IGP-Prefix Segment ID 225 36 IGP-Adjacency Segment ID 227 Service Segments and FRR will be considered in future version. 229 5.1. IPv4 IGP-Prefix Segment ID 231 The format is as below: 233 0 1 2 3 234 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 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | IPv4 Prefix | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 |Prefix Length | Protocol | Reserved | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 IPv4 Prefix 243 This field carries the IPv4 prefix to which the Segment ID is 244 assigned. In case of Anycast Segment ID, this field will carry 245 IPv4 Anycast address. If the prefix is shorter than 32 bits, 246 trailing bits SHOULD be set to zero. 248 Prefix Length 250 The Prefix Length field is one octet, it gives the length of the 251 prefix in bits (values can be 1 - 32). 253 Protocol 255 Set to 1 if the IGP protocol is OSPF and 2 if IGP protocol is 256 ISIS. 258 5.2. IPv6 IGP-Prefix Segment ID 260 The format is as below: 262 0 1 2 3 263 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 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | | 266 | IPv6 Prefix | 267 | | 268 | | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 |Prefix Length | Protocol | Reserved | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 IPv6 Prefix 274 This field carries the IPv6 prefix to which the Segment ID is 275 assigned. In case of Anycast Segment ID, this field will carry 276 IPv4 Anycast address. If the prefix is shorter than 128 bits, 277 trailing bits SHOULD be set to zero. 279 Prefix Length 281 The Prefix Length field is one octet, it gives the length of the 282 prefix in bits (values can be 1 - 128). 284 Protocol 286 Set to 1 if the IGP protocol is OSPF and 2 if IGP protocol is 287 ISIS. 289 5.3. IGP-Adjacency Segment ID 291 The format is as below: 293 0 1 2 3 294 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 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | Adj. Type | Protocol | Reserved | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | Local Interface ID (4 or 16 octets) | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | Remote Interface ID (4 or 16 octets) | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 ~ ~ 303 | Advertising Node Identifier (4 or 6 octets) | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 ~ ~ 306 | Receiving Node Identifier (4 or 6 octets) | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 Adj. Type (Adjacency Type) 311 Set to 1, when the Adjacency Segment is Parallel Adjacency as 312 defined in section 3.5.1 of [I-D.ietf-spring-segment-routing]. 313 Set to 4, when the Adjacency segment is IPv4 based and is not a 314 parallel adjacency. Set to 6, when the Adjacency segment is IPv6 315 based and is not a parallel adjacency. 317 Protocol 319 Set to 1 if the IGP protocol is OSPF and 2 if IGP protocol is ISIS 321 Local Interface ID 323 An identifier that is assigned by local LSR for a link on which 324 Adjacency Segment ID is bound. This field is set to local link 325 address (IPv4 or IPv6). Incase of unnumbered, 32 bit link 326 identifier defined in [RFC4203], [RFC5307] is used. If the 327 Adjacency Segment ID represents parallel adjacencies 328 (Section 3.5.1 of [I-D.ietf-spring-segment-routing]) this field 329 MUST be set to zero. 331 Remote Interface ID 333 An identifier that is assigned by remote LSR for a link on which 334 Adjacency Segment ID is bound. This field is set to remote 335 (downstream neighbor) link address (IPv4 or IPv6). In case of 336 unnumbered, 32 bit link identifier defined in [RFC4203], [RFC5307] 337 is used. If the Adjacency Segment ID represents parallel 338 adjacencies (Section 3.5.1 of [I-D.ietf-spring-segment-routing]) 339 this field MUST be set to zero. 341 Advertising Node Identifier 343 Specifies the advertising node identifier. When Protocol is set 344 to 1, then the 32 rightmost bits represent OSPF Router ID and if 345 protocol is set to 2, this field carries 48 bit ISIS System ID. 347 Receiving Node Identifier 349 Specifies the downstream node identifier. When Protocol is set to 350 1, then the 32 rightmost bits represent OSPF Router ID and if 351 protocol is set to 2, this field carries 48 bit ISIS System ID. 353 6. Extension to Downstream Mapping TLV 355 In an echo reply, the Downstream Mapping TLV [RFC4379] is used to 356 report for each interface over which a FEC could be forwarded. For a 357 FEC, there are multiple protocols that may be used to distribute 358 label mapping. The "Protocol" field of the Downstream Mapping TLV is 359 used to return the protocol that is used to distribute a specific a 360 label. The following protocols are defined in section 3.2 of 361 [RFC4379]: 363 Protocol # Signaling Protocol 364 ---------- ------------------ 365 0 Unknown 366 1 Static 367 2 BGP 368 3 LDP 369 4 RSVP-TE 371 With segment routing, OSPF or ISIS can be used for label 372 distribution, this document adds two new protocols as follows: 374 Protocol # Signaling Protocol 375 ---------- ------------------ 376 TBD5 OSPF 377 TBD6 ISIS 379 7. Procedures 381 This section describes aspects of LSP Ping and traceroute operations 382 that require further considerations beyond [RFC4379]. 384 7.1. FECs in Target FEC Stack TLV 386 When LSP echo request packets are generated by an initiator, FECs 387 carried in Target FEC Stack TLV may need to have deviating contents. 388 This document outlines expected Target FEC Stack TLV construction 389 mechanics by initiator for known scenarios. 391 Ping 393 Initiator MUST include FEC(s) corresponding to the destination 394 segment. 396 Initiator MAY include FECs corresponding to some or all of 397 segments imposed in the label stack by the initiator to 398 communicate the segments traversed. 400 Traceroute 402 Initiator MUST initially include FECs corresponding to all of 403 segments imposed in the label stack. 405 When a received echo reply contains FEC Stack Change TLV with 406 one or more of original segment(s) being popped, initiator MAY 407 remove corresponding FEC(s) from Target FEC Stack TLV in the 408 next (TTL+1) traceroute request as defined in section 4.3.1.2 409 of [RFC6424]. 411 When a received echo reply does not contain FEC Stack Change 412 TLV, initiator MUST NOT attempt to remove FEC(s) from Target 413 FEC Stack TLV in the next (TTL+1) traceroute request. 415 7.2. FEC Stack Change sub-TLV 417 Section 3.3.1.3 of [RFC6424] defines FEC Stack Change sub-TLV that a 418 router must 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. 439 7.4. Segment ID Check 441 This section updates the procedure defined in Step 6 of section 4.4. 442 of [RFC4379] 444 If the Label-stack-depth is 0 and Target FEC Stack Sub-TLV at FEC- 445 stack-depth is 34 (IPv4 IGP-Prefix Segment ID), the responder 446 should set Best return code to 10, "Mapping for this FEC is not 447 the given label at stack-depth " if any below conditions 448 fail: 450 /* The responder LSR is to check if it is the egress of the IPv4 451 IGP-Prefix Segment ID described in the Target FEC Stack Sub-TLV, 452 and if the FEC was advertised with the PHP bit set.*/ 454 * Validate that Node Segment ID is advertised for IPv4 Prefix. 456 * Validate that Node Segment ID is advertised with No-PHP flag { 457 + When Protocol is OSPF, NP-flag defined in Section 5 of 458 [I-D.ietf-ospf-segment-routing-extensions] should be set to 459 0. 461 + When Protocol is ISIS, P-Flag defined in Section 2.1 of 462 [I-D.ietf-isis-segment-routing-extensions] should be set to 463 0. 465 * } 467 If the Label-stack-depth is more than 0 and Target FEC Stack Sub- 468 TLV at FEC-stack-depth is 34 (IPv4 IGP-Prefix Segment ID), the 469 responder is to set Best return code to 10 if any below conditions 470 fail: 472 * Validate that Node Segment ID is advertised for IPv4 Prefix. 474 If the Label-stack-depth is 0 and Target FEC Sub-TLV at FEC-stack- 475 depth is 35 (IPv6 IGP-Prefix Segment ID), set Best return code to 476 10 if any below conditions fail: 478 /* The LSR needs to check if its being a tail-end for the LSP and 479 have the prefix advertised with PHP bit set*/ 481 * Validate that Node Segment ID is advertised for IPv6 Prefix. 483 * Validate that Node Segment ID is advertised of PHP bit. 485 If the Label-stack-depth is more than 0 and Target FEC Sub-TLV at 486 FEC-stack-depth is 35 (IPv6 IGP-Prefix Segment ID), set Best 487 return code to 10 if any below conditions fail: 489 * Validate that Node Segment ID is advertised for IPv6 Prefix. 491 If the Label-stack-depth is 0 and Target FEC sub-TLV at FEC-stack- 492 depth is 36 (Adjacency Segment ID), set Best return code to (error 493 code TBD) if any below conditions fail: 495 When the Adj. Type is 1 (Parallel Adjacency): 497 + Validate that Receiving Node Identifier is local IGP 498 identifier. 500 + Validate that Adjacency Segment ID is advertised by 501 Advertising Node Identifier of Protocol in local IGP 502 database. 504 When the Adj. Type is 4 or 6: 506 + Validate that Remote Interface ID matches the local 507 identifier of the interface (Interface-I) on which the 508 packet was received. 510 + Validate that Receiving Node Identifier is local IGP 511 identifier. 513 + Validate that IGP-Adjacency Segment ID is advertised by 514 Advertising Node Identifier of Protocol in local IGP 515 database. 517 7.5. TTL Consideration for traceroute 519 LSP Traceroute operation can properly traverse every hop of Segment 520 Routing network in Uniform Model described in [RFC3443]. If one or 521 more LSRs employ Short Pipe Model described in [RFC3443], then LSP 522 Traceroute may not be able to properly traverse every hop of Segment 523 Routing network due to absence of TTL copy operation when outer label 524 is popped. Short Pipe being the most commonly used model. The 525 following TTL manipulation technique MAY be used when Short Pipe 526 model is used. 528 When tracing a LSP according to the procedures in [RFC4379] the TTL 529 is incremented by one in order to trace the path sequentially along 530 the LSP. However when a source routed LSP has to be traced there are 531 as many TTLs as there are labels in the stack. The LSR that 532 initiates the traceroute SHOULD start by setting the TTL to 1 for the 533 tunnel in the LSP's label stack it wants to start the tracing from, 534 the TTL of all outer labels in the stack to the max value, and the 535 TTL of all the inner labels in the stack to zero. Thus a typical 536 start to the traceroute would have a TTL of 1 for the outermost label 537 and all the inner labels would have TTL 0. If the FEC Stack TLV is 538 included it should contain only those for the inner stacked tunnels. 539 The Return Code/Subcode and FEC Stack Change TLV should be used to 540 diagnose the tunnel as described in [RFC4379] and [RFC6424]. When 541 the tracing of a tunnel in the stack is complete, then the next 542 tunnel in the stack should be traced. The end of a tunnel can be 543 detected from the "Return Code" when it indicates that the responding 544 LSR is an egress for the stack at depth 1. Thus the traceroute 545 procedures in [RFC4379] can be recursively applied to traceroute a 546 source routed LSP. 548 8. Issues with non-forwarding labels 550 Source stacking can be optionally used to apply services on the 551 packet at a LSR along the path, where a label in the stack is used to 552 trigger service application. A data plane failure detection and 553 isolation mechanism should provide its functionality without applying 554 these services. This is mandatory for services that are stateful, 555 though for stateless services [RFC4379] could be used as-is. It MAY 556 also provide a mechanism to detect and isolate faults within the 557 service function itself. 559 How a node treats Service label is outside the scope of this document 560 and will be included in this or a different document later. 562 9. Backward Compatibility with non Segment Routing devices 564 [I-D.ietf-spring-segment-routing-ldp-interop] describes how Segment 565 Routing operates in network where SR-capable and non-SR-capable nodes 566 coexist. In such networks, there may not be any FEC mapping in the 567 responder when the Initiator is SR-capable while the responder is not 568 (or vice-versa). But this is not different from RSVP and LDP interop 569 scenarios. When LSP Ping is triggered, the responder will set the 570 FEC-return-code to Return 4, "Replying router has no mapping for the 571 FEC at stack-depth". 573 Similarly when SR-capable node assigns Adj-SID for non-SR-capable 574 node, LSP trace may fail as the non-SR-capable node is not aware of 575 "IGP Adjacency Segment ID" sub-TLV and may not reply with FEC Stack 576 change. This may result in any further downstream nodes to reply 577 back with Return-code as 4, "Replying router has no mapping for the 578 FEC at stack-depth". 580 10. IANA Considerations 582 10.1. New Target FEC Stack Sub-TLVs 584 IANA is requested to assign 3 new Sub-TLVs from "Sub-TLVs for TLV 585 Types 1, 16 and 21" sub-registry. 587 Sub-Type Sub-TLV Name Reference 588 ---------- ----------------- ------------ 589 34 IPv4 IGP-Prefix Segment ID Section 4.1 (this document) 590 35 IPv6 IGP-Prefix Segment ID Section 4.2 (this document) 591 36 IGP-Adjacency Segment ID Section 4.3 (this document) 593 11. Security Considerations 595 This document defines additional Sub-TLVs and follows the mechanism 596 defined in [RFC4379]. So all the security consideration defined in 597 [RFC4379] will be applicable for this document and in addition it 598 does not impose any security challenges to be considered. 600 12. Acknowledgement 602 The authors would like to thank Stefano Previdi, Les Ginsberg, Balaji 603 Rajagopalan, Harish Sitaraman, Curtis Villamizar, Pranjal Dutta and 604 Lizhong Jin for their review and comments. 606 The authors wold like to thank Loa Andersson for his comments and 607 recommendation to merge drafts. 609 13. Contributing Authors 611 Tarek Saad 612 Cisco Systems 613 Email: tsaad@cisco.com 615 Siva Sivabalan 616 Cisco Systems 617 Email: msiva@cisco.com 619 Balaji Rajagopalan 620 Juniper Networks 621 Email: balajir@juniper.net 623 Faisal Iqbal 624 Cisco Systems 625 Email: faiqbal@cisco.com 627 14. References 629 14.1. Normative References 631 [I-D.ietf-isis-segment-routing-extensions] 632 Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., 633 Litkowski, S., Decraene, B., and j. jefftant@gmail.com, 634 "IS-IS Extensions for Segment Routing", draft-ietf-isis- 635 segment-routing-extensions-09 (work in progress), October 636 2016. 638 [I-D.ietf-ospf-segment-routing-extensions] 639 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 640 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 641 Extensions for Segment Routing", draft-ietf-ospf-segment- 642 routing-extensions-10 (work in progress), October 2016. 644 [I-D.ietf-spring-segment-routing] 645 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 646 and R. Shakir, "Segment Routing Architecture", draft-ietf- 647 spring-segment-routing-09 (work in progress), July 2016. 649 [I-D.ietf-spring-segment-routing-ldp-interop] 650 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., and 651 S. Litkowski, "Segment Routing interworking with LDP", 652 draft-ietf-spring-segment-routing-ldp-interop-04 (work in 653 progress), July 2016. 655 [I-D.ietf-spring-segment-routing-mpls] 656 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 657 Litkowski, S., Horneffer, M., Shakir, R., 658 jefftant@gmail.com, j., and E. Crabbe, "Segment Routing 659 with MPLS data plane", draft-ietf-spring-segment-routing- 660 mpls-05 (work in progress), July 2016. 662 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 663 RFC 792, DOI 10.17487/RFC0792, September 1981, 664 . 666 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 667 Requirement Levels", BCP 14, RFC 2119, 668 DOI 10.17487/RFC2119, March 1997, 669 . 671 [RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing 672 in Multi-Protocol Label Switching (MPLS) Networks", 673 RFC 3443, DOI 10.17487/RFC3443, January 2003, 674 . 676 [RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in 677 Support of Generalized Multi-Protocol Label Switching 678 (GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005, 679 . 681 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 682 Label Switched (MPLS) Data Plane Failures", RFC 4379, 683 DOI 10.17487/RFC4379, February 2006, 684 . 686 [RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions 687 in Support of Generalized Multi-Protocol Label Switching 688 (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008, 689 . 691 [RFC6424] Bahadur, N., Kompella, K., and G. Swallow, "Mechanism for 692 Performing Label Switched Path Ping (LSP Ping) over MPLS 693 Tunnels", RFC 6424, DOI 10.17487/RFC6424, November 2011, 694 . 696 14.2. Informative References 698 [RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, 699 D., and S. Mansfield, "Guidelines for the Use of the "OAM" 700 Acronym in the IETF", BCP 161, RFC 6291, 701 DOI 10.17487/RFC6291, June 2011, 702 . 704 [RFC6425] Saxena, S., Ed., Swallow, G., Ali, Z., Farrel, A., 705 Yasukawa, S., and T. Nadeau, "Detecting Data-Plane 706 Failures in Point-to-Multipoint MPLS - Extensions to LSP 707 Ping", RFC 6425, DOI 10.17487/RFC6425, November 2011, 708 . 710 Authors' Addresses 712 Nagendra Kumar 713 Cisco Systems, Inc. 714 7200 Kit Creek Road 715 Research Triangle Park, NC 27709 716 US 718 Email: naikumar@cisco.com 720 George Swallow 721 Cisco Systems, Inc. 722 1414 Massachusetts Ave 723 Boxborough, MA 01719 724 US 726 Email: swallow@cisco.com 727 Carlos Pignataro 728 Cisco Systems, Inc. 729 7200 Kit Creek Road 730 Research Triangle Park, NC 27709-4987 731 US 733 Email: cpignata@cisco.com 735 Nobo Akiya 736 Big Switch Networks 738 Email: nobo.akiya.dev@gmail.com 740 Sriganesh Kini 741 Individual 743 Email: sriganeshkini@gmail.com 745 Hannes Gredler 746 Juniper Networks 748 Email: hannes@juniper.net 750 Mach(Guoyi) Chen 751 Huawei 753 Email: mach.chen@huawei.com