%% You should probably cite draft-ietf-bess-evpn-redundant-mcast-source instead of this I-D.
@techreport{skr-bess-evpn-redundant-mcast-source-00,
    number =    {draft-skr-bess-evpn-redundant-mcast-source-00},
    type =      {Internet-Draft},
    institution =   {Internet Engineering Task Force},
    publisher = {Internet Engineering Task Force},
    note =      {Work in Progress},
    url =       {https://datatracker.ietf.org/doc/draft-skr-bess-evpn-redundant-mcast-source/00/},
    author =    {Jorge Rabadan and Jayant Kotalwar and Senthil Sathappan and Eric C. Rosen and Zhaohui (Jeffrey) Zhang and Wen Lin},
    title =     {{Multicast Source Redundancy in EVPN Networks}},
    pagetotal = 28,
    year =      2018,
    month =     oct,
    day =       22,
    abstract =  {EVPN supports intra and inter-subnet IP multicast forwarding. However, EVPN (or conventional IP multicast techniques for that matter) do not have a solution for the case where a given multicast group carries more than one flow (i.e., more than one source), but where it is desired that each receiver gets only one of the several flows. Existing multicast techniques assume there are no redundant sources sending the same flows to the same IP multicast group, and, in case there were redundant sources, the receiver's application would deal with the received duplicated packets. This document extends the existing EVPN specifications and assumes that IP Multicast source redundancy may exist. It also assumes that, in case two or more sources send the same IP Multicast flows into the tenant domain, the EVPN PEs need to avoid that the receivers get packet duplication by following the described procedures.},
}