idnits 2.17.1 draft-ietf-mpls-spring-lsp-ping-08.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 20, 2017) is 2410 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 24, 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 20, 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-08 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 24, 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 . . . . . . . . . . . . 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 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 290 Section 3.5 of [I-D.ietf-spring-segment-routing]. The format is as 291 below: 293 0 1 2 3 294 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | Adj. Type | Protocol | Reserved | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | Local Interface ID (4 or 16 octets) | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | Remote Interface ID (4 or 16 octets) | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 ~ ~ 303 | Advertising Node Identifier (4 or 6 octets) | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 ~ ~ 306 | Receiving Node Identifier (4 or 6 octets) | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 Adj. Type (Adjacency Type) 311 Set to 1, when the Adjacency Segment is Parallel Adjacency as 312 defined in Section 3.4.1 of [I-D.ietf-spring-segment-routing]. 313 Set to 4, when the Adjacency segment is IPv4 based and is not a 314 parallel adjacency. Set to 6, when the Adjacency segment is IPv6 315 based and is not a parallel adjacency. Set to 0, when the 316 Adjacency segment is over unnumbered interface. 318 Protocol 320 Set to 1, if the Responder MUST perform FEC validation using OSPF 321 as IGP protocol. Set to 2, if the Responder MUST perform Egress 322 FEC validation using ISIS as IGP protocol. Set to 0, if Responder 323 can use any IGP protocol for Egress FEC validation. 325 Local Interface ID 327 An identifier that is assigned by local LSR for a link on which 328 Adjacency Segment ID is bound. This field is set to local link 329 address (IPv4 or IPv6). Incase of unnumbered, 32 bit link 330 identifier defined in [RFC4203], [RFC5307] is used. If the 331 Adjacency Segment ID represents parallel adjacencies 332 (Section 3.4.1 of [I-D.ietf-spring-segment-routing]) this field 333 MUST be set to 4 bytes of zero. 335 Remote Interface ID 337 An identifier that is assigned by remote LSR for a link on which 338 Adjacency Segment ID is bound. This field is set to remote 339 (downstream neighbor) link address (IPv4 or IPv6). In case of 340 unnumbered, 32 bit link identifier defined in [RFC4203], [RFC5307] 341 is used. If the Adjacency Segment ID represents parallel 342 adjacencies (Section 3.4.1 of [I-D.ietf-spring-segment-routing]) 343 this field MUST be set to 4 bytes of zero. 345 Advertising Node Identifier 347 Specifies the advertising node identifier. When Protocol is set 348 to 1, then the 32 rightmost bits represent OSPF Router ID and if 349 protocol is set to 2, this field carries 48 bit ISIS System ID. 351 Receiving Node Identifier 353 Specifies the downstream node identifier. When Protocol is set to 354 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 6. Extension to Downstream Detailed Mapping TLV 359 In an echo reply, the Downstream Mapping TLV [RFC8029] is used to 360 report for each interface over which a FEC could be forwarded. For a 361 FEC, there are multiple protocols that may be used to distribute 362 label mapping. The "Protocol" field of the Downstream Detailed 363 Mapping TLV is used to return the protocol that is used to distribute 364 the label carried in "Downstream Label" field. The following 365 protocols are defined in Section 3.4.1.2 of [RFC8029]: 367 Protocol # Signaling Protocol 368 ---------- ------------------ 369 0 Unknown 370 1 Static 371 2 BGP 372 3 LDP 373 4 RSVP-TE 375 With segment routing, OSPF or ISIS can be used for label 376 distribution, this document adds two new protocols as follows: 378 Protocol # Signaling Protocol 379 ---------- ------------------ 380 5 OSPF 381 6 ISIS 383 7. Procedures 385 This section describes aspects of LSP Ping and traceroute operations 386 that require further considerations beyond [RFC8029]. 388 7.1. FECs in Target FEC Stack TLV 390 When LSP echo request packets are generated by an initiator, FECs 391 carried in Target FEC Stack TLV may need to have deviating contents. 392 This document outlines expected Target FEC Stack TLV construction 393 mechanics by initiator for known scenarios. 395 Ping 397 Initiator MUST include FEC(s) corresponding to the destination 398 segment. 400 Initiator MAY include FECs corresponding to some or all of 401 segments imposed in the label stack by the initiator to 402 communicate the segments traversed. 404 Traceroute 406 Initiator MUST initially include FECs corresponding to all of 407 segments imposed in the label stack. 409 When a received echo reply contains FEC Stack Change TLV with 410 one or more of original segment(s) being popped, initiator MAY 411 remove corresponding FEC(s) from Target FEC Stack TLV in the 412 next (TTL+1) traceroute request as defined in Section 4.6 of 413 [RFC8029]. 415 When a received echo reply does not contain FEC Stack Change 416 TLV, initiator MUST NOT attempt to remove FEC(s) from Target 417 FEC Stack TLV in the next (TTL+1) traceroute request. 419 As defined in [I-D.ietf-ospf-segment-routing-extensions] and 420 [I-D.ietf-isis-segment-routing-extensions], Prefix SID can be 421 advertised as absolute value, index or as range. In any of these 422 cases, Initiator MUST derive the Prefix mapped to the Prefix SID and 423 use it in IGP-Prefix Segment ID defined in Section 5.1 and 5.2. 425 7.2. FEC Stack Change sub-TLV 427 Section 3.4.1.3 of [RFC8029] defines FEC Stack Change sub-TLV that a 428 router must include when the FEC stack changes. 430 The network node which advertised the Node Segment ID is responsible 431 for generating FEC Stack Change sub-TLV of pop operation for Node 432 Segment ID, regardless of whether PHP is enabled or not. 434 The network node that is immediate downstream of the node which 435 advertised the Adjacency Segment ID is responsible for generating FEC 436 Stack Change sub-TLV for "POP" operation for Adjacency Segment ID. 438 7.3. Segment ID POP Operation 440 The forwarding semantic of Node Segment ID with PHP flag is 441 equivalent to usage of implicit Null in MPLS protocols. Adjacency 442 Segment ID is also similar in a sense that it can be thought of as 443 locally allocated segment that has PHP enabled destined for next hop 444 IGP adjacency node. Procedures described in Section 4.4 of [RFC8029] 445 relies on Stack-D and Stack-R explicitly having Implicit Null value. 446 It may simplify implementations to reuse Implicit Null for Node 447 Segment ID PHP and Adjacency Segment ID cases. 449 7.4. Segment ID Check 451 This section updates the procedure defined in Section 4.4.1 of 452 [RFC8029]. Step 4 defined in Section 4.4.1 of [RFC8029] is updated 453 as below: 455 4. If the label mapping for FEC is Implicit Null, set FEC-status to 456 2 and proceed to step 5. Otherwise, if the label mapping for FEC 457 is Label-L, proceed to step 5. Otherwise, set FEC-return-code to 458 10 ("Mapping for this FEC is not the given label at stack- 459 depth"), set FEC-status to 1, and return. 461 4a. Segment Routing IGP Prefix and Adjacency SID Validation: 463 If the Label-stack-depth is 0 and Target FEC Stack Sub-TLV at 464 FEC-stack-depth is 34 (IPv4 IGP-Prefix Segment ID), { 466 Set Best return code to 10, "Mapping for this FEC is not the 467 given label at stack-depth " if any below conditions 468 fail: 470 /* The responder LSR is to check if it is the egress of the 471 IPv4 IGP-Prefix Segment ID described in the Target FEC Stack 472 Sub-TLV, and if the FEC was advertised with the PHP bit 473 set.*/ 475 - Validate that Node Segment ID is advertised for IPv4 476 Prefix by IGP Protocol{ 478 o When protocol field in received IPv4 IGP-Prefix 479 Segment ID Sub-TLV is 0, Use any locally enabled IGP 480 protocol. 482 o When protocol field in received IPv4 IGP-Prefix 483 Segment ID Sub-TLV is 1, Use OSPF as IGP protocol. 485 o When protocol field in received IPv4 IGP-Prefix 486 Segment ID Sub-TLV is 2, Use ISIS as IGP protocol. 488 o When protocol field in received IPv4 IGP-Prefix 489 Segment ID Sub-TLV is any other value, it MUST be 490 treated as Protocol value of 0. 492 } 494 - Validate that Node Segment ID is advertised with No-PHP 495 flag { 497 o When Protocol is OSPF, NP-flag defined in Section 5 of 498 [I-D.ietf-ospf-segment-routing-extensions] MUST be set 499 to 0. 501 o When Protocol is ISIS, P-Flag defined in Section 2.1 502 of [I-D.ietf-isis-segment-routing-extensions] MUST be 503 set to 0. 505 } 507 set FEC-Status to 1, and return. 509 } 511 Else if the Label-stack-depth is greater than 0 and Target FEC 512 Stack Sub-TLV at FEC-stack-depth is 34 (IPv4 IGP-Prefix Segment 513 ID), { 515 Set Best return code to 10 if any below conditions fail: 517 - Validate that Node Segment ID is advertised for IPv4 518 Prefix by IGP Protocol { 520 o When protocol field in received IPv4 IGP-Prefix 521 Segment ID Sub-TLV is 0, Use any locally enabled IGP 522 protocol. 524 o When protocol field in received IPv4 IGP-Prefix 525 Segment ID Sub-TLV is 1, Use OSPF as IGP protocol. 527 o When protocol field in received IPv4 IGP-Prefix 528 Segment ID Sub-TLV is 2, Use ISIS as IGP protocol. 530 o When protocol field in received IPv4 IGP-Prefix 531 Segment ID Sub-TLV is any other value, it MUST be 532 treated as Protocol value of 0. 534 } 536 set FEC-Status to 1, and return. 538 } 540 Else if the Label-stack-depth is 0 and Target FEC Sub-TLV at 541 FEC-stack-depth is 35 (IPv6 IGP-Prefix Segment ID), { 543 Set Best return code to 10 if any of the below conditions 544 fail: 546 /* The LSR needs to check if its being a tail-end for the 547 LSP and have the prefix advertised with PHP bit set*/ 549 - Validate that Node Segment ID is advertised for IPv6 550 Prefix by IGP Protocol { 552 o When protocol field in received IPv6 IGP-Prefix 553 Segment ID Sub-TLV is 0, Use any locally enabled IGP 554 protocol. 556 o When protocol field in received IPv6 IGP-Prefix 557 Segment ID Sub-TLV is 1, Use OSPF as IGP protocol. 559 o When protocol field in received IPv6 IGP-Prefix 560 Segment ID Sub-TLV is 2, Use ISIS as IGP protocol. 562 o When protocol field in received IPv6 IGP-Prefix 563 Segment ID Sub-TLV is any other value, it MUST be 564 treated as Protocol value of 0. 566 } 568 - Validate that Node Segment ID is advertised with No-PHP 569 flag. { 571 o When Protocol is OSPF, NP-flag defined in Section 5 of 572 [I-D.ietf-ospf-ospfv3-segment-routing-extensions] MUST 573 be set to 0. 575 o When Protocol is ISIS, P-Flag defined in Section 2.1 576 of [I-D.ietf-isis-segment-routing-extensions] MUST be 577 set to 0. 579 } 581 set FEC-Status to 1, and return. 583 } 585 Else if the Label-stack-depth is greater than 0 and Target FEC 586 Sub-TLV at FEC-stack-depth is 35 (IPv6 IGP-Prefix Segment ID), 587 { 589 set Best return code to 10 if any below conditions fail: 591 - Validate that Node Segment ID is advertised for IPv4 592 Prefix by IGP Protocol { 594 o When protocol field in received IPv6 IGP-Prefix 595 Segment ID Sub-TLV is 0, Use any locally enabled IGP 596 protocol. 598 o When protocol field in received IPv6 IGP-Prefix 599 Segment ID Sub-TLV is 1, Use OSPF as IGP protocol. 601 o When protocol field in received IPv6 IGP-Prefix 602 Segment ID Sub-TLV is 2, Use ISIS as IGP protocol. 604 o When protocol field in received IPv6 IGP-Prefix 605 Segment ID Sub-TLV is any other value, it MUST be 606 treated as Protocol value of 0. 608 } 610 set FEC-Status to 1, and return. 612 } 614 Else if the Target FEC sub-TLV at FEC-stack-depth is 36 (IGP- 615 Adjacency Segment ID), { 617 set Best return code to TBD1 (Section 10.3) if any below 618 conditions fail: 620 When the Adj. Type is 1 (Parallel Adjacency): 622 o Validate that Receiving Node Identifier is local IGP 623 identifier. 625 o Validate that IGP-Adjacency Segment ID is advertised 626 by Advertising Node Identifier of Protocol in local 627 IGP database { 629 * When protocol field in received IGP-Adjacency 630 Segment ID Sub-TLV is 0, Use any locally enabled 631 IGP protocol. 633 * When protocol field in received IGP-Adjacency 634 Segment ID Sub-TLV is 1, Use OSPF as IGP protocol. 636 * When protocol field in received IGP-Adjacency 637 Segment ID Sub-TLV is 2, Use ISIS as IGP protocol. 639 * When protocol field in received IGP-Adjacency 640 Segment ID Sub-TLV is any other value, it MUST be 641 treated as Protocol value of 0. 643 } 645 When the Adj. Type is 4 or 6 (IGP Adjacency or LAN 646 Adjacency): 648 o Validate that Remote Interface ID matches the local 649 identifier of the interface (Interface-I) on which the 650 packet was received. 652 o Validate that Receiving Node Identifier is local IGP 653 identifier. 655 o Validate that IGP-Adjacency Segment ID is advertised 656 by Advertising Node Identifier of Protocol in local 657 IGP database { 659 * When protocol field in received IGP-Adjacency 660 Segment ID Sub-TLV is 0, Use any locally enabled 661 IGP protocol. 663 * When protocol field in received IGP-Adjacency 664 Segment ID Sub-TLV is 1, Use OSPF as IGP protocol. 666 * When protocol field in received IGP-Adjacency 667 Segment ID Sub-TLV is 2, Use ISIS as IGP protocol. 669 * When protocol field in received IGP-Adjacency 670 Segment ID Sub-TLV is any other value, it MUST be 671 treated as Protocol value of 0. 673 } 675 set FEC-Status to 1, and return. 677 } 679 7.5. TTL Consideration for traceroute 681 LSP Traceroute operation can properly traverse every hop of Segment 682 Routing network in Uniform Model described in [RFC3443]. If one or 683 more LSRs employ Short Pipe Model described in [RFC3443], then LSP 684 Traceroute may not be able to properly traverse every hop of Segment 685 Routing network due to absence of TTL copy operation when outer label 686 is popped. Short Pipe being the most commonly used model. The 687 following TTL manipulation technique MAY be used when Short Pipe 688 model is used. 690 When tracing a LSP according to the procedures in [RFC8029] the TTL 691 is incremented by one in order to trace the path sequentially along 692 the LSP. However when a source routed LSP has to be traced there are 693 as many TTLs as there are labels in the stack. The LSR that 694 initiates the traceroute SHOULD start by setting the TTL to 1 for the 695 tunnel in the LSP's label stack it wants to start the tracing from, 696 the TTL of all outer labels in the stack to the max value, and the 697 TTL of all the inner labels in the stack to zero. Thus a typical 698 start to the traceroute would have a TTL of 1 for the outermost label 699 and all the inner labels would have TTL 0. If the FEC Stack TLV is 700 included it should contain only those for the inner stacked tunnels. 701 The Return Code/Subcode and FEC Stack Change TLV should be used to 702 diagnose the tunnel as described in [RFC8029]. When the tracing of a 703 tunnel in the stack is complete, then the next tunnel in the stack 704 should be traced. The end of a tunnel can be detected from the 705 "Return Code" when it indicates that the responding LSR is an egress 706 for the stack at depth 1. Thus the traceroute procedures in 707 [RFC8029] can be recursively applied to traceroute a source routed 708 LSP. 710 8. Backward Compatibility with non Segment Routing devices 712 [I-D.ietf-spring-segment-routing-ldp-interop] describes how Segment 713 Routing operates in network where SR-capable and non-SR-capable nodes 714 coexist. In such networks, there may not be any FEC mapping in the 715 responder when the Initiator is SR-capable while the responder is not 716 (or vice-versa). But this is not different from RSVP and LDP interop 717 scenarios. When LSP Ping is triggered, the responder will set the 718 FEC-return-code to Return 4, "Replying router has no mapping for the 719 FEC at stack-depth". 721 Similarly when SR-capable node assigns Adj-SID for non-SR-capable 722 node, LSP traceroute may fail as the non-SR-capable node is not aware 723 of "IGP Adjacency Segment ID" sub-TLV and may not reply with FEC 724 Stack change. This may result in any further downstream nodes to 725 reply back with Return-code as 4, "Replying router has no mapping for 726 the FEC at stack-depth". 728 9. IANA Considerations 730 9.1. New Target FEC Stack Sub-TLVs 732 IANA is requested to assign three new Sub-TLVs from "Sub-TLVs for TLV 733 Types 1, 16 and 21" sub-registry from the "Multi-Protocol Label 734 Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" 735 [IANA-MPLS-LSP-PING] registry. 737 Sub-Type Sub-TLV Name Reference 738 -------- ----------------- ------------ 739 34 IPv4 IGP-Prefix Segment ID Section 5.1 of this document 740 35 IPv6 IGP-Prefix Segment ID Section 5.2 of this document 741 36 IGP-Adjacency Segment ID Section 5.3 of this document 743 9.2. Protocol in Label Stack Sub-TLV of Downstream Detailed Mapping TLV 745 IANA is requested to create a new "Protocol" registry under the 746 "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) 747 Ping Parameters" registry. Code points in the range of 0-250 will be 748 assigned by Standards Action. The range of 251-254 are reserved for 749 experimental use and will not be assigned. The initial entries into 750 the registry will be. 752 Value Meaning Reference 753 ---------- ---------------- ------------ 754 0 Unknown Section 3.4.1.2 of RFC8029 755 1 Static Section 3.4.1.2 of RFC8029 756 2 BGP Section 3.4.1.2 of RFC8029 757 3 LDP Section 3.4.1.2 of RFC8029 758 4 RSVP-TE Section 3.4.1.2 of RFC8029 759 5 OSPF Section 6 of this document 760 6 ISIS Section 6 of this document 761 7-250 Unassigned 762 251-254 Experimental use This document 763 255 Reserved This document 765 9.3. Return Code 767 IANA is requested to assign a new Return Code from the "Multi- 768 Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping 769 Parameters" in "Return Codes" Sub-registry. 771 Value Meaning Reference 772 ---------- ----------------- ------------ 773 TBD1 Mapping for this FEC is not associated Section 7.4 of 774 with the incoming interface this document 776 Note to the RFC Editor (please remove before publication): IANA has 777 made early allocation for sub-type 34, 35 and 35. The early 778 allocation expires 2017-09-15. 780 10. Security Considerations 782 This document defines additional Sub-TLVs and follows the mechanism 783 defined in [RFC8029]. So all the security consideration defined in 784 [RFC8029] will be applicable for this document and in addition it 785 does not impose any security challenges to be considered. 787 11. Acknowledgement 789 The authors would like to thank Stefano Previdi, Les Ginsberg, Balaji 790 Rajagopalan, Harish Sitaraman, Curtis Villamizar, Pranjal Dutta, 791 Lizhong Jin, Tom Petch, Victor Ji and Mustapha Aissaoui, Tony 792 Przygienda, Alexander Vainshtein for their review and comments. 794 The authors wold like to thank Loa Andersson for his comments and 795 recommendation to merge drafts. 797 12. Contributors 799 The following are key contributors to this document: 801 Hannes Gredler, RtBrick, Inc. 803 Tarek Saad, Cisco Systems, Inc. 805 Siva Sivabalan, Cisco Systems, Inc. 807 Balaji Rajagopalan, Juniper Networks 809 Faisal Iqbal, Cisco Systems, Inc. 811 13. References 813 13.1. Normative References 815 [I-D.ietf-spring-segment-routing] 816 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 817 and R. Shakir, "Segment Routing Architecture", draft-ietf- 818 spring-segment-routing-12 (work in progress), June 2017. 820 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 821 Requirement Levels", BCP 14, RFC 2119, 822 DOI 10.17487/RFC2119, March 1997, 823 . 825 [RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing 826 in Multi-Protocol Label Switching (MPLS) Networks", 827 RFC 3443, DOI 10.17487/RFC3443, January 2003, 828 . 830 [RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in 831 Support of Generalized Multi-Protocol Label Switching 832 (GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005, 833 . 835 [RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions 836 in Support of Generalized Multi-Protocol Label Switching 837 (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008, 838 . 840 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 841 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 842 Switched (MPLS) Data-Plane Failures", RFC 8029, 843 DOI 10.17487/RFC8029, March 2017, 844 . 846 13.2. Informative References 848 [I-D.ietf-isis-segment-routing-extensions] 849 Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., 850 Litkowski, S., Decraene, B., and j. jefftant@gmail.com, 851 "IS-IS Extensions for Segment Routing", draft-ietf-isis- 852 segment-routing-extensions-13 (work in progress), June 853 2017. 855 [I-D.ietf-ospf-ospfv3-segment-routing-extensions] 856 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 857 Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3 858 Extensions for Segment Routing", draft-ietf-ospf-ospfv3- 859 segment-routing-extensions-10 (work in progress), 860 September 2017. 862 [I-D.ietf-ospf-segment-routing-extensions] 863 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 864 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 865 Extensions for Segment Routing", draft-ietf-ospf-segment- 866 routing-extensions-19 (work in progress), August 2017. 868 [I-D.ietf-spring-segment-routing-ldp-interop] 869 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., and 870 S. Litkowski, "Segment Routing interworking with LDP", 871 draft-ietf-spring-segment-routing-ldp-interop-08 (work in 872 progress), June 2017. 874 [I-D.ietf-spring-segment-routing-mpls] 875 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 876 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 877 data plane", draft-ietf-spring-segment-routing-mpls-10 878 (work in progress), June 2017. 880 [IANA-MPLS-LSP-PING] 881 IANA, "Multi-Protocol Label Switching (MPLS) Label 882 Switched Paths (LSPs) Ping Parameters", 883 . 886 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 887 RFC 792, DOI 10.17487/RFC0792, September 1981, 888 . 890 Authors' Addresses 892 Nagendra Kumar (editor) 893 Cisco Systems, Inc. 894 7200-12 Kit Creek Road 895 Research Triangle Park, NC 27709-4987 896 US 898 Email: naikumar@cisco.com 900 Carlos Pignataro (editor) 901 Cisco Systems, Inc. 902 7200-11 Kit Creek Road 903 Research Triangle Park, NC 27709-4987 904 US 906 Email: cpignata@cisco.com 908 George Swallow 909 Southend Technical Center 911 Email: swallow.ietf@gmail.com 913 Nobo Akiya 914 Big Switch Networks 916 Email: nobo.akiya.dev@gmail.com 917 Sriganesh Kini 918 Individual 920 Email: sriganeshkini@gmail.com 922 Mach(Guoyi) Chen 923 Huawei 925 Email: mach.chen@huawei.com