%% You should probably cite rfc8220 instead of this I-D.
@techreport{ietf-pals-vpls-pim-snooping-06,
    number =    {draft-ietf-pals-vpls-pim-snooping-06},
    type =      {Internet-Draft},
    institution =   {Internet Engineering Task Force},
    publisher = {Internet Engineering Task Force},
    note =      {Work in Progress},
    url =       {https://datatracker.ietf.org/doc/draft-ietf-pals-vpls-pim-snooping/06/},
    author =    {Olivier Dornon and Jayant Kotalwar and Venu Hemige and Ray Qiu and Zhaohui (Jeffrey) Zhang},
    title =     {{Protocol Independent Multicast (PIM) over Virtual Private LAN Service (VPLS)}},
    pagetotal = 43,
    year =      2017,
    month =     jun,
    day =       13,
    abstract =  {This document describes the procedures and recommendations for Virtual Private LAN Service (VPLS) Provider Edges (PEs) to facilitate replication of multicast traffic to only certain ports (behind which there are interested Protocol Independent Multicast (PIM) routers and/or Internet Group Management Protocol (IGMP) hosts) via PIM snooping and proxying. With PIM snooping, PEs passively listen to certain PIM control messages to build control and forwarding states while transparently flooding those messages. With PIM proxying, PEs do not flood PIM Join/Prune messages but only generate their own and send them out of certain ports, based on the control states built from downstream Join/Prune messages. PIM proxying is required when PIM Join suppression is enabled on the Customer Edge (CE) devices and is useful for reducing PIM control traffic in a VPLS domain. This document also describes PIM relay, which can be viewed as lightweight proxying, where all downstream Join/Prune messages are simply forwarded out of certain ports and are not flooded, thereby avoiding the triggering of PIM Join suppression on CE devices.},
}