idnits 2.17.1 draft-ietf-mpls-spring-lsp-ping-02.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 (December 1, 2016) is 2703 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-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-10 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-mpls-05 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-ldp-interop-04 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Work group N. Kumar 3 Internet-Draft G. Swallow 4 Intended status: Standards Track C. Pignataro 5 Expires: June 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 December 1, 2016 16 Label Switched Path (LSP) Ping/Trace for Segment Routing Networks Using 17 MPLS Dataplane 18 draft-ietf-mpls-spring-lsp-ping-02 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 June 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . . 6 76 5.2. IPv6 IGP-Prefix Segment ID . . . . . . . . . . . . . . . 6 77 5.3. IGP-Adjacency Segment ID . . . . . . . . . . . . . . . . 7 78 6. Extension to Downstream Detailed Mapping TLV . . . . . . . . 9 79 7. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 9 80 7.1. FECs in Target FEC Stack TLV . . . . . . . . . . . . . . 10 81 7.2. FEC Stack Change sub-TLV . . . . . . . . . . . . . . . . 10 82 7.3. Segment ID POP Operation . . . . . . . . . . . . . . . . 11 83 7.4. Segment ID Check . . . . . . . . . . . . . . . . . . . . 11 84 7.5. TTL Consideration for traceroute . . . . . . . . . . . . 13 85 8. Issues with non-forwarding labels . . . . . . . . . . . . . . 13 86 9. Backward Compatibility with non Segment Routing devices . . . 14 87 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 88 10.1. New Target FEC Stack Sub-TLVs . . . . . . . . . . . . . 14 89 10.2. Protocol in Label Stack Sub-TLV of Downstream Detailed 90 Mapping TLV . . . . . . . . . . . . . . . . . . . . . . 14 91 10.3. Return Code . . . . . . . . . . . . . . . . . . . . . . 15 92 11. Security Considerations . . . . . . . . . . . . . . . . . . . 15 93 12. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 15 94 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15 95 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 96 14.1. Normative References . . . . . . . . . . . . . . . . . . 16 97 14.2. Informative References . . . . . . . . . . . . . . . . . 17 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 100 1. Introduction 102 [I-D.ietf-spring-segment-routing] introduces and explains Segment 103 Routing architecture that leverages the source routing and tunneling 104 paradigms. A node steers a packet through a controlled set of 105 instructions called segments, by prepending the packet with Segment 106 Routing header. A detailed definition about Segment Routing 107 architecture is available in [I-D.ietf-spring-segment-routing] 109 As defined in [I-D.ietf-spring-segment-routing-mpls], the Segment 110 Routing architecture can be directly applied to MPLS data plane in a 111 way that, the Segment identifier (Segment ID) will be of 20-bits size 112 and Segment Routing header is the label stack. 114 "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures" 115 [I-D.ietf-mpls-rfc4379bis] defines a simple and efficient mechanism 116 to detect data plane failures in Label Switched Paths (LSP) by 117 specifying information to be carried in an MPLS "echo request" and 118 "echo reply" for the purposes of fault detection and isolation. 119 Mechanisms for reliably sending the echo reply are defined. The 120 functionality defined in [I-D.ietf-mpls-rfc4379bis] is modeled after 121 the ping/traceroute paradigm (ICMP echo request [RFC0792]) and is 122 typically referred to as LSP ping and LSP traceroute. 123 [I-D.ietf-mpls-rfc4379bis] supports hierarchal and stitching LSPs. 125 Unlike LDP or RSVP which are the other well-known MPLS control plane 126 protocols, segment assignment in Segment Routing architecture is not 127 hop-by-hop basis. 129 This nature of Segment Routing raises additional consideration for 130 fault detection and isolation in Segment Routing network. This 131 document illustrates the problem and describe a mechanism to perform 132 LSP Ping and Traceroute on Segment Routing network over MPLS data 133 plane. 135 2. Requirements notation 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 139 document are to be interpreted as described in [RFC2119]. 141 3. Terminology 143 This document uses the terminologies defined in 144 [I-D.ietf-spring-segment-routing], [I-D.ietf-mpls-rfc4379bis], and so 145 the readers are expected to be familiar with the same. 147 4. Challenges with Existing mechanism 149 This document defines sub-TLVs for the Target FEC Stack TLV and 150 explains how they can be used to tackle below challenges. 152 4.1. Path validation in Segment Routing networks 154 [I-D.ietf-mpls-rfc4379bis] defines the OAM machinery that helps with 155 fault detection and isolation in MPLS dataplane path with the use of 156 various Target FEC Stack Sub-TLV that are carried in MPLS Echo 157 Request packets and used by the responder for FEC validation. While 158 it is obvious that new Sub-TLVs need to be assigned, the unique 159 nature of Segment Routing architecture raises a need for additional 160 machinery for path validation. This section discuss the challenges 161 as below: 163 L1 164 +--------+ 165 | L2 | 166 R3-------R6 167 / \ 168 / \ 169 R1----R2 R7----R8 170 \ / 171 \ / 172 R4-------R5 174 Figure 1: Segment Routing network 176 The Node segment IDs for R1, R2, R3, R4, R5, R6, R7 and R8 are 5001, 177 5002, 5003, 5004, 5005, 5006, 5007, 5008 respectively. 179 9136 --> Adjacency Segment ID from R3 to R6 over link L1. 181 9236 --> Adjacency Segment ID from R3 to R6 over link L2. 183 9124 --> Adjacency segment ID from R2 to R4. 185 9123 --> Adjacency Segment ID from R2 to R3. 187 The forwarding semantic of Adjacency Segment ID is to pop the segment 188 ID and send the packet to a specific neighbor over a specific link. 190 A malfunctioning node may forward packets using Adjacency Segment ID 191 to incorrect neighbor or over incorrect link. Exposed segment ID 192 (after incorrectly forwarded Adjacency Segment ID) might still allow 193 such packet to reach the intended destination, although the intended 194 strict traversal has been broken. 196 Assume in above topology, R1 sends traffic with segment stack as 197 {9124, 5008} so that the path taken will be R1-R2-R4-R5-R7-R8. If 198 the Adjacency Segment ID 9124 is misprogrammed in R2 to send the 199 packet to R1 or R3, it will still be delivered to R8 but is not via 200 the expected path. 202 MPLS traceroute may help with detecting such deviation in above 203 mentioned scenario. However, in a different example, it may not be 204 helpful. For example if R3, due to misprogramming, forwards packet 205 with Adjacency Segment ID 9236 via link L1 while it is expected to be 206 forwarded over Link L2. 208 4.2. Service Label 210 A Segment ID can represent a service based instruction. An Segment 211 Routing header can have label stack entries where the label 212 represents a service to be applied along the path. Since these 213 labels are part of the label stack, they can influence the path taken 214 by a packet and consequently have implications on MPLS OAM. Service 215 Label is left for future study. 217 5. Segment ID sub-TLV 219 The format of the following Segment ID sub-TLVs follows the 220 philosophy of Target FEC Stack TLV carrying FECs corresponding to 221 each label in the label stack. When operated with the procedures 222 defined in [I-D.ietf-mpls-rfc4379bis], this allows LSP ping/ 223 traceroute operations to function when Target FEC Stack TLV contains 224 more FECs than received label stack at responder nodes. 226 Three new sub-TLVs are defined for Target FEC Stack TLVs (Type 1), 227 Reverse-Path Target FEC Stack TLV (Type 16) and Reply Path TLV (Type 228 21). 230 sub-Type Value Field 231 -------- --------------- 232 34 IPv4 IGP-Prefix Segment ID 233 35 IPv6 IGP-Prefix Segment ID 234 36 IGP-Adjacency Segment ID 236 Service Segments and FRR will be considered in future version. 238 5.1. IPv4 IGP-Prefix Segment ID 240 The format is as below: 242 0 1 2 3 243 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 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | IPv4 Prefix | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 |Prefix Length | Protocol | Reserved | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 IPv4 Prefix 252 This field carries the IPv4 prefix to which the Segment ID is 253 assigned. In case of Anycast Segment ID, this field will carry 254 IPv4 Anycast address. If the prefix is shorter than 32 bits, 255 trailing bits SHOULD be set to zero. 257 Prefix Length 259 The Prefix Length field is one octet, it gives the length of the 260 prefix in bits (values can be 1 - 32). 262 Protocol 264 Set to 1 if the IGP protocol is OSPF and 2 if IGP protocol is 265 ISIS. 267 5.2. IPv6 IGP-Prefix Segment ID 269 The format is as below: 271 0 1 2 3 272 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 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | | 275 | IPv6 Prefix | 276 | | 277 | | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 |Prefix Length | Protocol | Reserved | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 IPv6 Prefix 284 This field carries the IPv6 prefix to which the Segment ID is 285 assigned. In case of Anycast Segment ID, this field will carry 286 IPv4 Anycast address. If the prefix is shorter than 128 bits, 287 trailing bits SHOULD be set to zero. 289 Prefix Length 291 The Prefix Length field is one octet, it gives the length of the 292 prefix in bits (values can be 1 - 128). 294 Protocol 296 Set to 1 if the IGP protocol is OSPF and 2 if IGP protocol is 297 ISIS. 299 5.3. IGP-Adjacency Segment ID 301 The format is as below: 303 0 1 2 3 304 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 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | Adj. Type | Protocol | Reserved | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | Local Interface ID (4 or 16 octets) | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | Remote Interface ID (4 or 16 octets) | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 ~ ~ 313 | Advertising Node Identifier (4 or 6 octets) | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 ~ ~ 316 | Receiving Node Identifier (4 or 6 octets) | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 Adj. Type (Adjacency Type) 321 Set to 1, when the Adjacency Segment is Parallel Adjacency as 322 defined in section 3.5.1 of [I-D.ietf-spring-segment-routing]. 323 Set to 4, when the Adjacency segment is IPv4 based and is not a 324 parallel adjacency. Set to 6, when the Adjacency segment is IPv6 325 based and is not a parallel adjacency. 327 Protocol 329 Set to 1 if the IGP protocol is OSPF and 2 if IGP protocol is ISIS 331 Local Interface ID 333 An identifier that is assigned by local LSR for a link on which 334 Adjacency Segment ID is bound. This field is set to local link 335 address (IPv4 or IPv6). Incase of unnumbered, 32 bit link 336 identifier defined in [RFC4203], [RFC5307] is used. If the 337 Adjacency Segment ID represents parallel adjacencies 338 (Section 3.5.1 of [I-D.ietf-spring-segment-routing]) this field 339 MUST be set to zero. 341 Remote Interface ID 343 An identifier that is assigned by remote LSR for a link on which 344 Adjacency Segment ID is bound. This field is set to remote 345 (downstream neighbor) link address (IPv4 or IPv6). In case of 346 unnumbered, 32 bit link identifier defined in [RFC4203], [RFC5307] 347 is used. If the Adjacency Segment ID represents parallel 348 adjacencies (Section 3.5.1 of [I-D.ietf-spring-segment-routing]) 349 this field MUST be set to zero. 351 Advertising Node Identifier 353 Specifies the advertising node identifier. When Protocol is set 354 to 1, then the 32 rightmost bits represent OSPF Router ID and if 355 protocol is set to 2, this field carries 48 bit ISIS System ID. 357 Receiving Node Identifier 359 Specifies the downstream node identifier. When Protocol is set to 360 1, then the 32 rightmost bits represent OSPF Router ID and if 361 protocol is set to 2, this field carries 48 bit ISIS System ID. 363 6. Extension to Downstream Detailed Mapping TLV 365 In an echo reply, the Downstream Detailed Mapping TLV 366 [I-D.ietf-mpls-rfc4379bis] is used to report for each interface over 367 which a FEC could be forwarded. For a FEC, there are multiple 368 protocols that may be used to distribute label mapping. The 369 "Protocol" field of the Downstream Detailed Mapping TLV is used to 370 return the protocol that is used to distribute a specific a label. 371 The following protocols are defined in section 3.4.1.2 of 372 [I-D.ietf-mpls-rfc4379bis]: 374 Protocol # Signaling Protocol 375 ---------- ------------------ 376 0 Unknown 377 1 Static 378 2 BGP 379 3 LDP 380 4 RSVP-TE 382 With segment routing, OSPF or ISIS can be used for label 383 distribution, this document adds two new protocols as follows: 385 Protocol # Signaling Protocol 386 ---------- ------------------ 387 TBD5 OSPF 388 TBD6 ISIS 390 7. Procedures 392 This section describes aspects of LSP Ping and traceroute operations 393 that require further considerations beyond 394 [I-D.ietf-mpls-rfc4379bis]. 396 7.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 have deviating contents. 400 This document outlines expected Target FEC Stack TLV construction 401 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 as defined in section 4.6 of 421 [I-D.ietf-mpls-rfc4379bis]. 423 When a received echo reply does not contain FEC Stack Change 424 TLV, initiator MUST NOT attempt to remove FEC(s) from Target 425 FEC Stack TLV in the next (TTL+1) traceroute request. 427 7.2. FEC Stack Change sub-TLV 429 Section 3.4.1.3 of [I-D.ietf-mpls-rfc4379bis] defines FEC Stack 430 Change sub-TLV that a router must include when the FEC stack changes. 432 The network node which advertised the Node Segment ID is responsible 433 for generating FEC Stack Change sub-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 sub-TLV of &pop& operation for Adjacency Segment ID. 440 7.3. Segment ID POP Operation 442 The forwarding semantic of Node Segment ID with PHP flag is 443 equivalent to usage of implicit Null in MPLS protocols. Adjacency 444 Segment ID is also similar in a sense that it can be thought as next 445 hop destined locally allocated segment that has PHP enabled. 446 Procedures described in Section 4.4 of [I-D.ietf-mpls-rfc4379bis] 447 relies on Stack-D and Stack-R explicitly having Implicit Null value. 448 It may simplify implementations to reuse Implicit Null for Node 449 Segment ID PHP and Adjacency Segment ID cases. 451 7.4. Segment ID Check 453 This section updates the procedure defined in Step 6 of section 4.4. 454 of [I-D.ietf-mpls-rfc4379bis] 456 If the Label-stack-depth is 0 and Target FEC Stack Sub-TLV at FEC- 457 stack-depth is 34 (IPv4 IGP-Prefix Segment ID), the responder 458 should set Best return code to 10, "Mapping for this FEC is not 459 the given label at stack-depth " if any below conditions 460 fail: 462 /* The responder LSR is to check if it is the egress of the IPv4 463 IGP-Prefix Segment ID described in the Target FEC Stack Sub-TLV, 464 and if the FEC was advertised with the PHP bit set.*/ 466 * Validate that Node Segment ID is advertised for IPv4 Prefix. 468 * Validate that Node Segment ID is advertised with No-PHP flag { 470 + When Protocol is OSPF, NP-flag defined in Section 5 of 471 [I-D.ietf-ospf-segment-routing-extensions] should be set to 472 0. 474 + When Protocol is ISIS, P-Flag defined in Section 2.1 of 475 [I-D.ietf-isis-segment-routing-extensions] should be set to 476 0. 478 * } 480 If the Label-stack-depth is more than 0 and Target FEC Stack Sub- 481 TLV at FEC-stack-depth is 34 (IPv4 IGP-Prefix Segment ID), the 482 responder is to set Best return code to 10 if any below conditions 483 fail: 485 * Validate that Node Segment ID is advertised for IPv4 Prefix. 487 If the Label-stack-depth is 0 and Target FEC Sub-TLV at FEC-stack- 488 depth is 35 (IPv6 IGP-Prefix Segment ID), set Best return code to 489 10 if any below conditions fail: 491 /* The LSR needs to check if its being a tail-end for the LSP and 492 have the prefix advertised with PHP bit set*/ 494 * Validate that Node Segment ID is advertised for IPv6 Prefix. 496 * Validate that Node Segment ID is advertised of PHP bit. 498 If the Label-stack-depth is more than 0 and Target FEC Sub-TLV at 499 FEC-stack-depth is 35 (IPv6 IGP-Prefix Segment ID), set Best 500 return code to 10 if any below conditions fail: 502 * Validate that Node Segment ID is advertised for IPv6 Prefix. 504 If the Label-stack-depth is 0 and Target FEC sub-TLV at FEC-stack- 505 depth is 36 (Adjacency Segment ID), set Best return code to TBD7 506 (Section 10.3) if any below conditions fail: 508 When the Adj. Type is 1 (Parallel Adjacency): 510 + Validate that Receiving Node Identifier is local IGP 511 identifier. 513 + Validate that Adjacency Segment ID is advertised by 514 Advertising Node Identifier of Protocol in local IGP 515 database. 517 When the Adj. Type is 4 or 6: 519 + Validate that Remote Interface ID matches the local 520 identifier of the interface (Interface-I) on which the 521 packet was received. 523 + Validate that Receiving Node Identifier is local IGP 524 identifier. 526 + Validate that IGP-Adjacency Segment ID is advertised by 527 Advertising Node Identifier of Protocol in local IGP 528 database. 530 7.5. TTL Consideration for traceroute 532 LSP Traceroute operation can properly traverse every hop of Segment 533 Routing network in Uniform Model described in [RFC3443]. If one or 534 more LSRs employ Short Pipe Model described in [RFC3443], then LSP 535 Traceroute may not be able to properly traverse every hop of Segment 536 Routing network due to absence of TTL copy operation when outer label 537 is popped. Short Pipe being the most commonly used model. The 538 following TTL manipulation technique MAY be used when Short Pipe 539 model is used. 541 When tracing a LSP according to the procedures in 542 [I-D.ietf-mpls-rfc4379bis] the TTL is incremented by one in order to 543 trace the path sequentially along the LSP. However when a source 544 routed LSP has to be traced there are as many TTLs as there are 545 labels in the stack. The LSR that initiates the traceroute SHOULD 546 start by setting the TTL to 1 for the tunnel in the LSP's label stack 547 it wants to start the tracing from, the TTL of all outer labels in 548 the stack to the max value, and the TTL of all the inner labels in 549 the stack to zero. Thus a typical start to the traceroute would have 550 a TTL of 1 for the outermost label and all the inner labels would 551 have TTL 0. If the FEC Stack TLV is included it should contain only 552 those for the inner stacked tunnels. The Return Code/Subcode and FEC 553 Stack Change TLV should be used to diagnose the tunnel as described 554 in [I-D.ietf-mpls-rfc4379bis]. When the tracing of a tunnel in the 555 stack is complete, then the next tunnel in the stack should be 556 traced. The end of a tunnel can be detected from the "Return Code" 557 when it indicates that the responding LSR is an egress for the stack 558 at depth 1. Thus the traceroute procedures in 559 [I-D.ietf-mpls-rfc4379bis] can be recursively applied to traceroute a 560 source routed LSP. 562 8. Issues with non-forwarding labels 564 Source stacking can be optionally used to apply services on the 565 packet at a LSR along the path, where a label in the stack is used to 566 trigger service application. A data plane failure detection and 567 isolation mechanism should provide its functionality without applying 568 these services. This is mandatory for services that are stateful, 569 though for stateless services [I-D.ietf-mpls-rfc4379bis] could be 570 used as-is. It MAY also provide a mechanism to detect and isolate 571 faults within the service function itself. 573 How a node treats Service label is outside the scope of this document 574 and will be included in this or a different document later. 576 9. Backward Compatibility with non Segment Routing devices 578 [I-D.ietf-spring-segment-routing-ldp-interop] describes how Segment 579 Routing operates in network where SR-capable and non-SR-capable nodes 580 coexist. In such networks, there may not be any FEC mapping in the 581 responder when the Initiator is SR-capable while the responder is not 582 (or vice-versa). But this is not different from RSVP and LDP interop 583 scenarios. When LSP Ping is triggered, the responder will set the 584 FEC-return-code to Return 4, "Replying router has no mapping for the 585 FEC at stack-depth". 587 Similarly when SR-capable node assigns Adj-SID for non-SR-capable 588 node, LSP trace may fail as the non-SR-capable node is not aware of 589 "IGP Adjacency Segment ID" sub-TLV and may not reply with FEC Stack 590 change. This may result in any further downstream nodes to reply 591 back with Return-code as 4, "Replying router has no mapping for the 592 FEC at stack-depth". 594 10. IANA Considerations 596 10.1. New Target FEC Stack Sub-TLVs 598 IANA is requested to assign three new sub-TLVs from "Sub-TLVs for TLV 599 Types 1, 16 and 21" sub-registry from the "Multi-Protocol Label 600 Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" 601 [IANA-MPLS-LSP-PING] registry. 603 Sub-Type Sub-TLV Name Reference 604 ---------- ----------------- ------------ 605 34 IPv4 IGP-Prefix Segment ID Section 5.1 (this document) 606 35 IPv6 IGP-Prefix Segment ID Section 5.2 (this document) 607 36 IGP-Adjacency Segment ID Section 5.3 (this document) 609 10.2. Protocol in Label Stack Sub-TLV of Downstream Detailed Mapping 610 TLV 612 IANA is requested to create a new "Protocol" registry under the Label 613 Stack Sub-TLV of the Downstream Detailed Mapping TLV in the "Multi- 614 Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping 615 Parameters" registry [IANA-MPLS-LSP-PING]. 617 Value Meaning Reference 618 ------ ---------- ------------ 619 0 Unknown Section 3.4.2.1 [I-D.ietf-mpls-rfc4379bis] 620 1 Static Section 3.4.2.1 [I-D.ietf-mpls-rfc4379bis] 621 2 BGP Section 3.4.2.1 [I-D.ietf-mpls-rfc4379bis] 622 3 LDP Section 3.4.2.1 [I-D.ietf-mpls-rfc4379bis] 623 4 RSVP-TE Section 3.4.2.1 [I-D.ietf-mpls-rfc4379bis] 624 TBD5 OSPF Section 6 (this document) 625 TBD6 ISIS Section 6 (this document) 627 10.3. Return Code 629 IANA is requested to assign a new Return Code from the "Multi- 630 Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping 631 Parameters" [IANA-MPLS-LSP-PING] in "Return Codes" Sub-registry. 633 Value Meaning Reference 634 ------- ----------------- ------------ 635 TBD7 Mapping for this FEC is not associated Section 7.4 636 with the incoming interface (this document) 638 11. Security Considerations 640 This document defines additional Sub-TLVs and follows the mechanism 641 defined in [I-D.ietf-mpls-rfc4379bis]. So all the security 642 consideration defined in [I-D.ietf-mpls-rfc4379bis] will be 643 applicable for this document and in addition it does not impose any 644 security challenges to be considered. 646 12. Acknowledgement 648 The authors would like to thank Stefano Previdi, Les Ginsberg, Balaji 649 Rajagopalan, Harish Sitaraman, Curtis Villamizar, Pranjal Dutta, 650 Lizhong Jin, Tom Petch, and Mustapha Aissaoui for their review and 651 comments. 653 The authors wold like to thank Loa Andersson for his comments and 654 recommendation to merge drafts. 656 13. Contributors 658 The following are key contributors to this document: 660 Tarek Saad, Cisco Systems, Inc. 661 Siva Sivabalan, Cisco Systems, Inc. 662 Balaji Rajagopalan, Juniper Networks 663 Faisal Iqbal, Cisco Systems, Inc. 665 14. References 667 14.1. Normative References 669 [I-D.ietf-isis-segment-routing-extensions] 670 Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., 671 Litkowski, S., Decraene, B., and j. jefftant@gmail.com, 672 "IS-IS Extensions for Segment Routing", draft-ietf-isis- 673 segment-routing-extensions-09 (work in progress), October 674 2016. 676 [I-D.ietf-mpls-rfc4379bis] 677 Kompella, K., Swallow, G., Pignataro, C., Kumar, N., 678 Aldrin, S., and M. Chen, "Detecting Multi-Protocol Label 679 Switched (MPLS) Data Plane Failures", draft-ietf-mpls- 680 rfc4379bis-09 (work in progress), October 2016. 682 [I-D.ietf-ospf-segment-routing-extensions] 683 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 684 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 685 Extensions for Segment Routing", draft-ietf-ospf-segment- 686 routing-extensions-10 (work in progress), October 2016. 688 [I-D.ietf-spring-segment-routing] 689 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 690 and R. Shakir, "Segment Routing Architecture", draft-ietf- 691 spring-segment-routing-10 (work in progress), November 692 2016. 694 [I-D.ietf-spring-segment-routing-mpls] 695 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 696 Litkowski, S., Horneffer, M., Shakir, R., 697 jefftant@gmail.com, j., and E. Crabbe, "Segment Routing 698 with MPLS data plane", draft-ietf-spring-segment-routing- 699 mpls-05 (work in progress), July 2016. 701 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 702 Requirement Levels", BCP 14, RFC 2119, 703 DOI 10.17487/RFC2119, March 1997, 704 . 706 [RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing 707 in Multi-Protocol Label Switching (MPLS) Networks", 708 RFC 3443, DOI 10.17487/RFC3443, January 2003, 709 . 711 [RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in 712 Support of Generalized Multi-Protocol Label Switching 713 (GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005, 714 . 716 [RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions 717 in Support of Generalized Multi-Protocol Label Switching 718 (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008, 719 . 721 14.2. Informative References 723 [I-D.ietf-spring-segment-routing-ldp-interop] 724 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., and 725 S. Litkowski, "Segment Routing interworking with LDP", 726 draft-ietf-spring-segment-routing-ldp-interop-04 (work in 727 progress), July 2016. 729 [IANA-MPLS-LSP-PING] 730 IANA, "Multi-Protocol Label Switching (MPLS) Label 731 Switched Paths (LSPs) Ping Parameters", 732 . 735 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 736 RFC 792, DOI 10.17487/RFC0792, September 1981, 737 . 739 Authors' Addresses 741 Nagendra Kumar 742 Cisco Systems, Inc. 743 7200 Kit Creek Road 744 Research Triangle Park, NC 27709 745 US 747 Email: naikumar@cisco.com 749 George Swallow 750 Cisco Systems, Inc. 751 1414 Massachusetts Ave 752 Boxborough, MA 01719 753 US 755 Email: swallow@cisco.com 756 Carlos Pignataro 757 Cisco Systems, Inc. 758 7200 Kit Creek Road 759 Research Triangle Park, NC 27709-4987 760 US 762 Email: cpignata@cisco.com 764 Nobo Akiya 765 Big Switch Networks 767 Email: nobo.akiya.dev@gmail.com 769 Sriganesh Kini 770 Individual 772 Email: sriganeshkini@gmail.com 774 Hannes Gredler 775 Juniper Networks 777 Email: hannes@juniper.net 779 Mach(Guoyi) Chen 780 Huawei 782 Email: mach.chen@huawei.com