WG Drafts Overview - Stig Alvaro: pim-yang model is in the RFC Editors queue. A very late bug was found in the bfd model that pim imports and which effects several protocols. But bfd model is already published as an rfc and trying to figure out how to fix it. The OPS AD (Rob Wilton) is talking to the yang doctors. May republish BFD yang model and fast track it. And have the other docs published as they are with no changes. Mike: The wg agreed to adopt both pim-bdr-improvement and pim-bdr as separate drafts. The authors are driving these similar drafts with no assurance of wg progression especially if they make no draft progress. Stig: We still have time to determine what is best whether one or two solutions or a new merged draft. Mike: We have consensus to adopt the p2mp-policy-ping draft but we did received a comment to specify whether this is focused on SR-MPLS data plane and/or SRv6 data plane. Also the pim chairs should ping the mpls chairs to make sure they realize we are using one of their code points. Hooman: We should start with SR-MPLS and will update the draft. Mike: regarding charter update. We agreed with spring chairs over last year or two that we are doing SR P2MP work. There are other WG's working on p2mp related work including BESS and IDR and they will likely keep their work but there had been a discussion on pim taking on that work as well to consolidate into one wg. Stig and I will do our best to help this wg be aware of p2mp work being done in other wg's so we can review. We removed management and yang from our charter because the yang work is basically done. We added one bullet: Develop P2MP protocols. This includes SR/SRv6 P2MP work per agreement with the SPRING WG. This may alos require other P2MP protocols as requested from other Working Groups. Alvaro: The charter looks fine in general. But will need to look at the other work in other WG's. We need better coordination between working groups and not just with multicast. Won't want to progress the charter update until we agree on what will happen with the related p2mp work happening in other wg's. Aijun: The SR based SR solution is different from the pim protocol so I recommend coordinate within the side meeting and all SR related work should be in a new wg. Alvaro: The side meeting is not an official meeting. We need to discuss in the WG and look at charters and if there is work that hasn't been discussed in any wg then sure we can discuss that. If work overlaps we can do it. This wg is called PIM protocols for ip multicast not protocol independent multicast. Not that everything that has to do with multicast needs to be done here. Mike: multicast side meetings are a great way to brainstorm on things like this. Jake Holland had a great one at the last one. draft-ietf-pim-jp-extensions-lisp - Stig Mike: do we need to add anything about lisp related work in our charter? Stig: The reason we are doing this in pim is that we have a pim join attribute in pim. There has been some multicast work in lisp that didn't involve pim. draft-ietf-pim-sr-p2mp-policy - Hooman draft-li-pim-igmp-mld-extension-source-management - Huanan Stig: plan to add more comments. More work to be done. Mike: last ietf you mentioned msnip was there ever a comparison between that and this? Stig: In both the source can notify that it wants to send multicast and for the router to respond to the source about interested receivers. But the motivation is different and several use cases not mentioned in the msnip. Aijun: Their aim is similar and we can coordinate with what msnip provided and will work on comments from Stig. Acee: The primary motivation would be credential validation of the source and you can tell the sources to stop sending when no receivers? Aijun: That is correct. Authenticate multicast sources. And feedback to sources. Stig: The main complexity is source discovery. Some dynamic mechanism. We can simplify discovery and not use data driven signaling. Acee: You could eliminate the RP and use SSM and not use ASM. Hitoshi: Why this draft wants to use igmp/mld for source discovery. it would help to clarify differences between msnip and this draft. But why do you need to extend igmp/mld. Also we already have SAP. We could extend SAP for source discovery. Aijun: I'm not familiar with SAP. We selected igmp/mld. Lenny: It seems like this idea of request to send feels like an old idea. I remember it being abandoned a long time ago and msnip didn't gain much traction but not sure why. Does anyone remember? Stig: I don't remember but the main challenge is deployment. Hard to get hosts upgraded. It could be useful in some special cases with cameras with ip support or something specialized. Host stacks are a big challenge. Aijun: We want to make multicast inbound in a controller manner so source should be authenticated. Source side is different then the receiver side so may be more acceptable. Mike: lets discuss more on the list. draft-hb-pim-light - Hooman Alvaro: You are defining a different type of interface. Can you name the draft to a pim light interface? Hooman: I have no problem calling it pim light interface. We need to think about logical interfaces or physical interfaces or bier. Mike: We need a shepherd for this draft since Stig and I are on the draft. Sandy agreed to shepherd. Advancing IGMPv3 & MLDv2 to Internet Standard - Anuj Stig: For the igmp/mld extension there is agreement that we don't need to make it an offical update of the igmp/mld rfc's. Also need to consider what text we want to incorporate from 4604 Anuj: We have identified what sections from 4604 we will incorporate. And do we move RFC's 1112, 2236, 2710 to historic? Stig: Would be good to send an email to the pim list to discuss. Send an email for each open issue.