idnits 2.17.1 draft-geib-spring-oam-opt-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (28 October 2020) is 1276 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 2991 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force R. Geib, Ed. 2 Internet-Draft Deutsche Telekom 3 Intended status: Best Current Practice 28 October 2020 4 Expires: 1 May 2021 6 An MPLS SR OAM option reducing the number of end-to-end path validations 7 draft-geib-spring-oam-opt-00 9 Abstract 11 MPLS traceroute implementations validate dataplane connectivity and 12 isolate faults by sending messages along every end-to-end Label 13 Switched Path (LSP) combination between a source and a destination 14 node. This requires a growing number of path validations in networks 15 with a high number of equal cost paths between origin and 16 destination. Segment Routing (SR) introduces MPLS topology awareness 17 combined with Source Routing. By this combination, SR can be used to 18 implement an MPLS traceroute option lowering the total number of LSP 19 validations as compared to commodity MPLS traceroute. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on 1 May 2021. 38 Copyright Notice 40 Copyright (c) 2020 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 45 license-info) in effect on the date of publication of this document. 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. Code Components 48 extracted from this document must include Simplified BSD License text 49 as described in Section 4.e of the Trust Legal Provisions and are 50 provided without warranty as described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 56 2. MPLS OAM adding MPLS SR mechanisms . . . . . . . . . . . . . 5 57 2.1. Operation in an SR MPLS domain applying only IP-header 58 based ECMP . . . . . . . . . . . . . . . . . . . . . . . 6 59 2.2. Operation in an SR MPLS domain additionally using incoming 60 interface information for ECMP . . . . . . . . . . . . . 7 61 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 62 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 63 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 64 5.1. Normative References . . . . . . . . . . . . . . . . . . 9 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 67 1. Introduction 69 Commodity MPLS isn't topology aware and it offers no standard source 70 routing methods. It is reasonable to validate connectivity and 71 locate faults of MPLS LSPs by detecting and testing all existing LSP 72 combinations between a source and a destination node. The source 73 node originates all MPLS echo requests and evaluates all MPLS echo 74 replies. Operational MPLS OAM implementations were present, when SR 75 MPLS entered standardisation. They continue to work reliably in many 76 cases. MPLS domains with a high number of equal cost paths between 77 source and destination nodes push the detection capabilities of 78 commodity MPLS OAM to the limit. So far, modes of MPLS OAM operation 79 adding Segment Routing functionality to deal with limitations of 80 commodity MPLS OAM have not been published within IETF. 82 This draft assumes readers to be aware of MPLS OAM functionality as 83 specified by RFC 8029 [RFC8029] and RFC 8287 [RFC8287]. The function 84 described in the following works for Shortest Path First Paths or 85 Label stacks based on MPLS Node-SID and MPLS Adj-SIDs (if the latter 86 are distributed by Interior Gateway Protocols). 88 Networks supporting a high number of equivalent cost paths between 89 source and destination nodes require a high number of completed MPLS 90 path validations. Consider a network with Multiple equal cost paths, 91 as shown in figure 1. 93 +-R120-+ 94 / \ 95 8 12 96 / \ 97 R110--8--R121--4--R130 98 / \ 99 4 numbers indicate 4 100 / parallel links \ 101 RS RD 102 \ symmetric to / 103 4...upper network ...4 105 Figure 1 107 Figure 1: Multiple equal cost path example network. 109 The total number of MPLS LSP combinations between nodes RS and RD is 110 multiplicative by the number of (equal cost, so to say) links per 111 hop. That results in a maximum of 4096=2*4*(8*12+8*4)*4 path 112 combinations which a commodity MPLS may try to validate. Assume RS 113 to start an MPLS traceroute to RD containing a Multipath Data Sub-TLV 114 requesting Multipath information for 32 IP-addresses. By Equal Cost 115 Multipath routing (ECMP, [RFC2991]) traffic of likely 16 of these IP- 116 addresses is forwarded via R110 as next hop (the other 16 addresses 117 are assumed to be forwarded along the symmetric and equal cost paths 118 in the lower half, which are omitted in the figure for brevity). 119 R110 can be expected to respond by an MPLS echo reply indicating 120 prefixes to address each of the 4 equal cost (sub-)paths between RS 121 and R110. 123 R110 is able to forward traffic addressed by these 16 IP addresses 124 via 16 equal cost paths. There's a fairly high probability that this 125 will not be possible, as some of R110's availble paths to forwards 126 traffic to RD will be receive traffic of two or even three IP 127 addresses, while others receive no traffic at all. The MPLS Echo 128 Reply sent to RS will indicate that. A commodity solution is, to 129 start an additional MPLS traceroute with 32 different IP-addresses. 130 This may help to then enable forwaring traffic along all of R110's 131 paths to RD via R120 and R121, respectively. With bad luck, R110 132 will forward only 14 or 15 addresses via R120. R120 forwards traffic 133 along 12 equal cost paths to RD. Then again, there's a fair chance 134 that more IP-addresses are required to forward at least one MPLS echo 135 request along all of them. Per new set of addresses, the MPLS Echo- 136 Request / Reply dialogue must be completed starting from RS to at 137 least all routers along the path to R120. 139 R110 is able to forward traffic addressed by these 16 IP addresses 140 via 16 equal cost paths. There's a fairly high probability that some 141 of R110's availble paths to forward traffic to RD will receive 142 traffic of two or even three of these IP addresses, while other paths 143 receive no traffic at all. The MPLS Echo Reply returned to RS will 144 indicate that. A commodity solution is, to start an additional MPLS 145 traceroute to check the routes for 32 different IP-addresses. Note 146 that again traffic with 16 of these IP addresses is likely to be 147 routed to the omitted symmetric part of the example network. The 148 remaining additional 16 IP addresses forwarded to R110 however help 149 to then enable forwaring traffic along all of R110's paths to RD via 150 R120 and R121, respectively. With bad luck, R110 might forward only 151 14 or 15 addresses via R120. R120 forwards traffic along 12 equal 152 cost paths to RD. Then again, there's a fair chance that more IP- 153 addresses are required to forward at least one MPLS echo request 154 along all of them. For every additional new set of IP-addresses, the 155 MPLS Echo-Request / Reply dialogue must be completed starting from RS 156 to at least all routers along the path to R120. In the example, 157 roughly only a fourth of the addresses whose forwarding is validated 158 starting from node RS will be routed via R120. The ECMP "filters 159 away" 75% of the available addresses. If all 32 IP-addresses were 160 reaching R120, the probability of being unable to forward at least 161 one MPLS Echo request to each outgoing interface (or path, 162 respectively) to node RD was rather small. 164 The reason for completing all MPLS Echo Request / Reply dialogues 165 along the path between RS and R120 is figuring out, which IP 166 addresses are routed from R110 to R120 to be available at the latter 167 for forwarding traffic along paths to RD which can't be addressed 168 otherwise. RFC 8029 section 4.1 'Dealing with Equal-Cost Multipath 169 (ECMP)' concludes, that 'full coverage may not be possible' 170 [RFC8029]. 172 Segment Routing (SR) allows node RS to forward MPLS Echo Request 173 packets with up to, e.g, 32 IP addresses to every node which RS 174 detects on a path to node RD. Doing so reduces the number of path 175 options to be checked to no more than the sum of the interfaces 176 belonging to one of the ECMP routes between nodes RS and RD. In the 177 case of the example network above, this sum is 2*(4+8+8+12+4+4)=80. 178 That means, that around 2% of the messages required with commodity 179 MPLS traceroute implementations are sufficient to validate all local 180 forwarding options (note that the calculations aren't exact, they 181 rather indicate orders of magnitude). The commodity MPLS OAM 182 implementations are neither broken nor not working. SR allows to add 183 a new method to the router local MPLS OAM implementations to reliably 184 validate also high numbers of ECMP routes. The method proposed 185 results reduces the number of MPLS Echo-Request / -Reply dialogues to 186 be stored and completed in that case. 188 The functions specified by this document do not require changes in 189 the MPLS OAM protocol as specified by [RFC8029] and [RFC8287]. 191 1.1. Requirements Language 193 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 194 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 195 document are to be interpreted as described in RFC 2119 [RFC2119]. 197 2. MPLS OAM adding MPLS SR mechanisms 199 MPLS Segment Routing (SR) provides each node of an MPLS SR domain 200 with this domain's MPLS Node-SID topology [RFC8402]. The SR source 201 routing feature allows to forward packets to each individual node 202 within a SR domain. Combining topology awareness and source routing 203 allows complete validation of all local router shortest path 204 forwarding options from an RS node to an RD node in a domain 205 supporting ECMP. 207 Suppose SR to be deployed in the case of the example network and 208 digits following the letter "R" to indicate the corresponding Node- 209 SIDs. Assume "mixed operation" of commodity MPLS OAM and the option 210 applying SR. RS starts a commodity MPLS Echo request to R110. After 211 having received an MPLS Echo reply from R110 indicating local paths 212 of R110 on which none of the packets with the remaing 16 IP addresses 213 will be forwarded, RS creates an MPLS Echo Request which transports 214 the original 32 IP addresses to R110. To do so, an additional top- 215 Segment is pushed carrying the R110 Node-SID, 110. The message below 216 that additional segment is coded as a standard RFC8287 MPLS Echo 217 request. Two things are special: the TTL of the MPLS header 218 containing the Node SID of RD is always set to 1. Further, a 219 seperate sequence number series needs to be started to distinguish 220 the starting point of this SR using MPLS OAM sequence. Coding space 221 for MPLS OAM Sender's Handle and Sequence Number offer sufficient 222 coding space [RFC8029]. If PHP is active, the R110 Node-SID is 223 implicitly present only on the link to a neighboring node. Still 224 packets with all 32 IP-destination addresses are forwarded to R110. 225 The chances to address all of the 16 ECMP paths of R110 to RD with 226 the originally configured 32 IP-addresses increase. The same method 227 is repeated for R120. Now the top Segment picked by node RS is the 228 Node-SID of R120, again with a separate Sender's Handle and Sequence 229 Number combination. Note, that the MPLS Echo request destined to 230 R120 doesn't require execution of MPLS OAM functions in R110. That 231 latter node simply forwards the packet to R120. Also R120 receives 232 32 IP-addresses (which is a significant increase as compared to 233 commodity MPLS OAM). 235 As a result, the MPLS Echo reply tables maintained by RS likely 236 indicate ECMP several forwarding masks of the same IP address range 237 (discerned by the starting node receiving the MPLS Echo request with 238 top Segment TTL=1). For every path at an indermediate node, to which 239 the latter can't foward an MPLS Echo request due to the limited 240 number of available IP-addresses, a suitable SR top segement is added 241 for an additional next MPLS Echo request of node RS. This in the end 242 allows to circumvent the IP-address filtering effect caused by ECMP. 244 Being able to forward a "complete" set of IP addresses to any 245 interface along an end-to-end path is helpful in locating errors. 246 Different MPLS OAM addressing options also offer more possibilities 247 to test and unambiguosly locate a faultily sub-path. 249 2.1. Operation in an SR MPLS domain applying only IP-header based ECMP 251 The basic operation is to transport an MPLS Echo request from the 252 sender node sequentially to a next hop identified on any of the paths 253 to a destination node. This is done by applying standard SR 254 methodology, which here consists of pushing one additional Node-SID 255 on top of the Label-stack to be validated by the sender node. The 256 Node-SID is set to the value of the node, whose forwarding plane 257 information is requested by the MPLS Echo request. This is 258 illustrated by figure 2. 260 0 1 2 3 261 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 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 |Node-SID of the node whose forwarding information is requested | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | | 266 + Sender node MPLS Echo request + 267 | | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 Figure 2 272 Figure 2: MPLS OAM Label Stack in the case of IP-header only based 273 ECMP. 275 The added Node-SID is only added to use standard MPLS forwarding. 276 The TTL of this added Node-SID set to the default value for traffic 277 injected by the sending router. The MPLS-TC may be set to a value 278 ensuring reliable transport up to the node, whose forwarding 279 information is requested by the sender node (be aware of MPLS-TC 280 treatment of the node popping this added Node-SID in that case). 282 The TTL of the top Label of the sender node MPLS Echo request which 283 is contained below the added Node-SID initially is set to TTL=1. 284 Other TTL values can be picked if LSPs from the intermediate node 285 onwards to the destination node of that FEC are desired to be traced 286 or pinged by MPLS OAM messages. 288 Two modes of operation exist: either applying legacy MPLS OAM and 289 adding the described functionality as required or only applying the 290 option specified here. Note that the exact path from the sender node 291 to the intermediate node identified by the pushed Node-SID is only 292 known to the node originating and maintaining the MPLS traceroute 293 information, if only one path exists between that sender node and an 294 intermediate node. 296 If the method is added to commodity MPLS OAM functions, the 297 originatior IP-address of an MPLS Echo-reply indicating a lack of IP- 298 addresses to forward traffic along all ECMP egress interfaces at that 299 intermediate node can be used to derive the Node-SID to be pushed by 300 the MPLS Echo request sender node. 302 2.2. Operation in an SR MPLS domain additionally using incoming 303 interface information for ECMP 305 This option can only be applied, if the Segment Routing domain's Adj- 306 SID topology is known to the node originating MPLS Echo Request 307 messages. Configuring the the Interior Gateway Protocol to 308 distribute Adj-SIDs conveniently enables that. If ECMP is 309 additionally using the incoming interface of a packet for path 310 selection, an Adj-SID is added between the Node-SID and the MPLS Echo 311 request. As the idea is to determine the incoming interface of the 312 node, whose ECMP path choices are requested by MPLS OAM, the 313 additionaly pushed Node-SID here is that of the node preceding the 314 intermediate node, whose forwarding information is requested. The 315 Adj-SID is chosen to correspond to a specific incoming interface of 316 the intermediate node whose forwarding information is requested. As 317 the aim of that test is to ensure that every incoming to outgoing 318 interface path choice of the intermediate node can be addressed, the 319 topology information required to identify the upstream Adj-SID 320 corresponding to an incoming interface of the intermediate node is 321 assumed to be present and maintained in the originating node. This 322 additional MPLS to IP topology excerpt information results from prior 323 MPLS path validations of the same basic set of MPLS path validations 324 between the source node and the destination node (this is to express, 325 that no extra measurement effort is caused, as correlation of 326 available information is sufficient). The resulting label stack is 327 illustrated by figure 3. 329 0 1 2 3 330 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 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 |Node-SID of node preceding the node whose fwd info is requested| 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 |Adj-SID corresp. to inc-IF of node whose fwd info is requested | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | | 337 + Sender node MPLS Echo request + 338 | | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 Figure 3 343 Figure 3: MPLS OAM Label Stack applying SR features if ECMP is 344 additionally based on incoming interfaces. 346 In the network example of figure 1, node RS picks the Node-SID of 347 R110 and an Adj-SID of R110 corresponding to a particular incoming 348 interface of R120, if the latter's ECMP path also depends on the 349 incoming interface, by which the MPLS Echo request was received. 351 Here, the full set of original IP-addresses can be forwarded 352 individually per incoming interface of the router whose MPLS 353 forwarding information is requested. In the example above, it is 354 node R120 (not node R110.) Monitoring incoming interface based ECMP 355 results in a higher number of MPLS OAM validations, no matter whether 356 commodity MPLS OAM is applied or the option specified here. The 357 overall sum of tests now is determinde by the sum of per node 358 incoming * outgoing paths ( or interfaces, respectively). If the 359 method specified here is applied in the case of the example network, 360 2*(4*8 + 4*8 + 8*12 + 8*4 + 12*4 + 4*4) = 512 MPLS Echo-Request / 361 Response validations are required. Note that this is still a 362 smaller number than the original 4096 path validations in the case of 363 comodity MPLS OAM required for a domain applying ECMP based on IP- 364 address information only. Note that the number of required MPLS OAM 365 path validations is increasing significantly, if ECMP forwarding is 366 in addition based on incoming interfaces and the product of a nodes 367 incoming * outgoing interfaces is high. 369 3. IANA Considerations 371 This memo includes no request to IANA. 373 4. Security Considerations 375 This document does not introduce new functionality. It combines 376 Segment Routing functions with those of MPLS OAM. The related 377 security sections apply, see [RFC8029] and [RFC8402]. 379 5. References 381 5.1. Normative References 383 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 384 Requirement Levels", BCP 14, RFC 2119, 385 DOI 10.17487/RFC2119, March 1997, 386 . 388 [RFC2991] Thaler, D. and C. Hopps, "Multipath Issues in Unicast and 389 Multicast Next-Hop Selection", RFC 2991, 390 DOI 10.17487/RFC2991, November 2000, 391 . 393 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Kumar Nainar, 394 N., Aldrin, S., and M. Chen, "Detecting Multiprotocol 395 Label Switched (MPLS) Data-Plane Failures", RFC 8029, 396 DOI 10.17487/RFC8029, March 2017, 397 . 399 [RFC8287] Kumar Nainar, N., Pignataro, C., Swallow, G., Akiya, N., 400 Kini, S., and M. Chen, "Label Switched Path (LSP) Ping/ 401 Traceroute for Segment Routing (SR) IGP-Prefix and IGP- 402 Adjacency Segment Identifiers (SIDs) with MPLS Data 403 Planes", RFC 8287, DOI 10.17487/RFC8287, December 2017, 404 . 406 [RFC8402] Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 407 Litkowski, S., and R. Shakir, "Segment Routing 408 Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018, 409 . 411 Author's Address 413 Ruediger Geib (editor) 414 Deutsche Telekom 415 Heinrich Hertz Str. 3-7 416 64295 Darmstadt 417 Germany 419 Phone: +49 6151 5812747 420 Email: Ruediger.Geib@telekom.de