idnits 2.17.1 draft-ietf-mpls-spring-lsp-ping-07.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 (September 19, 2017) is 2401 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 (-15) exists of draft-ietf-spring-segment-routing-12 == Outdated reference: A later version (-25) exists of draft-ietf-isis-segment-routing-extensions-13 == Outdated reference: A later version (-27) exists of draft-ietf-ospf-segment-routing-extensions-19 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-ldp-interop-08 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-mpls-10 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, Ed. 3 Internet-Draft C. Pignataro, Ed. 4 Intended status: Standards Track Cisco 5 Expires: March 23, 2018 G. Swallow 6 Southend Technical Center 7 N. Akiya 8 Big Switch Networks 9 S. Kini 10 Individual 11 M. Chen 12 Huawei 13 September 19, 2017 15 Label Switched Path (LSP) Ping/Traceroute for Segment Routing IGP Prefix 16 and Adjacency SIDs with MPLS Data-plane 17 draft-ietf-mpls-spring-lsp-ping-07 19 Abstract 21 Segment Routing architecture leverages the source routing and 22 tunneling paradigms and can be directly applied to MPLS data plane. 23 A node steers a packet through a controlled set of instructions 24 called segments, by prepending the packet with a Segment Routing 25 header. 27 The segment assignment and forwarding semantic nature of Segment 28 Routing raises additional consideration for connectivity verification 29 and fault isolation in LSP with Segment Routing architecture. This 30 document illustrates the problem and describe a mechanism to perform 31 LSP Ping and Traceroute on Segment Routing network over MPLS data 32 plane. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on March 23, 2018. 50 Copyright Notice 52 Copyright (c) 2017 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 69 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 4. Challenges with Existing mechanism . . . . . . . . . . . . . 4 71 4.1. Path validation in Segment Routing networks . . . . . . . 4 72 5. Segment ID sub-TLV . . . . . . . . . . . . . . . . . . . . . 5 73 5.1. IPv4 IGP-Prefix Segment ID . . . . . . . . . . . . . . . 5 74 5.2. IPv6 IGP-Prefix Segment ID . . . . . . . . . . . . . . . 6 75 5.3. IGP-Adjacency Segment ID . . . . . . . . . . . . . . . . 7 76 6. Extension to Downstream Detailed Mapping TLV . . . . . . . . 8 77 7. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 9 78 7.1. FECs in Target FEC Stack TLV . . . . . . . . . . . . . . 9 79 7.2. FEC Stack Change sub-TLV . . . . . . . . . . . . . . . . 10 80 7.3. Segment ID POP Operation . . . . . . . . . . . . . . . . 10 81 7.4. Segment ID Check . . . . . . . . . . . . . . . . . . . . 10 82 7.5. TTL Consideration for traceroute . . . . . . . . . . . . 14 83 8. Backward Compatibility with non Segment Routing devices . . . 15 84 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 85 9.1. New Target FEC Stack Sub-TLVs . . . . . . . . . . . . . . 15 86 9.2. Protocol in Label Stack Sub-TLV of Downstream Detailed 87 Mapping TLV . . . . . . . . . . . . . . . . . . . . . . . 15 88 9.3. Return Code . . . . . . . . . . . . . . . . . . . . . . . 16 89 10. Security Considerations . . . . . . . . . . . . . . . . . . . 16 90 11. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 16 91 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17 92 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 93 13.1. Normative References . . . . . . . . . . . . . . . . . . 17 94 13.2. Informative References . . . . . . . . . . . . . . . . . 18 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 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] and 107 [I-D.ietf-spring-segment-routing-mpls], the Segment Routing 108 architecture can be directly applied to MPLS data plane in a way 109 that, the Segment identifier (Segment ID) will be of 20-bits size and 110 Segment Routing header is the label stack. 112 "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures" 113 [RFC8029] defines a simple and efficient mechanism to detect data 114 plane failures in Label Switched Paths (LSP) by specifying 115 information to be carried in an MPLS "echo request" and "echo reply" 116 for the purposes of fault detection and isolation. Mechanisms for 117 reliably sending the echo reply are defined. The functionality 118 defined in [RFC8029] is modeled after the ping/traceroute paradigm 119 (ICMP echo request [RFC0792]) and is typically referred to as LSP 120 ping and LSP traceroute. [RFC8029] supports hierarchical and 121 stitching LSPs. 123 Unlike LDP or RSVP which are the other well-known MPLS control plane 124 protocols, the basis of segment ID assignment in Segment Routing 125 architecture is not always on hop-by-hop basis. Depending on the 126 type of segment ID, the assignment can be unique to the node or 127 within a domain. 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 describes 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], [RFC8029], and so the readers are 145 expected to be familiar with the same. 147 4. Challenges with Existing mechanism 149 This document defines sub-TLVs for the Target Forwarding Equivalence 150 Class (FEC) Stack TLV and explains how they can be used to tackle 151 below challenges. 153 4.1. Path validation in Segment Routing networks 155 [RFC8029] defines the OAM machinery that helps with fault detection 156 and isolation in MPLS data-plane path with the use of various Target 157 FEC Stack Sub-TLV that are carried in MPLS Echo Request packets and 158 used by the responder for FEC validation. While it is obvious that 159 new Sub-TLVs need to be assigned, the unique nature of Segment 160 Routing architecture raises a need for additional machinery for path 161 validation. This section discusses the challenges 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. 180 9236 --> Adjacency Segment ID from R3 to R6 over link L2. 181 9124 --> Adjacency segment ID from R2 to R4. 182 9123 --> Adjacency Segment ID from R2 to R3. 184 The forwarding semantic of Adjacency Segment ID is to pop the segment 185 ID and send the packet to a specific neighbor over a specific link. 186 A malfunctioning node may forward packets using Adjacency Segment ID 187 to incorrect neighbor or over incorrect link. Exposed segment ID 188 (after incorrectly forwarded Adjacency Segment ID) might still allow 189 such packet to reach the intended destination, although the intended 190 strict traversal has been broken. 192 Assume in above topology, R1 sends traffic with segment stack as 193 {9124, 5008} so that the path taken will be R1-R2-R4-R5-R7-R8. If 194 the Adjacency Segment ID 9124 is misprogrammed in R2 to send the 195 packet to R1 or R3, it will still be delivered to R8 but is not via 196 the expected path. 198 MPLS traceroute may help with detecting such deviation in above 199 mentioned scenario. However, in a different example, it may not be 200 helpful. For example if R3, due to misprogramming, forwards packet 201 with Adjacency Segment ID 9236 via link L1 while it is expected to be 202 forwarded over Link L2. 204 5. Segment ID sub-TLV 206 The format of the following Segment ID sub-TLVs follows the 207 philosophy of Target FEC Stack TLV carrying FECs corresponding to 208 each label in the label stack. When operated with the procedures 209 defined in [RFC8029], this allows LSP ping/traceroute operations to 210 function when Target FEC Stack TLV contains more FECs than received 211 label stack at responder nodes. 213 Three new sub-TLVs are defined for Target FEC Stack TLVs (Type 1), 214 Reverse-Path Target FEC Stack TLV (Type 16) and Reply Path TLV (Type 215 21). 217 sub-Type Value Field 218 -------- --------------- 219 34 IPv4 IGP-Prefix Segment ID 220 35 IPv6 IGP-Prefix Segment ID 221 36 IGP-Adjacency Segment ID 223 5.1. IPv4 IGP-Prefix Segment ID 225 The format is as below: 227 0 1 2 3 228 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 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | IPv4 Prefix | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 |Prefix Length | Protocol | Reserved | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 IPv4 Prefix 237 This field carries the IPv4 prefix to which the Segment ID is 238 assigned. In case of Anycast Segment ID, this field will carry 239 IPv4 Anycast address. If the prefix is shorter than 32 bits, 240 trailing bits SHOULD be set to zero. 242 Prefix Length 244 The Prefix Length field is one octet, it gives the length of the 245 prefix in bits (values can be 1 - 32). 247 Protocol 249 Set to 1, if the Responder MUST perform FEC validation using OSPF 250 as IGP protocol. Set to 2, if the Responder MUST perform Egress 251 FEC validation using ISIS as IGP protocol. Set to 0, if Responder 252 can use any IGP protocol for Egress FEC validation. 254 5.2. IPv6 IGP-Prefix Segment ID 256 The format is as below: 258 0 1 2 3 259 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 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | | 262 | IPv6 Prefix | 263 | | 264 | | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 |Prefix Length | Protocol | Reserved | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 IPv6 Prefix 270 This field carries the IPv6 prefix to which the Segment ID is 271 assigned. In case of Anycast Segment ID, this field will carry 272 IPv4 Anycast address. If the prefix is shorter than 128 bits, 273 trailing bits SHOULD be set to zero. 275 Prefix Length 277 The Prefix Length field is one octet, it gives the length of the 278 prefix in bits (values can be 1 - 128). 280 Protocol 282 Set to 1, if the Responder MUST perform FEC validation using OSPF 283 as IGP protocol. Set to 2, if the Responder MUST perform Egress 284 FEC validation using ISIS as IGP protocol. Set to 0, if Responder 285 can use any IGP protocol for Egress FEC validation. 287 5.3. IGP-Adjacency Segment ID 289 This Sub-TLV is applicable for any IGP-Adjacency defined in section 290 3.5 of [I-D.ietf-spring-segment-routing]. The format is as below: 292 0 1 2 3 293 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 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Adj. Type | Protocol | Reserved | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | Local Interface ID (4 or 16 octets) | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | Remote Interface ID (4 or 16 octets) | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 ~ ~ 302 | Advertising Node Identifier (4 or 6 octets) | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 ~ ~ 305 | Receiving Node Identifier (4 or 6 octets) | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 Adj. Type (Adjacency Type) 310 Set to 1, when the Adjacency Segment is Parallel Adjacency as 311 defined in Section 3.4.1 of [I-D.ietf-spring-segment-routing]. 312 Set to 4, when the Adjacency segment is IPv4 based and is not a 313 parallel adjacency. Set to 6, when the Adjacency segment is IPv6 314 based and is not a parallel adjacency. Set to 0, when the 315 Adjacency segment is over unnumbered interface. 317 Protocol 319 Set to 1, if the Responder MUST perform FEC validation using OSPF 320 as IGP protocol. Set to 2, if the Responder MUST perform Egress 321 FEC validation using ISIS as IGP protocol. Set to 0, if Responder 322 can use any IGP protocol for Egress FEC validation. 324 Local Interface ID 326 An identifier that is assigned by local LSR for a link on which 327 Adjacency Segment ID is bound. This field is set to local link 328 address (IPv4 or IPv6). Incase of unnumbered, 32 bit link 329 identifier defined in [RFC4203], [RFC5307] is used. If the 330 Adjacency Segment ID represents parallel adjacencies 331 (Section 3.4.1 of [I-D.ietf-spring-segment-routing]) this field 332 MUST be set to 4 bytes of zero. 334 Remote Interface ID 336 An identifier that is assigned by remote LSR for a link on which 337 Adjacency Segment ID is bound. This field is set to remote 338 (downstream neighbor) link address (IPv4 or IPv6). In case of 339 unnumbered, 32 bit link identifier defined in [RFC4203], [RFC5307] 340 is used. If the Adjacency Segment ID represents parallel 341 adjacencies (Section 3.4.1 of [I-D.ietf-spring-segment-routing]) 342 this field MUST be set to 4 bytes of zero. 344 Advertising Node Identifier 346 Specifies the advertising node identifier. When Protocol is set 347 to 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 Receiving Node Identifier 352 Specifies the downstream node identifier. When Protocol is set to 353 1, then the 32 rightmost bits represent OSPF Router ID and if 354 protocol is set to 2, this field carries 48 bit ISIS System ID. 356 6. Extension to Downstream Detailed Mapping TLV 358 In an echo reply, the Downstream Mapping TLV [RFC8029] is used to 359 report for each interface over which a FEC could be forwarded. For a 360 FEC, there are multiple protocols that may be used to distribute 361 label mapping. The "Protocol" field of the Downstream Detailed 362 Mapping TLV is used to return the protocol that is used to distribute 363 the label carried in "Downstream Label" field. The following 364 protocols are defined in Section 3.4.1.2 of [RFC8029]: 366 Protocol # Signaling Protocol 367 ---------- ------------------ 368 0 Unknown 369 1 Static 370 2 BGP 371 3 LDP 372 4 RSVP-TE 374 With segment routing, OSPF or ISIS can be used for label 375 distribution, this document adds two new protocols as follows: 377 Protocol # Signaling Protocol 378 ---------- ------------------ 379 5 OSPF 380 6 ISIS 382 7. Procedures 384 This section describes aspects of LSP Ping and traceroute operations 385 that require further considerations beyond [RFC8029]. 387 7.1. FECs in Target FEC Stack TLV 389 When LSP echo request packets are generated by an initiator, FECs 390 carried in Target FEC Stack TLV may need to have deviating contents. 391 This document outlines expected Target FEC Stack TLV construction 392 mechanics by initiator for known scenarios. 394 Ping 396 Initiator MUST include FEC(s) corresponding to the destination 397 segment. 399 Initiator MAY include FECs corresponding to some or all of 400 segments imposed in the label stack by the initiator to 401 communicate the segments traversed. 403 Traceroute 405 Initiator MUST initially include FECs corresponding to all of 406 segments imposed in the label stack. 408 When a received echo reply contains FEC Stack Change TLV with 409 one or more of original segment(s) being popped, initiator MAY 410 remove corresponding FEC(s) from Target FEC Stack TLV in the 411 next (TTL+1) traceroute request as defined in Section 4.6 of 412 [RFC8029]. 414 When a received echo reply does not contain FEC Stack Change 415 TLV, initiator MUST NOT attempt to remove FEC(s) from Target 416 FEC Stack TLV in the next (TTL+1) traceroute request. 418 As defined in [I-D.ietf-ospf-segment-routing-extensions] and 419 [I-D.ietf-isis-segment-routing-extensions], Prefix SID can be 420 advertised as absolute value, index or as range. In any of these 421 cases, Initiator MUST derive the Prefix mapped to the Prefix SID and 422 use it in IGP-Prefix Segment ID defined in Section 5.1 and 5.2. 424 7.2. FEC Stack Change sub-TLV 426 Section 3.4.1.3 of [RFC8029] defines FEC Stack Change sub-TLV that a 427 router must include when the FEC stack changes. 429 The network node which advertised the Node Segment ID is responsible 430 for generating FEC Stack Change sub-TLV of pop operation for Node 431 Segment ID, regardless of whether PHP is enabled or not. 433 The network node that is immediate downstream of the node which 434 advertised the Adjacency Segment ID is responsible for generating FEC 435 Stack Change sub-TLV for "POP" operation for Adjacency Segment ID. 437 7.3. Segment ID POP Operation 439 The forwarding semantic of Node Segment ID with PHP flag is 440 equivalent to usage of implicit Null in MPLS protocols. Adjacency 441 Segment ID is also similar in a sense that it can be thought of as 442 locally allocated segment that has PHP enabled destined for next hop 443 IGP adjacency node. Procedures described in Section 4.4 of [RFC8029] 444 relies on Stack-D and Stack-R explicitly having Implicit Null value. 445 It may simplify implementations to reuse Implicit Null for Node 446 Segment ID PHP and Adjacency Segment ID cases. 448 7.4. Segment ID Check 450 This section updates the procedure defined in Steps 3 to 5 of 451 Section 4.4.1 of [RFC8029] 453 If the Label-stack-depth is 0 and Target FEC Stack Sub-TLV at FEC- 454 stack-depth is 34 (IPv4 IGP-Prefix Segment ID), the responder 455 should set Best return code to 10, "Mapping for this FEC is not 456 the given label at stack-depth " if any below conditions 457 fail: 459 /* The responder LSR is to check if it is the egress of the IPv4 460 IGP-Prefix Segment ID described in the Target FEC Stack Sub-TLV, 461 and if the FEC was advertised with the PHP bit set.*/ 462 * Validate that Node Segment ID is advertised for IPv4 Prefix by 463 IGP Protocol{ 465 + When protocol field in received IPv4 IGP-Prefix Segment ID 466 Sub-TLV is 0, Use any locally enabled IGP protocol. 468 + When protocol field in received IPv4 IGP-Prefix Segment ID 469 Sub-TLV is 1, Use OSPF as IGP protocol. 471 + When protocol field in received IPv4 IGP-Prefix Segment ID 472 Sub-TLV is 2, Use ISIS as IGP protocol. 474 + When protocol field in received IPv4 IGP-Prefix Segment ID 475 Sub-TLV is any other value, it MUST be treated as Protocol 476 value of 0. 478 } 480 * Validate that Node Segment ID is advertised with No-PHP flag { 482 + When Protocol is OSPF, NP-flag defined in Section 5 of 483 [I-D.ietf-ospf-segment-routing-extensions] MUST be set to 0. 485 + When Protocol is ISIS, P-Flag defined in Section 2.1 of 486 [I-D.ietf-isis-segment-routing-extensions] MUST be set to 0. 488 } 490 If the Label-stack-depth is more than 0 and Target FEC Stack Sub- 491 TLV at FEC-stack-depth is 34 (IPv4 IGP-Prefix Segment ID), the 492 responder is to set Best return code to 10 if any below conditions 493 fail: 495 * Validate that Node Segment ID is advertised for IPv4 Prefix by 496 IGP Protocol{ 498 + When protocol field in received IPv4 IGP-Prefix Segment ID 499 Sub-TLV is 0, Use any locally enabled IGP protocol. 501 + When protocol field in received IPv4 IGP-Prefix Segment ID 502 Sub-TLV is 1, Use OSPF as IGP protocol. 504 + When protocol field in received IPv4 IGP-Prefix Segment ID 505 Sub-TLV is 2, Use ISIS as IGP protocol. 507 + When protocol field in received IPv4 IGP-Prefix Segment ID 508 Sub-TLV is any other value, it MUST be treated as Protocol 509 value of 0. 511 } 513 If the Label-stack-depth is 0 and Target FEC Sub-TLV at FEC-stack- 514 depth is 35 (IPv6 IGP-Prefix Segment ID), set Best return code to 515 10 if any below conditions fail: 517 /* The LSR needs to check if its being a tail-end for the LSP and 518 have the prefix advertised with PHP bit set*/ 520 * Validate that Node Segment ID is advertised for IPv6 Prefix by 521 IGP Protocol{ 523 + When protocol field in received IPv6 IGP-Prefix Segment ID 524 Sub-TLV is 0, Use any locally enabled IGP protocol. 526 + When protocol field in received IPv6 IGP-Prefix Segment ID 527 Sub-TLV is 1, Use OSPF as IGP protocol. 529 + When protocol field in received IPv6 IGP-Prefix Segment ID 530 Sub-TLV is 2, Use ISIS as IGP protocol. 532 + When protocol field in received IPv4 IGP-Prefix Segment ID 533 Sub-TLV is any other value, it MUST be treated as Protocol 534 value of 0. 536 } 538 * Validate that Node Segment ID is advertised of PHP bit. 540 If the Label-stack-depth is more than 0 and Target FEC Sub-TLV at 541 FEC-stack-depth is 35 (IPv6 IGP-Prefix Segment ID), set Best 542 return code to 10 if any below conditions fail: 544 * Validate that Node Segment ID is advertised for IPv4 Prefix by 545 IGP Protocol{ 547 + When protocol field in received IPv4 IGP-Prefix Segment ID 548 Sub-TLV is 0, Use any locally enabled IGP protocol. 550 + When protocol field in received IPv4 IGP-Prefix Segment ID 551 Sub-TLV is 1, Use OSPF as IGP protocol. 553 + When protocol field in received IPv4 IGP-Prefix Segment ID 554 Sub-TLV is 2, Use ISIS as IGP protocol. 556 + When protocol field in received IPv4 IGP-Prefix Segment ID 557 Sub-TLV is any other value, it MUST be treated as Protocol 558 value of 0. 560 } 562 If the Label-stack-depth is 0 and Target FEC sub-TLV at FEC-stack- 563 depth is 36 (Adjacency Segment ID), set Best return code to TBD1 564 (Section 10.3) if any below conditions fail: 566 When the Adj. Type is 1 (Parallel Adjacency): 568 + Validate that Receiving Node Identifier is local IGP 569 identifier. 571 + Validate that Adjacency Segment ID is advertised by 572 Advertising Node Identifier of Protocol in local IGP 573 database { 575 - When protocol field in received IPv4 IGP-Prefix Segment 576 ID Sub-TLV is 0, Use any locally enabled IGP protocol. 578 - When protocol field in received IPv4 IGP-Prefix Segment 579 ID Sub-TLV is 1, Use OSPF as IGP protocol. 581 - When protocol field in received IPv4 IGP-Prefix Segment 582 ID Sub-TLV is 2, Use ISIS as IGP protocol. 584 - When protocol field in received IPv4 IGP-Prefix Segment 585 ID Sub-TLV is any other value, it MUST be treated as 586 Protocol value of 0. 588 } 590 When the Adj. Type is 4 or 6 (IGP Adjacency or LAN Adjacency): 592 + Validate that Remote Interface ID matches the local 593 identifier of the interface (Interface-I) on which the 594 packet was received. 596 + Validate that Receiving Node Identifier is local IGP 597 identifier. 599 + Validate that IGP-Adjacency Segment ID is advertised by 600 Advertising Node Identifier of Protocol in local IGP 601 database { 602 - When protocol field in received IPv4 IGP-Prefix Segment 603 ID Sub-TLV is 0, Use any locally enabled IGP protocol. 605 - When protocol field in received IPv4 IGP-Prefix Segment 606 ID Sub-TLV is 1, Use OSPF as IGP protocol. 608 - When protocol field in received IPv4 IGP-Prefix Segment 609 ID Sub-TLV is 2, Use ISIS as IGP protocol. 611 - When protocol field in received IPv4 IGP-Prefix Segment 612 ID Sub-TLV is any other value, it MUST be treated as 613 Protocol value of 0. 615 } 617 7.5. TTL Consideration for traceroute 619 LSP Traceroute operation can properly traverse every hop of Segment 620 Routing network in Uniform Model described in [RFC3443]. If one or 621 more LSRs employ Short Pipe Model described in [RFC3443], then LSP 622 Traceroute may not be able to properly traverse every hop of Segment 623 Routing network due to absence of TTL copy operation when outer label 624 is popped. Short Pipe being the most commonly used model. The 625 following TTL manipulation technique MAY be used when Short Pipe 626 model is used. 628 When tracing a LSP according to the procedures in [RFC8029] the TTL 629 is incremented by one in order to trace the path sequentially along 630 the LSP. However when a source routed LSP has to be traced there are 631 as many TTLs as there are labels in the stack. The LSR that 632 initiates the traceroute SHOULD start by setting the TTL to 1 for the 633 tunnel in the LSP's label stack it wants to start the tracing from, 634 the TTL of all outer labels in the stack to the max value, and the 635 TTL of all the inner labels in the stack to zero. Thus a typical 636 start to the traceroute would have a TTL of 1 for the outermost label 637 and all the inner labels would have TTL 0. If the FEC Stack TLV is 638 included it should contain only those for the inner stacked tunnels. 639 The Return Code/Subcode and FEC Stack Change TLV should be used to 640 diagnose the tunnel as described in [RFC8029]. When the tracing of a 641 tunnel in the stack is complete, then the next tunnel in the stack 642 should be traced. The end of a tunnel can be detected from the 643 "Return Code" when it indicates that the responding LSR is an egress 644 for the stack at depth 1. Thus the traceroute procedures in 645 [RFC8029] can be recursively applied to traceroute a source routed 646 LSP. 648 8. Backward Compatibility with non Segment Routing devices 650 [I-D.ietf-spring-segment-routing-ldp-interop] describes how Segment 651 Routing operates in network where SR-capable and non-SR-capable nodes 652 coexist. In such networks, there may not be any FEC mapping in the 653 responder when the Initiator is SR-capable while the responder is not 654 (or vice-versa). But this is not different from RSVP and LDP interop 655 scenarios. When LSP Ping is triggered, the responder will set the 656 FEC-return-code to Return 4, "Replying router has no mapping for the 657 FEC at stack-depth". 659 Similarly when SR-capable node assigns Adj-SID for non-SR-capable 660 node, LSP traceroute may fail as the non-SR-capable node is not aware 661 of "IGP Adjacency Segment ID" sub-TLV and may not reply with FEC 662 Stack change. This may result in any further downstream nodes to 663 reply back with Return-code as 4, "Replying router has no mapping for 664 the FEC at stack-depth". 666 9. IANA Considerations 668 9.1. New Target FEC Stack Sub-TLVs 670 IANA is requested to assign three new Sub-TLVs from "Sub-TLVs for TLV 671 Types 1, 16 and 21" sub-registry from the "Multi-Protocol Label 672 Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" 673 [IANA-MPLS-LSP-PING] registry. 675 Sub-Type Sub-TLV Name Reference 676 -------- ----------------- ------------ 677 34 IPv4 IGP-Prefix Segment ID Section 5.1 of this document 678 35 IPv6 IGP-Prefix Segment ID Section 5.2 of this document 679 36 IGP-Adjacency Segment ID Section 5.3 of this document 681 9.2. Protocol in Label Stack Sub-TLV of Downstream Detailed Mapping TLV 683 IANA is requested to create a new "Protocol" registry under the 684 "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) 685 Ping Parameters" registry. Code points in the range of 0-250 will be 686 assigned by Standards Action. The range of 251-254 are reserved for 687 experimental use and will not be assigned. The initial entries into 688 the registry will be. 690 Value Meaning Reference 691 ---------- ---------------- ------------ 692 0 Unknown Section 3.4.1.2 of RFC8029 693 1 Static Section 3.4.1.2 of RFC8029 694 2 BGP Section 3.4.1.2 of RFC8029 695 3 LDP Section 3.4.1.2 of RFC8029 696 4 RSVP-TE Section 3.4.1.2 of RFC8029 697 5 OSPF Section 6 of this document 698 6 ISIS Section 6 of this document 699 7-250 Unassigned 700 251-254 Experimental use This document 701 255 Reserved This document 703 9.3. Return Code 705 IANA is requested to assign a new Return Code from the "Multi- 706 Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping 707 Parameters" in "Return Codes" Sub-registry. 709 Value Meaning Reference 710 ---------- ----------------- ------------ 711 TBD1 Mapping for this FEC is not associated Section 7.4 of 712 with the incoming interface this document 714 Note to the RFC Editor (please remove before publication): IANA has 715 made early allocation for sub-type 34, 35 and 35. The early 716 allocation expires 2017-09-15. 718 10. Security Considerations 720 This document defines additional Sub-TLVs and follows the mechanism 721 defined in [RFC8029]. So all the security consideration defined in 722 [RFC8029] will be applicable for this document and in addition it 723 does not impose any security challenges to be considered. 725 11. Acknowledgement 727 The authors would like to thank Stefano Previdi, Les Ginsberg, Balaji 728 Rajagopalan, Harish Sitaraman, Curtis Villamizar, Pranjal Dutta, 729 Lizhong Jin, Tom Petch, Victor Ji and Mustapha Aissaoui, Tony 730 Przygienda, Alexander Vainshtein for their review and comments. 732 The authors wold like to thank Loa Andersson for his comments and 733 recommendation to merge drafts. 735 12. Contributors 737 The following are key contributors to this document: 739 Hannes Gredler, RtBrick, Inc. 741 Tarek Saad, Cisco Systems, Inc. 743 Siva Sivabalan, Cisco Systems, Inc. 745 Balaji Rajagopalan, Juniper Networks 747 Faisal Iqbal, Cisco Systems, Inc. 749 13. References 751 13.1. Normative References 753 [I-D.ietf-spring-segment-routing] 754 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 755 and R. Shakir, "Segment Routing Architecture", draft-ietf- 756 spring-segment-routing-12 (work in progress), June 2017. 758 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 759 Requirement Levels", BCP 14, RFC 2119, 760 DOI 10.17487/RFC2119, March 1997, 761 . 763 [RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing 764 in Multi-Protocol Label Switching (MPLS) Networks", 765 RFC 3443, DOI 10.17487/RFC3443, January 2003, 766 . 768 [RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in 769 Support of Generalized Multi-Protocol Label Switching 770 (GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005, 771 . 773 [RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions 774 in Support of Generalized Multi-Protocol Label Switching 775 (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008, 776 . 778 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 779 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 780 Switched (MPLS) Data-Plane Failures", RFC 8029, 781 DOI 10.17487/RFC8029, March 2017, 782 . 784 13.2. Informative References 786 [I-D.ietf-isis-segment-routing-extensions] 787 Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., 788 Litkowski, S., Decraene, B., and j. jefftant@gmail.com, 789 "IS-IS Extensions for Segment Routing", draft-ietf-isis- 790 segment-routing-extensions-13 (work in progress), June 791 2017. 793 [I-D.ietf-ospf-segment-routing-extensions] 794 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 795 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 796 Extensions for Segment Routing", draft-ietf-ospf-segment- 797 routing-extensions-19 (work in progress), August 2017. 799 [I-D.ietf-spring-segment-routing-ldp-interop] 800 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., and 801 S. Litkowski, "Segment Routing interworking with LDP", 802 draft-ietf-spring-segment-routing-ldp-interop-08 (work in 803 progress), June 2017. 805 [I-D.ietf-spring-segment-routing-mpls] 806 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 807 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 808 data plane", draft-ietf-spring-segment-routing-mpls-10 809 (work in progress), June 2017. 811 [IANA-MPLS-LSP-PING] 812 IANA, "Multi-Protocol Label Switching (MPLS) Label 813 Switched Paths (LSPs) Ping Parameters", 814 . 817 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 818 RFC 792, DOI 10.17487/RFC0792, September 1981, 819 . 821 Authors' Addresses 823 Nagendra Kumar (editor) 824 Cisco Systems, Inc. 825 7200-12 Kit Creek Road 826 Research Triangle Park, NC 27709-4987 827 US 829 Email: naikumar@cisco.com 830 Carlos Pignataro (editor) 831 Cisco Systems, Inc. 832 7200-11 Kit Creek Road 833 Research Triangle Park, NC 27709-4987 834 US 836 Email: cpignata@cisco.com 838 George Swallow 839 Southend Technical Center 841 Email: swallow.ietf@gmail.com 843 Nobo Akiya 844 Big Switch Networks 846 Email: nobo.akiya.dev@gmail.com 848 Sriganesh Kini 849 Individual 851 Email: sriganeshkini@gmail.com 853 Mach(Guoyi) Chen 854 Huawei 856 Email: mach.chen@huawei.com