WG Drafts Overview - Stig Mike - we are ready for wglc for draft-ietf-pim-assert-packing. Yisong - yes we want to request wglc. Stig - if anyone has concerns bring it up now or on the list. Stig - I reviewed the draft and it looks pretty good. I'll confirm my minor comment has been incorporated. Stig - Proposed new SR P2MP charter text. Mike - We've worked closely with spring wg chairs from the start. They don't have time for multicast and prefer we continue to do sr p2mp in pim. Add a sentence to the pim charter and make it formal. We will come to consensus in the pim wg on the charter text and run it by spring chairs. draft-ietf-pim-igmp-mld-proxy-yang - Hongji Zhao Stig - Did we do a yang doctor review yet? Hongji - yes, two months ago and addressed all comments. Mike - looks like we are ready for a wglc. speak up if you feel otherwise. draft-hb-p2mp-policy-ping - Hooman Bidgoli Jingrong - do you have the packet format for the p2mp pim policy. Is it using a udp port? Hooman - when it comes to the data path a p2mp policy is in part to p2mp ldp. we didn't choose any new procedures. Jingrong - question is about the pim data packet which may include encapsulate the pim echo reply in udp. Problem about what udp port and what ip address dest address used. you could use same as ldp pim etc. This should be checked. Hooman - yes definitely. Are you talking about the mtrace v2 udp port in linux traceroute? Jingrong - I'll follow up on list. Mike - the reason you are doing this is because the existing echo reply mechanisms for SR don't work for p2mp correct? Hooman - yes. When it comes to p2mp you need to have the procedure to fan out the echo request. Mike - you need to perform similar mods to other protocols so that's why you are presenting in other wg's? Hooman - yes. The procedures are close to mld or p2mp rsvp. the sr is unicast. if this was ingress replication we could have use sr procedures to to test the unicast paths. But if you want to go to the headend and send a single packet and have multiple replies the current procedures are not sufficient to make that happen. Mike - started a poll. 7 people in favor to support this draft. Stig - have you presented to spring? Hooman - have not presented in spring. Stig - we can check with spring chairs. Hooman - It's great pim is taking on p2mp do we still need spring blessing? Mike - After we recharter we won't need their blessing but will need to stay well coordinated with the chairs. Stig - if there is overlap its common to present in multiple wg's. Mike - what we typically do after our meetings is ping the spring chairs and let them know what we've been doing and extend that courtesy. draft-vgovindan-pim-jp-extensions-lisp - Stig Venaas Mike - There is already a multicast distribution tree specified in lisp, including defining PIM J/P attribute extensions to construct multicast distribution trees. So this document extends this to facilitate the construction of an underlay. Are you also proposing a mapping between underlay and overlay? Stig - In the underlay we send a join. What we do with the signaling, there is a pim join sending unicast from border routers. when we send the join, we also specify encapsulating in G-u1 or 2. We use existing rloc attribute. Stig - just relaxing what the RLOC attribute can be used for. Mike - Polled wg. 6 in favor none against. igmp-mld-extension-source-management - Huanan Li Stig - This is interesting. There was a draft discussed in MAGMA long ago that did source registration. And an msnip draft he presented about 10 years ago. Could send a null registration. One concern is its tricky to upgrade hosts. Brian - msnip was designed around the premise that you wanted to minimize sources when no receivers listening. Control the extrananeous flow of data. Some of the drawbacks are msnip was designed with SSM in mind, not ASM. Talk about request to send clear to send as well. Good to look at past history. cheng-spring-ipv6-msr-design-consideration - Weiqiang Cheng Mike - It appears you are not proposing a new protocol but raising the question of requirements with SR and traffic engineering and detnet it might be time to consider new solutions. Weiqiang - It's a huge opportunity for multicast if we can provide multicast as a service as an OTT provider. Maybe we can generate some new protocols for new requirements. Stig - interesting to analyze requirements. Would be good to present this in mboned wg as well for comments on use cases. Mike - bring this up on the mailing list and mboned particularly because this is coming from an operator. draft-li-spring-ipv6-msr-gap-analysis - Zhenbin Li Greg: These two proposals received extensive discussion in bier. Why continue the discussion in pim. Zhenbin: This is not only a bier discussion, it's a gap analysis. Greg: The gap analysis is not unbiased. Zhenbin: We can discuss in the mailing list. We also have TE work for source routing. Greg: We do have bier te architecture in bier group. Zhenbin: It depends upon the solution. How to promote MSR6 in pim, spring or new wg. ?: Like the previous draft, it should also be presented in mboned wg when involving the evolution of multicast routing given a certain amount of traffic. Greg: Surprised you don't mention bier wg but would strongly request you take it to the bier wg because it can address most of the issues you identify. Mike: continue the discussion in mboned, pim, bier, spring, etc. Stig: touches a lot of wg's. Lots of the gaps are bier specific. draft-eckert-pim-rfc1112bis - Toerless Eckert Brian - this document may become something similar to scoped address v6 arch document. capture broader pictures you were discussing. capture various v6 documents may be bigger then originally scoped. Toerless - no functional scope change. yes bring it up and lets discuss further. Hope can get this moved into pim github. draft-mcast-pim-3810bis-00 - Anuj Budhiraja draft-mcast-pim-3376bis-00 - Anuj Budhiraja Stig - trying to move this to full standard which is why are writing this bis document. does the wg think they are of sufficient quality to adopt now or to wait? Mike - let's take a poll to adopt. 6 in support, none against. Hitoshi - what do you think with relationship with lightweight igmpv3/mldv2 (5790)? Brian - we did not discuss relationship with lightweight and valid to add to issue tracker. Hitoshi - perhaps exclude unneeded functions from flowspec mode. Stig - design team is open to all, all welcome to join.