PALS Workgroup
Internet Engineering Task Force (IETF)                         O. Dornon
Internet-Draft
Request for Comments: 8220                                   J. Kotalwar
Intended status:
Category: Informational                                     Nokia
Expires: December 16, 2017                                        V. Hemige
ISSN: 2070-1721                                                    Nokia
                                                                  R. Qiu
                                                              mistnet.io
                                                                Z. Zhang
                                                  Juniper Networks, Inc.
                                                           June 14,
                                                          September 2017

                  Protocol Independent Multicast (PIM)
                over Virtual Private LAN Service (VPLS)
                  draft-ietf-pals-vpls-pim-snooping-06

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) 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) 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 Equipment Edge (CE) devices and is
   useful to reduce for reducing PIM control traffic in a VPLS domain.

   The

   This document also describes PIM relay, which can be viewed as light-
   weight
   lightweight proxying, where all downstream Join/Prune messages are
   simply forwarded out of certain ports but and are not flooded to avoid flooded, thereby
   avoiding the triggering of PIM Join suppression on CE devices.

Status of This Memo

   This Internet-Draft document is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the Internet Engineering Task Force
   (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list  It represents the consensus of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Not all documents
   approved by the IESG are a maximum candidate for any level of Internet
   Standard; see Section 2 of six months RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on December 16, 2017.
   https://www.rfc-editor.org/info/rfc8220.

Copyright Notice

   Copyright (c) 2017 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info)
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1. Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3 ....................................................4
      1.1. Multicast Snooping in VPLS  . . . . . . . . . . . . . . .   4 .................................5
      1.2. Assumptions . . . . . . . . . . . . . . . . . . . . . . .   5 ................................................6
      1.3. Definitions . . . . . . . . . . . . . . . . . . . . . . .   5 ................................................6
      1.4. Requirements Language ......................................7
   2. PIM Snooping for VPLS . . . . . . . . . . . . . . . . . . . .   6 ...........................................7
      2.1. PIM protocol background . . . . . . . . . . . . . . . . .   6 Protocol Background ....................................7
      2.2. General Rules for PIM Snooping in VPLS  . . . . . . . . .   7 .....................8
           2.2.1. Preserving Assert Trigger . . . . . . . . . . . . . .   7 Triggers ..........................8
      2.3. Some Considerations for PIM Snooping  . . . . . . . . . .   8 .......................9
           2.3.1. Scaling . . . . . . . . . . . . . . . . . . . . . . .   8 .............................................9
           2.3.2. IPv4 and IPv6 . . . . . . . . . . . . . . . . . . . .   9 ......................................10
           2.3.3. PIM-SM (*,*,RP) . . . . . . . . . . . . . . . . . . .   9 ....................................10
      2.4. PIM Snooping vs vs. PIM Proxying  . . . . . . . . . . . . . .   9 .............................10
           2.4.1. Differences between PIM Snooping, Relay Relay,
                  and Proxying    9 .......................................10
           2.4.2. PIM Control Message Latency . . . . . . . . . . . . .  10 ........................11
           2.4.3. When to Snoop and When to Proxy . . . . . . . . . . .  11 ....................12
      2.5. Discovering PIM Routers . . . . . . . . . . . . . . . . .  12 ...................................13
      2.6. PIM-SM and PIM-SSM  . . . . . . . . . . . . . . . . . . .  13 ........................................14
           2.6.1. Building PIM-SM States  . . . . . . . . . . . . . . .  13 .............................15
           2.6.2. Explanation for per (S,G,N) states  . . . . . . . . .  16 Per-(S,G,N) States .................17
           2.6.3. Receiving (*,G) PIM-SM Join/Prune Messages  . . . . .  16 .........18
           2.6.4. Receiving (S,G) PIM-SM Join/Prune Messages  . . . . .  18 .........20
           2.6.5. Receiving (S,G,rpt) Join/Prune Messages . . . . . . .  20 ............22
           2.6.6. Sending Join/Prune Messages Upstream  . . . . . . . .  20 ...............23
      2.7.  Bidirectional-PIM Bidirectional PIM (BIDIR-PIM) . . . . . . . . . . . . . .  21 .............................24
      2.8. Interaction with IGMP Snooping  . . . . . . . . . . . . .  22 ............................24
      2.9. PIM-DM  . . . . . . . . . . . . . . . . . . . . . . . . .  22 ....................................................25
           2.9.1. Building PIM-DM States  . . . . . . . . . . . . . . .  22 .............................25
           2.9.2. PIM-DM Downstream Per-Port PIM(S,G,N) State
                  Machine .  23 ............................................25
           2.9.3. Triggering ASSERT election Assert Election in PIM-DM  . . . . . . . .  23 ...............26
      2.10. PIM Proxy . . . . . . . . . . . . . . . . . . . . . . . .  23 ................................................26
           2.10.1. Upstream PIM Proxy behavior  . . . . . . . . . . . .  24 Behavior .......................26
      2.11. Directly Connected Multicast Source . . . . . . . . . . .  24 ......................26
      2.12. Data Forwarding Data-Forwarding Rules . . . . . . . . . . . . . . . . . .  25 ....................................27
           2.12.1. PIM-SM Data Forwarding Data-Forwarding Rules . . . . . . . . . . . .  25 ......................28
           2.12.2. PIM-DM Data Forwarding Data-Forwarding Rules . . . . . . . . . . . .  26 ......................29
   3. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  27 ............................................29
   4. Security Considerations . . . . . . . . . . . . . . . . . . .  27 ........................................30
   5.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  27
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  28
   7. References  . . . . . . . . . . . . . . . . . . . . . . . . .  28
     7.1. .....................................................30
      5.1. Normative References  . . . . . . . . . . . . . . . . . .  28
     7.2. ......................................30
      5.2. Informative References  . . . . . . . . . . . . . . . . .  29 ....................................31
   Appendix A. BIDIR-PIM Considerations . . . . . . . . . . . . . .  29 ..............................32
     A.1. BIDIR-PIM Data Forwarding Data-Forwarding Rules . . . . . . . . . . . . .  30 ............................32
   Appendix B. Example Network Scenario . . . . . . . . . . . . . .  30 ..............................33
     B.1. PIM Snooping Example  . . . . . . . . . . . . . . . . . .  31 .......................................33
     B.2. PIM Proxy Example with (S,G) / (*,G) interaction  . . . .  34 Interaction ...........36
   Acknowledgements ..................................................42
   Contributors ......................................................42
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  39 ................................................43

1.  Introduction

   In the Virtual Private LAN Service (VPLS), the Provider Edge (PE)
   devices provide a logical interconnect such that Customer Edge (CE)
   devices belonging to a specific VPLS instance appear to be connected
   by a single LAN.  The Forwarding Information Base (FIB) for a VPLS
   instance is populated dynamically by MAC Media Access Control (MAC)
   address learning.  Once a unicast MAC address is learned and
   associated with a particular Attachment Circuit (AC) or PseudoWire pseudowire
   (PW), a frame destined to that MAC address only needs to be sent on
   that AC or PW.

   For a frame not addressed to a known unicast MAC address, flooding
   has to be used.  This happens with the following so called BUM
   (Broadcast so-called "BUM"
   (Broadcast, Unknown Unicast, and Multicast) traffic:

   o  B: The destination MAC address is a broadcast address, address.

   o  U: The destination MAC address is unknown (has not been learned), learned).

   o  M: The destination MAC address is a multicast address.

   Multicast frames are flooded because a PE cannot know where
   corresponding multicast group members reside.  VPLS solutions (i.e.,
   RFC
   (RFC 4762 [VPLS-LDP] and RFC 4761 [VPLS-BGP]) perform replication for
   multicast traffic at the ingress PE devices.  As stated in the VPLS
   Multicast Requirements document RFC (RFC 5501 [VPLS-MCAST-REQ], [VPLS-MCAST-REQ]), there
   are two issues with VPLS multicast today:

   o  A.

   1.  Multicast traffic is replicated to non-member sites.

   o  B.

   2.  Multicast traffic may be replicated when several PWs share a
       physical path.

   Issue A 1 can be solved by multicast snooping - -- PEs learn sites with
   multicast group members by snooping multicast protocol control
   messages on ACs and forward IP multicast traffic only to member
   sites.  This document describes the procedures to achieve this when
   CE devices are PIM adjacencies of each other.  Issue B 2 is outside the
   scope of this document and is discussed in RFC 7117 [VPLS-MCAST] . [VPLS-MCAST].

   While descriptions in this document is are in the context of the VPLS,
   the procedures also apply to regular layer-2 Layer 2 switches interconnected
   by physical connections, except that the PW related concept PW-related concepts and
   procedures do not apply in that case.

1.1.  Multicast Snooping in VPLS

   IGMP snooping procedures described in RFC 4541 [IGMP-SNOOP] make sure
   that IP multicast traffic is only sent on the following:

   o  Attachment Circuits (ACs)  ACs connecting to hosts that report related group membership

   o  ACs connecting to routers that join related multicast groups

   o  PseudoWires (PWs)  PWs connecting to remote PEs that have the above
      described above-described ACs
   Notice

   Note that traffic is always sent on ports that have point-to-point
   connections to routers that are attached to a LAN on which there is
   at least one other router.  Because IGMP snooping alone can not cannot
   determine if there are interested receivers beyond those routers routers, we
   always need to send traffic to these ports, even if there are no
   snooped group memberships.  To further restrict traffic sent to those
   routers, PIM snooping can be used.  This document describes the
   procedures for PIM snooping, including the rules for when both IGMP and
   PIM snooping are enabled in a VPLS instance, which are elaborated in
   sections Section instance; see Sections 2.8 and Section 2.11.
   2.11 for details.

   Note that for both IGMP and PIM, the term snooping "snooping" is used loosely,
   referring to the fact that a layer-2 Layer 2 device peeks into layer-3 Layer 3
   routing protocol messages to build relevant control and forwarding
   states.  Depending on whether the control messages are transparently
   flooded, selectively forwarded, or aggregated, the processing may be
   called snooping "snooping" or proxy "proxying" in different contexts.

   We will use the term PIM snooping "PIM snooping" in this document; but, however, unless
   explicitly noted, noted otherwise, the procedures apply equally to PIM
   snooping and PIM proxying.  The procedures specific to PIM proxying specific procedures
   are described in Section 2.6.6.  Differences that need to be observed
   while implementing one or the other and recommendations on which
   method to employ in different scenarios are noted in section Section 2.4.

   This document also describes PIM relay, which can be viewed as light-
   weight
   lightweight PIM proxying.  Unless explicitly noted, noted otherwise, in the
   rest of the this document proxying implicitly includes relay as well.
   Please refer to Section 2.4.1 for an overview of the differences
   between snooping,
   proxying proxying, and relay.

1.2.  Assumptions

   This document assumes that the reader has a good understanding of the
   PIM protocols.  This  To help correlate the concepts and make the text
   easier to follow, this document is written in the same style as the
   following PIM
   RFCs to help correlate the concepts and to make it easier to follow. RFCs:

   o  RFC 3973 [PIM-DM]

   o  RFC 4607 [PIM-SSM]

   o  RFC 5015 [BIDIR-PIM]

   o  RFC 5384 [JOIN-ATTR]

   o  RFC 7761 [PIM-SM]

   In order to avoid replicating text related to PIM protocol handling
   from the PIM RFCs, this document cross references cross-references corresponding
   definitions and procedures in these those RFCs.  Deviations in protocol
   handling specific to PIM snooping are specified in this document.

1.3.  Definitions

   There are several definitions referenced in this document that are
   well described in the following PIM RFCs RFCs: RFC 7761 [PIM-SM], 3973 [PIM-DM], RFC 5015
   [BIDIR-PIM]
   [BIDIR-PIM], and RFC 3973 [PIM-DM]. 7761 [PIM-SM].  The following definitions and
   abbreviations are used throughout this document:

   o  A port is defined as either an attachment circuit (AC) AC or a
      pseudowire (PW). PW.

   o  When we say that a PIM message is received on a PE port, it means
      that the PE is processing the message for snooping/proxying or
      relaying.

   Abbreviations used in the this document:

   o  S: IP address of the multicast source.

   o  G: IP address of the multicast group.

   o  N: Upstream neighbor Neighbor field in a Join/Prune/Graft message.

   o  Port(N): Port on which neighbor N is learned, i.e. i.e., the port on
      which N's Hellos are received.

   o  rpt :  rpt: Rendezvous Point Tree Tree.

   o  PIM-DM: Protocol Independent Multicast - Dense Mode.

   o  PIM-SM: Protocol Independent Multicast - Sparse Mode.

   o  PIM-SSM: Protocol Independent Multicast - Source Specific Mode.

   Other definitions are explained in the sections where they are
   introduced. Source-Specific
      Multicast.

1.4.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

2.  PIM Snooping for VPLS

2.1.  PIM protocol background Protocol Background

   PIM is a multicast routing protocol running between routers, which
   are CE devices in a VPLS.  It uses the unicast routing table to
   provide reverse path reverse-path information for building multicast trees.  There
   are a few variants of PIM.  In  As described in RFC 3973 [PIM-DM],
   multicast datagrams are pushed towards downstream neighbors, similar
   to a broadcast mechanism, but in areas of the network where there are
   no group members, routers prune back branches of the multicast tree
   towards the source.  Unlike PIM-DM, other PIM flavors (RFC 7761
   [PIM-SM], RFC 4607 [PIM-SSM], and RFC 5015 [BIDIR-PIM]) employ a pull
   methodology via explicit joins Joins instead of the push and prune push-and-prune
   technique.

   PIM routers periodically exchange Hello messages to discover and
   maintain stateful sessions with neighbors.  After neighbors are
   discovered, PIM routers can signal their intentions to join or prune
   specific multicast groups.  This is accomplished by having downstream
   routers send an explicit Join/Prune message (for the sake of
   generalization, consider Graft messages for PIM-DM as Join messages)
   to their corresponding upstream router.  The Join/Prune message can
   be group specific (*,G) or group and source specific(S,G). specific (S,G).

2.2.  General Rules for PIM Snooping in VPLS

   The following rules for the correct operation of PIM snooping MUST be
   followed.

   o  PIM snooping MUST NOT affect the operation of customer layer-2 Layer 2
      protocols or layer-3 Layer 3 protocols.

   o  PIM messages and multicast data traffic forwarded by PEs MUST
      follow the split-horizon rule for mesh PWs, as defined in RFC 4762
      [VPLS-LDP].

   o  PIM states in a PE MUST be per VPLS instance.

   o  PIM assert Assert triggers MUST be preserved to the extent necessary to
      avoid sending duplicate traffic to the same PE (see
      Section 2.2.1).

2.2.1.  Preserving Assert Trigger Triggers

   In PIM-SM/DM, PIM-SM / PIM-DM, there are scenarios where multiple routers could
   be forwarding the same multicast traffic on a LAN.  When this
   happens, these routers start the PIM Assert election process by
   sending PIM Assert messages, to ensure that only the Assert winner
   forwards multicast traffic on the LAN.  The Assert election is a data driven
   data-driven event and happens only if a router sees traffic on the
   interface to which it should be forwarding the traffic.  In the case
   of a VPLS with PIM snooping, two routers may forward the same
   multicast datagrams at the same time time, but each copy may reach a
   different set of PEs, and that PEs; this is acceptable from the point of view of
   avoiding duplicate traffic.  If the two copies may reach the same PE PE,
   then the sending routers must be able to see each other's traffic, in
   order to trigger Assert election and stop duplicate traffic.  To
   achieve that, PEs enabled with PIM-SSM/SM PIM-SSM / PIM-SM snooping MUST forward
   multicast traffic for an
   (S,G)/(*,G) (S,G) / (*,G) not only on the ports on which
   they snooped
   Joins(S,G)/Joins(*,G), Join(S,G) / Join(*,G) but also towards the upstream neighbor(s)).
   neighbor(s).  In other words, the ports on which the upstream
   neighbors are learned must be added to the outgoing port list list, along
   with the ports on which Joins are snooped.  Please refer to
   Section 2.6.1 for the rules that determine the set of upstream
   neighbors for a particular (x,G).

   Similarly, PIM-DM snooping SHOULD make sure that asserts Asserts can be
   triggered (Section 2.9.3).

   The above logic needs to be facilitated without breaking VPLS split-
   horizon
   split-horizon forwarding rules.  That is, traffic should not be
   forwarded on the port on which it was received, and traffic arriving
   on a PW MUST NOT be forwarded onto other PW(s).

2.3.  Some Considerations for PIM Snooping

   The PIM snooping solution described here requires a PE to examine and
   operate on only PIM Hello and PIM Join/Prune packets.  The PE
   does not need to examine any other PIM packets.

   Most of the PIM snooping procedures for handling Hello/Join/Prune
   messages are very similar to those executed in a PIM router.
   However, the PE does not need to have any routing tables like those
   required in PIM multicast routing.  It knows how to forward Join/
   Prunes Join/Prune messages
   only by looking at the Upstream Neighbor field in the Join/
   Prune Join/Prune
   packets, as described in Section 2.12.

   The PE does not need to know about Rendezvous Points (RP) (RPs) and
   does not have to maintain any RP Set.  All of that is transparent to
   a PIM snooping PE.

   In the following sub-sections, subsections, we list some considerations and
   observations for the implementation of PIM snooping in the VPLS.

2.3.1.  Scaling

   PIM snooping needs to be employed on ACs at the downstream PEs (PEs
   receiving multicast traffic across the VPLS core) to prevent traffic
   from being sent out of ACs unnecessarily.  PIM snooping techniques
   can also be employed on PWs at the upstream PEs (PEs receiving
   traffic from local ACs in a hierarchical VPLS) to prevent traffic
   from being sent to PEs unnecessarily.  This may work well for small
   to medium scale
   small-scale or medium-scale deployments.  However, if there are a
   large number of VPLS instances with a large number of PEs per
   instance, then the amount of snooping required at the upstream PEs
   can overwhelm the upstream PEs.

   There are two methods to reduce the burden on the upstream PEs.  One
   is to use PIM proxying proxying, as described in Section 2.6.6, to reduce the
   control messages forwarded by a PE.  The other is not to snoop on the
   PWs at all, all but to have PEs signal the snooped states to other PEs out
   of band via BGP, as described in RFC 7117 [VPLS-MCAST].  In this
   document, it is assumed that snooping is performed on PWs.

2.3.2.  IPv4 and IPv6

   In the VPLS, PEs forward Ethernet frames received from CEs and as
   such are agnostic of the layer-3 Layer 3 protocol used by the CEs.  However,
   as a PIM snooping PE, the PE would have to look deeper into the IP
   and PIM packets and build snooping state based on that.  The PIM Protocol
   protocol specifications handle both IPv4 and IPv6.  The specification
   for PIM snooping in this document can be applied to both IPv4 and
   IPv6 payloads.

2.3.3.  PIM-SM (*,*,RP)

   This document does not address (*,*,RP) states in the VPLS network,
   as they have been removed from the PIM protocol as described in
   RFC 7761 [PIM-SM].

2.4.  PIM Snooping vs vs. PIM Proxying

   This document has previously alluded to PIM snooping/relay/proxying.
   Details on the PIM relay/proxying solution are discussed in
   Section 2.6.6.  In this section, a brief description and comparison
   are given.

2.4.1.  Differences between PIM Snooping, Relay Relay, and Proxying

   Differences between PIM snooping and relay/proxying can be summarized
   as the following: follows:

    +--------------------+---------------------+-----------------------+
    |     PIM snooping   |    PIM relay        |    PIM proxying       |
    +====================|=====================|=======================+
    | Join/Prune messages| Join/Prune messages | Join/Prune messages   |
    | snooped and flooded| snooped; forwarded  | consumed. Regenerated |  Regenerated|
    | according to VPLS  | as is out of certain| ones sent out of      |
    | flooding procedures| upstream ports      | certain upstream ports|
    +--------------------+---------------------+-----------------------+
    | Hello messages     | Hello messages      | Hello messages        |
    | snooped and flooded| snooped and flooded | snooped and flooded   |
    | according to VPLS  | according to VPLS   | according to VPLS     |
    | flooding procedures| flooding procedures | flooding procedures   |
    +--------------------+---------------------+-----------------------+
    | No PIM packets     | No PIM packets      | New Join/Prune        |
    | generated. generated          | generated           | messages generated    |
    +--------------------+---------------------+-----------------------+
    | CE Join suppression| CE Join Suppression suppression | CE Join suppression   |
    | not allowed        | allowed             | allowed               |
    +--------------------+---------------------+-----------------------+
   Other than the above differences, most of the procedures are common
   to PIM snooping and PIM relay/proxying, unless specifically stated
   otherwise.

   Pure PIM snooping PEs simply snoop on PIM packets as they are being
   forwarded in the VPLS.  As such such, they truly provide transparent LAN
   services
   services, since no customer packets are modified or consumed or nor are
   new packets introduced in the VPLS.  It is also simpler to implement
   than PIM proxying.  However  However, for PIM snooping to work correctly, it
   is a requirement that CE routers MUST disable Join suppression in the
   VPLS.  Otherwise, most of the CE routers with interest in a given
   multicast data stream will fail to send Join/Prune messages for that
   stream, and the PEs will not be able to tell which ACs and/or PWs
   have listeners for that stream.

   Given that a large number of existing CE deployments do not support
   the disabling of Join suppression and given the operational
   complexity for a provider to manage the disabling of Join suppression
   in the VPLS, it becomes a difficult solution to deploy.  Another
   disadvantage of PIM snooping is that it does not scale as well as PIM
   proxying.  If there are a large number of CEs in a VPLS, then every
   CE will see every other CE's Join/Prune messages.

   PIM relay/proxying has the advantage that it does not require Join
   suppression to be disabled in the VPLS.  Multicast as part of a VPLS service
   can be very easily provided without requiring any changes on the CE
   routers.  PIM relay/proxying helps scale VPLS Multicast multicast, since Join/
   Prune
   Join/Prune messages are only sent to certain upstream ports instead
   of flooded, and in case cases of full proxying (vs. relay) relay), the PEs
   intelligently generate only one Join/Prune message for a given
   multicast stream.

   PIM proxying however proxying, however, loses the transparency argument argument, since Join/
   Prunes
   Join/Prune packets could get modified or even consumed at a PE.
   Also, new packets could get introduced in the VPLS.  However, this
   loss of transparency is limited to PIM Join/Prune packets.  It is in
   the interest of optimizing multicast in the VPLS and helping a VPLS
   network scale much better, both for both the provider and the customer.
   Data traffic will still be completely transparent.

2.4.2.  PIM Control Message Latency

   A PIM snooping/relay/proxying PE snoops on PIM Hello packets while
   transparently flooding them in the VPLS.  As such such, there is no
   latency introduced by the VPLS in the delivery of PIM Hello packets
   to remote CEs in the VPLS.

   A PIM snooping PE snoops on PIM Join/Prune packets while
   transparently flooding them in the VPLS.  There is no latency
   introduced by the VPLS in the delivery of PIM Join/Prune packets when
   PIM snooping is employed.

   A PIM relay/proxying PE does not simply flood PIM Join/Prune packets.
   This can result in additional latency for a downstream CE to receive
   multicast traffic after it has sent a Join.  When a downstream CE
   prunes a multicast stream, the traffic SHOULD stop flowing to the CE
   with no additional latency introduced by the VPLS.

   Performing only proxying of Join/Prune and not Hello messages keeps
   the PE PE's behavior very similar to that of a PIM router router, without
   introducing too much additional complexity.  It keeps the PIM
   proxying solution fairly simple.  Since Join/Prunes Join/Prune messages are
   forwarded by a PE along the slow-path slow path and all other PIM packet types
   are forwarded along the fast-path, fast path, it is very likely that packets
   forwarded along the fast-path fast path will arrive "ahead" of Join/Prune
   packets at a CE router (note the stress on the fact that fast-path
   messages will never arrive after Join/Prunes). Join/Prune packets).  Of particular
   importance are Hello packets sent along the fast-path. fast path.  We can
   construct a variety of scenarios resulting in out of order out-of-order delivery
   of Hellos and Join/Prune messages.  However, there should be no
   deviation from normal expected behavior observed at the CE router
   receiving these messages out of order.

2.4.3.  When to Snoop and When to Proxy

   From the above descriptions, factors that affect the choice of
   snooping/relay/proxying include:

   o  Whether CEs do Join Suppression suppression or not

   o  Whether Join/Prune latency is critical or not

   o  Whether the scale of PIM protocol message/states messages/states in a VPLS
      requires the scaling benefit of proxying

   Of the above factors, Join Suppression suppression is the hard one - -- pure
   snooping can only be used when Join Suppression suppression is disabled on all
   CEs.  The latency associated with relay/proxying is implementation
   dependent and may not be a concern at all with a particular
   implementation.  The scaling benefit may not be important either,
   in that on a real LAN with Explicit Tracking (ET) a PIM router will
   need to receive and process all PIM Join/Prune messages as well.

   A PIM router indicates that Join Suppression suppression is disabled if the T-bit
   is set in the LAN Prune Delay option of its Hello message.  If all
   PIM routers on a LAN set the T-bit, Explicit Tracking ET is possible, allowing an
   upstream router to track all the downstream neighbors that have Join
   states for any (S,G) or (*,G).  That  This has two benefits:

   o  No need for PrunePending the Prune-Pending process - -- the upstream router may
      immediately stop forwarding data when it receives a Prune from the
      last downstream neighbor, neighbor and immediately prune to its upstream if
      that's for the last downstream interface.
      neighbor.

   o  For management purpose, purposes, the upstream router knows exactly which
      downstream routers exist for a particular Join State. state.

   While full proxying can be used with or without Join Suppression suppression on
   CEs and does not interfere with an upstream CE's bypass of
   PrunePending the
   Prune-Pending process, it does proxy all its downstream CEs as a
   single one to the upstream, upstream neighbors, removing the second benefit
   mentioned above.

   Therefore, the general rule is that if Join Suppression suppression is enabled on
   one or more CEs CEs, then proxying or relay MUST be used, but if
   Suppression Join
   suppression is known to be disabled on all CEs CEs, then either snooping, relay,
   or proxying MAY be used used, while snooping or relay SHOULD be used.

   An implementation MAY choose dynamic determination of to dynamically determine which mode to
   use, through the tracking of the above mentioned above-mentioned T-bit in all snooped
   PIM Hello messages, or MAY simply require static provisioning.

2.5.  Discovering PIM Routers

   A PIM snooping PE MUST snoop on PIM Hellos received on ACs and PWs.
   i.e.,
   That is, the PE transparently floods the PIM Hello while snooping on
   it.  PIM Hellos are used by the snooping PE to discover PIM routers
   and their characteristics.

   For each neighbor discovered by a PE, it includes an entry in the PIM
   Neighbor Database with the following fields:

   o  Layer 2 encapsulation for the Router router sending the PIM Hello.

   o  IP Address address and address family of the Router router sending the PIM Hello.

   o  Port (AC / PW) (AC/PW) on which the PIM Hello was received.

   o  Hello TLVs Option fields.

   The PE should be able to interpret and act on Hello TLVs Option fields as
   currently defined in the PIM RFCs. RFC 7761 [PIM-SM].  The TLVs Option fields of
   particular interest in this document are:

   o  Hello-Hold-Time

   o  Tracking Support

   o  DR  Designated Router (DR) Priority

   Please refer to RFC 7761 [PIM-SM] for a list of the Hello TLVs. Option
   fields.  When a PIM Hello is received, the PE MUST reset the
   neighbor-expiry-timer to Hello-Hold-Time.  If a PE does not receive a
   Hello message from a router within Hello-Hold-Time, the PE MUST
   remove that neighbor from its PIM Neighbor Database.  If a PE
   receives a Hello message from a router with the Hello-Hold-Time value
   set to zero, the PE MUST remove that router from the PIM snooping
   state immediately.

   From the PIM Neighbor Database, a PE MUST be able to use the
   procedures defined in RFC 7761 [PIM-SM] to identify the PIM
   Designated Router DR in the
   VPLS instance.  It should also be able to determine if Tracking Support tracking
   support is active in the VPLS instance.

2.6.  PIM-SM and PIM-SSM

   The key characteristic of PIM-SM and PIM-SSM is explicit join Join
   behavior.  In this model, multicast traffic is only forwarded to
   locations that specifically request it.  All the procedures described
   in this section apply to both PIM-SM and PIM-SSM, except for the fact
   that there is no (*,G) state in PIM-SSM.

2.6.1.  Building PIM-SM States

   PIM-SM and PIM-SSM states are built by snooping on the PIM-SM Join/
   Prune
   Join/Prune messages received on AC/PWs. ACs/PWs.

   The downstream state machine of a PIM-SM snooping PE very closely
   resembles the downstream state machine of PIM-SM routers.  The
   downstream state consists of:

   Per downstream (Port, *, G): (Port,*,G):

   o  DownstreamJPState: One of { "NoInfo" {"NoInfo" (NI), "Join" (J), "Prune
      Pending" (PP) }
      "Prune-Pending" (PP)}

   Per downstream (Port, *, G, N): (Port,*,G,N):

   o  Prune Pending  Prune-Pending Timer (PPT(N))

   o  Join Expiry Timer (ET(N))

   Per downstream (Port, S, G): (Port,S,G):

   o  DownstreamJPState: One of { "NoInfo" {"NoInfo" (NI), "Join" (J), "Prune
      Pending" (PP) }
      "Prune-Pending" (PP)}

   Per downstream (Port, S, G, N): (Port,S,G,N):

   o  Prune Pending  Prune-Pending Timer (PPT(N))

   o  Join Expiry Timer (ET(N))

   Per downstream (Port, S, G, rpt): (Port,S,G,rpt):

   o  DownstreamJPRptState: One of { "NoInfo" {"NoInfo" (NI), "Pruned" (P), "Prune
      Pending" (PP) }
      "Prune-Pending" (PP)}

   Per downstream (Port, S, G, rpt, N): (Port,S,G,rpt,N):

   o  Prune Pending  Prune-Pending Timer (PPT(N))

   o  Join Expiry Timer (ET(N))

   Where

   where S is the address of the multicast source, G is the Group
   address group
   address, and N is the upstream neighbor Upstream Neighbor field in the Join/Prune
   message.  Notice

   Note that unlike on the case of PIM-SM routers routers, where the PPT and ET are
   per (Interface, S, G), (Interface,S,G), PIM snooping PEs have to maintain the PPT and ET
   per (Port, S, G, N). (Port,S,G,N).  The reasons for this are explained in
   Section 2.6.2.

   Apart from the above states, we define the following state
   summarization macros. macros:

   UpstreamNeighbors(*,G):  If there is are one or more Join(*,G) Join(*,G)s received
      on any port with upstream neighbor N and ET(N) is active, then N
      is added to UpstreamNeighbors(*,G).  This set is used to determine
      if a Join(*,G) or a Prune(*,G) with upstream neighbor N needs to
      be sent upstream.

   UpstreamNeighbors(S,G):  If there is are one or more Join(S,G) Join(S,G)s received
      on any port with upstream neighbor N and ET(N) is active, then N
      is added to UpstreamNeighbors(S,G).  This set is used to determine
      if a Join(S,G) or a Prune(S,G) with upstream neighbor N needs to
      be sent upstream.

   UpstreamPorts(*,G):  This is the set of all Port(N) ports where N is
      in the set UpstreamNeighbors(*,G).  Multicast Streams streams forwarded
      using a (*,G) match MUST be forwarded to these ports.  So  So,
      UpstreamPorts(*,G) MUST be added to OutgoingPortList(*,G).

   UpstreamPorts(S,G):  This is the set of all Port(N) ports where N is
      in the set UpstreamNeighbors(S,G).  UpstreamPorts(S,G) MUST be
      added to OutgoingPortList(S,G).

   InheritedUpstreamPorts(S,G):  This is the union of UpstreamPorts(S,G)
      and UpstreamPorts(*,G).

   UpstreamPorts(S,G,rpt):  If PruneDesired(S,G,rpt) becomes true, TRUE, then
      this set is set to UpstreamPorts(*,G).  Otherwise, this set is
      empty.  UpstreamPorts(*,G) (-) UpstreamPorts(S,G,rpt) MUST be
      added to OutgoingPortList(S,G).

   UpstreamPorts(G):  This set is the union of all the
      UpstreamPorts(S,G) and UpstreamPorts(*,G) for a given G. proxy  Proxy
      (S,G) Join/Prune and (*,G) Join/Prune messages MUST be sent to a
      subset of UpstreamPorts(G) as specified in Section 2.6.6.1.

   PWPorts:  This is the set of all PWs.

   OutgoingPortList(*,G):  This is the set of all ports to which traffic
      needs to be forwarded on a (*,G) match.

   OutgoingPortList(S,G):  This is the set of all ports to which traffic
      needs to be forwarded on an (S,G) match.

   See Section 2.12 on Data Forwarding Rules ("Data-Forwarding Rules") for the specification on
   how OutgoingPortList is calculated.

   NumETsActive(Port,*,G): Number  This is the number of (Port,*,G,N) entries
      that have the Expiry Timer running.  This macro keeps track of the
      number of Join(*,G)s that are received on this Port with different
      upstream neighbors.

   NumETsActive(Port,S,G): Number  This is the number of (Port,S,G,N) entries
      that have the Expiry Timer running.  This macro keeps track of the
      number of Join(S,G)s that are received on this Port with different
      upstream neighbors.

   JoinAttributeTlvs(*,G):  Join Attributes RFC (RFC 5384 [JOIN-ATTR] [JOIN-ATTR]) are
      TLVs that may be present in received Join(*,G) messages, an messages.  An
      example would be RPF Reverse Path Forwarding (RPF) Vectors RFC (RFC 5496 [RPF-VECTOR].
      [RPF-VECTOR]).  If present, they must be copied to
      JoinAttributeTlvs(*,G).

   JoinAttributeTlvs(S,G):  Join Attributes RFC (RFC 5384 [JOIN-ATTR] [JOIN-ATTR]) are
      TLVs that may be present in received Join(S,G) messages.  If
      present, they must be copied to JoinAttributeTlvs(S,G).

   Since there are a few differences between the downstream state
   machines of PIM-SM Routers routers and PIM-SM snooping PEs, we specify the
   details of the downstream state machine of PIM-SM snooping PEs PEs, at
   the risk of repeating most of the text documented in RFC 7761
   [PIM-SM].

2.6.2.  Explanation for per (S,G,N) states Per-(S,G,N) States

   In PIM Routing routing protocols, states are built per (S,G).  On a router,
   an (S,G) has only one RPF-Neighbor.  However, a PIM snooping PE
   does not have the Layer 3 routing information available to the
   routers in order to determine the RPF-Neighbor for a multicast flow.
   It merely discovers it by snooping the Join/Prune message.  A PE
   could have snooped on two or more different Join/Prune messages for
   the same (S,G) that could have carried different Upstream-Neighbor Upstream Neighbor
   fields.  This could happen during transient network conditions or due
   to dual-
   homed dual-homed sources.  A PE cannot make assumptions on which one to pick,
   pick but instead must allow the CE routers to decide which Upstream
   Neighbor upstream
   neighbor gets elected as the RPF-Neighbor.  And for this purpose,
   the PE will have to track downstream and upstream Join/Prune Joins and Prunes
   per (S,G,N).

2.6.3.  Receiving (*,G) PIM-SM Join/Prune Messages

   A Join(*,G) or Prune(*,G) is considered "received" if one of the
   following conditions are is met:

   o  The port on which it arrived is not Port(N) where N is the
      upstream-neighbor
      upstream neighbor N of the Join/Prune(*,G), or, Join/Prune(*,G).

   o  if  If both Port(N) and the arrival port are PWs, then there exists at
      least one other (*,G,Nx) or (Sx,G,Nx) state with an AC
      UpstreamPort.

   For simplicity, the case where both Port(N) and the arrival port are
   PWs is referred to as PW-only Join/Prune "PW-only Join/Prune" in this document.  The PW-
   only
   PW-only Join/Prune handling is so that the Port(N) PW can be added to
   the related forwarding entries' OutgoingPortList to trigger an
   Assert, but that is only needed for those states with AC UpstreamPort.
   UpstreamPorts.  Note that in the PW-only case, it is OK for the
   arrival port and Port(N) to be the same.  See Appendix B for
   examples.

   When a router receives a Join(*,G) or a Prune(*,G) with upstream
   neighbor N, it must process the message as defined in the state
   machine below.  Note that the macro computations of the various
   macros resulting from this state machine transition is are exactly as
   specified in the PIM-SM RFC 7761 [PIM-SM].

   We define the following per-port (*,G,N) macro to help with the state
   machine below.

   Figure 1 : Downstream per-port (*,G) state machine in tabular form

   +---------------++---------------------------------------------+

   +---------------++-------------------------------------------------+
   |               ||                 Previous State                  |
   |               ++------------+--------------+-----------------+               ++-------------+--------------+--------------------+
   | Event         ||NoInfo         || NoInfo (NI) | Join (J)     | Prune-Pend Prune-Pending (PP) |
   +---------------++------------+--------------+-----------------+
   +---------------++-------------+--------------+--------------------+
   | Receive       ||->       || -> J state  | -> J state   | -> J state         |
   | Join(*,G)     || Action      | Action       | Action             |
   |               || RxJoin(N)   | RxJoin(N)    | RxJoin(N)          |
   +---------------++------------+--------------+-----------------+
   +---------------++-------------+--------------+--------------------+
   |Receive        || -           | -> PP state  | -> PP state        |
   |Prune(*,G) and ||             | Start PPT(N) |                    |
   |NumETsActive<=1||             |              |                    |
   +---------------++------------+--------------+-----------------+
   +---------------++-------------+--------------+--------------------+
   |Receive        || -           | -> J state   | -                  |
   |Prune(*,G) and ||             | Start PPT(N) |                    |
   |NumETsActive>1 ||             |              |                    |
   +---------------++------------+--------------+-----------------+
   +---------------++-------------+--------------+--------------------+
   |PPT(N) expires || -           | -> J state   | -> NI state        |
   |               ||             | Action       | Action             |
   |               ||             | PPTExpiry(N) |PPTExpiry(N) |
   +---------------++------------+--------------+-----------------+ PPTExpiry(N)       |
   +---------------++-------------+--------------+--------------------+
   |ET(N) expires  || -           | -> NI state  | -> NI state        |
   |and            ||             | Action       | Action             |
   |NumETsActive<=1||             | ETExpiry(N)  | ETExpiry(N)        |
   +---------------++------------+--------------+-----------------+
   +---------------++-------------+--------------+--------------------+
   |ET(N) expires  || -           | -> J state   | -                  |
   |and            ||             | Action       |                    |
   |NumETsActive>1 ||             | ETExpiry(N)  |                    |
   +---------------++------------+--------------+-----------------+
   +---------------++-------------+--------------+--------------------+

     Figure 1: Downstream Per-Port (*,G) State Machine in Tabular Form

   Action RxJoin(N):

      If ET(N) is not already running, then start ET(N).  Otherwise  Otherwise,
      restart ET(N).  If N is not already in UpstreamNeighbors(*,G),
      then add N to UpstreamNeighbors(*,G) and trigger a Join(*,G) with
      upstream neighbor N to be forwarded upstream.  If there are Join
      Attribute TLVs in the received (*,G) message and if they are
      different from the recorded JoinAttributeTlvs(*,G), then copy them
      into JoinAttributeTlvs(*,G).  In the case of conflicting attributes
      attributes, the PE will need to perform conflict resolution per
      (N) as described in RFC 5384 [JOIN-ATTR].

   Action PPTExpiry(N):

      Same as Action ETExpiry(N) below, plus Send send a Prune-Echo(*,G) with
      upstream-neighbor
      upstream neighbor N on the downstream port.

   Action ETExpiry(N):

      Disable timers ET(N) and PPT(N).  Delete neighbor Neighbor state
      (Port,*,G,N).  If there are no other (Port,*,G) states with
      NumETsActive(Port,*,G) > 0, transition DownstreamJPState [PIM-SM] (RFC 7761
      [PIM-SM]) to NoInfo.  If there are no other (Port,*,G,N) state states
      (different ports but for the same N), remove N from
      UpstreamPorts(*,G) - -- this will also serves as a trigger for the Upstream FSM (JoinDesired(*,G,N)
      becomes FALSE). Finite
      State Machine (FSM) with "JoinDesired(*,G,N) to FALSE".

2.6.4.  Receiving (S,G) PIM-SM Join/Prune Messages

   A Join(S,G) or Prune(S,G) is considered "received" if one of the
   following conditions are is met:

   o  The port on which it arrived is not Port(N) where N is the
      upstream-neighbor
      upstream neighbor N of the Join/Prune(S,G), or, Join/Prune(S,G).

   o  if  If both Port(N) and the arrival port are PWs, then there exists at
      least one other (*,G,Nx) or (S,G,Nx) state with an AC
      UpstreamPort.

   For simplicity, the case where both Port(N) and the arrival port are
   PWs is referred to as PW-only Join/Prune "PW-only Join/Prune" in this document.  The PW-
   only
   PW-only Join/Prune handling is so that the Port(N) PW can be added to
   the related forwarding entries' OutgoingPortList to trigger an
   Assert, but that is only needed for those states with AC UpstreamPort.
   UpstreamPorts.  Note that in the PW-only case, it is OK for the
   arrival port and Port(N) to be the same.  See Appendix B for
   examples.

   When a router receives a Join(S,G) or a Prune(S,G) with upstream
   neighbor N, it must process the message as defined in the state
   machine below.  Note that the macro computations of the various
   macros resulting from this state machine transition is are exactly as
   specified in RFC 7761 [PIM-SM].

   Figure 2: Downstream per-port (S,G) state machine in tabular form

   +---------------++---------------------------------------------+

   +---------------++-------------------------------------------------+
   |               ||                 Previous State                  |
   |               ++------------+--------------+-----------------+               ++-------------+--------------+--------------------+
   | Event       ||NoInfo         || NoInfo (NI) | Join (J)     | Prune-Pend Prune-Pending (PP) |
   +---------------++------------+--------------+-----------------+
   +---------------++-------------+--------------+--------------------+
   | Receive       ||->       || -> J state  | -> J state   | -> J state         |
   | Join(S,G)     || Action      | Action       | Action             |
   |               || RxJoin(N)   | RxJoin(N)    | RxJoin(N)          |
   +---------------++------------+--------------+-----------------+
   +---------------++-------------+--------------+--------------------+
   |Receive        || -           | -> PP state  | -                  |
   |Prune (S,G) and||
   |Prune(S,G) and ||             | Start PPT(N) |                    |
   |NumETsActive<=1||             |              |                    |
   +---------------++------------+--------------+-----------------+
   +---------------++-------------+--------------+--------------------+
   |Receive        || -           | -> J state   | -                  |
   |Prune(S,G) and ||             | Start PPT(N) |                    |
    NumETsActive>1
   |NumETsActive>1 ||             |              |                    |
   +---------------++------------+--------------+-----------------+
   +---------------++-------------+--------------+--------------------+
   |PPT(N) expires || -           | -> J state   | -> NI state        |
   |               ||             | Action       | Action             |
   |               ||             | PPTExpiry(N) |PPTExpiry(N)        |
   +---------------++------------+--------------+-----------------+
   +---------------++-------------+--------------+--------------------+
   |ET(N) expires  || -           | -> NI state  | -> NI state        |
   |and            ||             | Action       | Action             |
   |NumETsActive<=1||             | ETExpiry(N)  | ETExpiry(N)        |
   +---------------++------------+--------------+-----------------+
   +---------------++-------------+--------------+--------------------+
   |ET(N) expires  || -           | -> J state   | -                  |
   |and            ||             | Action       |                    |
   |NumETsActive>1 ||             | ETExpiry(N)  |                    |
   +---------------++------------+--------------+-----------------+
   +---------------++-------------+--------------+--------------------+

     Figure 2: Downstream Per-Port (S,G) State Machine in Tabular Form
   Action RxJoin(N):

      If ET(N) is not already running, then start ET(N).  Otherwise,
      restart ET(N).

      If N is not already in UpstreamNeighbors(S,G), then add N to
      UpstreamNeighbors(S,G) and trigger a Join(S,G) with upstream
      neighbor N to be forwarded upstream.  If there are Join Attribute
      TLVs in the received (S,G) message and if they are different from
      the recorded JoinAttributeTlvs(S,G), then copy them into
      JoinAttributeTlvs(S,G).  In case cases of conflicting attributes attributes, the
      PE will need to perform conflict resolution per (N) as described
      in RFC 5384 [JOIN-ATTR].

   Action PPTExpiry(N):

      Same as Action ETExpiry(N) below, plus Send send a Prune-Echo(S,G) with
      upstream-neighbor
      upstream neighbor N on the downstream port.

   Action ETExpiry(N):

      Disable timers ET(N) and PPT(N).  Delete neighbor Neighbor state
      (Port,S,G,N).  If there are no other (Port,S,G) states with
      NumETsActive(Port,S,G) > 0, transition DownstreamJPState to
      NoInfo.  If there are no other (Port,S,G,N) state states (different
      ports but for the same N), remove N from UpstreamPorts(S,G) - --
      this will also
      serves as a trigger for the Upstream FSM (JoinDesired(S,G,N) becomes
      FALSE). with "JoinDesired(S,G,N)
      to FALSE".

2.6.5.  Receiving (S,G,rpt) Join/Prune Messages

   A Join(S,G,rpt) or Prune(S,G,rpt) is "received" when the port on
   which it was received is not also the port on which the upstream-
   upstream neighbor N of the Join/Prune(S,G,rpt) was learned.

   While it is important to ensure that the (S,G) and (*,G) state
   machines allow for handling per (S,G,N) per-(S,G,N) states, it is not as
   important for (S,G,rpt) states.  It suffices to say that the
   downstream (S,G,rpt) state machine is the same as what is defined in
   section
   Section 4.5.3 of the RFC 7761 [PIM-SM].

2.6.6.  Sending Join/Prune Messages Upstream

   This section applies only to a PIM relay/proxying PE and not to a PIM
   snooping PE.

   A full PIM proxying (not relay) PE MUST implement the Upstream FSM
   for which
   along the procedures are similar to what is defined lines of the procedure described in section Section 4.5.4 of
   RFC 7761 [PIM-SM].

   For the purposes of the Upstream FSM, a Join or Prune message with
   upstream neighbor N is "seen" on a PIM relay/proxying PE if the port
   on which the message was received is also Port(N), Port(N) and the port is an
   AC.  The AC requirement is needed because a Join received on the
   Port(N) PW must not suppress this PE's Join on that PW.

   A PIM relay PE does not implement the Upstream FSM.  It simply
   forwards received Join/Prune messages out of the same set of upstream
   ports as in the PIM proxying case.

   In order to correctly facilitate assert Asserts among the CE routers, such
   Join/Prunes
   Join/Prune messages need to send not only towards the upstream neighbor,
   neighbor but also on certain PWs PWs, as described below.

   If JoinAttributeTlvs(*,G) is not empty, then it must be encoded in a
   Join(*,G) message sent upstream.

   If JoinAttributeTlvs(S,G) is not empty, then it must be encoded in a
   Join(S,G) message sent upstream.

2.6.6.1.  Where to send Send Join/Prune messages Messages

   The following rules apply, apply to both (1) forwarded (in the case of PIM relay),
   refresh
   relay) and (2) refreshed and triggered (in the case of PIM proxying) (S,G)/(*,G) Join/
   Prune
   (S,G) / (*,G) Join/Prune messages.

   o  The upstream neighbor Upstream Neighbor field in the Join/Prune to be sent is set to
      the N in the corresponding Upstream FSM.

   o  if  If Port(N) is an AC, send the message to Port(N).

   o  Additionally, if OutgoingPortList(x,G,N) contains at least one AC,
      then the message MUST be sent to at least all the PWs in
      UpstreamPorts(G) (for (*,G)) or InheritedUpstreamPorts(S,G) (for
      (S,G)).  Alternatively, the message MAY be sent to all PWs.

   Sending to a subset of PWs as described above guarantees that if
   traffic (of the same flow) from two upstream routers were to reach
   this PE, then the two routers will receive from each other,
   triggering assert. an Assert.

   Sending to all PWs guarantees that if two upstream routers both send
   traffic for the same flow (even if it is to different sets of
   downstream PEs), then they'll the two routers will receive from each other,
   triggering
   assert. an Assert.

2.7.  Bidirectional-PIM  Bidirectional PIM (BIDIR-PIM)

   Bidirectional PIM (BIDIR-PIM)

   BIDIR-PIM is a variation of PIM-SM.  The main
   differences between PIM-SM and Bidirectional-PIM BIDIR-PIM are as follows:

   o  There are no source-based trees, and source-specific multicast SSM is not supported (i.e.,
      no (S,G) states) in BIDIR-PIM.

   o  Multicast traffic can flow up the shared tree in BIDIR-PIM.

   o  To avoid forwarding loops, one router on each link is elected as
      the Designated Forwarder (DF) for each RP in BIDIR-PIM.

   The main advantage of BIDIR-PIM is that it scales well for many-to-
   many
   many-to-many applications.  However, the lack of source-based trees
   means that multicast traffic is forced to remain on the shared tree.

   As described in RFC 5015 [BIDIR-PIM], parts of a BIDIR-PIM enabled BIDIR-PIM-enabled
   network may forward traffic without exchanging Join/Prune messages, messages --
   for instance instance, between DF's DFs and the Rendezvous Point Link (RPL).

   As the described procedures for PIM snooping rely on the presence of
   Join/Prune messages, enabling PIM snooping on BIDIR-PIM networks
   could break the BIDIR-PIM functionality.  Deploying PIM snooping on
   BIDIR-PIM enabled
   BIDIR-PIM-enabled networks will require some further study.  Some
   thoughts on this topic are gathered discussed in Appendix A.

2.8.  Interaction with IGMP Snooping

   Whenever IGMP snooping is enabled in conjunction with PIM snooping in
   the same VPLS instance instance, the PE SHOULD follow these rules:

   o  To maintain the list of multicast routers and ports on which they
      are attached, the PE SHOULD NOT use the rules as described in
      RFC 4541 [IGMP-SNOOP] but SHOULD rely on the neighbors discovered
      by PIM snooping.  This list SHOULD then be used to apply the first
      forwarding rule as described (rule 1) listed in 2.1.1.(1) Section 2.1.1 of RFC 4541
      [IGMP-SNOOP].

   o  If the PE supports proxy-reporting, proxy reporting, an IGMP membership learned
      only on a port to which a PIM neighbor is attached but (i.e., not
      elsewhere
      learned elsewhere) SHOULD NOT be included in the summarized
      upstream report sent to that port.

2.9.  PIM-DM

   The characteristics key characteristic of PIM-DM is flood and prune flood-and-prune behavior.  Shortest
   path
   Shortest-path trees are built as a multicast source starts
   transmitting.

2.9.1.  Building PIM-DM States

   PIM-DM states are built by snooping on the PIM-DM Join, Prune, Graft Graft,
   and State Refresh messages received on AC/PWs ACs/PWs and State- State Refresh
   Messages
   messages sent on AC/PWs. ACs/PWs.  By snooping on these PIM-DM messages, a PE
   builds the following states per (S,G,N) where S is the address of the
   multicast source, G is the Group address group address, and N is the upstream
   neighbor to which Prunes/Grafts are sent by downstream CEs:

   Per PIM (S,G,N): PIM(S,G,N):

      Port PIM (S,G,N) PIM(S,G,N) Prune State:

      *  DownstreamPState(S,G,N,Port): One of {"NoInfo" (NI),
         "Pruned" (P), "PrunePending" "Prune-Pending" (PP)}

      *  Prune Pending  Prune-Pending Timer (PPT)

      *  Prune Timer (PT)

      *  Upstream Port (valid if the PIM(S,G,N) Prune State state is
         "Pruned"). "Pruned")

2.9.2.  PIM-DM Downstream Per-Port PIM(S,G,N) State Machine

   The downstream per-port PIM(S,G,N) state machine is as defined in
   section
   Section 4.4.2 of RFC 3973 [PIM-DM] [PIM-DM], with a few changes relevant to
   PIM snooping.  When reading section Section 4.4.2 of RFC 3973 [PIM-DM] [PIM-DM],
   please be aware that, for the purposes of PIM-snooping please be aware that PIM snooping, the
   downstream states are built per (S, G, N, Downstream-Port} (S,G,N,Downstream-Port) in PIM-snooping PIM
   snooping and not per
   {Downstream- Interface, S, G} (Downstream-Interface,S,G) as in a PIM-DM
   router.  As noted in the
   previous Section 2.9.1, the states (DownstreamPState) and
   timers (PPT and PT) are per (S,G,N,P). (S,G,N,Port).

2.9.3.  Triggering ASSERT election Assert Election in PIM-DM

   Since PIM-DM is a flood-and-prune protocol, traffic is flooded to all
   routers unless explicitly pruned.  Since PIM-DM routers do not prune
   on non-RPF interfaces, PEs should typically not receive Prunes on
   Port(RPF-neighbor).  So
   Port(RPF-Neighbor).  So, the asserting routers should typically be in
   pim_oiflist(S,G).  In most cases, assert Assert election should occur
   naturally without any special handling handling, since data traffic will be
   forwarded to the asserting routers.

   However, there are some scenarios where a prune Prune might be received on
   a port which that is also an upstream port (UP). port.  If we prune the port from
   pim_oiflist(S,G), then it would not be possible for the asserting
   routers to determine if traffic arrived on their downstream port.
   This can be fixed by adding pim_iifs(S,G) to pim_oiflist(S,G) so that
   data traffic flows to the UP upstream ports.

2.10.  PIM Proxy

   As noted earlier, PIM snooping will work correctly only if Join
   Suppression
   suppression is disabled in the VPLS.  If Join Suppression suppression is enabled
   in the VPLS, then PEs MUST do PIM relay/proxying for VPLS multicast
   to work correctly.  This section applies specifically to the full
   proxying case and not to relay.

2.10.1.  Upstream PIM Proxy behavior Behavior

   A PIM proxying PE consumes Join/Prune messages and regenerates PIM
   Join/Prune messages to be sent upstream by implementing the Upstream
   FSM as specified in the PIM RFC. Section 4.5.4 of RFC 7761 [PIM-SM].  This is the
   only difference from PIM relay.

   The source IP address in PIM packets sent upstream SHOULD be the
   address of a PIM downstream neighbor in the corresponding join/prune Join/Prune
   state.  The chosen address picked MUST NOT be the upstream neighbor Upstream Neighbor field to
   be encoded in the packet.  The layer Layer 2 encapsulation for the selected
   source IP address MUST be the encapsulation recorded in the PIM
   Neighbor database Database for that IP address.

2.11.  Directly Connected Multicast Source

   PIM snooping/relay/proxying could be enabled on a LAN that connects a
   multicast source and a PIM First Hop First-Hop Router (FHR).  As the FHR
   will not send any downstream Join/Prune messages messages, we will not be able
   to establish any forwarding states for that source.  Therefore, if
   there is a source in the CE network that connects directly into the
   VPLS instance, then multicast traffic from that source MUST be sent
   to all PIM routers on the VPLS instance in addition to the IGMP
   receivers in the VPLS.  If there is already (S,G) or (*,G) snooping
   state that is formed on any PE, this will not happen per the current
   forwarding rules and guidelines.  So, in order to determine if
   traffic needs to be flooded to all routers, a PE must be able to
   determine if the traffic came from a host on that LAN.  There are
   three ways to address this problem:

   o  The PE would have to do IPv4 ARP snooping and/or IPv6 Neighbor
      Discovery snooping, snooping to determine if a source is directly connected.

   o  Another option is to have configuration on configure all PEs to say indicate that there are
      CE sources that are directly connected to the VPLS instance and
      disallow snooping for the groups for which the source is going to
      send traffic.  This way way, traffic from that source to those groups
      will always be flooded within the provider network.

   o  A third option is to require that sources of CE multicast traffic
      must be behind a router.

   This document recommends the third option - -- sources of traffic must
   be behind a router.

2.12.  Data Forwarding  Data-Forwarding Rules

   First

   First, we define the rules that are common to PIM-SM and PIM-DM PEs.
   Forwarding rules for each protocol type is are specified in the sub-
   sections.
   subsections below.

   If there is no matching forwarding state, then the PE SHOULD discard
   the packet, i.e., the UserDefinedPortList below (Sections 2.12.1 and
   2.12.2) SHOULD be empty.

   The following general rules MUST be followed when forwarding
   multicast traffic in a VPLS:

   o  Traffic arriving on a port MUST NOT be forwarded back onto the
      same port.

   o  Due to VPLS Split-Horizon split-horizon rules, traffic ingressing on a PW
      MUST NOT be forwarded to any other PW.

2.12.1.  PIM-SM Data Forwarding Data-Forwarding Rules

   Per the rules in RFC 7761 [PIM-SM] and per the additional rules
   specified in this document,

   OutgoingPortList(*,G) = immediate_olist(*,G) (+)
                           UpstreamPorts(*,G) (+)
                           Port(PimDR)

   OutgoingPortList(S,G) = inherited_olist(S,G) (+)
                           UpstreamPorts(S,G) (+)
                           (UpstreamPorts(*,G) (-)
                           UpstreamPorts(S,G,rpt)) (+)
                           Port(PimDR)

   RFC 7761 [PIM-SM] specifies how immediate_olist(*,G) and
   inherited_olist(S,G) are built.  PimDR is the IP address of the
   PIM DR in the VPLS.

   The PIM-SM snooping forwarding data-forwarding rules are defined below in
   pseudocode:

   BEGIN
       iif is the incoming port of the multicast packet.
       S is the Source source IP Address address of the multicast packet.
       G is the Destination destination IP Address address of the multicast packet.

       If there is (S,G) state on the PE
       Then
           OutgoingPortList = OutgoingPortList(S,G)
       Else if there is (*,G) state on the PE
       Then
           OutgoingPortList = OutgoingPortList(*,G)
       Else
           OutgoingPortList = UserDefinedPortList
       Endif

       If iif is an AC
       Then
           OutgoingPortList = OutgoingPortList (-) iif
       Else
           ## iif is a PW
           OutgoingPortList = OutgoingPortList (-) PWPorts
       Endif

       Forward the packet to OutgoingPortList.
   END

   First
   First, if there is (S,G) state on the PE, then the set of outgoing
   ports is OutgoingPortList(S,G).

   Otherwise

   Otherwise, if there is (*,G) state on the PE, then the set of
   outgoing ports is OutgoingPortList(*,G).

   The packet is forwarded to the selected set of outgoing ports while
   observing the general rules above in Section 2.12 2.12.

2.12.2.  PIM-DM Data Forwarding Data-Forwarding Rules

   The PIM-DM snooping data forwarding data-forwarding rules are defined below in
   pseudocode:

   BEGIN
       iif is the incoming port of the multicast packet.
       S is the Source source IP Address address of the multicast packet.
       G is the Destination destination IP Address address of the multicast packet.

       If there is (S,G) state on the PE
       Then
           OutgoingPortList = olist(S,G)
       Else
           OutgoingPortList = UserDefinedPortList
       Endif

       If iif is an AC
       Then
           OutgoingPortList = OutgoingPortList (-) iif
       Else
           ## iif is a PW
           OutgoingPortList = OutgoingPortList (-) PWPorts
       Endif

       Forward the packet to OutgoingPortList.
   END

   If there is forwarding state for (S,G), then forward the packet to
   olist(S,G) while observing the general rules above in section Section 2.12 2.12.

   RFC 3973 [PIM-DM] specifies how olist(S,G) is constructed.

3.  IANA Considerations

   This document makes no request of IANA.

   Note to RFC Editor: this section may be removed on publication as an
   RFC. does not require any IANA actions.

4.  Security Considerations

   Security considerations provided in the VPLS solution documents
   (i.e., RFC 4762 [VPLS-LDP] and RFC 4761 [VPLS-BGP]) apply to this
   document as well.

7.

5.  References

7.1.

5.1.  Normative References

   [BIDIR-PIM]
              Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,
              "Bidirectional Protocol Independent Multicast (BIDIR-
              PIM)",
              (BIDIR-PIM)", RFC 5015, 2007. DOI 10.17487/RFC5015,
              October 2007, <https://www.rfc-editor.org/info/rfc5015>.

   [JOIN-ATTR]
              Boers, A., Wijnands, I., and E. Rosen, "The Protocol
              Independent Multicast (PIM) Join Attribute Format",
              RFC 5384, 2008. DOI 10.17487/RFC5384, November 2008,
              <https://www.rfc-editor.org/info/rfc5384>.

   [PIM-DM]   Adams, A., Nicholas, J., and W. Siadak, "Protocol
              Independent Multicast Version 2 - Dense Mode
              Specification", (PIM-DM): Protocol
              Specification (Revised)", RFC 3973, 2005. DOI 10.17487/RFC3973,
              January 2005, <https://www.rfc-editor.org/info/rfc3973>.

   [PIM-SM]   Fenner, B., Handley, M., Holbrook, H., Kouvelas, I.,
              Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent
              Multicast-
              Multicast - Sparse Mode (PIM-SM): Protocol Specification
              (Revised)", STD 83, RFC 7761, 2016. DOI 10.17487/RFC7761,
              March 2016, <https://www.rfc-editor.org/info/rfc7761>.

   [PIM-SSM]  Holbrook, H. and B. Cain, "Source-Specific Multicast for
              IP", RFC 4607, 2006. DOI 10.17487/RFC4607, August 2006,
              <https://www.rfc-editor.org/info/rfc4607>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, 1997.
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in
              RFC 2119 Key Words", BCP 14, RFC 8174,
              DOI 10.17487/RFC8174, May 2017,
              <https://www.rfc-editor.org/info/rfc8174>.

   [RPF-VECTOR]
              Wijnands, I., IJ., Boers, A., and E. Rosen, "The Reverse Path
              Forwarding (RPF) Vector TLV", RFC 5496, 2009.

7.2.
              DOI 10.17487/RFC5496, March 2009,
              <https://www.rfc-editor.org/info/rfc5496>.

5.2.  Informative References

   [IGMP-SNOOP]
              Christensen, M., Kimball, K., and F. Solensky,
              "Considerations for IGMP Internet Group Management Protocol
              (IGMP) and MLD snooping PEs", Multicast Listener Discovery (MLD) Snooping
              Switches", RFC 4541,
              2006. DOI 10.17487/RFC4541, May 2006,
              <https://www.rfc-editor.org/info/rfc4541>.

   [VPLS-BGP]
              Kompella, K. K., Ed., and Y. Rekhter, Ed., "Virtual Private
              LAN Service
              using (VPLS) Using BGP for Auto-Discovery and
              Signaling", RFC 4761,
              2007. DOI 10.17487/RFC4761, January 2007,
              <https://www.rfc-editor.org/info/rfc4761>.

   [VPLS-LDP]
              Lasserre, M. M., Ed., and V. Kompella, Ed., "Virtual Private
              LAN
              Services using LDP Service (VPLS) Using Label Distribution Protocol (LDP)
              Signaling", RFC 4762, 2007. DOI 10.17487/RFC4762, January 2007,
              <https://www.rfc-editor.org/info/rfc4762>.

   [VPLS-MCAST]
              Aggarwal, R., Ed., Kamite, Y., Fang, L., and Y. Rekhter, Y., and
              C. Kodeboniya, "Multicast in Virtual Private LAN Servoce Service
              (VPLS)", RFC 7117, 2014. DOI 10.17487/RFC7117, February 2014,
              <https://www.rfc-editor.org/info/rfc7117>.

   [VPLS-MCAST-REQ]
              Kamite, Y., Ed., Wada, Y., Serbest, Y., Morin, T., and L.
              Fang, "Requirements for Multicast Support in Virtual
              Private LAN Services", RFC 5501, 2009. DOI 10.17487/RFC5501,
              March 2009, <https://www.rfc-editor.org/info/rfc5501>.

Appendix A.  BIDIR-PIM Considerations

   This section appendix describes some guidelines that may be used to preserve
   BIDIR-PIM functionality in combination with PIM snooping.

   In order to preserve BIDIR-PIM PIM snooping snooping, routers need to set up
   forwarding states so that : that:

   o  on the RPL RPL, all traffic is forwarded to all Port(N) ports.

   o  on any other interface interface, traffic is always forwarded to the DF DF.

   The information needed to setup set up these states may be obtained by : by:

   o  determining the mapping between group(range) the group (range) and RP the RP.

   o  snooping and storing DF election information information.

   o  determining where the RPL is, this is.  This could be achieved by static
      configuration,
      configuration or by combining the information mentioned in
      previous bullets. the two
      bullet items above.

A.1.  BIDIR-PIM Data Forwarding Data-Forwarding Rules

   The BIDIR-PIM snooping forwarding data-forwarding rules are defined below in
   pseudocode:

   BEGIN
       iif is the incoming port of the multicast packet.
       G is the Destination destination IP Address address of the multicast packet.

       If there is forwarding state for G
       Then
           OutgoingPortList = olist(G)
       Else
           OutgoingPortList = UserDefinedPortList
       Endif

       If iif is an AC
       Then
           OutgoingPortList = OutgoingPortList (-) iif
       Else
           ## iif is a PW
           OutgoingPortList = OutgoingPortList (-) PWPorts
       Endif

       Forward the packet to OutgoingPortList.
   END
   If there is forwarding state for G, then forward the packet to
   olist(G) while observing the general rules above in Section 2.12 2.12.

   RFC 5015 [BIDIR-PIM] specifies how olist(G) is constructed.

Appendix B.  Example Network Scenario

   Let us consider the scenario in Figure 3.

   Figure 3: An Example Network for Triggering Assert

                                            +------+ AC3 +------+
                                            |  PE2 |-----| CE3  |
                                           /|      |     +------+
                                          / +------+         |
                                         /     |             |
                                        /      |             |
                                       /PW12   |             |
                                      /        |           /---\
                                     /         |PW23       | S |
                                    /          |           \---/
                                   /           |             |
                                  /            |             |
                                 /             |             |
                       +------+ /           +------+         |
          +------+     |  PE1 |/   PW13     |  PE3 |     +------+
          | CE1  |-----|      |-------------|      |-----| CE4  |
          +------+ AC1 +------+             +------+ AC4 +------+
                           |
                           |AC2
                       +------+
                       | CE2  |
                       +------+

           Figure 3: An Example Network for Triggering an Assert

   In the examples below, JT(Port,S,G,N) is the downstream Join Expiry
   Timer on the specified Port for the (S,G) with upstream neighbor N.

B.1.  PIM Snooping Example

   In the network depicted in Figure 3, S is the source of a multicast
   stream (S,G).  CE1 and CE2 both have two ECMP routes to reach the
   source.

   1.  CE1 Sends sends a Join(S,G) with Upstream Neighbor(S,G) UpstreamNeighbors(S,G) = CE3.

   2.  PE1 snoops on the Join(S,G) and builds forwarding states state, since it
       is received on an AC.  It also floods the Join(S,G) in the VPLS.
       PE2 snoops on the Join(S,G) and builds forwarding state state, since
       the Join(S,G)is targeting a neighbor residing on an AC.  PE3
       does not create forwarding state for (S,G) because this is a
       PW-only join Join and there is neither an existing (*,G) state with an
       AC in UpstreamPorts(*,G) nor an existing (S,G) state with an AC
       in UpstreamPorts(S,G).  Both PE2 and PE3 will also flood the
       Join(S,G) in the VPLS VPLS.

       The resulting states at the PEs is are as follows:

        At PE1:

       PE1 states:
          JT(AC1,S,G,CE3)        = JP_HoldTime
          UpstreamNeighbors(S,G) = { CE3 }
          UpstreamPorts(S,G)     = { PW12 }
          OutgoingPortList(S,G)  = { AC1, PW12 }

          At PE2:

       PE2 states:
          JT(PW12,S,G,CE3)       = JP_HoldTime
          UpstreamNeighbors(S,G) = { CE3 }
          UpstreamPorts(S,G)     = { AC3 }
          OutgoingPortList(S,G)  = { PW12, AC3 }

          At PE3:

       PE3 states:
          No (S,G) state

   3.  The multicast stream (S,G) flows along CE3 -> PE2 -> PE1 -> CE1 CE1.

   4.  Now CE2 sends a Join(S,G) with Upstream Neighbor(S,G) UpstreamNeighbors(S,G) = CE4.

   5.  All PEs snoop on the Join(S,G), build forwarding state state, and flood
       the Join(S,G) in the VPLS.  Note that for PE2 PE2, even though this
       is a PW-only join, Join, forwarding state is built on this
       Join(S,G) Join(S,G),
       since PE2 has an existing (S,G) state with an AC in
       UpstreamPorts(S,G)
       UpstreamPorts(S,G).

       The resulting states at the PEs:

          At PE1: PEs are as follows:

       PE1 states:
          JT(AC1,S,G,CE3)        = active
          JT(AC2,S,G,CE4)        = JP_HoldTime
          UpstreamNeighbors(S,G) = { CE3, CE4 }
          UpstreamPorts(S,G)     = { PW12, PW13 }
          OutgoingPortList(S,G)  = { AC1, PW12, AC2, PW13 }

          At PE2:
       PE2 states:
          JT(PW12,S,G,CE4)       = JP_HoldTime
          JT(PW12,S,G,CE3)       = active
          UpstreamNeighbors(S,G) = { CE3, CE4 }
          UpstreamPorts(S,G)     = { AC3, PW23 }
          OutgoingPortList(S,G)  = { PW12, AC3, PW23 }

          At PE3:

       PE3 states:
          JT(PW13,S,G,CE4)       = JP_HoldTime
          UpstreamNeighbors(S,G) = { CE4 }
          UpstreamPorts(S,G)     = { AC4 }
          OutgoingPortList(S,G)  = { PW13, AC4 }

   6.  The multicast stream (S,G) flows into the VPLS from the two of the
       CEs -- CE3 and CE4.  PE2 forwards the stream received from CE3 to PW23
       PW23, and PE3 forwards the stream to AC4.  This facilitates helps the CE
       routers to trigger assert Assert election.  Let us say that CE3 becomes
       the
       assert Assert winner.

   7.  CE3 sends an Assert message to the VPLS.  The PEs flood the
       Assert message without examining it.

   8.  CE4 stops sending the multicast stream to the VPLS.

   9.  CE2 notices an RPF change due to the Assert and sends a
       Prune(S,G) with Upstream Neighbor upstream neighbor = CE4.  CE2 also sends a
       Join(S,G) with
       Upstream Neighbor upstream neighbor = CE3.

   10. All the PEs start a prune-pend Prune-Pending timer on the ports on which
       they received the Prune(S,G).  When the prune-pend Prune-Pending timer
       expires, all PEs will remove the downstream (S,G,CE4) states.

       Resulting

       The resulting states at the PEs:

          At PE1: PEs are as follows:

       PE1 states:
          JT(AC1,S,G,CE3)        = active
          UpstreamNeighbors(S,G) = { CE3 }
          UpstreamPorts(S,G)     = { PW12 }
          OutgoingPortList(S,G)  = { AC1, AC2, PW12 }

          At PE2:

       PE2 states:
          JT(PW12,S,G,CE3)       = active
          UpstreamNeighbors(S,G) = { CE3 }
          UpstreamPorts(S,G)     = { AC3 }
          OutgoingPortList(S,G)  = { PW12, AC3 }

          At PE3:
       PE3 states:
          JT(PW13,S,G,CE3)       = JP_HoldTime
          UpstreamNeighbors(S,G) = { CE3 }
          UpstreamPorts(S,G)     = { PW23 }
          OutgoingPortList(S,G)  = { PW13, PW23 }

       Note that at this point at PE3, since there is no AC in
       OutgoingPortList(S,G) and no (*,G) or (S,G) state with an AC in
       UpstreamPorts(*,G) or UpstreamPorts(S,G) UpstreamPorts(S,G), respectively, the
       existing (S,G) state at PE3 can also be removed. So  So, finally:

          At PE3:

       PE3 states:
          No (S,G) state

   Note that at the end of the assert Assert election, there should be no
   duplicate traffic forwarded downstream downstream, and traffic should flow only
   on the desired path.  Also note that there are no unnecessary (S,G)
   states on PE3 after the assert Assert election.

B.2.  PIM Proxy Example with (S,G) / (*,G) interaction Interaction

   In the same network, let us assume that CE4 is the Upstream Neighbor upstream neighbor
   towards the RP for G.

   JPST(S,G,N) is the JP sending timer for the (S,G) with upstream
   neighbor N.

   1.  CE1 Sends sends a Join(S,G) with Upstream Neighbor(S,G) UpstreamNeighbors(S,G) = CE3.

   2.  PE1 consumes the Join(S,G) and builds forwarding state state, since the
       Join(S,G) is received on an AC.

       PE2 consumes the Join(S,G) and builds forwarding state state, since the
       Join(S,G) is targeting a neighbor residing on an AC.

       PE3 consumes the Join(S,G) but does not create forwarding state
       for (S,G) (S,G), since this is a PW-only join Join and there is neither an
       existing (*,G) state with an AC in UpstreamPorts(*,G) nor an
       existing (S,G) state with an AC in UpstreamPorts(S,G) UpstreamPorts(S,G).

       The resulting states at the PEs is are as follows:

       PE1 states:
          JT(AC1,S,G,CE3)        = JP_HoldTime
          JPST(S,G,CE3)          = t_periodic
          UpstreamNeighbors(S,G) = { CE3 }
          UpstreamPorts(S,G)     = { PW12 }
          OutgoingPortList(S,G)  = { AC1, PW12 }

       PE2 states:
          JT(PW12,S,G,CE3)       = JP_HoldTime
          JPST(S,G,CE3)          = t_periodic
          UpstreamNeighbors(S,G) = { CE3 }
          UpstreamPorts(S,G)     = { AC3 }
          OutgoingPortList(S,G)  = { PW12, AC3 }

       PE3 states:
          No (S,G) state

       Joins are triggered as follows:
       PE1 triggers a Join(S,G) targeting CE3.  Since the Join(S,G) was
       received on an AC and is targeting a neighbor that is residing
       across a PW, the triggered Join(S,G) is sent on all PWs.

       PE2 triggers a Join(S,G) targeting CE3.  Since the Joins(S,G) Join(S,G) is
       targeting a neighbor residing on an AC, it only sends the join Join
       on AC3.

       PE3 ignores the Join(S,G) Join(S,G), since this is a PW-only join Join and there
       is neither an existing (*,G) state with an AC in
       UpstreamPorts(*,G) nor an existing (S,G) state with an AC in UpstreamPorts(S,G)
       UpstreamPorts(S,G).

   3.  The multicast stream (S,G) flows along CE3 -> PE2 -> PE1 -> CE1.

   4.  Now let us say that CE2 sends a Join(*,G) with
       UpstreamNeighbor(*,G)
       UpstreamNeighbors(*,G) = CE4.

   5.  PE1 consumes the Join(*,G) and builds forwarding state state, since the
       Join(*,G) is received on an AC.

       PE2 consumes the Join(*,G) and though Join(*,G); although this is a PW-only join, Join,
       forwarding state is build built on this Join(*,G) Join(*,G), since PE2 has an
       existing (S,G) state with an AC in UpstreamPorts(S,G).  However,
       since this is a PW-only join, Join, PE2 only adds the PW towards PE3
       (PW23) into UpstreamPorts(*,G) and hence into
       OutgoingPortList(*,G).  It does not add the PW towards PE1 (PW12)
       into OutgoingPortsList(*,G) OutgoingPortList(*,G).

       PE3 consumes the Join(*,G) and builds forwarding state state, since the
       Join(*,G) is targeting a neighbor residing on an AC.

       The resulting states at the PEs is are as follows:

       PE1 states:
          JT(AC1,*,G,CE4)        = JP_HoldTime
          JPST(*,G,CE4)          = t_periodic
          UpstreamNeighbors(*,G) = { CE4 }
          UpstreamPorts(*,G)     = { PW13 }
          OutgoingPortList(*,G)  = { AC2, PW13 }

          JT(AC1,S,G,CE3)        = active
          JPST(S,G,CE3)          = active
          UpstreamNeighbors(S,G) = { CE3 }
          UpstreamPorts(S,G)     = { PW12 }
          OutgoingPortList(S,G)  = { AC1, PW12, PW13 }

       PE2 states:
          JT(PW12,*,G,CE4)       = JP_HoldTime
          UpstreamNeighbors(*,G) = { CE4 }
          UpstreamPorts(G)       = { PW23 }
          OutgoingPortList(*,G)  = { PW23 }

          JT(PW12,S,G,CE3)       = active
          JPST(S,G,CE3)          = active
          UpstreamNeighbors(S,G) = { CE3 }
          UpstreamPorts(S,G)     = { AC3 }
          OutgoingPortList(S,G)  = { PW12, AC3, PW23 }

       PE3 states:
          JT(PW13,*,G,CE4)       = JP_HoldTime
          JPST(*,G,CE4)          = t_periodic
          UpstreamNeighbors(*,G) = { CE4 }
          UpstreamPorts(*,G)     = { AC4 }
          OutgoingPortList(*,G)  = { PW13, AC4 }

       Joins are triggered as follows:
       PE1 triggers a Join(*,G) targeting CE4.  Since the Join(*,G) was
       received on an AC and is targeting a neighbor that is residing
       across a PW, the triggered Join(S,G) is sent on all PWs.

       PE2 does not trigger a Join(*,G) based on this join Join, since this
       is a PW-only join. Join.

       PE3 triggers a Join(*,G) targeting CE4.  Since the Join(*,G) is
       targeting a neighbor residing on an AC, it only sends the join Join
       on AC4.

   6. In case  If traffic is not flowing yet (i.e. (i.e., step 3 is delayed to
       come so that it
       occurs after step 6) and in the interim JPST(S,G,CE3) on PE1
       expires, causing it to send a refresh Join(S,G) targeting CE3,
       since the refresh Join(S,G) is targeting a neighbor that is
       residing across a PW, the refresh Join(S,G) is sent on all PWs.

   7.  Note that PE1 refreshes its JT timer based on reception of refresh joins
       Joins from CE1 and CE2 CE2.

       PE2 consumes the Join(S,G) and refreshes the JT(PW12,S,G,CE3)
       timer.

       PE3 consumes the Join(S,G).  It also builds forwarding state on
       this Join(S,G), even though this is a PW-only join, Join, since now PE2
       has an existing (*,G) state with an AC in UpstreamPorts(*,G).
       However, since this is a PW-only join, Join, PE3 only adds the PW
       towards PE2 (PW23) into UpstreamPorts(S,G) and hence into
       OutgoingPortList(S,G).  It does not add the PW towards PE1 (PW13)
       into OutgoingPortList(S,G).

       PE3 States: states:
          JT(PW13,*,G,CE4)       = active
          JPST(S,G,CE4)          = active
          UpstreamNeighbors(*,G) = { CE4 }
          UpstreamPorts(*,G)     = { AC4 }
          OutgoingPortList(*,G)  = { PW13, AC4 }

          JT(PW13,S,G,CE3)       = JP_HoldTime
          UpstreamNeighbors(*,G) = { CE3 }
          UpstreamPorts(*,G)     = { PW23 }
          OutgoingPortList(*,G)  = { PW13, AC4, PW23 }

       Joins are triggered as follows:
       PE2 already has (S,G) state, so it does not trigger a Join(S,G)
       based on reception of this refresh join. Join.

       PE3 does not trigger a Join(S,G) based on this join Join, since this
       is a PW-only join. Join.

   8.  The multicast stream (S,G) flows into the VPLS from the two
       CEs, of the
       CEs -- CE3 and CE4.  PE2 forwards the stream received from CE3 to
       PW12 and PW23.  At the same time time, PE3 forwards the stream
       received from CE4 to PW13 and PW23.

       The stream received over PW12 and PW13 is forwarded by PE1 to AC1
       and AC2.

       The stream received by PE3 over PW23 is forwarded to AC4.  The
       stream received by PE2 over PW23 is forwarded to AC3.  Either of
       these facilitates helps the CE routers to trigger assert Assert election.

   9.  CE3 and/or CE4 send(s) Assert message(s) to the VPLS.  The PEs
       flood the Assert message(s) without examining it.

   10. CE3 becomes the (S,G) assert winner Assert winner, and CE4 stops sending the
       multicast stream to the VPLS.

   11. CE2 notices an RPF change due to the Assert and sends a
       Prune(S,G,rpt) with Upstream Neighbor upstream neighbor = CE4.

   12. PE1 consumes the Prune(S,G,rpt) Prune(S,G,rpt), and since
       PruneDesired(S,G,Rpt,CE4) is TRUE, it triggers a Prune(S,G,rpt)
       to CE4.  Since the prune Prune is targeting a neighbor across a PW, it
       is sent on all PWs.

       PE2 consumes the Prune(S,G,rpt) and does not trigger any prune Prune
       based on this Prune(S,G,rpt) Prune(S,G,rpt), since this was a PW-only prune. Prune.

       PE3 consumes the Prune(S,G,rpt) Prune(S,G,rpt), and since
       PruneDesired(S,G,rpt,CE4) is TRUE TRUE, it sends the Prune(S,G,rpt)
       on AC4.

       PE1 states:
          JT(AC2,*,G,CE4)        = active
          JPST(*,G,CE4)          = active
          UpstreamNeighbors(*,G) = { CE4 }
          UpstreamPorts(*,G)     = { PW13 }
          OutgoingPortList(*,G)  = { AC2, PW13 }

          JT(AC2,S,G,CE4)        = JP_Holdtime JP_HoldTime with FLAG sgrpt S,G,rpt prune flag
          JPST(S,G,CE4)          = none, since this is sent along
                                   with the Join(*,G) to CE4 based
                                   on JPST(*,G,CE4) expiry
          UpstreamPorts(S,G,rpt) = { PW13 }
          UpstreamNeighbors(S,G,rpt) = { CE4 }

          JT(AC1,S,G,CE3)        = active
          JPST(S,G,CE3)          = active
          UpstreamNeighbors(S,G) = { CE3 }
          UpstreamPorts(S,G)     = { PW12 }
          OutgoingPortList(S,G)  = { AC1, PW12, AC2 }

          At PE2:
       PE2 states:
          JT(PW12,*,G,CE4)       = active
          UpstreamNeighbors(*,G) = { CE4 }
          UpstreamPorts(*,G)     = { PW23 }
          OutgoingPortList(*,G)  = { PW23 }

          JT(PW12,S,G,CE4)       = JP_Holdtime JP_HoldTime with FLAG sgrpt S,G,rpt prune flag
          JPST(S,G,CE4)          = none, since this was created
                                   off a PW-only prune Prune
          UpstreamPorts(S,G,rpt) = { PW23 }
          UpstreamNeighbors(S,G,rpt) = { CE4 }

          JT(PW12,S,G,CE3)       = active
          JPST(S,G,CE3)          = active
          UpstreamNeighbors(S,G) = { CE3 }
          UpstreamPorts(S,G)     = { AC3 }
          OutgoingPortList(*,G)  = { PW12, AC3 }

          At PE3:

       PE3 states:
          JT(PW13,*,G,CE4)       = active
          JPST(*,G,CE4)          = active
          UpstreamNeighbors(*,G) = { CE4 }
          UpstreamPorts(*,G)     = { AC4 }
          OutgoingPortList(*,G)  = { PW13, AC4 }

          JT(PW13,S,G,CE4)       = JP_Holdtime JP_HoldTime with S,G,rpt prune flag
          JPST(S,G,CE4)          = none, since this is sent along
                                   with the Join(*,G) to CE4 based
                                   on JPST(*,G,CE4) expiry
          UpstreamNeighbors(S,G,rpt) = { CE4 }
          UpstreamPorts(S,G,rpt) = { AC4 }

          JT(PW13,S,G,CE3)       = active
          JPST(S,G,CE3)          = none, since this state is
                                   created by a PW-only join Join
          UpstreamNeighbors(S,G) = { CE3 }
          UpstreamPorts(S,G)     = { PW23 }
          OutgoingPortList(S,G)  = { PW23 }

   Even in this example, at the end of the (S,G) / (*,G) assert Assert
   election, there should be no duplicate traffic forwarded downstream downstream,
   and traffic should flow only to the desired CEs.

   However, the reason we don't have duplicate traffic is because one of the CEs stops
   sending traffic due to assert, the Assert, not because we don't have any
   forwarding state in the PEs to do this forwarding.

6.

Acknowledgements

   Many members of the former L2VPN and PIM working groups have
   contributed to to, and provided valuable comments and feedback to on, this
   document, including Vach Kompella, Shane Amante, Sunil Khandekar, Rob
   Nath, Marc Lassere, Lasserre, Yuji Kamite, Yiqun Cai, Ali Sajassi, Jozef
   Raets, Himanshu Shah (Ciena), and Himanshu Shah (Alcatel-Lucent).

5. (Cisco).

Contributors

   Yetik Serbest, Serbest and Suresh Boddapati co-authored coauthored earlier versions. draft versions
   of this document.

   Karl (Xiangrong) Cai and Princy Elizabeth made significant
   contributions to bring the specification to its current state,
   especially in the area of Join forwarding rules.

Authors' Addresses

   Olivier Dornon
   Nokia
   50
   Copernicuslaan
   Antwerp, B2018 50
   B-2018  Antwerp
   Belgium

   Email: olivier.dornon@nokia.com

   Jayant Kotalwar
   Nokia
   701 East Middlefield Rd.
   Mountain View, CA  94043
   United States of America

   Email: jayant.kotalwar@nokia.com

   Venu Hemige
   Nokia

   Email: vhemige@gmail.com

   Ray Qiu
   mistnet.io

   Email: ray@mistnet.io

   Jeffrey Zhang
   Juniper Networks, Inc.
   10 Technology Park Drive
   Westford, MA  01886
   United States of America

   Email: zzhang@juniper.net