to be cleaned up by chairs:

Welcome to PIMworking Group. I'm glad to see you all made it here on a Friday. We have an exciting session coming up. Also, cool stuff So here's a note well. I hope you have seen it many times this week you should all be aware of this it's about how we should conduct ourselves and so on and the IETF and in meetings

00:02:01 - 00:04:00
Go to 00:02:01
Okay, next slide. Here is our agenda So one big thing that might surprise some of you is that we want to do rechartering or we'll get to lie shortly Nothing too big, I hope Then we have several presentations here any comments on the agenda No, just wanted to say thanks to Brian for the 1112 feedback because and I think when you close this or so I'll upload another revision with this system. Okay, great All right, so here's the working group status. So we have this three best drafts to progress IGMP with 3 and MLDW2 to Internet Standard. And, yeah, thanks a lot to Brian for working on those. They're all approved on everything just waiting for the RFC editor and then we have an RFC-12 BIS that TORLIS just mentioned. So that's also related to this progression, basically the host, the art this explaining the host behavior for for multicast was based on IGMP versus one dimension later IGMP or no mention of IPV6 so so that's in this new version we just had a working group last call and we only got one response So it would be great if someone you can have a look If you just want to say it's fine, that's okay. But yeah great if you at least have a quick look at it All right yeah, Mike and I will have to figure out if we feel like we have enough responses, but it's not easy if we have only one one response Okay you have your improvement draft

00:04:00 - 00:06:01
Go to 00:04:00
we need to do some more work on that at some point And also the backup D.R that is on this agenda Ah, yeah, okay Yeah, Presad Sorry, a bit late to raise my hand on the agenda part Basically, I mean, observation, not a question, there are a couple of LISP multicast documents. I don't know if the agenda should exist say that we should review them or something like that but if it's not needed, no problem Okay, sure. Yeah, let me mention that. So, um, were presented by Dino the last PIM meeting Basically, there are some three RFC in the LISP working group that have to do with multiple over LISP, and they are being progressed from experimental to proposed standard and it would be great if you can help read those documents Dino presented them here last IETF I guess we can try to cross-post any last calls or ask Dino to post to pay mailing lists But yeah, the list working group, they focus on the list part so they need us to help with the multicasts Okay. Then we have some drafts that the request publication for that are awaiting rechartering So we'll explain about rechartering shortly once I'm through the list here and PIML Lite requested publication that probably does not have to wait for their rechartering but we'll see also the joint print extensions for LISP yeah, more for ours. We have a lot of drafts

00:06:01 - 00:08:01
Go to 00:06:01
we requested publication for So we've been pretty productive. Then we have a few drafts that I've not discussed this meeting Next slide Also the, yeah, this discovery or what I should call them drafts are not presented here Well, the zero-compassignment is on the agenda and then you have the proxy and some pfm forwarding enhancements on the agenda yeah okay So that's hopefully covered all the working group drafts so then I think we can talk about rechartering I can see it. Oh, there we go hope have this happen pretty quick I mean, if we can, we've had this on the discuss it on that mailing list for a couple weeks now I think we'll do a two-week working group last call like maybe even starting this weekend and then we want to get going on getting this completed so that we can advance some drafts that are kind of being held off We've been working on a charter episode for a couple years we just kind of stall doing it. We were wanting to recharter because of the segment routing related point-to-multipoint work that we've adopted in PIM in agreement with Spring and the chairs and the ADs were all in agreement to add this to our charter and add this work. So there's no controversy there at all. But I think it's with the advent of maybe a new idea chair. I'm not sure, but we do have a some people in the ICA looking at our charters really closely and they feel like some of the drafts don't quite fit, so we need to

00:08:01 - 00:10:01
Go to 00:08:01
get this explicitly listed so that we can advance some drafts that we have so this we don't need to spend a whole lot of time in this. You can look it up real quick if you want, just type in PM, IETA charter to see what it currently is. But what I think, and I think I got it all here is in red, we have what we propose as being changed to the charter. And again, this is what was sent on the list and it has been discussed every comment to date has been added to the charter so it's just real quickly go through it. The very open paragraph, we just simply made it a little bit more explicit to say chartered to maintain improvement add extensions to PIM. Do you have a comment? Yeah, just a quick comment. So basically the way they read the old charger was that we were only allowed to work on what was in the bullet list. So now we are trying to add this first change there to explain that we want to work on you know additions or whatever to Pima and IGMP and so not just that list Okay, let me just finish, just talking about this quick and we have people in the queue we'll let you go we'll let you go here shortly so we just kind of made that more clear in the first paragraph that this is what we're chartered to do for these protocols, MIG&P and MLDP And then we added bullet two with regards to the segment routing drafts that we've been wanting to do for a couple years now We added one with regards to making any work on distribution trees and LISP environments explicit since we've already been working on that Bullet 5

00:10:01 - 00:12:04
Go to 00:10:01
we added that specifically because of a m of r draft that we have and number six we have group address allocation protocols that we're working on. And Nathan is we're not going to the list yet, but there's there's already a nice queue going on by the way. There's three people in front of you and then seven there's experience document because we do have this experience document that we are working on and then we modified that I think these were tortoises suggestions on the bottom just kind of making it you know more explicit with regards to adopting any new work would have to have a reach in that last paragraph a little bit more explicitly as well And do you have a comment? before, you get to override the queue if you want, so go ahead I don't know I know I'm just being polite yeah so i think we're at a point where let's go Okay, no, no, so just, you know, to reflect what you know, from the IG perspective how they were reading it. So you should actually put the work to working group will also work on the following items. The word also is new also, you know, is actually a new word Oh, yeah. So if you look into the old charter, it's just like, you know, the work just like you know we will work on mutica stuff and then it's like the working group will work on these four items only yeah that's true and then what is below this like anything else outside of these four items is actually outside of the scope And we have to do a re-sharter. So anything red here was actually completely out so basically anything the pinwork I know if you read it very formally, okay? The PIMP has been working upon for the last couple of years was out of shorter So anyway, so we're going to that now. It's gonna be, yeah, yeah. And I'm pretty sure, you know, it will go, I hope it will go reasonably, you know famous last words that will go rather smooth because, you know, this thing will, yeah

00:12:04 - 00:14:01
Go to 00:12:04
Yeah, so it should be should go fine, I think. So working group last couple is the appropriate way to do this, right? For a charter, that's what our plan is No, so the way actually it works is I have this match button like re-charter And in that magical button, there will be like you know that will trigger like a re-shorter you know shorter you know shorter review proposal for the IESG. So then they will review this thing for being made public and I'm based upon that you know, the workers of loss or something like that. Should we do? a working group last call or not? Yeah, but maybe to show soon right now okay okay so this is actually you know come up with the proposal first, what you think actually is okay. Then she it over to me. I'll press some buttons left, right, and center then it will be reviewed by the iESG that it's going to be like, okay. And then, you know, then it can we can publish this thing yeah i feel like it might be good to have a few days where the working group can have the chance to we'll work it out I'm still you know the first reshart of that I'm doing so you know I'm like new in the but at least if you're if you're listening to this and you feel like something should be changed please let us know. It's a thousand times better than it was before, so I also want to say the main thing here is at least we're trying to just add what we need for the current documents and if you have like new topics you feel like should be here we can discuss changing the charter further later So, you know, in general, you know, updating a charter it should not be a heavy-lived kind of work yeah So this should not take like big, crazy amount of time i'm also pretty sure that the people you know who wish shredder, if we give them like a reshortering thing, then you're not going to oppose this because, you know, then I'm going to say, like, yeah, but come on, guys, you know, ask me to re-sharter and now you block it you know Hi, Nate Carson. So one of the things in one of my presentations today is that there isn't really a good home for multicast snooping

00:14:01 - 00:16:01
Go to 00:14:01
so it may be worth throwing that in here as well I know you said you wanted to cover existing work, but it's kind of this weird thing because it's layered two is owned by ICCLEE, layer three is owned by this group to some degree so. That's a good point And the document out there is currently described IGMP snooping, which doesn't cover ID at all. So that in and of itself might be worth looking at some point. Right. You have a working group document on, like, IGV MLD proxy, so that's there too but yeah. Thanks i wonder if i wonder if our existing like igem and MLD description in the first paragraph is enough maintaining, improving, adding extent. Actually, you know, we probably should add snooping on Kamala msisco systems so this second point segment routing is it for SR and SRV6 both Yeah Yeah, someone mentioned a list that we didn't. I think it was Greg, that we didn't need to explicitly say SR So that makes sense So, Talsecret, I'm not that much word as Nate on the IG snooping because it has IGMP in the name but we were yesterday brainstormed and the one protocol I can't for the heck of it come up with the name was from the switch to the routers to, you know, stop it forwarding traffic that's not needed. And I do remember that we had a proposal also in the IETF and I think it wasn't called IGMP right so maybe one of the tricks is, you know, whatever logically is an extension this was nicely be a logical extension, we just have to call it something IGMP, MLD, or PIM to have it past the chart or somebody comes up with a nice term for that, improve and add extensions to, you know

00:16:01 - 00:18:01
Go to 00:16:01
the realm of PIM, IGMP and MLD, right, so that we have more freedom with the names On the other hand, I didn't like MLD as a change in name anyhow but so, yeah, as long as we call it IGMP or MLD, I think we'll be fine. Other other maybe a little bit more flexibility on that sentence Are you suggesting that maybe we don't? need to include snooping then? So, I mean, I think we can do that explicitly, except then that some pencil pusher will ask us what we did if if we decide not to do something so that always the problem of explicit items for which we're just pondering and haven't decided Yeah, Gantor here again speaking as an AD so you also have the option of doing this in two steps, to do like reshortering first to help you with the pending drafts and then work on a more, you know, more cleaned up version you know more future proof on you know in a later time so so it's not an opportunity no possibility come Uh, who may it calling? to Nokia? Should we worry about OIMS stuff here? specifically? I don't see any anything on OEM No, we did it here At least some of related stuff has been done in Mbon D so it's a little unclear where it should go I feel It, yeah, it depends Yeah, I specifically want to make sure we don't fall into a trap for the OEM point to multi stuff that is in him right So one more thing, process perspective I'll just check with my fellow, you know, ADs. They say like, doing the working group last call of the charter before shipping it after me

00:18:01 - 00:20:01
Go to 00:18:01
So what about the EVPN? multicars related stuff? They already have a couple of RFCs for ISM and IGMP, the EVPN Multicons related like that. Those are two RFCs that they have multicars related Would that be now within the charter of it? No, there's, actually, several working groups working on multicast related work. Okay. And we don't get involved i think we have um like on the bottom here it says like open this support review discussions for multi-cats related work from other working groups. We're here to offer new expertise and two other work groups they need it, but I don't see there being any need, unless you do that we need to add anything about EV in here because they're doing their own thing Yeah, we can add it later if we need to but but yeah, this sort of like other work groups might ask for help in a way like with the point to multipine stuff, for instance, some of it might have been done in spring, but they felt like they didn't have the multicast expertise So I think we have to take those in the case by case basis Thank you. And Prasad Yeah, thanks, Mike Prasad, Cisco systems So a couple of comments. One is the MSDP Enika StarP, do we want to add that here? I mean, not that I'm saying that I have a proposal for MSDP or any other but that at least was part of the Multicast suite Yeah, with would say let's add it later if we see and there is some yeah MSTP is a bit special There might be some resistance to doing new work with msdp sure sure sure and then one question on the seventh bullet i mean i i understand

00:20:01 - 00:22:01
Go to 00:20:01
that the protocol left draft and singular draft I mean, I'm just bringing it as an example, are part of that, but is it the deployment angle also that we are considering here when you say design experience, is it the network design we are talking about? or just the? Just protocol and it's specifically because we have a draft right now that getting into experience and history of certain protocols multi-gast protocols i think if we added deployment, we would be stepping on work that's going on in M-Bone D because they have a similar they have a similar part of their charter so we're just specifically working on protocol specific experience information Thank you. Good question. Anything else? Yeah, he's on from China Mobile, I wonder how is the new Bantikasa protocol for the processes of that Because I have a submitted a new draft about about the msr 6 in the PIM program can we a discuss this technology? here and until the I see the charter until the adoption? we are just to decide whether whether in the group is that correct So, so Gunther here speaking, you know, as an AD. So this is the Amazon stuff, correct? Yeah, so there was a buff on that that actually ended up not so good and that, you know is no longer you know followed from a perspective so it

00:22:01 - 00:24:01
Go to 00:22:01
should not be here Yeah I think we probably get a many different opinions on that one. I've tried to distance my myself a bit from that because I was kind of involved, but if we're touching other working groups work like beer, for instance, and others that work should be done there. But if there's new proposals that have to do with multiple this is the place to address those kind of things as long as they don't involve protocols from other working groups I guess. Does that sound reasonable? Yeah, I would say at least, you know, our focus should be on what we have in the charter, but if we have time available, then we are usually open to people presenting things related to multi-cost But, yeah at least this case in particular it's not something that we can, you know do as work items at the moment I would say, but if you have time, we can you know, maybe discuss it a little bit Anything else? If not, then let's go on to their agenda, usually save new drafts to the end, but we're going to have Sandy go Flexalgo day week, a tough week a tough week, right? Happy to see you all here So this is Sandy, this presentation is for multi-topology in PIN and I presented this draft on behalf of our

00:24:01 - 00:26:01
Go to 00:24:01
co-author, Benchong, Stig, Jeffrey, and Homer Next, please So, this draft has been presented in last meeting And in last meeting, we found that there is a gap between the off-sea UFSI-9350, that is FlexA algorithm based draft and this draft so we find some solution to feel the gap, such as the software data plan. And also we found that the UPC 9502 can be used also in different deployment So we added the two references draft in the in the document. And also we are the PIM extensions to align with the modification and also we improve the description for better reading and thanks for the help from Les and P Peter much appreciate for your help Next please So this is an introduction of this draft We know that this draft wanted to define the PIM message extensions to provide a way to build the multi-cast tree through the combination of work instead of the shortest path. What's TED? TED means topology, algorithm, and data plane So all the routers are given PIM multicaster tree must participate in the same TED So we know that before using the method defining this document we must make every routers advertise the participation of flex eagles and the associated data plane. So

00:26:01 - 00:28:01
Go to 00:26:01
if we would like to use the software data plane we can use the print of multi-cast sources advertised as in the default topology And if we'd like to use the IP data plan, defining upstream, we can also use the prefix of modic multicaster sources, advertised with us associated flex egos So the software data plane draft has been presented in LSR meeting yesterday. So maybe you have some remember on it. So after we advertise the participation of the data plane we can use a method defined in these draft. So the first half router can advertise the test subduv, which associated with the group source info for TOV PFM function. Sorry there is a typo. Please ignore it And the last hope router, and the router along the path can get the upstream router from different tests around calculation and send the PIM join message with TED attribute to build the path. Next So this is the format of the PIM extensions And compared to the last version, we add the data plan ID in the group source in 4TAD, SubtOV, and the PIMJ join prune pad attribute So this EPID is used for distinguishes different data planning. So we can use this for soft plan or IP flex. There you go. Yeah. Next please So this is

00:28:01 - 00:30:01
Go to 00:28:01
an example and we know that if we use the shortest path in the figure, we can only get one path for the two multicast flows, because the two multifacted flows has the same source and the receiver. So there is only one path can be used to deliver the multi-cast flows and but if the bandwidth is not enough for the two flows, packet loss will occur So if we'd like to use a function defining this document at first, we must advertise the nodi participants for TED for data playing, so we can use the software data plane for example If we want to use software data plane, we can let every prefix of multi-custom source is advertised in the default topology. That it means the prefix is advertised as you-yo And after that, we can use let the first the FHR, that means the R1 in this figure, to stand this group info group source info, TOV associated with the TAD sub TOV So we're in the PFM function So every router in the figure can get the information and for the last hope router, that means R6 in the figure, it will use the associated TED to look for the unicast route from the associated FlexA algorithm and the the right upstream hope. So as every routers such as R2 are R3, and R5 will use

00:30:01 - 00:32:01
Go to 00:30:01
the same function to build the multicars tree. So at last we can get two different paths for the two different multicaster flows forwarding So there is no packet loss occur. Yeah So that's all the draft and we welcome more comments and review. And we'd like to know if this draft can be adopted. Thank you Any comments? So with regards to that second bullet point, the LSR, working group, they're aware of this draft and you've included the references to two drafts in this draft. Are they, are they? with, I mean would they expect this not to be worked on? in LSR? Yes, they would be one draft is afti already, right? And then the other one will be adopted in the LSR working group And yesterday we get our consensus about the solution. In our working group So they wouldn't expect to be working on this draft in that in they would not, they would not, they would not work on this draft in LSR. Or so will work on the software yeah so of the plane yeah so so so all the work is under the working group I think agreement yeah okay okay to add this work has to pieces. One is IGP-specific or? you know I'll go flex august specific which is happening in the LSI It has been done for the purpose of this trap, actually. But I think this is a multicast work which will happen here and we'll take care of the other one But we are coordinating

00:32:01 - 00:34:01
Go to 00:32:01
Okay, great I'm just curious and I think we should take it offline. I'd love to learn how in Unica traffic for different topologies is basically put onto that topology, right? So outside of ESR and MPLS, if there is, is even anything for basic IP traffic because I remember when we tried to do that, well, now maybe 20 years ago or so that was really painful and that was one of the reason why the equivalent for multicast wasn't adopted so I want to just see I love the idea right I'm just a little bit worried if we have something that only works for for multicast right how we make it best Peter Francisco, let me respond. This is not used for multicath it will not for unicast it will not work for unicast so this is tailored for application which built their own forwarding state independently based on the data that we give them So let's say, for example, I have an IPTV application and once have resilience. It has both unicast and multicast traffic right? And you also want to be able for the unicast traffic to have resilience right? So how would you do that part? So you can do you can use any of the existing data planes and you can even use the same alga for it. So if you, for example, have an SR, you can use SR to forward along the same topology using Unicast and you can use the software plane to use it for multicast yeah so i mean it's clear to me that with sr you can do it right So we don't have a fitting data plane without SR All right, there are existing data planes that you can use with Flexalgo, which are SR SRV6, and IP Flexalgo. So we have three. We are defining the fourth one, which is not a real data plane, but can be used multicat and other applications Which is IPFlex is, do I find a draft IPFlex data plan? So IPFlex data plane is for prefixes which are advertised as an

00:34:01 - 00:36:03
Go to 00:34:01
ALGO specific prefixes That's up to see 9502 Okay, so we do have a doc adoption call going on right now, so we'll just let it run for a second here. You can see it going on We'll take it to the list and I may email the LSR chairs just to officially have it on record like we did with spring just to make sure. Yeah, just me, you know, speaking as an idea again here So no issues with adoption card all, but may after the research, please. Okay, sure yeah also think, I know, we may have to, you know, see if they, are adopting it in LSR. I mean, that other job because we need that to move forward with this It's Peter Francisco here again. And we are doing this most for you, so we don't want to create the circular dependency that you're waiting for us and we're waiting for you. Right, sure yeah no we can certainly do the adoption call without waiting for LSR. Yeah Okay. Thank you, Sandy. Yes. Thank you. Yes and for no opinion and we will move on to Monkamanah All right PFN first forwarding, uh, enhancements You know which one? Yeah, the, yeah extension, PFM extension. This one this one, enhancements or another one? No, this By GMP, Mody, multipath?

00:36:03 - 00:38:01
Go to 00:36:03
Okay, that's one. This one Yeah, that's one Good afternoon so i'm going to present pfm s d extension for evan multi homing we can go to the next slide so very first question comes into the mind that why even this is the use case where exactly we are going to use this so i am describing two use cases here and both are from mostly from the best working group, EVPPen related work so the left hand side of the picture it's shows layer two multi homing where you have a layer two domain which is interconnecting with layer three domain and you can have IRB in those routers 1 2 3 4 that is one of the use case it is well defined in seven four three two second is you may have end to end layer three domain and we may have a layer three multi homing all active multi homing that is a new work being done in desk working group so these are the two use cases which actually creates a requirement here can you go to the next slide so why these draft in the best are bringing requirement for PIM and is it something which PIM has to do or somewhere else? this has to be solved? So, if we look at the simple example, if I am doing M multi-homing and I have same subnet which is present at router one and router two which is 1011 slash 24. And every on the top of router 1 is layer 3 so what is going to happen in the IGP reachability S1 and S2 which are spine are any of the PE boxes they are going to see both of the router as a next hop for this prefix so if PIM join reaches to S2 it is going to see ECMP path

00:38:01 - 00:40:01
Go to 00:38:01
and since it is so it could be ECMP are you depending on what kind of topology you have, but if you have ECMP nothing prevents S2 to send its join to router 2 because router 2 is also advertising the same prefix on the other hand when we are started sending the multicast traffic from the source it is a port channel and port channel has two member link at this point of time switch has to make a decision that which port traffic has to go on and nothing prevents this switch to pick left-hand side of the port so traffic goes to router one the end result is we have traffic on router 1 we have join sitting on 2. So the receiver is never going to get the traffic. Next slide So now the question is why? why pimp should solve something which is being posed by EV PIN multi-homing so truly speaking if we look at this as a whole network EVPN has no role to play in the upper side of the network. So EVPN is termed right here at 1 and 2. And the whole advertisement process are the information about reachable It is of any of the layer 3 protocol One can potentially say that can we do something with IGP but IGP cannot really carry any information associated with per flow so the next best choice we have is doing extension to existing procedure in PIM and the existing procedure in PIM is PIM flooding mechanism for source and group mapping and that is what we are going to use next slide so if we look at just requirement that we have to have a way where S1 S2 can really know that where exactly the source is active that is number one. And the second thing is if we are using flood mechanism this whole PIM domain could be really big. This information is not needed in the rest

00:40:01 - 00:42:06
Go to 00:40:01
of the world. This information is useful only at the point where you really have to make a decision between whether to pick one or with to pick two so these are the kind of high level requirement but as we move forward if working group thinks that there are some more requirements which needs to be handled for this case they can be added later next so how exactly this draft is solving this? problem is initially when you have if multicast source is not active we cannot really spread that information where the source is going to be active it is it is not possible to know so initially if pimp control plane is coming up first pym is going to build tree as is, as it does today. But as so as your multicast source starts sending traffic and if source is active, now at this point of time we are going to use a pfm to flood the source and group info now to remember that the initial pfm was defined only for ASM not for SSM But in this case, we have to do flooding even for SSM cases so as soon as source is active we are going to advertise or we are going we will start flooding the information so that S1 at S2 both are aware that this particular SG is active in one so that it can change its rpf according So next step is getting feedback from the working group. Current draft just says about flooding mechanism there is an, we have worked on one algorithm, we are trying to simplify how to prevent the flood in the whole domain how to restrict it within the boundary of where that information is really needed so that will be the next step which we are going to add in the draft Any question?

00:42:06 - 00:44:03
Go to 00:42:06
Thank you very much, D.T Man Canana, this reminds me a lot about the issue that we've solved with MOFAR on the uplink trunks. Could that be the same? procedure that could be feasible for this issue as well? Because if you go back to this line the topmost two routers is one and as two if they request via MOFR are both streams from the upstream router, then you basically have the information available via both links so that will require another protocol extension because in this case one and two just consider that one and two are multi-home three and four are lan and between multi multi-homing and lann as one and s-2 will have no way to different whether it is because of my ECMP path is because of multi-homing or it is because of land segment in the land case you don't want to do to join only in case of multi homing mifrr way you can do okay then we need a different mechanism here Has this been discussed in the list at all? I have this job is present there for something now. Okay. Have we discussed it on the list? you know i think once we had presented in maybe year ago and that's when the question came that do we really want to solve this in PIM? whether it should be solved in EVPN landed? itself okay so i wanted to cover that part that why eVPen cannot solve this

00:44:03 - 00:46:01
Go to 00:44:03
Which one is this next one now, Steve? Let's see it there you see it there? I hope you for it's Hold on just a second Otherwise, I just can go away. Otherwise, what? Others can go. Oh, that's true yeah. But let me just see if we can It's not out there It's not going to show up now, but we can probably share screen but I don't have that Let me ask me, uh, okay, yeah, why don't we do that, yeah, okay yeah, still we'll go, and then I'll figure it out Thanks. Okay, so you're is, uh, Okay, enhancement Yeah, I am Stegian I'll present another draft on PFM so I presented this a few, few meters now. The next slide I'll be fairly quick about this I think many of you have seen this already. So this draft does two things One is the original PFM, RFC, it only has a TLD for announcing S-comagi If you want to announce any additional information,

00:46:01 - 00:48:01
Go to 00:46:01
about the flow, there is no easy way of doing that you could put it in a separate tlv but you hold you associate it with a particular S comma G if you do that? So what this proposes is a new TLV that has s comma g but also a low sub sub-telv, so you can add any kind of information Of course, those sub-TLVs would have to be defined here and there could be many different things but at least it allows that to be done I had one proposal earlier about having bandwidth, for instance but it could be any kind of data associated with with a flag thing this draft does is a forwarding enhancement. So basically if you have multiple point-to-point links between two routers we can forward a pfm message just once So this works the same as a say, same way as BSR forwarding where the like RPF based, so we need some special tweaks to basically do a loose RPF check for the sender to send this message on any of those links because we don't know which link happens to be the RPF for the receiver Okay, next slide so there's a lot of editorial changes trying to make the draft more readable a lot more text in there One change that was done was to have separate capabilities for the new TLV and the forwarding because those are two completely separate enhancements So you could potentially support one and not the other or say maybe both might be supported but the admin only enabled one of them. So in this draft, we actually have one hello option with two bits, like two flat But I'm starting to think now that two separate hello options is actually easier because you don't need to worry about AI

00:48:01 - 00:50:01
Go to 00:48:01
registries for bit fills or whatever But that's a minor detail we can discuss further The other new thing in this draft is with the TLVs so we want to be back compatible so in the sense that if you have a you're forwarding a pfm message that has this new TLV with an SG and some sub-tLVs, if you forward that out and interface, where we know there is a neighbor that doesn't support it we can pull back to using the old TLV You will actually take this TLV probably type 2, change it to a type 1 and remove the sub-telves. Then it will look kind of like the old TLV and the old routers can process it Another way of doing this could have been or might be that the first up router sends to messages, one with the old format and one with the new format The only thing is the first up browser can't really know easily if there's some router out there in the network support one or the other versions, so it would have to be maybe up to the admin to enable that This fallback is more automatic okay next slide so would be quite happy to get any input on this we should change differently. Do you have ideas for what this subtilvies should be? I guess, yeah, by the way, the, um, the, um, one use case as well because you want to save a particular flow that you should use that particular algorithm And at least the next steps you are planning is to implement this to see how it works in practice and maybe improve the specification a bit Sunny Zan ZTE it Sunny Zanzanzhi, my question is about the type of the draft. The draft is an experimental type, right? Yeah. But if at least there is

00:50:01 - 00:52:01
Go to 00:50:01
two extensions, we'll use, you'll reference this draft. But the reference to experimental is down-roof reference Could you please change it to standard? well yeah the other thing is the the pfm itself is experimental So, um yeah, I mean, I would be interested in you know, at some point in time, hopefully you know, making it the standards track document. So just have to see if there enough interest in the working group but thank you but yeah see what you are saying. So at least for the, yeah, the flex I'll go. I mean one option would be to on use joint attributes in that or or get some permission to say that we can done reference in this particular case But yeah, we have to think about that. Thank you Any comments? All right Yeah, I think that's it for me. Good, yeah. I'm just going to share my screen, Moncomana. I can't load them But we're just going to do that Yeah, we got it Good afternoon. Man Kamala Misra from Cisco

00:52:01 - 00:54:01
Go to 00:52:01
so this is a sort of date on one of the other draft which is PIM backup DR procedures I'm going to present on behalf of other authors Just to give a little bit of background that why we start this work, it was mostly to have some kind of enhancement in PIM where we can achieve faster convergence and in process of that initially we did have another draft which is PIMDR improvement which defines some procedures with respect to PIM protocol extends about how exactly we can create a backup DR and then how can we get faster convergence but while working on those drafts we realized that there is another way to do that and that will not require any protocol extension and that is what was defined in PIMBDR draft Even though we progressed further and both of the draft got adopted by working group later or later stage there were comment that which parts would be covered in which draft and whether we want to make both of them as a rfc so today what i'm going to present is the scope of this particular draft that what we want to keep in this draft and maybe we still make progress in the other draft So, the scope for this draft is going to be very simple and two steps. The first one is how to elect backup DR without doing any team extension And the second one is the sticky DR behavior sticky DR behavior so both of them have been implemented as well and the now this draft is informational, but to me it looks like we may have to go to standard because that this sticky DR behavior requires some INA registry registration for PIM DR

00:54:01 - 00:56:03
Go to 00:54:01
value the priority value So next step will be we will be updating the draft within this defined scope and I think we'll have to give reference to the other PIMDR draft because that is what was the comment last time That's all. Any question? Sanizong ZTE, I think the true solution is about two separate perspective of the problem So we think one solution is a stick and the other one is non-stocky. So we think the operators or the enemy, the next administrator can choose the solution from different deployment. So we think both of them makes sense Thanks All right, let's see if slides are here I've got a zero card Yeah, come on up Nate. We'll see which ones And what's the other one? Would it be? um, okay, whatever. I have both of those. They're already loaded So what, which one would you prefer to start? Oh, is your comp one. Okay

00:56:03 - 00:58:01
Go to 00:56:03
Okay, good afternoon, everybody So we have three documents that were drafted less than a year ago, I think, at this point and just kind of I've been giving updates at every IETF meeting about that So this is kind of the update on those Next slide, please So basically what we're doing right now is we're working to get this into a product as a perfect concept, but not actually releasing that that product in the form that is in the document So just kind of a refresher on how this works You have the random group ID that you're generating and from the you generate a link-scoped IPV-6 multicast address, and then use MDNS to publish a PTR record for that MAC address that corresponds to the IPV6 multicass address but use in the ether.ar.arar suffix So the example down there, which is taken from the document you have that top line is a random number, then you have the link scope IPV6 multi-gas address then the Ethernet multi-gas address and then finally the record at the bottom next slide please so with our proof of concept, we're basically going to change the suffix at the end So what we've done is we have our own range of multicast addresses that were allocated to Garmin Marine so that's a pre-allocated range of numbers. It's out there in the IONA document or page for that and we're basically taking a subset of that range and saying, we're going to use this for dynamic allocation. And then the random numbers that we generate will be within that range so as an example here that range would get or that random number might be 2E5. That's the following line would be the MAC address for that. And then the last line would be the corresponding MAC address with the blue net suffix instead of the ethas or . ARPA. So the idea here is that they

00:58:01 - 01:00:01
Go to 00:58:01
conceivably could coexist on the same network should the standard be adopted and the product not be at a point where we could update it So the idea here is that we'll take this proof of concept and use it to really prove out the idea and hopefully use that as kind of further evidence that the that we should proceed with standardizing the document Any questions about that? I've got a quick comment How, I know this is a bit new to you as far as progressing the drafts, but how how, how far? do you think this has progressed? I mean, do you think it's getting mature enough to start thinking about? the document and sending it out of the working group and doing like a working group last call or do you think there's still a fair amount of work that needs to be done still and the reason I asked that is Dino last time on his related gap draft is it's in his abain that that draft is done So we kind of need to eventually sometime in the near future start doing some working group last calls So on this draft, what do you think the maturity is on it? Yeah, so I think between the three documents, definitely the first two are pretty mature, ready to go, and the both of zero comments and the gap depend on those. So I think it's kind of natural that we could proceed with that, regardless of how comfortable we are with the third one. Okay. The third one I think, is, I mean, we have a perfect concept with code out there already that people could experiment with if they want This perfect concept that we're developing right now is just kind of, kind of the extra proof So I could go either way on that So one thing is you know, we're kind of focused on routing in this working group and there's a lot of application people out there that are not in this working group. So I think we should

01:00:01 - 01:02:01
Go to 01:00:01
at least look into how we can get input from some other working groups in the IETF that know about multicasts more from application points of view. Yeah I think, you know, it might be perfectly fine that, you know, it's, it's done here in PIM, but at least it want to get input from, from those people, I think Okay, so I think along those lines, the first two documents would be definitely within the wheelhouse of PIM because it's focusing more on what's the problem and what more kind of the groundwork that we need to lay in order to allow the development of dynamic multicast allocation algorithms and then both gap and the zero comp algorithm are implementation of that. And so I think you're right, the zero comp one could definitely use input from more applications people Okay, so now moving out of the next topic we have basically implemented multicast snooping in one of our networks and we've noticed some traffic patterns in there that are not optimal, so wanted to kind of bring those problems. We brought those problems to the meeting, discussed it with a number of people and kind of came up with the latest of what our thinking around on this is So Joseph Wong, my colleague, he's here as well. David is not here, but Joseph and david oran I have been working on this for a while now. Next slide please. So first question, and this kind of leads into what we discussed with the charter is, is this the appropriate venue to discuss this? RFC 45 which is the only RFC out there, it's kind of an informational RFC and that was developed by the Magma Working Group and last, it was released in May 2006 so there's a lot of information that's become available since then specifically with deployments and stuff, especially what we've learned with our network And so I think

01:02:01 - 01:04:01
Go to 01:02:01
that this is probably the best venue for it So that's why we're here and not with I-Triple-E or something. Multicast snooping kind of is in this weird layer two, layer three thing and so my thought is that we would kind of tend more towards IETF as the appropriate venue So just kind of a reminder and probably most of you don't need this, but the IGMP and MLD that's used by host to report the multicast group membership to the neighboring multi routers, and then the two messages that we're focusing mostly on here for this is the query and the report messages. But when we look at how those report messages are used and specific, within the multicast snoop and they talk about reports suppression and how it's important to make sure that you're not distributing the reports to every note on the network just to the multicast router Next slide So what we've seen is that there's problems with the forwarding rules both in the data path and the control path, that's leading to this. And we'll get to some examples networks here that kind of really illustrate the idea here. But the are excerpts from the RFC So specifically the highlighted or the bolded text there must also be forwarded to the router ports That requirement is what leads to the non-opt traffic distribution. Next slide, please And then there's also this requirement for the control path, which is how you're distributing the reports here And it says something, the top line and then it immediately says the next line. So it's saying forward those membership reports only to those ports where the multicast routers are attached, and then it's saying alternative don't forward it to the ports on which hosts are attached. But there's a gap in there, which is do you forward it to switches or do you not and so that that's something that we think would, you know, clarifying that would be helpful for sure but it also kind of feeds into maybe gets to the root of the problem that we're seeing here

01:04:01 - 01:06:01
Go to 01:04:01
Next slide, please So this is an example network here. You've got on the bottom, you've got host one source on the left host one destination on the right, and you can see that there's no other source or no other hosts on the network that are needing that traffic. But regardless, it's actually being forwarded up to the querier s1 which is acting kind of as like the multicast router in this case But nobody needs it. And that's that's problem. That's not really an optimal distribution. On the other hand, with the blue arrows, you got the host one, host two source That's going through switch to switch one and into host two, the destination. And that's that's an appropriate, you know, you should definitely forward that data up to the switch one in this case, because host two needs that so what we're seeing here those two forwarding rules that I mentioned on the previous slides, that's kind of the root of what's causing this. The first one is that, well, the packets must be forwarded to the router, forward onto the router port So if you don't do that, then you get rid of that that red stream of data between S2 and S1. Next slide So now what you run into is if you're not forwarding the data to the multicast router, the stream from host to source to destination isn't going to get forwarded either. So how do you handle? that? Well, the reason that that's happening is because the membership proposal as we mentioned before, they're only being forwarded to the multicast router. Once it gets there, they're not being forwarded down to the rest of the network infrastructure So that becomes the second problem that would need to be addressed. So next slide, please So if you forward those membership reports to other switches then you'll see that the data is distributed only to the locations that actually needs that. So that's kind of the two things that we're seeing there. Next slide

01:06:01 - 01:08:01
Go to 01:06:01
please. So the problem there is, well, the data is going up to the multicast router because the multicaster router needs to know whether to get that data off the network to somebody who's needing it off the networks So because it no longer has all the data forwarded to them it would not be able to distribute it traffic. So there's a couple different ways to look at that One is you could say, well, maybe the multicast router needs to take a more active role in requesting that routable traffic to send an IGMP message or or something along those lines But at the very least, we think that this is a problem worth solving for the layer two network only. And so in that case, we could look at it and say, okay, of all the different multicast traffic out there we could definitely say membership reports for non-routable IP addresses don't need to be forwarded onto the multicast router but you could still forward those membership reports and all traffic associated with routable multicass data up to the multicast router So somewhere in there between just solving this for link local or placing requirements on multicast routers to take a more active approach we think is probably a good solution for some sort of document to maybe do an update to 4541 to kind of explain this and optimize the traffic flow. So next slide, please so the other issue here is the report suppression and we talked a little bit before about that gap between they're saying forwarded to multi-guise routers don't forward it to host, what do we do about switches? So our suggestion here is to not forward those membership reports to ports on which only hosts are attached Determining that, you know, where the hosts are

01:08:01 - 01:10:01
Go to 01:08:01
that's not really, I mean, it's described a little bit in the 4541 document as far as listening for query or messages, but there may be more protocols that we need to build on top to really paint a bigger picture of what's going on of the layer two network there So next slide, please. All right so any questions So it sounds like the summary is that you're suggesting that 4541 needs a be updated. Yeah Yes. Whether it's a rewrite or I mean, I don't know the easiest way to do that. What's, what's? standard practice for that nowadays like that Abyss document or what? Is that really the way to go? It's kind of an old informational draft It's just is like a small update, you can do like an errata thing which will be done in the tracking for like a future update in a beast document. So it's actually more like a yeah but then at least it's tracked you know but I think formally it's probably going to be like a beast document I guess yeah like a beast document I think is kind of you know more typical if you want to progress it on, on standard track or something like that. And if you want to work on like errata and fix like everything in the original document but if it's like some smaller updates then it's could just be an rfc that updates the original rfc and again networking. So I'm all for standardizing a layer violation, which is why the, you know, back then we did do it, but also because every vendor was experimented around how to make this thing best work

01:10:01 - 01:12:01
Go to 01:10:01
So if there is sufficient support in the working group but I wonder how many, you know, are still active or, you know, nobody even remembers how IGMP snooping works i mean i'm not sure how much active development is on that part. And certainly I'd be surprised if even within large companies with many different implementations, there's consistent behavior So I think that would be against making it more standardized because that would really create pain and work for existing implement And so not sending to the router will not work for link local Scope IPV4 because I don't think we've completed eliminated even from IGMPV3 I'm trying to remember, right? So we didn't we didn't have these routers much also send IGMP reports for 221 00x. Right so if I I'm not no hundred right, but there was always one of the problems that the routers traditionally never did that. And I'm not sure if they're correct doing it now and what we did in the latest business we're just getting through to RFC editor So there may be some obstacles IPV6, I think to remember we did an MLDB2 So those are some obstacles But, yeah, other than that, I think the main issue that you were saying, I think that that's a question of how to recognize router ports, right? So, and I think maybe maybe there there there there is the useful trick that I was mentioning yesterday that even in IG snooping switch could send out a PIM hello with DR priority zero I don't want to be DR. I'm not going to forward you any traffic, but I'm a multi- router sent me all the traffic right so that would that would problem, right? So that may be another update we could do to IGMP snooping if people review

01:12:01 - 01:14:01
Go to 01:12:01
that, right? Or any of the other ideas that you had and that could go. So I would stick with it informationally, unfortunately, right, just because of the possible pain for implementers that don't want this but yeah if there is enough interest to revisit that document Jeffrey from Julie I missed some of the discussions on earlier slides If we have time, we can go back to them But if you don't, we can have offline discussion Which slide would be there? Yeah, this the original problem description so I believe the membership report should always be sent towards the router because the purpose of membership reports is to let the host to the routers know that there are receivers there, right? So why did we stop the membership reports? as this is kind of a limitation? of, I mean, it's probably my my lack of PowerPoint skill the membership report gets into the switch one there, and it is processed. It's just not forwarded out to S2. To meet that, this to be a bug And that's kind of what we're seeing too Yeah. And it might have been in the that gap between what is a multicast router versus what is a host, right? And another thing is sending the traffic to the module multicast router, at least in the ASM mode that is really so that you that the hustle hop routers can send out resolve, can send out register message so would it be required

01:14:01 - 01:16:01
Go to 01:14:01
for a non-routable multicast traffic though Oh, I mean for, uh, for the, uh, for the, um, right so I'm not that. Okay OK. So when you do the correct thing, which I think even is in the IGMP snooping one one of the, so in the absence of any multicast router, just the networks you're interested in one switch needs to be the multicast query at the IGMP query And the queries are the ones that make you kind of being a port to be flooded to so whoever is the query becomes the root of the tree to which everybody sends the traffic upstream so that the downstream traffic can go from there. The downstream traffic is controlled by the IGMP membership reports you have Questions, how do you get the upstream traffic? that is flooded and that is because you're flooding to the query Right, yeah, and that's exactly what we're seeing So you're saying that there is no router Well, if I I'll follow up offline. Okay, thank you One more comment here So if you want to limit link local packets like scope 2 for V6, for 224 slash 24, one issue could be that, you know, the router itself might be interested in some of those linked local packets because it's participating in some protocols it could be NTP or it could be some, yeah, various protocols. So and and also for the link local not all implementations actually send IGMP reports or MLD report because they assume that because it's linked local they will just receive it anyway so

01:16:01 - 01:18:01
Go to 01:16:01
I need to at least think more about it if it's safe to limit it. But I would say ideally if the router really wants those linked local packets, because it has some specific protocol, it would be great if the router sent an IGMP report or MLD report. Yeah, yeah we agree. So to answer your question is there's a couple ways to do it, it sounds like, and one is you can just do a pretty short update draft to update 45-41 Or you can do a much more involved rewriting of 4541, which we've done with it and tortoise is doing that right now with another draft but that's another option as well Yeah, we're kind of flexible. I think if there were other people looking at 4541 and seeing other issues with it that we could collaborate on a more extensive this document. But aside from that, we could just write up what we're focused on specifically and then kind of perfect it from there that's what you did first step yeah You know, I mean, that there were a lot of things we could do but the industry was very lazy, right? So even just one of the painful problems that we still haven't fully solved, which is, you know, avoiding fallback to IGMPV2 in the presence of older stuff, right? Switches could help with that But yeah, that stuff never got through the industry. So we'll it's unfortunately old industry, old stuff so it's always hard to figure out how much interest there is Yeah, we've been talking about that a lot this week as well And so that may end up kind of going in organically. So we'll see, start small and grow up as it needs to, I guess. Yeah, I love it thing for that old draft, there were lots of different implementations doing different things and this was like almost 20 years ago. So maybe in the have some more perspective and we have some ideas what worked what didn't work or do we want to recommend certain things? Or it might be that we just want to stay neutral and i'm not sure but yeah i actually remember many many years ago

01:18:01 - 01:20:00
Go to 01:18:01
there was a presentation in team working group talking about how the first half router could send some signaling based on the PIM joints it received into the layer two source network Okay Right. Yeah, I was thinking about that too You know, we, you're sending this to the first up router because you don't know what the router might want but potentially if the first-up router did know, it could send IGMP reports or something into that layer 2 network right for them thanks everybody Yeah, he has two Is it just a small presentation for both? Yeah. Perfect everyone. This is from Telefonica. We'll present this is doing work with Itosh So I will present on behalf of him So, yeah, we have packed the two groups in once just one presentation because it's the same story Please, next. So a little bit of background on this, the idea was to extend the capability of the proxies for supporting more than one upstream interface So RFC 4605 basically does not support that multi-home-in situation, just one single upstream interface is supported, so the idea here would be to extend that fact. The motivations for that are so many cases where these could be necessary, maybe robots, if you want to have, collect the traffic from different trees or even connection to intra- internet or even using different

01:20:00 - 01:22:01
Go to 01:20:00
technologies for getting the content next please so we are working now in paralleling to documents and even there is a third one on the horizon We have this draft IETFP in multipath proxy which is the somehow described the framework for this. We define a number of potential interface configurations for a activating one or the other one of the available actually interfaces We are considering different criteria selecting the absente interface based on the channel on the subscriber, that this is a topic that is under review now i will comment later on or even based on the priority of the interface. That could be, somehow the operator could determine what could be the priority. That would be for the static configuration Also, another option would be the control-based upstream selection we have not yet a document on this but even though we are working on that, and the idea here would be to use a kind of SDN controller or centralized controller for signal selecting the interface So that is the framework of the concept and we are in parallel working in one of one solution that would be the draft that you can see on the button, that is basically a signal based solution so that we are defining some stations for IGMP and MLD for that purpose So next please. So we will go now through the framework document some some few updates on that next please so basically the status this that was adopted in before last IETF meeting. During the adoption process, there was identify a relevant issue that is in relation to this subscriber-based apps in selection So that could be problematic in situations where the link is shared between the subscribers because actually we cannot identify clear leaders subscribers. So we are working on a solution for this

01:22:01 - 01:24:01
Go to 01:22:01
We are looking at the ERFC 92, 790 for the extensions of the messages so in such a way that we could somehow play with the with some signature of associated to the subscriber leveraging on those stations for basically clearly identified the subscriber and then be able to do this selection of the upstream interface based on that The next version of the draft intends to cover that point. Next please So we quickly go through the one of the solutions, the one looking for signaling for this that this is this other draft next please So here, just a insisting on the point there are two aspects to consider for whatever solution, one is the policies for how we select or in what is the rational for selecting one interface or the other the subscriber base has said is under analysis but we could select the upstream interface based on the source and the content or only the content or only the source or even the static priorities that we mentioned before For this dynamic selection, we understand there will be three different signals situations. One would be the the point of retrieving the what is what is being, I mean, how many upstream interfaces the proxy has, and also what is the content around per each of the upstream interfaces that would be the the first motivation for signaling the other one will be the request from one or more apps in interfaces the content and finally the checking of the membership. So what subscribers are consuming the different contents of the proxy can maybe understand let's say who is consuming what for the last part that will be the signal in situations we are leveraging on the sections of RFC 9279 Yeah, we are defining the messages and what could be the how the signaling will go

01:24:01 - 01:26:01
Go to 01:24:01
Next please. So the status of this we have had updated the lab according to the new terminology in the framework document because at the beginning we were referring to that as multiple support of multiple apps upstream interfaces now we are going in it towards the terminology of multipath so we have added the draft accordingly we have also conced extensions for IGMB in the previous version, we were focusing on MLD, so we have generalized to both when possible and when applicable, we differentiate the terminology for MLD and IGMP We have also others on security considerations For instance, the fact that the malicious applications could request content for multiple interfaces or creating congestion So this is something that should be prevented And also some considerations about the frequency of the messages or the number of TLBs on the messages So yeah, these are things that we need to take care of to avoid in attacks. The next step, to be to keep collecting comments, so any comment is more than welcome I'm preparing a new version of this for one to two and hopefully having the other document the third one that would be the one for the jump model in one to two as well so these these were the updates if there is any question Take it Yep, thanks I think we're done then. Anyone got any? they want to say? All right, so I think we'll um, we should send something on the charter to the mailing list in a few days and do maybe two weeks working group last call on the charter and then we'll hopefully

01:26:01 - 01:28:03
Go to 01:26:01
progress with that pretty soon okay okay thanks everyone see you next