idnits 2.17.1 draft-mohanty-bess-evpn-bum-opt-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 5, 2018) is 2245 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: 'RFC4271' is defined on line 312, but no explicit reference was found in the text == Unused Reference: 'RFC4364' is defined on line 336, but no explicit reference was found in the text == Outdated reference: A later version (-21) exists of draft-ietf-bess-evpn-igmp-mld-proxy-00 == Outdated reference: A later version (-01) exists of draft-sajassi-bess-evpn-per-mcast-flow-df-election-00 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BESS WorkGroup S. Mohanty 3 Internet-Draft M. Ghosh 4 Intended status: Standards Track Cisco Systems 5 Expires: September 6, 2018 S. Breeze 6 Claranet 7 J. Uttaro 8 ATT 9 March 5, 2018 11 BGP EVPN Flood Traffic Optimization 12 draft-mohanty-bess-evpn-bum-opt-00 14 Abstract 16 In EVPN, the Broadcast, Unknown Unicast and Multicast (BUM) traffic 17 is sent to all the routers participating in the EVPN instance. In a 18 multi-homing scenario, when more than one PEs share the same Ethernet 19 Segment, i.e. there are more than one PEs in a redundancy group, only 20 the PE that is the Designated-Forwarder (DF) for the ES will forward 21 that packet on the access interface whereas all non-DF PEs will drop 22 the packet. From the perspective of the network, this is quite 23 wasteful. This is especially true if there are significantly more 24 PEs on the Ethernet Segment. This draft explores this problem and 25 provides a solution for the same. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on September 6, 2018. 44 Copyright Notice 46 Copyright (c) 2018 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Requirements Language and Terminology . . . . . . . . . . . . 2 62 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 3. Problem Description . . . . . . . . . . . . . . . . . . . . . 4 64 4. Solution 1. Suppress the advertisement of the IMET route . . 5 65 5. Solution 2. Advertisement of the IMET route from the BDF . . 6 66 6. Protocol Considerations . . . . . . . . . . . . . . . . . . . 6 67 7. Operational Considerations . . . . . . . . . . . . . . . . . 7 68 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 69 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 70 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 7 71 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 11.1. Normative References . . . . . . . . . . . . . . . . . . 7 73 11.2. Informative References . . . . . . . . . . . . . . . . . 8 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 76 1. Requirements Language and Terminology 78 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 79 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 80 document are to be interpreted as described in [RFC2119]. 82 o ES: Ethernet Segment 84 o EVI: Ethernet virtual Instance, this is a mac-vrf. 86 o IMET: Inclusive Multicast Route 88 o DF: Designated Forwarder 90 o BDF: Backup Designated Forwarder 92 2. Introduction 94 BGP [RFC7432] describes a solution for disseminating mac addresses 95 over an mpls core via the Border Gateway Protocol. In EVPN, data 96 plane learning is confined to the access, and the control plane 97 learning happens via BGP in the core. This prevents unnecessary 98 flooding in the data plane as the traffic is directed to where the 99 destination is learnt from. However, in case of Broadcast, Unknown 100 Unicast and Multicast (BUM) traffic, the PE needs to do a flooding to 101 all the other PEs in the domain. 103 PEs elect a Designated Forwarder (DF) amongst themselves, for a given 104 ES, by exchanging type-4 routes via BGP. The role of a DF is to 105 forward BUM traffic received from the core, towards its access facing 106 interface. A PE in a non-DF role will drop flood traffic received on 107 its core-facing interface. Note that the DF election process is only 108 confined to the set of PEs who host the same Ethernet Segment. 109 Remote PEs are not interested in type-4 routes for Ethernet Segments 110 that they do not host. Hence remote PEs are ignorant of the DFs for 111 segments which is not local to them. Consequently, when the remote 112 PE needs to do a BUM flooding using ingress replication, it will 113 flood the frames to all participating PEs, irrespective of whether 114 DFs or not. The key to creating a list of PEs with which to flood 115 to, is the Inclusive multicast ethernet tag route which is described 116 below. 118 The IMET route (type-3) in EVPN advertises the BUM label for the EVI 119 to all the other PEs who are interested in the same EVI. For ingress 120 replication the label is encapsulated in the PMSI attribute. The 121 label is used to encapsulate the BUM traffic at the ingress entity. 122 This label is inserted just above the split-horizon label in the BUM 123 frame. When the BUM packet is received by a PE that is multi-homed 124 to the same Ethernet segment as the PE that originated the BUM 125 packet, and, is the DF for that (EVI, ES) pair, after popping the 126 transport label, the receiving PE is going to check if the split- 127 horizon label is its own. If so, it will drop the packet if no other 128 ES is configured. Otherwise it will forward the frame on all other 129 Segments that are part of the same EVI. if the PE is not the DF, it 130 will straightaway drop the packet immediately. 132 |- -PE1- - -| 133 | | 134 CE1---|- -PE2 - --|-RR - - PE5- -|-CE2 135 | | 136 |- -PE3- - -+ 137 | 138 CE2- - - PE4- - -+ 140 An EVPN Network 142 Figure 1 144 3. Problem Description 146 In the Figure 1. above, PE1, P2 and PE3 are all multi-homed to CE1 on 147 the same Ethernet Segment, say ES1. PE4 has a single host which is 148 not multi-homed. The same EVPN instance (Bridge-Domain) exists on 149 all the PEs. For this EVPN instance, PE1 is the Designated Forwarder 150 on ES1. Also, PE3 is the backup DF [I-D.ietf-bess-evpn-df-election]. 151 When PE5 sends the BUM traffic, the flooded frames are received by 152 PE1, PE2, PE3 and PE4. PE1 is going to forward the flood traffic on 153 its access link towards CE1. PE2 and PE3 will drop the flooded 154 frames that they receive from the core. PE4 will forward it as it 155 has a single-homed host on the same EVPN instance. 157 Here it is wasteful for PE2 and PE3 to receive the flooded frames. 158 Whilst the majority of deployments usually have two PEs as part of 159 the redundancy group, in some cases, there may be more than two PEs 160 on the same ES. An example being when capacity demands of the PE are 161 close to the hardware limits of the PE. In this scenario, operators 162 may chose to protect their investments and increase their resilience 163 by installing additional PEs, instead of replacing them or further 164 segmenting the access network. Further,increasing the number of PEs 165 results in efficient load-balancing across vlans. 167 We can now formally describe the issue. In general, consider an EVPN 168 instance, EVIi, that exists in a PE, say PEk. As per existing EVPN 169 behavior, even If PEk is not the DF for any of its Ethernet Segments 170 (that are multi-homed to other PEs) and also there are no other 171 single-homed Ethernet Segments that are part of EVIi in PEk , PEk 172 will still receive BUM traffic meant for EVIi from a remote PE, PEj. 173 This traffic is simply dropped as PEk is not a DF for any of these 174 Ethernet Segments. 176 1. This is an unnecessary usage of bandwidth in the EVPN Core. 178 2. PEk receives traffic which it drops which is non-optimal usage of 179 the L2 Forwarding engine. 181 3. PEj replicates a copy of the Ethernet Frame to PEk which is 182 anyway to be dropped. This consumes cycles at PEj. 184 In this draft we address the above problem and give two simple 185 solutions for the same. These solutions do not mandate any protocol 186 changes and are backwards compatible. 188 4. Solution 1. Suppress the advertisement of the IMET route 190 The first solution is for a PE not to advertise the IMET route if the 191 outcome is to drop the flooded traffic 193 o PEk only needs to advertise "Inclusive Multicast Ethernet Tag 194 route" (Type-3 route) for an EVPN Instance, EVIi if and only if 195 EVIi is configured on at least one Ethernet Segment (which also 196 has a presence in another PEj, i.e Multihomed) and PEk is the DF 197 for that specific Ethernet Segment. 199 o The Type-3 SHOULD also be advertised if there is a "Single-Home" 200 Ethernet Segment on an EVI. 202 o Where a PE is the first DF for an ES on an EVPN Instance, the IMET 203 should be advertised, whereas on the Last DF to Non-DF transition, 204 it should be withdrawn. 206 In the Figure 2 the same EVPN instance exists in PE1, PE2, PE3, PE4 207 and pE5. But only PE1 and PE4 advertise the IMET route. So PE5 208 sends the flood traffic to PE1 and PE4 only. 210 - - -> 211 |- -PE1- - -| 212 | | 213 CE1---|- -PE2 - --|-RR - - PE5- -|-CE2 214 | | 215 |- -PE3- - -+ 216 | 217 CE2- - - PE4- - -+ 218 - - -> 220 An EVPN Network 222 Figure 2 224 With this approach, on a DF PE (PE1) failure, BUM traffic will be 225 dropped until the IMET from the next elected DF [PE2 or PE3], is 226 received at PE5. Note, present behaviour is that BUM is also dropped 227 based on route type 4 withdraw in the peering PEs. In comparison of 228 this proposal with the existing methods, convergence delay will be 229 MAX[Type 4, Type 3 Propagation delays] after the New DF is elected. 230 This leads to our next solution extension, where convergence cannot 231 be traded off over bandwidth optimization. 233 5. Solution 2. Advertisement of the IMET route from the BDF 235 1. Multihomed PEs can easily compute the Backup DF, based on the DF 236 election mode in operation. 238 2. Extending Solution 1, we are proposing that a PE should only 239 advertise Type-3 for an EVI if and only if one of the conditions 240 hold: 242 * It has an Single Home Ethernet Segment, in the EVI 244 * It is DF for at least one Ethernet-Segment, for that EVI 246 * It is BDF for at least one Ethernet-Segment, for that EVI 248 This would mean that, in Fig. 2, in addition to the IMET routes that 249 are being advertised from PE1 and PE4, PE3 also advertises the IMET 250 route since it is the BDF. It can be seen from the above example 251 that with increasing number of multi-homed PEs sharing the same 252 Ethernet-Segment and Vlans, only two PEs will advertise IMET on 253 behalf of an EVI. Of course, if there are some single-homed hosts, 254 there may be some additional IMET advertisements. But the real 255 benefits are in the data plane since this results in no BUM traffic 256 for PEs that do not need it; but would have, nevertheless, got it, as 257 per the existing EVPN procedures. 259 6. Protocol Considerations 261 This idea conforms to existing EVPN drafts that deal with BUM 262 handling [RFC7432], and [I-D.ietf-bess-evpn-igmp-mld-proxy]. 263 Additionally, to take DF Type 4 as explained in 264 [I-D.sajassi-bess-evpn-per-mcast-flow-df-election] into 265 consideration, along the other conditions specified in Sections 4 and 266 5, the PE should advertise IMET if and only if there is at least one 267 (S,G) for which it is DF. For all other DF Types, no additional 268 considerations are required. 270 7. Operational Considerations 272 None 274 8. Security Considerations 276 This document raises no new security issues for EVPN. 278 9. Acknowledgements 280 The authors would like to thank Ali Sajassi for his feedback and 281 insight into the deployments that can benefit from this proposal. 283 10. Contributors 285 Samir Thoria 286 Cisco Systems 287 US 289 Email: sthoria@cisco.com 291 Sameer Gulrajani 292 Cisco Systems 293 US 295 Email: sameerg@cisco.com 297 11. References 299 11.1. Normative References 301 [I-D.ietf-bess-evpn-df-election] 302 satyamoh@cisco.com, s., Patel, K., Sajassi, A., Drake, J., 303 and T. Przygienda, "A new Designated Forwarder Election 304 for the EVPN", draft-ietf-bess-evpn-df-election-03 (work 305 in progress), October 2017. 307 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 308 Requirement Levels", BCP 14, RFC 2119, 309 DOI 10.17487/RFC2119, March 1997, 310 . 312 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 313 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 314 DOI 10.17487/RFC4271, January 2006, 315 . 317 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 318 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 319 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 320 2015, . 322 11.2. Informative References 324 [I-D.ietf-bess-evpn-igmp-mld-proxy] 325 Sajassi, A., Thoria, S., Patel, K., Yeung, D., Drake, J., 326 and W. Lin, "IGMP and MLD Proxy for EVPN", draft-ietf- 327 bess-evpn-igmp-mld-proxy-00 (work in progress), March 328 2017. 330 [I-D.sajassi-bess-evpn-per-mcast-flow-df-election] 331 Sajassi, A., mishra, m., Thoria, S., Rabadan, J., and J. 332 Drake, "Per multicast flow Designated Forwarder Election 333 for EVPN", draft-sajassi-bess-evpn-per-mcast-flow-df- 334 election-00 (work in progress), March 2018. 336 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 337 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 338 2006, . 340 Authors' Addresses 342 Satya Ranjan Mohanty 343 Cisco Systems 344 170 W. Tasman Drive 345 San Jose, CA 95134 346 USA 348 Email: satyamoh@cisco.com 350 Mrinmoy Ghosh 351 Cisco Systems 352 170 W. Tasman Drive 353 San Jose, CA 95134 354 USA 356 Email: mrghosh@cisco.com 357 Sandy Breeze 358 Claranet 359 University of Warwick 360 United Kingdom 362 Email: sandy.breeze@eu.clara.net 364 Jim Uttaro 365 ATT 366 200 S. Laurel Avenue 367 Middletown, CA 07748 368 USA 370 Email: uttaro@att.com