WG Overview - Chairs draft-ietf-pim-yang: Stig: many yang models will be published at the same time. Acee: ospf has a similar situation with yang models. The redo of the BFD model is going to go into Auth48 and will be pushed through as quickly as possible. This is the reference that we are all waiting for. rfc 9127bis is fixing the bfd config parameters. You can either specific the parameters within the protocol or specify them externally. draft-ietf-pim-dr-improvement and pim-bdr: Mankamana: We will work on them before next ietf since some of the sticky behavior has now been implemented and deployed. Update provided at 115. draft-ietf-pim-p2mp-policy: Hooman: There was an email to the wg asking for last call on this. Poll: 14 in favor of LC, 2 against. Mike: This draft was waiting on the related replication segment draft in spring. What's the status? Hooman: Trying to do a last call on that one as well. Makes sense to have the wglc even if the spring draft isn't ready. This draft discusses the tree and the replication segment discusses the forwarding plane. Mike: pim chairs will first ping spring chairs. Hooman: Yes any comments please let us know. draft-ietf-pim-p2mp-policy-ping: Hooman: We went to the mpls wg asking for comments. Need to follow up. Only thing left is getting a sub-tlv assignment from iana. Perhaps we can then do a last call. He will put something together for 115. draft-ietf-pim-mofrr-tilfa - Yisong Liu No comments draft-hb-pim-light - Hooman Bidgoli Sandy: It would be great if more details can be added to the draft. If we received a hello from the PLI what will we do? The hello packet process needs to be added. But I do support adoption. Mike: Sandy is acting as chair for this draft since Stig and I are authors. Rishabh: BSR needs pim neighbor on an interface. So if no neighbors you need to determine how forwarding will work. Stig: I agree, we need to mention that. Maybe just say it's not supported. We should look at all message types and make sure they are covered. Adoption poll: 13 in favor and 1 against. Sandy will confirm on the list. dynamic multicast address assignment - Nate Karstens Lenny: Are the receivers sending igmp/mld reports? Nate: yes Lenny: You said ssm isn't universally supported by switch hw, what parts of ssm aren't supported? Nate: It's the tables they use to make decisions, it's all focused on the destination address. There's one vector with a bit field that says these are the ports. You would expect some filter to look at the source but even then we are looking at the source mac not ip address. You would have to put the source address of a router for data coming from outside. Lenny: Is the snooping mechanism used by the switch mld snooping? Nate: yes what we find is that the switch recognizes an igmp/mld message and forward that to a cpu and then the cpu recognizes there is interest in the data now I have to modify that entry in the address table. There's partnership between the switch port and the cpu. Lenny: It's doing mld snooping but it can't look at the source. Nate: correct. Toerless: Are you doing ASM or SSM. What L2 hw capabilities do you need in the switch for snooping? Nate: What's not working is we don't have a good way to allocate multicast addresses dynamically assigning them in a zero config environment. Toerless: What's the use case Nate: High speed and low speed sensors connected to the same network. We want to have different speeds of traffic and only directed to ports that can handle that. Toerless: we've had 30 years of people giving up on the idea and coming up with simple pragmatic address allocation. Nate: A lot of our users are weekend fisherman that don't understand networks so we take care of it as much as possible. Toerless: how about certain deployments using certain addresses.Everyone is hardcoding multicast addresses into their apps. And then problems arise in larger networks. You don't have a large network its very predictable. So you come up with an address plan and it gets hard coded into the devices. Nate: I disagree that every network is the same. Boats are wildly different. Toerless: perhaps an address plan with all the known possibilities would be sufficient to address the problem. Nate: It would not be. Toerless: these days if dynamic allocation is needed it's using applications and controllers rather than rely on network protocols. Nate: The same argument could be made for assigning addresses to individual nodes. Someone once said it makes more sense to have a dhcp server than individually assigning addresses to nodes. Same thing here applies to destination multicast addresses. Hooman: We have the same type of issues with iptv. We use zero touch provisioning. Static multicast addresses are within the configurations downloaded to the routers. Anything coming on this interface needs to go to a source that is 480. Anything coming on another interface needs to go to a source that is 1080. Nate: does a server upload your configuration for pre-provisioning? Hooman: for zero touch provisioning unicast comes up and you used dhcp discover to get router address and based on dhcp options you get your configuration specifically for that router and the provider knows which routers interface has 480 streams and other interfaces have 1080. It can then statically assign multicast addresses accordingly. Nate: we would avoid a dhcp server because it represents a single point of failure. Lenny: how about rfc 3306 where we can derive a multicast address from a unicast address. Nate: problem is that once you do have that unique ipv6 multicast address when you transmit that on ethernet the group id part is not unique on the network. The interface id is unique on the network. But the lower bits multiple devices could choose the same group id. It would be unique at the ip layer but not at the mac layer. Our switches are only looking at the l2 switch address. Dino: Thanks for your thorough preparation. I have several questions but let's wait until the end of your presentation. Toerless: How do I learn the address well you learn the name how do you learn the name. Various steps necessary in the design process. Stig: Sounds like discovery is important. SSM won't work because how would you know the source address. Nate: we are using MDNS for discovery. Stig: may be able to use SSM for the actual data traffic but you will need something for discovery. Nate: the problem isn't that we can't discover the different sources. The problem is that the switch hardware doesn't support filtering based off the source address. Xuesong: Very interesting. Interested in the scenario. How many sensors, etc in the multicast domain? Nate: Looking to support 1 display and 1 sensor to potentially 100s. A container ship may want different sensors throughout the boat for temperature, depth etc. Xuesong: We have met similar use cases in enterprise. Stig: so you only need discovery at layer 2. Do you see a need for multiple links or at a site? Nate: Are you saying discoverying which address you are interested in? Stig: sounds like you need uniqueness within one broadcast domain or link. Nate: It doesn't mean we won't want to support various scopes. Stig: It may be helpful to solve a more general problem. Dino: There is a simple solution for group allocation. You could do hashing on the sources and receivers. But a couple questions about your deployment to make sure its clear. All the sources and receivers are on the ship and ther are no routers involved? Nate: That's true for our current conception but larger container ships probably will need different segments. Dino: ok so the solution doesn't matter whether its multihop or single. Since you are using multicast dns you are looking up a dns name so you are naming each of the group communication. So all you have to do on the sources and receiver is run a SHA256 hash on that name which will create a unique address that both sources and receivers will sync to. You could ahead of time look at those names and if they hash to the same lower 32 bits which will collide at ethernet you pick a different name. The sources and receivers can be dynamic. If they hash they will hash to the same addresses and the problem is solved. No 3rd party it's completely decentralized. Doing the hashing to figure out the group addresses is trivial. I could write you a 10 line python program to do that. And the problem of group address allocation is solved. Nate: That's an interesting idea. We also want to be as standard compliant as possible. Cameras for instance will run this protocol in a marine environment. We want to take an off the shelf solution and put it on the boat Dino: If you want to play with the high order bits to make them unique with other applications you can do that as well. What we want the 256 bit hash to do is truncate to the lower 32 bits but the whole point is you don't want your groups to have address collision but that's easy by picking the right names ahead of time. Sources and receivers hash on the same value because you want them to get the same group address. Nate: If we say that's how the onenet protocol should do it how do we know other none marine onenet devices will support this and not get collisions from those other devices. tvs, cameras, satellite systems. Dino: you can put the prefix in the higher order bits of the prefix. And the prefix can be unique to these sets of applications. Dino: you are doing detection but I want you to do collision avoidance ahead of time. Nate: that makes sense if everyone is using the same avoidance algorithm. there's still potential for race conditions based on who understands the state of the network at any given point in time as far as calculating names and determining if there collisions. Dino: They all have to follow the same algorithm. We can talk more about your future applications that may cause collisions. But at least for this ship scenario there is a simple solution. Stig: You might have multiple apps on the same host correct? So you have an issue that they have the same source address so may need to put something more into the hash to make them unique. Dino: we are just clouding the discussion by just calling it ssm or asm because right now it's just a l2 switch. So we sourcing groups and hosts are joining end of story. SSM/ASM is a concept for multihop routers. Lenny: One bit of advice some of the old proposals like madcap we moved away from them years ago such as complexity and came up with better static mechanisms. Dino is suggesting a clever way of doing this. Each of these solutions were addressing mechanisms that were simple. Caution against against trying to reinvent the wheel we abandoned years ago. Dino: If you have one source sending to multiple receivers, ie one group, we would make the group address equal to the lower order bits of the source address since there is always one source. If you wanted to look at content you would know the source address by looking at the group address. That's a one to many only solution. Stig: Often people register fixed addresses to devices with iana. If you have multiple devices they can't just use the same address. A static allocation would be difficult in this case. Dino: You could just put them in dns and have the source send to the same name that the receivers look up and apps do dns lookup that matches to a group address. Stig: 10 years ago we started looking at ways to avoid static allocation but it didn't go anywhere. The more simple the better. and needs to work. Dino: If you want to look into the future and do multihop routing and use overlays you could have independent paths because these addresses are relatively random. The hasing provides the randomness. You could do load splitting due to this randomness. Nate: Hashing is a good idea. You have to detect collisions and when you detect them is the resulting protocol more complex than a protocol that just dynamically allocates everything. Dino: Collision avoidance is key. And you can't do that on all the hosts if they don't want to join all the groups. You dont want a protocol to do it. A good hash will provide good randomness across 32 bits so you may not have to worry about this problem. You pick these names x.com and run it through this python hash. You will know ahead of time. When you put the names in your database you can run the program across all the names and you'll know if there are collisions. When you want to add a new name you run it again to look for collisions. If there are collisions then the name you just added is not unique enough. Nate: When you integrate another piece of equipment that doesn't do that. Dino: you are right. The new set of applications that don't follow this algorithm will not likely collide because there is enough randomness in the 32 bits though not guaranteed. Nate: so a collision would be rare but when it does we can't expect our user to figure it out. Dino: If it does happen and it's rare you are no worse off than you are today. Nate: we don't want to play the odds because our customers streams won't work. Dino: if have to decide what the future will be with these apps and if they will do group addressing. Nate: we want to set up ourselves for success. Dino: there is no reason why you can't statically configure the addresses on the newer apps or use madcap etc. Or if you really want to solve the less than 1% cases of collisions you change the l2 box to a l3 box and get less collision possibility because ipv6 subnets will further segment because of you have the whole ipv6 128bit address space. The likelihood of duplicating an ipv6 address happens in something like 120 years if you try to reallocate the address every second. Nate: the problems introduced by adding a router may not be worth it. Brian: there does seem like there are existing ways to solve this problem but will need to dive deeper into the scenarios. Stig: probably good to avoid grand solutions with dhcp and madcap. Dino: The reasons we are looking for more simple solutions is because we have many years of experience with these complicated solutions and haven't taken off. They all work but have a cost. Toerless: Maybe write down an informational document and we can help further define solutions. Stig: writing a draft and requirements would be great. Nate: write a set of requirements without a set of proposed solutions? Stig: correct. Nate: I made an assumption that there is an understanding on how these things connect. Nate: The expectation for their users is they connect these things and they work, they don't have to do anything else. Nate: the onenet standard covers much of this and I'm walking the fine line of providing too much information and not enough. There's a certification process that each device goes through to test things. Toerless: lets run with one simple example so we can clearly understand the use case. Mike: Thank you so much. This is the right place if we do go down the new protocol route even though that's not recommended. Otherwise an informational draft perhaps in mboned would be the correct route. Stig: a simple draft to understand the requirement would be very helpful. 4604 Issues - Brian Haberman Acee: I agree that it doesn't make sense to keep them separate and should be done together. To do it to full standard don't you have to have so other implementation document and survey? Brian: yes and it's already been done prior to the start of the two bis documents. Stig: the survey covers everything for 4604? Brian: we would probably have to go back and do some additional work for 4604. From what I've seen from an operational and implementation perspective that survey should be straight forward. Stig: it would be good to include this because I've seen implementations that have overlooked some requirements. Perhaps the only reason 4604 is a separate document is because it was done after those base protocols. Brian: You'll find I'm an author of 4604 with Hugh and Brad. We didn't want to open up 3375 and 3810 again given that people were trying to implement those versions while we were also working on ssm. Stig: Only one small comment on the 4604 errata. Dino: Do you think mld could be a dual stack reporter? ipv4 addresses can be embedded in ipv6 group addresses and just run one protocol to join v4 and v6 groups. Maybe that's some new effort. Brian: We could look at something like that but that would be a next version thing. Brian: consensus call on the list for incorporating 4604 into 3376bis and 3810bis? Poll: 15 in favor of incorporating 4604 into bis drafts. none against. Stig: Is all of 4604 what people implement? Brian: There's two ways of looking at it. When we wrote 4604 we specifically marked what pieces of the document were modifying 3376/3810 we could focus on just those aspects and get those incorporated into the bis documents. otherwise it will be more work to see what the survey for 4604 would look like. Brian: I can ping the wg. Alvaro: I hope this is done soon. When we go to internet standard one of the requirements is that there hasn't been significant changes. Since we are incorporating 4604 it may look like significant changes. We will want justify why it looks like there are significant changes when there aren't. Do we have shepherd. We should assign one now. Stig: if someone implements just the base rfc and not the ssm 4604 part the problem could be they aren't compliant anymore with the full spec. On the other hand we want everyone to implement the ssm part. draft-nandy-pim-static-routing - Tathagata Nandy Mike: the authors aren't here. We told them to take it to the list. My take is they are proposing to standardize static mcast routes that are extended to include forwarding location. Static ip mroute and instead of just pointing back to the source you are extending that to show where that traffic should flow to. And also to have a redistribute option. Toerless: There has been various cli to do these things on the vendor equipment using multiple commands. If it's a yang model thing perhaps it's more of an mboned thing? Lenny: we do have a yang draft. Toerless: would recommend coming up with a good use case to get use excited about it to get it standardized. Mike: is standardized static multicast routes what we should do? toerless: it's standardizing the config of it using yang. Stig: This is something everyone implements pretty much but they might do it in slightly different ways and I don't know if we want to standardize one specific way that may not match the various implementations. And it's very local to that device. A yang model would be something we would need to standarized. Dino: Perhaps static distribution trees is a better name if we want to standarize it. Even though you are configuring the route in one router you have to consistently configure it downstream as well. If unicast changes should the static mroute change? Lenny: static is a protocol. And this is a protocol wg. Is there a unicast static route rfc? If not we shouldn't do it. If yes we should. Toerless: there should be a yang model for static routes. mboned would be a good place to vet interest in the use case. Stig: Would be good to document in mboned. Dino: This shouldn't be specified nor standardized. What if pim is running over this router that has static routes. Does one override the other? There's a lot of machinery that would have to get spec'd out to get this right. And if you provide a recommendation and it's wrong it's going to mess up networks. Let's avoid this monster alltogether. Acee: The rumors of a static routing yang model are not exaggerated I'm an author. For the yang model for ospf we got all the major vendors and put multiple ways of doing things in the yang model. Juniper, cisco, Huawei, Nokia. It did end of being alot. We did not specify redistribution but it's something people ask about. Mike: we will inform the authors and suggest they ask for comments on the list.