draft-ietf-pim-bdr - Mankamana Mishra Tianji Jiang: How about the BDR side? Sticky BDR? Mankamana: Don't think there is a need for sticky BDR as well. Sandy: The contents in the slides is not the same as the draft. Mankamana: Yes, the draft will be updated. draft-ietf-pim-dr-improvement - Sandy Zhang Sandy: dr-improvement has explicit signaling and pim-bdr doesn't. Mike: We have these two drafts we've adopted. We understood the different solutions. We either continue these two drafts or combine. Would the authors of the drafts prefer to keep them separate? Sandy: Probably should focus discussion on whether to use explicit signalling or not. Stig: We need a solution for sticky dr. Both have a solution and are different. Which method is best, the pros and cons, is there a need for both? Do we want one sticky dr draft that the wg picks or two going forward? Need a technical discussion on the mailing list. Does it makes sense merge the documents? First focus on technical aspects. Mankamana needs to update his draft. Mike: Stig or I will initiate a discussion on the list. draft-ietf-pim-p2mp-policy-ping - Hooman Bidgoli Mike: Did the email for feedback go to mpls and pim wgs? Hooman: Should have gone to both will check. Mike: We will respond but better if they do. draft-hb-pim-light - Hooman Bidgoli Toerless: If we have an upstream interface with multiple possible senders and doing asserts. We have strong rpf. In bier we have bfr id in header and knows who sent it. Effectively changing the rpf interface so at the pim level representing not a lan but a separate p2p interface. In the forwarding plan you want to receive a packet and filter on the bfr id to get rid of assert. Stig: With bier you don't have a shared medium so don't have asserts anyway. You would only receive it if asked to receive it. Only works if you have a shared medium. Should be possible to say this this pim like mechanism doesn't support asserts. That's why you also don't need the dr election. I don't see a problem with an RP which doesn't need anything in particular with neighborships. And for interface, certain interfaces can be enabled by default. Most of the questions can be dealt with fairly easily. Sandy: I do support the motivation of this draft. pim over bier is useful. But I think some details must be more clear so implementers understand. Hooman: We will wait one more ietf, think about the questions. We will then update the draft. We will then ask for adoption. There is some agreement but sounds like we need more meat in the draft. Mike: We don't need to wait for the next ietf, Sandy can issue an adoption call on the list. draft-zhao-pim-igmp-mld-snooping-yang-l2vpn-ext - Hongji Zhao Stig: the l3vpn draft we were waiting on is that progressing? Hongji: no. Stig: if we move forward it gets stuck again but we should move forward. The contents of the draft is what we agreed to before? Hongji: yes. Mike: 15 agree to adopt, none against according to the poll. We will send an email as well. draft-liu-pim-mofrr-tilfa - Yisong Liu Hooman: When sending the joins, are those going over SR or over an interface? Yisong: Just going over an interface, just using SR as an RFC reference. Hooman: When traffic goes from r6 to r5 and r5 says this isn't the best path and go back to r6 how to handle? Yisong: Hop by hop will build the pim state for the s,g. Will send the join to r5 and it will create the s,g state. Hooman: the multicast traffic is never going over an SR tunnel. Yisong: correct. Nils Warnke: This is a live live communication so will receive on r6 the streams twice. With low bandwidth routes this really seems a bit constructed, is there a real life demand or more therectical and informational. Yisong: it is informational. We recommend this mechanism in SR networks. Stig: drafts looks interesting. We can do a call. Do people really understand what's in the document. Mike: 15 in support. 1 against according to the poll. Stig: need to take it to the list and understand why people support and why against. Lots of interest. draft-chen-pim-mrh6 - Huaimo Chen Mike: As an individual on this draft, this was presented in 6man this week. Bob Hinden said to the authors that the header format and processing would be ok for 6man to discuss but the whole notion of the MRH would be better in a wg that focuses on multicast which is why it's being presented here. 6man would work on the actual processing and header format. Probably similar to what Hooman did with having a replication segment done in spring and the policy done here. Stig: this is all new so need to study carefully. Let's follow up on the mailing list and have discussion there. How many people have read it. Robin: Later we will provide more information about this solution including comparison between the various solutions. Stig: there are a couple of solutions, yes. May have to give it some time to have people understand the options and see which solutions look the most promising. Mike: 10 people have read the draft and 5 have not according to the poll. draft-xu-msr6-rbs - Toerless Eckert Robin: SRv6 is incremental deployment based on IPv6. Not sure if this mechanism takes incremental deployment into account or do you need to upgrade the whole document to support rbs? Toerless: It can work incrementally. Only need to support rbs on the nodes that you want replication. Define the fib with adjencies with non directly connected next hops. You may have more adjancy bits. Performance evaluation needs to be done. Robin: Multicast solution may be more complex than unicast. In the draft may provide more info for better understanding for this solution. Toerless: Thinking about the basic forwarding mechanisms. Encoding side may need to go to 6man. None of this covers the control plane. This work is just starting. Stig: Developing an architecture document would be helpful without deciding on solution or encoding. Mike: Taking it to pim seems to be the right place while other elements may need to go elsewhere. draft-geng-msr6-rlb-segment - Xuesong Geng Mike: We have much to discussion on the list. Robin: This is a different mechanism from the MRH. We should think about how to converge solutions and how many types of MRH are necessary. Toerless: Could take one codepoint for the routing header field space and then different subtypes for different types of encodings. The space is rather large, 8 bits and not many values being used. In unicast we have two source routing headers the iot space has done their own in addition to spring. Took values from 8 bit space. Could get several codepoints. Stig: Discuss on list and see what happens and not just wait for the next ietf or bof.