idnits 2.17.1 draft-ietf-pals-vpls-pim-snooping-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 14, 2017) is 2498 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PALS Workgroup O. Dornon 3 Internet-Draft J. Kotalwar 4 Intended status: Informational Nokia 5 Expires: December 16, 2017 V. Hemige 7 R. Qiu 8 mistnet.io 9 Z. Zhang 10 Juniper Networks, Inc. 11 June 14, 2017 13 Protocol Independent Multicast (PIM) over Virtual Private LAN Service 14 (VPLS) 15 draft-ietf-pals-vpls-pim-snooping-06 17 Abstract 19 This document describes the procedures and recommendations for 20 Virtual Private LAN Service (VPLS) Provider Edges (PEs) to facilitate 21 replication of multicast traffic to only certain ports (behind which 22 there are interested Protocol Independent Multicast (PIM) routers 23 and/or Internet Group Management Protocol (IGMP) hosts) via Protocol 24 Independent Multicast (PIM) snooping and proxying. 26 With PIM snooping, PEs passively listen to certain PIM control 27 messages to build control and forwarding states while transparently 28 flooding those messages. With PIM proxying, Provider Edges (PEs) do 29 not flood PIM Join/Prune messages but only generate their own and 30 send out of certain ports, based on the control states built from 31 downstream Join/Prune messages. PIM proxying is required when PIM 32 Join suppression is enabled on the Customer Equipment (CE) devices 33 and useful to reduce PIM control traffic in a VPLS domain. 35 The document also describes PIM relay, which can be viewed as light- 36 weight proxying, where all downstream Join/Prune messages are simply 37 forwarded out of certain ports but not flooded to avoid triggering 38 PIM Join suppression on CE devices. 40 Requirements Language 42 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 43 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 44 document are to be interpreted as described in RFC 2119 [RFC2119]. 46 Status of This Memo 48 This Internet-Draft is submitted in full conformance with the 49 provisions of BCP 78 and BCP 79. 51 Internet-Drafts are working documents of the Internet Engineering 52 Task Force (IETF). Note that other groups may also distribute 53 working documents as Internet-Drafts. The list of current Internet- 54 Drafts is at http://datatracker.ietf.org/drafts/current/. 56 Internet-Drafts are draft documents valid for a maximum of six months 57 and may be updated, replaced, or obsoleted by other documents at any 58 time. It is inappropriate to use Internet-Drafts as reference 59 material or to cite them other than as "work in progress." 61 This Internet-Draft will expire on December 16, 2017. 63 Copyright Notice 65 Copyright (c) 2017 IETF Trust and the persons identified as the 66 document authors. All rights reserved. 68 This document is subject to BCP 78 and the IETF Trust's Legal 69 Provisions Relating to IETF Documents 70 (http://trustee.ietf.org/license-info) in effect on the date of 71 publication of this document. Please review these documents 72 carefully, as they describe your rights and restrictions with respect 73 to this document. Code Components extracted from this document must 74 include Simplified BSD License text as described in Section 4.e of 75 the Trust Legal Provisions and are provided without warranty as 76 described in the Simplified BSD License. 78 Table of Contents 80 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 81 1.1. Multicast Snooping in VPLS . . . . . . . . . . . . . . . 4 82 1.2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 5 83 1.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 84 2. PIM Snooping for VPLS . . . . . . . . . . . . . . . . . . . . 6 85 2.1. PIM protocol background . . . . . . . . . . . . . . . . . 6 86 2.2. General Rules for PIM Snooping in VPLS . . . . . . . . . 7 87 2.2.1. Preserving Assert Trigger . . . . . . . . . . . . . . 7 88 2.3. Some Considerations for PIM Snooping . . . . . . . . . . 8 89 2.3.1. Scaling . . . . . . . . . . . . . . . . . . . . . . . 8 90 2.3.2. IPv4 and IPv6 . . . . . . . . . . . . . . . . . . . . 9 91 2.3.3. PIM-SM (*,*,RP) . . . . . . . . . . . . . . . . . . . 9 92 2.4. PIM Snooping vs PIM Proxying . . . . . . . . . . . . . . 9 93 2.4.1. Differences between PIM Snooping, Relay and Proxying 9 94 2.4.2. PIM Control Message Latency . . . . . . . . . . . . . 10 95 2.4.3. When to Snoop and When to Proxy . . . . . . . . . . . 11 96 2.5. Discovering PIM Routers . . . . . . . . . . . . . . . . . 12 97 2.6. PIM-SM and PIM-SSM . . . . . . . . . . . . . . . . . . . 13 98 2.6.1. Building PIM-SM States . . . . . . . . . . . . . . . 13 99 2.6.2. Explanation for per (S,G,N) states . . . . . . . . . 16 100 2.6.3. Receiving (*,G) PIM-SM Join/Prune Messages . . . . . 16 101 2.6.4. Receiving (S,G) PIM-SM Join/Prune Messages . . . . . 18 102 2.6.5. Receiving (S,G,rpt) Join/Prune Messages . . . . . . . 20 103 2.6.6. Sending Join/Prune Messages Upstream . . . . . . . . 20 104 2.7. Bidirectional-PIM (BIDIR-PIM) . . . . . . . . . . . . . . 21 105 2.8. Interaction with IGMP Snooping . . . . . . . . . . . . . 22 106 2.9. PIM-DM . . . . . . . . . . . . . . . . . . . . . . . . . 22 107 2.9.1. Building PIM-DM States . . . . . . . . . . . . . . . 22 108 2.9.2. PIM-DM Downstream Per-Port PIM(S,G,N) State Machine . 23 109 2.9.3. Triggering ASSERT election in PIM-DM . . . . . . . . 23 110 2.10. PIM Proxy . . . . . . . . . . . . . . . . . . . . . . . . 23 111 2.10.1. Upstream PIM Proxy behavior . . . . . . . . . . . . 24 112 2.11. Directly Connected Multicast Source . . . . . . . . . . . 24 113 2.12. Data Forwarding Rules . . . . . . . . . . . . . . . . . . 25 114 2.12.1. PIM-SM Data Forwarding Rules . . . . . . . . . . . . 25 115 2.12.2. PIM-DM Data Forwarding Rules . . . . . . . . . . . . 26 116 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 117 4. Security Considerations . . . . . . . . . . . . . . . . . . . 27 118 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 27 119 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 120 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 121 7.1. Normative References . . . . . . . . . . . . . . . . . . 28 122 7.2. Informative References . . . . . . . . . . . . . . . . . 29 123 Appendix A. BIDIR-PIM Considerations . . . . . . . . . . . . . . 29 124 A.1. BIDIR-PIM Data Forwarding Rules . . . . . . . . . . . . . 30 125 Appendix B. Example Network Scenario . . . . . . . . . . . . . . 30 126 B.1. PIM Snooping Example . . . . . . . . . . . . . . . . . . 31 127 B.2. PIM Proxy Example with (S,G) / (*,G) interaction . . . . 34 128 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 130 1. Introduction 132 In Virtual Private LAN Service (VPLS), the Provider Edge (PE) devices 133 provide a logical interconnect such that Customer Edge (CE) devices 134 belonging to a specific VPLS instance appear to be connected by a 135 single LAN. The Forwarding Information Base (FIB) for a VPLS 136 instance is populated dynamically by MAC address learning. Once a 137 unicast MAC address is learned and associated with a particular 138 Attachment Circuit (AC) or PseudoWire (PW), a frame destined to that 139 MAC address only needs to be sent on that AC or PW. 141 For a frame not addressed to a known unicast MAC address, flooding 142 has to be used. This happens with the following so called BUM 143 (Broadcast Unknown Multicast) traffic: 145 o B: The destination MAC address is a broadcast address, 147 o U: The destination MAC address is unknown (has not been learned), 149 o M: The destination MAC address is a multicast address. 151 Multicast frames are flooded because a PE cannot know where 152 corresponding multicast group members reside. VPLS solutions (i.e., 153 RFC 4762 [VPLS-LDP] and RFC 4761 [VPLS-BGP]) perform replication for 154 multicast traffic at the ingress PE devices. As stated in the VPLS 155 Multicast Requirements document RFC 5501 [VPLS-MCAST-REQ], there are 156 two issues with VPLS multicast today: 158 o A. Multicast traffic is replicated to non-member sites. 160 o B. Multicast traffic may be replicated when several PWs share a 161 physical path. 163 Issue A can be solved by multicast snooping - PEs learn sites with 164 multicast group members by snooping multicast protocol control 165 messages on ACs and forward IP multicast traffic only to member 166 sites. This document describes the procedures to achieve this when 167 CE devices are PIM adjacencies of each other. Issue B is outside the 168 scope of this document and discussed in RFC 7117 [VPLS-MCAST] . 170 While this document is in the context of VPLS, the procedures also 171 apply to regular layer-2 switches interconnected by physical 172 connections, except that the PW related concept and procedures do not 173 apply in that case. 175 1.1. Multicast Snooping in VPLS 177 IGMP snooping procedures described in RFC 4541 [IGMP-SNOOP] make sure 178 that IP multicast traffic is only sent on the following: 180 o Attachment Circuits (ACs) connecting to hosts that report related 181 group membership 183 o ACs connecting to routers that join related multicast groups 185 o PseudoWires (PWs) connecting to remote PEs that have the above 186 described ACs 188 Notice that traffic is always sent on ports that have point-to-point 189 connections to routers that are attached to a LAN on which there is 190 at least one other router. Because IGMP snooping alone can not 191 determine if there are interested receivers beyond those routers we 192 always need to send traffic to these ports, even if there are no 193 snooped group memberships. To further restrict traffic sent to those 194 routers, PIM snooping can be used. This document describes the 195 procedures for PIM snooping, including the rules when both IGMP and 196 PIM snooping are enabled in a VPLS instance, which are elaborated in 197 sections Section 2.8 and Section 2.11. 199 Note that for both IGMP and PIM, the term snooping is used loosely, 200 referring to the fact that a layer-2 device peeks into layer-3 201 routing protocol messages to build relevant control and forwarding 202 states. Depending on whether the control messages are transparently 203 flooded, selectively forwarded, or aggregated, the processing may be 204 called snooping or proxy in different contexts. 206 We will use the term PIM snooping in this document; but, unless 207 explicitly noted, the procedures apply equally to PIM snooping and 208 PIM proxying. The PIM proxying specific procedures are described in 209 Section 2.6.6. Differences that need to be observed while 210 implementing one or the other and recommendations on which method to 211 employ in different scenarios are noted in section Section 2.4. 213 This document also describes PIM relay, which can be viewed as light- 214 weight PIM proxying. Unless explicitly noted, in the rest of the 215 document proxying implicitly includes relay as well. Please refer to 216 Section 2.4.1 for an overview of the differences between snooping, 217 proxying and relay. 219 1.2. Assumptions 221 This document assumes that the reader has good understanding of the 222 PIM protocols. This document is written in the same style as the PIM 223 RFCs to help correlate the concepts and to make it easier to follow. 224 In order to avoid replicating text related to PIM protocol handling 225 from the PIM RFCs, this document cross references corresponding 226 definitions and procedures in these RFCs. Deviations in protocol 227 handling specific to PIM snooping are specified in this document. 229 1.3. Definitions 231 There are several definitions referenced in this document that are 232 well described in the PIM RFCs RFC 7761 [PIM-SM], RFC 5015 233 [BIDIR-PIM] and RFC 3973 [PIM-DM]. The following definitions and 234 abbreviations are used throughout this document: 236 o A port is defined as either an attachment circuit (AC) or a 237 pseudowire (PW). 239 o When we say a PIM message is received on a PE port, it means that 240 the PE is processing the message for snooping/proxying or 241 relaying. 243 Abbreviations used in the document: 245 o S: IP address of the multicast source. 247 o G: IP address of the multicast group. 249 o N: Upstream neighbor field in a Join/Prune/Graft message. 251 o Port(N): Port on which neighbor N is learned, i.e. the port on 252 which N's Hellos are received. 254 o rpt : Rendezvous Point Tree 256 o PIM-DM: Protocol Independent Multicast - Dense Mode. 258 o PIM-SM: Protocol Independent Multicast - Sparse Mode. 260 o PIM-SSM: Protocol Independent Multicast - Source Specific Mode. 262 Other definitions are explained in the sections where they are 263 introduced. 265 2. PIM Snooping for VPLS 267 2.1. PIM protocol background 269 PIM is a multicast routing protocol running between routers, which 270 are CE devices in a VPLS. It uses the unicast routing table to 271 provide reverse path information for building multicast trees. There 272 are a few variants of PIM. In RFC 3973 [PIM-DM], multicast datagrams 273 are pushed towards downstream neighbors, similar to a broadcast 274 mechanism, but in areas of the network where there are no group 275 members, routers prune back branches of the multicast tree towards 276 the source. Unlike PIM-DM, other PIM flavors (RFC 7761 [PIM-SM], RFC 277 4607 [PIM-SSM], and RFC 5015 [BIDIR-PIM]) employ a pull methodology 278 via explicit joins instead of the push and prune technique. 280 PIM routers periodically exchange Hello messages to discover and 281 maintain stateful sessions with neighbors. After neighbors are 282 discovered, PIM routers can signal their intentions to join or prune 283 specific multicast groups. This is accomplished by having downstream 284 routers send an explicit Join/Prune message (for the sake of 285 generalization, consider Graft messages for PIM-DM as Join messages) 286 to their corresponding upstream router. The Join/Prune message can 287 be group specific (*,G) or group and source specific(S,G). 289 2.2. General Rules for PIM Snooping in VPLS 291 The following rules for the correct operation of PIM snooping MUST be 292 followed. 294 o PIM snooping MUST NOT affect the operation of customer layer-2 295 protocols or layer-3 protocols. 297 o PIM messages and multicast data traffic forwarded by PEs MUST 298 follow the split-horizon rule for mesh PWs, as defined in RFC 4762 299 [VPLS-LDP]. 301 o PIM states in a PE MUST be per VPLS instance. 303 o PIM assert triggers MUST be preserved to the extent necessary to 304 avoid sending duplicate traffic to the same PE (see 305 Section 2.2.1). 307 2.2.1. Preserving Assert Trigger 309 In PIM-SM/DM, there are scenarios where multiple routers could be 310 forwarding the same multicast traffic on a LAN. When this happens, 311 these routers start the PIM Assert election process by sending PIM 312 Assert messages, to ensure that only the Assert winner forwards 313 multicast traffic on the LAN. The Assert election is a data driven 314 event and happens only if a router sees traffic on the interface to 315 which it should be forwarding the traffic. In the case of VPLS with 316 PIM snooping, two routers may forward the same multicast datagrams at 317 the same time but each copy may reach different set of PEs, and that 318 is acceptable from the point of view of avoiding duplicate traffic. 319 If the two copies may reach the same PE then the sending routers must 320 be able to see each other's traffic, in order to trigger Assert 321 election and stop duplicate traffic. To achieve that, PEs enabled 322 with PIM-SSM/SM snooping MUST forward multicast traffic for an 323 (S,G)/(*,G) not only on the ports on which they snooped 324 Joins(S,G)/Joins(*,G), but also towards the upstream neighbor(s)). 325 In other words, the ports on which the upstream neighbors are learned 326 must be added to the outgoing port list along with the ports on which 327 Joins are snooped. Please refer to Section 2.6.1 for the rules that 328 determine the set of upstream neighbors for a particular (x,G). 330 Similarly, PIM-DM snooping SHOULD make sure that asserts can be 331 triggered (Section 2.9.3). 333 The above logic needs to be facilitated without breaking VPLS split- 334 horizon forwarding rules. That is, traffic should not be forwarded 335 on the port on which it was received, and traffic arriving on a PW 336 MUST NOT be forwarded onto other PW(s). 338 2.3. Some Considerations for PIM Snooping 340 The PIM snooping solution described here requires a PE to examine and 341 operate on only PIM Hello and PIM Join/Prune packets. The PE does 342 not need to examine any other PIM packets. 344 Most of the PIM snooping procedures for handling Hello/Join/Prune 345 messages are very similar to those executed in a PIM router. 346 However, the PE does not need to have any routing tables like those 347 required in PIM multicast routing. It knows how to forward Join/ 348 Prunes only by looking at the Upstream Neighbor field in the Join/ 349 Prune packets, as described in Section 2.12. 351 The PE does not need to know about Rendezvous Points (RP) and does 352 not have to maintain any RP Set. All that is transparent to a PIM 353 snooping PE. 355 In the following sub-sections, we list some considerations and 356 observations for the implementation of PIM snooping in VPLS. 358 2.3.1. Scaling 360 PIM snooping needs to be employed on ACs at the downstream PEs (PEs 361 receiving multicast traffic across the VPLS core) to prevent traffic 362 from being sent out of ACs unnecessarily. PIM snooping techniques 363 can also be employed on PWs at the upstream PEs (PEs receiving 364 traffic from local ACs in a hierarchical VPLS) to prevent traffic 365 from being sent to PEs unnecessarily. This may work well for small 366 to medium scale deployments. However, if there are a large number of 367 VPLS instances with a large number of PEs per instance, then the 368 amount of snooping required at the upstream PEs can overwhelm the 369 upstream PEs. 371 There are two methods to reduce the burden on the upstream PEs. One 372 is to use PIM proxying as described in Section 2.6.6, to reduce the 373 control messages forwarded by a PE. The other is not to snoop on the 374 PWs at all, but PEs signal the snooped states to other PEs out of 375 band via BGP, as described in RFC 7117 [VPLS-MCAST]. In this 376 document, it is assumed that snooping is performed on PWs. 378 2.3.2. IPv4 and IPv6 380 In VPLS, PEs forward Ethernet frames received from CEs and as such 381 are agnostic of the layer-3 protocol used by the CEs. However, as a 382 PIM snooping PE, the PE would have to look deeper into the IP and PIM 383 packets and build snooping state based on that. The PIM Protocol 384 specifications handle both IPv4 and IPv6. The specification for PIM 385 snooping in this document can be applied to both IPv4 and IPv6 386 payloads. 388 2.3.3. PIM-SM (*,*,RP) 390 This document does not address (*,*,RP) states in the VPLS network, 391 as they have been removed from the PIM protocol as described in RFC 392 7761 [PIM-SM]. 394 2.4. PIM Snooping vs PIM Proxying 396 This document has previously alluded to PIM snooping/relay/proxying. 397 Details on the PIM relay/proxying solution are discussed in 398 Section 2.6.6. In this section, a brief description and comparison 399 are given. 401 2.4.1. Differences between PIM Snooping, Relay and Proxying 403 Differences between PIM snooping and relay/proxying can be summarized 404 as the following: 406 +--------------------+---------------------+-----------------------+ 407 | PIM snooping | PIM relay | PIM proxying | 408 +====================|=====================|=======================+ 409 | Join/Prune messages| Join/Prune messages | Join/Prune messages | 410 | snooped and flooded| snooped; forwarded | consumed. Regenerated | 411 | according to VPLS | as is out of certain| ones sent out of | 412 | flooding procedures| upstream ports | certain upstream ports| 413 +--------------------+---------------------+-----------------------+ 414 | Hello messages | Hello messages | Hello messages | 415 | snooped and flooded| snooped and flooded | snooped and flooded | 416 | according to VPLS | according to VPLS | according to VPLS | 417 | flooding procedures| flooding procedures | flooding procedures | 418 +--------------------+---------------------+-----------------------+ 419 | No PIM packets | No PIM packets | New Join/Prune | 420 | generated. | generated | messages generated | 421 +--------------------+---------------------+-----------------------+ 422 | CE Join suppression| CE Join Suppression | CE Join suppression | 423 | not allowed | allowed | allowed | 424 +--------------------+---------------------+-----------------------+ 426 Other than the above differences, most of the procedures are common 427 to PIM snooping and PIM relay/proxying, unless specifically stated 428 otherwise. 430 Pure PIM snooping PEs simply snoop on PIM packets as they are being 431 forwarded in the VPLS. As such they truly provide transparent LAN 432 services since no customer packets are modified or consumed or new 433 packets introduced in the VPLS. It is also simpler to implement than 434 PIM proxying. However for PIM snooping to work correctly, it is a 435 requirement that CE routers MUST disable Join suppression in the 436 VPLS. Otherwise, most of the CE routers with interest in a given 437 multicast data stream will fail to send Join/Prune messages for that 438 stream, and the PEs will not be able to tell which ACs and/or PWs 439 have listeners for that stream. 441 Given that a large number of existing CE deployments do not support 442 disabling of Join suppression and given the operational complexity 443 for a provider to manage disabling of Join suppression in the VPLS, 444 it becomes a difficult solution to deploy. Another disadvantage of 445 PIM snooping is that it does not scale as well as PIM proxying. If 446 there are a large number of CEs in a VPLS, then every CE will see 447 every other CE's Join/Prune messages. 449 PIM relay/proxying has the advantage that it does not require Join 450 suppression to be disabled in the VPLS. Multicast as a VPLS service 451 can be very easily provided without requiring any changes on the CE 452 routers. PIM relay/proxying helps scale VPLS Multicast since Join/ 453 Prune messages are only sent to certain upstream ports instead of 454 flooded, and in case of full proxying (vs. relay) the PEs 455 intelligently generate only one Join/Prune message for a given 456 multicast stream. 458 PIM proxying however loses the transparency argument since Join/ 459 Prunes could get modified or even consumed at a PE. Also, new 460 packets could get introduced in the VPLS. However, this loss of 461 transparency is limited to PIM Join/Prune packets. It is in the 462 interest of optimizing multicast in the VPLS and helping a VPLS 463 network scale much better, both for the provider and the customer. 464 Data traffic will still be completely transparent. 466 2.4.2. PIM Control Message Latency 468 A PIM snooping/relay/proxying PE snoops on PIM Hello packets while 469 transparently flooding them in the VPLS. As such there is no latency 470 introduced by the VPLS in the delivery of PIM Hello packets to remote 471 CEs in the VPLS. 473 A PIM snooping PE snoops on PIM Join/Prune packets while 474 transparently flooding them in the VPLS. There is no latency 475 introduced by the VPLS in the delivery of PIM Join/Prune packets when 476 PIM snooping is employed. 478 A PIM relay/proxying PE does not simply flood PIM Join/Prune packets. 479 This can result in additional latency for a downstream CE to receive 480 multicast traffic after it has sent a Join. When a downstream CE 481 prunes a multicast stream, the traffic SHOULD stop flowing to the CE 482 with no additional latency introduced by the VPLS. 484 Performing only proxying of Join/Prune and not Hello messages keeps 485 the PE behavior very similar to that of a PIM router without 486 introducing too much additional complexity. It keeps the PIM 487 proxying solution fairly simple. Since Join/Prunes are forwarded by 488 a PE along the slow-path and all other PIM packet types are forwarded 489 along the fast-path, it is very likely that packets forwarded along 490 the fast-path will arrive "ahead" of Join/Prune packets at a CE 491 router (note the stress on the fact that fast-path messages will 492 never arrive after Join/Prunes). Of particular importance are Hello 493 packets sent along the fast-path. We can construct a variety of 494 scenarios resulting in out of order delivery of Hellos and Join/Prune 495 messages. However, there should be no deviation from normal expected 496 behavior observed at the CE router receiving these messages out of 497 order. 499 2.4.3. When to Snoop and When to Proxy 501 From the above descriptions, factors that affect the choice of 502 snooping/relay/proxying include: 504 o Whether CEs do Join Suppression or not 506 o Whether Join/Prune latency is critical or not 508 o Whether the scale of PIM protocol message/states in a VPLS 509 requires the scaling benefit of proxying 511 Of the above factors, Join Suppression is the hard one - pure 512 snooping can only be used when Join Suppression is disabled on all 513 CEs. The latency associated with relay/proxying is implementation 514 dependent and may not be a concern at all with a particular 515 implementation. The scaling benefit may not be important either, in 516 that on a real LAN with Explicit Tracking (ET) a PIM router will need 517 to receive and process all PIM Join/Prune messages as well. 519 A PIM router indicates that Join Suppression is disabled if the T-bit 520 is set in the LAN Prune Delay option of its Hello message. If all 521 PIM routers on a LAN set the T-bit, Explicit Tracking is possible, 522 allowing an upstream router to track all the downstream neighbors 523 that have Join states for any (S,G) or (*,G). That has two benefits: 525 o No need for PrunePending process - the upstream router may 526 immediately stop forwarding data when it receives a Prune from the 527 last downstream neighbor, and immediately prune to its upstream if 528 that's for the last downstream interface. 530 o For management purpose, the upstream router knows exactly which 531 downstream routers exist for a particular Join State. 533 While full proxying can be used with or without Join Suppression on 534 CEs and does not interfere with an upstream CE's bypass of 535 PrunePending process, it does proxy all its downstream CEs as a 536 single one to the upstream, removing the second benefit mentioned 537 above. 539 Therefore, the general rule is that if Join Suppression is enabled on 540 one or more CEs then proxying or relay MUST be used, but if 541 Suppression is known to be disabled on all CEs then either snooping, 542 relay, or proxying MAY be used while snooping or relay SHOULD be 543 used. 545 An implementation MAY choose dynamic determination of which mode to 546 use, through the tracking of the above mentioned T-bit in all snooped 547 PIM Hello messages, or MAY simply require static provisioning. 549 2.5. Discovering PIM Routers 551 A PIM snooping PE MUST snoop on PIM Hellos received on ACs and PWs. 552 i.e., the PE transparently floods the PIM Hello while snooping on it. 553 PIM Hellos are used by the snooping PE to discover PIM routers and 554 their characteristics. 556 For each neighbor discovered by a PE, it includes an entry in the PIM 557 Neighbor Database with the following fields: 559 o Layer 2 encapsulation for the Router sending the PIM Hello. 561 o IP Address and address family of the Router sending the PIM Hello. 563 o Port (AC / PW) on which the PIM Hello was received. 565 o Hello TLVs 566 The PE should be able to interpret and act on Hello TLVs currently 567 defined in the PIM RFCs. The TLVs of particular interest in this 568 document are: 570 o Hello-Hold-Time 572 o Tracking Support 574 o DR Priority 576 Please refer to RFC 7761 [PIM-SM] for a list of the Hello TLVs. When 577 a PIM Hello is received, the PE MUST reset the neighbor-expiry-timer 578 to Hello-Hold-Time. If a PE does not receive a Hello message from a 579 router within Hello-Hold-Time, the PE MUST remove that neighbor from 580 its PIM Neighbor Database. If a PE receives a Hello message from a 581 router with Hello-Hold-Time value set to zero, the PE MUST remove 582 that router from the PIM snooping state immediately. 584 From the PIM Neighbor Database, a PE MUST be able to use the 585 procedures defined in RFC 7761 [PIM-SM] to identify the PIM 586 Designated Router in the VPLS instance. It should also be able to 587 determine if Tracking Support is active in the VPLS instance. 589 2.6. PIM-SM and PIM-SSM 591 The key characteristic of PIM-SM and PIM-SSM is explicit join 592 behavior. In this model, multicast traffic is only forwarded to 593 locations that specifically request it. All the procedures described 594 in this section apply to both PIM-SM and PIM-SSM, except for the fact 595 that there is no (*,G) state in PIM-SSM. 597 2.6.1. Building PIM-SM States 599 PIM-SM and PIM-SSM states are built by snooping on the PIM-SM Join/ 600 Prune messages received on AC/PWs. 602 The downstream state machine of a PIM-SM snooping PE very closely 603 resembles the downstream state machine of PIM-SM routers. The 604 downstream state consists of: 606 Per downstream (Port, *, G): 608 o DownstreamJPState: One of { "NoInfo" (NI), "Join" (J), "Prune 609 Pending" (PP) } 611 Per downstream (Port, *, G, N): 613 o Prune Pending Timer (PPT(N)) 614 o Join Expiry Timer (ET(N)) 616 Per downstream (Port, S, G): 618 o DownstreamJPState: One of { "NoInfo" (NI), "Join" (J), "Prune 619 Pending" (PP) } 621 Per downstream (Port, S, G, N): 623 o Prune Pending Timer (PPT(N)) 625 o Join Expiry Timer (ET(N)) 627 Per downstream (Port, S, G, rpt): 629 o DownstreamJPRptState: One of { "NoInfo" (NI), "Pruned" (P), "Prune 630 Pending" (PP) } 632 Per downstream (Port, S, G, rpt, N): 634 o Prune Pending Timer (PPT(N)) 636 o Join Expiry Timer (ET(N)) 638 Where S is the address of the multicast source, G is the Group 639 address and N is the upstream neighbor field in the Join/Prune 640 message. Notice that unlike on PIM-SM routers where PPT and ET are 641 per (Interface, S, G), PIM snooping PEs have to maintain PPT and ET 642 per (Port, S, G, N). The reasons for this are explained in 643 Section 2.6.2. 645 Apart from the above states, we define the following state 646 summarization macros. 648 UpstreamNeighbors(*,G): If there is one or more Join(*,G) received on 649 any port with upstream neighbor N and ET(N) is active, then N is 650 added to UpstreamNeighbors(*,G). This set is used to determine if a 651 Join(*,G) or a Prune(*,G) with upstream neighbor N needs to be sent 652 upstream. 654 UpstreamNeighbors(S,G): If there is one or more Join(S,G) received on 655 any port with upstream neighbor N and ET(N) is active, then N is 656 added to UpstreamNeighbors(S,G). This set is used to determine if a 657 Join(S,G) or a Prune(S,G) with upstream neighbor N needs to be sent 658 upstream. 660 UpstreamPorts(*,G): This is the set of all Port(N) ports where N is 661 in the set UpstreamNeighbors(*,G). Multicast Streams forwarded using 662 a (*,G) match MUST be forwarded to these ports. So 663 UpstreamPorts(*,G) MUST be added to OutgoingPortList(*,G). 665 UpstreamPorts(S,G): This is the set of all Port(N) ports where N is 666 in the set UpstreamNeighbors(S,G). UpstreamPorts(S,G) MUST be added 667 to OutgoingPortList(S,G). 669 InheritedUpstreamPorts(S,G): This is the union of UpstreamPorts(S,G) 670 and UpstreamPorts(*,G). 672 UpstreamPorts(S,G,rpt): If PruneDesired(S,G,rpt) becomes true, then 673 this set is set to UpstreamPorts(*,G). Otherwise, this set is empty. 674 UpstreamPorts(*,G) (-) UpstreamPorts(S,G,rpt) MUST be added to 675 OutgoingPortList(S,G). 677 UpstreamPorts(G): This set is the union of all the UpstreamPorts(S,G) 678 and UpstreamPorts(*,G) for a given G. proxy (S,G) Join/Prune and 679 (*,G) Join/Prune messages MUST be sent to a subset of 680 UpstreamPorts(G) as specified in Section 2.6.6.1. 682 PWPorts: This is the set of all PWs. 684 OutgoingPortList(*,G): This is the set of all ports to which traffic 685 needs to be forwarded on a (*,G) match. 687 OutgoingPortList(S,G): This is the set of all ports to which traffic 688 needs to be forwarded on an (S,G) match. 690 See Section 2.12 on Data Forwarding Rules for the specification on 691 how OutgoingPortList is calculated. 693 NumETsActive(Port,*,G): Number of (Port,*,G,N) entries that have 694 Expiry Timer running. This macro keeps track of the number of 695 Join(*,G)s that are received on this Port with different upstream 696 neighbors. 698 NumETsActive(Port,S,G): Number of (Port,S,G,N) entries that have 699 Expiry Timer running. This macro keeps track of the number of 700 Join(S,G)s that are received on this Port with different upstream 701 neighbors. 703 JoinAttributeTlvs(*,G): Join Attributes RFC 5384 [JOIN-ATTR] are TLVs 704 that may be present in received Join(*,G) messages, an example would 705 be RPF Vectors RFC 5496 [RPF-VECTOR]. If present, they must be 706 copied to JoinAttributeTlvs(*,G). 708 JoinAttributeTlvs(S,G): Join Attributes RFC 5384 [JOIN-ATTR] are TLVs 709 that may be present in received Join(S,G) messages. If present, they 710 must be copied to JoinAttributeTlvs(S,G). 712 Since there are a few differences between the downstream state 713 machines of PIM-SM Routers and PIM-SM snooping PEs, we specify the 714 details of the downstream state machine of PIM-SM snooping PEs at the 715 risk of repeating most of the text documented in RFC 7761 [PIM-SM]. 717 2.6.2. Explanation for per (S,G,N) states 719 In PIM Routing protocols, states are built per (S,G). On a router, 720 an (S,G) has only one RPF-Neighbor. However, a PIM snooping PE does 721 not have the Layer 3 routing information available to the routers in 722 order to determine the RPF-Neighbor for a multicast flow. It merely 723 discovers it by snooping the Join/Prune message. A PE could have 724 snooped on two or more different Join/Prune messages for the same 725 (S,G) that could have carried different Upstream-Neighbor fields. 726 This could happen during transient network conditions or due to dual- 727 homed sources. A PE cannot make assumptions on which one to pick, 728 but instead must allow the CE routers to decide which Upstream 729 Neighbor gets elected the RPF-Neighbor. And for this purpose, the PE 730 will have to track downstream and upstream Join/Prune per (S,G,N). 732 2.6.3. Receiving (*,G) PIM-SM Join/Prune Messages 734 A Join(*,G) or Prune(*,G) is considered "received" if the following 735 conditions are met: 737 o The port on which it arrived is not Port(N) where N is the 738 upstream-neighbor N of the Join/Prune(*,G), or, 740 o if both Port(N) and the arrival port are PWs, then there exists at 741 least one other (*,G,Nx) or (Sx,G,Nx) state with an AC 742 UpstreamPort. 744 For simplicity, the case where both Port(N) and the arrival port are 745 PWs is referred to as PW-only Join/Prune in this document. The PW- 746 only Join/Prune handling is so that the Port(N) PW can be added to 747 the related forwarding entries' OutgoingPortList to trigger Assert, 748 but that is only needed for those states with AC UpstreamPort. Note 749 that in PW-only case, it is OK for the arrival port and Port(N) to be 750 the same. See Appendix B for examples. 752 When a router receives a Join(*,G) or a Prune(*,G) with upstream 753 neighbor N, it must process the message as defined in the state 754 machine below. Note that the macro computations of the various 755 macros resulting from this state machine transition is exactly as 756 specified in the PIM-SM RFC 7761 [PIM-SM]. 758 We define the following per-port (*,G,N) macro to help with the state 759 machine below. 761 Figure 1 : Downstream per-port (*,G) state machine in tabular form 763 +---------------++---------------------------------------------+ 764 | || Previous State | 765 | ++------------+--------------+-----------------+ 766 | Event ||NoInfo (NI) | Join (J) | Prune-Pend (PP) | 767 +---------------++------------+--------------+-----------------+ 768 | Receive ||-> J state | -> J state | -> J state | 769 | Join(*,G) || Action | Action | Action | 770 | || RxJoin(N) | RxJoin(N) | RxJoin(N) | 771 +---------------++------------+--------------+-----------------+ 772 |Receive || - | -> PP state | -> PP state | 773 |Prune(*,G) and || | Start PPT(N) | | 774 |NumETsActive<=1|| | | | 775 +---------------++------------+--------------+-----------------+ 776 |Receive || - | -> J state | - | 777 |Prune(*,G) and || | Start PPT(N) | | 778 |NumETsActive>1 || | | | 779 +---------------++------------+--------------+-----------------+ 780 |PPT(N) expires || - | -> J state | -> NI state | 781 | || | Action | Action | 782 | || | PPTExpiry(N) |PPTExpiry(N) | 783 +---------------++------------+--------------+-----------------+ 784 |ET(N) expires || - | -> NI state | -> NI state | 785 |and || | Action | Action | 786 |NumETsActive<=1|| | ETExpiry(N) | ETExpiry(N) | 787 +---------------++------------+--------------+-----------------+ 788 |ET(N) expires || - | -> J state | - | 789 |and || | Action | | 790 |NumETsActive>1 || | ETExpiry(N) | | 791 +---------------++------------+--------------+-----------------+ 793 Action RxJoin(N): 795 If ET(N) is not already running, then start ET(N). Otherwise 796 restart ET(N). If N is not already in UpstreamNeighbors(*,G), 797 then add N to UpstreamNeighbors(*,G) and trigger a Join(*,G) with 798 upstream neighbor N to be forwarded upstream. If there are Join 799 Attribute TLVs in the received (*,G) message and if they are 800 different from the recorded JoinAttributeTlvs(*,G), then copy them 801 into JoinAttributeTlvs(*,G). In case of conflicting attributes 802 the PE will need to perform conflict resolution per (N) as 803 described in RFC 5384 [JOIN-ATTR]. 805 Action PPTExpiry(N): 807 Same as Action ETExpiry(N) below, plus Send a Prune-Echo(*,G) with 808 upstream-neighbor N on the downstream port. 810 Action ETExpiry(N): 812 Disable timers ET(N) and PPT(N). Delete neighbor state 813 (Port,*,G,N). If there are no other (Port,*,G) states with 814 NumETsActive(Port,*,G) > 0, transition DownstreamJPState [PIM-SM] 815 to NoInfo. If there are no other (Port,*,G,N) state (different 816 ports but for the same N), remove N from UpstreamPorts(*,G) - this 817 also serves as a trigger for Upstream FSM (JoinDesired(*,G,N) 818 becomes FALSE). 820 2.6.4. Receiving (S,G) PIM-SM Join/Prune Messages 822 A Join(S,G) or Prune(S,G) is considered "received" if the following 823 conditions are met: 825 o The port on which it arrived is not Port(N) where N is the 826 upstream-neighbor N of the Join/Prune(S,G), or, 828 o if both Port(N) and the arrival port are PWs, then there exists at 829 least one other (*,G,Nx) or (S,G,Nx) state with an AC 830 UpstreamPort. 832 For simplicity, the case where both Port(N) and the arrival port are 833 PWs is referred to as PW-only Join/Prune in this document. The PW- 834 only Join/Prune handling is so that the Port(N) PW can be added to 835 the related forwarding entries' OutgoingPortList to trigger Assert, 836 but that is only needed for those states with AC UpstreamPort. See 837 Appendix B for examples. 839 When a router receives a Join(S,G) or a Prune(S,G) with upstream 840 neighbor N, it must process the message as defined in the state 841 machine below. Note that the macro computations of the various 842 macros resulting from this state machine transition is exactly as 843 specified in RFC 7761 [PIM-SM]. 845 Figure 2: Downstream per-port (S,G) state machine in tabular form 847 +---------------++---------------------------------------------+ 848 | || Previous State | 849 | ++------------+--------------+-----------------+ 850 | Event ||NoInfo (NI) | Join (J) | Prune-Pend (PP) | 851 +---------------++------------+--------------+-----------------+ 852 | Receive ||-> J state | -> J state | -> J state | 853 | Join(S,G) || Action | Action | Action | 854 | || RxJoin(N) | RxJoin(N) | RxJoin(N) | 855 +---------------++------------+--------------+-----------------+ 856 |Receive || - | -> PP state | - | 857 |Prune (S,G) and|| | Start PPT(N) | | 858 |NumETsActive<=1|| | | | 859 +---------------++------------+--------------+-----------------+ 860 |Receive || - | -> J state | - | 861 |Prune(S,G) and || | Start PPT(N) | | 862 NumETsActive>1 || | | | 863 +---------------++------------+--------------+-----------------+ 864 |PPT(N) expires || - | -> J state | -> NI state | 865 | || | Action | Action | 866 | || | PPTExpiry(N) |PPTExpiry(N) | 867 +---------------++------------+--------------+-----------------+ 868 |ET(N) expires || - | -> NI state | -> NI state | 869 |and || | Action | Action | 870 |NumETsActive<=1|| | ETExpiry(N) | ETExpiry(N) | 871 +---------------++------------+--------------+-----------------+ 872 |ET(N) expires || - | -> J state | - | 873 |and || | Action | | 874 |NumETsActive>1 || | ETExpiry(N) | | 875 +---------------++------------+--------------+-----------------+ 877 Action RxJoin(N): 879 If ET(N) is not already running, then start ET(N). Otherwise, 880 restart ET(N). 882 If N is not already in UpstreamNeighbors(S,G), then add N to 883 UpstreamNeighbors(S,G) and trigger a Join(S,G) with upstream 884 neighbor N to be forwarded upstream. If there are Join Attribute 885 TLVs in the received (S,G) message and if they are different from 886 the recorded JoinAttributeTlvs(S,G), then copy them into 887 JoinAttributeTlvs(S,G). In case of conflicting attributes the PE 888 will need to perform conflict resolution per (N) as described in 889 RFC 5384 [JOIN-ATTR]. 891 Action PPTExpiry(N): 893 Same as Action ETExpiry(N) below, plus Send a Prune-Echo(S,G) with 894 upstream-neighbor N on the downstream port. 896 Action ETExpiry(N): 898 Disable timers ET(N) and PPT(N). Delete neighbor state 899 (Port,S,G,N). If there are no other (Port,S,G) states with 900 NumETsActive(Port,S,G) > 0, transition DownstreamJPState to 901 NoInfo. If there are no other (Port,S,G,N) state (different ports 902 but for the same N), remove N from UpstreamPorts(S,G) - this also 903 serves as a trigger for Upstream FSM (JoinDesired(S,G,N) becomes 904 FALSE). 906 2.6.5. Receiving (S,G,rpt) Join/Prune Messages 908 A Join(S,G,rpt) or Prune(S,G,rpt) is "received" when the port on 909 which it was received is not also the port on which the upstream- 910 neighbor N of the Join/Prune(S,G,rpt) was learned. 912 While it is important to ensure that the (S,G) and (*,G) state 913 machines allow for handling per (S,G,N) states, it is not as 914 important for (S,G,rpt) states. It suffices to say that the 915 downstream (S,G,rpt) state machine is the same as what is defined in 916 section 4.5.3 of the RFC 7761 [PIM-SM]. 918 2.6.6. Sending Join/Prune Messages Upstream 920 This section applies only to a PIM relay/proxying PE and not to a PIM 921 snooping PE. 923 A full PIM proxying (not relay) PE MUST implement the Upstream FSM 924 for which the procedures are similar to what is defined in section 925 4.5.4 of RFC 7761 [PIM-SM]. 927 For the purposes of the Upstream FSM, a Join or Prune message with 928 upstream neighbor N is "seen" on a PIM relay/proxying PE if the port 929 on which the message was received is also Port(N), and the port is an 930 AC. The AC requirement is needed because a Join received on the 931 Port(N) PW must not suppress this PE's Join on that PW. 933 A PIM relay PE does not implement the Upstream FSM. It simply 934 forwards received Join/Prune messages out of the same set of upstream 935 ports as in the PIM proxying case. 937 In order to correctly facilitate assert among the CE routers, such 938 Join/Prunes need to send not only towards the upstream neighbor, but 939 also on certain PWs as described below. 941 If JoinAttributeTlvs(*,G) is not empty, then it must be encoded in a 942 Join(*,G) message sent upstream. 944 If JoinAttributeTlvs(S,G) is not empty, then it must be encoded in a 945 Join(S,G) message sent upstream. 947 2.6.6.1. Where to send Join/Prune messages 949 The following rules apply, to both forwarded (in case of PIM relay), 950 refresh and triggered (in case of PIM proxying) (S,G)/(*,G) Join/ 951 Prune messages. 953 o The upstream neighbor field in the Join/Prune to be sent is set to 954 the N in the corresponding Upstream FSM. 956 o if Port(N) is an AC, send the message to Port(N). 958 o Additionally, if OutgoingPortList(x,G,N) contains at least one AC, 959 then the message MUST be sent to at least all the PWs in 960 UpstreamPorts(G) (for (*,G)) or InheritedUpstreamPorts(S,G) (for 961 (S,G)). Alternatively, the message MAY be sent to all PWs. 963 Sending to a subset of PWs as described above guarantees that if 964 traffic (of the same flow) from two upstream routers were to reach 965 this PE, then the two routers will receive from each other, 966 triggering assert. 968 Sending to all PWs guarantees that if two upstream routers both send 969 traffic for the same flow (even if it is to different sets of 970 downstream PEs), then they'll receive from each other, triggering 971 assert. 973 2.7. Bidirectional-PIM (BIDIR-PIM) 975 BIDIR-PIM is a variation of PIM-SM. The main differences between 976 PIM-SM and Bidirectional-PIM are as follows: 978 o There are no source-based trees, and source-specific multicast is 979 not supported (i.e., no (S,G) states) in BIDIR-PIM. 981 o Multicast traffic can flow up the shared tree in BIDIR-PIM. 983 o To avoid forwarding loops, one router on each link is elected as 984 the Designated Forwarder (DF) for each RP in BIDIR-PIM. 986 The main advantage of BIDIR-PIM is that it scales well for many-to- 987 many applications. However, the lack of source-based trees means 988 that multicast traffic is forced to remain on the shared tree. 990 As described in RFC 5015 [BIDIR-PIM], parts of a BIDIR-PIM enabled 991 network may forward traffic without exchanging Join/Prune messages, 992 for instance between DF's and the Rendezvous Point Link (RPL). 994 As the described procedures for PIM snooping rely on the presence of 995 Join/Prune messages, enabling PIM snooping on BIDIR-PIM networks 996 could break the BIDIR-PIM functionality. Deploying PIM snooping on 997 BIDIR-PIM enabled networks will require some further study. Some 998 thoughts are gathered in Appendix A. 1000 2.8. Interaction with IGMP Snooping 1002 Whenever IGMP snooping is enabled in conjunction with PIM snooping in 1003 the same VPLS instance the PE SHOULD follow these rules: 1005 o To maintain the list of multicast routers and ports on which they 1006 are attached, the PE SHOULD NOT use the rules as described in RFC 1007 4541 [IGMP-SNOOP] but SHOULD rely on the neighbors discovered by 1008 PIM snooping. This list SHOULD then be used to apply the 1009 forwarding rule as described in 2.1.1.(1) of RFC 4541 1010 [IGMP-SNOOP]. 1012 o If the PE supports proxy-reporting, an IGMP membership learned 1013 only on a port to which a PIM neighbor is attached but not 1014 elsewhere SHOULD NOT be included in the summarized upstream report 1015 sent to that port. 1017 2.9. PIM-DM 1019 The characteristics of PIM-DM is flood and prune behavior. Shortest 1020 path trees are built as a multicast source starts transmitting. 1022 2.9.1. Building PIM-DM States 1024 PIM-DM states are built by snooping on the PIM-DM Join, Prune, Graft 1025 and State Refresh messages received on AC/PWs and State- Refresh 1026 Messages sent on AC/PWs. By snooping on these PIM-DM messages, a PE 1027 builds the following states per (S,G,N) where S is the address of the 1028 multicast source, G is the Group address and N is the upstream 1029 neighbor to which Prunes/Grafts are sent by downstream CEs: 1031 Per PIM (S,G,N): 1033 Port PIM (S,G,N) Prune State: 1035 * DownstreamPState(S,G,N,Port): One of {"NoInfo" (NI), "Pruned" 1036 (P), "PrunePending" (PP)} 1038 * Prune Pending Timer (PPT) 1040 * Prune Timer (PT) 1042 * Upstream Port (valid if the PIM(S,G,N) Prune State is 1043 "Pruned"). 1045 2.9.2. PIM-DM Downstream Per-Port PIM(S,G,N) State Machine 1047 The downstream per-port PIM(S,G,N) state machine is as defined in 1048 section 4.4.2 of RFC 3973 [PIM-DM] with a few changes relevant to PIM 1049 snooping. When reading section 4.4.2 of RFC 3973 [PIM-DM] for the 1050 purposes of PIM-snooping please be aware that the downstream states 1051 are built per (S, G, N, Downstream-Port} in PIM-snooping and not per 1052 {Downstream- Interface, S, G} as in a PIM-DM router. As noted in the 1053 previous Section 2.9.1, the states (DownstreamPState) and timers (PPT 1054 and PT) are per (S,G,N,P). 1056 2.9.3. Triggering ASSERT election in PIM-DM 1058 Since PIM-DM is a flood-and-prune protocol, traffic is flooded to all 1059 routers unless explicitly pruned. Since PIM-DM routers do not prune 1060 on non-RPF interfaces, PEs should typically not receive Prunes on 1061 Port(RPF-neighbor). So the asserting routers should typically be in 1062 pim_oiflist(S,G). In most cases, assert election should occur 1063 naturally without any special handling since data traffic will be 1064 forwarded to the asserting routers. 1066 However, there are some scenarios where a prune might be received on 1067 a port which is also an upstream port (UP). If we prune the port 1068 from pim_oiflist(S,G), then it would not be possible for the 1069 asserting routers to determine if traffic arrived on their downstream 1070 port. This can be fixed by adding pim_iifs(S,G) to pim_oiflist(S,G) 1071 so that data traffic flows to the UP ports. 1073 2.10. PIM Proxy 1075 As noted earlier, PIM snooping will work correctly only if Join 1076 Suppression is disabled in the VPLS. If Join Suppression is enabled 1077 in the VPLS, then PEs MUST do PIM relay/proxying for VPLS multicast 1078 to work correctly. This section applies specifically to the full 1079 proxying case and not relay. 1081 2.10.1. Upstream PIM Proxy behavior 1083 A PIM proxying PE consumes Join/Prune messages and regenerates PIM 1084 Join/Prune messages to be sent upstream by implementing Upstream FSM 1085 as specified in the PIM RFC. This is the only difference from PIM 1086 relay. 1088 The source IP address in PIM packets sent upstream SHOULD be the 1089 address of a PIM downstream neighbor in the corresponding join/prune 1090 state. The address picked MUST NOT be the upstream neighbor field to 1091 be encoded in the packet. The layer 2 encapsulation for the selected 1092 source IP address MUST be the encapsulation recorded in the PIM 1093 Neighbor database for that IP address. 1095 2.11. Directly Connected Multicast Source 1097 PIM snooping/relay/proxying could be enabled on a LAN that connects a 1098 multicast source and a PIM First Hop Router (FHR). As the FHR will 1099 not send any downstream Join/Prune messages we will not be able to 1100 establish any forwarding states for that source. Therefore, if there 1101 is a source in the CE network that connects directly into the VPLS 1102 instance, then multicast traffic from that source MUST be sent to all 1103 PIM routers on the VPLS instance in addition to the IGMP receivers in 1104 the VPLS. If there is already (S,G) or (*,G) snooping state that is 1105 formed on any PE, this will not happen per the current forwarding 1106 rules and guidelines. So, in order to determine if traffic needs to 1107 be flooded to all routers, a PE must be able to determine if the 1108 traffic came from a host on that LAN. There are three ways to 1109 address this problem: 1111 o The PE would have to do IPv4 ARP snooping and/or IPv6 Neighbor 1112 Discovery snooping, to determine if a source is directly 1113 connected. 1115 o Another option is to have configuration on all PEs to say there 1116 are CE sources that are directly connected to the VPLS instance 1117 and disallow snooping for the groups for which the source is going 1118 to send traffic. This way traffic from that source to those 1119 groups will always be flooded within the provider network. 1121 o A third option is to require that sources of CE multicast traffic 1122 must be behind a router. 1124 This document recommends the third option - sources traffic must be 1125 behind a router. 1127 2.12. Data Forwarding Rules 1129 First we define the rules that are common to PIM-SM and PIM-DM PEs. 1130 Forwarding rules for each protocol type is specified in the sub- 1131 sections. 1133 If there is no matching forwarding state, then the PE SHOULD discard 1134 the packet, i.e., the UserDefinedPortList below SHOULD be empty. 1136 The following general rules MUST be followed when forwarding 1137 multicast traffic in a VPLS: 1139 o Traffic arriving on a port MUST NOT be forwarded back onto the 1140 same port. 1142 o Due to VPLS Split-Horizon rules, traffic ingressing on a PW MUST 1143 NOT be forwarded to any other PW. 1145 2.12.1. PIM-SM Data Forwarding Rules 1147 Per the rules in RFC 7761 [PIM-SM] and per the additional rules 1148 specified in this document, 1150 OutgoingPortList(*,G) = immediate_olist(*,G) (+) 1151 UpstreamPorts(*,G) (+) 1152 Port(PimDR) 1154 OutgoingPortList(S,G) = inherited_olist(S,G) (+) 1155 UpstreamPorts(S,G) (+) 1156 (UpstreamPorts(*,G) (-) 1157 UpstreamPorts(S,G,rpt)) (+) 1158 Port(PimDR) 1160 RFC 7761 [PIM-SM] specifies how immediate_olist(*,G) and 1161 inherited_olist(S,G) are built. PimDR is the IP address of the PIM 1162 DR in the VPLS. 1164 The PIM-SM snooping forwarding rules are defined below in pseudocode: 1166 BEGIN 1167 iif is the incoming port of the multicast packet. 1168 S is the Source IP Address of the multicast packet. 1169 G is the Destination IP Address of the multicast packet. 1171 If there is (S,G) state on the PE 1172 Then 1173 OutgoingPortList = OutgoingPortList(S,G) 1174 Else if there is (*,G) state on the PE 1175 Then 1176 OutgoingPortList = OutgoingPortList(*,G) 1177 Else 1178 OutgoingPortList = UserDefinedPortList 1179 Endif 1181 If iif is an AC 1182 Then 1183 OutgoingPortList = OutgoingPortList (-) iif 1184 Else 1185 ## iif is a PW 1186 OutgoingPortList = OutgoingPortList (-) PWPorts 1187 Endif 1189 Forward the packet to OutgoingPortList. 1190 END 1192 First if there is (S,G) state on the PE, then the set of outgoing 1193 ports is OutgoingPortList(S,G). 1195 Otherwise if there is (*,G) state on the PE, the set of outgoing 1196 ports is OutgoingPortList(*,G). 1198 The packet is forwarded to the selected set of outgoing ports while 1199 observing the general rules above in Section 2.12 1201 2.12.2. PIM-DM Data Forwarding Rules 1203 The PIM-DM snooping data forwarding rules are defined below in 1204 pseudocode: 1206 BEGIN 1207 iif is the incoming port of the multicast packet. 1208 S is the Source IP Address of the multicast packet. 1209 G is the Destination IP Address of the multicast packet. 1211 If there is (S,G) state on the PE 1212 Then 1213 OutgoingPortList = olist(S,G) 1214 Else 1215 OutgoingPortList = UserDefinedPortList 1216 Endif 1218 If iif is an AC 1219 Then 1220 OutgoingPortList = OutgoingPortList (-) iif 1221 Else 1222 ## iif is a PW 1223 OutgoingPortList = OutgoingPortList (-) PWPorts 1224 Endif 1226 Forward the packet to OutgoingPortList. 1227 END 1229 If there is forwarding state for (S,G), then forward the packet to 1230 olist(S,G) while observing the general rules above in section 1231 Section 2.12 1233 RFC 3973 [PIM-DM] specifies how olist(S,G) is constructed. 1235 3. IANA Considerations 1237 This document makes no request of IANA. 1239 Note to RFC Editor: this section may be removed on publication as an 1240 RFC. 1242 4. Security Considerations 1244 Security considerations provided in VPLS solution documents (i.e., 1245 RFC 4762 [VPLS-LDP] and RFC 4761 [VPLS-BGP]) apply to this document 1246 as well. 1248 5. Contributors 1250 Yetik Serbest, Suresh Boddapati co-authored earlier versions. 1252 Karl (Xiangrong) Cai and Princy Elizabeth made significant 1253 contributions to bring the specification to its current state, 1254 especially in the area of Join forwarding rules. 1256 6. Acknowledgements 1258 Many members of the former L2VPN and PIM working groups have 1259 contributed to and provided valuable comments and feedback to this 1260 document, including Vach Kompella, Shane Amante, Sunil Khandekar, Rob 1261 Nath, Marc Lassere, Yuji Kamite, Yiqun Cai, Ali Sajassi, Jozef Raets, 1262 Himanshu Shah (Ciena), Himanshu Shah (Alcatel-Lucent). 1264 7. References 1266 7.1. Normative References 1268 [BIDIR-PIM] 1269 Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, 1270 "Bidirectional Protocol Independent Multicast (BIDIR- 1271 PIM)", RFC 5015, 2007. 1273 [JOIN-ATTR] 1274 Boers, A., Wijnands, I., and E. Rosen, "The Protocol 1275 Independent Multicast (PIM) Join Attribute Format", 1276 RFC 5384, 2008. 1278 [PIM-DM] Adams, A., Nicholas, J., and W. Siadak, "Protocol 1279 Independent Multicast Version 2 - Dense Mode 1280 Specification", RFC 3973, 2005. 1282 [PIM-SM] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 1283 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 1284 Multicast- Sparse Mode (PIM-SM): Protocol Specification 1285 (Revised)", RFC 7761, 2016. 1287 [PIM-SSM] Holbrook, H. and B. Cain, "Source-Specific Multicast for 1288 IP", RFC 4607, 2006. 1290 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1291 Requirement Levels", BCP 14, RFC 2119, 1997. 1293 [RPF-VECTOR] 1294 Wijnands, I., Boers, A., and E. Rosen, "The Reverse Path 1295 Forwarding (RPF) Vector TLV", RFC 5496, 2009. 1297 7.2. Informative References 1299 [IGMP-SNOOP] 1300 Christensen, M., Kimball, K., and F. Solensky, 1301 "Considerations for IGMP and MLD snooping PEs", RFC 4541, 1302 2006. 1304 [VPLS-BGP] 1305 Kompella, K. and Y. Rekhter, "Virtual Private LAN Service 1306 using BGP for Auto-Discovery and Signaling", RFC 4761, 1307 2007. 1309 [VPLS-LDP] 1310 Lasserre, M. and V. Kompella, "Virtual Private LAN 1311 Services using LDP Signaling", RFC 4762, 2007. 1313 [VPLS-MCAST] 1314 Aggarwal, R., Kamite, Y., Fang, L., and Y. Rekhter, 1315 "Multicast in Virtual Private LAN Servoce (VPLS)", 1316 RFC 7117, 2014. 1318 [VPLS-MCAST-REQ] 1319 Kamite, Y., Wada, Y., Serbest, Y., Morin, T., and L. Fang, 1320 "Requirements for Multicast Support in Virtual Private LAN 1321 Services", RFC 5501, 2009. 1323 Appendix A. BIDIR-PIM Considerations 1325 This section describes some guidelines that may be used to preserve 1326 BIDIR-PIM functionality in combination with PIM snooping. 1328 In order to preserve BIDIR-PIM PIM snooping routers need to set up 1329 forwarding states so that : 1331 o on the RPL all traffic is forwarded to all Port(N) 1333 o on any other interface traffic is always forwarded to the DF 1335 The information needed to setup these states may be obtained by : 1337 o determining the mapping between group(range) and RP 1339 o snooping and storing DF election information 1341 o determining where the RPL is, this could be achieved by static 1342 configuration, or by combining the information mentioned in 1343 previous bullets. 1345 A.1. BIDIR-PIM Data Forwarding Rules 1347 The BIDIR-PIM snooping forwarding rules are defined below in 1348 pseudocode: 1350 BEGIN 1351 iif is the incoming port of the multicast packet. 1352 G is the Destination IP Address of the multicast packet. 1354 If there is forwarding state for G 1355 Then 1356 OutgoingPortList = olist(G) 1357 Else 1358 OutgoingPortList = UserDefinedPortList 1359 Endif 1361 If iif is an AC 1362 Then 1363 OutgoingPortList = OutgoingPortList (-) iif 1364 Else 1365 ## iif is a PW 1366 OutgoingPortList = OutgoingPortList (-) PWPorts 1367 Endif 1369 Forward the packet to OutgoingPortList. 1370 END 1372 If there is forwarding state for G, then forward the packet to 1373 olist(G) while observing the general rules above in Section 2.12 1375 RFC 5015 [BIDIR-PIM] specifies how olist(G) is constructed. 1377 Appendix B. Example Network Scenario 1379 Let us consider the scenario in Figure 3. 1381 Figure 3: An Example Network for Triggering Assert 1383 +------+ AC3 +------+ 1384 | PE2 |-----| CE3 | 1385 /| | +------+ 1386 / +------+ | 1387 / | | 1388 / | | 1389 /PW12 | | 1390 / | /---\ 1391 / |PW23 | S | 1392 / | \---/ 1393 / | | 1394 / | | 1395 / | | 1396 +------+ / +------+ | 1397 +------+ | PE1 |/ PW13 | PE3 | +------+ 1398 | CE1 |-----| |-------------| |-----| CE4 | 1399 +------+ AC1 +------+ +------+ AC4 +------+ 1400 | 1401 |AC2 1402 +------+ 1403 | CE2 | 1404 +------+ 1406 In the examples below, JT(Port,S,G,N) is the downstream Join Expiry 1407 Timer on the specified Port for the (S,G) with upstream neighbor N. 1409 B.1. PIM Snooping Example 1411 In the network depicted in Figure 3, S is the source of a multicast 1412 stream (S,G). CE1 and CE2 both have two ECMP routes to reach the 1413 source. 1415 1. CE1 Sends a Join(S,G) with Upstream Neighbor(S,G) = CE3. 1416 2. PE1 snoops on the Join(S,G) and builds forwarding states since it 1417 is received on an AC. It also floods the Join(S,G) in the VPLS. 1418 PE2 snoops on the Join(S,G) and builds forwarding state since the 1419 Join(S,G)is targeting a neighbor residing on an AC. PE3 does not 1420 create forwarding state for (S,G) because this is a PW-only join 1421 and there is neither existing (*,G) state with an AC in 1422 UpstreamPorts(*,G) nor an existing (S,G) state with an AC in 1423 UpstreamPorts(S,G). Both PE2 and PE3 will also flood the 1424 Join(S,G) in the VPLS 1426 The resulting states at the PEs is as follows: 1428 At PE1: 1430 JT(AC1,S,G,CE3) = JP_HoldTime 1431 UpstreamNeighbors(S,G) = { CE3 } 1432 UpstreamPorts(S,G) = { PW12 } 1433 OutgoingPortList(S,G) = { AC1, PW12 } 1435 At PE2: 1436 JT(PW12,S,G,CE3) = JP_HoldTime 1437 UpstreamNeighbors(S,G) = { CE3 } 1438 UpstreamPorts(S,G) = { AC3 } 1439 OutgoingPortList(S,G) = { PW12, AC3 } 1441 At PE3: 1442 No (S,G) state 1444 3. The multicast stream (S,G) flows along 1445 CE3 -> PE2 -> PE1 -> CE1 1446 4. Now CE2 sends a Join(S,G) with Upstream Neighbor(S,G) = CE4. 1447 5. All PEs snoop on the Join(S,G), build forwarding state and 1448 flood the Join(S,G) in the VPLS. Note that for PE2 even though 1449 this is a PW-only join, forwarding state is built on this 1450 Join(S,G) since PE2 has existing (S,G) state with an AC in 1451 UpstreamPorts(S,G) 1453 The resulting states at the PEs: 1455 At PE1: 1456 JT(AC1,S,G,CE3) = active 1457 JT(AC2,S,G,CE4) = JP_HoldTime 1458 UpstreamNeighbors(S,G) = { CE3, CE4 } 1459 UpstreamPorts(S,G) = { PW12, PW13 } 1460 OutgoingPortList(S,G) = { AC1, PW12, AC2, PW13 } 1462 At PE2: 1463 JT(PW12,S,G,CE4) = JP_HoldTime 1464 JT(PW12,S,G,CE3) = active 1465 UpstreamNeighbors(S,G) = { CE3, CE4 } 1466 UpstreamPorts(S,G) = { AC3, PW23 } 1467 OutgoingPortList(S,G) = { PW12, AC3, PW23 } 1469 At PE3: 1470 JT(PW13,S,G,CE4) = JP_HoldTime 1471 UpstreamNeighbors(S,G) = { CE4 } 1472 UpstreamPorts(S,G) = { AC4 } 1473 OutgoingPortList(S,G) = { PW13, AC4 } 1475 6. The multicast stream (S,G) flows into the VPLS from the two CEs 1476 CE3 and CE4. PE2 forwards the stream received from CE3 to PW23 1477 and PE3 forwards the stream to AC4. This facilitates the CE 1478 routers to trigger assert election. Let us say CE3 becomes the 1479 assert winner. 1480 7. CE3 sends an Assert message to the VPLS. The PEs flood the 1481 Assert message without examining it. 1482 8. CE4 stops sending the multicast stream to the VPLS. 1483 9. CE2 notices an RPF change due to Assert and sends a Prune(S,G) 1484 with Upstream Neighbor = CE4. CE2 also sends a Join(S,G) with 1485 Upstream Neighbor = CE3. 1486 10. All the PEs start a prune-pend timer on the ports on which 1487 they received the Prune(S,G). When the prune-pend timer expires, 1488 all PEs will remove the downstream (S,G,CE4) states. 1490 Resulting states at the PEs: 1492 At PE1: 1493 JT(AC1,S,G,CE3) = active 1494 UpstreamNeighbors(S,G) = { CE3 } 1495 UpstreamPorts(S,G) = { PW12 } 1496 OutgoingPortList(S,G) = { AC1, AC2, PW12 } 1498 At PE2: 1499 JT(PW12,S,G,CE3) = active 1500 UpstreamNeighbors(S,G) = { CE3 } 1501 UpstreamPorts(S,G) = { AC3 } 1502 OutgoingPortList(S,G) = { PW12, AC3 } 1504 At PE3: 1505 JT(PW13,S,G,CE3) = JP_HoldTime 1506 UpstreamNeighbors(S,G) = { CE3 } 1507 UpstreamPorts(S,G) = { PW23 } 1508 OutgoingPortList(S,G) = { PW13, PW23 } 1510 Note that at this point at PE3, since there is no AC in 1511 OutgoingPortList(S,G) and no (*,G) or (S,G) state with an AC in 1512 UpstreamPorts(*,G) or UpstreamPorts(S,G) respectively, the 1513 existing (S,G) state at PE3 can also be removed. So finally: 1515 At PE3: 1516 No (S,G) state 1518 Note that at the end of the assert election, there should be no 1519 duplicate traffic forwarded downstream and traffic should flow only 1520 on the desired path. Also note that there are no unnecessary (S,G) 1521 states on PE3 after the assert election. 1523 B.2. PIM Proxy Example with (S,G) / (*,G) interaction 1525 In the same network, let us assume CE4 is the Upstream Neighbor 1526 towards the RP for G. 1528 JPST(S,G,N) is the JP sending timer for the (S,G) with upstream 1529 neighbor N. 1531 1. CE1 Sends a Join(S,G) with Upstream Neighbor(S,G) = CE3. 1533 2. PE1 consumes the Join(S,G) and builds forwarding state since the 1534 Join(S,G) is received on an AC. 1536 PE2 consumes the Join(S,G) and builds forwarding state since the 1537 Join(S,G) is targeting a neighbor residing on an AC. 1539 PE3 consumes the Join(S,G) but does not create forwarding state 1540 for (S,G) since this is a PW-only join and there is neither 1541 existing (*,G) state with an AC in UpstreamPorts(*,G) nor an 1542 existing (S,G) state with an AC in UpstreamPorts(S,G) 1544 The resulting states at the PEs is as follows: 1546 PE1 states: 1547 JT(AC1,S,G,CE3) = JP_HoldTime 1548 JPST(S,G,CE3) = t_periodic 1549 UpstreamNeighbors(S,G) = { CE3 } 1550 UpstreamPorts(S,G) = { PW12 } 1551 OutgoingPortList(S,G) = { AC1, PW12 } 1553 PE2 states: 1554 JT(PW12,S,G,CE3) = JP_HoldTime 1555 JPST(S,G,CE3) = t_periodic 1556 UpstreamNeighbors(S,G) = { CE3 } 1557 UpstreamPorts(S,G) = { AC3 } 1558 OutgoingPortList(S,G) = { PW12, AC3 } 1560 PE3 states: 1561 No (S,G) state 1563 Joins are triggered as follows: 1564 PE1 triggers a Join(S,G) targeting CE3. Since the Join(S,G) was 1565 received on an AC and is targeting a neighbor that is residing 1566 across a PW, the triggered Join(S,G) is sent on all PWs. 1568 PE2 triggers a Join(S,G) targeting CE3. Since the Joins(S,G) is 1569 targeting a neighbor residing on an AC, it only sends the join 1570 on AC3. 1572 PE3 ignores the Join(S,G) since this is a PW-only join and there 1573 is neither existing (*,G) state with an AC in UpstreamPorts(*,G) 1574 nor an existing (S,G) state with an AC in UpstreamPorts(S,G) 1576 3. The multicast stream (S,G) flows along CE3 -> PE2 -> PE1 -> CE1. 1578 4. Now let us say CE2 sends a Join(*,G) with 1579 UpstreamNeighbor(*,G) = CE4. 1581 5. PE1 consumes the Join(*,G) and builds forwarding state since the 1582 Join(*,G) is received on an AC. 1584 PE2 consumes the Join(*,G) and though this is a PW-only join, 1585 forwarding state is build on this Join(*,G) since PE2 has 1586 existing (S,G) state with an AC in UpstreamPorts(S,G). 1587 However, since this is a PW-only join, PE2 only adds the PW 1588 towards PE3 (PW23) into UpstreamPorts(*,G) and hence into 1589 OutgoingPortList(*,G). It does not add the PW towards 1590 PE1 (PW12) into OutgoingPortsList(*,G) 1592 PE3 consumes the Join(*,G) and builds forwarding state since 1593 the Join(*,G) is targeting a neighbor residing on an AC. 1595 The resulting states at the PEs is as follows: 1597 PE1 states: 1598 JT(AC1,*,G,CE4) = JP_HoldTime 1599 JPST(*,G,CE4) = t_periodic 1600 UpstreamNeighbors(*,G) = { CE4 } 1601 UpstreamPorts(*,G) = { PW13 } 1602 OutgoingPortList(*,G) = { AC2, PW13 } 1604 JT(AC1,S,G,CE3) = active 1605 JPST(S,G,CE3) = active 1606 UpstreamNeighbors(S,G) = { CE3 } 1607 UpstreamPorts(S,G) = { PW12 } 1608 OutgoingPortList(S,G) = { AC1, PW12, PW13 } 1610 PE2 states: 1611 JT(PW12,*,G,CE4) = JP_HoldTime 1612 UpstreamNeighbors(*,G) = { CE4 } 1613 UpstreamPorts(G) = { PW23 } 1614 OutgoingPortList(*,G) = { PW23 } 1616 JT(PW12,S,G,CE3) = active 1617 JPST(S,G,CE3) = active 1618 UpstreamNeighbors(S,G) = { CE3 } 1619 UpstreamPorts(S,G) = { AC3 } 1620 OutgoingPortList(S,G) = { PW12, AC3, PW23 } 1622 PE3 states: 1623 JT(PW13,*,G,CE4) = JP_HoldTime 1624 JPST(*,G,CE4) = t_periodic 1625 UpstreamNeighbors(*,G) = { CE4 } 1626 UpstreamPorts(*,G) = { AC4 } 1627 OutgoingPortList(*,G) = { PW13, AC4 } 1629 Joins are triggered as follows: 1630 PE1 triggers a Join(*,G) targeting CE4. Since the Join(*,G) was 1631 received on an AC and is targeting a neighbor that is residing 1632 across a PW, the triggered Join(S,G) is sent on all PWs. 1634 PE2 does not trigger a Join(*,G) based on this join since this 1635 is a PW-only join. 1637 PE3 triggers a Join(*,G) targeting CE4. Since the Join(*,G) is 1638 targeting a neighbor residing on an AC, it only sends the join 1639 on AC4. 1641 6. In case traffic is not flowing yet (i.e. step 3 is delayed to 1642 come after step 6) and in the interim JPST(S,G,CE3) on PE1 1643 expires, causing it to send a refresh Join(S,G) targeting CE3, 1644 since the refresh Join(S,G) is targeting a neighbor that is 1645 residing across a PW, the refresh Join(S,G) is sent on all PWs. 1647 7. Note that PE1 refreshes its JT timer based on reception of 1648 refresh joins from CE1 and CE2 1650 PE2 consumes the Join(S,G) and refreshes the JT(PW12,S,G,CE3) 1651 timer. 1653 PE3 consumes the Join(S,G). It also builds forwarding state on 1654 this Join(S,G), even though this is a PW-only join, since now 1655 PE2 has existing (*,G) state with an AC in UpstreamPorts(*,G). 1656 However, since this is a PW-only join, PE3 only adds the PW 1657 towards PE2 (PW23) into UpstreamPorts(S,G) and hence into 1658 OutgoingPortList(S,G). It does not add the PW towards 1659 PE1 (PW13) into OutgoingPortList(S,G). 1661 PE3 States: 1662 JT(PW13,*,G,CE4) = active 1663 JPST(S,G,CE4) = active 1664 UpstreamNeighbors(*,G) = { CE4 } 1665 UpstreamPorts(*,G) = { AC4 } 1666 OutgoingPortList(*,G) = { PW13, AC4 } 1667 JT(PW13,S,G,CE3) = JP_HoldTime 1668 UpstreamNeighbors(*,G) = { CE3 } 1669 UpstreamPorts(*,G) = { PW23 } 1670 OutgoingPortList(*,G) = { PW13, AC4, PW23 } 1672 Joins are triggered as follows: 1673 PE2 already has (S,G) state, so it does not trigger a Join(S,G) 1674 based on reception of this refresh join. 1676 PE3 does not trigger a Join(S,G) based on this join since this 1677 is a PW-only join. 1679 8. The multicast stream (S,G) flows into the VPLS from the two 1680 CEs, CE3 and CE4. PE2 forwards the stream received from CE3 to 1681 PW12 and PW23. At the same time PE3 forwards the stream 1682 received from CE4 to PW13 and PW23. 1684 The stream received over PW12 and PW13 is forwarded by PE1 to 1685 AC1 and AC2. 1687 The stream received by PE3 over PW23 is forwarded to AC4. The 1688 stream received by PE2 over PW23 is forwarded to AC3. Either of 1689 these facilitates the CE routers to trigger assert election. 1691 9. CE3 and/or CE4 send(s) Assert message(s) to the VPLS. The PEs 1692 flood the Assert message(s) without examining it. 1694 10. CE3 becomes the (S,G) assert winner and CE4 stops sending the 1695 multicast stream to the VPLS. 1697 11. CE2 notices an RPF change due to Assert and sends a 1698 Prune(S,G,rpt) with Upstream Neighbor = CE4. 1700 12. PE1 consumes the Prune(S,G,rpt) and since 1701 PruneDesired(S,G,Rpt,CE4) is TRUE, it triggers a Prune(S,G,rpt) 1702 to CE4. Since the prune is targeting a neighbor across a PW, it 1703 is sent on all PWs. 1705 PE2 consumes the Prune(S,G,rpt) and does not trigger any prune 1706 based on this Prune(S,G,rpt) since this was a PW-only prune. 1708 PE3 consumes the Prune(S,G,rpt) and since 1709 PruneDesired(S,G,rpt,CE4) is TRUE it sends the Prune(S,G,rpt) 1710 on AC4. 1712 PE1 states: 1713 JT(AC2,*,G,CE4) = active 1714 JPST(*,G,CE4) = active 1715 UpstreamNeighbors(*,G) = { CE4 } 1716 UpstreamPorts(*,G) = { PW13 } 1717 OutgoingPortList(*,G) = { AC2, PW13 } 1719 JT(AC2,S,G,CE4) = JP_Holdtime with FLAG sgrpt prune 1720 JPST(S,G,CE4) = none, since this is sent along 1721 with the Join(*,G) to CE4 based 1722 on JPST(*,G,CE4) expiry 1723 UpstreamPorts(S,G,rpt) = { PW13 } 1724 UpstreamNeighbors(S,G,rpt) = { CE4 } 1726 JT(AC1,S,G,CE3) = active 1727 JPST(S,G,CE3) = active 1728 UpstreamNeighbors(S,G) = { CE3 } 1729 UpstreamPorts(S,G) = { PW12 } 1730 OutgoingPortList(S,G) = { AC1, PW12, AC2 } 1732 At PE2: 1733 JT(PW12,*,G,CE4) = active 1734 UpstreamNeighbors(*,G) = { CE4 } 1735 UpstreamPorts(*,G) = { PW23 } 1736 OutgoingPortList(*,G) = { PW23 } 1738 JT(PW12,S,G,CE4) = JP_Holdtime with FLAG sgrpt prune 1739 JPST(S,G,CE4) = none, since this was created 1740 off a PW-only prune 1741 UpstreamPorts(S,G,rpt) = { PW23 } 1742 UpstreamNeighbors(S,G,rpt) = { CE4 } 1744 JT(PW12,S,G,CE3) = active 1745 JPST(S,G,CE3) = active 1746 UpstreamNeighbors(S,G) = { CE3 } 1747 UpstreamPorts(S,G) = { AC3 } 1748 OutgoingPortList(*,G) = { PW12, AC3 } 1750 At PE3: 1751 JT(PW13,*,G,CE4) = active 1752 JPST(*,G,CE4) = active 1753 UpstreamNeighbors(*,G) = { CE4 } 1754 UpstreamPorts(*,G) = { AC4 } 1755 OutgoingPortList(*,G) = { PW13, AC4 } 1757 JT(PW13,S,G,CE4) = JP_Holdtime with S,G,rpt prune 1758 flag 1759 JPST(S,G,CE4) = none, since this is sent along 1760 with the Join(*,G) to CE4 based 1761 on JPST(*,G,CE4) expiry 1762 UpstreamNeighbors(S,G,rpt) = { CE4 } 1763 UpstreamPorts(S,G,rpt) = { AC4 } 1765 JT(PW13,S,G,CE3) = active 1766 JPST(S,G,CE3) = none, since this state is 1767 created by PW-only join 1768 UpstreamNeighbors(S,G) = { CE3 } 1769 UpstreamPorts(S,G) = { PW23 } 1770 OutgoingPortList(S,G) = { PW23 } 1772 Even in this example, at the end of the (S,G) / (*,G) assert 1773 election, there should be no duplicate traffic forwarded downstream 1774 and traffic should flow only to the desired CEs. 1776 However, the reason we don't have duplicate traffic is because one of 1777 the CEs stops sending traffic due to assert, not because we don't 1778 have any forwarding state in the PEs to do this forwarding. 1780 Authors' Addresses 1782 Olivier Dornon 1783 Nokia 1784 50 Copernicuslaan 1785 Antwerp, B2018 1787 Email: olivier.dornon@nokia.com 1789 Jayant Kotalwar 1790 Nokia 1791 701 East Middlefield Rd. 1792 Mountain View, CA 94043 1794 Email: jayant.kotalwar@nokia.com 1796 Venu Hemige 1798 Email: vhemige@gmail.com 1800 Ray Qiu 1801 mistnet.io 1803 Email: ray@mistnet.io 1804 Jeffrey Zhang 1805 Juniper Networks, Inc. 1806 10 Technology Park Drive 1807 Westford, MA 01886 1809 Email: zzhang@juniper.net