idnits 2.17.1 draft-kompella-mpls-nffrr-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 : ---------------------------------------------------------------------------- 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 (November 02, 2020) is 1265 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: 'L1' is mentioned on line 395, but not defined == Missing Reference: 'L2' is mentioned on line 397, but not defined == Missing Reference: 'L3' is mentioned on line 281, but not defined == Missing Reference: 'L4' is mentioned on line 283, but not defined == Missing Reference: 'L5' is mentioned on line 293, but not defined == Missing Reference: 'L6' is mentioned on line 295, but not defined == Missing Reference: 'L3 L2' is mentioned on line 346, but not defined == Missing Reference: 'L4 L2' is mentioned on line 336, but not defined == Missing Reference: 'L5 L2' is mentioned on line 340, but not defined == Missing Reference: 'L6 L2' is mentioned on line 342, but not defined == Missing Reference: 'NFFRR L2' is mentioned on line 403, but not defined == Missing Reference: 'L20 L21' is mentioned on line 422, but not defined == Missing Reference: 'T1 S2' is mentioned on line 487, but not defined == Missing Reference: 'T3 S3' is mentioned on line 473, but not defined == Missing Reference: 'T2 S2' is mentioned on line 469, but not defined == Outdated reference: A later version (-08) exists of draft-ietf-idr-next-hop-capability-06 == Outdated reference: A later version (-14) exists of draft-ietf-mpls-rmr-13 Summary: 0 errors (**), 0 flaws (~~), 19 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS WG K. Kompella 3 Internet-Draft W. Lin 4 Intended status: Standards Track Juniper Networks 5 Expires: May 6, 2021 November 02, 2020 7 No Further Fast Reroute 8 draft-kompella-mpls-nffrr-01 10 Abstract 12 There are several cases where, once Fast Reroute has taken place (for 13 MPLS protection), a second fast reroute is undesirable, even 14 detrimental. This memo gives several examples of this, and proposes 15 a mechanism to prevent further fast reroutes. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on May 6, 2021. 34 Copyright Notice 36 Copyright (c) 2020 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1. Other Approaches . . . . . . . . . . . . . . . . . . . . 3 53 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2.1. EVPN (VPN/VPLS) Active-active Multihoming . . . . . . . . 3 56 2.2. RMR Protection . . . . . . . . . . . . . . . . . . . . . 4 57 2.3. General MPLS forwarding . . . . . . . . . . . . . . . . . 5 58 3. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 3.1. NFFRR for MPLS forwarding . . . . . . . . . . . . . . . . 6 60 3.2. Proposal . . . . . . . . . . . . . . . . . . . . . . . . 8 61 3.2.1. NFFRR and SPRING . . . . . . . . . . . . . . . . . . 10 62 3.3. NFFRR for MPLS Services . . . . . . . . . . . . . . . . . 10 63 3.4. NFFRR for RMR . . . . . . . . . . . . . . . . . . . . . . 11 64 4. Signaling NFFRR Capability . . . . . . . . . . . . . . . . . 12 65 4.1. Signaling NFFRR Capability for MPLS Services with BGP . . 12 66 4.2. Signaling NFFRR Capability for MPLS Services with 67 Targeted LDP . . . . . . . . . . . . . . . . . . . . . . 12 68 4.3. Signaling NFFRR Capability for MPLS Forwarding . . . . . 12 69 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 71 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 72 7.1. Normative References . . . . . . . . . . . . . . . . . . 13 73 7.2. Informative References . . . . . . . . . . . . . . . . . 14 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 76 1. Introduction 78 MPLS Fast Reroute (FRR) [RFC4090] [RFC5286] [RFC7490] is a useful and 79 widely deployed tool for minimizing packet loss in the case of a link 80 or node failure. This has not only proven to be very effective, it 81 is often the reason for using MPLS as a data plane. FRR works for a 82 variety of control plane protocols, including LDP, RSVP-TE, and 83 SPRING. Furthermore, FRR is often used to protect MPLS services such 84 as IP VPN and EVPN. 86 Having said this, there are case where, once FRR has taken place, if 87 the packet encounters a second failure, a second FRR is not helpful, 88 perhaps even disruptive. For example, the packet may loop until TTL 89 expires. This can lead to link congestion and further packet loss. 90 Thus, the attempt to prevent a packet from being dropped may instead 91 affect many other packets. Note that the "second" failure may simply 92 be another manifestation of the same failure; see Figure 1. 94 This memo proposes a mechanism for preventing further FRR once in 95 cases where such further protection may be harmful. Several examples 96 where this is the case are demonstrated as motivation. A solution 97 using special-purpose labels (SPLs) is then offered. Some mechanisms 98 for distributing the capability to avoid further fast reroutes are 99 also discussed, although these may be better placed in other 100 documents in other Working Groups. 102 1.1. Other Approaches 104 [ALDT] has a more elaborate mechanism for preventing loops due to 105 multiple failures. This involves marking the nodes redirecting 106 traffic in a header (either individually, or as node groups), and 107 dropping the packet at a transit node if its ID is in the header. 109 1.2. Terminology 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 113 "OPTIONAL" in this document are to be interpreted as described in BCP 114 14 [RFC2119] [RFC8174] when, and only when, they appear in all 115 capitals, as shown here. 117 2. Motivation 119 A few cases are given where "further fast reroute" is harmful. Some 120 of the cases are for MPLS services; others for "plain" MPLS 121 forwarding. 123 2.1. EVPN (VPN/VPLS) Active-active Multihoming 125 Consider the following topology for multihoming an Ethernet VPN (EVPN 126 [RFC7432]) Customer Edge (CE) device for protection against the 127 failure of a Provider Edge (PE) device or a PE-CE link. To do so, 128 there is a backup MPLS path between PE2 and PE3 (denoted by the 129 starred line). 131 P1 ... ... P3 --- PE2 132 / * \ link1 133 / * \ 134 CE1 --- PE1 * CE2 135 \ * / 136 \ * / link2 137 P2 ... ... P4 --- PE3 139 Figure 1: EVPN Multihoming 141 Suppose (known unicast) traffic goes from CE1 to CE2. With active- 142 active multihoming, this traffic will be load-balanced between PE2 143 (to CE2 via link link1) and PE3 (to CE2 via link2). If link1 were to 144 fail, PE2 can still get traffic for CE2 by sending it over the backup 145 path to PE3 (and similarly for PE3 if link2 fails). 147 However, suppose CE2 is down. PE2 will assume link1 is down and send 148 traffic for CE2 to PE3 over the backup path. PE3 (which thinks that 149 link2 is down; note that the single real failure of CE2 being down is 150 manifested as separate failures to PE2 and PE3) will protect this 151 "second" failure by sending traffic for CE2 over the backup path to 152 PE2. Thus, traffic will ping-pong between PE2 and PE3 until TTL 153 expires. 155 Thus, the attempt to protect traffic to CE2 may end up doing more 156 harm than good, by congesting the backup path between PE2 and PE3 and 157 by giving PE2 and PE3 useless work to do. 159 A similar topology can be used in EVPN-Etree [RFC8317], EVPN-VPWS 160 [RFC8214], IP VPN [RFC4364] or VPLS [RFC4761] [RFC4762]. In all 161 these cases, the same looping behavior would occur for unicast 162 traffic if CE2 is down. 164 2.2. RMR Protection 166 R0 . . . R1 167 . . 168 R7 R2 169 Anti- | . . | 170 Clockwise | . Ring . | Clockwise 171 v . . v 172 R6 R3 173 . . 174 R5 . . . R4 176 Figure 2: RMR Looping 178 In Resilient MPLS Rings (RMR), suppose traffic goes from a node, say 179 R0, to a node, say R4, over a clockwise path. Protection consists of 180 switching this traffic onto the anti-clockwise path to R4. This 181 works well if a node or link between R0 or R4 is down. However, if 182 node R4 itself is down, its adjacent neighbor R3, will send the 183 traffic anti-clockwise to R4; when this traffic reaches R4's other 184 neighbor R5, it will return to N3, and so on, until TTL expires. 185 [I-D.ietf-mpls-rmr] provides more details, and offers some means of 186 mitigation. This memo offers a more elegant solution. 188 2.3. General MPLS forwarding 190 Consider the following topology: 192 N1 --- N2 --- N3 --- N4 193 | | 194 | | 195 N5 --- N6 --- N7 --- N8 196 | | 197 | | 198 N9 --- N10 200 Figure 3: General MPLS Forwarding 202 Say link protection is configured for links N2-N3 and N6-N7. Link 203 N2-N3 is protected by a bypass tunnel N2-N6-N7-N3, and link N7-N3 is 204 protected by a bypass tunnel N7-N6-N2-N3. (These bypass tunnels may 205 be set up using RSVP-TE [RFC3209] or via SPRING stacks [RFC8660].) 206 Say furthermore that there is an LSP from N1 to N4 with path 207 N1-N2-N3-N4, which asks for link protection. If link N2-N3 fails, 208 traffic will take the path N1-N2-N6-N7-N3-N4. 210 Suppose, however, links N2-N3 and N7-N3 fail simultaneously. This 211 may happen if they share fate (e.g., go over a common fiber conduit); 212 it may also appear to happen if node N3 fails. Either way, first, 213 the bypass protecting link N2-N3 kicks in, and traffic is sent to N3 214 via N6 and N7. However, when the traffic hits N7, the bypass for 215 N7-N3 kicks in, and traffic is sent back to N2. Thus the traffic 216 will loop between N2 and N7 until TTL expires, in the process 217 congesting links N2-N6 and N6-N7. 219 Now consider an LSP: N5-N6-N7-N8. The link N6-N7 may be protected by 220 the bypass N6-N2-N3-N7 or by N6-N9-N10-N7, or by load-balancing 221 between these two bypasses. If both links N2-N3 and N6-N7 fail, then 222 traffic that is protected via bypass N6-N2-N3-N7 will ping-pong 223 between N6 and N2 until TTL expires; traffic protected via bypass 224 N6-N9-N10-N7 will successfully make it to N8. If link N6-N7 is 225 protected by load-balancing across the two bypass paths, then about 226 half the traffic will loop between N6 and N2, and the rest will make 227 it to N8. 229 While the above description is for protection using a bypass tunnel, 230 the same principle applies to protection using Loop-Free Alternates 231 [RFC5286] [RFC7490] or any of its variants (such as Topology 232 Independent LFA). 234 3. Solution 236 To address this issue, we suggest the use of a SPL [RFC7274] called 237 NFFRR (value TBD; suggested: 8). An alternate would be to use an 238 extended SPL, whereby a pair of labels indicates that no further fast 239 route is desired. However, in the case of SPRING MPLS bypass tunnels 240 (Section 3.2.1) of depth N, this would triple the label stack size. 241 Using regular SPLs instead would only double the stack size. 243 3.1. NFFRR for MPLS forwarding 245 To illustrate, we'll first take the example of Figure 3, with MPLS 246 paths signaled using RSVP-TE. This method can be used for paths that 247 use SPRING stacks, but this will be detailed in a later version. 249 N1 --- N2 --- N3 --- N4 LSP N1 to N4: L1->L2->null 250 | | Bypass for N2-N3: L3->L4->null 251 | | Bypass for N7-N3: L5->L6->null 252 N5 --- N6 --- N7 --- N8 LSP N5 to N8: L7->L8->null 253 | | Bypass1 for N6-N7: L9->L10->null 254 | | Bypass2 for N6-N7: L11->L12->null 255 N9 --- N10 (via N9-N10-N7) 257 Figure 4: Example Using RSVP-TE LSPs 259 +------+----------+------+----------+----------+ 260 | Node | Action | Next | New Pkt | Comment | 261 +------+----------+------+----------+----------+ 262 | N1 | push L1 | N2 | [L1] pkt | ingress | 263 | | | | | | 264 | N2 | L1 -> L2 | N3 | [L2] pkt | | 265 | | | | | | 266 | N3 | pop L2 | N4 | pkt | PHP | 267 | | | | | | 268 | N4 | fwd pkt | - | - | continue | 269 +------+----------+------+----------+----------+ 271 Table 1: Forwarding from N1 to N4 273 Note 1: "[L1 ...]" denotes the label stack on the packet; pkt is the 274 original packet received at ingress. "L1 -> L2" means swap label L1 275 with L2. "pop L2" means pop the top label L2. "fwd pkt" means 276 forward the packet as usual. 278 +------+----------+------+----------+---------+ 279 | Node | Action | Next | New Pkt | Comment | 280 +------+----------+------+----------+---------+ 281 | N2 | push L3 | N6 | [L3] pkt | ingress | 282 | | | | | | 283 | N6 | L3 -> L4 | N7 | [L4] pkt | | 284 | | | | | | 285 | N7 | pop L4 | N3 | pkt | PHP | 286 +------+----------+------+----------+---------+ 288 Table 2: Forwarding over the bypass for link N2-N3 290 +------+----------+------+----------+---------+ 291 | Node | Action | Next | New Pkt | Comment | 292 +------+----------+------+----------+---------+ 293 | N7 | push L5 | N6 | [L5] pkt | ingress | 294 | | | | | | 295 | N6 | L5 -> L6 | N2 | [L6] pkt | | 296 | | | | | | 297 | N2 | pop L6 | N3 | pkt | PHP | 298 +------+----------+------+----------+---------+ 300 Table 3: Forwarding over Bypass1 for link N7-N3 302 +------+----------+------+-------------+----------+ 303 | Node | Action | Next | New Pkt | Comment | 304 +------+----------+------+-------------+----------+ 305 | N1 | push L1 | N2 | [L1] pkt | ingress | 306 | | | | | | 307 | N2 | L1 -> L2 | N3 | [L2] pkt | N3 X | 308 | | | | | | 309 | N2 | push L3 | N6 | [L3 L2] pkt | PLR | 310 | | | | | | 311 | N6 | L3 -> L4 | N7 | [L4 L2] pkt | | 312 | | | | | | 313 | N7 | pop L4 | N3 | [L2] pkt | merge | 314 | | | | | | 315 | N3 | pop L2 | N4 | pkt | PHP | 316 | | | | | | 317 | N4 | fwd pkt | - | - | continue | 318 +------+----------+------+-------------+----------+ 320 Table 4: Forwarding from N1 to N4 if link N2-N3 fails 322 Table 4 is obtained by composing Table 1 and Table 2. 324 Note 2: "N3 X" means "next hop N3 unavailable (because link N2-N3 325 failed)". 327 +------+----------+------+-------------+---------+ 328 | Node | Action | Next | New Pkt | Comment | 329 +------+----------+------+-------------+---------+ 330 | N1 | push L1 | N2 | [L1] pkt | ingress | 331 | | | | | | 332 | N2 | L1 -> L2 | N3 | [L2] pkt | N3 X | 333 | | | | | | 334 | N2 | push L3 | N6 | [L3 L2] pkt | PLR | 335 | | | | | | 336 | N6 | L3 -> L4 | N7 | [L4 L2] pkt | | 337 | | | | | | 338 | N7 | pop L4 | N3 | [L2] pkt | N3 X' | 339 | | | | | | 340 | N7 | push L5 | N6 | [L5 L2] pkt | | 341 | | | | | | 342 | N6 | L5 -> L6 | N2 | [L6 L2] pkt | PLR | 343 | | | | | | 344 | N2 | pop L6 | N3 | [L2] pkt | N3 X | 345 | | | | | | 346 | N2 | push L3 | N6 | [L3 L2] | PLR | 347 | | | | | | 348 | etc | | | | loop! | 349 +------+----------+------+-------------+---------+ 351 Table 5: Forwarding from N1 to N4 if links N2-N3 and N7-N3 fail 353 Table 5 is obtained by composing Table 1, Table 2 and Table 3. 355 Note 3: "N3 X'" means "next hop N3 unavailable because link N7-N3 is 356 down. 358 Note 4: While the impact of a loop is pretty bad, the impact of an 359 ever-growing label stack (not illustrated here) and possible 360 associated fragmentation on transit nodes may be worse. 362 3.2. Proposal 364 An LSR (typically a PLR) that wishes to prevent further FRRs after 365 the first one can push an SPL, namely NFFRR, onto the label stack as 366 follows: 368 +------+----------------+------+-------------------+----------+ 369 | Node | Action | Next | New Pkt | Comment | 370 +------+----------------+------+-------------------+----------+ 371 | N1 | push L1 | N2 | [L1] pkt | ingress | 372 | | | | | | 373 | N2 | L1 -> L2 | N3 | [L2] pkt | N3 X | 374 | | | | | | 375 | N2 | push L3, NFFRR | N6 | [L3 NFFRR L2] pkt | PLR | 376 | | | | | | 377 | N6 | L3 -> L4 | N7 | [L4 NFFRR L2] pkt | | 378 | | | | | | 379 | N7 | pop L4, NFFRR | N3 | [L2] pkt | merge | 380 | | | | | | 381 | N3 | pop L2 | N4 | pkt | PHP | 382 | | | | | | 383 | N4 | fwd pkt | - | - | continue | 384 +------+----------------+------+-------------------+----------+ 386 Table 6: Forwarding from N1 to N4 if link N2-N3 fails with NFFRR 388 Note 5: N2 can insert an NFFRR label only if it knows that all LSRs 389 in the path can process it correctly. See Section 4 for some details 390 on how this capability is communicated. 392 +------+----------------+------+-------------------+----------+ 393 | Node | Action | Next | New Pkt | Comment | 394 +------+----------------+------+-------------------+----------+ 395 | N1 | push L1 | N2 | [L1] pkt | ingress | 396 | | | | | | 397 | N2 | L1 -> L2 | N3 | [L2] pkt | N3 X | 398 | | | | | | 399 | N2 | push L3, NFFRR | N6 | [L3 NFFRR L2] pkt | PLR | 400 | | | | | | 401 | N6 | L3 -> L4 | N7 | [L4 NFFRR L2] pkt | | 402 | | | | | | 403 | N7 | pop L4 | N3 | [NFFRR L2] pkt | N3 X | 404 | | | | | | 405 | N7 | check NFFRR | - | - | drop pkt | 406 +------+----------------+------+-------------------+----------+ 408 Table 7: Forwarding from N1 to N4 if links N2-N3 and N7-N3 fail with 409 NFFRR 411 Note 6: "check NFFRR" means that, before N7 applies FRR (because link 412 N7-N3 is down), N7 checks the label below the top label (or in this 413 case, because of PHP, the top label itself). If this is the NFFRR 414 label, N7 drops the packet rather than apply FRR. 416 3.2.1. NFFRR and SPRING 418 Suppose that, to protect link N2-N3, a bypass tunnel N2-N6-N7-N3 were 419 instantiated using SPRING MPLS [RFC8660], in particular, using 420 adjacency SIDs. If the corresponding labels for links N6-N7 and 421 N7-N3 were L20 and L21, the bypass would consist of pushing the label 422 stack [L20 L21] onto the packet and sending the packet to N6. To 423 indicate that FRR has already occurred and to drop the packet rather 424 than to try to protect the packet again, N2 would have to push [L20 425 NFFRR L21 NFFRR] onto the packet before sending it to N6. If the 426 packet came from N1 with label L1, N2 would send a packet with label 427 stack [L20 NFFRR L21 NFFRR L2] to N6. 429 N6 would see L20, pop it, note the NFFRR label and pop it, then 430 attempt to send the packet to N7. If the link N6-N7 is down, N6 431 drops the packet. Otherwise, N7 gets the packet, sees L21, pops it, 432 sees NFFRR, pops it and tries to send the packet to N3. If link 433 N7-N3 is down, N7 drops the packet. Otherwise, N3 gets the packet 434 with L2, swaps with with L3 and sends it to N4. 436 Note that with SPRING MPLS, the NFFRR label needs to be repeated for 437 each label in the bypass stack. Hence the request for a "regular" 438 SPL rather than an extended SPL. 440 3.3. NFFRR for MPLS Services 442 First, we illustrate known unicast EVPN forwarding: 444 +------+-------------+-------+-------------+---------+ 445 | Node | Action | Next | Packet | Comment | 446 +------+-------------+-------+-------------+---------+ 447 | PE1 | send to CE2 | PE2 | [T1 S2] pkt | EVPN | 448 | | | | | | 449 | PE2 | send to CE2 | link1 | pkt | done! | 450 +------+-------------+-------+-------------+---------+ 452 Note: T1/T2/T3 are the transport labels for PE1/PE3/PE2 to reach 453 PE2/PE2/PE3 respectively. S2/S3 are the service labels announced by 454 PE2/PE3 for CE2. 456 Then, we show what happens when CE2 is down without NFFRR: 458 +------+-------------+-------+-------------+---------+ 459 | Node | Action | Next | Packet | Comment | 460 +------+-------------+-------+-------------+---------+ 461 | PE1 | send to CE2 | PE2 | [T1 S2] pkt | EVPN | 462 | | | | | | 463 | PE2 | send to CE2 | link1 | -- | link1 X | 464 | | | | | | 465 | PE2 | send to CE2 | PE3 | [T3 S3] pkt | eFRR | 466 | | | | | | 467 | PE3 | send to CE2 | link2 | -- | link2 X | 468 | | | | | | 469 | PE3 | send to CE2 | PE2 | [T2 S2] pkt | eFRR | 470 | | | | | | 471 | PE2 | send to CE2 | link1 | -- | link1 X | 472 | | | | | | 473 | PE2 | send to CE2 | PE3 | [T3 S3] pkt | eFRR | 474 | | | | | | 475 | ... | | | | loop! | 476 +------+-------------+-------+-------------+---------+ 478 Note: link1/link2 X means link1/link2 is down. eFRR refers to EVPN 479 multihoming FRR. 481 In the case of MPLS services such as EVPN Figure 1, the NFFRR label 482 is inserted below the service label, as shown below: 484 +------+-------------+-------+-------------------+-------------+ 485 | Node | Action | Next | Packet | Comment | 486 +------+-------------+-------+-------------------+-------------+ 487 | PE1 | send to CE2 | PE2 | [T1 S2] pkt | EVPN | 488 | | | | | | 489 | PE2 | send to CE2 | link1 | -- | link1 X | 490 | | | | | | 491 | PE2 | send to CE2 | PE3 | [T3 S2 NFFRR] pkt | eFRR | 492 | | | | | | 493 | PE3 | send to CE2 | link2 | -- | link2 X | 494 | | | | | | 495 | PE3 | drop pkt | -- | -- | check NFFRR | 496 +------+-------------+-------+-------------------+-------------+ 498 Note: "check NFFRR" is as above. 500 3.4. NFFRR for RMR 502 As described in Figure 2, packets will loop until TTL expires if the 503 destination node in an RMR ring (here, R4) fails. The solution in 504 this case is that the first node to apply RMR protection (R3) pops 505 the current RMR transport label being used, sees that the next label 506 is not NFFRR (so protection is allowed), pushes an NFFRR label and 507 then the RMR transport label for the reverse direction. 509 When R5 receives the packet, it sees that the next link is down, pops 510 the RMR transport label, sees the NFFRR label and drops the packet. 511 Thus, the loop is avoided. 513 4. Signaling NFFRR Capability 515 4.1. Signaling NFFRR Capability for MPLS Services with BGP 517 The ideal choice would be an attribute consisting of a bit vector of 518 node capabilities, one bit of which would be the capability of 519 processing the NFFRR SPL below the BGP service label. This would be 520 used by BGP L2VPN, BGP VPLS, EVPN, E-Tree and E-VPWS. An alternative 521 is to use the BGP Capabilities Optional Parameter 522 [I-D.ietf-idr-next-hop-capability]. Details to be worked out. 524 4.2. Signaling NFFRR Capability for MPLS Services with Targeted LDP 526 One approach to signaling NFFRR capability for MPLS services signaled 527 with targeted LDP is to introduce a new LDP TLV called the NFFRR 528 Capability TLV as an Optional Parameter in the Label Mapping Message 529 [RFC5036]. This TLV has Type TBD (suggested: 0x0207) and Length 0. 531 Another approach is to use LDP Capabilities [RFC5561]; this approach 532 has the advantage that it deals with capabilities on a node basis 533 rather than on a per label mapping basis. However, there don't 534 appear to be other documents using this approach. 536 4.3. Signaling NFFRR Capability for MPLS Forwarding 538 The authors suggest signaling a router's ability to process the NFFRR 539 SPL using the Link State Router TE Node Capabilities [RFC5073], which 540 works for both IS-IS and OSPF. A new TE Node Capability bit, the N 541 bit (suggested value 5) indicates that the advertising node is 542 capable of processing the NFFRR SPL. 544 5. IANA Considerations 546 If this draft is deemed useful, an SPL for NFFRR will need to be 547 allocated. We suggest the early allocation of label 8 for this. 549 Furthermore, means of signaling the ability to process the NFFRR SPL 550 should be defined for IS-IS, OSPF, LDP and BGP. 552 The following update is suggested for the Link State Router TE Node 553 Capabilities registry: 555 +-----+-------+----------------+ 556 | Bit | Name | Reference | 557 +-----+-------+----------------+ 558 | 5 | NFFRR | This docusment | 559 +-----+-------+----------------+ 561 The following update is suggested for the TLV Type Name Space of the 562 Label Distribution Protocol (LDP) Parameters registry: 564 +--------+-------+----------------+ 565 | Type | Name | Reference | 566 +--------+-------+----------------+ 567 | 0x0207 | NFFRR | This docusment | 568 +--------+-------+----------------+ 570 6. Security Considerations 572 A malicious or compromised LSR can insert NFFRR into a label stack, 573 preventing FRR from occurring. If so, protection will not kick in 574 for failures that could have been protected, and there will be 575 unnecessary packet loss. 577 7. References 579 7.1. Normative References 581 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 582 Requirement Levels", BCP 14, RFC 2119, 583 DOI 10.17487/RFC2119, March 1997, 584 . 586 [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., 587 "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, 588 October 2007, . 590 [RFC5073] Vasseur, J., Ed. and J. Le Roux, Ed., "IGP Routing 591 Protocol Extensions for Discovery of Traffic Engineering 592 Node Capabilities", RFC 5073, DOI 10.17487/RFC5073, 593 December 2007, . 595 [RFC7274] Kompella, K., Andersson, L., and A. Farrel, "Allocating 596 and Retiring Special-Purpose MPLS Labels", RFC 7274, 597 DOI 10.17487/RFC7274, June 2014, 598 . 600 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 601 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 602 May 2017, . 604 7.2. Informative References 606 [ALDT] Merling, D., Braun, W., and M. Menth, "Efficient Data 607 Plane Protection for SDN", June 2018, 608 . 611 [I-D.ietf-idr-next-hop-capability] 612 Decraene, B., Kompella, K., and W. Henderickx, "BGP Next- 613 Hop dependent capabilities", draft-ietf-idr-next-hop- 614 capability-06 (work in progress), October 2020. 616 [I-D.ietf-mpls-rmr] 617 Kompella, K. and L. Contreras, "Resilient MPLS Rings", 618 draft-ietf-mpls-rmr-13 (work in progress), August 2020. 620 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 621 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 622 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 623 . 625 [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast 626 Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 627 DOI 10.17487/RFC4090, May 2005, 628 . 630 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 631 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 632 2006, . 634 [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private 635 LAN Service (VPLS) Using BGP for Auto-Discovery and 636 Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, 637 . 639 [RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private 640 LAN Service (VPLS) Using Label Distribution Protocol (LDP) 641 Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, 642 . 644 [RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for 645 IP Fast Reroute: Loop-Free Alternates", RFC 5286, 646 DOI 10.17487/RFC5286, September 2008, 647 . 649 [RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL. 650 Le Roux, "LDP Capabilities", RFC 5561, 651 DOI 10.17487/RFC5561, July 2009, 652 . 654 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 655 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 656 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 657 2015, . 659 [RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. 660 So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)", 661 RFC 7490, DOI 10.17487/RFC7490, April 2015, 662 . 664 [RFC8214] Boutros, S., Sajassi, A., Salam, S., Drake, J., and J. 665 Rabadan, "Virtual Private Wire Service Support in Ethernet 666 VPN", RFC 8214, DOI 10.17487/RFC8214, August 2017, 667 . 669 [RFC8317] Sajassi, A., Ed., Salam, S., Drake, J., Uttaro, J., 670 Boutros, S., and J. Rabadan, "Ethernet-Tree (E-Tree) 671 Support in Ethernet VPN (EVPN) and Provider Backbone 672 Bridging EVPN (PBB-EVPN)", RFC 8317, DOI 10.17487/RFC8317, 673 January 2018, . 675 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 676 Decraene, B., Litkowski, S., and R. Shakir, "Segment 677 Routing with the MPLS Data Plane", RFC 8660, 678 DOI 10.17487/RFC8660, December 2019, 679 . 681 Authors' Addresses 683 Kireeti Kompella 684 Juniper Networks 685 1133 Innovation Way 686 Sunnyvale, CA 94089 687 United States 689 Email: kireeti.kompella@gmail.com 690 Wen Lin 691 Juniper Networks 692 1133 Innovation Way 693 Sunnyvale, CA 94089 694 United States 696 Email: wlin@juniper.net