WG Status - Stig Mankamana - I will be updating the two DR related drafts Mike - Not enough time to present the lessons-learned draft but there is a fair amount of new text on mospf and msdp so please review. draft-ietf-pim-light-01 - Hooman Stig - I have some input and will contribute. Sandy - Just started work on df election in bier overlay so maybe pim can use it as well. Hooman - We want to keep pim light very basic. Might as well use pim if not. Sandy - You can just reference in your draft for another option. Greg - The generic df election mechanism is targeted for pim free environments. Maybe explain in the document what the development models will be. Stig - Don't think we should discuss bier in this document. In bier wg you can discuss use cases etc. draft-ietf-pim-p2mp-policy-ping - Hooman Jim - The replication segment draft is in the rfc editor queue. Mike - And that draft is one that we are dependent upon with progressing our related drafts. Mike - The reason you added SRv6 the pim policy draft is is because it was added to the spring draft correct? Hooman - Yes. Mike - Is that significant text? Hooman - It does explain how the SR edge should be built on the PHP routers. Mike - So we need to review those additions as a wg. Hooman - Most of the heart of it is in the replication segment but there are some examples. Stig - We need to do better at discussion on the list so will do a last call and take it to the list. draft-ietf-pim-gaap-00 - Dino Toerless - I'm 100% persuaded this needs to support SSM and ASM. Split the address range into both of them. You need to make sure the receiver knows what the source address is and that's an application responsibility. Dino - How does the application know what ranges the network is using and which one to allocate? Toerless - What have the IANA registry draft which is where we are going to take two address ranges for gaap. Dino - The gaap spec says it will get a single range for ipv4 and ipv6. Toerless - It should say it will get a range for ASM and SSM. Dino - And how does the application know which range to allocate? It's going to ask gaap for a group address. Toerless - The application will need to know whether it's ASM or SSM. In the garmin application it's SSM applications. I want to have an SSM address, done. Dino - Its not that simple, the application doesn't know anything about the sources and you are requiring it to do that. Toerless - The garmin application wants this. Dino - Thats an application that will not use gaap. Toerless - Thats not true. Dino - The protocol doesn't support it. Toerless - if you have your way with gaap that's true but if this is a wg document as a wg member my opinion its simple to have gaap support SSM and ASM. Dino - We want to support decentralized applicastions. How will all members and senders of the group going to coordinate with what the network is using for the ranges. We want applications to work w/o knowing sources. Toerless - Why? Dino - Because that's the service model. Toerless - The use case from Garmin is that the sources are well known. Dino - We aren't building a protocol for one use case. Toerless - We are building a protocol for some use cases. You can use gaap for ASM but there should be support for SSM apps. So just allow gaap to allocate out of two ranges. Dino - You want to give it more functionality and the protocol is an ASM protocol period. Toerless - This is simple what I'm asking for and I'm not sure what the resistance is. Nate - We, Garmin, do not want to use SSM for our use case. The model makes it seem like it's SSM but our hardware doesn't support SSM. Toerless - There is no difference between ASM and SSM for your L2 switches. Mike - We will ask the list and will think more about this. draft-ietf-pim-ipv6-zeroconf-assignment - Nate Toerless - This is competing with Dino proposal? Dino - No Toerless - both will want to use madcap address space. Two competing solutions for that address space that we would need to further subdivide? Nate - For address allocation there are two possible solutions and they each have their own benefits and drawbacks. They can coexist. Toerless - If I want to run both in the same network they would need to have separate address ranges. Dino - Yes Toerless - That's what I mean by competing. We will all need to be happy with the size of the address space. Aren't we taking this all from the madcap space? Stig - That address space will be divided into smaller chunks for each application. Toerless - When you are claiming an address with mdns I think you are reinventing something unnecessary. You may get resistance from dnnsd folks because they are already doing this so let's discuss more. draft-eckert-pim-rts-forwarding-00 - Toerless draft-zhao-pim-evpn-multicast-yang-03 - Hongji Mike - This would be a draft that should be worked on in bess. We've pinged the bess chairs and wg about this draft. They are a very busy wg and Hongji hasn't made any progress there so that's why he's presenting here especially since we've progressed several of his other yang drafts. The bess chairs gave the go ahead to discuss and potentially adopt in pim. In the poll 8 were for and 1 against adoption. We will take to list and cc bess. draft-mankamana-pim-pfm-sd-extension-evpn-mh - Mankamana Toerless - Are we needing to fix something multicast related in evpn? Mankamana - Til now we've been doing multihoming with active and standby. This new concept is getting traction with elective multihoming. Both sides are advertising the same prefixes. This will impact multicast differently than unicast. Multicast comes in reverse direction so something is needed. Toerless - Why shouldn't the evpn folks fix it on their side. Mankamana - There is nothing that evpn can do here. Toerless - But that's how evpn is defined they are using that mechanism Mankamana - There are two decisions. Traffic coming from southbound to northbound how can evpn make the call. Toerless - Let's discuss offline. Sandy - Can it not only be used by evpn multihoming it could be included in various instances where this is needed. Mankamana - Sure draft-skr-bess-evpn-pim-proxy-02 - Mankamana Mike - Do you want us to ping the list about this or will you? Manakamana - I will draft-chen-pim-adaptive-te-02 - Huaimo Toerless - Would be nice to see a hw implementation of that. Similar to what I'm proposing. Huaimo - Yes it's similar. Toerless - Would be good to have a P4 implementation. Huaimo - It's a good research topic. draft-contreras-pim-multiif-config-01 - Luis Mike - The related Hitoshi draft you will be eventually be seeking adoption? Luis - Yes. We should take to the list for people to read. Mike - Has the Hitoshi draft been updated? Luis - Not updated from text but it's alive. Mike - Update it, bring it to the list and the chairs could then ask for adoption.