Internet Engineering Task Force 111, 30 Jul 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF111-PIM-20210730-2300

Description

PIM meeting session at IETF111
2021/07/30 2300

https://datatracker.ietf.org/meeting/111/proceedings/

A

I'm not sure if you heard me then, but I used a new tool and all the slides are now loaded into meat echo, which is kind of nice. So we don't have to share our squint screen. We can just uh select the deck we want from that icon from second from the left right next to the hand, and what I don't know is that people can drive their own slides if we need to drive that for them. Using this method,.

B

C

B

I go to um meeting materials like the fifth from the left. Like the folder thing, I see, uh I see the agenda slides, I think, and then I see two other presentations, but but not all of them.

A

Well, if you go to the um on the right by your name, if you click on the folded paper, looking thing between the hand and the screen, if you click on that, you should see all the slides. I'm going to stop this and let you do it.

A

You click on that and I just loaded everything everything is sitting there to uh to select.

A

If it doesn't work for you, don't stress, because it's working for me.

B

And taken, I guess I need to um let's see if I remove yours, okay now, let me.

B

B

That looks great so, uh but.

A

They're not they're, not, I don't know.

B

You can share and then you can actually do other stuff. Certainly in the meantime or I know you want me to share- and you take notes again or how to do this.

A

Sure, let's do that, but right now I can't see your shared slides. I don't know.

D

I'm not seeing anything either guys try to share the agenda.

A

But I think it yeah exactly.

A

Yeah there you go that works good, so yeah you do that if you've got that figured out, then choose those.

A

And I'll take notes, but the reality is, I'm just going to go back and watch the video later and take the take notes and you and I are just going to be talking over each other since you're, half duplex.

A

Why don't you go ahead? Stick start us.

A

E

See my slide or.

F

A

See your slide.

B

B

B

Okay, I got it. I just had to change the presentation view. Okay, so shall I start this often go through the status slides. Yes,.

B

I'll start, and if you want me to stop speaking if anyone wants also to talk or anything just just wave at me- okay, great, okay, so um welcome everyone to itf, 111, pin working group. It's not a good time for many people or it's a great time for some people as usual, but yeah thanks for those two. Thanks to those who made it here, we've got quite a few people, that's great all right! So um yeah mike- and I are the chairs- forget what we look like.

B

There's some photos here where you can see: mike's camera.

B

There's a note: well so it's the usual slide. I hope you all know this.

B

Right then, we have the agenda which looks like this pretty full agenda, so we got a request from tourists to present a bit earlier. So we're going to move the last presentation before on anish's presentation: um does the agenda look good, otherwise,.

B

All right, so, let's go to the working group status.

B

So basically we're going to look mostly at the drafts that are working group drafts.

B

We have the pym yang model, it's been sitting in the queue for three years or so I think the rfc editor's queue uh looks like all our references are are are sorted now from what I see. I think it should be published very soon. Now then we have the igp emily sleeping young model that has been in the queue for a long time too, but not quite as long. So hopefully that will be published soon as well.

B

Then we got the point-to-point multicast bfd multi-point bft that yeah we requested publishing for that a while ago the ads alvaro has reviewed. It had some comments and the offers are working on revising the document and addressing the comments. So hopefully that will move forward soon as well.

B

We requested publication for the igp mld extension draft, so that was kind of recently, so we haven't turned back from our ad. Yet, regarding that, then they have the dr improvement and we also have this backup, dr draft, so the story now is that we uh we have adopted the uh man commander and bdr draft uh as well, um but that doesn't mean that we will necessarily publish both those drafts as rcs. Eventually, we need to figure out in a working group. What do you want to do? Do we need both solutions or not?

B

Do we need two drafts or not just open questions here, but those are some other things we need to figure out, um but we're not gonna discuss that today we are waiting for the offers to publish new drafts, so hopefully next itf.

B

We will have a lot of discussion about uh where dr solutions, then we have another registered packing. um So we needed more review in a working group and we got a couple of volunteers that reviewed it and we had some discussion on the list, which is great, but we are waiting for the authors to address all the comments, so a little bit slow going here. But hopefully we can make progress soon.

B

But thanks a lot for those that volunteered and reviewed the draft.

B

Then we have um ig ignpmld proxy young model that we will discuss today. Mr packing draft was revised and presented: oh no, not presented, but anyway, it was revised in june, but not presented. This meeting um all right comments from mike.

A

Yeah, so um I think- uh and I think I saw yee song on this call, so I think we are I'm on this draft. I think we are ready for working group last call um ethon. If you're there. Could you confirm whether you agree with that.

A

Poor sandy don't hear me.

G

Yeah yeah, we we have a discussion in the uh with some all core authors and we think that the draft is stable and we think we want to request a lesser call great. Thank you.

A

That's what I thought so stig um after this idf. We will ask you to do that on the list. Please.

B

Yeah that sounds good um yeah. If there's anyone in in the room, I was gonna, say: uh if there's anyone listening that have any concerns about doing a loss call please let me know now or bring it up on the mailing.

B

B

All right, yeah, I can see at least personally I reviewed the draft. I think I had like one minor comment, but it looks pretty good and yeah. I think maybe my comment actually has been like incorporated already I'll check that later.

B

All right, um then we have some other drafts. We have the um sr, pointy point multi-point point to multi-point policy um and we'll have some discussion today related to to that um then. Finally, uh we are moving ahead with the progressing rgmp and mld rfcs to internet standards, basically yeah igb version 3 and mle version 2..

B

So we will discuss that today. There's also this other really old rfc for host extensions for multicasting that also you probably want to revise, and then we will discuss that later today as well.

B

So yeah, that's what we had for the status uh yeah. If there's any comments, let me know or please speak up um all right. The last thing we had is uh charter update. So um we have been start. You know we started doing some sr point multi-point work in pim and he already had adopted that draft, so that was discussed with uh routing ids and spring chairs, and you know we agree that that work could be done in him and um in general they might do some more work in this area.

B

But if you do, it would be in close collaboration with spring to figure out. You know what, where is the best place to do the work, but we thought it would be good to formalize this a little bit and at least add some text to the charter mike. Maybe you can comment on this.

A

So I think we've done this well from the beginning, when we first adopted this draft and before we dropped to that draft, we we worked very closely with the spring working group waiting for the replication segment draft to be adopted, and then we adopted this draft per springs desire. They just don't have time for multicast, they don't want to deal with it and they even just told us last week that yep, you guys got it. We're not gonna we're not gonna recharter. um We probably don't need a new working group.

A

Let's just go ahead and just make this formal and just add a sentence into the pin charter just to make it formal. So we have proposed text. That could be a better way to word this, but this is what we are planning to add. Whatever we decide to um add, we will run this by the spring working group and then before we officially add this to our charter.

A

It may be good to hear some thoughts from the working group on whether they have different feelings or, if they think, there's better wording.

A

Yes, go ahead. Human.

A

Can't hear you.

A

Try again later, if you get your audio working.

B

The mic icon, I guess, to to actually speak.

A

He's gonna try again, he said one chat, so just keep.

A

A

Okay, I'm gonna go ahead and remove them from the queue anybody else.

A

Okay, so I say we just will send this to the list, maybe just as we have it here and we'll take the discussion from there once we come to a consensus, then we'll send it to the spring working group for their opinions and then, if it's all agreed upon we'll.

A

B

You got the microphone but yeah, I guess it didn't work.

A

Okay, no, it didn't so. Let's move on.

B

I wish I was the only one with audio trouble.

B

Okay, so uh I guess that's what we had for the the status slides um yeah, I'm gonna mute myself here now, but yeah. I guess we are ready to start on the first presentation.

A

Then yeah so stick. Why don't you just keep driving the slot? Yeah just choose um ong slide now, and it should work good and if so, 100 you're up.

E

A

Here, can you hear me can hear you fine, just can't see the slides yet.

E

Can you, yes, I can hear you I I saw a new deck is being shared. Yeah.

H

E

E

There we go okay.

A

H

H

B

But just uh tell me, you know when you go to the next slide. I went to number two here. I hope that's. Okay,.

E

Let me know okay now now this is the number two okay, it's okay and now now let me introduce some some updates about the agmp mrd proxy. Your model- and this is the version file for this draft.

E

We have update the list drops according to young young daughter's comments and other comments. The next slide piece.

E

Okay, thank you, the one with the future mode, the leaflets the manta rays, the sleeve, contains the numeration uh include our exclude uh in the old. This leaf is not the mandatory here. We sell this one as much relief. Now last one.

E

E

Piece: okay update: two: we change the uh in the ignp proxy tree. We change the type of the google device from the ipv4 address into the ipwa for multicast group of drives and.

E

This type, this new type, is also used in the ignp uh young model. A nice nice piece.

E

uh Similarly, we also change the type of group guys from ipv6 advice into ipv6 multicast group address uh in the mlb proxy 3, and this this new type is also used in the mlb yamaha, okay and nice. Please.

E

uh After three, uh according to the young young doctor's comments, uh we update the prefix of this yamamoto from mmp into the ignp mld proxy, and here is the abbreviation of the ignp mld proxy. Using the full name is more clear.

E

E

Okay, here are all the updates about the latest version and let's we would like to apply for the work group last call and we welcome more comments.

E

Thank you. That's all.

B

Question here: uh did they do a young doctor review of this? I don't remember right now to be honest,.

E

Yes, the young doctor have reviewed about maybe two months ago.

E

We hope we have already addressed all the comments from the young model uh from the youngsters.

B

So that's worked out. Okay, there are no major issues.

E

uh Yes, uh his side and most of this uh most of this job is okay, just some nice and where we have this, all all the comments from the young.

E

A

Great, so I think we are ready for working group last call.

A

If anybody feels otherwise, please stick up now.

A

Okay, thank you sanji. I think we're.

A

I think, we're good.

A

And if human hasn't figured out his audio yet we may need to move to stig. You know, yeah.

I

Okay, I had to change pc. I I don't know why. The other one is giving me so much trouble yeah, it's fun.

I

Okay, thank you um so next slide. Please.

I

So nothing much has changed when it comes to the different drafts for point-to-mod point policy. The status quo is the same at the psap. We did change some aspects of that draft to fit the pce controller method better um and we are again asking for adaptation into 112..

I

The chair was liking our rate going forward, so hopefully that's going to work out and in the idr uh we did present the point to multi-point policy and uh we did ask for adaptation in idr and in bess.

I

um So this is obviously the transport tunnel technology, so we weren't sure whether it's going to fit in best or whether in idr. um So that's one thing: we need to figure out. Where is the home for it, uh which one of those working group is the home for it?

I

Probably it's gonna end up in idr, but we'll see and the last but not least, is this ping policy and just to give you folks a little bit of background, um since this entire technology is from controller uh from controller point of view, and there is no signaling. So when it comes to detecting data path failure, uh we could either use like m trace type of technology that goes over the vprn.

I

That would test the two ends of the two pes or the ces, and not the transport tunnel itself, or we need to have a technology like the point of multi-point ping that would test the tree itself next slide. Please.

I

So just a little bit of memory refresher here, so this kind of will remind you what you're trying to do here so uh on the head and note there is a point to multi-point policy that has a set of canada paths. uh One canada pack is the active canada pad and the remaining canada pants are back up. Canada pads, if you will.

H

I

The canada pack, there is usually two path instances. The pattern sense is the tree itself. It's the point to multiply lsp itself, where the forwarding instructions or what we call aka replication seats are associated with. So again, the the forwarding instructions are associated with the path instances, and the reason for that is that we were hoping to achieve global, reversive, behavior or global optimization, and so that's why we have two path. Instance under each candidate path. So if there is optimization done from the pce perspective, it's gonna.

I

uh It's gonna nail down a second tree with its own replication segments, forwarding instructions, and then it can do a make before break on the head end to this backup tree and obviously, for this to work. That means that the receivers uh the leaf pes they need to listen to both path instances.

I

So while there are traffic on the fly on the previously active one, you process them, and then you can also process the the traffic new traffic that is going over the new path. Instance, that is optimized. So this draft is trying to test the path instances for each candidate path end-to-end. So it should be able to uh identify each pattern sense for each candidate path and test that end-to-end. Another point I want to just bring up is that you know previously.

I

We mentioned that uh two replication segments could be disjoined from each other could be uh connected via unicast sr policy, whether it's a mpls or srv6 beside the point. So there could be a unicast, the sr policy that connects the two replication seats and, in that case, the replication seat. The label itself is at bottom of the stack.

I

So in that case, in this draft we are really not testing the unicast domain. So we are just testing the replication points where the replication segments are again. We can definitely talk about it and and see whether we need to test the unicast domain, and if so, how do we want to achieve that?

I

But as of now that the way that the draft is it just decrements at the replication segment, it just decrements the ttl it pushes on the unicast label uh whether those unicast labels are going to be pipe mode, or uh I forgot the name of the other mode, the the one that uniform mode uh beside the point. But if the ttl in the unicast domain expires as of now, the draft is not uh testing that it is not able to detect that next slide.

I

Please. So we tried to reuse a bunch of rfcs that are out there, um obviously rfc 4379, just for the packet construction, and then there is rfc 6425, which is the mpls extensions.

I

uh That rfc is for both ldp and point to multi-point rsppte reading that rfc uh we felt that ldp procedures they fit very nicely with the point to multi-point policy.

I

So we didn't try to reinvent the wheel, but that doesn't mean that uh if you know uh the working group has started reading these rfcs and they felt some part of it doesn't fit nicely. You know we cannot modify our ad so that that's exactly why we are here. um So the only thing that we really uh added here is two new subtleties: um that identified the ipv4, uh sorry a point multi-point policy for ipv4 and for ipv6.

I

um So these two stop tlvs. I think it's in the next slide.

I

So the reason I said by the way, ipv4 and ipv6- those are the the root addresses again. If there is a better name for it. We are all ears. uh I I know probably right now that I read it.

I

I kind of realized that it might be a little bit misleading, because the point to multiply policy is really mpls or srv6, but the reason that we call it ipv4 and ipv6 was because it identifies the root id of the point to multi-point policy where really that's the root id and the tree id and the path instance are the unique identifiers that that identify the replication segment at each hop. So that was the reason behind the naming again. If we feel that that's not good by all means, we can change it.

I

But, as I explained, uh the the identifier now is the root address, the three I id and the pad instance, and uh that's how we can identify the replication segments and if the ttl expired based on whether it's a trace or a ping use the procedures in the previous rfc. To reply back to the header next slide, please yeah, so there should be a bulletin that says you know, questions comments, please. You know we are all ears and uh based on the feedback, we are hoping to eventually adopt this uh in this work.

A

Thank you: go ahead, uh g wrong, get.

J

Hello uh thanks holmen for the for the sharing. I have a question: uh do you have the packet for a packet format of the of the p20 policy? Pin packet?

J

J

I

I

Do we need a udp port again, those part of it we left in par with the previous rfc, that we we called it. I forgot what was 64 whatever it was, uh so all those parts are explained in that rfc. We like, let me put it this way when it comes to the data path itself. Really a point to multiplying policy is very much in part with the point to multiply ldp.

I

I know some people might not agree, but basically all it is is a label in and then you got a bunch of outgoing interfaces and you swap the label with the next replication segment and you shoot the packet out the oif. So when it comes to the data pad, if your data pad supports mpls- or you know nldp point, the multipoint is very easy to program your data pad, because it's exactly the same. So that's why we didn't feel when it comes to the procedures, they need to be any different whatsoever than what is inside.

I

That draft, which again I keep forgetting 64 75. I think I don't know whether that answers your question or not, but yeah. That's that's. My summary of it.

J

Oh okay, thank you. I think you, you got to the point that this question is about the pim packet painted packet, which may include the uh encapsulate the the pin echo requires to or echo reply in, odp faster udp and then your ip and then in the talo header. So there is a there is a problem about the what the udp port and what the ip destination address used.

J

Of course you can use the same as as scenes like about dpp or ldp ldp lspp, but I I suggest this this can be, can be checked.

I

Yeah for sure, uh let's take it to the working group, uh yeah definitely yeah, maybe there's something that we are missing. Obviously we need. uh We need to fix that. Sorry, just just to make sure I understand, are you? Are you talking about the entrance v2 that the the udp, uh uh the udp port, is falling in the linux uh traceroute?

I

Is that what you mean- or I wasn't quite sure what you mean by the pin udp.

I

Okay, thank you. Yeah definitely send us a message there. We can definitely discuss it further over there.

A

Since there's nobody else in the queue um so human, it seems like the reason that you're proposing this is because the existing echo request and reply mechanisms for segment routing, don't work for point to multipoint and is that correct? Is that why you're doing this.

I

Yes, exactly because.

I

So when it comes to point to multi-point, uh you need to have the procedure to fan out your uh your trace route or your echo request, which which again yeah the the segment routing and stuff doesn't fit very nicely here.

I

A

And so you need to do similar. You have to do similar things for other protocols and that's why you're doing similar proposals in other working groups correct.

I

Yeah, so exactly so, we feel that the procedures again are very much closer to mlbp or 0.1 multi-point rsvp lsps, um the segment routing is, is unicast that, uh like let me put it this way. If, if this was in this replication, somehow this was increased for application. Then we could have used segment routing procedures to uh test each one of those unicast paths uh from head and to the to the end.

I

So we can actually say that hey, I want to test leaf one or leaf two and and send the the ping to that specific leaf. But if you want to go on to the head end and send a single packet and make sure that every single leaf replies to that packet, the unicast sr stuff is not working the procedures. There's are not sufficient enough to make this happen. So this is why the mldp uh point to multipoint lsps procedures are more in line uh with with the point to multiply policy rather than the unique ssr.

A

That makes sense, I'm going to go ahead and start a poll right now we'll take this to a list, but let's just get an additional, uh an initial um idea of who, how people feel about adopting this draft.

B

Yes, so um can I ask, though, by the way I think my audio is working now without my headset? uh Have you presented this to spring as well, or uh you know, do you believe yeah? It belongs in him rather than in spring.

I

No, I have not presented this spring if the chairs feel that we should present this to the screen by all means, we could do that, but no, I have not.

B

Okay, yeah: now we can, we can check you know if there's interest in him in adopting it and if there is then we'll have a discussion with the spring chairs, whether they feel less alright or not.

F

I

Sure no problem.

A

Yeah, I think that makes sense. The difficulty is never trying to get time to present in spring. So that's why people with regards to spring and point of multipoint they present here, which makes sense, but I agree so right now we have six seven people who have raised their hand to support this, nobody against it. Yet we will take it to a list and if we are in agreement then I think sting.

A

I think the point we're making is that we should then just copy the spring working group say hey: this is what we're planning to adopt and do you have any feelings? Otherwise, we'll probably need to do this at all related drafts related to segment.

B

I

So yeah, okay, very good. I think that was my next question that I was trying to ask. My question: was that it's great that this working group is taking on? You know the multipoint segment, routing and stuff, um but how would this group approach with the with the spring? Is this something that uh we still need the blessing of a spring by presenting it there? But you know if they bless, then the main work is going to be done here or is the blessing with this working group itself again, I'm open either way.

I

I just want to understand.

A

Yeah, my feeling is that we don't after we reach harder, particularly we don't need their blessing anymore, but um we do we. We have agreed to keep uh well coordinated with them and particularly particularly when it involves the replication segment which they do own and which this draft seems to affect. So we we definitely need to be coordinated with them and and.

B

A

B

Right so typically, if there's like you know, like kind of overlap, is pretty common to present drafts in multiple working groups. So so, even if the spring chairs, you know, say that okay sure this this is better to do in pim. You might still want to work to also be discussed in spring. Just to see that you know it makes sense there, because there might be these participants a screen that don't come to payment. So.

B

Thank you, but yeah. Well, we'll see what the spring chairs say. You know whether they feel it needs review in spring first or whether you can go ahead.

A

What we typically do- human and everybody else is, after our meeting, we just ping the chairs of spring and just say hey. This is what we've done. We're planning to adopt this, please yell. If you have any major concerns, otherwise we're just going to keep going.

A

It will change a bit like I said when we officially update our charter, but we'll still still give them that courtesy, okay, understood. Thank you. Thank.

A

B

All right, so I believe I'm I'm next and uh yeah, I'm not using my headset now, so this should hopefully be working. Okay, I can hear if anyone is saying anything um so.

B

Yeah, this draft was presented in lisp on wednesday by the way, so we believe that the work belongs in the team working group. But since it's about this, we want the list work group to make sure that it works. From this perspective and at least uh in the present yeah after my presentation in lisp, they seem to be okay, whatever got it being done in pim all right.

B

So um last itf, um the first version like zero versus serial of this draft was presented, um and one of the things that we discussed uh previously was whether it makes sense to define a new tlv like a new joint print attributes, whether to reuse some existing attributes.

B

So, um just after some discussion about this I'll get back to that at least the the authors um well, including myself, now uh believe it is fine to reuse the existing attribute um I'll get back to that on the on the next slide.

B

So the use case is basically doing list multicast, so you have like lisp sites that have multicast and you want connectivity between the sites between the sites. It can be like a unicast network, so you do head on replication like just unicast replication between the sites or you can try to do multicast between the sites to just have. You know, like normal, run pim and have multicast replication in the core.

B

um So there is this rfc that we did in here in pim 6831 that defines some joint print attributes for lisp signaling. So, basically the way it works.

B

Is you join through the core to establish a multicast tree in the core, if necessary, for from if it's multicast in the core, but you also need to somehow signal between the lisp list border routers, to say what you actually want to receive right, it's encapsulation and the signal in in the core would be just for the underlay grip, but we need to signal and say what what do you actually want to receive over the other way?

B

So um so there's two ways of using this today uh with unicost in the core. You you send this join message and and using 6831. You say that I want unicast replication and I want this destination address to be, for the uni cost packets right for the encapsulation, but you can also use this rfc to say I want to receive my multicast.

B

The problem, though, is when you receive a multicast. There is no way today to say which group do you want to encapsulate this in 6831 doesn't define that.

B

So what we are saying in this draft is that this, the existing joint print attribute in 6841 only want to reuse that for specifying a group address for the underlay, so um there's deployments today using list multicast in the core, but the grip address is just hard coded by configuration or whatever there's no way of signaling this.

B

But we would like to have this flexibility where the receiving site can signal and unspecify the group betters.

B

There's various use cases where you might want to have different, uh maybe have two different end caps for the same group: uh two different flows, s1g and s2g, for instance, might even though it's the same grip in the overlay, we might want to use separate groups in the underway, uh but yeah. The main thing is to just have this flexibility.

B

B

um It's maybe not that useful, but it kind of shows what I was just talking about, where um in this use case, have have regular ip multicast in the core, and so the signaling we're talking about in this draft is basically joints that are going over the top directly between the d routers, like b2 to b1 or b2, to b1 to say what multicast do we want to receive um and that's, as I said in addition to the underlay signaling in the core, so 8059 is defining this um lock attribute uh and it says uh in 5859.

B

It says: receiver are locked and, as I said, that's like the destination address that you want to encapsulate to when you do uni cost in the core.

B

So what we want to do in this draft or what we specify in this draft is basically saying that you can reuse this receiver lock attribute to specify a multicast group address the concern about doing this was like backwards compatibility, but at least as far as we can tell existing uh implementations that your multicultural core, they would never look at this. This receiver are look right because that's specifically specified to be used for unicost.

B

So if you try to reuse this now, existing implementation should ignore it. Only new implementations that support multicast in the core and this new draft would actually go and look at this. This attribute.

B

All right so, um let's see yeah so uh yeah. I'm presenting this as an author, and I would like to ask the working group then, and the chairs uh whether you know this can be adopted and also, if there's any any comments in the working group.

A

Nobody's in the queue, so I'm just gonna go ahead so there's already a lisp multicast distribution tree specified in lisp, um including defining pim joint prune, attribute extensions and things like that to to to construct the tree. So this document extends this to this to facilitate the construction of underlay. Multicast, so um is, are you also?

A

Are you also proposing the mapping between the underlay and overlay uh in this breath? I didn't catch that.

B

A

B

What happens is let's say if I go back to this slide here, so you see here I'm talking about, for instance, like s1 g0 right where g is in the overlay, so that's like some source inside the lisp site is sending say to s1 geo and in the in the underlay we just send a join for, say like the group g u1, or something right, because that's the in the outer header.

B

So what we want to do I want to do with this. Signaling is basically there is this lisp sorry pim joint sent us unicos from one board this port a router to another and saying I want to receive s1 gl.

B

What is new here is that when we send that join to say you want to receive s1 gl, we also can specify oh by the way I want it to be encapsulated inside gu1 or gu2.

B

Okay, so looking at this, this slide here right. um If the source is inside site, one sending to s1 g0, um you won't see a join to go, be sent from by unicast from b2 to b1, saying I want to receive s1 g0.

B

Then they want b2 to be able to say I wanted to use gu for ncap in the core, so the only thing new they are saying here is we use this existing urloc attribute to say what you want the underlay group to be so you can say for unicast, you are specifying the outer destination address right, which is the unit cost address, and what we want for multicast is the same. We want to specify the outer destination, it's just that it. It happens to be agreed better since it's multicast.

A

Okay, and do you want us to pull the working group right now.

B

Yeah, that would be uh would be great, so uh but yeah just to clarify. So um all you are doing here is to relax uh what this one attribute can be used for.

A

A

The pull is out we'll see if we get any response and.

A

We will also take it to a list.

A

Any questions for stig before we move on to the next presentation.

A

All right, so we have six people who are in favor none against, so um we will uh ask the list as well. Thank you for doing that and uh uh let's talk igmp mld extension source management.

A

Is it pronounced one on.

A

One on lead, china,.

K

Hi hi pm experts- I am finally from china telecom I'm going to introduce our draft. Its name is igmp extension, igmp mld extension for multicultural source management. Next page, please, first I will introduce five-way, proposes extensions and procedures. Then I will introduce newly defined messages for itmp and mld next page. Thank you.

K

Among protocols for ip multicast, there is no interaction protocol between multicast sources and routers. So far, the interaction between a multicast source and the root under router is triggered by the multicast source, sending packets to multicast group, which is technic component with multicast data. In this way, multicast sources cannot be well management, especially in large scale, multicast service scenario.

K

In addition, the multicast source is unaware of receivers. The multicast source make continuously send multicast multicast data when there is no multicast receiver in the group, resulting in a waste of resource with specific custom. Oh, we can specify some new messages to extend igmp version, 3 and mld version 2 for exchanging source registration, information and data transmission control, information between sources and routers.

K

In this way, the transmission of multicast source data can be effectively controlled, enhancing the security and controller controllability of the multicast service.

K

We will introduce our solution in combination with the beer, multicast management signaling process based on pcp between routers, in the figure on this page step, step 1 to step 10 are the process, other processes of the over overall solution, where step 1, step, 4, step, 8 and step 10 other related processes of multicast source management.

K

Step one source, sorry step one, so some newly defined multicast source registration, many message into to ingress router, requesting to activate activate the multicast data transmission service step. 2 ingress rooter sends the request information to the controller step. 3 the controller feeds back the authentication results, step, 4, ingress, routers authentication results to the source where newly defined multicast source registration message. If the authentication succeeds the multicast source with ways for the router to notify it to data step, 5 receiver send itmp or mld message to egress routers requesting to draw or leave a sg step.

K

6 egress routers send this request: requests to controller step, 7 controller, inform the egress router start or stop forwarding step. Eight in ingresses routers.

K

Ingress routers and newly defined.

K

To the group step, 9 turn the source stars or stops sending multicast pages step 10 in ingress, router pro periodically newly defined multicast receiver status, message to the source to synchronize statistics of receivers next page secure.

K

So I will introduce these methods. First, the next, the multicast source registration message called the msr method is used for the rich registration and the registry registration of multicast sources, as well as the corresponding response flag. Ibs indicates whether the sender of the message is the source flag. Arbit indicates whether the action of the message is a multicast service request. Flag 8-bit indicates whether the request is is successful.

K

Create grid credential is used for also authorization of multicast resources times stamps are used to indicate the duration of the service request.

K

Next page, please so multicast data notification message called mdn message is sent by router to notify multicast source to start or stop sending multicast packets for different sd tuples. The router needs to send multiple mdr messages. Flags cbs indicates whether to start sending multicast multicast package. Sorry, I made a mis. I made a mistake here, let's play. Thank you.

K

Next page, please.

K

The mo the multicast receiver status, a message called the mrs message is sent by routers distant by router to multicast the source to synchronize the receiver static critiques of a group of multiple different. As you tables, the router needs to send multiple mirrors messages next page. Thank you.

K

That's that some main content of this draft, any comments or of our work will come. Thank.

B

B

Yeah um speaking as uh working group participants, I think this is pretty interesting. um There was a draft um presented or or discussed in the magma working group very long time ago. That also did like a source registration thing, and there was that draft. I presented in pym like 10 years ago, like magma m m snip that also uh yeah talk talked about this uh so yeah. I think it could be interesting. uh There's, there's lots of problems in multicast related to source discovery and, for instance, with regular pim right. They do like data registers.

B

If we add something like this, we could send just a null register, for instance, and have the rp join the shortest path tree to the source before the source starts. Sending the only concern really I see is that you know it's. It's tricky to get hosts to up be upgraded to support new signaling, that's the main problem I see. Otherwise. It looks quite interesting to me.

A

Yeah, likewise, I don't remember the magma discussions on this, but I think it is pretty clever to oh here goes brian. He remembers, go ahead.

D

Yeah you guys just dust off all the old good stuff um yeah, so msnip was was designed around the premise that you wanted to minimize sources, sending data when there were no receivers actually listening and it would it would essentially it would help control the the the extraneous flow of data, especially when you're talking about a uh a rendezvous point that was was, you know, potentially far away the um some of the drawbacks, and this may be a question for the authors.

D

um M-Snip was designed with ssm in mind and it really did not have support for asm. So the question would be: do they intend to support both both modes of distribution?

D

Or is this really just focused solely on beer.

D

So you know there is some history here there is. There is talk of a request to send clear to send kind of methodology for uh igmp way back. I think in the idmr working group as well, so I I would.

D

I would encourage people who are interested in this topic to kind of dig into the archives to to see what kinds of things they might learn from previous attempts to do something similar for.

D

B

Yeah I'll be happy to comment on the on the mailing list, with some pointers to drafts and some some.

B

A

Thank you one and I think we're. I think, we're good do you. uh I guess we just would take this to the list, as doesn't seem to be requests for an adoption at this time.

A

L

Hello chaz, can you hear me yes go ahead, please thank you. Okay, this is uh we chan, chung from channel mobile, and I will give some presentation for this draft at the beginning. I think this draft we don't intend to involve in some specific solutions.

L

The only purpose for the draft is to provide some observation and consideration on our new requirements. So next page uh in this page, I want to present some new requirements and potential use case for the broadcast the. Firstly, the networks are changing the application.

L

And the websites support ipv6, better and brighter the operators network have already support ipv6, uh very well, so the ipv6 traffic wrapped rapidly growing.

L

uh So from my point of view, the pure ipv6 network will be used in the new filter and the. Secondly, there are a lot of new application scenarios for the broadcast, which bring some new opportunities. Here. I would like to talk about more on the ott lab video.

L

M

Richard uh michael, I think this maybe go to the next page.

L

Yeah yeah the wrong the wrong page: okay,.

B

So let me know whenever you're on the wrong slide.

L

Oh yeah, I just look my local.

L

Okay, so uh I just mentioned that the first factor is networking are changing, the ipv6 network will be used, the pure ipv6 network will be used soon, and the second factor is that there are some new opportunities for the broadcasting and I would like to talk more about the ott live video example.

L

I would like to introduce.

L

So on this thursday a new record of ott live video was generated.

L

uh I I don't know if you know uh there is a very famous chinese purpose: uh singer and movie star named andy law and in on this thursday he had a uh online live shoe for his 40 years carrier on the doing application, which is a tick tock for chinese version, the number of on live years, uh even more than 100 million.

L

At the same time, I think it's a unbelievable um uh believable record, uh so you know uh on the at the same time, on the du yin application, there are uh hundreds of thousands similar personal uh live. Video shoe is ongoing, so the problem for operator is that there is no any caster technology used for such a huge mom traffic, because the operators network cannot sense the multicast traffic.

L

This also generates a very traffic, very big traffic burst to the operator's network, so how we can handle that that is a problem. Let's summary, the the the key requirement for this kind of service, maybe a person that can be a multicast source- and you know there are a huge number of those kind of multicast sources.

L

The second is a large number of on live viewers, as I just mentioned this example I just mentioned even over 100 miller. They just for one person, level shoe and for operators.

L

I think there is a big opportunity is that we provide the multicast service. Maybe I want to see mult customer service assets, the multicast as a service is a potential big market uh for operators, so I think it. uh This is some new requirement for mult casting, and maybe we can consider service oriented, multicast technology for ipv6 network, and it's time we can consider some new way for that situation.

L

L

Okay, so uh let's go back to the existing network. We know uh such as a pim. That is a traditional multicast solution. It requires the multicast tree uh which building on a control plan, and there are some new solutions, uh source routing based such as beer, it reduced the status of the nodes and it can simplify the deployment and the matinees.

L

I think both of them are good, but, as I just mentioned, this solution cannot support the service, oriented application scenario. So is that possible for us to concede ipv6 and the mudcast and the source routine, to develop.

L

Combine them together to develop some new solution which can be used better for the service oriented applicant scenario.

L

If that is possible for operator, we can provide multicast as a service. So next page.

L

So here are some considerations on. We call that msr6 ipv6 multicast for source routing here are some basic lists.

L

Let it just uh some initial uh draft. uh Please comment that the first one is. We hope this kind of a solution can support basic multicast functions such as p2mp forwarding, multicast flow overlay, p2mpom functions and, secondly,.

L

We hope this kind of solution can meet the need of high quality services. uh You know the service I just mentioned: maybe need a high reliability.

L

So in order to achieve that, the solution should support traffic.

L

Engineering and some fun grand grand newton network measurement.

L

L

L

This page yeah, so the third requirement may be.

L

We hope the existing uh solutions can be reused as much as possible, such as a beer. We think that is a very good solution and maybe include srv6 because include including a channel mobile.

L

More and more operator operators begin to develop srv6.

L

So we we think maybe we can concede the i76 also and the existing and ongoing ipv6 extension.

L

L

Okay, here are summary: we just write a name, I might sr6.

L

We hope that can have a following carrier statistics. The first one is a native ipv6 design to reduce the hidden layers and the second one is reuse, the existing ipv6 and srv6 capability and the third one is beer. Maybe is a good multicast mechanism and the fourth says I'm reading and the traffic management traffic engineering should be required, but anyway, all those requirements should support the service oriented multicasting.

L

So we write a proposal that maybe now is the right time to consider new multicast mechanism for those new requirements. So that's all. Thank you. Any.

L

A

Thank you. Any questions.

A

If not, my comment commented so I did read the draft. It appears that you're not proposing any particular protocol solution, but you're raising the question of given segment routing, particularly srv6.

A

And requirements with regards to traffic engineering um and maybe even det, net related kind of information, you're suggesting that maybe it's time to consider a new uh solution beyond what we have today. And maybe that includes certain elements that we have today like beer and.

L

That is the the basic content in current draft, but I think we really met some uh problems for the multicasting as a use case. I just mentioned in fact it's a huge opportunity for multicasting if we can provide multicast as a service to those ott.

L

Provider, I think that is a very good, uh very strong, driven streams to deploy some new type multicasting solutions. I think we need that. We hope a community can concede that this kind of requirement, maybe we can generate some new uh protocol or new solutions for the user requirements. Thank you.

B

Yeah, I think it's interesting to analyze. You know what our use cases see. What can we do and what we have today and basically, what is missing? What can't we do today?

B

um It could be good to present this in mb as well, because they are focusing more on the use of multicast to to see you know whether they have additional use cases or comments on these use cases. Well, in the pin working group, we would more see you know. Do we have any solutions, especially work on solutions for those problems.

L

A

A

Yeah good comment, william in the chat so yeah. I would encourage you to take stick's advice and also to maybe bring this up on the mailing list at bim mailing list, as well as in bone d, and let's uh have further discussion. Thank you particularly thank you. We're getting this proposed from a uh operator. That's for us! That's golden! That's fantastic, because we hear we hear plenty from vendors, so it's nice to hear from operators. Thank you.

L

M

uh Hello can't hear me.

E

Hello: yes, go ahead: okay, okay,.

M

uh uh Okay, this is the german uh huawei, so this is a quick introduction about the gap analysis of the ipv6 multicast source, routine. Okay, next page.

M

Okay, so we have this brief introduction about msr6, then the gap, analysis and the summary of the next speed.

M

Okay, since the design consolidation has been introduced by wechang, so here is just a quick glance on the uh imis r6, so this is a for the msr scope for the better effort service, traffic engineering service and overlay service, including the mvp, and also we have this the reliability and oem, and we also need to take into account combining with other ipv6 based functionalities, including the network, slice, iom, alternating marking, ap, etc.

M

So and also this user try to take use of the existing solutions as much as possible. Okay, next page.

M

Okay, so here these are the possible solutions. This is the beer in six, so that's the keep the beer as an independent layer. So let's use the possible solutions for the for the existing solution. So this is the gap analysis as follows. So this is a is not a design for the native ipv6.

M

That means it can also support the non-native ipv6 scenarios, a second one. So that's you for the ipv6 source routine. So there are some these architectural concerns.

M

The first one is the beer is treated as an independent layer, so the existing how to support the existing ipv6 filters, so these possible ipv6 filters include the fragment security network, slicing.net, etc.

M

So this to that deploy to divide, define the new encapsulations in the beer layer or not. So that's the first one, the second one. So that's the if the beer is treated as a separate layer, but the rest of the functionalities are realized in the ip layers. There's also some challenges.

M

For example, if encryption is supported in the ipv6 data plane, so it makes the content of the beer layer encrypted and unprocessable.

M

So this also needs to be taken into account, so the third one as a introduction from the return, so that we think about this, the ipv6 multicast source routine as a host.

M

So that's a this also, if the bearing six you use the for the uh source routine as a host side, so the br layer will have the conflict with the transporter layer, including the tcp and the udp.

M

So that's a and also the source address of this. The packet of the package originated by the host may be also changed. So this is also there's the challenges, so that's the others. That's needed to maintain the tunnel state and the last one, so there's a existing functionality.

M

So that's the brin6 should be extended to support the imovie traffic engineering and ipv6 existing features, including fragmentation and esp okay. Next, one.

M

So this is the gap analysis of the bre6 brv6 used to encapsulate the beer in the ipv6 extension header.

M

So this is a native ipv6 native ipv6 solution, so it can reuse the ipv6 functionalities, so you can also use the ip native ipv6 and initiate the source routine as a host site, and the prv6 also has the following challenges. The first one is a non-mgr sphere. Header defined, but has a appear. Header is designed as a separate layer, so there's a little some fields unused and redundant in ipv6, a second one. So that's the bre6 also needs to be extended to support the mov and the traffic engineering.

M

Okay, next page.

B

A

You're able to take it go ahead, greg.

A

You got a question greg. I recall.

N

That um in the beer working group, these two proposals received a very extensive discussion.

N

I don't really understand what is the purpose of continuing this discussion in pim group.

M

Okay, so this is a not only the peer discussion. This is a discuss, the gap, analysis of these solutions for the ipv6, the multicast, but.

N

But your analysis seems to be one-sided.

M

Okay other to learn the other side.

N

Yes, so basically, you provide position of one of the side that was in a discussion in a beer working group. So I don't really see this gap analysis as unbiased analysis. You are promoting single solution.

M

Okay, so I think that's a if you have this one. This can be go on to be discussed in the main list, because this is a beer. I think now that's used for the best as effort service, but we also have the traffic engineering work to be done for the ipv6 source, routine.

N

But why not to have this discussion in a beer working group why to take it outside of beer working group? That's what I wonder.

M

uh But this maybe for the traffic engineering worker has nothing with the beer.

N

Why, for example, we do have a brte architecture in a beer group proposal, so traffic engineering in beer, in my understanding, is very much in the scope of beer working group.

M

Okay, so this is because you know that's the some of this work is in the pim working group to take use the routine header to encapsulate the multicast tree based on the srv6 segment. So I think this work is related with srv6, so we think this user should be discussed in the team working group.

N

uh Well, definitely, that is something that working group chairs can decide, but I really wonder why you take uh you: bring the beer discussion to the pm working group without discussing it in a beer working group.

N

I think I'm personally.

M

Very much surprised. Thank you, okay, okay! So that's a user depending on the solution. Okay, okay. Next page.

M

Okay, so this is the summary, so I think that the existing multicast solutions are not as sufficient for multicaster source routine to support the future potential multicast use cases.

M

So we think this is the right time to expect a new multicast solution and also is just as discussed with the greg, because this work related with the spring beer and ipv6.

M

So that's we think that's a work has a multiple uh involved parties, so here we're just thinking about this to be done in the team working group spring working group or new working group. So this is depend on the coordination of the different working group.

M

H

M

H

um I think, like the previous draft, uh we're presenting here uh a problem or a or an issue that needs to be addressed, and so I think the ambon group should be also where this should be also this cause or percentage right. So what's the uh evolution of routing for uh given the the amount of traffic, etc, etc, and so that should be where the emblem group should be where this should be. This course, in my opinion, thanks.

M

M

N

Correct I'm surprised that uh in the list of their working groups, you don't mention beer working group, but I would strongly uh encourage you uh to bring this um and discuss it in a beer working group, because uh my understanding is that uh beer technology solution uh is absolutely capable addressing uh most of uh issues that you identified here and, uh as I noted, uh traffic engineering already has an architecture document that uh being progressed and if I understand correctly it's on in isg review.

N

uh So um there is a solution. The proposal how to address it- and you can look at it and see and that solution is- can coexist at this domain uh with what can be characterized as a classic uh beer and uh traffic engineered there. So uh again, uh please bring this uh discussion to the beer working group.

M

Okay, thanks for your suggestion, we'll take it into account.

A

M

A

The takeaway, then, is to continue this discussion in mbondi and pem in beer um and any maybe spring since it's very srv6 heavy and.

B

A

B

There yeah this touches on a lot of working grips, but uh yeah. A lot of this has been discussed pretty intensively in in here. So uh I certainly think that this this needs to be uh discussed further in here as well.

B

Basically, you know a lot. A lot of these uh gaps are like beer specific, and it would be good to. You know, get analyzes done in here to see you know whether these gaps are there or or if the space was solving it with beer or whether it can't be done with existing beer.

M

Okay, we can, we can go on, have this the more gap, analysis and also uh later present. This work in the br working group, okay,.

G

Great thanks again.

H

Yeah, thank you, but.

A

Let's move to tourists.

O

All right, you're sharing the slides for me great.

O

Okay, next slide.

O

Okay, so the goal this is part of updating the core pims standards that we started with igmp, and so this one includes ignpv1 which we need to retire. So we need to obsolate 1112, but basically keep everything except for igmpd1, and the main issue is this is also the only and the most you know basic core standard for multicast.

O

It's full itf standard, so we'll need to figure out how to manage the process that this can go back immediately to full standard, there's going to be no functional changes of either what's kind of functionally written or what I think is actually implemented, and I think we'll take alvaro's advice as we walk along next slide.

O

So this is what I did for the zero zero draft. Admittedly, it's all the simple stuff: I removed the igmpv1 section and text referring to it. uh So that gets the main thing um done. I added references to v2, uh ignpv3 and mldv2.

O

um Those, I think, would be replaced with references to the drafts uh that are meant to supersede them so that you know ultimately we'll have a big cluster coming out together, all pointing to the right. You know documents referential to each other. I added text to make this apply equally to v6. Obviously this was written when there was no v6 in 89 um and the existing there is no existing ipv6 document. That would do anything similar right.

O

So there is some text in a 8504, but that doesn't really capture what this document does, and I also added a text to say well. This is now also called asm and references to the ssm documents that we have so that we also unconfuse people that have seen you know asm only being referred to as ip multicast in code. This document, which is the bible for um you, know.

H

O

Next slide so now we're getting to the tougher parts.

O

um So this predates also the rfc 21 19 and later uh language with must should and and so on, and so I'm not even sure if it would be possible these days with all the itf politics to simply keep the text as it is without starting to you know, change small letter must to large letter must, and so on would love to hear input from alvaro on that one if we even have the option, but maybe we do actually want to do this so trying to find the places where uh requirements have to be capitalized is is one of the tasks I wanted to take on.

O

Anyhow next slide.

O

Okay, so what is 11 1112 actually normative for right, because people think it's just the api to the applications and we haven't standardized the apis to the applications outside of tabs working group so fairly recently, it is actually the protocol part of the host stack of ip multicast without routing uh send and receive multicast actually has three levels defined right, so no multicast only allows sending of multicast, which kind of an 89 was something you got for free.

O

You didn't have to do anything for it um and then level two, which is what we today perceive as multicast, which is sending and receiving multicast right, so it is normative on the wire behavior not explained in any other rfc, and so, if you were asked for adoption of rfc 1112, you know I. I basically asked the counter question, so you know show me a single system that does tcp that doesn't implement level 2 ip multicast, because, for example, in ipv6 it's even mandatory for basic discovery and right. This is not multicast routing.

O

This is multicast whole step right, so um zero and one more questionable I'd like to keep them. I think that's going to be an interesting discussion. There are going to be crazy issues that might come so next slide.

O

So what was actually the biggest normative issue with this whole stack right so, and that was really that um we had packets with the unicast destination address, but source addresses in the multicast range, um and those perfectly well resulted in denial of service attacks in a distributed fashion with the unicast destination, returning a multicast packet with icmp port unreachable, or something like that, and that, of course, is correctly written as you must drop these packets in 1112. But you know 1112 was never mandated anyplace else. So a lot of implementations didn't do it.

O

We fixed most of it in the early 2000s, but it is not today uh a mandatory update for 791 ipv4.

O

Obviously there is nothing even equal for v6, so I think one of the things is that this this document will need to end up being a mandatory update for rfc, 791 and 8200, or 8504 still need to figure that out so that, basically, these very simple things about there are multicast addresses, they're, multicast, packets and and they're multicast addresses, and you know what you do with with packets of either shape the ones that are multicast packets and the one that are just crap so and 11.

O

12 already says this fine, but needs to be mandated next slide so yeah. So it's ops. It's meant to obsolete 11 12.. There is a bunch of other strange techs in 85 or four I've started to look into that. Doesn't look too good, so for the matter of time or running out of it, I'm going to skip over this just captured it for my own notes here for the update for the next update next slide.

O

um Actually, these these back packets with multicast source addresses they should also be dropped on forwarders. um This is necessarily going to describe all multicast following. There is no really good rfc at all that says what every multicast forwarder should do, but this one piece I think we can sneak in there to really make sure these these packets, even in ipv6, are never going to cause issues next slide yep. So then the uh not so fun stuff.

O

So, with the situation that you know, a lot of these core documents were written by steve leering, including 8200, where he also didn't edit anything and bob hinton was doing that for him and after 8200 was finished and, and that was fine.

O

The the itf process put some more hurdles into it like you cannot submit any draft without email addresses for every of the authors, and uh you know um steve darian doesn't want to have his email address, published and um authors actually are not the ones who are editors but the one who are responsible for the content right and obviously it's still the same content. Even if we change the wording um that, from from steve so alvaro, already discussed this in the isg, thank you very much. So hopefully that piece we're going to figure out.

O

There is also the question of copyright of transfer of copyright, which you know, isn't implicit by old documents that happen also in the late 90s early 2000s, so um yeah fun, administrative stuff. So that's pretty much it so I think the next slide. The plan will be. um Please start engaging in that I'll.

O

Try to bug the igmp biz design team meeting um with with the work that I'm doing- and you know co-authors, for this one also welcome and hopefully it'll be in a shape to ask for working group adoption by uh itf 112 in november.

O

That's it thank you.

A

D

Hey torellis, um I'm I'm almost wondering if what this document needs to become is something similar to the um scoped address, scoped, addressing architecture document for v6.

D

um I think what we need to be able to capture is is those broader?

D

Those broader pictures that you were discussing- and I think 11 12 is is- is a good starting point, but there's a bunch of other things that we would need to pull in, which will allow you to capture some of those relationships between 791 and the various ipv6 documents as well. So we may. We may need to think about this as being a slightly bigger project than just yeah.

O

Just where, where we've started well- let's, let's discuss this so far. I haven't seen anything that I would feel you know um worried about asking to simply keep the this as a full internet standard like 11. 12 is because there is really no functional change, functional scope, change other than the obvious one which is same applies to ipv6 and and all this stuff has been working perfectly well. Unless somebody ignores these simple, you know send and receive packets from the whole stack like we've seen in before. I haven't tracked a lot of that in v6.

O

Obviously, in the one vendor we had the problem with before we fixed it also for v6 immediately, so it didn't show up independently at that point in time. In the early 2000s, there wasn't much v6, but if you can see now a lot more vendors in iot and other spaces, you know implementing, maybe even only v6, so yeah bring it up. Please, let's, hopefully have this follow-up discussion on the design team. I don't know what other stuff beyond the scope.

O

um I hope I can get the stuff moved into the pmwg github mic when you're listening to this right, um so that we can start putting also issues up there so that we can track these things.

O

Any other questions for tourists, otherwise we need to move on to the final, uh unfortunately, to need to leave. I have my third presentation, this slot so but I'll watch the recording. Thank you thanks.

A

For joining and you look good see.

A

Ya all right: let's talk 3810 and 33.76.

C

Oh hey, uh I'm already.

C

Hello uh yeah thank you uh good afternoon and good evening. Everyone, my name, is anuj and I'll, be presenting on the behalf of the team working on advancing igmp, v3 and mldv2 to a full internet standard, uh instead of taking separately about both igmp v3 and mlv. Due draft updates I'll be presenting the update together through one slide deck, which is showing me here next slide, please yeah. So this work started some time back. First, with preparing a survey containing a set of questions about the implementation status of the different versions of igmp and mld.

C

It also had questions about the implementation specifics and the implementation perspective of the vendor, so different vendors participated in the survey later. Server results were captured in a report and they were also published in a draft so currently team focused on developing the zeroth versions of rsa 3376 for igem pv3 and rfc 38104 mld v2.

C

So main idea was to focus on the criteria to make these rfc's full standard, so primary focus was to access, assess and incorporate valid errata, also to identify if there are any other potential. Changes needs to be done in these documents.

C

Some of those changes could be like consolidating the work done on igmpv3 and mltv2 via some other documents. Let's say, for example, rfc 4604 is one of them, so as objective here is to make these rfcs full standard.

C

So what we have to make sure that there shouldn't be any optimizations done in terms of protocol exchange and all changes should be more inline to make them a full internet standard.

C

uh So if there are any unclear parts of the rfcs that should be explained in a better way, it could be either like parts which were unclear during implementations or leading to making some assumptions while doing these implementations by vendors or like host implementations.

C

So changes should be done to remove parts of the rlcs which were not used by any vendors or any implementations.

C

So initial versions of these documents are published with valid errata and can be accessed by these links, which are there present most of the content of zeroth version. These best versions for three three, seven, six and three at one zeros- are borrowed from rfc three, three, seven, six and three eight one zero. So it would be better.

C

Like if we use the diff tools to see the differences for those people who are already well aware of the rfcs and have been gone through them many times uh all the issues which we worked on or which are all currently also present like open issues, they are all tracked by the github and if working group has any issues which they wish to report, so they can use the github next slide. Please yeah!

C

So we have instead of talking about all the things. So we have picked the representative issue on which teams spent a good amount of time. So this this is an existing error against the definition of older version queried present timeout in rfc 3376.

C

So the older version queried interval is the timeout for transitioning a host, backed by gmpv3 mode. Once an older version. Query is heard on the web, so the problem here is the referenced variables in the definition are not even available to the listening host. So we looked at the three sampled implementations and they do not use the formula formula originally mentioned in the rfc 3376, so keeping the criteria of like full standard and mindful internet standard in mind like interoperability and consistency between the implementations.

C

So we updated the definition text so that it could be clear for the new implementers as well as text definition text was updated to reference values available to host and they were more aligned with the information found in old query messages.

C

Clear justification for this definition is provided in this document uh why they were required in the first place at all, and now definition is like more aligned with what is implemented and what is used in operation.

C

So what remaining item would be like carrying this definition over to the from three three seven, six plus two, three, eight one: zero base, mld v2 for the consistency next slide. Please.

C

Yeah, so what would be the next steps that needs to be done? It would be like going through the remaining issues which are documented on github and or all other issues which are going to be reported. So all those issues should be considered and a few other things would be like discussing with the working group and the ad for the status of the older versions of igmp and mld like rfc one one, one, two igmp v1, two, two three: six igmpv2 and two seven one zero for mld v1.

C

So what should be the status for them? Should we move them to historic or they should still be marked as obsoleted in the uh new standard and um like we would be looking for working good working group adoption going forward. Any questions and comments.

C

That would be all from my site.

A

Thank you and stay keep driving this, so I'm going to let you continue to do so.

B

Right so um we I don't know if you should do a poll, but I'm assuming that there's good support in a working group for trying to make the our car rc's dodge and pvtml leave it to full standard.

B

And the way to do that is by writing these this documents that you have started on here. So I guess the main question is whether the working group thinks you know they are of sufficient quality to adopt now or whether it's better to to wait.

B

um I don't have a strong feeling on that um to adopt now or or.

B

B

D

Well, since um mike likes to use the uh the hand raised tool, I would at least be interested in whether or not people in the working group are are supportive of of the direction we're taking with these documents.

A

C

A

P

uh I I agree on the adaption, but uh uh what do you think about validation with uh lightweight version of igb3 and mldb2? Because there is no description about.

P

D

I'm not exactly sure I understood your question. Could you ask it again.

P

um Because uh there is no discussion about uh relation with a lightweight version of igb v3 and mld v2, the rfc number is lfc 5790. That is also a.

P

Proposed standard- and I don't know, I'm sorry, but I only attended a few meeting of the design team meeting and I couldn't follow everything uh of the discussion inside the design team meeting. But uh if we can exclude the explicit mode operation, then you also need to live for the lfc 5790, because uh lightweight version igp mldb2 uh are pretty much is simple and it's easy to implement in a host side under the outer side implementation.

P

So so I don't know what kind of discussion uh happened in the design team meeting related to a lightweight version and excluded moderation, and so on.

D

Yeah so most of us all the sessions I attended, we we, we did not discuss the relationship with with the lightweight versions, and um I think that's those are valid issues to um to add to the to the issue tracker so that we can actually look at that um because part of what we have to decide uh and um and the slides allude to it a little bit with you know what we want to do with the with the actual older versions of igmp and mld. You know: are they?

D

Are they just simply going to be? You know obsoleted by this new draft, or are we actually going to move them to historic and there's there's all sorts of administrative things that kind of go along with that?

D

I don't see any reason why we can't add the lightweight rfcs to to that list for consideration of how we want to handle them in relation to these new documents.

P

Okay, um so my question is that uh if the aim of this uh standardization is just for fixing the a ladder, uh I also want to say, maybe we can just exclude the unneeded functions from the full spec mode. So maybe this kind of discussion could be valuable, so this is just my comment. Thank you.

D

Thanks for the question, that's a good thing, good thing for us to consider.

P

A

Yeah and for what it's worth brian we've had six people uh in support of adopting and not against, so we'll, of course, follow up on the list with this and I'm confident that it will be adopted, they will be adopted any other questions comments about this or anything else we've talked about today, we're nearing the end.

B

Yeah, I can maybe add that if anyone wants to join the design team, it's it's open for all and they were looking for volunteers and, uh if yeah, if there's someone else that hasn't volunteered yet welcome to join us.

B

But yeah, I guess we are done then.

A

Yeah, thank you we'll see you in madrid or not. I don't know.

B

Yeah we'll see yeah. Oh that's a big rate.

A

B

O

A

A good weekend.

O

A