Montreal PIM raw minutes to be cleaned up by pim chairs:

yeah that's right Turns out that it's actually the optimal thing for language models No, isn't It's an artifact of creating a layer two overlay on top of a layer three network It has nothing to do with replication comment Now we can start. OK. Let's talk about it. So you Okay, welcome to PIM Next slide This is the note bell. I hope you all have seen this before Yeah, you should go and look this up if you haven't seen it before, but it's more or less how we are supposed to behave when you are in the IETF Okay, this is the agenda It's quite a full agenda um so So yeah, any comments on the agenda? think TORLIST you were asking if you could be moved up a little little or yeah um yeah thankful just go to the next slide slide. So since last IETF, we actually published several RFCs. So all I worked with it revising IGMP versus 3 and Emily Wurston 2, progressing on the Internet standard has been done so thanks a lot to Brian for that Also the new RFCs, it's kind of cool how the the IGMPV3 ends in 76 still, and it's

00:04:01 - 00:06:00
Go to 00:04:01
also standard 100, which is even better Yeah, so I don't know if you folks have probably all seen we're reaching IETF 10,000, but most people ignore that the real IT process, all the pain is to get work up to a full standard And well, luckily, you know it got IGMPV3. And so I thought there was time to actually memorize that so I got some mugs done and there's one special mug with the name on it Yeah, Now this is a group effort. There is a mug for everybody in the back of the room. So maybe at the end of the, no they don't have that's just the one special one that's a special one but yeah, please everybody pick up a, mug from the back at the end of the meeting I'll need to quickly that's why i wanted to change go over to core next door, I'll be back and we can deal with the mugs at the end thanks all right great yeah thanks awesome All right uh yeah we also got standard 101 and the 3228 biz related to that the IANA considerations is BCP 57 we got the 11thel bis that Horlis is working on. That should be nearly done or pretty much ready for publication I guess I'll talk a bit about that soon Also, other drafts dear improvement We'll see if we can pick that work up, BDR will we discuss this meeting let's see Also other drafts um multi -point policies and IETF last call, maybe it just ended, I'm not sure

00:06:00 - 00:08:00
Go to 00:06:00
Policy ping workers requested publication for that that. Some June Prune attributes for LIS got published RFCN the 798 the uh draft is an RFC editor queue, so lots of here Our AD has been very busy busy. And we got some yang drafts that are not discussed this meeting and also lessons learned is not discussed today and last slide Yeah, I wrote here that gap and stuff are not discussed today, but the bill actually be covered together with the problem statement by Nate soon Let's see see yeah the multipath work it's on the agenda. I'll talk about the forwarding enhancements, PFM, the deterministic caching is not on the agenda so that's the status. Any comments? Yeah, real quick. I think the gap up through the zero conf, so the first four are going to be discussed all under the auspices of the problem statement one Right yeah, okay, yeah, thanks okay I guess you're ready for the first presenter it's warless All right So I thought we were done last time. So then Slick brought up next slide. Oh, wait a second, that's me me. One question about that permanently joining, which I couldn't figure out a good reason, so I went

00:08:00 - 00:10:01
Go to 00:08:00
back and then, stumbled across some which you should never stumble across things but that one was too important to ignore And that is oh my goodness i don't know Okay, I should really upload PDFs. Okay, persuaded me me. So there is RFC 1112, which is the still valid standard for IP before host requirements And that one actually says in section 337 in summary that all hosts should support IP Multicast, but may support IGMP having actually the explanation that you really don't need IGMP. Nobody needs IGMP Multicast is link local They didn't say it, but that works perfectly fine without IGMP, which is true which, example, let's say, was perfectly used and I think it's still used 40 years later before Dino implemented IP multicast routing in iOS, right? there are, you know, devices that perfectly run link local scope multicast for OSPF and other groups without any IGMP But RFC 1112 doesn't have even that option right it has layer 0, 1, and 2, and 2, 2 says multicast sending and receiving with IGMP so So I thought long and hard. So I added layer to L which basically says it's sending and receiving, really without IGMP and should only be used for link local scope multicast. And then basically the point of course is now that IGMPV3 is a full standard we also start having a requirement in the document that says you should support a layer two and only if you cannot support layer two, then should support layer two So that's basically exactly what 11 says, except that it's upgrading the IGMP requirement also to assure. I cannot come up with a must if the group fields we could add the mass must and upgrade

00:10:01 - 00:12:00
Go to 00:10:01
that. is fine i just was trying to be as backward compatible as possible And for V4, I cannot find a justification for a must right? Just because we're multicast fans, we want to go back to the IESG and say this is actually more compatible with, you know, 40 years of deployment now um 1112 was so that's why it immediately goes back to full standard And a must maybe hindrance to that. So that's the before change and I brought this up to the mailing list when I had it. So of course, Brian seemed to have done exactly the same check for V6 I was already talking about that that and click click next slide no Where? Okay Oh, that was we six. Yeah. Sorry. Wrong order, Brian was pointing to 42, 91, which I was already, I had read that but I hadn't really kind of taken the interpretation that Brian correctly did, which really that because base requirements for IPV6 address management does require link local multicast, you also must have multicast so now we have the requirement in there you must do multi right? But of course, it should be level two. And if not, then it must be level 2, right? So because for all the stuff that V6 host requirements require, it's link local scope, so it could also be done without any MLD But of course, it should be level two with MLD right so so basically last IETF we didn't have an RFC with this one that was requiring any multicast. Now we have a, you know, should multicast V4 and V6 and, you know, even must V6 with even

00:12:00 - 00:14:00
Go to 00:12:00
if you're not using MLD right so i hope there is very little evidence that there are any devices that are don't doing V6 with MLD support I wasn't there in the early days that much. I think Stig might remember even more. can't remember the first implementation of V6 multicast or V6 IP, IPV6 in iOS or other So we may want to go back and revisit that in detail, but basically this sounds like a saying place to do And then the final one, and that was Sticks asked. So I put that back have a new section trying to explain that went into the Linux kernel of the place to try to figure out how that 224-001 is being handled and indeed it is seems to be still statically joined i couldn't find any really good use case for that the only technical reason which i added to the explanatory section is that it allows you to avoid kernel level APIs for joining that group for some of the things you may do over that group, right? And I do see that in the Linux kernel as well So that was the only justification, but in the end, main justification is it doesn't serve any useful purpose but we have had this requirements in there since 89 Doesn't seem to have hurt anybody, so we're keeping it. That makes us happy with the IESG again folks yes tigir one thing that maybe bothers me slightly is that i think the mLD RFC says that it's required to send reports for link local yes yes sleeping devices. That's true. I'm saying level to L is, is there is, if you cannot do level two right for whatever reason right so um i was trying to make it as compatible with everything that's out there as possible, right? So and the 4291, I cannot translate myself into you must do ML because you can do all the link local scope that are required by 42 92 those are all link local

00:14:00 - 00:16:01
Go to 00:14:00
scope IPV-6 addresses. They will work perfectly well without any MLD right? So that's why the suggestion to say you should do level two and level two says you must do MLD right and if you cannot do that then you'll do level to L which is you can only do link local and that's your only way to not do MLD. But MLD is not changing MLD must do signaling for link local. So that's not changing. But you have to hope that there's no sleeping switches that require reports But then, of course, the link local without IGMP or MLD doesn't work because we explicitly put in also the IGMP and MLD snooping, we put the you must do snooping for link local in v6 so yeah. Okay, yeah, thanks so uh so you believe that it's ready for publication now? or? As much as I thought so last time, I think this, this change really was good and useful because now we have the two V4 and V6 host requirements I think well embedded. We have upgraded multicast to now a should and a must, which was hidden in some you know other RFCs in the past. it was good that we did this one more round but yes of course I think it's ready. But we'll still have IESG review right so from that perspective the question is do we still feel that in the working group there is still anything? we can do to significantly improve it? Right. And I don't think there is is. Yeah. So, yeah So I think we should I think we should a working group last call just to give people some deadline for giving comments if they have any but if you don't get any comments then i think we are probably good but yeah I also want to review it myself again but yeah okay thanks Okay, I think I'm next on the agenda

00:16:01 - 00:18:00
Go to 00:16:01
Yeah Yeah, so this is a draft I presented a few times before before. I guess I skipped a couple of IETFs wanted to do some implementation work before I came back here again So, um, to repeat what this is for people that haven't seen it before So we have this mechanism called P.F.M can flood information in a pin domain about active sources the way it's defined to is you have an S-coma tlv for a flow But the problem is that it's very hard to add any additional data to that The obvious way of doing it is to have TLVs, but the way it's defined today, you can't really do that So this is defining a new TLD that explicitly can have have sub TLDs. There are other part, which is i've been what i've been working on is this reduction in message forwarding So So yeah, I kind of said this part already I don't know if it's obvious, if you have one TLA with Schwarzen Group and you have or you have multiple TLV with different sources and groups, you can't add add a separate TLV in which only applies to one of those S comma Gs because you don't know which one applies to what kind of. That's why I to use use sub tlves. I'll skip this but it's in the slides if I don't to look at it for the forwarding optimization I know I talked about this before too, the other basic idea is if a multiple links between two routers, there's not

00:18:00 - 00:20:01
Go to 00:18:00
point in sending the same message multiple times on multiple interfaces So if you look on the left side here, without optimization, if there's like three links between a and b then Router A sends its message out all interfaces It's like BSR forwarding It will be sent three times to rather B. But B only accepts it on the RPF interface, so it will only really use one of those copies But A has no idea which interface would be the RPF interface interface. The other part is that you also when B receives it forwards without all interfaces, it will go back to A on multiple interfaces Instead, we do with the optimization is, A-sensit on one interface B does some kind of loose RPF check So it says it's not maybe not on the right point to point link, but at least I received it on A on a point to point link and the actual RPF interface should be from A on a different point to link, so I choose to accept it And also it knows that it should not have to send it back to A And use PIMHallows with a router ID option to control this so it knows that it's, you know, the identity of the router A So in the last revision I've implemented this and added more details how to do this So let's see Did I have a slide on that? Okay, so we have the RFC 6395 that we used for the router IDs But then the thing is Let me go back to this We only want to do this between A and B for point to point links. So there is some work checking which neighbors do have on which interfaces and is B like as the

00:20:01 - 00:22:02
Go to 00:20:01
sole neighbor on these interfaces or not And there's some text in the draft now that explains a bit how to do this without having to check for neighbors for every packet you forward you can kind of pre which interfaces to forward the messages And yeah, I think that's about it There's some hello option to indicate that you support this And yeah, I just said this Yeah, my plan is to implement the sub-tlV part as well There's some, some, won't have some logic to detect if your neighbor supports it and if it doesn't then you can kind of downgrade to using the old tlv but stripping the sub-tLVs So to implement that part and do some more testing but uh otherwise i think it should be done from my side soon So give you another update next to IETF Any comments? Okay, thanks All right, Nate, I'm pulling up your slide and I'll give you All right, good afternoon, everybody today we're to have four documents. I'll summarize that on the next page here A lot to go over and just about 10 minutes to do that Yeah, we got control. Thank you all right so so we have four documents here. The first one is

00:22:02 - 00:24:01
Go to 00:22:02
passed the working group last call and that's the problem statement this up up the problem state and requirements and the criteria for evaluating proposed solutions The second document is a proposed update to the Multicast Group ID allocation hope is that last call soon There's a zero confis assignment, which is an NDNS-based zero-conf assignment protocol there's also GAAP. those last two are solutions to the problem put forth in the problem statement. And I hope is that the last three of the last call scene Okay, so diving in the problem statement again just to refresh everybody The idea behind this is that the way that we use multicast snooping marine networks is that we have a lot of different multi-cast streams there coming from radar sources sonar sources video streams, and so on each data stream is assigned a different multicast address and devices are only going to request streams that they're interested in and the multicast snooping switch will forward packets only to the interested ports And this becomes important when you have mixed link speeds here. for example, this gigabit rate could saturate the link between the switch and the that's a heading sensor there it could saturate the link there if that's only 100 megabit link. So that's what we use switch and multi-guess looping But the display is still request that data The problem is, when you start to mix in multiple different types of sensors more than one radar, more than one sonar, the pre-allocated way of assigning addresses can doesn't lend itself well to to flex in the networks. So to understand that better

00:24:01 - 00:26:01
Go to 00:24:01
we want to move towards something like a dynamic multicast assignment but there's some challenges with that it's just kind of an overview here of the multicast addresses and what they're composed of of. RC 1884, that's the format there. You got 120 120 120 bits for the group I and rc 2464 talks about how you transmit IPV6 packets over Ethernet networks and basically take for your 48-bit Mac address, take the first two octets and set it to 33 33 and then the last four are the last four octet of the IPD6 multicast address address. RFC 3307 has guidance that basically says group IDs less than or equal 32 bits long will generate unique link layer addresses within a given multicast scope But this does present a problem when you're transmitting on Ethernet For example, you have link scoped IPV6 multicast address where each node can basically assign its own multicast addresses They'll have a unique IID but then the group ID there, is chosen either random maybe that might just start at zero and start this new addresses from there but in any case when when you go to transmit that onto Ethernet, the 32-bit group ID combined with the 3333 will result in duplicate Mac addresses And that causes problems with managed switches that focus only the Mac address for how they're going to manage their address tables So we considered a number of solutions here to address the problem. You could have the switch pay attention to the IQ6 destination address and so you're considering the full 120 bits of that address but the rc 4541 which

00:26:01 - 00:28:01
Go to 00:26:01
which is the multicast snooping RC basically indicates that most switch We looked at sort of specific multi-casts but that's not universally supported by switch hardware and definitely it's designed more for routing for traffic between networks than it is locally Madcap is a centralized mechanism for assigning IP addresses, multi-gas IP addresses. But the problem within a marine network is that it represents a single point of failure. So if we ever lose contact with that Madcap server or with the device goes offline then you lose and basically take out any sort of that is reliant adverse allocation ZMAP is a decentralized mechanism, but that was never much the draft expired in 2000 We looked at maybe bringing that back to life, but ultimately decided that there was inspired starting over So ultimately what we decided was that this is a decentralized zero configuration protocol for dynamically assigning multicast addresses requirements for this solution are that it does not require a, does not rely on a single point of failure does not depend on user configuration coexist with other multicast adverse assignment protocol supports operation on a single cell, does not rely does not require an internet connection supports multiple applications on the same host, and detects resolves adders collisions Before we get into the, solutions here, we have to take a bit of a detour and talk about how multicast group IDs are currently allocated So RC 3307 lays out the multicass adders guidelines where they define a group ID

00:28:01 - 00:30:00
Go to 00:28:01
is there's two different range, well, three different ranges here. You've got the permanent IPV6 multicast adders and those are allocated by IONA. You've also got a group identifiers allocated by Iyana. So those are going to be your hex 1 through 7F So true. Then section 4.3 talks about dynamic IP and 6 multicast addresses and that's that's for hex 80 through FM but the problem is it it does define both server allocation and host allocation mechanisms for that but the range is overlap So if you were to lay this out in a table, we'll see that the server, allocation and the host allocation conflict with each other. And then there's also this solicitive node multicast addresses that are used for a neighbor discovery protocol and that conflicts with that range as well So in order to resolve that, we propose that IANA have a new table for allocating the multicast addresses and the dynamic assignment range And this is what it would currently look like with the protocols that are currently published. Now that first entry from Madcap revision on its current current allocated range, that we would cut that down a bit and to leave a large unassigned area and then of course the solicited mode uh node multi-gas addresses would get in there as well and then i hope is that eventually once we publish the solution documents that we would have two more entries in this table, for the zero configuration for the group for GAAP So getting on to the assignment protocols, these are the solutions that we came up with both of these protocols meet the requirements on the problem statement

00:30:00 - 00:32:00
Go to 00:30:00
So then the question is, well, why do we need to? The zero conf algorithm is built on MD&S, which means that we might build to take advantage of existing software out there it works by choosing a random address and publishes that people PTR record in a new ETHAdder.Arper range or special purpose domain and then it retains that adders for free use which ensures that the network eventually reaches a steady state But it is IPV6 only The GAAP protocol is a new protocol. calculates the address from the hash of a group name and it supports IPV4 as well as IPB6 So moving forward, we're hoping to get working group last call for these three documents And then brief notes in Ireland we presented in Bangkok as well we presented on Congress on a multi-cast napping optimization That's the name of the document up there And I just want to apologize to our colleagues at Juniper for the delay on that We intend to resume that Okay. Thanks for your attention. Are there any questions? questions? Yeah, this is Stig. So, yeah, you have two solutions and you say, a little bit about why two. But if, let's say, someone reads these RFCs later and they wonder which one should they use, which one should they implement or whatever know, is there any recommendations so people can kind of choose? what works best for them or I think it kind of depends if you only need IPV6 and you happen to already be using IP or MDNS, within your network design, the zero confluence is better if you need IPv4, then the

00:32:00 - 00:34:01
Go to 00:32:00
GAP one, that's the only one that supports supports IPv4. Right yeah, so at least I think you know um well, one thing is to IESG might possibly ask why are we coming with two solutions so it would be good to have some some more details in that appeal And yeah, other thing is for you to choose And yeah, it can be more or less what you just said, but I think it's good to at least explain that to some extent so apart from the D4V6 part, is the retaining the addresses? Maybe one of the big benefits for them? mdns or I think that's just it handles the situation for you don't want to have to renegotiate addresses every time you start the network i think Gap handles that a little differently and that because it's your name, it inherently kind of retains that anyway and then I guess for our use case, we're representing a standard body and so within that you know, area concerned the standard body would choose, okay, this is going to be using for marine networks but then other other deployments may have different opinions on what's going to work best Thank you Yeah, at least least it's good if you can give it some thought if there some more text that could be added to explain this a bit Okay, yeah, we can work But it's not from that Yeah, the only concern I have at least

00:34:01 - 00:36:01
Go to 00:34:01
Yeah, this is Mike. I think that's valid. We could maybe figure out where in each of the drafts we can put this some wording in referencing the other solution and why you may want to choose one over the other, it would be pretty simple to do The question we have, Stig, is, i can't remember how we've done this before but we have three drafts here that are queued up for working group glass coal We're gonna have to decide whether we just do them all at the same time or do we just do one after the other and you're going to have to do it Yeah, I don't think it matters that much with the order, but I think it makes sense to me to do the solution maybe together during the same time The third draft is, you know, splitting up the ranges. That's kind of like a separate thing that can be done on its own i think Should we do a poll or something or I don't know Yeah Well, basically, I wonder if the working group thinks, you know, these drafts are ready for a last call I can ask differently. Is there anyone here? in the room or remotely that? have any concerns about taking? these to the last call?

00:36:01 - 00:38:01
Go to 00:36:01
We do have somebody in a queue I didn't check the gap gap draft but I think there is some so I just checked the draft now and there was some description about hash collision and maybe there is some solution about if there is hash collision so the we can guarantee the uniqueness and so on so but I'm not sure that this kind of procedure is a security guarantee or is it any review by some security specialists and so? on or we don't need to care about such kind of security aspects about such kind of such such harsh collision You understand, what that means? Yeah, think so I think both of the XeroConf and the gap protocols, if you have somebody on the network, who wants to disrupt operation they can certainly put out messages that would do so In order to secure your data, you you would want to encrypt it at the application layer you know, use IPSEC or that. But as far as allocating the multicast addresses, suddenly somebody could do a denial of service by just repeatedly

00:38:01 - 00:40:00
Go to 00:38:01
out collisions So I think that might be an underlying assumption of both of these Does that answer the question? Hi, this is Dino. Nate, let me take a crack at the question So the spec does provide with hash collision repair And it turns out that the application that I wrote GapChat that uses a library that implements the protocol um uses encryption so and with my implementation also did was it found out if people were trying to collide with different groups. So in other words, if there's two different group names and one of the group names doesn't hash to the first one but they're using that address we can take them out of the group We were trying to figure out a way to move everybody to a new group so so there are some provisions and it may not be totally complete but have a look at it and let us know And I'd add for the MD and S-based one, we kind of looked to MDNS if there's a need for encryption or additional protection that that would be solved by the So as here, so is there any more text? needed about collisions in the solutions? solution drafts, or is that all? good? sure Well, looks like there's good support for taking it to last calls So, so, yeah if if if yeah if you're Hitoshi or anyone else can reach you know, raise this on the mailing list

00:40:00 - 00:42:02
Go to 00:40:00
or we can also take it as part of the last call feedback and see if there's anything needed to address the collisions Thank you, Nate Thank you. Have good day Okay, man to man Yep Good afternoon and we are going to talk about PIM backup DR and we did present it a bunch of time and there were a lot of confusion about what to do with the DR improvement draft and there were comment about adding some extra text for stickiness of pymdr so after giving a lot of thought I thought that backup DR and having stickiness behavior, are kind of disjoint it doesn't need it's not necessary that both of them have to be together it's better to keep them independent What we are trying to solve since we presented it long ago, I am just trying to kind of refresh the memory So by default, when pymdia relaxation is happening it could be because of failure in this picture, if you look at R so r3 is a DR right now. if there is any failure at r3 but it is going to take some amount of time to have re-election plus rebuilding the tree So you'll have transient traffic loss at that point of time And the second case is, if new route comes into the land with high priority, the same problem will happen

00:42:02 - 00:44:01
Go to 00:42:02
where the new router will become DR immediately and it will take some more some time to really build the tree and start following the traffic The goal of this draft is how can we reuse the existing PIM spec and still minimize the traffic loss during re-election. And the simplicity what PIM is providing rather than coming up with too many extra protocol extension. So there are two things which we are going to talk about the first thing is having a backup DR and the second thing is delayed DR election. So if you look at both of the point, it's not necessary that you have to really have delayed d r election it really depends on what deployment is trying to achieve So the first part, the backup D election procedure is exactly same what your PIMDR election procedure is so what we are going to do that instead of having just one DR in the network, you elect a second DR which becomes a backup DR and it it can build a traffic it can build an upstream tree but it will not forward the traffic and the traffic will be forwarded only when it detects the primary DR is out, out of the network So the, the which you will get out of this is backup DR can resume as soon as it detects that the DR is out of the network The second case which we are speaking about is delayed DR election. reason is, irrespective even if you have backup DR let's say that what if some new router comes, which has priority of 500 in the previous picture we had priority of 100 200 300 and 400 so in priority of 500 comes in the network it is going to immediately really do the DR re-election and it will start

00:44:01 - 00:46:01
Go to 00:44:01
taking over the tree and you will have transient traffic loss So this draft, defines that if you really, if deployment, really wants to minimize traffic loss, even in that case, what it can do it can initiate its it can delay the DR election where you start sending your DR priority as a zero and you still send your actual DR priority that what your new DR priority will be And there are, there are a cases possible where either you can be the new DR or maybe you are not DR at all. So if you are not DR at all, you don't need worry about it. But if you are a DR, you say that I'm going to, this is my original priority but when I'm sending DR priority zero, it means you don't want others to really give up their DR role yet so that you get time to build your upstream tree So if you look at this picture maybe it will be easy with picture in this picture when R4 comes up, r4 is going to send its priority as a zero, at the same time it says that my configured priority is 400 What it means for r1 or 2 r3 that r3 knows that there is a new d r coming but there is no election happening yet because R3 is considering priority zero for r4 while r4 r4 builds its own tree upstream tree but it is not forwarding yet and once the time has expired it will start sending its original priority and that's when DR re-election will kick in. You already have pre-built the tree so that will make it easy. You'll have minimum traffic loss Sure This is Dino. So when the new router comes up, and joins the tree, duplicates will come to the land or does the new

00:46:01 - 00:48:01
Go to 00:46:01
d r does our four not forward packets It does not forward. Okay And another case can happen that let's say that while r4 is really building a tree at the same time r5 comes and r5 has a priority of 500 even though it is sending its priority as a zero, the configured priority is 500 So R4 is really going to prune its tree. It knows that it is not going to be DR anymore. So it is kind of, it really depends that in the worst case if your network, each route, is coming after a few seconds there are chances that you might end up building multiple trees and keep pruning it but by and large, are in real deployment scenario we don't expect these type of scenario to happen. So it will be, it will be okay uh comment stick here Yeah, so I think there are implementations from some vendors that do this delayed your election today where they don't immediately, you know, take over SDR but i don't know if they have a hello option like this it's the reason for the hello option is to avoid multiple new routers trying to join the tree, guess. Yeah. So if you don't have hello options, what will happen if there are 400, 500, 600 priority coming in of all of them start sending as a zero and all of them they only know about their priority plus three other priorities so they have no clue that after re-election who is exactly going to be DR. So that will kind of cause three trees to be built in advance. it's better to kind of give a hint that this is the configured priority and so this is adds one extension to hello option where we are going to have delayed DR priorities when we say delayed DR priority, what? it means that you're going to send your original priority as a zero, but you want to send or notify your peer that what exactly priority will is configured so that you can make the adjustment

00:48:01 - 00:50:01
Go to 00:48:01
So the next step for draft is I think it is now we have really trimmed it down we have made it lightweight and it is, I don't see any problem it working with existing network. So we'll wait for some more feedback before going to the next step Yes Jimanshu from Siena. I haven't read your draft so I'm just it an offhand comment How about if, because this is a new and now the legacy box has to do something extra for delay for the delay and all that? why not just the new router refrain from sending the because he knows about all other priority right so he can just refrain let the tree build and then once the tree is built he would then become the d r so if there is only one router coming, yes, this logic will work If there are two routers coming up and both of them they all of them can do that because they will know everyone's uh priority right? They will not know each other. So let's say... two new routers... Exactly yes yeah it can work i won't say that it won't work yes we can go ahead with the logic where each router will independently build the tree so you might end up having let's say that four routers coming up together. Then you may create four trees and then you will be pruning All of them. And refrain from. Exactly something to think about Stanley Zanthi, I just confused with two drafts. One is adopted draft, which is BDR rights, and the other one is a new individual draft So I read the two drops seems like this solution is up as in the individual route, right

00:50:01 - 00:52:00
Go to 00:50:01
yes so backup DR is adopted draft there was a comment to add stickiness behavior if we want to support PIM sticky PIM DR where once you have DR election done, you want to keep your DR up and running irrespective of whether what is the priority for new router but i don't see that these two things really need to be together. I mean to say that practically you can have stickiness behavior without having backup dr so both are independent thing so I removed the stickiness behavior completely in the independent draft but if working group thinks that these three things, have to be in single draft, we can merge it it so so f f s uh over emerged. the the BDR draft there is two solutions here. One is sticky solution and the other one is not sticky so sticky so stickiness behavior for pymdr has nothing to do with backup D.R. So today we support sticky DR behavior and multiple vendors. Actually, was looking at the config, so Nokia Juniper and Cisco all three of us support stickiness behavior but we are not our all operating system may not support backup DR so both are completely distinct solution. I mean, when I say there are different problem space altogether they're not solving the same problem Okay, I'd be i think this problem has existed so long time there is many solutions for it So how we will do for this, this solutions we just adopt one to publish one or we can publish all of them Okay, let me rephrase my story when we are going with back DR you are creating live live tree. You are waiting to detect the DR failure so that

00:52:00 - 00:54:00
Go to 00:52:00
you can forward the traffic. So this is your backup DR solution Stickiness behavior is you have a single d r single tree, even if new router comes no matter what is the priority, don't want to give up the DR role yes so these these things are completely orthogonal to each other They can coexist in the same network can have DR, BDR stickiness, but you can have stickiness without having backup. Yes, for the sticky solution, that means the i will not change, even if some routers joins with higher that's correct So, we think that in the P input, which is adopted several years ago is also a sticky solution so we are just a question to cheers if all of them can be published or something else yes but i support this solution too, because this seems like as existed a solution for years you know that's of some feedback from our customers. Yes, they may choose different assumptions for that. So the, um, the DR improvement draft that does both sticky and backup DR, right? Yes, sticky, sticky. Yes solution in PIMDR improvement is sticky solution. Even if some router with higher priority joins in, he will know which one is DR. Is it also backup DR? A backup DR will follow the be elected as the highest priority router in the network. Yes. if the DR feels DF feels, BDR will replace with the highest priority or maybe okay but yeah at least

00:54:00 - 00:56:00
Go to 00:54:00
I would say, yeah, like we discussed on the previous presentation you know, we have, yeah we have two different solutions that we need to about yeah we want to publish both history and need for both if you do that should we have some recommendations for which one to use or do we just ship them? both and just that people do whatever they want? Okay, thank you I'll be real quick I think if you just delay the DR election, you don't need a backup and you don't need an extra hello because just like the gentleman said is you could wait for all the wrong so the DR comes up he knows his priority. know he will be the DR if his priority is hired and everybody else He listens to all the hellos. If he isn't the highest priority, then it just operates like today. If he is the highest priority um he's still sending his lows because he wants everybody else to see it. Everybody else sees this higher priority guy, but they delay they delay it right they arguably they may not even have to delay it because when the guy comes up and he knows he's the highest priority, he could start sending joins and wait for traffic to come then, and then, you know, um should then then the old DR you need a time because you want the old DR to be able to prune the traffic, but I don't think you need a hello because it just predicting what's happening The hello just tells you what the DR priority is going to be in the future not the one he's currently sending to hello with. That's correct. But you don't have to do it So I just think if you put in a timer, and use the regular DR election, you're done sure the only thing you have to do extra is the new DR has to join That's what you've already said and the old one has to prune. But I think that's going handles all the cases, no? It will, so with bag, so the purpose of backup DR is not only to handle the new d r coming to network. So if you have

00:56:00 - 00:58:00
Go to 00:56:00
existing network with R1, R2, R3, R3 is my DR. If R3 goes down, R2 needs time to rebuild the tree so the backup the purpose of back DR is to really minimize the traffic loss in case of the actual DR failure. So that is case one one. So you could have two DR in the same days, but the one just doesn't forward. That's correct Is that with the backer? Yes. The definition of back yes yes and And absolutely correct about your other comment that if we really delay based on timer, we can potentially achieve the thing what we are doing with hello. Yeah, Yeah. And then the doesn't you have to set zero. Yes Yes. You know, he doesn't have so much they change. Yeah Yeah. message is always good sure yeah the the only problem is if, with, you know, if multiple routers come up at the same time they both think they are going to be the the new best they are Yeah, because you know, let's say there is one Roger with priority one Just two times, Too much Yeah. the timer expires you to join. And then when the other timer expires, you give yourself enough So there's a DIA election and there's a joining time And the join time is there because your way side to send be done so actually you can either go timer way so it is possible may be some transient or very corner cases where two people may end up joining but i think that should be okay okay Yeah, yeah. But if they do, they know which one should other's almost. Yeah, yeah. But if they do, they know which one should. That's correct Oh, I thought he has come Yeah, with me Okay Yeah, thank you

00:58:00 - 01:00:01
Go to 00:58:00
So Sandy, chat, GPT is a beautiful thing because I just did a quick search on show me in the pen mailing list a discussion about this because i'm remember we discussed this very thing and so back in 22 it came right up it's just amazing but But you did respond to my request about comparing the two drafts and then you said that they were significant different and then a detailed comparison would be coming So what I'd recommend you do with your draft is it's expired. you should probably update it We do still could still use a detailed comparison between these two drafts to Stig's comment about we're happy to propose two solutions to the IESG, but it would be helpful either in the draft or in some other mechanism showing what the differences are between them and why we have two different solutions If you're interested in that, then we're happy to progress it okay it's good because the four of two solutions, one is need a hello options Yes, and the other one need a new priority process, yes we see, I think that for the software, the update is all needed both of the solutions needed the software updated. So I think that we can make them all existed It's one way and and the other solution maybe makes them together or something else let us know what you want to do Yeah, so it would be great if we say next to IETF could have a bit longer slot where we can, know have like pro-a-cons and reach for the solutions or proponents reach off can say why they think you know their draft is needed

01:00:01 - 01:02:01
Go to 01:00:01
So she Here you go Okay, so is a presentation about Marta Pass support for IGMRD proxy Actually, have three railroad drafts and so today I'd like to ask you about the next step for for these trusts. So, well, I can skip the background because it's already known that the current IJMPR the proxy definition definition RFC 4-6-05 doesn't support a much forming situation we definitely need to support some function of this mechanism So we have three relevant routes, one in static upstream interface configuration for proxy. And this is approved as a working group draft and the intentive status is is informational. And the second one is dynamic upstream interface configuration using IGPMLMLD extension that is defined in in RFC in 9279. And the last one is a young model to include this kind of new extension So this supports SDN-like control-based upstream interface configurations So I'd like to briefly explain each drafts each draft and the static upstream interface configuration, we

01:02:01 - 01:04:01
Go to 01:02:01
approved as a working group with draft but there was some question about a subscriber-based upstream interface selection, especially we defined this function in a previous version of this draft, but but especially for the IPV6, it's mostly impossible to provide a subscriber-based authentication based on the link local address. So we should definitely remove this function Maybe this kind of function must be defined if we need We must define a new, let's say, like IGMP, security implementation maybe. So this is not the main task of this draft. So we can simply remove subscriber-based upstream interface selection So now we have two major major conflagration. One is channel-based upstream interface selection, the other is interface priority-based configuration And yeah, we can use the different upstream interface is no configuration or long configuration. So the next one is a dynamic upstream interface configuration based on the RFC-9278. So we can just simply use use this extension field of IGMPMRD. So the upstream upstream, uh, no, the proxy can decide based on this kind of information then the dynamical set up the upstream interface The last one is control-based upstream interface configuration based on the young model So we will will, augmentation, we will have some augmentation of existing young data models definition that that is RC 93 98 so the

01:04:01 - 01:06:01
Go to 01:04:01
main question of this presentation is that we we would like to march the signaling draft, draft it means a dynamic configuration draft into the static configuration working draft So, maybe young model draft can be kept as a separate draft, but the two draft can be merged into one draft so i'd like to add you that this kind of situation is possible. So at first, maybe I should ask you to review the signaling draft because this is still individual draft So the question is, can we submit a merge draft? whose entity state is changed to? propose the standard before the next IETF or do we need to confirm it in mailing this after? the ULAB? or do we need to discuss that kind of situation? Scientific meetings So again, the question for everyone is whether we can change the current intended status from informational to propose a standard and whether it's possible to merge two drafts or not So this is a question to all participants So just to confirm you're proposing the details in a individual draft be merged into a adopted working group draft. Yes, yes So we would either need to Adopt that individual draft or at least least decide as a working group if the details in

01:06:01 - 01:08:02
Go to 01:06:01
draft or yeah, I think we can handle that in the list i think we could ask the list Okay. We can just, yeah does that make sense? We can just see if those Yeah, at this normal if you are working group draft normally there's not stopping offers from really adding new content as they like and yeah but the working group can you know change us for it to be changed or taken out or something if they don't like it but since it's already written down as a draft it's good to get some input first before it gets added Okay, okay, But one question I have at least about the signaling um I know I mentioned this before before but how does the host or the stack know which identifier to use? Does it, is it passed somehow from the application? through the stack? or does the admin? whatever configure the hosts somehow with what ID to pass? the IGMPLD must currently be implemented in a counter-stacks, application may do some signal to the canal and then kind of must form the extension field to IGPMRD packet and then sent to the upstream So, well, it's a little bit heavy task to implement that one. But the LFC what I said I forgot the number but the our extension draft already support that kind of extension field so we can just look that extension field so maybe we can assume that that kind of extension field can be supported by the carnival application and so we just use that he's right so would you

01:08:02 - 01:10:00
Go to 01:08:02
what you would like ideally is that some of the user of the application is able to choose. Yeah, yeah, yeah Then the question is, I don't know Yeah, you need to someone know that okay, this choice corresponds to this idea or something something but yeah um okay um the other question i had is if what if two hosts are asking for different interfaces through different IDs, right? right? Mm-hmm. Maybe we should describe this kind of a in the draft yeah it's almost like a joint attribute conflict that it will talk about later. right right right yeah we'll take it to the list and see if people are okay with the merge, think and well my question is actually well the reason why we are now thinking about merging the draft is that in a previous meeting, there was a question about the main aim of the static configuration to be an R of C because it just just informational and like it's something like a guideline because there is no no wired format change so that kind of situation, maybe a little weaker to push it as an out of sea So, well, this is something like our background to think about merging the draft. So maybe having the integrating the signal draft into the current one is more stronger to push the hit to the to be all of sea right so yeah by the way when you you merge this both of the both of them will be optional Someone can choose to implement

01:10:00 - 01:12:01
Go to 01:10:00
either just the static or just that sure sure sure sure but otherwise i get your point yeah yeah but so if the chair or members think that still keeping the static configuration draft is better than we can, course without merging the draft Yeah, no What do we prefer? I don't know to Because, well, again, maybe just making a guideline all the fees is really difficult. Maybe bright has some comment about it Because previously, well, sorry for the long discussion, but the reason why the explicit tracking draft, that was weird important and but it was a failure by the ISD review last time. And because there was no wire format change So even though the other function is really important, if there is no wire form of change, why we need to have have RFC maybe when Brian was IESG, there were such current comment So maybe the situation is really similar, so I think it's better to merge the draft and to yeah having the proposals on the draft draft are easier or easier would express support for merging. These are two pretty similar things why not put them there's seems seems like a no-brainer

01:12:01 - 01:14:01
Go to 01:12:01
would give a thumbs up Yeah, No, i i yeah personally i agree um i think it's good that you can choose to implement just one of them if you want but personally I feel it can be one document I await your comment Thank you All right, thank you, Montemana Let us ask to be here. I'll it's this one Oh, I see Oh, Lenny, you have question before I start? Yeah, it's because of new feature, which I'm going to present so this this particular draft if we see so before in fact writing the draft i was kind of looking into what we support so i know that this what does this i looked at some of the juniper config juniper also has something similar which is already present. Nokia also has such configuration so just wanted to bring it here so that we can have it kind of really make it standard and if anyone else is trying to support sticky pymdr so they can have this same way very simple problem statement that there are deployments where if I have three routers in my network irrespective of what is the priority coming for the fourth router, don't want to give up the DR role. it could be very simple reason that you really don't want that transient traffic loss

01:14:01 - 01:16:00
Go to 01:14:01
to have once DR election is done let it be there unless the router fails or maybe once in a while for some practical reason as a operator you want to enforce re-election so this particular draft is talking about these two cases that how we are going to support both cases The solution it is, this is how it has been in fact implemented in XR, something close with other vendors as well the solution says that we have our DR election as the way we are doing it today And it is kind of giving a mute x value so that nobody else can really take it over so what we are going to do that assign a max DR priority minus one to the dear elected d r and after this step, R3 is always going to announce its DR priority as a max DR priority minus 1 What this will result into, that no matter who is coming, or any new router is coming it is not going to take over over and when new router comes up even if router r4 gets priority 400 definitely it will not take over now the question comes what what if someone really goes and configures this max minus 1 as a configured priority you can it is kind of you have multiple ways to mess up your network so this will be one of them we can't prevent in that case And as I said, what if you have backup D are also configured? So in that case, we are saying that the backup d r can get the priority of uh max minus 2 but there are multiple variations possible here and I really even though I have put it here but while I was thinking thought it may not be needed because backup d r stickiness behavior, I practically, don't see the reason that if you

01:16:00 - 01:18:00
Go to 01:16:00
really want to have a backup DR why do you want to have a stickiness behavior? if some customer wants, yes, this is how we will do it Otherwise, backup DR can do its own re-election I don't think you need any of this because you already have a sticky DR. It's the one with the highest priority No, oh, which one? The first part. Yes. this is not needed just for the sake of completion that in case you want to have stickness. I don't think it's sticky DR new solution is necessary because we already have one When you bring up all the routers, the network administrator decided what the priority was. And the one with the highest priority is a sticky DR. Any new router that comes up should not have a higher priority. That's a network management problem no that is not true so let's let's say, let's go into this picture I have R1, R2, R3 R3 is DR R3 failed. R3 there was a router got reload Now when R3 comes up, R3 will come with priority 300 but there are deployments where you don't want to move the traffic back to 300 even if the configured priority is 300 so it's you want one particular router, to be sticky, and always have the traffic, it's the highest priority one by definition definition Yes, that's correct there are actually deployments where I think it's over engineering a problem that doesn't happen that often It's adding all this extra machinery that makes the implementation complicated Well, routers don't crash that often. You have to handle it, but they don't crash that often to have all this machinery put in It is deployed, by the way And it was was

01:18:00 - 01:20:01
Go to 01:18:00
us. It doesn't matter. Just because you can do, it doesn't mean you should do Yeah jeffrey john hpe i have really thought through about this yet but it just reminds me of OSPF, DR, BDR. And my impression is that they have the stickness there. The OSP BDR, existing one, they don't get preempted. I wonder i i i I'm not wrong, I don't know if the same person, should be used here they already have this thickness always get as a simpler issue because it's only Right, but everybody's sensitive to the problem problem right but i and that uh guess I need to confirm if OSPF, DRBR have the stickness, if they already have the stickness, then they do it just with priority I create that sticking I'll try to find the because somehow I have the impression that the new new router will not mess up the existing ones, even if they right that's may that may be wrong I'll confirm it offline yeah So, actually, I agree with Jeffrey because I will check with RFC, 28 So in my memory, if my memory is right, in OSPF it's sticky sticky. So the same mechanism as used in PuneDi improvement dropped. So the draft has been adopted years before So, so structure borrows the idea

01:20:01 - 01:22:01
Go to 01:20:01
from OSPF So this idea is not from OSPF It's a typical problem. It's not a student And you else from Deutsche Telecom. You know, just wanted to reply to one comment of yours saying this does not happen so often, right? as an operator slightly different experience there because there's a lot of disturbances in the network point one point two it's not just because of failures that router powers down, but there are also something called updates, reloads you know these all kind of things you can you need to restart your router even though the router vendors promise you that they have you know in-life upgrades of software it turns out it often doesn't work so i do see a point in Manca Manana that there is a problem to solve slow. Yeah. But why don't raise the priority of the back before you take the other one down? down. Yes, you could yes you could do that but then you would have to have either a controller in place that does it or the second point you would have to have very rigid operational plans in place and I can tell you out of experience half of the time it's not going to happen the way that the engineers have planned for it Yeah, I'm in the qs well here um sorry but yeah so even if you do that if you do a plan change of your priority, that also can cause some some traffic loss but but i feel like what you are saying, Dino, is more or less less sticky in a sense that you want a specific router to be the d r when everyone is up But this thickness is more like, I don't care which router is DR but whoever is DR should keep

01:22:01 - 01:24:01
Go to 01:22:01
being the arc kind of okay just to repeat, we have failures and we have recoveries right, and I don't see why customers need to have two outages, two interrupt in that case. I'm not claiming whether this is the best or the only way to do it, but certainly not one that also requires a controller, right? So, and I we need a solution for that. And if somebody has a better, idea than this to make it half the number of outages please step forward So I just did the Google search and yeah, yeah overview says that if the existing DR or BDR is still active, the new router will not be elected as DR or BDR, even if it has a higher priority To first new one, new election, you will need to either shut down the calendar, DRBJ interface, or lower its priority priority. So it seems that we could borrow the OSPF for implementation No, the PIM, but the says that if anyone, any router comes with high priority, you have to give up. That's what the base PIMRFC says care which one is policies usually in Thank you think the key elements here is that the we must use bdr to monitor the status of DR because when DR fails there is packed laws. So this is the first point the elements Yes, and as a second is if somebody wants to use the one has higher priority to replace the previous one and all he will add a new

01:24:01 - 01:26:00
Go to 01:24:01
element here, a router here he, one he put it in it, he should influence the process, yes so if we use the function defining PIMD improvement the router with a higher priority, will be elected as b so he maybe he will not forward the flow because there is existed but one dear feels he will do it so yes the two goals will be achieved by the function. Yeah, I've mentioned, Yes Yes, yes I know you have to pre-joy. That's the new problem. Yes the DR is the highest priority here BDR will have the second highest priority here Yes, yes, if if the DR has been elected and it has not the highest priority because somebody with a higher priority joins they will not feel the road to the new router but in case the DR fails, it will give the road to the highest to the router with the highest priority, yes yeah that's the the solution we that's the solution we introduce the PMBI improvement job. Yeah. Okay we're going to move on. Thank you so moving on to to the next draft this particular few disclaimer even though I'm using term SRV6, so there is nothing s rv6 construct being used here so it is pure pym over ipv6 number one number two this is informational draft so we are not doing any any new protocol extensions the whole reason why this draft is coming into the existence because a lot of

01:26:00 - 01:28:01
Go to 01:26:00
customers they had confusion about how exactly they're going to deploy or what what all the possible solutions if they are migrating their unicast network to a service sector So there are the use cases which we are going to speak about I think many of them, it's kind of it's already present in multiple different places We are just bringing it together so that it becomes a handy document for customers for deployment So the first use case is if you have just end-to-end IPV6 so nothing prevents you to turn on PIMV6 end-to-end and run your multicast over lowcast tree, is running your PIMV6 classic PIMV6 over SRV6 network The second case which we talk about is if you have flexelgo in your network. So there is already existing draft where we are talking about how to support PIM with Flexalgo. It is, I think, not adopted yet. So it is a work it is a individual draft in PIM working group. So So SRV6 network with PIM can reuse the same construct where you don't want to really build your tree using your low latency path or potentially you want to go low latency not the highest IGP path and you can build your tree per flexelgo and your your multicast can be serviced over this service X network the third option which we have is a centralized control plane. And even in this case, we look at the data plane so data plane is still remains exactly same, is native IPV6 so your controller instead of PIM programming the tree controller is programming the trees around the network and you get rid of PIM because if you don't want to run PIM in the network but if you look at the forwarding state so forwarding state is a to remain exactly same as

01:28:01 - 01:30:01
Go to 01:28:01
native IPV6 multicash forwarding what what is the extra benefit which centralized control plane provides it is more flexible compared to flexelgo so flex algo may not you may not be able to really define a policy where you can say that i don't want to use this particular link or avoid this particular box potentially with centralized control plane you have more more handle over it The last case is if you want to use multicast or VPN or MVPN cases, so in this case, can use either of the underlay tree building mechanism, which is your just pmv6 or with flexelgo are centralized TE tree and you can build those many daytime IPMZ or SPMZ which we call data MDT or default MDT trees and your underlay trees are still going to be built by PIM protocol so we can use next-gen mvpn signaling for customer signaling, whereas your underlay is being built by PIM PIM. The last section which really I think it is more of implementation and it is important as well is how exactly data plane encapsulation is going to happen so your data plane encapsulation for this particular solution is going to be IP in IP where if you have IP header coming in our IP traffic coming in, so it are going to encapsulate it with v6 header and carry it over the core So that's all, it's pretty pretty short informational draft. And if there are any comments, please provide I haven't found the time to read it, sorry, I do know that MBO and D

01:30:01 - 01:32:01
Go to 01:30:01
has adopted what I would feel to be a similar draft in terms of giving some overview and so it might be good to bring this also to end bond each as well that they express an opinion because I think overall recommendations of how to apply the technologies that we have operationally is primarily been an M-Bondi thing, but but in any case it would just look very stupid if the same type of scope was done in one working group document in PIM and the other in M Bone D without getting an overall picture Sure. This all aligns Thank you just a real quick question for you, actually get back up here, just real quick. So there's no as you stated, there's no new protocols that are being proposed it's probably an information draft yes it's the how pymn can be integrated with SRV6 and Flex Al. Other things to make multicests work that's correct over SRV6 yes And it's, it's meant to be kind of a a maybe not a best use case, but just to be able to answer the question of how multicasts can be used in a specifically segment routing v6 or segment routing in general or srv6 or any IPV6 or any IPV6 that's correct yes okay thank you you. Niels from Dutch Telecom again First of all, thank you for the draft think it's very well written When I came across the draft, I was debating with myself whether it is a good idea also to mention the method of deploying our beer just as a side reference so that you give a hint that there's additional protocols that could be used in order to achieve

01:32:01 - 01:34:01
Go to 01:32:01
it. So the reason why we didn't add beer here is there is another draft which Jeffrey has that already talks about how beer can be deployed in that network. So I don't think there's really, it will be kind of redundant I understand that I was just you know you my thought comes from the point that you're trying to provide an extensive overview of what is possible so maybe that would be helpful i don't know thanks Thank you. One question Sunny Zonati, just a question about why trees it or p2m policy has not been mentioned in this draft because I think that it's really really the alternative solution for it and it's also can be used over SR6, yeah yeah so if you look at the draft it clearly says that how PIM can be deployed so this actually draft is limited to the scope of draft is if you want to utilize how exactly it is going to work it doesn't say that don't use trace it or it doesn't say don't use Ingress replication or something else So there are, of course, there are multiple ways to build the tree. But if you want to use pym what exactly are how exactly you are going to carry? carry the traffic over IP IPV6 core okay but i think if it's just limited in P and you must mention that, the prefix it used from different routing table, because we know that from flex ego and different prefix may be existed in different routing table. So he must look up the right routing table to get the right next at Sure. Thanks See right

01:34:01 - 01:36:01
Go to 01:34:01
Can you hear me? Good evening, Evan. Can you hear me? Yeah Okay. Thanks Passing your control Okay and just speak up a little here you're pretty light. Okay, Is it better now? Yeah, it's great. Okay okay so good evening everyone this is the best draft for the combined RFC, 8599798 so yeah basically both both of the rfc is 8059 and 9798 by experimental, think 9798 just got to RFC so we thought that you know this is probably a good time to make the best primarily to get them to standards track and this is probably one of the last few documents in the list multicars section that is undergoing the experimental to standard track this process you know the unicast drafts have already been done the 68 31 I'm sorry I don't remember the number right is already being done by Dino and us so this is probably one of the last you know why are they needed uh they're probably i mean 859 was brought in essentially to introduce two new joint prune attributes for the you know PIM D essentially joint-to-run attributes for LISP. The first one is essentially to kind of signal the underlay transport preference that you know any ETR or a egress LISP node wants to, LISP wants to use whether it's unicast or multicast IPV 4 v6 you know and and even potentially a combination of the above as well you know if there are multiple transport options that uh can listen to

01:36:01 - 01:38:01
Go to 01:36:01
That's the first you know reason why that that that attribute was introduced and then there is something called receiver hour lack attribute i mean none of this is new these are all introduced in 859 and of course uh slightly enhanced by 9798 and the receiver hour lock attribute is essentially specifies the multicast group or the Unicast Arlock you know receiver Arlock wants to use for a particular flow so you know given the Lisp signal the way it works with PIM over PIM, know, the previous one, the SRVC context, this is the list context but we found this extremely useful and and being implemented of course by by Cisco IOSXC and being deployed in a lot of places so we thought that it's very reasonable to bring this to standards track so that's the reason for the best track i don't think i probably have to go to to the solution, yeah, please go ahead yeah so looks to me more given how you don't have an update section as if you're trying to obsolete the two other RFCs. Yes, no? yes we are trying to obsolete two RFCs yeah that's that's a different status please, please change that according to Sure, sure thank you for pointing that out out thank you for pointing pointing that out. Yeah, so yeah I think mostly what i covered earlier is essentially the list transport attribute and the receiver ETRR lock attributes are defined there and we can pretty much reuse the IANA code points. think that's one of the doubts I had and I think still clarified the top line you know, you can reuse the same Iana code points but probably update the text you know say same point that tarless product you know make sure that we be clearly call out that we are obsolating the two experimental RFCs and then this is the new standard track RFC that will replace them

01:38:01 - 01:40:03
Go to 01:38:01
We'll probably add text and, you know to that effect, but but no real functional change in that sense we don't want any change because this is pretty much the same content that was already available in experimental track, they're now bringing it to standard structure Yeah, Stieg here, just a comment and yeah, I'm also an offer Yeah, I think it should use to say code points. It's the same on the progress other drafts uh you know Internet standard or whatever you because you want existing implementations to actually support the new RFC. Yes Yeah, mostly that's sick from my side don't think I have anything more bad Stick anything if you want to Thank you Thank you Yeah. Thank you Okay. Yeah Thank you Thank you All right, so in Bangkok, I was presenting a draft on the experiment that we would like to do to bring the stateless multicast forwarding to PIM Greg? do you want to ask now or wait later?

01:40:03 - 01:42:00
Go to 01:40:03
I can't hear him, he's in the queue sure How's that? Can you hear me now? Yep okay uh yeah seemed to this already in the draft mentions uh beer and is the standard solution. Why is this not being presented in beer? beer um well the the whole point was that you said a solution that reuses the beer architecture but doesn't use the beer encapsulation is not a beer solution and the IETF has also said that multicast extension to SRV6 are handled in PIM So that's basically one. is not encapsulation this is encoding you're changing the forwarding planes. it's not a simple V6 encapsulation it it it is i encapsulation right so one of the no it's you're encoding the bits and the head That's not encapsulated in V6. This is especially began years ago No. We asked you to rename it as in cap and the original author agreed that it was in cap but because of whatever reason you in code excuse me you continue to call it encapsulation No, a second. okay, let me for the people to understand this uh who may not have been in Bangkok, right? So the experiment draft explains all this history that Greg is talking about right so and I think it's a more approach document that doesn't, um, to become an RFC, but that i was suggesting to to adopt in pin so to basically does it explain that this work was rejected by the beer working group? Yes, course Does it explain that it had two boffs? that were rejected as well um the large the boffs were for uh they were a working group forming buff. So that was basically a rejection at this work and and talking with IESG. Of course, answer was take that work to the appropriate working groups like PIM which i'm doing here okay so

01:42:00 - 01:44:02
Go to 01:42:00
and you're claiming that it doesn't change the forwarding plane this is just encapsulation um no of course it does change the forwarding plane because the the uh the the way that i packets are handled hop by hop is exactly incompatible with beer, is why the who want to have an IPV6 -only network cannot work with the... That's not true. That's beer in six is native v6 that allows beer no no it is it is it is it it is, is, uh, it is a solution that tunnels across IPV6 but it is not a native IPV6 solution Link Local is not tunneling That's just... Yes, is that is still a tunnel that is still a tunnel and right and how is so that's the link architecture that the IETF has put forward and has been dominant in the internet for is the solution of one particular working group that uses hop-by-hop forwarding based on a particular beer header, right? It is a layer 2.5 solution. It's all in the experiment document right? So this is native IPV6 solution using an IPV6 routing extension header which is a much more preferred solution by IPV6 network operators. Well, that's, an opinion. There's no proof of that since the V6 group itself puts back to beer for our our perfect our um our input that's that's basically exactly why we, you know, have a rough consensus pro assess right so if there are sufficiently many operators that are interested in having just work adopted, we can basically figure out if the PIM working group is the right group to adopt this to adopt this rejected work In beer rejected work uh in the morning in beer in beer you ran a very tricky process of eliminating any operational considerations for requirements and took it down purely to functional things and hop-by-hop tunneling over link local IPV6 tunnel which aren't working on any bloody bloody router right hasn't uh you know is not a good solution for ipv6 networks sorry this part of the experiment document and I would like to continue to talk about the new draft that I

01:44:02 - 01:46:00
Go to 01:44:02
written. just want to make sure everyone understands that this work has been rejected by beer and had presented in two boffs we rejected summarily First of all, this is not exactly the same type of encapsulation the same type of features that was discussed two years ago in the the MSR6 buff. And this has evolved since then and I think there are very clear differences visible in what this is versus what beer is trying to do So let me just make one more point then to make sure the when beer was uh formed ad at the time made sure that we understood that we're talking about the fording plane. It's the narrow part of the hourglass she insisted that we took our time collaborated with everyone across the IETF and got it right and once we standardized it, we defended it because having options in the forwarding playing complicates the layered structure of the internet. So which is why in which is five, which which is five which why ipv6 networks in Unicast we already have um one two three four i can go to that slide So here is basically what we have for IPV6 Unicast forwarding and last service provider networks, kind of all RFC80200 stateless solution forwardings right so we started out with the SRH header, which is kind of the traditional uncompressed unicast hop-by-hop forwarding And then basically there is also the same equivalent for IOT networks, which is is rfc 6554 um and then uh there is basically two different encodings with a a six-men experimental draft from Juniper, CRH-16-C CRH 32, and then there are also two different type of encodings of compressed forwarding sequences um for unicast forward that also uses the SRH header right so one, three, five, six different forms of doing stateless forwarding with steering in Unicast. you're not telling me that

01:46:00 - 01:48:00
Go to 01:46:00
options exist in the IETF because we have different preferences in different customer spaces And again, if you're neglect that the same is true for multi- i think that is ridiculous so i think it's ridiculous to think that V6 extension headers should be used to replicate every phone function that the IETF has already standardized those are new functions which is the point of the V6 extension header. Add functionality that's unique so replicate every function that already have standardized somewhere else. Yeah, we got your individual contributor opinion. That's fine So that's why we have rough consensus process right? Okay so solution overview so what I wrote since last time is, the draft that specifies the forwarding behavior. So this is called sorry, exactly on this last draft IETF, PIM, Eckert MRH and I just want to quickly to show what this doesn't the forwarding plane. So you basically got an IPV6 packet that is forwarded end to end across an IPV6 network with with replication, with steering, potentially that is replacing the need for stateful forwarding in the IPV6 network It doesn't use any form of additional tunneling or so. It's in the same way as any of the different unicast steering headers so the way that these things work in IPV6 is that you do have the destination address in the IPV6 header that is rewritten on every loose hop of this steering, right? It doesn't have to be strict hop can be a loose hop, then basically the extension header has two elements in there. One is what I call the MSCR segment, which is the multicast exit router segment, which is effectively the IPV6 multicast destination address, right? So this is an IPV6 multicast package with an IPV6 multicast address source address in the IPV header, destination address in the extension header

01:48:00 - 01:50:01
Go to 01:48:00
And then there is, depending on the subtype, that we're using where i'm i'm thinking when we we do require two different types One is destination-based, which is kind of really just indicating the replication, other is steering-based So for the destination based, that's exactly where it is using the RFC 82-79 forwarding rules Beer exactly with a bit string with a BSL, SDNSI, S-defined in that, right? So this is basically ultimately the option that would make the full IPV6 header with the extension header replacing the beer header, So we're using beer forwarding architecture. We're just using a different header. And of course, draft described the hop-by-hop forwarding rules were in the same way as in Unicast, the IPV6 destination address is rewritten and then the steel one, that's where we have currently currently different alternative options. Some of them have been validated through experimental implementations in vendors or in universities and that one we're still working out how to come up with a coalesced proposal detail So that's pretty much what this is as far as the overall architecture is concerned that's the next thing and that's basically shown here a little bit kind of how this would look like, right? You get your IPV6 and with the MRI extension header module in the IPV6 forwarding in the host in the IPV6 host in the routers and then you have your sender and receiver applications that are just doing normal IPV6 multicast sockets and then you have your signaling demons so the signaling that we were thinking of for that is simply MLD based from the receiver to the sender notes and then the state table and it's being translated So that's for things to come so yeah um anybody else questions? on that?

01:50:01 - 01:52:01
Go to 01:50:01
And the slide with a different IPV things that have been done now also kind of discusses exactly what particular implementation choices in the header would mean for which group this would go to right? So if, for example, we use a new routing header code point type, that would mean that the forwarding plane draft would go to six men in the same way as the juniper draft went if we use the SRH, routing header code point, then it would be something that would have to be done in agreement between Spring and PIM So kind of spring would have to tell us, yes, they're fine that we're overloading this code point like they have overloaded three times already, right? So there is the uncompressed There are the two different compression headers so we can add this one as well. So that's one of the forwarding plane options to decide upon. But obviously, the control plane the architecture these things of course belong into PIM as, you know, IPV6 multicast routing in a status fashion for it SRV6 networks Okay. Okay. Yeah. Thank you All right He's all Hello everyone, I'm Yisung Liu from Chen Mobile and today I will introduce the IPF vector conflict resolution in this fake

01:52:01 - 01:54:00
Go to 01:52:01
we have a receivers, one another R2. So when R1, send the PIM join One the Pim John come to the R3 router As RUTER, assumed that Arthur had the the MOFR, and it will continue to join in the primary path to the R2 router and the backup backup in the figure with the blue line The backup joined will carry the vector R5. And another, receiver R2 will join with the with the in here and it will send John from R8 router to the R6 router So in the R6 router we have two conflicted pin join. One, we will take the PIM vector, the R5, and the other join without vector so how to choose the the next RPIF. So for the existing RFC for the RFC RFC 5384, the 5384, in the Pim John, when we have the same joint attributes, that means the type is the same So we will compare the

01:54:00 - 01:56:00
Go to 01:54:00
neighborhood address. If they address the same, we will compare the interface index But the but the condition, we must have another condition that the drug attributes is the theme In the RFC 7891, when the Pim John with the the RPF vector, but the router must verify the consistent order of the appurator types If the order, the order inconsistent and the types are considered equal. So the rules along with the RFC at 53 84 rules but another of of this ARFCs the scenario in the previous slide So, uh, our draft, we recommend a new handle mechanism but we don't think we are we that the is the best solution we can discuss If we, The first rule is that if one join with the RPF vector and the other without, and we we selected the join method without the API vector vector. If we, if we, that the second rule is that if the PM join contains the only contains, one join can only contains the class zero the cloud zero as the original RPF vector and the other one contains the class four that explicit RP vector

01:56:00 - 01:58:01
Go to 01:56:00
So we recommend that the join method with the only class zero get the priority So, under the mechanism, we have provided the the previous slide scenario and the drone carried the vector R5, all this is some something wrong here vector r5 on we will at the R6 router and the join from R8 to R6 will continue to join our hope one by one So that's our proposal for this problem So that's all Any questions? questions? Mancabna, Cisco system. So I think problem statement is clear, but for solution, need some more brainstorming i don't think we can there are multiple cases to really think about it which one to give priority, when to give up when not to give up okay thank you yes stick here yeah i'm little curious what made you choose the one you did. I mean, there's two options options. But yeah, I also wonder about existing implementations what they might have done. It must be code today where implementation decide what to do Okay Well done