From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc8220.txt | 2411 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 2411 insertions(+) create mode 100644 doc/rfc/rfc8220.txt (limited to 'doc/rfc/rfc8220.txt') diff --git a/doc/rfc/rfc8220.txt b/doc/rfc/rfc8220.txt new file mode 100644 index 0000000..033a40d --- /dev/null +++ b/doc/rfc/rfc8220.txt @@ -0,0 +1,2411 @@ + + + + + + +Internet Engineering Task Force (IETF) O. Dornon +Request for Comments: 8220 J. Kotalwar +Category: Informational V. Hemige +ISSN: 2070-1721 Nokia + R. Qiu + mistnet.io + Z. Zhang + Juniper Networks, Inc. + September 2017 + + + Protocol Independent Multicast (PIM) + over Virtual Private LAN Service (VPLS) + +Abstract + + This document describes the procedures and recommendations for + Virtual Private LAN Service (VPLS) Provider Edges (PEs) to facilitate + replication of multicast traffic to only certain ports (behind which + there are interested Protocol Independent Multicast (PIM) routers + and/or Internet Group Management Protocol (IGMP) hosts) via PIM + snooping and proxying. + + With PIM snooping, PEs passively listen to certain PIM control + messages to build control and forwarding states while transparently + flooding those messages. With PIM proxying, PEs do not flood PIM + Join/Prune messages but only generate their own and send them out of + certain ports, based on the control states built from downstream + Join/Prune messages. PIM proxying is required when PIM Join + suppression is enabled on the Customer Edge (CE) devices and is + useful for reducing PIM control traffic in a VPLS domain. + + This document also describes PIM relay, which can be viewed as + lightweight proxying, where all downstream Join/Prune messages are + simply forwarded out of certain ports and are not flooded, thereby + avoiding the triggering of PIM Join suppression on CE devices. + + + + + + + + + + + + + + + +Dornon, et al. Informational [Page 1] + +RFC 8220 PIM Snooping September 2017 + + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of 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 candidate for any level of Internet + Standard; see Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + 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 + (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 ....................................................4 + 1.1. Multicast Snooping in VPLS .................................5 + 1.2. Assumptions ................................................6 + 1.3. Definitions ................................................6 + 1.4. Requirements Language ......................................7 + 2. PIM Snooping for VPLS ...........................................7 + 2.1. PIM Protocol Background ....................................7 + 2.2. General Rules for PIM Snooping in VPLS .....................8 + 2.2.1. Preserving Assert Triggers ..........................8 + 2.3. Some Considerations for PIM Snooping .......................9 + 2.3.1. Scaling .............................................9 + 2.3.2. IPv4 and IPv6 ......................................10 + 2.3.3. PIM-SM (*,*,RP) ....................................10 + + + + + +Dornon, et al. Informational [Page 2] + +RFC 8220 PIM Snooping September 2017 + + + 2.4. PIM Snooping vs. PIM Proxying .............................10 + 2.4.1. Differences between PIM Snooping, Relay, + and Proxying .......................................10 + 2.4.2. PIM Control Message Latency ........................11 + 2.4.3. When to Snoop and When to Proxy ....................12 + 2.5. Discovering PIM Routers ...................................13 + 2.6. PIM-SM and PIM-SSM ........................................14 + 2.6.1. Building PIM-SM States .............................15 + 2.6.2. Explanation for Per-(S,G,N) States .................17 + 2.6.3. Receiving (*,G) PIM-SM Join/Prune Messages .........18 + 2.6.4. Receiving (S,G) PIM-SM Join/Prune Messages .........20 + 2.6.5. Receiving (S,G,rpt) Join/Prune Messages ............22 + 2.6.6. Sending Join/Prune Messages Upstream ...............23 + 2.7. Bidirectional PIM (BIDIR-PIM) .............................24 + 2.8. Interaction with IGMP Snooping ............................24 + 2.9. PIM-DM ....................................................25 + 2.9.1. Building PIM-DM States .............................25 + 2.9.2. PIM-DM Downstream Per-Port PIM(S,G,N) State + Machine ............................................25 + 2.9.3. Triggering Assert Election in PIM-DM ...............26 + 2.10. PIM Proxy ................................................26 + 2.10.1. Upstream PIM Proxy Behavior .......................26 + 2.11. Directly Connected Multicast Source ......................26 + 2.12. Data-Forwarding Rules ....................................27 + 2.12.1. PIM-SM Data-Forwarding Rules ......................28 + 2.12.2. PIM-DM Data-Forwarding Rules ......................29 + 3. IANA Considerations ............................................29 + 4. Security Considerations ........................................30 + 5. References .....................................................30 + 5.1. Normative References ......................................30 + 5.2. Informative References ....................................31 + Appendix A. BIDIR-PIM Considerations ..............................32 + A.1. BIDIR-PIM Data-Forwarding Rules ............................32 + Appendix B. Example Network Scenario ..............................33 + B.1. PIM Snooping Example .......................................33 + B.2. PIM Proxy Example with (S,G) / (*,G) Interaction ...........36 + Acknowledgements ..................................................42 + Contributors ......................................................42 + Authors' Addresses ................................................43 + + + + + + + + + + + + +Dornon, et al. Informational [Page 3] + +RFC 8220 PIM Snooping September 2017 + + +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 Media Access Control (MAC) + address learning. Once a unicast MAC address is learned and + associated with a particular Attachment Circuit (AC) or 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, Unknown Unicast, and Multicast) traffic: + + o B: The destination MAC address is a broadcast address. + + o U: The destination MAC address is unknown (has not been 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 + (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 5501 [VPLS-MCAST-REQ]), there + are two issues with VPLS multicast today: + + 1. Multicast traffic is replicated to non-member sites. + + 2. Multicast traffic may be replicated when several PWs share a + physical path. + + Issue 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 2 is outside the + scope of this document and is discussed in RFC 7117 [VPLS-MCAST]. + + While descriptions in this document are in the context of the VPLS, + the procedures also apply to regular Layer 2 switches interconnected + by physical connections, except that the PW-related concepts and + procedures do not apply in that case. + + + + + + +Dornon, et al. Informational [Page 4] + +RFC 8220 PIM Snooping September 2017 + + +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 ACs connecting to hosts that report related group membership + + o ACs connecting to routers that join related multicast groups + + o PWs connecting to remote PEs that have the above-described ACs + + 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 cannot + determine if there are interested receivers beyond those 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 rules for when both IGMP and + PIM snooping are enabled in a VPLS instance; see Sections 2.8 and + 2.11 for details. + + Note that for both IGMP and PIM, the term "snooping" is used loosely, + referring to the fact that a Layer 2 device peeks into 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" or "proxying" in different contexts. + + We will use the term "PIM snooping" in this document; however, unless + explicitly noted otherwise, the procedures apply equally to PIM + snooping and PIM proxying. The procedures specific to PIM proxying + 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 2.4. + + This document also describes PIM relay, which can be viewed as + lightweight PIM proxying. Unless explicitly noted otherwise, in the + rest of this document proxying implicitly includes relay as well. + Please refer to Section 2.4.1 for an overview of the differences + between snooping, proxying, and relay. + + + + + + + + + + +Dornon, et al. Informational [Page 5] + +RFC 8220 PIM Snooping September 2017 + + +1.2. Assumptions + + This document assumes that the reader has a good understanding of the + PIM protocols. 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: + + 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 corresponding + definitions and procedures in 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: RFC 3973 [PIM-DM], RFC 5015 + [BIDIR-PIM], and RFC 7761 [PIM-SM]. The following definitions and + abbreviations are used throughout this document: + + o A port is defined as either an AC or a 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 this document: + + o S: IP address of the multicast source. + + o G: IP address of the multicast group. + + o N: Upstream Neighbor field in a Join/Prune/Graft message. + + o Port(N): Port on which neighbor N is learned, i.e., the port on + which N's Hellos are received. + + o rpt: Rendezvous Point Tree. + + + + +Dornon, et al. Informational [Page 6] + +RFC 8220 PIM Snooping September 2017 + + + o PIM-DM: Protocol Independent Multicast - Dense Mode. + + o PIM-SM: Protocol Independent Multicast - Sparse Mode. + + o PIM-SSM: Protocol Independent Multicast - 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 + 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 + + 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 information for building multicast trees. There + are a few variants of PIM. 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 instead of the 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). + + + + + + + + + + + + +Dornon, et al. Informational [Page 7] + +RFC 8220 PIM Snooping September 2017 + + +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 + protocols or 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 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 Triggers + + In 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 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, but each copy may reach a + different set of PEs; this is acceptable from the point of view of + avoiding duplicate traffic. If the two copies may reach the same 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 / PIM-SM snooping MUST forward + multicast traffic for an (S,G) / (*,G) not only on the ports on which + they snooped Join(S,G) / Join(*,G) but also towards the upstream + neighbor(s). In other words, the ports on which the upstream + neighbors are learned must be added to the outgoing port 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 can be + triggered (Section 2.9.3). + + + + + + + +Dornon, et al. Informational [Page 8] + +RFC 8220 PIM Snooping September 2017 + + + The above logic needs to be facilitated without breaking VPLS + 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 routing. It knows how to forward Join/Prune messages + only by looking at the Upstream Neighbor field in the Join/Prune + packets, as described in Section 2.12. + + The PE does not need to know about Rendezvous Points (RPs) and + does not have to maintain any RP Set. All of that is transparent to + a PIM snooping PE. + + In the following 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-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, 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 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. + + + + + + + +Dornon, et al. Informational [Page 9] + +RFC 8220 PIM Snooping September 2017 + + +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 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 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. 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, and Proxying + + Differences between PIM snooping and relay/proxying can be summarized + as follows: + + +--------------------+---------------------+-----------------------+ + | PIM snooping | PIM relay | PIM proxying | + +====================|=====================|=======================+ + | Join/Prune messages| Join/Prune messages | Join/Prune messages | + | snooped and flooded| snooped; forwarded | consumed. 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 | messages generated | + +--------------------+---------------------+-----------------------+ + | CE Join suppression| CE Join suppression | CE Join suppression | + | not allowed | allowed | allowed | + +--------------------+---------------------+-----------------------+ + + + + +Dornon, et al. Informational [Page 10] + +RFC 8220 PIM Snooping September 2017 + + + 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, they truly provide transparent LAN + services, since no customer packets are modified or consumed nor are + new packets introduced in the VPLS. It is also simpler to implement + than PIM proxying. 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 + can be very easily provided without requiring any changes on the CE + routers. PIM relay/proxying helps scale VPLS multicast, since + Join/Prune messages are only sent to certain upstream ports instead + of flooded, and in cases of full proxying (vs. relay), the PEs + intelligently generate only one Join/Prune message for a given + multicast stream. + + PIM proxying, however, loses the transparency argument, since + 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, 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, there is no + latency introduced by the VPLS in the delivery of PIM Hello packets + to remote CEs in the VPLS. + + + + + +Dornon, et al. Informational [Page 11] + +RFC 8220 PIM Snooping September 2017 + + + 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's behavior very similar to that of a PIM router, without + introducing too much additional complexity. It keeps the PIM + proxying solution fairly simple. Since Join/Prune messages are + forwarded by a PE along the slow path and all other PIM packet types + are forwarded along the fast path, it is very likely that packets + forwarded along the 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/Prune packets). Of particular + importance are Hello packets sent along the fast path. We can + construct a variety of scenarios resulting in 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 or not + + o Whether Join/Prune latency is critical or not + + o Whether the scale of PIM protocol messages/states in a VPLS + requires the scaling benefit of proxying + + Of the above factors, Join suppression is the hard one -- pure + snooping can only be used when Join 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. + + + + + + +Dornon, et al. Informational [Page 12] + +RFC 8220 PIM Snooping September 2017 + + + A PIM router indicates that Join 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, ET is possible, allowing an + upstream router to track all the downstream neighbors that have Join + states for any (S,G) or (*,G). This has two benefits: + + o No need for the Prune-Pending process -- the upstream router may + immediately stop forwarding data when it receives a Prune from the + last downstream neighbor and immediately prune to its upstream + neighbor. + + o For management purposes, the upstream router knows exactly which + downstream routers exist for a particular Join state. + + While full proxying can be used with or without Join suppression on + CEs and does not interfere with an upstream CE's bypass of the + Prune-Pending process, it does proxy all its downstream CEs as a + single one to the upstream neighbors, removing the second benefit + mentioned above. + + Therefore, the general rule is that if Join suppression is enabled on + one or more CEs, then proxying or relay MUST be used, but if Join + suppression is known to be disabled on all CEs, then snooping, relay, + or proxying MAY be used, while snooping or relay SHOULD be used. + + An implementation MAY choose to dynamically determine which mode to + use, through the tracking of the 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. + 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 sending the PIM Hello. + + o IP address and address family of the router sending the PIM Hello. + + o Port (AC/PW) on which the PIM Hello was received. + + o Hello Option fields. + + + + + +Dornon, et al. Informational [Page 13] + +RFC 8220 PIM Snooping September 2017 + + + The PE should be able to interpret and act on Hello Option fields as + currently defined in RFC 7761 [PIM-SM]. The Option fields of + particular interest in this document are: + + o Hello-Hold-Time + + o Tracking Support + + o Designated Router (DR) Priority + + Please refer to RFC 7761 [PIM-SM] for a list of the Hello 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 DR in the + VPLS instance. It should also be able to determine if 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 + 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. + + + + + + + + + + + + + + + + + + + + +Dornon, et al. Informational [Page 14] + +RFC 8220 PIM Snooping September 2017 + + +2.6.1. Building PIM-SM States + + PIM-SM and PIM-SSM states are built by snooping on the PIM-SM + Join/Prune messages received on 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): + + o DownstreamJPState: One of {"NoInfo" (NI), "Join" (J), + "Prune-Pending" (PP)} + + Per downstream (Port,*,G,N): + + o Prune-Pending Timer (PPT(N)) + + o Join Expiry Timer (ET(N)) + + Per downstream (Port,S,G): + + o DownstreamJPState: One of {"NoInfo" (NI), "Join" (J), + "Prune-Pending" (PP)} + + Per downstream (Port,S,G,N): + + o Prune-Pending Timer (PPT(N)) + + o Join Expiry Timer (ET(N)) + + Per downstream (Port,S,G,rpt): + + o DownstreamJPRptState: One of {"NoInfo" (NI), "Pruned" (P), + "Prune-Pending" (PP)} + + Per downstream (Port,S,G,rpt,N): + + o Prune-Pending Timer (PPT(N)) + + o Join Expiry Timer (ET(N)) + + where S is the address of the multicast source, G is the group + address, and N is the Upstream Neighbor field in the Join/Prune + message. + + + + + + +Dornon, et al. Informational [Page 15] + +RFC 8220 PIM Snooping September 2017 + + + Note that unlike the case of PIM-SM routers, where the PPT and ET are + per (Interface,S,G), PIM snooping PEs have to maintain the PPT and ET + per (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: + + UpstreamNeighbors(*,G): If there are one or more 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 are one or more 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 forwarded + using a (*,G) match MUST be forwarded to these ports. 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, 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 + (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. + + + + + + + + +Dornon, et al. Informational [Page 16] + +RFC 8220 PIM Snooping September 2017 + + + 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 ("Data-Forwarding Rules") for the specification on + how OutgoingPortList is calculated. + + NumETsActive(Port,*,G): 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): 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 5384 [JOIN-ATTR]) are + TLVs that may be present in received Join(*,G) messages. An + example would be Reverse Path Forwarding (RPF) Vectors (RFC 5496 + [RPF-VECTOR]). If present, they must be copied to + JoinAttributeTlvs(*,G). + + JoinAttributeTlvs(S,G): Join Attributes (RFC 5384 [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 and PIM-SM snooping PEs, we specify the + details of the downstream state machine of PIM-SM snooping 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 + + In PIM 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 + fields. This could happen during transient network conditions or due + to dual-homed sources. A PE cannot make assumptions on which one to + pick but instead must allow the CE routers to decide which upstream + + + + +Dornon, et al. Informational [Page 17] + +RFC 8220 PIM Snooping September 2017 + + + neighbor gets elected as the RPF-Neighbor. And for this purpose, + the PE will have to track downstream and upstream 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 is met: + + o The port on which it arrived is not Port(N) where N is the + upstream neighbor N of the Join/Prune(*,G). + + o 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" in this document. The + 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 + 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 are exactly as + specified in RFC 7761 [PIM-SM]. + + + + + + + + + + + + + + + + + + + + + +Dornon, et al. Informational [Page 18] + +RFC 8220 PIM Snooping September 2017 + + + We define the following per-port (*,G,N) macro to help with the state + machine below. + + +---------------++-------------------------------------------------+ + | || Previous State | + | ++-------------+--------------+--------------------+ + | Event || NoInfo (NI) | Join (J) | 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) | + +---------------++-------------+--------------+--------------------+ + |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, + 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, the PE will need to perform conflict resolution per + (N) as described in RFC 5384 [JOIN-ATTR]. + + + + + +Dornon, et al. Informational [Page 19] + +RFC 8220 PIM Snooping September 2017 + + + Action PPTExpiry(N): + + Same as Action ETExpiry(N) below, plus send a Prune-Echo(*,G) with + upstream neighbor N on the downstream port. + + Action ETExpiry(N): + + Disable timers ET(N) and PPT(N). Delete Neighbor state + (Port,*,G,N). If there are no other (Port,*,G) states with + NumETsActive(Port,*,G) > 0, transition DownstreamJPState (RFC 7761 + [PIM-SM]) to NoInfo. If there are no other (Port,*,G,N) states + (different ports but for the same N), remove N from + UpstreamPorts(*,G) -- this will also trigger the Upstream 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 is met: + + o The port on which it arrived is not Port(N) where N is the + upstream neighbor N of the Join/Prune(S,G). + + o 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" in this document. The + 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 + 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. + + + + + + + + + + + + + + + + +Dornon, et al. Informational [Page 20] + +RFC 8220 PIM Snooping September 2017 + + + 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 are exactly as + specified in RFC 7761 [PIM-SM]. + + +---------------++-------------------------------------------------+ + | || Previous State | + | ++-------------+--------------+--------------------+ + | Event || NoInfo (NI) | Join (J) | 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 || | Start PPT(N) | | + |NumETsActive<=1|| | | | + +---------------++-------------+--------------+--------------------+ + |Receive || - | -> J state | - | + |Prune(S,G) and || | Start PPT(N) | | + |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 + + + + + + + + + + + + + + +Dornon, et al. Informational [Page 21] + +RFC 8220 PIM Snooping September 2017 + + + 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 cases of conflicting 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 a Prune-Echo(S,G) with + upstream neighbor N on the downstream port. + + Action ETExpiry(N): + + Disable timers ET(N) and PPT(N). Delete 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) states (different + ports but for the same N), remove N from UpstreamPorts(S,G) -- + this will also trigger the Upstream FSM 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 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) 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 4.5.3 of RFC 7761 [PIM-SM]. + + + + + + + + + + + +Dornon, et al. Informational [Page 22] + +RFC 8220 PIM Snooping September 2017 + + +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 + along the lines of the procedure described in 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) 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 Asserts among the CE routers, such + Join/Prune messages need to send not only towards the upstream + neighbor but also on certain 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 Join/Prune Messages + + The following rules apply to both (1) forwarded (in the case of PIM + relay) and (2) refreshed and triggered (in the case of PIM proxying) + (S,G) / (*,G) Join/Prune messages. + + o The Upstream Neighbor field in the Join/Prune to be sent is set to + the N in the corresponding Upstream FSM. + + o 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. + + + + + + + +Dornon, et al. Informational [Page 23] + +RFC 8220 PIM Snooping September 2017 + + + 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 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 the two routers will receive from each other, + triggering an Assert. + +2.7. Bidirectional PIM (BIDIR-PIM) + + Bidirectional PIM (BIDIR-PIM) is a variation of PIM-SM. The main + differences between PIM-SM and BIDIR-PIM are as follows: + + o There are no source-based trees, and 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 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 + network may forward traffic without exchanging Join/Prune messages -- + for instance, between 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 networks will require some further study. Some + thoughts on this topic are 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, 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 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 (rule 1) listed in Section 2.1.1 of RFC 4541 + [IGMP-SNOOP]. + + + +Dornon, et al. Informational [Page 24] + +RFC 8220 PIM Snooping September 2017 + + + o If the PE supports proxy reporting, an IGMP membership learned + only on a port to which a PIM neighbor is attached (i.e., not + learned elsewhere) SHOULD NOT be included in the summarized + upstream report sent to that port. + +2.9. PIM-DM + + The key characteristic of PIM-DM is flood-and-prune behavior. + 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, + and State Refresh messages received on ACs/PWs and State Refresh + messages sent on 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, and N is the upstream + neighbor to which Prunes/Grafts are sent by downstream CEs: + + Per PIM(S,G,N): + + Port PIM(S,G,N) Prune State: + + * DownstreamPState(S,G,N,Port): One of {"NoInfo" (NI), + "Pruned" (P), "Prune-Pending" (PP)} + + * Prune-Pending Timer (PPT) + + * Prune Timer (PT) + + * Upstream Port (valid if the PIM(S,G,N) Prune state is "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 4.4.2 of RFC 3973 [PIM-DM], with a few changes relevant to + PIM snooping. When reading Section 4.4.2 of RFC 3973 [PIM-DM], + please be aware that, for the purposes of PIM snooping, the + downstream states are built per (S,G,N,Downstream-Port) in PIM + snooping and not per (Downstream-Interface,S,G) as in a PIM-DM + router. As noted in Section 2.9.1, the states (DownstreamPState) and + timers (PPT and PT) are per (S,G,N,Port). + + + + + + + + +Dornon, et al. Informational [Page 25] + +RFC 8220 PIM Snooping September 2017 + + +2.9.3. Triggering 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, the asserting routers should typically be in + pim_oiflist(S,G). In most cases, Assert election should occur + naturally without any special handling, since data traffic will be + forwarded to the asserting routers. + + However, there are some scenarios where a Prune might be received on + a port that is also an upstream 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 upstream ports. + +2.10. PIM Proxy + + As noted earlier, PIM snooping will work correctly only if Join + suppression is disabled in the VPLS. If Join suppression is enabled + in the VPLS, then PEs MUST do PIM relay/proxying for VPLS multicast + to work correctly. This section applies specifically to full + proxying and not to relay. + +2.10.1. Upstream PIM Proxy 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 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 + state. The chosen address MUST NOT be the Upstream Neighbor field to + be encoded in the packet. The Layer 2 encapsulation for the selected + source IP address MUST be the encapsulation recorded in the PIM + Neighbor 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 Router (FHR). As the FHR + will not send any downstream Join/Prune 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 + + + +Dornon, et al. Informational [Page 26] + +RFC 8220 PIM Snooping September 2017 + + + 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 to determine if a source is directly connected. + + o Another option is to configure all PEs to 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, 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 Rules + + First, we define the rules that are common to PIM-SM and PIM-DM PEs. + Forwarding rules for each protocol type are specified in the + subsections below. + + If there is no matching forwarding state, then the PE SHOULD discard + the packet, i.e., the UserDefinedPortList (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 rules, traffic ingressing on a PW + MUST NOT be forwarded to any other PW. + + + + + + + + + + + +Dornon, et al. Informational [Page 27] + +RFC 8220 PIM Snooping September 2017 + + +2.12.1. PIM-SM 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 data-forwarding rules are defined below in + pseudocode: + + BEGIN + iif is the incoming port of the multicast packet. + S is the source IP address of the multicast packet. + G is the destination IP 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 + + + + +Dornon, et al. Informational [Page 28] + +RFC 8220 PIM Snooping September 2017 + + + First, if there is (S,G) state on the PE, then the set of outgoing + ports is OutgoingPortList(S,G). + + 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. PIM-DM Data-Forwarding Rules + + The PIM-DM snooping data-forwarding rules are defined below in + pseudocode: + + BEGIN + iif is the incoming port of the multicast packet. + S is the source IP address of the multicast packet. + G is the destination IP 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 2.12. + + RFC 3973 [PIM-DM] specifies how olist(S,G) is constructed. + +3. IANA Considerations + + This document does not require any IANA actions. + + + + + + +Dornon, et al. Informational [Page 29] + +RFC 8220 PIM Snooping September 2017 + + +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. + +5. References + +5.1. Normative References + + [BIDIR-PIM] + Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, + "Bidirectional Protocol Independent Multicast + (BIDIR-PIM)", RFC 5015, DOI 10.17487/RFC5015, + October 2007, . + + [JOIN-ATTR] + Boers, A., Wijnands, I., and E. Rosen, "The Protocol + Independent Multicast (PIM) Join Attribute Format", + RFC 5384, DOI 10.17487/RFC5384, November 2008, + . + + [PIM-DM] Adams, A., Nicholas, J., and W. Siadak, "Protocol + Independent Multicast - Dense Mode (PIM-DM): Protocol + Specification (Revised)", RFC 3973, DOI 10.17487/RFC3973, + January 2005, . + + [PIM-SM] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., + Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent + Multicast - Sparse Mode (PIM-SM): Protocol Specification + (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, + March 2016, . + + [PIM-SSM] Holbrook, H. and B. Cain, "Source-Specific Multicast for + IP", RFC 4607, DOI 10.17487/RFC4607, August 2006, + . + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in + RFC 2119 Key Words", BCP 14, RFC 8174, + DOI 10.17487/RFC8174, May 2017, + . + + + + + +Dornon, et al. Informational [Page 30] + +RFC 8220 PIM Snooping September 2017 + + + [RPF-VECTOR] + Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path + Forwarding (RPF) Vector TLV", RFC 5496, + DOI 10.17487/RFC5496, March 2009, + . + +5.2. Informative References + + [IGMP-SNOOP] + Christensen, M., Kimball, K., and F. Solensky, + "Considerations for Internet Group Management Protocol + (IGMP) and Multicast Listener Discovery (MLD) Snooping + Switches", RFC 4541, DOI 10.17487/RFC4541, May 2006, + . + + [VPLS-BGP] + Kompella, K., Ed., and Y. Rekhter, Ed., "Virtual Private + LAN Service (VPLS) Using BGP for Auto-Discovery and + Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, + . + + [VPLS-LDP] + Lasserre, M., Ed., and V. Kompella, Ed., "Virtual Private + LAN Service (VPLS) Using Label Distribution Protocol (LDP) + Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, + . + + [VPLS-MCAST] + Aggarwal, R., Ed., Kamite, Y., Fang, L., Rekhter, Y., and + C. Kodeboniya, "Multicast in Virtual Private LAN Service + (VPLS)", RFC 7117, DOI 10.17487/RFC7117, February 2014, + . + + [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, DOI 10.17487/RFC5501, + March 2009, . + + + + + + + + + + + + + +Dornon, et al. Informational [Page 31] + +RFC 8220 PIM Snooping September 2017 + + +Appendix A. BIDIR-PIM Considerations + + This appendix describes some guidelines that may be used to preserve + BIDIR-PIM functionality in combination with PIM snooping. + + In order to preserve BIDIR-PIM snooping, routers need to set up + forwarding states so that: + + o on the RPL, all traffic is forwarded to all Port(N) ports. + + o on any other interface, traffic is always forwarded to the DF. + + The information needed to set up these states may be obtained by: + + o determining the mapping between the group (range) and the RP. + + o snooping and storing DF election information. + + o determining where the RPL is. This could be achieved by static + configuration or by combining the information mentioned in the two + bullet items above. + +A.1. BIDIR-PIM Data-Forwarding Rules + + The BIDIR-PIM snooping data-forwarding rules are defined below in + pseudocode: + + BEGIN + iif is the incoming port of the multicast packet. + G is the destination IP 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 + + + +Dornon, et al. Informational [Page 32] + +RFC 8220 PIM Snooping September 2017 + + + If there is forwarding state for G, then forward the packet to + olist(G) while observing the general rules above in Section 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. + + +------+ 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 a Join(S,G) with UpstreamNeighbors(S,G) = CE3. + + 2. PE1 snoops on the Join(S,G) and builds forwarding 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, since + + + +Dornon, et al. Informational [Page 33] + +RFC 8220 PIM Snooping September 2017 + + + 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 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. + + The resulting states at the PEs are as follows: + + PE1 states: + JT(AC1,S,G,CE3) = JP_HoldTime + UpstreamNeighbors(S,G) = { CE3 } + UpstreamPorts(S,G) = { PW12 } + OutgoingPortList(S,G) = { AC1, PW12 } + + PE2 states: + JT(PW12,S,G,CE3) = JP_HoldTime + UpstreamNeighbors(S,G) = { CE3 } + UpstreamPorts(S,G) = { AC3 } + OutgoingPortList(S,G) = { PW12, AC3 } + + PE3 states: + No (S,G) state + + 3. The multicast stream (S,G) flows along CE3 -> PE2 -> PE1 -> CE1. + + 4. Now CE2 sends a Join(S,G) with UpstreamNeighbors(S,G) = CE4. + + 5. All PEs snoop on the Join(S,G), build forwarding state, and flood + the Join(S,G) in the VPLS. Note that for PE2, even though this + is a PW-only Join, forwarding state is built on this Join(S,G), + since PE2 has an existing (S,G) state with an AC in + UpstreamPorts(S,G). + + The resulting states at the 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 } + + + + + + + + + +Dornon, et al. Informational [Page 34] + +RFC 8220 PIM Snooping September 2017 + + + 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 } + + 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 two of the + CEs -- CE3 and CE4. PE2 forwards the stream received from CE3 to + PW23, and PE3 forwards the stream to AC4. This helps the CE + routers to trigger Assert election. Let us say that CE3 becomes + the 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 = CE4. CE2 also sends a + Join(S,G) with upstream neighbor = CE3. + + 10. All the PEs start a Prune-Pending timer on the ports on which + they received the Prune(S,G). When the Prune-Pending timer + expires, all PEs will remove the downstream (S,G,CE4) states. + + The resulting states at the 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 } + + PE2 states: + JT(PW12,S,G,CE3) = active + UpstreamNeighbors(S,G) = { CE3 } + UpstreamPorts(S,G) = { AC3 } + OutgoingPortList(S,G) = { PW12, AC3 } + + + + + + +Dornon, et al. Informational [Page 35] + +RFC 8220 PIM Snooping September 2017 + + + 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), respectively, the + existing (S,G) state at PE3 can also be removed. So, finally: + + PE3 states: + No (S,G) state + + Note that at the end of the Assert election, there should be no + duplicate traffic forwarded 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 election. + +B.2. PIM Proxy Example with (S,G) / (*,G) Interaction + + In the same network, let us assume that CE4 is the 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 a Join(S,G) with UpstreamNeighbors(S,G) = CE3. + + 2. PE1 consumes the Join(S,G) and builds forwarding state, since the + Join(S,G) is received on an AC. + + PE2 consumes the Join(S,G) and builds forwarding 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), since this is a PW-only 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). + + + + + + + + + + + + +Dornon, et al. Informational [Page 36] + +RFC 8220 PIM Snooping September 2017 + + + The resulting states at the PEs 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 Join(S,G) is + targeting a neighbor residing on an AC, it only sends the Join + on AC3. + + PE3 ignores the Join(S,G), since this is a PW-only 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). + + 3. The multicast stream (S,G) flows along CE3 -> PE2 -> PE1 -> CE1. + + 4. Now let us say that CE2 sends a Join(*,G) with + UpstreamNeighbors(*,G) = CE4. + + 5. PE1 consumes the Join(*,G) and builds forwarding state, since the + Join(*,G) is received on an AC. + + PE2 consumes the Join(*,G); although this is a PW-only Join, + forwarding state is built on this 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, 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 OutgoingPortList(*,G). + + + +Dornon, et al. Informational [Page 37] + +RFC 8220 PIM Snooping September 2017 + + + PE3 consumes the Join(*,G) and builds forwarding state, since the + Join(*,G) is targeting a neighbor residing on an AC. + + The resulting states at the PEs 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, since this + is a PW-only 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 + on AC4. + + + +Dornon, et al. Informational [Page 38] + +RFC 8220 PIM Snooping September 2017 + + + 6. If traffic is not flowing yet (i.e., step 3 is delayed 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 based on reception of refresh + Joins from CE1 and 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, since now PE2 + has an existing (*,G) state with an AC in UpstreamPorts(*,G). + However, since this is a PW-only 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: + 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. + + PE3 does not trigger a Join(S,G) based on this Join, since this + is a PW-only Join. + + 8. The multicast stream (S,G) flows into the VPLS from two of the + CEs -- CE3 and CE4. PE2 forwards the stream received from CE3 to + PW12 and PW23. At the same 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. + + + + + +Dornon, et al. Informational [Page 39] + +RFC 8220 PIM Snooping September 2017 + + + 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 helps the CE routers to trigger 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, 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 = CE4. + + 12. PE1 consumes the 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 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 + based on this Prune(S,G,rpt), since this was a PW-only Prune. + + PE3 consumes the Prune(S,G,rpt), and since + PruneDesired(S,G,rpt,CE4) is 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 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 + 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 } + + + + + + + +Dornon, et al. Informational [Page 40] + +RFC 8220 PIM Snooping September 2017 + + + PE2 states: + JT(PW12,*,G,CE4) = active + UpstreamNeighbors(*,G) = { CE4 } + UpstreamPorts(*,G) = { PW23 } + OutgoingPortList(*,G) = { PW23 } + + JT(PW12,S,G,CE4) = JP_HoldTime with S,G,rpt prune flag + JPST(S,G,CE4) = none, since this was created + off a PW-only 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 } + + 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 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 + 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 + election, there should be no duplicate traffic forwarded downstream, + and traffic should flow only to the desired CEs. + + However, we don't have duplicate traffic because one of the CEs stops + sending traffic due to the Assert, not because we don't have any + forwarding state in the PEs to do this forwarding. + + + + + +Dornon, et al. Informational [Page 41] + +RFC 8220 PIM Snooping September 2017 + + +Acknowledgements + + Many members of the former L2VPN and PIM working groups have + contributed to, and provided valuable comments and feedback on, this + document, including Vach Kompella, Shane Amante, Sunil Khandekar, Rob + Nath, Marc Lasserre, Yuji Kamite, Yiqun Cai, Ali Sajassi, Jozef + Raets, Himanshu Shah (Ciena), and Himanshu Shah (Cisco). + +Contributors + + Yetik Serbest and Suresh Boddapati coauthored earlier 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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Dornon, et al. Informational [Page 42] + +RFC 8220 PIM Snooping September 2017 + + +Authors' Addresses + + Olivier Dornon + Nokia + Copernicuslaan 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 + + + + + + + + + + + + +Dornon, et al. Informational [Page 43] + -- cgit v1.2.3