%% You should probably cite rfc8220 instead of this I-D. @techreport{ietf-pals-vpls-pim-snooping-01, number = {draft-ietf-pals-vpls-pim-snooping-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-ietf-pals-vpls-pim-snooping/01/}, author = {Olivier Dornon and Jayant Kotalwar and Venu Hemige and Ray (Lei) Qiu and Zhaohui (Jeffrey) Zhang}, title = {{Protocol Independent Multicast (PIM) over Virtual Private LAN Service (VPLS)}}, pagetotal = 40, year = 2015, month = oct, day = 16, 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 Protocol Independent Multicast (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, Provider Edges (PEs) do not flood PIM Join/Prune messages but only generate their own and send 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 Equipment (CE) devices and useful to reduce PIM control traffic in a VPLS domain. The document also describes PIM relay, which can be viewed as light- weight proxying, where all downstream Join/Prune messages are simply forwarded out of certain ports but not flooded to avoid triggering PIM Join suppression on CE devices.}, }