WG Status - Stig Stig - Is pim-mofrr-tilfa ready for wlgc? Poll: 5 say yes. 4 no opinion. 0 say no. draft-ietf-pim-light - Hooman Sandy - As the shephard this draft is in good shape. All main comments have been addressed and ready for wglc. Stig - Both Mike and I are co-authors that is why Sandy is chairing this document. Poll: 9 in support. 0 no opinion or no's. Mike - Sandy will need to start the wglc on the list. Sandy - If there is no response to my email there is no objection. Stig - Because it is difficult to get responses on the list. draft-ietf-pim-p2mp-policy-ping - Hooman Jeff - The last bullet (draft-ietf-idr-sr-p2mp-policy), we need to progress the work here? Hooman - No, didn't mean working on it here. Toerless - Has the implementation and known support reach the same level of support of going from experimental to standards? If there is not enough maybe it should start off as experimental. Hooman - I'm not going to talk about other vendors. At Nokia we have live customers that use yang. Connect the replication segment to a sid list. There are live customers using yang. Toerless - The hardware seems to already be supported by multiple vendors. Hooman - When it comes to mpls it is the same as rsvp/ldp. Toerless - that's fine thank you. Hooman - Even though we call it a replication segment when you go to the data path it is by all means an mpls label that has a bunch of oifs. At the replication points there are states like p2mp rsvp-te. It tries to marry unicast and multicast so you can connect replication segments through a unicast domain through sid lists or policies. The feedback we are getting is having this marriage is very helpful. Mike - We did have a discussion with spring chairs and agreed to work on these documents. Now that replication segment is an rfc we don't see a reason not to progress these drafts. Stig - You mentioned that some oam parts may need a different draft. Will you want to take some parts out of this draft? Hooman - No. Stig - You don't plan any further changes? Hooman - No. It becomes too complicated. p2mp policy with mpls is ready to go. Mike - These are our documents but we will inform the spring list of any pim actions. Poll: Ready for wglc? 1 yes and 6 no opinion. No one against. will follow up on list. draft-ietf-pim-sr-p2mp-policy - Hooman Poll: 3 yes. 1 no opinion. 0 no's. Will take to list. draft-ietf-pim-evpn-multicast-yang - Hongji -no comments draft-ietf-pim-eckert-rfc1112bis - Toerless Bill Fenner - I will review this document. Stig - The other bis documents we need to also discuss but referencing them should be fine. draft-ietf-pim-multicast-lessons-learned - Mike Greg - I owe you text. I am working on it. Before Vancouver. Hitoshi - How about Multicast address scheme. Proposals about dynamic allocations/assignments. We've had discussions about this and experience. Include why it has been successful or not. Mike - I fully agree. There are some group address allocation drafts we've recently adopted and they are part of this story. We will add this for sure. Hitoshi - Also since you are talking about SD and SDR you should also talk about SAP. We've had alot of problems with it. History will help for future work. Mike - Great point, we will add. Toerless - I sent a couple text options, have they been included. Mike - Yes, we've included much of it and added you to contributors. Toerless - It would also be nice to have a section entitled SSM. Mike - We do cover SSM but perhaps it needs it's own section. rfc3376bis and v2 querier fallback - Stig Toerless - We like to see host ignored igmpv2 and lower queriers. And must have a configuration option to allow them but the default behavior should be ssm safe and won't fall back in the presence of an older querier. We aren't ready to remove the backward compatibility all together. Stig - We can't make any major changes as we progress this to Internet Standard. We need ensure if we are compliant with current RFC that we are still compliant with any changes. Toerless - I would consider this a small fatal bug which is appropriate to do in a bis document. Stig - We can make recommendations with MAYs and SHOULDs. But can't have a MUST doing something different from the previous RFC. Toerless - Maybe we can negotiate down to a SHOULD. Bill - In the 90's the routers knew everything and that's where the auto querier came from. We didn't know the networks people would actually deploy. Routers were tightly controlled. It does make sense to try to do something. But trying to do something affects all hosts and host OS's are hard to upgrade. I don't know what to do. Toerless - If we do the must or the should and we aren't compliant yet you sometime add the fix into your source code. It's a small fix. Bill - It's fine to go forward changing it but not sure what that does to standards level. Reality is different from 20 years ago and makes sense to look at deployment problems now. Mike - I agree with what you just said but disagree in that this should be dealt with in a new document. We should do points 1 and 2. Do nothing and proceed with 3376 bis and deal with this in a new document. We've known about these issues for a long time. Hitoshi - This problem is known for 25 years. In my kernal bsd implementation and linux stacks can just statically configure backward compatibility and can just be ignored by host. Easiest way is to just ignore this fallback message on the host. We can explicitly say to ignore the fallback function by configuration. But which should be the default value? I don't have a strong opinion on default behavior. Nikolai - We've had these problems for a couple years. igmpv2 queriers will not disappear. We talked to router vendors and they were always referring to igmpv3 rfc. We aren't going to fix it then we aren't standard compliant. So we should at least have a sentence that this behavior exists and can be fixed. Toerless - Anthing we are changing may require new code. Maybe we should look at other RFC's to see how far they went in fixing bugs. Maybe these deployment experiences just discussed might help to swing the pendulum. Whatever the right thing is for the default. The major use of SSM is in embedded devices like set top boxes and also can say applications can have mechanisms to overturn os defaults. If the network devices uses SSM then the devices can change the default. Stig - It's a good idea to check with ADs to see how far we can go with new texts. And I think it's a good idea to add some recommendations about falling back. Maybe recommend using a different default. So you can still be compliant if you aren't doing that. But strong enough to recommend a change. Maybe uses a SHOULD to be still compliant. Toerless - Applications should have an opportunity to have the right default. Stig - If you have a host stack that can supress the fall back, if the application or STB can make sure that's configured we should be ok. Toerless - It's good for the application to be in control to say if this is SSM. Stig - It might take a decade to get something implemented and shipped. Toerless - Maybe doesn't need to be capital SHOULD. Stig - If some devices uses v2 and it shouldn't be there and it becomes a DR and doesn't understand v3 reports and has the wrong RP config, multicast can break. There is a clear issue. I support adding some text. Brian has the editor pen. We will ask Brian if he has suggestions. I would like to conclude on this in a few weeks. This is the only thing holding up the document. Mike - Are we of the conclusion that we will add some succinct to the document to clarify this aka option 3? Toerless - Yes, add text to 3376 bis recommending new behavior. We are still compliant if we don't. draft-ietf-pim-jp-extensions-lisp - Stig Poll: 4 in favor of another wglc and 2 no opinions. We will take to list and cc lisp in wglc. draft-gopal-pim-pfm-forwarding-enhancements - Stig Poll: 6 yes and 2 no opinion and we will follow up on list. draft-venaas-pim-pfm-sd-subtlv - Stig Jeffrey - Both this and the previous draft and straightforward and simple enhancements to the same mechanism. Would it make sense to combine into a single draft. Stig - We could do that if there is support for both. Sandy - We should define common method on how to use the subtlv and the other can be for different use cases. In this draft we define how to use the new subtlv. Maybe we can use one base draft for how to use subtlv and the other for different use cases. Stig - I'm including the flow rate not just as an example but that it's actually use for us. We could possibly have all in one document. But you are suggesting taking the subtlv out of this document and I'm fine either way. I can combine documents and take the flow rate out. Stig - If we can check if there is interest in this work in pim. The main thing is to keep them separate as they are now or do as Jeffrey suggested. Mike - There is clear interest in this work. Maybe figure out how you want to structure the draft and then we can ask for adoptions. draft-eckert-pim-rts-forwarding - Toerless no comments draft-asaeda-pim-multiif-igmpmldproxy - Hitoshi Jeffrey - There is mofrr rfc and another rfc for multiple upstream neighbor redundancy. Where the the egress pe can receive multiple copies of the same traffic. and they decide which stream they will receive. Here it seems we have the same problem. which upstream interface to send the igmp join to (or both) and when you receive traffic, which interface will you use. To me it could be local behavior. The proxy device decides. Hitoshi - what is the question? Mike - He doesn't think it needs to be standardized since it's a local behavior. Hitoshi - It is experimental or informational and the biggest problem is the current igmp proxy rfc doesn't support multiple upstream interface. So this is a problem. WE dont propose this as a proposed standard. Toerless - If this is an operational method it could go to mboned but I have no opinion. Stig - Maybe it can be a local decision. But it's good to document if you try to implement something like this is how you may do it and what to think about. The original use case for this was multicast mobility. Sandy - We can do it through configuration using a local method. If you want to standardize is is that it's very complex. Many things can be carried though igmp join. It may be more complex than you want. Hitoshi - thats why I don't promote that it should be standardized. This doesn't provide information on which interface to select, etc. Sandy - Providing guidance on the selection is good. You can list some of your thinking. It makes sense. Toerless - You may also had Nick (german telcom or telefonica) they have different upstream vlans where one has multicast and one doesn't. It's an important use case. This may also be standards. Maybe aiming too low with informational. Hitoshi - yes those operators had similar issues and we've been talking about these requirements. I'm not sure how to add requirements into this solutions draft. Luis would still like to have a requirements draft. Not sure if we should work on requirements first then work on this dynamic step. We have 3 drafts. this is the second one. Mike - Do you want us to do an adoption on this draft? Hitoshi - yes, the requirements draft has had less interest. Maybe next time we will present the dynamic approach as well. Sandy: Should change the title of the draft whether requirements or not. Poll: 4 in favor of adoption and 1 no opinion. Will take to the list. draft-zzhang-pi-non-source-routed-sr-mcast - Jeffrey Greg - We do have vendors deployment in active customer networks. Sandy - This draft is very valuable. It provides many recent technologies. The title can be changed perhaps. More explicit. Jeffrey - This is a replacement for another draft. The reason we call it non source routed is because did exclude the sr options. We know there are options for sr options. We are not including them in our draft, not because they aren't good, it's just good to focus on non source routed first. Sandy - If we want to use source routing for TE. Non source routing confusese me. The title doesn't tell me anything. Hitoshi - Does SRv6 support ip multicast tree? Jeffrey - Both SRv6 multicast and plain old v6 multicast is based on ip address. When trying to how to replicate traffic you treat it the same. On the outgoing side with plain v6 your group address doesn't addres, but with SRv6 you do change the address. Jeffrey - We will discuss and then eventually we will request adoption as information draft.