IETF 124 PIM WG Meeting Q&A Notes 1. WG Status / Agenda (Chairs) Chairs: Noted a new Note Well slide. Confirmed the agenda structure, where the two DR drafts would be presented together for joint discussion. WG Status: Briefly reviewed drafts: RFC1112bis update had a WG Last Call; three drafts in the RFC editor queue; MPMLD proxy PFM enhancements and ECMP drafts being discussed/not discussed. All address assignment drafts are moving forward. 2. DR Improvement (Sandy) Speaker (Sandy): Summarized the next steps: Propose moving the draft to WG Last Call. Chair: Agreed that the presentation and discussion seem sufficient to move forward. No further technical discussion on the floor. 3. BDR - Bidirectional Designated Router (Mankamana) Prakash: Expressed concern about the complexity of maintaining separate lists (DR list and BDR list) and the added state information for the simple benefit described. Mankamana: Confirmed the draft is specifically for PIM-SSM and intends to simplify the design by leveraging the BDR for Join/Prune messages, avoiding complex DR election timeout scenarios. Mike: Asked for clarification on whether this mechanism is only for PIM-SSM or if it could be applied to PIM-SM as well. Mankamana: Confirmed the current focus is PIM-SSM. Extending it to PIM-SM would require significant additional work on RP-related mechanisms, which is out of scope for now. Peter (Cisco): Questioned the sticky DR solution mentioned by Mankamana (using max priority): What prevents multiple routers from announcing max priority, and how is the DR picked then? Mankamana: Explained that the initial DR election uses configured priority; once a router becomes DR, it starts announcing max DR priority (a mutex) to ensure stickiness. Sandy: Suggested that if two different BDR/sticky solutions exist, the WG should choose only one best one. Mankamana: Stated that stickiness and BDR are orthogonal and could be separate operator choices based on deployment. Stig (as individual): Suggested the number one priority should be finding one or two sticky DR solutions, and then considering backup DR on top of that. Chair: Requested a clear call for adoption on the mailing list to gauge WG interest. Action Item: Mankamana to send a call for adoption to the PIM WG mailing list. 4. Lessons Learned (Mike) Dino: Suggested adding a note on deployments where the RP is placed on the first hop LAN to achieve shared tree functionality that mimics shortest path, balancing state reduction and optimal path. Mike agreed. Mike: Stated that the lesson learned regarding SPT/RPT switchover thresholds is that often, complexity (non-zero/non-infinity thresholds) was added where the default (immediate switchover) was sufficient. Toerless (on state): Commented that the worry about state (memory capacity) was a premature optimization; the true state impact is often network performance/convergence time under failure. David: Asked if the forwarding plane uses $\*$,G or S,G even if the control plane only has $\*$,G join. (Discussion confirmed S,G is used in the forwarding plane.) Mike: Asked if anything should be added about IGMP snooping. Toerless: Stated the lesson learned on IGMP snooping is that without a standard approach (before RFC 4541), different implementations led to interoperability issues and many bugs. Prasad (Cisco): Suggested adding MLDD (IPv6 equivalent) and MSDP/Anycast RP (IPv6 equivalent) to the document. Mike agreed. Prasad (Cisco): Also suggested discussing LISP, and offered to provide a "lesson learned" on LISP interaction. Prasad (Cisco): Stated there are certain use cases where a non-zero threshold for RPT to SPT switchover is actually used, contrary to the draft's current statement. Mankamana: Pointed out that RFC 4541 is the informational draft that defines IGMP snooping and MLDD snooping. Mike: Clarified the focus should be on PIM protocol lessons learned, not general MBONE or deployment choices. 5. PIM PFM Enhancements (Stig) Sandy: Asked if the draft updates the PFM RFC, and if the type should be changed from Experimental to Standard since it is implemented. Stig: Clarified the draft adds to the RFC with a new TLV format and does not need to be an update. Agreed that once implementation matures (Cisco and others are shipping it), it could move to Proposed Standard. Toerless: Commented that the draft is architecturally great, as it is a more efficient way to move multicast information (like active sources) than abusing IGPs like OSPF, as it avoids storing hop-by-hop state. Chair: Stated the working group appears to be in favor of starting the work. Action Item: Stig to start the Working Group Last Call, possibly next week. 6. RFC1112bis Update (Toerless) Dino: Asked if the IGMP issue Phil K. had about one year ago, regarding lack of clarity in 1112/successors for IoT implementation, was resolved. Toerless: Did not recall the specific comment but offered to look it up. Toerless: Summarized the next step is to initiate directorate reviews (INT, TSV, SEC) before closing WG Last Call, as the document is essentially stable but the security/privacy sections (now 6 pages) need external non-multicast review. Action Item: Toerless to send an email to the Chairs with details for the review request form. Chairs to initiate the directorate review. 7. Multipath (Hitoshi) Stig: Questioned the document status: Since the static configuration draft has implementation, it could be Experimental, but since it involves no protocol changes, Informational might be better. Hitoshi: Confirmed the implementation is for the static draft. The dynamic draft (protocol extension) should be Proposed Standard. The authors decided to keep the static and dynamic drafts separate. Stig: Agreed that Informational is often better for non-protocol, local implementation advice, but is open. Hitoshi: Announced two remaining todos: define a default active interval for detecting an inactive upstream interface, and address security threats from potential loss attacks. 8. BIER in AIDC (Jeffrey) Markus: Asked if using a single local group address (for simpler receiver implementation) goes against the need for different group addresses for different flows, which have different combinations of destinations. Jeffrey: Clarified that if the source GPU cannot handle Beer encapsulation, then different group addresses are needed per flow, and the first-hop router must handle the Beer header. If the source GPU can handle encapsulation, a single common multicast address can be used. Toerless: Asked if the solution is limited to GPUs within a single rack versus across servers, and asked about the source knowing all receivers (is this from a management plane/MEC layer?). Jeffrey: Confirmed it can work across servers if BFR functionality is in the hosts. Stated that the source is assumed to know the receiver IDs (a common pattern in AI/ML). Also noted that the receiver signaling (IGMP) is removed because the source is authoritative about the receivers. Jeffrey: Confirmed that the IGMP extension part (Receiver Proxy Report) needs to be standardized in PIM, but the core Beer procedure is informational and has no new protocol elements. Chair: Agreed to have the IGMP extension defined in PIM, pending BIER WG feedback on the overall solution. 9. PIM MT - Multicast Tags / Flex-Algo (Sandy) Yugon (on Soft Flex Algo): Asked why multicast needs the new soft flex algorithm approach rather than the existing standard Flex-Algo participation. Peter (Cisco): Clarified that a data plane must be picked for Flex-Algo (e.g., SRv6, SR-MPLS). The soft data plane is a virtual option for networks where none of the existing SR data planes are available, allowing them to still utilize Flex-Algo paths for multicast. Chair: Noted that there was some support and some opposition to adoption, and requested a poll on the list. Action Item: Sandy to look for the adoption call on the mailing list. 10. PIM Join Attributes for LISP Environments (Prasad) Prasad: Summarized the work, noting that the two documents were being merged into one and that the work is a key building block for the LISP multicast standard track RFC 6831. Requested adoption to move the draft to standards track. Chair: Confirmed the request for adoption. Action Item: Chair to ask the list for adoption. 11. Mcast over SRv6 (Mankamana) Toerless: Questioned why this is not being proposed to MBONED, as it looks like deployment choices rather than new protocol features. Mankamana: Stated that the focus is on PIMv6 usage and how to deploy it over a V6/SRv6 core, and that this document helps operators specifically looking for a V6 solution. Neil (DT): Stated the document is helpful for operators in the midst of SRv6 core deployment planning who need to evaluate different options for multicast. Lenny (Juniper, MBONED Co-chair): Asked about overlap with a similar draft in MBONED ("non-source routed multicast in source routed networks"). Mankamana said he would look into that. Chair: Noted the adoption request and conducted a quick poll, confirming they would also ask on the list. Action Item: Chair to ask the list for adoption.