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