idnits 2.17.1 draft-ietf-bess-pbb-evpn-isid-cmacflush-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 : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 121 has weird spacing: '... |stb vES...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (October 15, 2019) is 1626 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) == Unused Reference: 'RFC7432' is defined on line 401, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 4 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 Nokia 7 M. Miyake 8 T. Matsuda 9 Softbank 11 Expires: April 17, 2020 October 15, 2019 13 PBB-EVPN ISID-based CMAC-Flush 14 draft-ietf-bess-pbb-evpn-isid-cmacflush-00 16 Abstract 18 Provider Backbone Bridging (PBB) can be combined with Ethernet VPN 19 (EVPN) to deploy ELAN services in very large MPLS networks (PBB- 20 EVPN). Single-Active Multi-homing and per-ISID Load-Balancing can be 21 provided to access devices and aggregation networks. In order to 22 speed up the network convergence in case of failures on Single-Active 23 Multi-Homed Ethernet Segments, PBB-EVPN defines a CMAC-Flush 24 mechanism that works for different Ethernet Segment BMAC address 25 allocation models. This document complements those CMAC-Flush 26 procedures for cases in which no PBB-EVPN Ethernet Segments are 27 defined (ESI 0) and an ISID-based CMAC-Flush granularity is desired. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF), its areas, and its working groups. Note that 36 other groups may also distribute working documents as Internet- 37 Drafts. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 The list of current Internet-Drafts can be accessed at 45 http://www.ietf.org/ietf/1id-abstracts.txt 46 The list of Internet-Draft Shadow Directories can be accessed at 47 http://www.ietf.org/shadow.html 49 This Internet-Draft will expire on April 15, 2020. 51 Copyright Notice 53 Copyright (c) 2019 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 2 69 2. Solution requirements . . . . . . . . . . . . . . . . . . . . . 4 70 3. EVPN BGP Encoding for ISID-based CMAC-flush . . . . . . . . . . 5 71 4. Solution description . . . . . . . . . . . . . . . . . . . . . 6 72 4.1 ISID-based CMAC-Flush activation procedures . . . . . . . . 7 73 4.2 CMAC-Flush generation . . . . . . . . . . . . . . . . . . . 7 74 4.3 CMAC-Flush process upon receiving a CMAC-Flush 75 notification . . . . . . . . . . . . . . . . . . . . . . . . 8 76 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 8 77 6. Conventions used in this document . . . . . . . . . . . . . . . 9 78 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 9 79 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9 80 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 81 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 9 82 9.2 Informative References . . . . . . . . . . . . . . . . . . . 10 83 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 84 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 10 85 17. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10 87 1. Problem Statement 89 [RFC7623] defines how Provider Backbone Bridging (PBB) can be 90 combined with Ethernet VPN (EVPN) to deploy ELAN services in very 91 large MPLS networks. [RFC7623] also describes how Single-Active 92 Multi-homing and per-ISID Load-Balancing can be provided to access 93 devices and aggregation networks. When Access Ethernet/MPLS Networks 94 exists, [vES] describes how virtual ES can be associated to a group 95 of Ethernet Virtual Circuits (EVCs) or even Pseudowires (PWs). In 96 order to speed up the network convergence in case of failures on 97 Single-Active Multi-Homed Ethernet Segments, [RFC7623] defines a 98 CMAC-Flush mechanism that works for different Ethernet Segment BMAC 99 address allocation models. 101 In some cases, the administrative entities that manage the access 102 devices or aggregation networks, don't demand Multi-Homing Ethernet 103 Segments (ES) from the PBB-EVPN provider, but simply multiple single- 104 homed ES. If that is the case, the PBB-EVPN network is no longer 105 aware of the redundancy offered by the access administrative entity. 106 Figure 1 shows an example where the PBB-EVPN network provides four 107 different Attachment Circuits (ACs) for ISID1, with those ACs not 108 being part of any ES or vES (therefore they are referred to as null 109 vES). 111 <--PBB-EVPN Network---> 113 ISID1 vES +-----+ +-----+ 114 +----+ null| PE1 +---------+ PE3 |vES null 115 |CE1 +--------+ BM1 | | BM3 | +---------+ 116 +-+--+ act| | | |===== | 117 | G.8032 +-+---+ +---+-+ | \act | ISID1 118 | Access | | | \ +-+--+ 119 | Ring | IP/MPLS | | ==|CE3 | 120 | | | | / +-+--+ 121 |stb vES +-+---+ +---+-+ | /stb | 122 +-+--+ null| PE2 | | PE4 +----- | 123 |CE2 +--------+ BM2 | | BM4 | +---------+ 124 +----+ act| +---------+ |vES null 125 ISID1 +-----+ +-----+ <-MPLS Ag-> 126 Network 128 Figure 1 PBB-EVPN and non-ES based redundancy 130 In the example in Figure 1, CE1 and CE2 provide redundant 131 connectivity for ISID1 through the use of G.8032 Ethernet Ring 132 Protection Switching. CE3 provides redundant active-standby PW 133 connectivity for ISID1. In the two cases the ACs are connected to 134 null ES, hence the PEs will keep their ACs active and the CEs will be 135 responsible for the per-ISID load balancing while avoiding loops. 137 For instance, CE2 will block its link to CE1 and CE3 will block its 138 forwarding path to PE4. In this situation, a failure in one of the 139 redundant ACs will make the CEs to start using their redundant paths, 140 however those failures will not trigger any CMAC-Flush procedures in 141 the PEs. For example, if the active PW from CE3 fails, PE3 will not 142 issue any CMAC-Flush message and therefore the remote PEs will 143 continue pointing at PE3's BMAC to reach CE3's CMACs, until the CMACs 144 age out in the ISID1 FDBs. 146 [RFC7623] provides a CMAC-Flush solution based on a shared BMAC 147 update along with the MAC Mobility extended community where the 148 sequence number is incremented. However, while that procedure could 149 be used in the example of Figure 1, it would result in unnecessary 150 flushing of unaffected ISIDs on the remote PEs, and subsequent 151 flooding. 153 This document describes an extension of the [RFC7623] CMAC-Flush 154 procedures, so that in the above failure example, PE3 can trigger a 155 CMAC-Flush notification that makes PE1, PE2 and PE4 flush all the 156 CMACs associated to PE3's BMAC and (only) ISID1. This new CMAC-Flush 157 procedure explained in this document will be referred to as "PBB-EVPN 158 ISID-based CMAC-Flush" and can be used in PBB-EVPN networks with null 159 or non-null (virtual) Ethernet Segments. 161 2. Solution requirements 163 The following requirements must be met by the CMAC-Flush solution 164 described in this document: 166 a) The solution MUST solve black-hole scenarios in case of failures 167 on null ES ACs (Attachment Circuits not associated to ES, that is, 168 ESI=0) when the access device/network is responsible for the 169 redundancy. 171 b) This extension SHOULD work with Single-Active non-null ES and 172 virtual ES, irrespective of the PE BMAC address assignment 173 (dedicated per-ES BMAC or shared BMAC). 175 c) In case of failure on the egress PE, the solution MUST provide a 176 CMAC-Flush notification at BMAC AND ISID granularity level. 178 d) The solution MUST provide a reliable CMAC-Flush notification in 179 PBB-EVPN networks that use Route-Reflectors (RRs). 181 e) The solution MUST coexist in [RFC7623]-compliant networks where 182 there are systems not supporting this extension. 184 f) The solution SHOULD be enabled/disabled by an administrative 185 option on a per-PE and per-ISID basis. 187 3. EVPN BGP Encoding for ISID-based CMAC-flush 189 The solution does not use any new BGP attributes but reuses the MAC 190 Mobility extended community as an indication of CMAC-Flush (as in 191 [RFC7623]) and encodes the ISID in the Ethernet Tag field of the 192 MAC/IP route. As a reference, Figure 2 shows the MAC Mobility 193 extended community and the MAC/IP route that are used in this 194 document as a CMAC-Flush notification. 196 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 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 | Type=0x06 | Sub-Type=0x03 | Flags | Reserved=0 | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | Sequence Number | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 +---------------------------------------+ 204 | RD | 205 +---------------------------------------+ 206 | ESI = 0 | 207 +---------------------------------------+ 208 | Ethernet Tag ID = ISID | 209 +---------------------------------------+ 210 | MAC Address Length = 48 | 211 +---------------------------------------+ 212 | BMAC Address | 213 +---------------------------------------+ 214 | IP Address Length = 0 | 215 +---------------------------------------+ 216 | MPLS Label1 | 217 +---------------------------------------+ 219 Figure 2 CMAC-Flush notification encoding: BMAC/ISID route 221 Where: 223 o The route's RD and RT are the ones corresponding to its EVI. 224 Alternatively to the EVI's RT, the route MAY be tagged with an RT 225 auto-derived from the Ethernet Tag (ISID) instead. [RFC7623] 226 describes how the RT can be derived from the ISID. 228 o The Ethernet Tag encodes the ISID for which the PE that receives 229 the route must flush the CMACs upon reception of the route. 231 o The MAC address field encodes the BMAC Address for which the PE 232 that receives the route must flush the CMACs upon reception of the 233 route. 235 o The MAC Mobility extended community is used as in [RFC7623], where 236 a delta in the sequence number between two updates for the same 237 BMAC/ISID will be interpreted as a CMAC-flush notification for the 238 corresponding BMAC and ISID. 240 All the other fields are set and used as defined in [RFC7623]. This 241 document will refer to this route as the BMAC/ISID route, as opposed 242 to the [RFC7623] BMAC/0 route (BMAC route sent with Ethernet Tag = 243 0). 245 Note that this BMAC/ISID route will be accepted and reflected by any 246 RFC7432-compliant RR, since no new attributes or values are used. A 247 PE receiving the route will process the received BMAC/ISID update 248 only in case of supporting the procedures described in this 249 document. 251 4. Solution description 253 Figure 1 will be used in the description of the solution. CE1, CE2 254 and CE3 are connected to ACs associated to ISID1, where no (Multi- 255 Homed) Ethernet Segments have been enabled. All the ACs are 256 operationally active and ready to forward frames. 258 Enabling or disabling ISID-based CMAC-Flush SHOULD be an 259 administrative choice on the system that MAY be configured per ISID 260 (I-Component). When enabled on a PE: 262 a) The PE will be able to generate BMAC/ISID routes as CMAC-Flush 263 notifications for the remote PEs. 265 b) The PE will be able to process BMAC/ISID routes received from 266 remote PEs. 268 When ISID-based CMAC-Flush is disabled, the PE will follow the 269 [RFC7623] procedures for CMAC-flush. 271 These new CMAC-flush procedures are described in sections 4.1, 4.2 272 and 4.3 respectively: 274 o ISID-based CMAC-flush activation 275 o CMAC-flush notification generation upon AC failures 276 o CMAC-flush process upon receiving a CMAC-Flush notification 278 4.1 ISID-based CMAC-Flush activation procedures 280 The following behavior MUST be followed by the PBB-EVPN PEs (see 281 Figure 1): 283 o As in [RFC7623], each PE has previously advertised a shared BMAC in 284 a BMAC/0 route (BM1, BM2, BM3 and BM4 respectively). This is the 285 BMAC that each PE will use as BMAC SA (Source Address) when 286 encapsulating the frames received on any local single-homed AC. 287 Each PE will import the received BMAC/0 routes from the remote PEs 288 and will install the BMACs in its B-component MAC-VRF. For 289 instance, PE1 will advertise BM1/0 and will install BM2, BM3 and 290 BM4 in its MAC-VRF. 292 o Assuming ISID-based CMAC-Flush is activated for ISID 1, the PEs 293 will advertise the shared BMAC with ISID 1 encoded in the Ethernet 294 Tag. That is, PE1 will advertise BM1/1 and will receive BM2/1, 295 BM3/1 and BM4/1. The receiving PEs MUST use these BMAC/ISID routes 296 only for CMAC-Flush procedures and they MUST NOT be used to 297 add/withdraw any BMAC entry in the MAC-VRFs. As per [RFC7623], only 298 BMAC/0 routes can be used to add/withdraw BMACs in the MAC-VRFs. 300 o The above procedure MAY also be used for dedicated BMACs. 302 4.2 CMAC-Flush generation 304 If, for instance, there is a failure on PE1's AC, PE1 will generate 305 an update including BM1/1 along with the MAC Mobility extended 306 community where the Sequence Number has been incremented. The 307 reception of the BM1/1 with a delta in the sequence number will 308 trigger the CMAC-Flush procedures on the receiving PEs. 310 o An AC going operationally down MUST generate a BMAC/ISID with a 311 higher Sequence Number. If the AC going down makes the entire local 312 ISID go operationally down, the PE will withdraw the BMAC/ISID 313 route for the ISID. 315 o An AC going operationally up SHOULD NOT generate any BMAC/ISID 316 update, unless it activates its corresponding ISID, in which case 317 the PE will advertise the BMAC/ISID route. 319 o An AC receiving a CMAC-Flush notification from the access network, 320 e.g. by G.8032, MAY propagate it to the remote PEs by generating a 321 BMAC/ISID update with higher Sequence Number. 323 4.3 CMAC-Flush process upon receiving a CMAC-Flush notification 325 A PE receiving a CMAC-Flush notification will follow these 326 procedures: 328 o A received BMAC/ISID route (with non-zero ISID) MUST NOT add/remove 329 any BMAC to/from the MAC-VRF. 331 o An update of a previously received BMAC/ISID route with a delta 332 Sequence Number, MUST flush all the CMACs associated to that ISID 333 and BMAC. CMACs associated to the same ISID but different BMAC MUST 334 NOT be flushed. 336 o A received BMAC/ISID withdraw (with non-zero ISID) MUST flush all 337 the CMACs associated to that BMAC and ISID. 339 Note that the CMAC-Flush procedures described in [RFC7623] for BMAC/0 340 routes are still valid and a PE receiving [RFC7623] CMAC-flush 341 notification messages MUST observe the behavior specified in 342 [RFC7623]. 344 5. Conclusions 346 The ISID-based CMAC-Flush solution described in this document has the 347 following benefits: 349 a) The solution solves black-hole scenarios in case of failures on 350 null ES ACs, since the CMAC-flush procedures are independent of 351 the Ethernet Segment definition. 353 b) This extension can also be used with Single-Active non-null ES and 354 virtual ES, irrespective of the PE BMAC address assignment 355 (dedicated per-ES BMAC or shared BMAC). 357 c) It provides a CMAC-Flush notification at BMAC AND ISID granularity 358 level, therefore flushing a minimum number of CMACs and reducing 359 the amount of flooding in the network. 361 d) It provides a reliable CMAC-Flush notification in PBB-EVPN 362 networks that use RRs. RRs will propagate the CMAC-flush 363 notifications for all the affected ISIDs and irrespective of the 364 order in which the notifications make it to the RR. 366 e) The solution can coexist in a network with systems supporting or 367 not supporting the CMAC-flush extensions. 369 6. Conventions used in this document 371 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 372 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 373 "OPTIONAL" in this document are to be interpreted as described in 374 BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all 375 capitals, as shown here. 377 7. Security Considerations 379 Security considerations described in [RFC7623] apply to this 380 document. In addition, this document suggests additional procedures, 381 that can be activated on a per ISID basis, and generate additional 382 BGP EVPN MAC/IP advertisements in the network. The format of these 383 additional MAC/IP routes is backwards compatible with [RFC7623] 384 procedures and should not create any issues on receiving PEs not 385 following this specification, however, the additional routes may 386 consume extra memory resources on the receiving systems. Because of 387 that, this feature should be activated only when necessary, and not 388 by default in any PBB-EVPN PE. 390 8. IANA Considerations 392 9. References 394 9.1 Normative References 396 [RFC7623] Sajassi, A., Ed., Salam, S., Bitar, N., Isaac, A., and W. 397 Henderickx, "Provider Backbone Bridging Combined with Ethernet VPN 398 (PBB-EVPN)", RFC 7623, DOI 10.17487/RFC7623, September 2015, 399 . 401 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 402 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet 403 VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, 404 . 406 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 407 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 408 1997, . 410 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 411 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, 412 . 414 9.2 Informative References 416 [vES] Sajassi et al. "EVPN Virtual Ethernet Segment", draft-ietf- 417 bess-evpn-virtual-eth-segment-04, work-in-progress, January, 2019. 419 10. Acknowledgments 421 The authors want to thank Vinod Prabhu, Sriram Venkateswaran, Laxmi 422 Padakanti, Ranganathan Boovaraghavan for their review and 423 contributions. 425 11. Contributors 427 17. Authors' Addresses 429 Jorge Rabadan 430 Nokia 431 777 E. Middlefield Road 432 Mountain View, CA 94043 USA 433 Email: jorge.rabadan@nokia.com 435 Senthil Sathappan 436 Nokia 437 701 E. Middlefield Road 438 Mountain View, CA 94043 USA 439 Email: senthil.sathappan@nokia.com 441 Kiran Nagaraj 442 Nokia 443 701 E. Middlefield Road 444 Mountain View, CA 94043 USA 445 Email: kiran.nagaraj@nokia.com 447 Masahiro Miyake 448 Softbank 449 Email: masahiro.miyake@g.softbank.co.jp 451 Taku Matsuda 452 Softbank 453 Email: taku.matsuda@g.softbank.co.jp