idnits 2.17.1 draft-ietf-bess-pbb-evpn-isid-cmacflush-02.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 == Line 117 has weird spacing: '... |stb vES...' -- The document date (April 26, 2021) is 1088 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) == Outdated reference: A later version (-15) exists of draft-ietf-bess-evpn-virtual-eth-segment-06 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BESS Workgroup J. Rabadan, Ed. 3 Internet-Draft S. Sathappan 4 Intended status: Standards Track K. Nagaraj 5 Expires: October 28, 2021 Nokia 6 M. Miyake 7 T. Matsuda 8 Softbank 9 April 26, 2021 11 PBB-EVPN ISID-based CMAC-Flush 12 draft-ietf-bess-pbb-evpn-isid-cmacflush-02 14 Abstract 16 Provider Backbone Bridging (PBB) can be combined with Ethernet VPN 17 (EVPN) to deploy Ethernet Local Area Network (ELAN) services in large 18 Multi-Protocol Label Switching (MPLS) networks (PBB-EVPN). Single- 19 Active Multi-homing and per-ISID Load-Balancing can be provided to 20 access devices and aggregation networks. In order to speed up the 21 network convergence in case of failures on Single-Active Multi-Homed 22 Ethernet Segments, PBB-EVPN defines a flush mechanism for Customer 23 MACs (CMAC-flush) that works for different Ethernet Segment Backbone 24 MAC (BMAC) address allocation models. This document complements 25 those CMAC-flush procedures for cases in which no PBB-EVPN Ethernet 26 Segments are defined (the attachment circuit is associated to a zero 27 Ethernet Segment Identifier) and a Service Instance Identifier based 28 (ISID-based) CMAC-flush granularity is required. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on October 28, 2021. 47 Copyright Notice 49 Copyright (c) 2021 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 1.1. Terminology and Conventions . . . . . . . . . . . . . . . 4 66 2. Solution requirements . . . . . . . . . . . . . . . . . . . . 5 67 3. EVPN BGP Encoding for ISID-based CMAC-flush . . . . . . . . . 6 68 4. Solution description . . . . . . . . . . . . . . . . . . . . 7 69 4.1. ISID-based CMAC-Flush activation procedures . . . . . . . 8 70 4.2. CMAC-Flush generation . . . . . . . . . . . . . . . . . . 8 71 4.3. CMAC-flush process upon receiving a CMAC-flush 72 notification . . . . . . . . . . . . . . . . . . . . . . 9 73 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 76 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 77 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 78 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 79 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 80 10.2. Informative References . . . . . . . . . . . . . . . . . 11 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 83 1. Introduction 85 [RFC7623] defines how Provider Backbone Bridging (PBB) can be 86 combined with Ethernet VPN (EVPN) to deploy ELAN services in very 87 large MPLS networks. [RFC7623] also describes how Single-Active 88 Multi-homing and per-ISID Load-Balancing can be provided to access 89 devices and aggregation networks. When Access Ethernet/MPLS Networks 90 exists, [I-D.ietf-bess-evpn-virtual-eth-segment] describes how 91 virtual Ethernet Segments can be associated to a group of Ethernet 92 Virtual Circuits (EVCs) or even Pseudowires (PWs). In order to speed 93 up the network convergence in case of failures on Single-Active 94 Multi-Homed Ethernet Segments, [RFC7623] defines a CMAC-flush 95 mechanism that works for different Ethernet Segment BMAC address 96 allocation models. 98 In some cases, the administrative entities that manage the access 99 devices or aggregation networks don't demand Multi-Homing Ethernet 100 Segments (ES) from the PBB-EVPN provider, but simply multiple single- 101 homed ES. If that is the case, the PBB-EVPN network is no longer 102 aware of the redundancy offered by the access administrative entity. 103 Figure 1 shows an example where the PBB-EVPN network provides four 104 different Attachment Circuits (ACs) for ISID1, with those ACs not 105 being part of any ES or vES (therefore they are referred to as null 106 vES). 108 <--PBB-EVPN Network---> 109 ISID1 vES +-----+ +-----+ 110 +----+ null| PE1 +---------+ PE3 |vES null 111 |CE1 +--------+ BM1 | | BM3 | +---------+ 112 +-+--+ act| | | |===== | 113 | G.8032 +-+---+ +---+-+ | \act | ISID1 114 | Access | | | \ +-+--+ 115 | Ring | IP/MPLS | | ==|CE3 | 116 | | | | / +-+--+ 117 |stb vES +-+---+ +---+-+ | /stb | 118 +-+--+ null| PE2 | | PE4 +----- | 119 |CE2 +--------+ BM2 | | BM4 | +---------+ 120 +----+ act| +---------+ |vES null 121 ISID1 +-----+ +-----+ <-MPLS Ag-> 122 Network 124 Figure 1: PBB-EVPN and non-ES based redundancy 126 In the example in Figure 1, CE1 and CE2 provide redundant 127 connectivity for ISID1 through the use of G.8032 Ethernet Ring 128 Protection Switching. CE3 provides redundant active-standby PW 129 connectivity for ISID1. In the two cases the ACs are connected to 130 null ES, hence the PEs will keep their ACs active and the CEs will be 131 responsible for the per-ISID load balancing while avoiding loops. 133 For instance, CE2 will block its link to CE1 and CE3 will block its 134 forwarding path to PE4. In this situation, a failure in one of the 135 redundant ACs will make the CEs to start using their redundant paths, 136 however those failures will not trigger any CMAC-flush procedures in 137 the PEs that implement [RFC7623]. For example, if the active PW from 138 CE3 fails, PE3 will not issue any CMAC-flush message and therefore 139 the remote PEs will continue pointing at PE3's BMAC to reach CE3's 140 CMACs, until the CMACs age out in the ISID1 forwarding tables. 142 [RFC7623] provides a CMAC-flush solution based on a shared BMAC 143 update along with the MAC Mobility extended community where the 144 sequence number is incremented. However, the procedure is only used 145 along with Ethernet Segments. Even if that procedure could be used 146 for null Ethernet Segments, as in the example of Figure 1, the 147 [RFC7623] CMAC-flush procedure would result in unnecessary flushing 148 of unaffected ISIDs on the remote PEs, and subsequent flooding of 149 unknown unicast traffic in the network. 151 This document describes an extension of the [RFC7623] CMAC-flush 152 procedures, so that in the above failure example, PE3 can trigger a 153 CMAC-flush notification that makes PE1, PE2 and PE4 flush all the 154 CMACs associated to PE3's BMAC and (only) ISID1. This new CMAC-flush 155 procedure explained in this document will be referred to as "PBB-EVPN 156 ISID-based CMAC-flush" and can be used in PBB-EVPN networks with null 157 or non-null (virtual) Ethernet Segments. 159 1.1. Terminology and Conventions 161 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 162 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 163 "OPTIONAL" in this document are to be interpreted as described in BCP 164 14 [RFC2119] [RFC8174] when, and only when, they appear in all 165 capitals, as shown here. 167 EVPN: Ethernet Virtual Private Networks, as in [RFC7432]. 169 EVI: EVPN Instance. 171 MAC-VRF: A Virtual Routing and Forwarding table for MAC addresses. 173 PBB-EVPN: Provider-Backbone-Bridging and EVPN, as in [RFC7623]. 175 PE: Provider Edge router. 177 CE: Customer Edge router. 179 CMAC: Customer MAC address. 181 BMAC or BM: Backbone MAC address. 183 ISID: Service Instance Identifier. 185 B-Component: Backbone Component, as in [RFC7623]. 187 I-Component: Service Instance Component, as in [RFC7623]. 189 PW: Pseudowire. 191 AC: Attachment Circuit. 193 ES and ESI: Ethernet Segment and Ethernet Segment Identifier. 195 Act: Active state, used with ACs or PWs that are operationally 196 active. 198 Stb: Standby state, used with ACs or PWs that are in a state where 199 they cannot transmit traffic. 201 G.8032: Ethernet Ring Protection. 203 RD: Route Distinguisher. 205 RT: Route Target. 207 BMAC/ISID route: an EVPN MAC/IP Advertisement route that uses a BMAC 208 in the MAC address field and an ISID in the Ethernet Tag field, and 209 it is used to notify remote PEs about the required CMAC-flush 210 procedure for the CMACs associated with the advertised BMAC and ISID. 212 BMAC/0 route: an EVPN MAC/IP Advertisement route that uses a BMAC in 213 the MAC address field and a zero Ethernet Tag ID. 215 Familiarity with the terminology in [RFC7623] is expected. 217 2. Solution requirements 219 The following requirements are followed by the CMAC-flush solution 220 described in this document: 222 a. The solution solves black-hole scenarios in case of failures on 223 null ES ACs (Attachment Circuits not associated to ES, that is, 224 ESI=0) when the access device/network is responsible for the 225 redundancy. 227 b. This extension works with Single-Active non-null ES and virtual 228 ES, irrespective of the PE BMAC address assignment (dedicated 229 per-ES BMAC or shared BMAC, as in [RFC7623]). 231 c. In case of failure on the egress PE, the solution provides a 232 CMAC-flush notification at BMAC and ISID granularity level. 234 d. The solution provides a reliable CMAC-flush notification in PBB- 235 EVPN networks that use Route-Reflectors (RRs), without causing 236 "double flushing" or no flushing for certain ISIDs due to the 237 notification messages being aggregated at the RR. 239 e. The solution coexists in [RFC7623] networks where there are PEs 240 that do not support this specification. 242 f. The solution SHOULD be enabled/disabled by an administrative 243 option on a per-PE and per-ISID basis. 245 3. EVPN BGP Encoding for ISID-based CMAC-flush 247 The solution does not use any new BGP attributes but reuses the MAC 248 Mobility extended community as an indication of CMAC-flush (as in 249 [RFC7623]) and encodes the ISID in the Ethernet Tag field of the EVPN 250 MAC/IP advertisement route. As a reference, Figure 2 shows the MAC 251 Mobility extended community and the EVPN MAC/IP advertisement route 252 that are used specified in [RFC7432] and used in this document as a 253 CMAC-flush notification message. 255 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 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | Type=0x06 | Sub-Type=0x03 | Flags | Reserved=0 | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | Sequence Number | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 +---------------------------------------+ 263 | RD | 264 +---------------------------------------+ 265 | ESI = 0 | 266 +---------------------------------------+ 267 | Ethernet Tag ID = ISID | 268 +---------------------------------------+ 269 | MAC Address Length = 48 | 270 +---------------------------------------+ 271 | BMAC Address | 272 +---------------------------------------+ 273 | IP Address Length = 0 | 274 +---------------------------------------+ 275 | MPLS Label1 | 276 +---------------------------------------+ 278 Figure 2: CMAC-Flush notification encoding: BMAC/ISID route 280 Where: 282 o The route's RD and RT are the ones corresponding to its EVI. 283 Alternatively to the EVI's RT, the route MAY be tagged with an RT 284 auto-derived from the Ethernet Tag (ISID) instead. [RFC7623] 285 describes how the EVPN MAC/IP Advertisement routes can be 286 advertised along with the EVI RT or an RT that is derived from the 287 ISID. 289 o The Ethernet Tag encodes the ISID for which the PE that receives 290 the route must flush the CMACs upon reception of the route. 292 o The MAC address field encodes the BMAC Address for which the PE 293 that receives the route must flush the CMACs upon reception of the 294 route. 296 o The MAC Mobility extended community is used as in [RFC7623], where 297 a delta in the sequence number between two updates for the same 298 BMAC/ISID will be interpreted as a CMAC-flush notification for the 299 corresponding BMAC and ISID. 301 All the other fields are set and used as defined in [RFC7623]. This 302 document will refer to this route as the BMAC/ISID route, as opposed 303 to the [RFC7623] BMAC/0 route (BMAC route sent with Ethernet Tag ID = 304 0). 306 Note that this BMAC/ISID route will be accepted and reflected by any 307 [RFC7432] RR, since no new attributes or values are used. A PE 308 receiving the route will process the received BMAC/ISID update only 309 in case of supporting the procedures described in this document. 311 4. Solution description 313 Figure 1 will be used in the description of the solution. CE1, CE2 314 and CE3 are connected to ACs associated to ISID1, where no (Multi- 315 Homed) Ethernet Segments have been enabled, and the ACs and PWs are 316 in active or standby state as per Figure 1. 318 Enabling or disabling ISID-based CMAC-flush SHOULD be an 319 administrative choice on the system that MAY be configured per ISID 320 (I-Component). When enabled on a PE: 322 a. The PE will be able to generate BMAC/ISID routes as CMAC-Flush 323 notifications for the remote PEs. 325 b. he PE will be able to process BMAC/ISID routes received from 326 remote PEs. 328 When ISID-based CMAC-flush is disabled, the PE will follow the 329 [RFC7623] procedures for CMAC-flush. 331 This CMAC-flush specification is described in three sets of 332 procedures: 334 o ISID-based CMAC-flush activation 336 o CMAC-flush notification generation upon AC failures 338 o CMAC-flush process upon receiving a CMAC-flush notification 340 4.1. ISID-based CMAC-Flush activation procedures 342 The following behavior MUST be followed by the PBB-EVPN PEs following 343 this specification. Figure 1 is used as a reference. 345 o As in [RFC7623], each PE advertises a shared BMAC in a BMAC/0 346 route (with BM1, BM2, BM3 and BM4 in the MAC address field, 347 respectively). This is the BMAC that each PE will use as BMAC SA 348 (Source Address) when encapsulating the frames received on any 349 local single-homed AC. Each PE will import the received BMAC/0 350 routes from the remote PEs and will install the BMACs in its 351 B-component MAC-VRF. For instance, PE1 will advertise BM1/0 and 352 will install BM2, BM3 and BM4 in its MAC-VRF. 354 o Assuming ISID-based CMAC-flush is activated for ISID 1, the PEs 355 will advertise the shared BMAC with ISID 1 encoded in the Ethernet 356 Tag. That is, PE1 will advertise BM1/1 and will receive BM2/1, 357 BM3/1 and BM4/1. The receiving PEs MUST use these BMAC/ISID 358 routes only for CMAC-flush procedures and they MUST NOT be used 359 them to add/withdraw any BMAC entry in the MAC-VRFs. As per 360 [RFC7623], only BMAC/0 routes can be used to add/withdraw BMACs in 361 the MAC-VRFs. 363 o The above procedure MAY also be used for dedicated BMACs (BMACs 364 allocated per Ethernet Segment). 366 4.2. CMAC-Flush generation 368 If, for instance, there is a failure on PE1's AC, PE1 will generate 369 an update including BM1/1 along with the MAC Mobility extended 370 community where the Sequence Number has been incremented. The 371 reception of the BM1/1 with a delta in the sequence number will 372 trigger the CMAC-flush procedures on the receiving PEs. 374 o An AC going operationally down MUST generate a BMAC/ISID with a 375 higher Sequence Number. If the AC going down makes the entire 376 local ISID go operationally down, the PE will withdraw the BMAC/ 377 ISID route for the ISID. 379 o An AC going operationally up SHOULD NOT generate any BMAC/ISID 380 update, unless it activates its corresponding ISID, in which case 381 the PE will advertise the BMAC/ISID route. 383 o An AC receiving a G.8032 flush notification or a flush message in 384 any other protocol from the access network MAY propagate it to the 385 remote PEs by generating a BMAC/ISID route update with higher 386 Sequence Number. 388 4.3. CMAC-flush process upon receiving a CMAC-flush notification 390 A PE receiving a CMAC-flush notification will follow these 391 procedures: 393 o A received BMAC/ISID route (with non-zero ISID) MUST NOT add/ 394 remove any BMAC to/from the MAC-VRF. 396 o An update of a previously received BMAC/ISID route with a delta 397 Sequence Number, MUST flush all the CMACs associated to that ISID 398 and BMAC. CMACs associated to the same ISID but different BMAC 399 MUST NOT be flushed. 401 o A received BMAC/ISID withdraw (with non-zero ISID) MUST flush all 402 the CMACs associated to that BMAC and ISID. 404 Note that the CMAC-flush procedures described in [RFC7623] for BMAC/0 405 routes are still valid and a PE receiving [RFC7623] CMAC-flush 406 notification messages MUST observe the behavior specified in 407 [RFC7623]. 409 5. Conclusions 411 The ISID-based CMAC-flush solution described in this document has the 412 following benefits: 414 a. The solution solves black-hole scenarios in case of failures on 415 null ES ACs, since the CMAC-flush procedures are independent of 416 the Ethernet Segment definition. 418 b. This extension can also be used with Single-Active non-null ES 419 and virtual ES, irrespective of the PE BMAC address assignment 420 (dedicated per-ES BMAC or shared BMAC). 422 c. It provides a CMAC-flush notification at BMAC and ISID 423 granularity level, therefore flushing a minimum number of CMACs 424 and reducing the amount of unknown unicast flooding in the 425 network. 427 d. It provides a reliable CMAC-flush notification in PBB-EVPN 428 networks that use RRs. RRs will propagate the CMAC-flush 429 notifications for all the affected ISIDs and irrespective of the 430 order in which the notifications make it to the RR. 432 e. The solution can coexist in a network with systems supporting or 433 not supporting this specification. 435 6. Security Considerations 437 Security considerations described in [RFC7623] apply to this 438 document. 440 In addition, this document suggests additional procedures, that can 441 be activated on a per ISID basis, and generate additional EVPN MAC/IP 442 Advertisement routes in the network. The format of these additional 443 EVPN MAC/IP Advertisement routes is backwards compatible with 444 [RFC7623] procedures and should not create any issues on receiving 445 PEs not following this specification, however, the additional routes 446 may consume extra memory and processing resources on the receiving 447 PEs. Because of that, it is RECOMMENDED to activate this feature 448 only when necessary (when multi-homed networks or devices are 449 attached to the PBB-EVPN PEs), and not by default in any PBB-EVPN PE. 451 7. IANA Considerations 453 8. Acknowledgments 455 The authors want to thank Vinod Prabhu, Sriram Venkateswaran, Laxmi 456 Padakanti, Ranganathan Boovaraghavan for their review and 457 contributions. 459 9. Contributors 461 10. References 463 10.1. Normative References 465 [RFC7623] Sajassi, A., Ed., Salam, S., Bitar, N., Isaac, A., and W. 466 Henderickx, "Provider Backbone Bridging Combined with 467 Ethernet VPN (PBB-EVPN)", RFC 7623, DOI 10.17487/RFC7623, 468 September 2015, . 470 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 471 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 472 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 473 2015, . 475 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 476 Requirement Levels", BCP 14, RFC 2119, 477 DOI 10.17487/RFC2119, March 1997, 478 . 480 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 481 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 482 May 2017, . 484 10.2. Informative References 486 [I-D.ietf-bess-evpn-virtual-eth-segment] 487 Sajassi, A., Brissette, P., Schell, R., Drake, J., and J. 488 Rabadan, "EVPN Virtual Ethernet Segment", draft-ietf-bess- 489 evpn-virtual-eth-segment-06 (work in progress), March 490 2020. 492 Authors' Addresses 494 Jorge Rabadan (editor) 495 Nokia 496 777 Middlefield Road 497 Mountain View, CA 94043 498 USA 500 Email: jorge.rabadan@nokia.com 502 Senthil Sathappan 503 Nokia 504 701 E. Middlefield Road 505 Mountain View, CA 94043 USA 507 Email: senthil.sathappan@nokia.com 509 Kiran Nagaraj 510 Nokia 511 701 E. Middlefield Road 512 Mountain View, CA 94043 USA 514 Email: kiran.nagaraj@nokia.com 516 M. Miyake 517 Softbank 519 Email: masahiro.miyake@g.softbank.co.jp 520 T. Matsuda 521 Softbank 523 Email: taku.matsuda@g.softbank.co.jp