idnits 2.17.1 draft-arora-mpls-spring-ttl-procedures-srte-paths-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC3443], [RFC8029]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 75 has weird spacing: '... egress route...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: When the node advertising the Binding SID is operating in short pipe model [RFC3443], it SHOULD not send FEC stack change sub-TLV. The Binding SID is treated as single hop and the nodes internal to the Tunnel represented by Binding SID SHOULD NOT be traced. -- The document date (February 21, 2019) is 1884 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC8012' is mentioned on line 381, but not defined ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Routing area K. Arora 3 Internet-Draft S. Hegde 4 Intended status: Standards Track Juniper Networks Inc. 5 Expires: August 25, 2019 S. Aldrin 6 Google 7 S. Litkowski 8 Orange Business Service 9 M. Durrani 10 Equinix 11 February 21, 2019 13 TTL Procedures for SR-TE Paths in Label Switched Path Traceroute 14 Mechanisms 15 draft-arora-mpls-spring-ttl-procedures-srte-paths-01 17 Abstract 19 Segment routing supports the creation of explicit paths using 20 adjacency-sids, node-sids, and anycast-sids. The SR-TE paths are 21 built by stacking the labels that represent the nodes and links in 22 the explicit path. A very useful Operations And Maintenance 23 requirement is to be able to trace these paths as defined in 24 [RFC8029]. This document specifies a uniform mechanism to support 25 MPLS traceroute for the SR-TE paths when the nodes in the network are 26 following uniform mode or short-pipe mode [RFC3443]. 28 Requirements Language 30 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 31 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 32 document are to be interpreted as described in RFC 2119 [RFC2119]. 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 August 25, 2019. 50 Copyright Notice 52 Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Problem with SR-TE Paths . . . . . . . . . . . . . . . . . . 3 69 2.1. Short Pipe model . . . . . . . . . . . . . . . . . . . . 4 70 2.2. Uniform Model . . . . . . . . . . . . . . . . . . . . . . 4 71 3. Detailed Solution For TTL procedures for SR-TE paths . . . . 5 72 3.1. P bit in DDMT TLV . . . . . . . . . . . . . . . . . . . . 5 73 3.1.1. Procedures for a PHP router of the tunnel being 74 traced . . . . . . . . . . . . . . . . . . . . . . . 5 75 3.1.2. Procedures for a egress router of the tunnel being 76 traced . . . . . . . . . . . . . . . . . . . . . . . 5 77 3.1.3. Procedures for a ingress router of the SR-TE path . . 5 78 3.1.4. Example describing the solution . . . . . . . . . . . 6 79 3.2. Procedures for handling binding-sids . . . . . . . . . . 7 80 3.2.1. Uniform Model . . . . . . . . . . . . . . . . . . . . 7 81 3.2.2. Shortpipe Model . . . . . . . . . . . . . . . . . . . 8 82 4. Backward Compatibility . . . . . . . . . . . . . . . . . . . 8 83 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 84 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 85 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 86 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 87 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 88 8.2. Informative References . . . . . . . . . . . . . . . . . 9 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 91 1. Introduction 93 The mechanisms to handle TTL procedures for SR-TE paths are described 94 in ([RFC8287]). Section 7.5 of ([RFC8287]) defines the TTL 95 manipulation procedures for short pipe model as below.The LSR 96 initiating the traceroute SHOULD start by setting the TTL to 1 for 97 the tunnel in the LSP's label stack it wants to start the tracing 98 from, the TTL of all outer labels in the stack to the max value, and 99 the TTL of all the inner labels in the stack to zero. However this 100 mechanism has issues when the constituent tunnels are penultimate- 101 hop-popping(PHP). This document does not propose any change to 102 ([RFC8287]) if the constituent tunnels are ultimate-hop-popping (UHP) 103 or Egress LSR advertizes explicit NULL. 105 Section 2 describes problems in tracing SR-TE paths and the need for 106 a specialized mechanism to trace SR-TE paths. Section 3 describes 107 the solution applied to mpls echo request/response to trace 108 adjacency-sids and node-sids trace SR-TE path in uniform model and 109 short pipe model. 111 2. Problem with SR-TE Paths 113 The topology shown in Figure 1. illustrates a example network 114 topology with SPRING enabled on each node. 116 Node Node Node Node 117 sid:1 sid:2 sid:3 sid:4 118 +----+ 10 +----+ 10 +----+ 10 +----+ 119 | R1 |--------| R2 |--------| R3 |--------| R4 | 120 +----+ +----+ +----+ +----+ 122 Label stack: 123 +------------+ 124 | 1003 (top)| 125 +------------+ 126 | 1004 | 127 +------------+ 129 Figure 1: Example topology with SRGB 1000-2000 131 Consider an explicit path in the topology in Figure 1 from R1->R4 via 132 R1->R2->R3->R4. The label stack to instantiate this path contains 133 two node-sids 1003 and 1004. The 1003 label will take the packet 134 from R1 to R3. The next label in the stack 1004 will take the packet 135 from R3 to the destination R4. consider the mechanism below for the 136 TTL procedures specified in RFC 8287 for short pipe model and uniform 137 model for PHP LSPs. 139 Notation: ((X,Y),(Z,W)) refers to a label stack whose top label stack 140 entry has the label corresponding to the node-SID of X, with TTL Y, 141 and whose second label stack entry has the label corresponding to the 142 node-SID of Z, with TTL W. 144 According to the procedure in Section 7.5 of [RFC8287], the LSP 145 traceroute is done as follows in short pipe model and uniform model: 147 2.1. Short Pipe model 149 Refer the diagram in Figure 1. 151 1. Ingress R1 sends mpls LSP Echo Request with label stack of 152 ((1003,1),(1004,0)) to R2. 154 2. Since R2 receives mpls LSP Echo Request with TTL as 1 for outer 155 most label, R2's local software processes the Lsp traceroute packet 156 and R2 sends an echo reply to R1 with return code as 'transit'. 158 3. R1 receives the LSP Echo Reply from R2, and then sends next LSP 159 Echo Request with label stack ((1003,2),(1004,0)). 161 4. R2 forwards packet to R3 as ((1004,0)) (i.e. R2 being PHP, pops 162 the label 1003 and does not propagate TTL) 164 5. R3 receives a packet with TTL=0 at the top of the stack. Receipt 165 of a packet with TTL=0 may cause R3 to drop the packet or rate limit 166 it. 168 6. Even if R3's local software processes the packet and validates 169 the FEC for 1003 and sends egress code in echo-reply, the next packet 170 will have ((1003,255), (1004, 1)) which causes TTL to expire again on 171 R3 as the 1003 label is popped at the penultimate. 173 RFC 8287 suggests that when R1's LSP Echo Request has reached the 174 egress of the outer tunnel, R1 should begin to trace the inner tunnel 175 by sending a LSP Echo Request with label stack ((1003,255),(1004,1)). 176 However, as explained in step 6, the traceroute procedure does not 177 work correctly. 179 2.2. Uniform Model 181 1. Ingress R1 sends mpls LSP Echo Request with label stack of 182 ((1003,1),(1004,0)) to R2. 184 2. Since R2 receives mpls LSP Echo Request with TTL as 1 for outer 185 most label, R2's local software processes the Lsp ping packet and R2 186 sends an echo reply to R1 with return code as 'transit'. 188 3. R1 receives the LSP Echo Reply from R2, and then sends next LSP 189 Echo Request with label stack ((1003,2),(1004,0)). 191 4. It is expected that R2 should propogate the TTL of outer label to 192 inner label before forwarding the packet to R3. However most of the 193 PFEs implementations generally do not increase a label stack entry's 194 TTL when they do TTL propagation. So when (1003,2) is popped, we 195 might still end up with (1004,0) at R3, even if we have TTL 196 propagation configured. Increasing the TTL of a packet is not a good 197 practice as it can result in forwarding loops. 199 5. R3 receives a packet with TTL=0 at the top of the stack. Receipt 200 of a packet with TTL=0 will cause R3 to drop the packet or rate limit 201 it. 203 6. Even if R3's local software processes the packet and validates 204 the FEC for 1003 and sends egress code in echo-reply, the next packet 205 will have ((1003,255), (1004, 1)) which causes TTL to expire again on 206 R3 as the 1003 label is popped at the penultimate. 208 So in either case (uniform model or short pipe model) traceroute may 209 not work for SR-TE paths with PHP Lsps. 211 3. Detailed Solution For TTL procedures for SR-TE paths 213 3.1. P bit in DDMT TLV 215 DS flags has 4 unused bits from position '0' to '3'. This document 216 uses bit '3' in DS flags of downstream mapping TLV. 218 3.1.1. Procedures for a PHP router of the tunnel being traced 220 When a LSR receives an echo request it MUST validate the outermost 221 FEC in the echo request. LSR SHOULD set the 'P' bit in the DS flags 222 of downstream mapping TLV if its a PHP router for the outermost FEC. 223 Other cases it should work as explained in [RFC8029] and [RFC8287]. 225 3.1.2. Procedures for a egress router of the tunnel being traced 227 When a LSR receives an echo request it MUST validate the outermost 228 FEC in the echo request. Egress cases should work as explained in 229 [RFC8029] and [RFC8287]. 231 3.1.3. Procedures for a ingress router of the SR-TE path 233 When an ingress LSR receives an echo response it MUST behave as 234 defined below depending on the return code in the echo response. 236 1. When an ingress LSR receives an echo response with return code as 237 8 (Label switched at stack-depth), Ingress LSR MUST check if the LSR 238 that sent the echo response is PHP for the outermost FEC in the FEC 239 stack. If the LSR that sent the echo response is PHP for the 240 outermost FEC then while sending next echo request Ingress LSR MUST 241 increase the TTL value of inner label also (if exists) in addition to 242 increasing the TTL value of the tunnel it is tracing. Ingress LSR 243 can detect that LSR that sent the echo response is a PHP router for 244 the outermost FEC, either by looking at 'P' bit set in the DS flags 245 of downstream mapping TLV or if Ingress LSR has received LABEL '3' in 246 the label stack TLV of downstream detailed mapping TLV. For all 247 other cases ingress should work as explained in [RFC8029] and 248 [RFC8287]. 250 2. When an Ingress LSR receives an echo response with return code as 251 3 (Replying router is an egress for the FEC at stack-depth) for the 252 outermost FEC and this is not the only FEC in the FEC stack, then 253 ingress LSR SHOULD remove the outermost FEC from the FEC stack and 254 send the next traceroute request with the same TTL value for all the 255 labels in the label stack as the previous echo request. This will 256 ensure the egress of the tunnel is visited twice, once as egress for 257 top label and again as a transit for next tunnel. 259 3.1.4. Example describing the solution 261 This section provides a detailed description of how PHP router helps 262 ingress in handling TTL procedures for SR-TE paths. Below are the 263 procedures performed by PHP router and ingress router to perform TTL 264 procedure for mpls traceroute for SR-TE paths. Below solution works 265 for both uniform model and short pipe model. 267 1. Ingress R1 sends mpls LSP Echo Request with label stack of 268 ((1003,1),(1004,0)) to R2. 270 2. Since R2 receives mpls LSP Echo Request with TTL as 1 for outer 271 most label, R2's local software processes the Lsp ping packet. R2's 272 local software validates the outermost FEC and looking at the FEC R2 273 knows that its the PHP router for outermost FEC (Node-Sid R3). 275 3. R2 sets a bit in the DS flags in the DDMT TLV in echo response (P 276 bit, One of the reserved bits). 278 4. When R1 looks at the echo response from R2 it sees P bit in DDMT 279 TLV. 281 5. So R1 increments the TTL value of Node-R3 by 1 (make it 2) and 282 TTL value of next element in the label stack also 284 6. R1 should send the next mpls LSP Echo Request with label stack 285 ((1003,2),(1004,1)). 287 7. R2 being PHP pops the outermost label from the label stack and 288 forwards the packet to R3 with with label (1004, 1) 290 8. R3 receives mpls LSP Echo Request with TTL as 1 for outer most 291 label, R3's local software processes the echo request. 293 9. R3 validates the outermost FEC and sends echo response to R1 with 294 return code as the egress for outermost FEC (Node-Sid R3). 296 10. When R1 receives echo response with return code as egress, R1 297 should remove outermost FEC (Node-Sid R3) from the FEC stack and send 298 the next echo request with the same TTL value as the previous one i.e 299 ((1003,2),(1004,1)). 301 11. Since R3 is the PHP router for FEC (Node-Sid R4) in the label 302 stack. R3 should set 'P' bit in the in the DS flags in the DDMT TLV 303 in echo response with return code as Transit. 305 12. R1 should send the next mpls LSP Echo Request with label stack 306 ((1003,2),(1004,2)) with FEC Node-Sid-R4 . 308 13. R2 pops the first label from the label stack and R3 pops the 309 second label from the label stack. 311 14. R4 receives an unlabelled packet with RA bit set in ip options. 312 R4 delivers the packet to local software for processing. 314 15. R4's local software validates the ouetmost FEC as 'egress' and 315 sends an echo reply with return code as egress. 317 17. R1 receives an echo reply with return code as egress for the 318 last FEC in the FEC stack TLV and completes the traceroute. 320 3.2. Procedures for handling binding-sids 322 Inorder to provide greater scalability, network opacity, and service 323 independence, SR architecture [RFC8402] defines a Binding SID (BSID). 324 A Binding SID is bound to an SR policy which typically involves a 325 list of SIDs. These Binding SIDs may appear in another SR Policy or 326 may be used to steer service traffic from the service origin. The 327 TTL handling mechanisms for MPLS traceroute procedures involving 328 Binding SIDs is described below. 330 3.2.1. Uniform Model 332 When the node advertising the Binding SID is operating in uniform 333 mode [RFC3443], it SHOULD send FEC stack change sub-TLV as in sec 334 4.5.1 of [RFC8029]. The ingress node SHOULD increment the TTL of 335 Binding SID label at every step until "egress" return code is sent 336 for all the new FECs included due to FEC stack change and all the 337 Tunnels replaced by the Binding SID are completely traced. It is 338 required that all the label popping nodes involved in these tunnels 339 MUST support uniform model and copy the TTL to bottom label when the 340 label is popped. 342 3.2.2. Shortpipe Model 344 When the node advertising the Binding SID is operating in short pipe 345 model [RFC3443], it SHOULD not send FEC stack change sub-TLV. The 346 Binding SID is treated as single hop and the nodes internal to the 347 Tunnel represented by Binding SID SHOULD NOT be traced. 349 4. Backward Compatibility 351 The extension proposed in this document is backward compatible with 352 procedures described in [RFC8029] and [RFC8287]. If the LSR with the 353 proposed solution is the Ingress and all other LSR in the SR tunnel 354 are not with the extension, Then no LSR is going to set 'P' bit so 355 ingress LSR with new extension will work as per [RFC8029] and 356 [RFC8287].If the LSR with the proposed extension is the one of the 357 transit router and if its the PHP then it may set 'P' bit based on 358 the section 3. Ingress may not react to the 'P' bit and traceroute 359 will continue to work as per [RFC8029] and [RFC8287]. 361 5. Security Considerations 363 TBD 365 6. IANA Considerations 367 IANA has created and now maintains a registry entitled "DS Flags". 368 The registration policy for this registry is Standards Action 369 [RFC5226]. IANA has made the following assignments: 371 Bit Number Name Reference 373 ---------- ------------------------------------------- --------- 375 7 N: Treat as a Non-IP Packet [RFC8029] 377 6 I: Interface and Label Stack Object Request [RFC8029] 379 5 E: ELI/EL push indicator [RFC8012] 381 4 L: Label-based load balance indicator [RFC8012] 382 3 P: Penulimate Hop router 384 2-0 Unassigned 386 7. Acknowledgements 388 Thanks to Przemyslaw Krol for careful review and comments. 390 8. References 392 8.1. Normative References 394 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 395 Requirement Levels", BCP 14, RFC 2119, 396 DOI 10.17487/RFC2119, March 1997, 397 . 399 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 400 IANA Considerations Section in RFCs", RFC 5226, 401 DOI 10.17487/RFC5226, May 2008, 402 . 404 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 405 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 406 Switched (MPLS) Data-Plane Failures", RFC 8029, 407 DOI 10.17487/RFC8029, March 2017, 408 . 410 [RFC8287] Kumar, N., Ed., Pignataro, C., Ed., Swallow, G., Akiya, 411 N., Kini, S., and M. Chen, "Label Switched Path (LSP) 412 Ping/Traceroute for Segment Routing (SR) IGP-Prefix and 413 IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data 414 Planes", RFC 8287, DOI 10.17487/RFC8287, December 2017, 415 . 417 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 418 Decraene, B., Litkowski, S., and R. Shakir, "Segment 419 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 420 July 2018, . 422 8.2. Informative References 424 [RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing 425 in Multi-Protocol Label Switching (MPLS) Networks", 426 RFC 3443, DOI 10.17487/RFC3443, January 2003, 427 . 429 Authors' Addresses 431 Kapil Arora 432 Juniper Networks Inc. 433 Exora Business Park 434 Bangalore, KA 560103 435 India 437 Email: kapilaro@juniper.net 439 Shraddha Hegde 440 Juniper Networks Inc. 441 Exora Business Park 442 Bangalore, KA 560103 443 India 445 Email: shraddha@juniper.net 447 Sam Aldrin 448 Google 450 Email: aldrin.ietf@gmail.com 452 Stephane Litkowski 453 Orange Business Service 455 Email: stephane.litkowski@orange.com 457 Muhammad Durrani 458 Equinix 460 Email: mdurrani@equinix.com