idnits 2.17.1 draft-ietf-mpls-spring-lsp-ping-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 4 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 (September 21, 2017) is 2402 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 (-23) exists of draft-ietf-ospf-ospfv3-segment-routing-extensions-10 == 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: 1 error (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Work group N. Kumar, Ed. 3 Internet-Draft C. Pignataro, Ed. 4 Intended status: Standards Track Cisco 5 Expires: March 25, 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 21, 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-09 19 Abstract 21 A Segment Routing architecture leverages source routing and tunneling 22 paradigms and can be directly applied to use of a Multi Protocol 23 Label Switching (MPLS) data plane. A node steers a packet through a 24 controlled set of instructions called segments, by prepending the 25 packet with a Segment Routing header. 27 The segment assignment and forwarding semantic nature of Segment 28 Routing raises additional consideration for connectivity verification 29 and fault isolation for an LSP within a Segment Routing architecture. 30 This document illustrates the problem and defines extensions to 31 perform LSP Ping and Traceroute for a Segment Routing network with a 32 MPLS data 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 25, 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 mechanisms . . . . . . . . . . . . . 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 . . . . . . . . . . . . 15 83 8. Backward Compatibility with non Segment Routing devices . . . 16 84 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 85 9.1. New Target FEC Stack Sub-TLVs . . . . . . . . . . . . . . 17 86 9.2. Protocol in Label Stack Sub-TLV of Downstream Detailed 87 Mapping TLV . . . . . . . . . . . . . . . . . . . . . . . 17 88 9.3. Return Code . . . . . . . . . . . . . . . . . . . . . . . 17 89 10. Security Considerations . . . . . . . . . . . . . . . . . . . 18 90 11. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 18 91 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18 92 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 93 13.1. Normative References . . . . . . . . . . . . . . . . . . 18 94 13.2. Informative References . . . . . . . . . . . . . . . . . 19 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 97 1. Introduction 99 [I-D.ietf-spring-segment-routing] introduces and describes a 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 of the Segment Routing 104 architecture is available in [I-D.ietf-spring-segment-routing] 106 As described 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 an MPLS data plane, the 109 Segment identifier (Segment ID) will be of 20-bits size and the 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 a Segment Routing network. This 131 document illustrates the problem and describes a mechanism to perform 132 LSP Ping and Traceroute on a Segment Routing network with a 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], readers are expected to 145 be familiar with it. 147 4. Challenges with Existing mechanisms 149 The following example describes the challenges with using the current 150 MPLS OAM mechanisms on a Segment Routing network. 152 4.1. Path validation in Segment Routing networks 154 [RFC8029] defines the MPLS OAM mechanisms that help with fault 155 detection and isolation for a MPLS data-plane path by the use of 156 various Target FEC Stack Sub-TLVs 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 for Segment 159 Routing, the unique nature of the Segment Routing architecture raises 160 the need for additional operational considerations 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 an incorrect neighbor or over an incorrect link. The exposed 188 Segment ID (of an incorrectly forwarded Adjacency Segment ID) might 189 still allow such packet to reach the intended destination, although 190 the intended 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, the packet may still be delivered to R8 (if the 196 nodes are configured with same SRGB) but is not via the expected 197 path. 199 MPLS traceroute may help with detecting such a deviation in the above 200 mentioned scenario. However, in a different example, it may not be 201 helpful. For example if R3, due to misprogramming, forwards a packet 202 with Adjacency Segment ID 9236 via link L1, while it is expected to 203 be forwarded over Link L2. 205 5. Segment ID sub-TLV 207 The format of the following Segment ID sub-TLVs follows the 208 philosophy of Target FEC Stack TLV carrying FECs corresponding to 209 each label in the label stack. When operated with the procedures 210 defined in [RFC8029], this allows LSP ping/traceroute operations to 211 function when Target FEC Stack TLV contains more FECs than received 212 label stack at responder nodes. 214 Three new sub-TLVs are defined for Target FEC Stack TLVs (Type 1), 215 Reverse-Path Target FEC Stack TLV (Type 16) and Reply Path TLV (Type 216 21). 218 sub-Type Value Field 219 -------- --------------- 220 34 IPv4 IGP-Prefix Segment ID 221 35 IPv6 IGP-Prefix Segment ID 222 36 IGP-Adjacency Segment ID 224 5.1. IPv4 IGP-Prefix Segment ID 226 The format is as below: 228 0 1 2 3 229 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 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | IPv4 Prefix | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 |Prefix Length | Protocol | Reserved | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 IPv4 Prefix 238 This field carries the IPv4 prefix to which the Segment ID is 239 assigned. In case of Anycast Segment ID, this field will carry 240 IPv4 Anycast address. If the prefix is shorter than 32 bits, 241 trailing bits SHOULD be set to zero. 243 Prefix Length 245 The Prefix Length field is one octet, it gives the length of the 246 prefix in bits (values can be 1 - 32). 248 Protocol 250 Set to 1, if the Responder MUST perform FEC validation using OSPF 251 as IGP protocol. Set to 2, if the Responder MUST perform Egress 252 FEC validation using ISIS as IGP protocol. Set to 0, if Responder 253 can use any IGP protocol for Egress FEC validation. 255 5.2. IPv6 IGP-Prefix Segment ID 257 The format is as below: 259 0 1 2 3 260 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 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | | 263 | IPv6 Prefix | 264 | | 265 | | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 |Prefix Length | Protocol | Reserved | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 IPv6 Prefix 271 This field carries the IPv6 prefix to which the Segment ID is 272 assigned. In case of Anycast Segment ID, this field will carry 273 IPv4 Anycast address. If the prefix is shorter than 128 bits, 274 trailing bits SHOULD be set to zero. 276 Prefix Length 278 The Prefix Length field is one octet, it gives the length of the 279 prefix in bits (values can be 1 - 128). 281 Protocol 283 Set to 1, if the Responder MUST perform FEC validation using OSPF 284 as IGP protocol. Set to 2, if the Responder MUST perform Egress 285 FEC validation using ISIS as IGP protocol. Set to 0, if Responder 286 can use any IGP protocol for Egress FEC validation. 288 5.3. IGP-Adjacency Segment ID 290 This Sub-TLV is applicable for any IGP-Adjacency defined in 291 Section 3.5 of [I-D.ietf-spring-segment-routing]. The format is as 292 below: 294 0 1 2 3 295 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 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | Adj. Type | Protocol | Reserved | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | Local Interface ID (4 or 16 octets) | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | Remote Interface ID (4 or 16 octets) | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 ~ ~ 304 | Advertising Node Identifier (4 or 6 octets) | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 ~ ~ 307 | Receiving Node Identifier (4 or 6 octets) | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 Adj. Type (Adjacency Type) 312 Set to 1, when the Adjacency Segment is Parallel Adjacency as 313 defined in Section 3.4.1 of [I-D.ietf-spring-segment-routing]. 314 Set to 4, when the Adjacency segment is IPv4 based and is not a 315 parallel adjacency. Set to 6, when the Adjacency segment is IPv6 316 based and is not a parallel adjacency. Set to 0, when the 317 Adjacency segment is over unnumbered interface. 319 Protocol 321 Set to 1, if the Responder MUST perform FEC validation using OSPF 322 as IGP protocol. Set to 2, if the Responder MUST perform Egress 323 FEC validation using ISIS as IGP protocol. Set to 0, if Responder 324 can use any IGP protocol for Egress FEC validation. 326 Local Interface ID 328 An identifier that is assigned by local LSR for a link on which 329 Adjacency Segment ID is bound. This field is set to local link 330 address (IPv4 or IPv6). Incase of unnumbered, a 32 bit link 331 identifier as defined in [RFC4203], [RFC5307] is used. If the 332 Adjacency Segment ID represents parallel adjacencies 333 ([I-D.ietf-spring-segment-routing]), this field MUST be set to 4 334 bytes of zero. 336 Remote Interface ID 338 An identifier that is assigned by remote LSR for a link on which 339 Adjacency Segment ID is bound. This field is set to remote 340 (downstream neighbor) link address (IPv4 or IPv6). In case of 341 unnumbered, a 32 bit link identifier as defined in [RFC4203], 342 [RFC5307] is used. If the Adjacency Segment ID represents 343 parallel adjacencies ([I-D.ietf-spring-segment-routing]), this 344 field MUST be set to 4 bytes of zero. 346 Advertising Node Identifier 348 Specifies the advertising node identifier. When Protocol is set 349 to 1, then the 32 rightmost bits represent OSPF Router ID and if 350 protocol is set to 2, this field carries 48 bit ISIS System ID. 352 Receiving Node Identifier 354 Specifies the downstream node identifier. When Protocol is set to 355 1, then the 32 rightmost bits represent OSPF Router ID and if 356 protocol is set to 2, this field carries 48 bit ISIS System ID. 358 6. Extension to Downstream Detailed Mapping TLV 360 In an echo reply, the Downstream Detailed Mapping TLV [RFC8029] is 361 used to report for each interface over which a FEC could be 362 forwarded. For a FEC, there are multiple protocols that may be used 363 to distribute label mapping. The "Protocol" field of the Downstream 364 Detailed Mapping TLV is used to return the protocol that is used to 365 distribute the label carried in "Downstream Label" field. The 366 following protocols are defined in [RFC8029]: 368 Protocol # Signaling Protocol 369 ---------- ------------------ 370 0 Unknown 371 1 Static 372 2 BGP 373 3 LDP 374 4 RSVP-TE 376 With segment routing, OSPF or ISIS can be used for label 377 distribution, this document adds two new protocols as follows: 379 Protocol # Signaling Protocol 380 ---------- ------------------ 381 5 OSPF 382 6 ISIS 384 7. Procedures 386 This section describes aspects of LSP Ping and traceroute operations 387 that require further considerations beyond [RFC8029]. 389 7.1. FECs in Target FEC Stack TLV 391 When LSP echo request packets are generated by an initiator, FECs 392 carried in the Target FEC Stack TLV may need to differ to support a 393 Segment Routing architecture. The following defines Target FEC Stack 394 TLV construction mechanics by an initiator for Segment Routing 395 scenarios. 397 Ping 399 Initiator MUST include FEC(s) corresponding to the destination 400 segment. 402 Initiator MAY include FECs corresponding to some or all of 403 segments imposed in the label stack by the initiator to 404 communicate the segments traversed. 406 Traceroute 408 Initiator MUST initially include FECs corresponding to all of 409 segments imposed in the label stack. 411 When a received echo reply contains FEC Stack Change TLV with 412 one or more of original segment(s) being popped, initiator MAY 413 remove corresponding FEC(s) from Target FEC Stack TLV in the 414 next (TTL+1) traceroute request as defined in Section 4.6 of 415 [RFC8029]. 417 When a received echo reply does not contain FEC Stack Change 418 TLV, initiator MUST NOT attempt to remove FEC(s) from Target 419 FEC Stack TLV in the next (TTL+1) traceroute request. 421 As defined in [I-D.ietf-ospf-segment-routing-extensions] and 422 [I-D.ietf-isis-segment-routing-extensions], Prefix SID can be 423 advertised as absolute value, index or as range. In any of these 424 cases, Initiator MUST derive the Prefix mapped to the Prefix SID and 425 use it in IGP-Prefix Segment ID defined in Section 5.1 and 5.2. 427 7.2. FEC Stack Change sub-TLV 429 [RFC8029] defines a FEC Stack Change sub-TLV that a router must 430 include when the FEC stack changes. 432 The network node which advertised the Node Segment ID is responsible 433 for generating a FEC Stack Change sub-TLV with pop operation type for 434 Node Segment ID, regardless of whether penultimate hop popping (PHP) 435 is enabled or not. 437 The network node that is immediate downstream of the node which 438 advertised the Adjacency Segment ID is responsible for generating FEC 439 Stack Change sub-TLV for "POP" operation for Adjacency Segment ID. 441 7.3. Segment ID POP Operation 443 The forwarding semantic of Node Segment ID with PHP flag is 444 equivalent to usage of implicit Null in MPLS protocols. Adjacency 445 Segment ID is also similar in a sense that it can be thought of as 446 locally allocated segment that has PHP enabled destined for next hop 447 IGP adjacency node. Procedures described in Section 4.4 of [RFC8029] 448 relies on Stack-D and Stack-R explicitly having Implicit Null value. 449 It may simplify implementations to reuse Implicit Null for Node 450 Segment ID PHP and Adjacency Segment ID cases. 452 7.4. Segment ID Check 454 This section modifies the procedure defined in Section 4.4.1 of 455 [RFC8029]. Step 4 defined in Section 4.4.1 of [RFC8029] is updated 456 as below: 458 4. If the label mapping for FEC is Implicit Null, set FEC-status to 459 2 and proceed to step 5. Otherwise, if the label mapping for FEC 460 is Label-L, proceed to step 5. Otherwise, set FEC-return-code to 461 10 ("Mapping for this FEC is not the given label at stack- 462 depth"), set FEC-status to 1, and return. 464 4a. Segment Routing IGP Prefix and Adjacency SID Validation: 466 If the Label-stack-depth is 0 and Target FEC Stack Sub-TLV at 467 FEC-stack-depth is 34 (IPv4 IGP-Prefix Segment ID), { 469 Set Best return code to 10, "Mapping for this FEC is not the 470 given label at stack-depth " if any below conditions 471 fail: 473 /* The responder LSR is to check if it is the egress of the 474 IPv4 IGP-Prefix Segment ID described in the Target FEC Stack 475 Sub-TLV, and if the FEC was advertised with the PHP bit 476 set.*/ 478 - Validate that Node Segment ID is advertised for IPv4 479 Prefix by IGP Protocol{ 481 o When protocol field in received IPv4 IGP-Prefix 482 Segment ID Sub-TLV is 0, Use any locally enabled IGP 483 protocol. 485 o When protocol field in received IPv4 IGP-Prefix 486 Segment ID Sub-TLV is 1, Use OSPF as IGP protocol. 488 o When protocol field in received IPv4 IGP-Prefix 489 Segment ID Sub-TLV is 2, Use ISIS as IGP protocol. 491 o When protocol field in received IPv4 IGP-Prefix 492 Segment ID Sub-TLV is any other value, it MUST be 493 treated as Protocol value of 0. 495 } 497 - Validate that Node Segment ID is advertised with No-PHP 498 flag { 500 o When Protocol is OSPF, NP-flag defined in Section 5 of 501 [I-D.ietf-ospf-segment-routing-extensions] MUST be set 502 to 0. 504 o When Protocol is ISIS, P-Flag defined in Section 2.1 505 of [I-D.ietf-isis-segment-routing-extensions] MUST be 506 set to 0. 508 } 510 set FEC-Status to 1, and return. 512 } 514 Else if the Label-stack-depth is greater than 0 and Target FEC 515 Stack Sub-TLV at FEC-stack-depth is 34 (IPv4 IGP-Prefix Segment 516 ID), { 518 Set Best return code to 10 if any below conditions fail: 520 - Validate that Node Segment ID is advertised for IPv4 521 Prefix by IGP Protocol { 523 o When protocol field in received IPv4 IGP-Prefix 524 Segment ID Sub-TLV is 0, Use any locally enabled IGP 525 protocol. 527 o When protocol field in received IPv4 IGP-Prefix 528 Segment ID Sub-TLV is 1, Use OSPF as IGP protocol. 530 o When protocol field in received IPv4 IGP-Prefix 531 Segment ID Sub-TLV is 2, Use ISIS as IGP protocol. 533 o When protocol field in received IPv4 IGP-Prefix 534 Segment ID Sub-TLV is any other value, it MUST be 535 treated as Protocol value of 0. 537 } 539 set FEC-Status to 1, and return. 541 } 543 Else if the Label-stack-depth is 0 and Target FEC Sub-TLV at 544 FEC-stack-depth is 35 (IPv6 IGP-Prefix Segment ID), { 546 Set Best return code to 10 if any of the below conditions 547 fail: 549 /* The LSR needs to check if its being a tail-end for the 550 LSP and have the prefix advertised with PHP bit set*/ 552 - Validate that Node Segment ID is advertised for IPv6 553 Prefix by IGP Protocol { 555 o When protocol field in received IPv6 IGP-Prefix 556 Segment ID Sub-TLV is 0, Use any locally enabled IGP 557 protocol. 559 o When protocol field in received IPv6 IGP-Prefix 560 Segment ID Sub-TLV is 1, Use OSPF as IGP protocol. 562 o When protocol field in received IPv6 IGP-Prefix 563 Segment ID Sub-TLV is 2, Use ISIS as IGP protocol. 565 o When protocol field in received IPv6 IGP-Prefix 566 Segment ID Sub-TLV is any other value, it MUST be 567 treated as Protocol value of 0. 569 } 571 - Validate that Node Segment ID is advertised with No-PHP 572 flag. { 574 o When Protocol is OSPF, NP-flag defined in Section 5 of 575 [I-D.ietf-ospf-ospfv3-segment-routing-extensions] MUST 576 be set to 0. 578 o When Protocol is ISIS, P-Flag defined in Section 2.1 579 of [I-D.ietf-isis-segment-routing-extensions] MUST be 580 set to 0. 582 } 584 set FEC-Status to 1, and return. 586 } 588 Else if the Label-stack-depth is greater than 0 and Target FEC 589 Sub-TLV at FEC-stack-depth is 35 (IPv6 IGP-Prefix Segment ID), 590 { 592 set Best return code to 10 if any below conditions fail: 594 - Validate that Node Segment ID is advertised for IPv4 595 Prefix by IGP Protocol { 597 o When protocol field in received IPv6 IGP-Prefix 598 Segment ID Sub-TLV is 0, Use any locally enabled IGP 599 protocol. 601 o When protocol field in received IPv6 IGP-Prefix 602 Segment ID Sub-TLV is 1, Use OSPF as IGP protocol. 604 o When protocol field in received IPv6 IGP-Prefix 605 Segment ID Sub-TLV is 2, Use ISIS as IGP protocol. 607 o When protocol field in received IPv6 IGP-Prefix 608 Segment ID Sub-TLV is any other value, it MUST be 609 treated as Protocol value of 0. 611 } 613 set FEC-Status to 1, and return. 615 } 617 Else if the Target FEC sub-TLV at FEC-stack-depth is 36 (IGP- 618 Adjacency Segment ID), { 620 set Best return code to TBD1 (Section 10.3) if any below 621 conditions fail: 623 When the Adj. Type is 1 (Parallel Adjacency): 625 o Validate that Receiving Node Identifier is local IGP 626 identifier. 628 o Validate that IGP-Adjacency Segment ID is advertised 629 by Advertising Node Identifier of Protocol in local 630 IGP database { 632 * When protocol field in received IGP-Adjacency 633 Segment ID Sub-TLV is 0, Use any locally enabled 634 IGP protocol. 636 * When protocol field in received IGP-Adjacency 637 Segment ID Sub-TLV is 1, Use OSPF as IGP protocol. 639 * When protocol field in received IGP-Adjacency 640 Segment ID Sub-TLV is 2, Use ISIS as IGP protocol. 642 * When protocol field in received IGP-Adjacency 643 Segment ID Sub-TLV is any other value, it MUST be 644 treated as Protocol value of 0. 646 } 648 When the Adj. Type is 4 or 6 (IGP Adjacency or LAN 649 Adjacency): 651 o Validate that Remote Interface ID matches the local 652 identifier of the interface (Interface-I) on which the 653 packet was received. 655 o Validate that Receiving Node Identifier is local IGP 656 identifier. 658 o Validate that IGP-Adjacency Segment ID is advertised 659 by Advertising Node Identifier of Protocol in local 660 IGP database { 662 * When protocol field in received IGP-Adjacency 663 Segment ID Sub-TLV is 0, Use any locally enabled 664 IGP protocol. 666 * When protocol field in received IGP-Adjacency 667 Segment ID Sub-TLV is 1, Use OSPF as IGP protocol. 669 * When protocol field in received IGP-Adjacency 670 Segment ID Sub-TLV is 2, Use ISIS as IGP protocol. 672 * When protocol field in received IGP-Adjacency 673 Segment ID Sub-TLV is any other value, it MUST be 674 treated as Protocol value of 0. 676 } 678 set FEC-Status to 1, and return. 680 } 682 7.5. TTL Consideration for traceroute 684 LSP Traceroute operation can properly traverse every hop of Segment 685 Routing network for the Uniform Model as described in [RFC3443]. If 686 one or more LSRs employ a Short Pipe Model, as described in 688 [RFC3443], then LSP Traceroute may not be able to properly traverse 689 every hop of Segment Routing network due to the absence of TTL copy 690 operation when the outer label is popped. The Short Pipe is one of 691 the most commonly used models. The following TTL manipulation 692 technique MAY be used when the Short Pipe model is used. 694 When tracing a LSP according to the procedures in [RFC8029] the TTL 695 is incremented by one in order to trace the path sequentially along 696 the LSP. However when a source routed LSP has to be traced there are 697 as many TTLs as there are labels in the stack. The LSR that 698 initiates the traceroute SHOULD start by setting the TTL to 1 for the 699 tunnel in the LSP's label stack it wants to start the tracing from, 700 the TTL of all outer labels in the stack to the max value, and the 701 TTL of all the inner labels in the stack to zero. Thus a typical 702 start to the traceroute would have a TTL of 1 for the outermost label 703 and all the inner labels would have TTL 0. If the FEC Stack TLV is 704 included it should contain only those for the inner stacked tunnels. 705 The Return Code/Subcode and FEC Stack Change TLV should be used to 706 diagnose the tunnel as described in [RFC8029]. When the tracing of a 707 tunnel in the stack is complete, then the next tunnel in the stack 708 should be traced. The end of a tunnel can be detected from the 709 "Return Code" when it indicates that the responding LSR is an egress 710 for the stack at depth 1. Thus the traceroute procedures in 711 [RFC8029] can be recursively applied to traceroute a source routed 712 LSP. 714 8. Backward Compatibility with non Segment Routing devices 716 [I-D.ietf-spring-segment-routing-ldp-interop] describes how Segment 717 Routing operates in a network where SR-capable and non-SR-capable 718 nodes coexist. In such networks, there may not be any FEC mapping in 719 the responder, when the Initiator is SR-capable, while the responder 720 is not (or vice-versa). But this is not different from RSVP and LDP 721 interop scenarios. When LSP Ping is triggered, the responder will 722 set the FEC-return-code to Return 4, "Replying router has no mapping 723 for the FEC at stack-depth". 725 Similarly when a SR-capable node assigns Adj-SID for a non-SR-capable 726 node, LSP traceroute may fail as the non-SR-capable node is not aware 727 of "IGP Adjacency Segment ID" sub-TLV and may not reply with FEC 728 Stack change. This may result in any further downstream nodes to 729 reply back with Return-code as 4, "Replying router has no mapping for 730 the FEC at stack-depth". 732 9. IANA Considerations 734 9.1. New Target FEC Stack Sub-TLVs 736 IANA is requested to assign three new Sub-TLVs from "Sub-TLVs for TLV 737 Types 1, 16 and 21" sub-registry from the "Multi-Protocol Label 738 Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" 739 [IANA-MPLS-LSP-PING] registry. 741 Sub-Type Sub-TLV Name Reference 742 -------- ----------------- ------------ 743 34 IPv4 IGP-Prefix Segment ID Section 5.1 of this document 744 35 IPv6 IGP-Prefix Segment ID Section 5.2 of this document 745 36 IGP-Adjacency Segment ID Section 5.3 of this document 747 9.2. Protocol in Label Stack Sub-TLV of Downstream Detailed Mapping TLV 749 IANA is requested to create a new "Protocol" registry under the 750 "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) 751 Ping Parameters" registry. Code points in the range of 0-250 will be 752 assigned by Standards Action. The range of 251-254 are reserved for 753 experimental use and will not be assigned. The initial entries into 754 the registry will be: 756 Value Meaning Reference 757 ---------- ---------------- ------------ 758 0 Unknown Section 3.4.1.2 of RFC8029 759 1 Static Section 3.4.1.2 of RFC8029 760 2 BGP Section 3.4.1.2 of RFC8029 761 3 LDP Section 3.4.1.2 of RFC8029 762 4 RSVP-TE Section 3.4.1.2 of RFC8029 763 5 OSPF Section 6 of this document 764 6 ISIS Section 6 of this document 765 7-250 Unassigned 766 251-254 Experimental use This document 767 255 Reserved This document 769 9.3. Return Code 771 IANA is requested to assign a new Return Code from the "Multi- 772 Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping 773 Parameters" in "Return Codes" Sub-registry. 775 Value Meaning Reference 776 ---------- ----------------- ------------ 777 TBD1 Mapping for this FEC is not associated Section 7.4 of 778 with the incoming interface this document 780 Note to the RFC Editor (please remove before publication): IANA has 781 made early allocation for sub-type 34, 35 and 35. The early 782 allocation expires 2017-09-15. 784 10. Security Considerations 786 This document defines additional MPLS LSP Ping Sub-TLVs and follows 787 the mechanisms defined in [RFC8029]. All the security considerations 788 defined in [RFC8029] will be applicable for this document, and in 789 addition, they do not impose any additional security challenges to be 790 considered. 792 11. Acknowledgement 794 The authors would like to thank Stefano Previdi, Les Ginsberg, Balaji 795 Rajagopalan, Harish Sitaraman, Curtis Villamizar, Pranjal Dutta, 796 Lizhong Jin, Tom Petch, Victor Ji and Mustapha Aissaoui, Tony 797 Przygienda, Alexander Vainshtein and Deborah Brungard for their 798 review and comments. 800 The authors wold like to thank Loa Andersson for his comments and 801 recommendation to merge drafts. 803 12. Contributors 805 The following are key contributors to this document: 807 Hannes Gredler, RtBrick, Inc. 809 Tarek Saad, Cisco Systems, Inc. 811 Siva Sivabalan, Cisco Systems, Inc. 813 Balaji Rajagopalan, Juniper Networks 815 Faisal Iqbal, Cisco Systems, Inc. 817 13. References 819 13.1. Normative References 821 [I-D.ietf-spring-segment-routing] 822 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 823 and R. Shakir, "Segment Routing Architecture", draft-ietf- 824 spring-segment-routing-12 (work in progress), June 2017. 826 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 827 Requirement Levels", BCP 14, RFC 2119, 828 DOI 10.17487/RFC2119, March 1997, 829 . 831 [RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing 832 in Multi-Protocol Label Switching (MPLS) Networks", 833 RFC 3443, DOI 10.17487/RFC3443, January 2003, 834 . 836 [RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in 837 Support of Generalized Multi-Protocol Label Switching 838 (GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005, 839 . 841 [RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions 842 in Support of Generalized Multi-Protocol Label Switching 843 (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008, 844 . 846 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 847 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 848 Switched (MPLS) Data-Plane Failures", RFC 8029, 849 DOI 10.17487/RFC8029, March 2017, 850 . 852 13.2. Informative References 854 [I-D.ietf-isis-segment-routing-extensions] 855 Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., 856 Litkowski, S., Decraene, B., and j. jefftant@gmail.com, 857 "IS-IS Extensions for Segment Routing", draft-ietf-isis- 858 segment-routing-extensions-13 (work in progress), June 859 2017. 861 [I-D.ietf-ospf-ospfv3-segment-routing-extensions] 862 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 863 Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3 864 Extensions for Segment Routing", draft-ietf-ospf-ospfv3- 865 segment-routing-extensions-10 (work in progress), 866 September 2017. 868 [I-D.ietf-ospf-segment-routing-extensions] 869 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 870 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 871 Extensions for Segment Routing", draft-ietf-ospf-segment- 872 routing-extensions-19 (work in progress), August 2017. 874 [I-D.ietf-spring-segment-routing-ldp-interop] 875 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., and 876 S. Litkowski, "Segment Routing interworking with LDP", 877 draft-ietf-spring-segment-routing-ldp-interop-08 (work in 878 progress), June 2017. 880 [I-D.ietf-spring-segment-routing-mpls] 881 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 882 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 883 data plane", draft-ietf-spring-segment-routing-mpls-10 884 (work in progress), June 2017. 886 [IANA-MPLS-LSP-PING] 887 IANA, "Multi-Protocol Label Switching (MPLS) Label 888 Switched Paths (LSPs) Ping Parameters", 889 . 892 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 893 RFC 792, DOI 10.17487/RFC0792, September 1981, 894 . 896 Authors' Addresses 898 Nagendra Kumar (editor) 899 Cisco Systems, Inc. 900 7200-12 Kit Creek Road 901 Research Triangle Park, NC 27709-4987 902 US 904 Email: naikumar@cisco.com 906 Carlos Pignataro (editor) 907 Cisco Systems, Inc. 908 7200-11 Kit Creek Road 909 Research Triangle Park, NC 27709-4987 910 US 912 Email: cpignata@cisco.com 914 George Swallow 915 Southend Technical Center 917 Email: swallow.ietf@gmail.com 918 Nobo Akiya 919 Big Switch Networks 921 Email: nobo.akiya.dev@gmail.com 923 Sriganesh Kini 924 Individual 926 Email: sriganeshkini@gmail.com 928 Mach(Guoyi) Chen 929 Huawei 931 Email: mach.chen@huawei.com