WG Overview - Chairs Stig: Both pim-assert-packing and null-register-packing approved for publication. The lessons-learned draft passed adoption call and everyone should be welcome to contribute to the draft if they wish. The wglc ended for pim-rfc8736bis with no responses. Toerless: That's the bits in the header correct? Stig: yes Toerless: I would love to see an example of how to write this up. And putting in the actual bits is not an actual iana allocation. These two descriptive things would be nice improvements. Mike: For Hooman, the one draft we don't have an update for this ietf is the p2mp-policy-ping and you sent an email to us and mpls chairs for an early allocation and we said yes sounds good it meets all the requirements and they said the same thing and the AD's were included and then Loa said we need to start the process over again and request it so we will resend a new email to the AD's, ccing the mpls chairs and it should be ok. Hooman: Makes sense, thank you. draft-ietf-pim-light-03 - Hooman Toerless: Could simply be an update for 5669 saying that we don't need the hello's when an interface is configured. How do you figure out when you open the tcp connection that it is for pim light vs pim how do you do that w/o the hello? address, port number whatever you choose so you know this is a tcp socket for pim light mode. With 6559 its only experimental right now. Alvaro: You said something about this on a lan interface and recommending only using it on p2p. Are you recommending only using this on p2p or are you saying this only works on p2p period? Hooman: Only works on p2p. Dino: Regarding the tcp interaction is it your intention to only run it over tcp or udp and tcp. As part of your procedures, just send a syn message to the port that's allocated and if you get a reset then fall back to udp. Hooman: Are we going to use the same port or not. pim light only talks to pim light. Stig: source dr and rp have to be in same domain. It should fine to have pim light sitting at the first hop with the rp, nothing preventing it. Hooman: I thought that was the register message preventing that. Stig: no the register message is just unicast. Hooman: The register doesn't need hello? Stig: No Toerless: I'll keep pushing for that implementations should support 6559. Because if we are deploying this with bier we would get the recommended reliability. If we have a bier domain between that is multiaccess and we wont have an assert issue because we are only getting the traffic from the upstream router. Hooman: You are right, its one direction and not just p2p, we need to get the text right. Toerless: We can't use it on networks or we will have assert issues. Hooman: Good comments and I'll update. draft-ietf-pim-mofrr-tilfa-01 - Yisong Hooman: When it comes to tilfa you don't always terminate on the next router so you could have a next next hop, what would happen in that case with pim adjencies with a router that is multiple hops away. Two routers adjacent will work nicely but what if there is a router between. Are you going to create an adjacency between R2 and R7? Yisong: If you have multiple hops we can use multiple attributes to establish backup tree. Every router we assume has pim neighbor. If we specify the attribute we look up rpf per attribute. if we don't specify we check the unicast routing to the next rpf vector attribute. If we use type 0 we just check the unicast routing. Let's take it to the list. Mankamana: Join is not going to go by tunnel, still hop by hop. rpf vector will help where to go. There won't be any tunnel where pim neighborship is needed. Stig: should consider wglc. Does anyone have concerns about going to wglc? we will take it to the list if no objections. PIM Backup DR & Sticky DR - Mankamana Dino: Should the BDR expect igmp reports so when it gets the role it knows there is an outgoing interface? Because if he is elected BDR and hasn't heard any igmp reports he thinks there are no members on the lan. Mankamana: Yes. If there is an igmp report coming all the routers on the lan will get it. Alvaro: There is no draft, it's expired. All the new stuff isn't anywhere. What about the other draft, what are we doing to do? This one doesn't say anything about the other one. Do we really need two? Stig: I agree. We need some analysis to determine if we need two solutions or is one solution enough. Alvaro: The other draft says that because this one doesn't have the sticky then we could use that other draft but now there is stickiness here what to do. Manakaman: if there is any technical issues with either issues, which one will be simpler. Alvaro: yes, that's why I'm trying to force someone to say something. You say there are limitations, maybe there are, many things to consider. We need to do something. Mike: We vary well may have two drafts that proceed. Sandy: This draft has been implemented and deployed and want to know if both solutions can be in the wg. I'm ok for wg decision. Stig: in order to decide we need to decide how they work technically. which solution works best with use cases. authors please work together. draft-farinacci-pim-gaap-02 - Dino Xuesong: First question is about claim message will be sent in unicast or multicast. Dino: it's designed to send in multicast so everyone can hear the same messages and asking iana to allocate one v4 and one v6 address for it. Xuesong: second question this is decentralized protocol. what group name will be allocated. Dino: the group name will have to be allocated by the application by however people rendevoux. But it may not need a web page guide or central directory like we've seen in the past. Toerless: layer 2 and layer 3 domains are you expecting people to configure sparse mode or some app level flooding across layer 2 networks. Dino: gaap is protocol that is a mcast application that runs on a mcast group address so everything we've designed over the last 20 years could be used. It might be hard to run gaap on ssm because then you would have to advertise sources and that would require some centralization. Toerless: Maybe how to build gaap forwarder. Dino: In the marine time use case its a small domain but we want this to work wide area. Toerless: but how wide area. Dino: the spec doesn't specify which pim flavor to use just that the packets need to get to app nodes. Toerless: the specific gaap forwarder should be possible. Dino: Maybe there is a lightweight iot node that doesn't want to run the protocol but it could still get allocations by doing a restful api from some other node but that is starting to feel centralized. Toerless: In anima we did application level multicasting but still be decentralized w/o creating loops. also you have application a and then application b comes up. now a collision on the hash now new sender for b. Dino: it's gaap node claims b. then b+1 will send a trigger to say to go to b+1. This algorithm not only does collision detection and fixes it but if someone is on an old address it will be detected. Toerless: But if application a isn't there anymore, it's it based on time? Dino: the collision resolution between a and b happens, the reason a won is because it created the group first and its timestamp is less so when b+1 comes up b will resolve b+1, if A comes back to the network then everything is ok because it is running a group address that is unique to it. Toerless: Once A is gone then the winner is the one who hashes B against B+1 because the allocation is older than the new guy. Dino: lets take it offline and I'll explain it. Lenny: SD and SDR did something similar by picking an address from a block. How is this different. Dino: Its the same mechanism but done at the application layer and was both a address allocation and human rendevoux mechanism for groups and content. Multicast was always depending upon things above its layer and this is really a network layer function. The addresses are advertised through protocols. We want to put the functionality where we think architecturally best. Ice: How to distribute the claim messages. Have you thought about using BSR to distribute claims? Dino: gaap is an indepedent protocol and should be able to be sent over mospf even. And over pim. but not depend upon pim machinery. Ice: But BSR doesn't depend upon pim machinery. It's app level flooding. Dino: We want gaap to depend upon services in the network and not have to depend upon the protocol mechanisms of any one given protocol. draft-karstens-pim-ipv6-zeroconf-assignments - Nate Sandy: So this solution is centralized? Nate: No it's decentralized. You could use dns from a central server but it's designed to use mdns and decentralized. Dino: Regarding your mdns layers 2 comment. This is a plug for overlays, you can probably not change mdns and run it at layer 2 and It'll just work. Nate: yes. Mike: Stig will drive this concept of address allocation on the list regarding adoptions, etc. draft-asaeda-pim-multiif-igmpmldproxy-05 - Luis Didn't catch name: igmp snooping proxy normally deployed with multicast instance. Is this compatible with multicast instance function of vsi. Luis: not sure, let's discuss on the list. Didn't catch name: another question, igmp snooping proxy is deployed on layer 2 equipment, should it use the mac address of the set top box or home gateway? Luis: We are considering the ip address from the customer and use that for selecting customer. Didn't catch name: If two subscribers join the same channel what will happen, duplicat traffic? Luis: Depends upon policies. One subscriber could take the same content depending upon policies. draft-eckert-pim-rfc-1112bis-01 - Toerless Dino: Are you sending a message that switch vendors should no longer support igmpv1? Toerless: yes Dino: So it's a strong statement you are making. And if they don't support it good luck then hosts wont be able to use it? Toerless: We already have the bis's of igmpv3/mldv2 and will be full internet standard. Dino: I'm worries about what should be removed from the past. And it sounds like there is an effort staring to tell vendors igmpv1 is going to be obsoleted and should take it out of your product. Toerless: yes Alvaro: igmp bis didn't take igmpv1 out right? But what I really want to say is 8200 has been a bad experience because of the lack of normative language. There have been multiple interpretations of what the rfc says depending upon how you read the text. It concerns me that this would not have normative language and you seeing 8200 as a justification. But also have a bunch of other stuff you want to change. I would talk to your new AD and get him to start working on this now because even if you don't change the normative language there is still a bunch of changes. And we don't want to get to the iesg and they say no. Toerless: There isn't any similar contensious language in 1112 as with 8200. I see no reason to try to change any of the texts other than updating the references, terminology, applicability to v6. Every host stack supports igmp host stack. The text of 1112 is fine and we don't need to redo it. Dino: I wonder what it means to say we don't support igmpv1 anymore. All igmpv1 is is the query and the report. that report is also used in igmpv2 so you have to be careful how you message this. A vendore will say I don't need to listen to igmpv1 reports anymore, I'm just going to listen to igmpv3 Toerless: What you are talking about is the backward compatibility in igmpv3/mldv2 which is standardized. The fallback messaging is included in these rfc's. You don't need 1112 for that. draft-zzhang-pim-multicast-scaling-considerations - Jeffrey Xuesong: Good to see these 3 scaling dimensions because we have the same considerations in our msr6 problem statement document. Scaling problems may be more severe in different use cases. Please review our document. Maybe we can work together on this. Jeffrey: I will read it. Xuesong: I noticed that RBS is treated as bier-te. It is still in discussion in the bier wg whether rbs can be done maybe that needs more discussion. Jeffrey: I was just referring to the technology, not where it is done. Stig: We will take the various adoption calls on the list. Any comments please do so on the list.