WG Overview - Chairs Mankamana: pim bdr is under progress and a new version will be published in a few weeks. Stig: going forward we will have a shephard for all documents especially for LC. Hooman: some discussion in spring. Wanted us to clarify replication policy and submitted clarification. Mike: regarding p2mp policy the spring chairs asked us to hold off on progressing p2mp drafts until the replication segment draft progresses passes spring LC. Hooman: The comments I gave were for the p2mp policy. wrt to ping I did some modifications and asked for early allocation for sub tlv and never received response from wg's. If we can get early allocation that would help. Mike: Stig and I will ask mpls chairs to help. draft-ietf-pim-light-03 - Hooman Toerless: this should run over tcp especially when used together with bier. How to get reliable big bursts under convergence using pim. Look at 6559. Hooman: this was born through bier. some of the ideas on the bier side that the joins and prunes are only being used for signalling not part of the pim protocol. We need to grab pim and water it down. I have no issue going over tcp but that will change the message types of the joins/prunes going over tcp. Toerless: The burstiness can result in 1,000s of messages and tcp takes nicely care of that. Mankamana: It is agnostic whether we do it over udp or tcp. Hellos are coming before we do signalling. Just clarifying the pim base behavior. Toerless: hopefully that is case. But we should still have pim light must support default to port (6559) to finally have a good reason to deploy port. Alvaro: process observation. Sandy did the adoption call. Please reflect that in the data tracker, list her as a shephard and make her a delegate. Since both chairs are on the draft. draft-karstens-pim-ipv6-zeroconf-assignment - Nate Dino: You said the source could have multiple applications running. Could the receiver have multiple applications running as well? Nate: yes Dino: have to advertise the port number. should adv the port number with the multicast address so you know which port to use with what multicast address. Because a source running multiple applications needs to use multiple ports. Nate: The source and destination are going to be different ports. And will use a well known destination port. Dino: so if the source is running two different applications, 56296, in the example, is being advertised for one application are you using a different port for another application? Nate: the two different apps would use two different group ids so the ptr record name is going to be different. It would have a different record name. Dino: so you'll use the same source/destination ports for the different streams. I think you need to have a different source port per stream. Nate: Yes, that's correct, so if you have two different apps their record name would be different because the destination address would be different and the source port would also be different. Dino: so there is a list of these myports that will be advertised. Nate: it's less about advertising those and more about advertising the address. Dino: then why do you need to advertise the source port. Nate: we can discuss offline if needed. Stig: Not sure if you can use a colon in a domain name. Also your assuming that any app using a group id in the address range would be using thise scheme right? Nate: correct. Stig: may have to update madcap rfc not sure if it addresses v6. Since we are constraining what range they can use. Need others to review this perhaps ipv6 experts. Alvaro: you aren't really changing mdns but using mdns. but changing the ranges in 3307. The wg in general thinks this is probably a fine solution. Questions for chairs is should we do this work. This is an app of mdns and update of iana registry. to figure out with dnssd and 6man to figure out what do we do. we can process this document but will need to coordinate with them. the wg that processed 3307 doesn't exist anymore. Make sure 6man etc are ok with it. It might be that another wg processes the document. Mike: Brian haberman is the only author of 3307 so will need to be involved. Alvaro: 3307 was done in malloc in transport area. Probably should talk to eric kline and Brian may be the expert assigned. He would just need to see if the range is ok. Stig: need to also look at madcap. Dino: we live in a decentralized world and we need unique group allocations for applications and this solution is only for a L2 network, we need to generalize it for a L3 network. In that context this wg should work on it. Stig: Agree. This is my concern, need to make sure site local etc doesn't conflict or if someone is using addresses in this range. Dino: that's why he wants to use an allocated range so no one else uses it. and this solution is using multicast to allocate a multicast address and the reason it works is because its on layer 2. Toerless: thank you for the draft. would rather error on the side of getting something done like this than waiting for something better that we can't figure out. Stig: I'll reach out to Brian and others. If you have improvements please speak out. Have most of you read the draft? Poll: 6 people have read it and 6 have not. draft-zhao-pim-evpn-multicast-yang-00 - Hongji stig: evpn bgp routes that you are describing are specified in bess? Hongji: yes Stig: have you presented in bess? Hongji: first presentation in pim wg do you think it's better in bess? Stig: It relies heavily on an rfc from bess so good to present there. Not sure which one should be the owner of the document right now. Mankamana: May be best in bess. the base evpn yang model is on hold for now so probably not best to do something which is beyond the base evpn yang model. Either do this along with the base model or afterwords. Stig: We will reach out of the bess chairs to know where to take this. draft-giuliano-treedn - Lenny Stig: This is what we've been telling people for some time now but we don't have a document that explains it. Lenny: yes it's nothing new, a combination of SSM+AMT to ecentially describe a CDN. Stig: a content provider could be a router receiving multicast. Dino: we have an AMT doc that describes the protocol but need a last mile document. We need a deployment document of some source. Nils: Maybe incorporate work that Jake has done for mboned. Content provider could be off net. Relay could also be pushed out to edge cloud. Dino: source could be off net, receivers could be off net. Not just a last mile solution. Could be first and middle. An overlay could do it all. You may not have multicast. You want to deliver the multicast service. Lenny: The overlay may not be a destination. This could grow over time. The overlays essentially provide the bridge to get from native multicast to non multicast. Incremental deployment helps deployment. Ice: Source discovery is another impediment to deployment. Are you going to describe source discovery? By punting to the app then if we don't we can't do SSM. Lenny: Punting to some out of band mechanism and we are simply following those guidelines. Dino: if you started with an overlay and head replication hits a wall, providers have customers and have to solve the problem, multicast support would naturally come out. Xuesong: Very interesting topic. Quick clarification, whether the source of the live streaming will be dynamic, can it be anywhere in the network and is that a problem for setting up p2mp paths. Will receivers be dynamic which may influence convergence. Lenny: You can have emphermal receivers coming and going. This is optimized for OTP receivers. Yes, sources can be anywhere. Xuesong: will existing multicast protocols be able to support dynamic receivers. Dino: using amt gateways the receivers can move around a lot and will attach to a new relay. From the sources point of view, let's have the sources in the multicast cloud. source mobility with multicast hasn't been done much. If it hits a relay that is already using the source address we are good to go. Could be an RPF change going to new relay. Message is, as AMT sources/receivers will the tree have to change and if it doesn't its a wonderful scaling properties. Stig: the app must discover new source address. Dino: In lisp the source address never changes. Lenny: overlay networking technologies can be used to get multicast even over points of network that aren't multicast enabled. Dino: as the source moves it can always attached to the same point. Lenny: I don't see the source address changing often. Usually it's stationary. draft-mcbride-mboned-lessons-learned - Mike Xuesong: This is necessary. When I want to learn something about multicast, there are a lot of protocols that I'm not familiar with. Good to know what we can learn from these. Dino: Young designers coming up with proposals and older people saying it wont work because it's already been done. Have to document history or will repeat mistakes. Ryan: Would love to see this document produced and will provide feedback. I drift in and out of needing to work on multicast. This would be valuable work. Stig: Also thinks this is useful. Good to describe bidir. Easy to get lost with all the rfc's. Will do an adoption call on the list. Will check with mboned chairs as well. Lenny: If this is lessons about deployment it would be in mboned. If it's lessons about protocols it would be pim. This document does a little bit of both but seems more protocol lessons so pim would be the better fit. Dino: documenting both deployment and protocols would be useful. A deployment would be much bigger. Alvaro: both types sound interesting. Don't know if history of deployment is as interesting as how to take the tools I have today and how to deploy them. Focus on how to move forward not why it failed before. History of protocols is more interesting than history of deployment. Nils: The discussions we had at 114 shows that old drafts were pulled out and why we didn't deploy them weren't documented. If you are working on working on new stuff it would be helpful to know why we didn't use the old stuff. Dino: Like dvmrp.