%% You should probably cite draft-wang-bess-evpn-cmac-overload-reduction-07 instead of this revision.
@techreport{wang-bess-evpn-cmac-overload-reduction-01,
    number =    {draft-wang-bess-evpn-cmac-overload-reduction-01},
    type =      {Internet-Draft},
    institution =   {Internet Engineering Task Force},
    publisher = {Internet Engineering Task Force},
    note =      {Work in Progress},
    url =       {https://datatracker.ietf.org/doc/draft-wang-bess-evpn-cmac-overload-reduction/01/},
    author =    {Yubao(Bob) Wang},
    title =     {{Reduction of EVPN C-MAC Overload}},
    pagetotal = 26,
    year =      ,
    month =     ,
    day =       ,
    abstract =  {When there are too many customer-MACs (C-MACs), the RRs and/or ASBRs will be overloaded by the RT-2 routes for these MACs according to {[}RFC7432{]}. This issue can be simply solved by making the remote C-MAC entries learnt via data-plane MAC learning (like what PBB VPLS have done since {[}RFC7041{]}) rather than received from RT-2 routes. This simplified solution will works as well as PBB VPLS. But this simplified solution will lose many important features that based on the ESI concept. Because the ingress-ESI can't be learnt via data- plane MAC learning at the egress PE. So when the data packets is forwarded following these MAC entries, they can't benefit from the EAD/EVI routes as per RFC7432. So the All-Active Redundancy mode for ES can't be supported. This make the simplified solution can't work as well as PBB EVPN ({[}RFC7623{]}). This document proposes some new extensions to {[}RFC7432{]} to achieve all-active mode ES redundancy on TPEs and reduce the C-MAC loads for RRs and ASBRs at the same time. The new solution will work even more better than PBB EVPN under the help of these extensions, especially when there is no deployment of MPLS dataplane. In Section 6.2, this draft is compared with PBB EVPN and other solutions . These solutions are PBB EVPN, PBB VPLS, VXLAN({[}RFC7348{]}).},
}