Internet Engineering Task Force 104, 28 Mar 2019

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF104-PIM-20190328-1350

Description

PIM meeting session at IETF104
2019/03/28 1350

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

A

A

B

I'm not sure what I use that the providing.

C

Lamia, don't you know.

B

How to use yeah.

B

No, oh that's for the mouse, the remote! Thank you. It's forward for this right! Sure, right, yeah, I, think it's just before my cookies.

B

Yeah yeah, all these three minutes. It's a meeting get that minute taker.

B

Yeah I need to get Jake 400, but yeah I can take commitments which should take minutes along okay, I'm. Sorry.

D

E

Derek, okay, we're gonna go ahead, get started! Thank you for coming. People may filter in we're competing with spring. Unfortunately, we'll try not to make that conflict next time, but proceed being here.

E

We do need a thank you for getting that door. We do need a note-taker, our usual people that take notes are not here. Does anybody.

E

Have interest in taking notes and it's.

E

E

So we just do it this time, we're just gonna. Do it we're just gonna have to take turns and do it ourselves plus we got the video, so we can go back and watch the video if we have to fill in the gaps, all right so no well. This is our agenda should take us most of the time today.

E

If any that looks incorrect, if we missed you, please say something.

E

Hooman we I know you have a draft name, but we just didn't update this with your draft name that yeah it's it's there.

E

All right so stayed you're gonna. Take all this.

B

Alright, so we'll try to go through all the working group documents and what her status is. So we have a pin yang model that has been approved and it's been in the RFC editors queue for half a year. Maybe it's basically waiting on references, there's a lot of other young documents that that it's waiting on so sorry, big group or young documents that will go in together, I'll be published together a startup cease.

B

We also have a MP and Emily yang models that are with the isg and there was an ITF last call and there's some comments and some work on addressing those we'll have a presentation on that today. I believe so, as an MSc p, yang model did pass last call and we yeah. We should probably request publication for that now. There was some question whether there should be adjacent example in there or not, not entirely sure that we may have to ask a llevarlo.

F

B

Some young expert, but you might just request publication and see whether we will be told to add that or not we got the multiple upstream document, so it's a little complicated, but basically our ad and the is G doesn't think it's worth publishing it the way it is now as we understand it, it's just requirements and they fought a requirements where it may be, not that well not worth publishing. So the offers are asking to publish it as an independent submission.

B

Basically, anyone can unrelated to working groups can go ahead and publish a document as an RFC there's like a separate approval process for those doesn't really mean much for us I think, as the working group will get published the document at how the requirements that we agreed on that we wanted to get published. It's just that. It's not officially a working group product of the working group see you next slide. I was trying to change all right. We got the dr load-balancing draft. We requested publication for that.

B

Since society f, we got Emily slipping yang model, get an update on that today. It might be ready for last call. Perhaps we'll talk about that the before prefix or ipv6 next hop the offers have been very lazy. That means I have had been very lazy. I'll try to work on that for next ITF, dr improvement draft it past working group last call the rest mandatory all comments, and almost all of them are addressed. I had two very minor comments. I think they're waiting for a bond last relation to to satisfy those.

B

So yes and the thing in those revisions, seven I commented on, and you said that you would address my comments, but I don't think they have attribution eight yet.

F

Yes, I said I'm out for you to make sure than you. The new explanation address you're, okay,.

B

F

I haven't submitted a new version: okay,.

B

Wait: okay, I will I'll check my email too, but yeah. It's just that editorial might very minor thing. So once that is done, though, will request publication, and then we have an explicit tracking job that is dead and probably remained that unless the author's or someone else decides that they want to work on it.

B

Okay: okay, we also have our draft on reserve bits that will be discussed this meeting and all registered packing as well and there's also a draft on by using point-to-multipoint BFD that got adopted since the last meeting, but we're not discussing that today so I think that's all we working group documents that we have right now.

B

Any questions comments.

B

Yeah all right.

G

Good afternoon, I'm chief Miller from water networks here to give a quick update, Toto documents. This is the first one, the smoking model, so we we are trying to get some updates to this document and the since last revision.

G

We are tracing few comments because we have another similar young documents, which is a AGM pmid young or though so we got a lot of comments for that document. So when we review the comments, so we think a lot of our comments can be applied to this document. Also so, which is the address. The most comments in this document also, and some changes particular to the model. So here there are some tax young tax already been published in some other documents, other models.

G

So the comments is that ask us to reuse those types so that we can share the same type between models. So here are some examples here, instead of what we use the IP addresses, so we are dative and the multicast Corp address and multicast are sausages, so we just echo had to use them so making a more consistent and more precise and those are the changes and we have down for this document, and so we still trying to see if any further comments if we have any or dress them.

G

Otherwise, probably we can go further for the next call.

B

All right, thanks so see we're not too many people here, but have you read this document? Raise your hand if you have read this document?

B

Okay, one person so I wanted to ask people photos ready for last call, but it's a little hard with with only one person having read the draft.

B

So unless you have any objections, we we plan to do a record blast caller on the mailing list in a few weeks. No objections right. Okay, so you do plan to do some additional revision firsts. Are they pretty much ready to do? The last call right now, if you want to.

G

Write then we think of pretty much merida, so the comments we solve another document already been prior to this one.

G

Alright next document that's a different model, so this is for the proxy.

G

So this is a revision, 0 1, so 0 0 was a present 8 in Bangkok I think so there are some really received some comments to this model and thanks for those comments, we addressed other comments so far. So when is that the place where we should argument this one's at the model from young models, we have a base model and augmentation model, so we're trying to fit the big structure of the routing protocols, all the polar calls together and so the place.

G

We think it's better for this model to fade. No, it's nicer routing protocols and particular protocol for this one and also there's another comments about the restriction between different models.

G

So, let's look at the changes, so you should be since we're trying to enable us to say both the proxy and particularly interfaces without probably put on the interfaces and but the interface here is it's not a good place, because that could be different kind of interface and may or may not be the protocol interfaces and the current conversion is that we have all the protocols kupah together in the place like the control protocols and protocol and list of protocols. So we do the same here and move the structure here.

G

We have a list of interface here so that we know which interface we are trying to do the confirmation and that's one change. Another change is the restriction between the models, but now we have the proxy in about an interface which should be we need to check.

G

The pin should not be enabled on the same interface, so we added check, but there are some issues and so because we just assert the proxy model and so to toe the check. We have to access the pin model. So we have that these issues. So if we try to implement the proxy on the system, we may not have the pin implemented at all.

G

So we had this issue and yesterday talked with the young doctors in the net count session mode, so the consensus from them is that so the way we are doing should be okay, so here, even though we don't have the pin model implemented, we can still import the pin model and mark them as Justin cost, not imprinted, and in that case we can still to the checking and they are trying to improve the yen language in the next revision, so make it better usable we can check see if the particular model is in imprinted are not implanted and that's a client in still being discussed, see if they can be put into the next revision of the yen language.

G

So we'll see if we have that feature then well use that data, but for now we just to whatever we do here, unless we have objections from the working group other that, so we like to receive more comments, and so we can impor the model further.

G

That's it! Thank you.

B

All right thanks so I guess that question is whether we should have adopted this as a working group item.

B

Can ask how many people have read this draft the IGMP MLD snipping draft?

B

Can you please raise your hand if you read the the IGMP Emily snipping draft, any people read it a couple of people, two people.

B

So so now there's been this young model design team working on this, but it looks like there is less vendors work that were involved with this one than the other documents.

G

We are trying to cut seems like yeah, we came back more participant. Also, we got people from Cisco VMware and not the Huawei and others so I think of a resume. We create discussion meeting from.

G

Participants to the session.

B

B

So do you do you have a feeling where this is something we should work on? Is it useful to have a young model for our gym? Pml is sleeping. Okay, one person yeah.

B

Yes, this has been around for Inc, like maybe three ITX, now more so, and at least there's a handful of people that have been working on it so from a few different vendors, so at least they are interested, so I think maybe wish we could do another option. Call on the list. Do you have any thoughts on that.

E

Well, we had two people that raised their hands. Do you of those two or anybody else think that we should have got this work.

H

Ian Duncan Sienna I'm, neither a yang.

F

H

Or an ml d or IGMP expert really haven't I, understand them that I've worked on implementations of some of them, so I, don't feel qualified to say whether the document as it's written is correct, but I think it's work that we should be doing. Okay, fair enough.

E

Well, we appreciate you raising your hand anyway, so okay well well, we'll make this request on the list. Thank you and they're working on getting us another microphone.

B

All right, so this draft is about penal register packing the offers couldn't be here so I'm presenting on their behalf.

B

This was adopted as a working rep item since the last ITF I think very recently, at least so the most you remember this I guess the idea is simple: some deployments you have to send hundreds even maybe thousand lot registers every second or something like that, because it's a single message per Eskimo G and this causes problems if some of those small registers get dropped for because of control, plane, passing or other reasons- and you know, if you miss some of those, you will end up doing data registers and the load gets even higher on the RP and so on.

B

So based on several issues we've seen, but also like Cisco customers, we decided that it would be useful to have a way of sending multiple Eskimo gene all registers in a single message.

B

So that is what this draft is about and in addition to the they're packing itself, there's also this compatibility check, which basically says that initially, you would send the the regular registers we have today. But if an RP supports this, it will send a bit set of bits in a register. Stop messages. So that's where the first uproar can learn, learn that your pin supports this and can change to using this new new type of knowledge. Sirs.

B

And the other is some some good reasons for doing this. The changes is last time is mainly the the P message type. There is this draft I'm presenting after this that talks about how to extend the PIM message type face, and this has been changed to make you so that there's also so many cast RP considerations.

B

Basically, if you do any cost RP, you should make sure that you either enable this new support for this new thing on all your piece or none of them else. You might have a first browser that initially registers to one RP and thinks it supports it, then, because it's any cause it might suddenly send a registered to one on the other, our piece which maybe wouldn't support it. So so that's just some text explaining that. That's that's all that happens since last version.

B

Let's see that's all we have so I guess the offers would like input on on a changes or we like people to help review the document.

I

This is, do you know, I I haven't read the draft just want to know I hope. The format is exactly like a giant prune message since.

B

I

B

No new code has to be written. You can use existing code right so basically you're saying that, for instance, you would like to have a group range and the number of sources, or something like that. Then yeah yeah, right right, yeah, there's another job presented later today. That also does this type of packing and that some may be something to consider for that as well. Right thanks to skill inputs.

B

Yeah yeah any other comments.

I

This is Deena um so protocols for what's called protocols for internet multicast, IP multicast. So why isn't the EM also stand for hambone? What why isn't hasn't it been combined and I thought that was something I was supposed to happen.

E

Yeah we're not thank you for the comment. I, don't know if we're gonna get into that again, but we have discussed that a lot yeah. We decided not to you that there's plenty of working both organ groups.

A

But they're trying to meet.

B

Together as much as we can lock in their JS and slots, this time we had a lunch break between those all right. Okay, I think: that's it for this document.

B

That's the research. It's.

B

B

Okay, so this is about him reserved bits. It does a couple of things, the main thing at least what we fought initially was the document how different we throwed bits have been used by different RFC's.

B

There's, no there's no place today, where you can go and see which bits are used by which IRC and some of the sources should have updated 4601, but they never did anyway this just so. This document started out explaining that, but maybe the most important part with this document is extending the PIM type space.

B

So, as you see on the bottom here, we have type 13, 14 and 15 and you're, proposing taking four restore bits for each of those types and make make subtypes similar to what was done for embody before so what happens is the pin header type will change from what you see at the top there to the bottom one. So after the type, you have a sub type field that this forbids.

B

So we talked about this before too, but just repeating this. So basically, what happens is that new new? If you do this, the new RFC's would not get a single like type like type 30, no type 14, they would be assigned, say, type 30, not 0, 30, not 113, not 2 and so on. So this gives us 48 new types instead of T that we have today yeah. So this document was adopted, I think well kind of recently and I kind of want to move ahead with this and maybe go for last call.

B

So it's been stable for a long time. I don't know anything that needs to be added to it. But please, let me know if you have any concerns and the thing is we have some new new drafts that might need new types soon and we would like to you know, use this new sub type space for it for those drafts. This.

I

Do you know, do you think you have enough bits where you can assign one type to vendors specific and then vendors keep two things.

B

I would be kind of hesitant, at least my feeling is, that would become hesitant to give them say one of those types like 13, 14 or 15, because that will reduce it to like 32 types that we have used this subtype. But we could we could, but we do have. If you do this, you have 48 types, so it could maybe assign a couple or a few of those for the eight types for vendor specific.

B

Yeah yeah yeah sure.

B

Yeah so I think we talked about earlier that this draft could just stay around until we be neatly needed the type space there's no urgency publishing this, but given that you're on your drafts that that you might want to publish in an ITF or two or something I think it would be good to just get this done, and so other drivers don't have to wait on this.

B

That's my my feel at least so any comments on the draft. Do you think it could be ready for last call should ask the chairs if they would consider last call on this or if you want to ask the room, there's.

E

Only one left by default, so who's read the draft, so I see three hands four hands: okay, so of those who think that this draft is ready for a working group, last call so two of the four Fila. That's.

B

E

Of the four okay, all right, so that's good indicator, we'll take it to the list and see how we'll get responses, but I you're, probably right.

B

All right thanks yep, then I got one more.

D

B

All right, so we published fairly recently an RFC on this BIM flooding pellicle. The main purpose for now is source announcements, but it could be used for other stuff and the way it's defined this, the first up, router with every 60 seconds or some configurable time, send a periodic update with all the active Eskimo G's that it has.

B

Yeah and the thing is potentially, there could be a big amount of state and it's kind of unfortunately having to send this updates every that yeah that often also you kind of want to send them, often just in case you missed some triggered updates.

B

But if yes reliable way of doing this, we could send updates much less frequently. You could pretty much only sense you get updates only rarely do like a full update. So at least the idea in this draft here is. We want to try to make pfm, pre or reliable and we're thinking we can maybe use import for this so import. We have reliable transport between peer neighbors and this message is doesn't hop by hop between neighbors, so that seems fairly easy.

B

So what you're proposing is some new port message types so that we can send not just join principal, also send these messages so.

B

You are suggesting that port connections can be established between neighbors according to the existing pin port RFC, and then we have two new message: types one is for sending and pfm update, so a more less than the update as it is defined in the pfm RFC. But we add a major and a minor sequence number to identify the updates.

B

We also have a new message to request an update from a neighbor. So when a TCP connection comes up, you can send this message and say the latest I have from these two originators. Are these versions and the neighbor can send all the latest it has. That is more recent than what was requested.

B

And also, if you receive a message from a neighbor that is, has something newer than what you already had. You will update what you stored and it will send what you just got to your neighbors.

B

And this is major and minor sequence numbers. The idea is that each full update would have like a major number 0.0, 1.0, 2.0 and so on. The minor updates would be say, 2.1 2.2, which are updates versus, say, version to 0. That was the full update and if you get the full update, you can forget the course all the previous state you had from that originator. If you don't get the full update, you need to remember the previous full update, still plus all incremental updates since since to us full of it.

B

I should say, though, that we didn't have time to make this perfect. We can see some issues with how we describe this and we will do some more work. It's a little bit like. Maybe how an OSP fo ice is how you ensure that everyone has the latest information, except that this is using TCP for reliability and one of the main issues we have in the current solution.

B

Perhaps is sequence numbers we rely on these numbers being always be increasing, but if a router restarts all you ensure that it can use numbers that are higher than the previous used versions, so you can maybe rely on the clock or something like that, but it's vicious with that. You can maybe need some way of finding out the last version number that is out there in in the domain or the network and then finally, ok I need to use something larger than that. This is something that has been solved for the our GPS as well.

B

I think so, there's more work to do here, guess my main question, for you is thought about adoption or anything. But what do you think it's useful to to work in this space and happy for any feedback? Of course.

I

This is Dina, I, don't know if it's real late. It's not related to this draft, but I was just wondering and it's kind of off topic, and if you want to tell me to sit down, please do, but is there any requirements to send him control messages encrypted, and would you consider adding quick to port.

B

Yeah, so the there there are people that want to do authentication, no pin messages, I'm, not sure about encryption and yeah, maybe okay. This is just me talking as I know as an individual you develop import which has been defined but I'm, not sure if anyone has implemented it. So this it wouldn't be a top priority to had a quick unless that is actually something that you know would make it more useful to people. We.

J

Had that telepsychic we had that discussion a decade back in snooping and when we're doing PIM security. The discussion before the RFC and I think one of the compromise that we seem to like was to I only have authentication but zero encryption so that you could still see what payload is there, but they would be authenticated.

J

I've, never seen that being done and to the best of my knowledge now, both TLS, 1.3 and quake are kind of of the matter that zero encryption. Nobody needs that. So it's not in the profiles. It's one of the things I bitched about in TLS, one three, so I'm not sure how difficult it would be to use you know, TLS or quick, where zero encryption only authentication. That's what I would love to see.

B

Another thing I think we need to consider where transport like TCP or our quick is, if you actually want to have like a snipping device that can do say, like PIM snooping to actually have connections explicitly terminated at the snipping device or something instead of having to inspect these I know packets on the wire, maybe.

I

Maybe I should ask the more general question is: do you think the performance properties of quick merit adding it to port, not just for encryption.

I

B

Yeah I mean I think it could be fun to look into it. I'm happy to maybe have some discussions.

B

All right, I think that's, okay, one more comment: I.

J

Mean I, obviously like port, so you know if we adopt anything new, it would be lovely not to have the new staff be a reason of not being able to to use port right. So from that perspective, I'd support this year down to two. Basically, you know when people want to start using it. Unfortunately, I feel that there's so little support for port right now that this may be a little bit still not sufficient to have people import.

B

Yeah- and it's also a draft presented a little while ago on em registers using TCP or port for transport, so I guess we need to see overall how much interest is there in like reliable signaling for for PIM and its port, the right solution, other things we can do to improve port and so on.

J

Somehow I think we managed to avoid in the last pin revisions the discussion about you know if you do this, you know across the internet or so how about your congestion control right. So we never got into that and I'm not sure how we would fare today. If that would come up, but the obvious answer to those congestion problems.

J

You know when you do reconvergence and if you're really big bursts of things to do, and we know how badly pin works in general and how interval problems are with the buffers port is the right answer, but I think we have a hard time now, elevating it up to really be the recommended solution, as opposed to the you know, all data grandpa right, yeah.

B

Right only I, we can maybe see if there's some improvements or are things we can do to make this work better for PIM. Alright, okay, thanks.

K

Good afternoon, when come now my server from Cisco Systems, so we had presented this draft in I think I ATF back. It was about about back up dr election. So basically, there are a couple of deployments where we are looking for. Having live, live traffic and to select the primary path and secondary paths you could use either or a vector to make sure they are divergent paths. Are there are flex L go? There are so many other procedures to do that. So the question comes: how do you elect backup, dr?

K

So this this drop doesn't propose any new protocol mechanism per se, and so I think I just wanted to go by a problem statement again that if you have failure in the dr, this guy has to detect new dr election. You build the tree and then get the traffic, so maybe for some deployment this might be a problems problem. They don't want any delay in the traffic flow in case of any failures and for those cases for faster convergence. This was the draft we proposed okay, so the solution was having backup.

K

Dr and now question is how do you elect the backup dear, so in this draft I had said that, rather than doing any protocol signaling for backup dr election, you just do the second best, dr as a backup, dr, and send pim, join and keep dropping the traffic at the backup. Dr and finally, when you detect the failure you have to basically move to the new dr. There were a couple of cases and feedback which I had got in last IETF was to make it informational rather than standard, because it doesn't define any new procedure.

K

There are a couple of cases which need to be thought through which, like when new router is coming up. Our priority changes so how we are going to handle that so I have added text in those area, but we are, it would be good to get feedback at.

J

All secretary I hope I'm not contradicting anything I, not remember having said last time, but just because there are no new messages. The behavior on the wire does change right.

F

J

Are sending out the joints or which would to me mean it's actually a protocol extension and it should be just normal standards track. I mean I would rather like to call it hot standby, because there's I think the typical term that.

F

J

Basically use when you base it, you have this backup that you know is immediately ready to do things. Makeup is a little bit unto an specific, but other than that. You know why not simply standard strike I'm. You know what was the argument for it. There is change on the way you two are sending the joint with your otherwise don't. Okay,.

K

I, don't remember what all the argument, but yes I, presented in 102 and that's when I think there was a feedback from the room that it has to be informational. I, don't remember who had made that comment.

L

B

Know some comments sticker yeah, so it does also propose things like you know like using your priorities here of initially, for instance, when you come up and stuff, so it does change the protocol behavior, so I feel like this draft has other important things than just back up the are, for instance, for that just said about whole time of 0. Sorry, the our priorities here of initially so I wonder if the title should be slightly different sure just think about it.

B

I feel like we need some more text explain how this differs from the the dr improvement draft. Okay,.

M

B

Would you use this versus that or so the idea improvement draft, which your improvement? What it does is. It uses some new hello options and it allows you to have kind of like a sticky, dr and sticky PDR when there's changes, which is something that this lesson do. So it's Quebec good to maybe explain that with a few words Jeffery from juniper did.

M

We talk about the merging those two tracts. No, no.

E

We discuss it, I remember we mentioned this in the previous working group, but then you decided that they're, you know worthwhile.

N

M

E

M

Mention each other just so that the.

B

Yeah, yes, actually I was thinking. You know this should mention that they are improvement draft, but we we should think about. Maybe it's worth adding just a little bit of text and we are improvement to to just sort of say how it is different.

B

From this sure we can propose some text in the list and discuss that yeah also yeah I'm reading this draft I felt like it could need some more text still to explain the behavior of the BDR like what what are the benefits so electing a PDR, and how exactly can the PDR take advantage? Show talk about that.

J

Is that improvement draft also support this type of use? Cases meant to do that or.

B

Yeah, so much about the whole time of 0, but at least the whole idea with that too is do you like the PDR and the PDR can do things like do like hot standby, as you said like it's in joints upstream and so on. So.

J

We do have then two competing solutions and yeah.

B

J

So I need to reach two drafts as no two RFC's later on as a user and figure out without having any explicit comparison, which one fits me better by understanding all the protocol details, yeah I'm.

B

J

Yeah I understand as a draft reader. I should do it in the IDF, but is that also what we want? The end user absorbing are sees later on to do.

B

Yes, well is one option would have been to merge them. The other option we are saying now is you know, maybe that two drafts can reference each other and have some brief text explaining you know how is this different.

K

So I think maybe in the list we can get the feedback and then decide. So, in fact, during last presentation the same question was reused: whether we want to have single draft or we want to have both of them, whether it makes sense to have two different kind of solution. I.

J

Mean I completely understand how it's easier to get a lot of small drafts through the ITF, but I mean ask any poor operator how he kind of tries to get through that maze right, I! Think. That's always the issue. Yeah.

E

I think that would be the ideal. An avro I think that you would agree that that would be the ideal, but it's working groups do produce competing RFC's right, I mean that's something that happens.

N

Yeah, yes, I was referred as documents, because I have to read them all, but yes, I think the important thing is is if there are two solutions to this a problem, it needs to be clear why, if it's just that, we have two solutions: a problem and there's no real functional difference or nothing against this raft. But the other draft does other things and addresses this use case yeah. Maybe that's something that working group should consider as well, but in the in the I guess it's case. Where we go with two competing solutions.

N

We need to sort of justify why yeah we're talking about you know, there's implementations and there's appointments of both or something you know. Maybe those are factors that would weigh into policy both as well. So it's not as easy as just saying one thought to members to think: there's other things that need to be considered as well.

O

No requests right well.

K

Then I think there's some more disgusting music.

E

You'll take it.

E

Yeah, okay, so, while we're packing things, why not? Pack a certs as well it'd be interesting to get your opinions on this? Whether this is a something that would be a good idea or if it's crap but we'd like to just get your opinions on this and the goal is to be kind of forward-thinking. You know it would be potentially helpful to reduce the sending and receiving of a certain messages. The pressure of that in maybe some.

E

You know that it's probably not really an issue today, but you know maybe in some future deployments, whether it's TSN kind of networks. There may be a benefit of doing this, we'll see. So let me just explain it and then get your opinions, so we didn't cleat include some use cases that describe where this could be helpful and again. We admittedly need to develop these use cases more, especially ones that are maybe a future related.

E

But if we want him to scale well into the future, then we should be able to work on these kind of things. If we, you just want to push people towards beer and other things, then we won't alright. So the problem that most of us are likely aware of is just the certain mechanism. If you do have a lot of sources and groups, there could be times where there could be, in short, bursts a lot of assert messaging, that's happening, and there could be a large processing load on the routers.

E

So we aren't proposing any changes to the PIM state machine where we are proposing a new pin, hello option extension for assert packing and being able to know she can negotiate that packing capability and then we're considering two types of solutions. One is a simple packing solution: one a little bit more involved aggregating packing solution.

E

If this is something that we pursue, so the proposed PIM hello option extension format is a new option type and then a packing type, whether it's simple or aggregated. So again, the new defined hello option is used to negotiate the assert packing capability and we will have a packing type of one for the simple packing type and a packing type of two for aggregating.

B

Steiger ever question, so if you support aggregating the type to aggregating them, do them implicitly also support check one more I.

E

Don't know because.

B

If you, if you support both, you announce one or two, and what, if you know someone else, one and some announced you take.

E

A question yeah: we were assuming that they were discreet, but we need to make that clear in the draft. That's a good! That's a very good point! Stig, okay, yeah! Think about that one, some more so in the simple packing solution, you're, simply taking the existing assert packet and inserting that into a new assert packet. That's grouping all these inserts together. The original assert message bodies is used as the record, making carry multiple assert records and then identify the number of Records.

E

So the advantages is that it's a simple extension that disadvantage is that when you oftentimes have a small number of sources and groups, there could be a large number of records with the same metric preferences and stuff. So it kind of wastes the the payload or the transmit has transmitted message, but it is a simple way to go about doing it, and this is what the simple packet format would look like just putting in those each asset record into the new packet.

E

You could separately have a little bit more or a lot more involved, aggregating packet solution where you could combine the records rated to the same source or RP address in in the assert message. So in the case of like a cert record, one you could have the source address and all the groups that use that same address, packed into that particular record.

E

You have another record which has based upon the RP address grouping the groups according to the RP address, and then subsequently, each group record having the sources that use that particular group more involved, not sure what hit that would have on the processing. But again it's less messages that on the wire that the routers have to process, it adds more complexity, but the advantages you're also optimizing. The payload of the transmitted message by merging the same filled content.

E

So I believe this is the last slide. This again, just kind of takes a look at the pen, assert packing format on the left upper left and then each star, comma G, assert record format with the you know, with the rpe address, and then all the different group records the bottom left. You have a s, comma G, assert record and all the groups that use those same address same source address, and then each group format would be as as follows.

J

So yeah comments, yeah Toula Tosa is a co-author, so it didn't have you know really a lot of cycles spent on trying to see all the details, or so my main interest was really the problems that we had heard over the years and so in business. Critical environments, like you know, in the finance sector, or what we had to do to deal with assert problems or is ready to tell them. You can't have a transit land with multiple downstream in multiple app streams you need to create.

J

You know, point-to-point lands, and you know when your whole business depends on it. You can basically go through the trouble of changing your network, but since then you know and ten years passed and now we have a lot more interesting layer, two technologies that actually you know you can buy. Metro Ethernet lands right. If you buy a single Metro Ethernet line, that's a different price point than buying a lot more point-to-point, matauri that land putting another Q&Q on top of it is another problem: space death net.

J

You may get qsr in these lands right so having the expectation that you don't have any transit layer, two lands, just because of multicast I think is- is a risky proposition for us right. It's like in the Wi-Fi case, maybe kicking us as multicast more and more out of the picture right now. Obviously, the proof of the pudding would be to figure out if you know and I think that applies to the other packing drafts as well.

J

Could there be any performance numbers right, so I'm, prototyping or so that would really be I think very helpful to persuade right, but obviously it should be better. How much better we don't know, and it's it's an important problem, especially because also in port, we we have no replacement for for the multicast deserts. So this thing is going here. The assert problem is going here to stay.

J

Whenever you have multiple down streams and at least you know two redundant up streams, and so we should continue to be right because in big deployments we have big issues. Thank.

M

You so if a sir, it's becoming a scanning concern, I wonder if there are other ways to solve that problem without using p2p beings, for example, you already learned you already know who else is sending what kind of joins? If you, if you remember that information you, maybe when you choose your own upstream router, you can consider who, who else yes asking for that something I.

J

Mean that that came up over and over again I was always suggesting what I called strong RPF check, which is your RPF against the sending MAC address, and people were never kind of. You know daring to to break that layer. The separation right, I think the guy back. There is already starting to laugh out loud. So, yes, I think there are a better solution. No I, don't think we could get them through the idea.

J

E

That was truly speaking and it's Jeffrey speaking again for the people on video. Another common is that now.

M

If you are start packing, how long do you wait before yours you send out, and since these this is for a certain, your your having duplicate packets, going young? How how fast? How quickly do you want to send out your SMS you so that you can quickly stop the duplication.

E

Yeah great questions we don't we are, we are proposing any changes to the search state machine, so that would all be the same as it would be today.

M

Mission change a meeting at the timings, because, when you are, you know compacting. That means you know you're waiting for certain point. Certain times before you send out your pack pack, packets, right, that's yeah,.

J

Yeah, okay, typically, the way you do it is that you basically you know as long as you don't have to wait. So you can read non-blocking further assert notification, your control plane, that's when you basically take them and as soon as you, basically, your packet is folder. You send them out. That's no additional delay right. That's there's! No waiting for additional notification.

K

Mancom no Cisco I think actually Jeffrey asked my question. I just wanted to know that. How are we going to implement it? How long you are going to wait when, when to send the update, whether we will create lists only for the subsequent asserts, and we will send the new one right away, how it is going to happen.

E

Okay, those are things we have not included in the draft. Thank you. Well, we should do that. Misty.

I

Know yeah. Those last two points are critically important in terms of implementation, because why do you send an assert because a packet came on an outgoing interface? That means at that point in time, there's only one s, comma G, you know, and if you want to aggregate that means you need to collect all subsequent ask emojis that are going to come on this output. It interface, and if you wait then Jeffrey's point is true that you're gonna be sending its while you're waiting on the previous ones.

I

So it's really hard to implement right now, but so the other question I had is this: why do certs happen so much in sparse mode? You send joins one way versus the other. You know so.

J

Oh, are you worried.

I

About the RPF caves and a join to a new path and then the prune gets lost and then you have the double forwarding on a multi excess. So if you want to solve it for den smoke because the search happened more often there that's fine, but was that a motivation.

E

That wasn't, we were just thinking of sparse mode, just just sparse or.

I

Sparse mode yeah in the transient case of joins, because you know a downstream router sends to join one way in a multi access network to one that neighbor. The only time I could think you get certs is when there's an RPF changed. You join this way and you didn't prove that way, which you should the spec says you should, but if the previous, then that you have two routers that are forwarding on the multi-axis LAN and that's when the cert would happen, but that doesn't happen very often. No.

E

It doesn't happen that often.

I

E

We do we do talk about that in the draft that bit it's just that there could be those small bursts of times where there could be a lot in a short burst of time. It could be a lot of asserts happening if there's a lot of yes, okay,.

I

So you're, what you're saying is in that transient case, there's a burst of asserts for a bunch of different Eskimo Gees that may have been affected by the prefix for the RPS.

F

I

And then how long do you think you should wait.

E

I

B

May have some comments on the.

I

Comments, if you, if you wait for the timeout period, it's just going to clear itself out because the routers just gonna prune, but that's gonna, be three minutes and that's like infinity right. If you wait one second, then you yeah it just this doesn't seem to I. Think it's going to be hard to do the implementation based on what these two guys said, and it doesn't seem like it's worth it. For the very rare case. It's a lot of effort in machinery put in for a rare case.

I

You believe it's a rare case or or you think it's going to happen. Yeah.

E

I

E

May happen more I, don't know I'm gonna.

B

Jump into the queue at some point in.

P

There, along the same lines, why we're asserts put in there. It was because of this idea that we would have trained it lands for multicast exchanges, where one provider would pick this neighbor and another provider would pick a different neighbor I.

P

Don't know that we're gonna have multicast exchanges anytime soon and I think that use case may have evaporated, so so maybe I think Dino's along the same like on the right lines of the thing that we thought a cert would do, is probably irrelevant these days and moot what is it yeah for sparsh mode and certainly for dense mode? If there's anything more mooted, it would be dense mode, so I think it's worth looking at all right. What does a cert do now because the search do happen and is it just those transient?

P

Are you know transient reconvergence, or is it something's broken, or does it not happen that much because, usually what is you know? What's your typical transit land, it's going to be a you know, a whatever a pimsy with multiple pease who have connectivity to the source, but you know again are these? Are cert I've seen a search happen recently, but why are they happening? Is it because something's misconfigured?

P

Is it because there's transient reconvergence issues, certainly I have a tough time, believing that it's happening for the reasons we thought the cert was going to be used originally so I think that be looking at something's broken here. Somebody misconfigured something yeah or you know somebody somebody poorly designed something. It shouldn't happen that.

E

Was Lenny from juniper speaking by the way and turn this is crawling out of his skin, to say something so.

J

First of all, in this thing in burundi working group we finished last year a BCP about inter-domain, so there is basically section about exactly that absurd problem in exchanges, and you can't build these exchanges with a layer tool and because it would get persistence cert. So this is not the use case right. This is the broken stuff. This is what we would need strong, RPF check.

J

This is really, in my opinion, for layer, two transit lands in normal enterprise networks, which may use Metro, which may use that net, which may use layer two subnets, because a transit instead of point-to-point. For all the reasons that you know layer, two Ethernet has improved over the 10 years and is very attractive, except for the assert stuff right, and we have seen in the past. As I said exactly in these networks in finance, they were using layer, 2 transit network. They had humongous refreshes right.

J

There is one improvement in the latest version of PIM, which is basically proactive, asserts, oh just because you're, basically having not exactly the same type of conversion, speed of your 10 downstream routers to your to upstream routers. When you have RPF change all right, so when these two are conflicting with each other, both of them are sending and you get the earth pretty much for all the state leave. Certs is a standard mechanism.

J

Yeah the prunes and joints are overlapping and basically the latest version of PMS try to improve that, and obviously one of the important things is to figure out how to implement it. For the two cases one is the data trigger the third one, the other one is a lot easier, which is the preventive asserts and for the data triggered it asserts. I, don't really see the issue right. You have a queue of event: notification.

J

No, no I mean you, you basically get your assert, which are data, triggered events. There is a queue of that and basically you're simply whenever there is the first message in that queue. You look through the queue if the queue has more than one element, you're, just everything, that's in the queue that fits into one assert packet, you're, collecting and sending out I, don't see the problem. Sorry.

A

F

C

Want a support tool is here on this. First, you.

F

See I always say Isis.

C

So I would think you know we want to make modifications to a search, it's better to get rid of them completely. They said of move on to make it better so up there SEC, based on MAC, address or some other things, I think. Maybe that's where we should spend our time.

C

B

This stay gonna make some comments too. So I think one common case forget asserts is last hop. Very you know. One router is the DR, but also another router is receiving a pin joints.

B

If you wish, and both a transit land and the last topically, if they're receivers, then you will get the certs and often a source can be kind of transient situations, but once you get an assert, you end up listening and starts forever as long as your Eskimo G state and for those pre Ola concerts, I, think this graph is useful so base that this.

I

Deena, based on what tourists said about just make more than layer two topologies point to point: does that mean there's multiple, there's multiple replications on that land? Because that's a that's a disadvantage! You want. You want to take advantage of multi access lands because you want the replication to be done by the media, not by the router.

J

Well so I mean read the BCP about. You know the case of an exchange point where every downstream has different opinions who his upstream is, and he wouldn't like to get his multicast from a different upstream right. So that's that case.

Q

Q

J

So that's cases out of bounds right, that's what I was trying to say to Lenny and I think we should basically talk have a sentence about that. That's clear! So, yes, within a network where a single network operator wants to do the policies, obviously we should do the replication, but the whole point of strong RPF check is instead of very quickly for the transient case to try to resolve the duplicates and get rid of them rather have a little bit more duplicates in the transient state and not do all the signaling.

I

Ice is saying: is you turn off a search on that land altogether and everybody who is switching over to joins I know they do them in a different time, so some are still joining here until they get the RPF inside, but eventually they're all going to switch over and there's gonna be a shitload of prunes. That are you going this way? So even if it's a it's a congested network, one of those prunes are going to get through and that's gonna cause that guy to remove the ayat.

I

Oh I am so so I think just get rid of these I think you're, not how about having a neighbor option to say we don't do a search, but.

J

That's I think what what what we say it right. So the better option is strong RPF check the way that the term we phrase in the back. Well, that basically means both. Both up streams are, for you know, half a seconds are sending, but when I'm sending my join I'm, putting in my RPF to say not only from this interface but from the following, sending MAC address and that way I will not forward.

J

That's the whole point. You want to avoid that during the switch over you're forwarding duplicates and the asserts are all meant to avoid duplicates as quickly as possible. Yeah. That's exactly why you know this is the better best solution in my opinion, but we are not doing it. No, we haven't, we haven't done it I! Think! huh Yes, yes, that's why.

F

Examine the products.

J

That's why I've given up on it? You know we've done it in MPLS, obviously right, but you don't want to hear about MPLS right. You know ml DP, yes, so the answer, of course, is a MPLS right, but if you don't want it, sorry that you know there's a cost for it either you try to optimize the assert or you come up with another complex state machinery that everybody agrees, and you know you make a downstream elector for everything like in OSPF or.

C

This is ice, but ice now yeah, so I wasn't suggesting to stop using a search. Well, yeah, sometimes it's but but I do want I think you need to strung up. Your check has to let's say that stronger artistic means that downstream does not just art, be up against the interface, but something more now I think we can be mac address. You can use ambulance labels or maybe even feeling, there's something something to tune. Make your land into a virtual point. Multiple.

E

But it's it's! This is being recorded. You guys get to go to the mic. Youtube just.

I

Remove the assert allow duplicates for a very short period of time and everybody's roughly good if you're running OSPF or any I GP everybody's, roughly gonna converge at the same time enjoying the same way so I think the amount of time that there's duplicates being sent is going to be minimized. That's the trade-off from sending a hell of a lot of asserts or waiting waiting to aggregate them was just still gonna send duplicates so well.

J

The tone ii again that the the problem with duplicates is that we have a lot of networks and in video applications or so where duplicates because they're causing link congestion are a lot worse than you know, missing packets right so and we're not getting missing packets because the switch over actually is fairly flawless in the way that we have it. It just creates duplicates so.

Q

J

No I mean with with with the way we're working.

J

I'm saying if we had the strong RPF check, we would have you know pretty flawless failover right. So that's.

Q

J

But I mean then then that's fine, which is basically why I've kind of you know said it's super consulate, vendors, the next after this from RPF check. So that's the question: how cheap can it be made these days right and otherwise here is a software only implementation that optimizes the asserts you're saying get rid of the asserts and accept duplicates I, don't think so.

R

B

Are corner cases reimagine of the duplicates permanently, though, like one example is, as I was saying, if you have transatlantic, that's also a last hop if the dr is forwarding and another router is sending a pin joint across that land to receive the traffic. No, you might.

I

C

Think it's that easy plugin, so I think there's letting do please go to is quite dangerous because she can have ten thousand states right converging, so it takes a while for pin to converge right. So the first boom you got in okay people cough kills but number 10,000. There's a lot of duplicates going down.

I

Don't forget when there's a unicast, RPF change, it's affecting a lot of s, comma G's and the joins are gonna happen and they're gonna be aggregated and grouped. The prunes are going to get rid of a lot at one time, because we already have an aggregated solution to call during prune messages right.

I

It's just not one. Eskimo G, like the assert, has just one s: comma G, yeah,.

P

Lenna Giuliana juniper, so it seems like the choices are fix or replace asserts, which Dino's suggesting is really expensive, nobody's ever going to do it. The alternative is, don't bother, doing asserts because and just live with duplicates because it shouldn't be a persistent duplicate case. It's duplicates should be quite rare and assert just shortens the amount of duplicates that you're getting it doesn't eliminate it and then the what you're suggesting is, let's optimize asserts.

P

The idea of let's eliminate asserts only makes sense if you're not going to build, asserts in the first place, but once you've already implemented, asserts and asserts. Are there you might as well keep them it's not like somebody's gonna go back in and say. Let me turn off my asserts now.

P

Perhaps there's a processing cost, or maybe there isn't- and maybe the point of this was just to enhance the process, but the process is a rare and unlikely and not worth enhance about process. I, guess that's what it comes down to is so, yes, it makes it. It would make sense if you are gonna build an implementation to start like if you're going to implement PIM for the first time. Let's not bother building this assert thing because I think it's obsolete. We don't really need it anymore.

P

We'll just live with these duplicates and you know it's a canary in the coal mine anyway, and you know you're broken anyhow. If it's happening, if or you say, this is a problem just for transit transient cases, in which case we're reducing it from a short amount of time to a shorter amount of time. Or you know, that's, oh I, think I, don't know what I think, but that's what.

E

P

Just what I would say is I'm not sure it's worth optimizing, I'm, not sure it's worth fixing I'm, not sure it's it's worth, eliminating I, guess I'm saying maybe if we just stick with what we got put our hands up in the air and say yeah yeah.

B

I think you have to stop pretty soon. That's like kids, good summary I.

J

Mean we had nationwide TPT right, which is basically these wonderful sub, 50, millisecond layer, two rings which were basically carrying all TV programs of the bloody country, and you know when you had a switchover between the two app streams and you had 50 down streams right, you do get bloody asserts and you have duplicate traffic. You know to all the receivers right. That is not a good service thinking.

E

We're gonna be done. There appreciate those comments, those are very helpful. Us authors will powwow and if anybody's interested in joining us in this, please do and we'll decide whether we want to pursue it or not. Thank you. Yeah.

B

And if anyone wants to write some new drafts of proposals on how to do a source, different your improve them or avoid them, whatever I mean you're you're welcome it's a good discussion and.

B

You're bringing up a starts to be excite people and cause some discussion.

S

Thank you, so my meatball, you know Kia. So first I'd like to thank the chairs for allowing us to present this here. I think this is a new multicast concept and it is being the PIM group. It would be nice for everybody to hear about it. It's a concept that we are working with: Bell Canada and our Cisco colleagues, and basically what it is. It's a segmented routing policy for point-to-multipoint.

S

So the basic idea behind this concept is that, as probably you guys know going forward, there has been some changes on the unicast on some simplification. This segmented routing the removal of an LD. They remove up removal of MPLS protocols like LD, P, rsvp-te.

S

Everything is being advertised with underlay IGP overlay BGP, and then you have the PCE, which really calculates the traffic engineering and any updates to the to the path of a LSP throughout the domain. So those simplification of course starts trickling into the multicast domain as well, and this is the main idea behind this new console. So, basically, what it is, it's it's a segment routing policy, its instantiate it on a PCE from a route to a set of leaves and it gets downloaded from the PCE.

S

We had different type of technologies which I'll go through it later on, but it's Pisa, whether it's BGP, srte, etc, etc. The PCE will download the tree to the nodes or the PC sees, and then the traffic will flow throughout that point-to-multipoint tunnel. What are the point-to-multipoint tunneled is the Kimsey or whatever it's sitting in the IGP, and certain SG like IGMP team joins will join, will actually go through that tunnel.

S

Beside the point, it's going to be like a MPLS tunnel on the data path that is instantiated via the PC, so I think I kind of explained this, but again the SRA application is a point-to-multipoint segment and if you guys are familiar with segment routing, a segment is presented via a label. Hence the MPLS part of this in the future. We might extend it as our v6, but as of now it's MPLS, so you will configure the data path on the nodes we are MPLS.

S

There is going to be push actions, there is going to be swapping actions on the data path and there are two type of replication seconds. There is a spray. Basically, what that spray is, is ingress, replication, meaning that you try to create your tree via point-to-point segment, routing tunnels, and then there is a tree see a tree. Seed is more like a tree, obviously, by the name and what it means is: there's going to be a route. There's gonna, be a replication points and there's going to be a leaf.

S

The entire biggest point here is the tree itself is a single segment, so it's gonna be presented. We are a single MPLS path and a single label astac how that label a stack gonna be if it's gonna have extra pushes on it comes on the PC which I'm going to explain later on, or you could have and label a stack with multiple labels on it. When you try to do fast reroute, when your route is resolved via point-to-point segment routing tunnel, then you can start stacking labels.

S

But as of now that receipt is a single segment, so the entire idea will take the spring segment routing policy to the next step. So we are actually using that policy to to create the point in multi-point segments and it's really identified via our route and we are a set of transit nodes and the leaf nodes. You can do traffic engineering, there could be constraints, colors, etc and all those are done on the PC.

S

So, basically, from the PCC point of view or north point of view, we will send the update to the PC saying that this is the route here are set of the Leafs on the next slide. You will see that and this point multi point three is identified throughout the network. We are the root node IP address, loopback, whatever it is, and a tree ID, which is unique on that root node.

S

So here's an example of it. Basically, these three was in Senshi ated. We are a single root and two Leafs, and then the PCE was able to calculate the path throughout the network. So in this case you can see that the PCE programs, so maybe I, should take a step back how it was in Senshi. Ated on the root in this case could have been via two mechanism. You could have gone on the controller and you could have said that here is my root.

S

Statically configure it and here are my leaves and then the PCE will actually figure out the path from the root to the leaf figuring out. What are replication notes or another way to do that is. You could have used the next generation and VPN procedures with BGP, where you can discover your Leafs via an VPN procedures on the route.

S

You will discover all the Leafs via those procedure and the routes update the controller with all that information and that's how the controller will know where the route is and where the Leafs is either way it doesn't matter. The fact remains that the controller needs to understand a single route and multiple leaves to build that tree. So in this case, when the controller was really trying to build the tree, it realizes as an example from n1 to entry. There is a ijp shirkuh, the example here. So what it does it actually built?

S

A label stack with that IGP shortcut on top of the tree see and we were gonna, have multiple label stacks or, with the same token it between n 3 and n 5. In this example, there were two links: entry could have created a fast reroute, protecting the previous link and that fast reroute were it will be. Programs from the PC to the node will have another label. Is that so you could actually do label a stack in video. It was mechanisms from the node to the PCE.

S

You could create a tree, you could delete a tree and you can update a tree based on these procedures. Pce will recalculate the tree. If there is some optimization, the PC can do make before break so from redundancy resiliency point of view. You're gonna have redundancy and resiliency on the node itself, which is fast reroute and you can recover the tree within minimum amount of time.

S

But after that, like any other MPLS protocol out there rsvp-te point-to-multipoint, RS 50, you could optimize the tree and redownload the tree to the to the PCCs or the nodes and do a make before break whether that's local, optimization, whether its global 3, optimization and you'll, make before break to switch to a new optimized tree.

S

So, with the same token, there will be a couple of more drafts coming up, as I mentioned, we try to keep this concept very simple. The PC is the brain of the concept. The PC is the one that calculates the entire tree as of now. Igp is not involved in calculating the tree, except the fact that the linker states are sucked up to the PCE. There is gonna be a PCE draft which the SR policies are going to be defined.

S

They are gonna, be based on like extra objects based on the current SR policy, there's going to be an VPN draft and the SR v6, 3, C or fully bill comes in, but this.

I

Is Dina a question on the PC? Ok, compute, reverse paths as well. There's no reason why I couldn't remember.

S

Because the the PC, he really has the entire state of the network right so.

I

Assign, if it's RPF or okay and a suggestion spray, it might be good to have another term a different term, because people rather than introducing new terms people are going to say. Is it like this or is like that?

I

Maybe you should call it head end replication, because that's what it is I mean it's henan replication of using regular segment routes and for Teresa that is probably as good as any other thing I mean replicating said or whatever, but um but it just spray and also spray gets scary, because it looks like it's broadcast right actually,.

S

That's a good point. Thank you very much appreciate.

M

There are indeed looks some discussions and, on the terms, I also agreed that could be renamed for something else, but ahead Andrea and replication versus ingress replication. The ingress replication is a is established name, yes, this in some context.

I

Yeah, the other reason I wanted to rename and I forgot to bring up. The point is your: what you're really doing is you're replicating on the route? Some people call that ingress replication other people's call, it egress that's another source of confusion.

S

Any other comments, questions so I'm not gonna, go through that last slide. I think this is going to be part of this spring from adaptation point of view, but thank you for your time.

J

Who already saw this in M Bundy?

J

Okay, not too bad okay? So this is an an update report of the work that started out something around ITF 102 about. How can we update the status of our AGM P and M LV RFC's, with a particular fun data? Point that if you're looking for the best standardized, full internet standard receiver, signal protocol, use IGMP version, one nets and full internet standard? So obviously that's not what you want to do, but everything newer has just you know, draft or proposed standard, and so we wanted to change that.

J

And so then we started to understand that we need to steal the process we did with him, which is basically trying to vet the industry operationally and implementation wise what's out there for the newer ones, and once we have that understanding. Hopefully, then Alvaro tells us the next steps on how we can basically update the status of the documents, and maybe we need to fix the documents, but so right now we're at this questionnaire estate and so around ITF 103. We formed a mailing list.

J

Any group of people that started to work out that questionnaire, so there were a couple of really good meetings where we had all these people here, which are also now on the draft come together and work out the questionnaire it's.

B

Just a comment: I'm not sure if it's in there, but the mailing list is archived and everything is public. So you can go and see it. There, oh yeah, and this was a wiki and some stuff right. Yeah, wiki, really um yeah. If you go to the pimiki, there's a link to pin wiki.

J

Oh yeah I looked on the inbound e wiki, a okay I'm confused right.

J

So so the plan would be to finalize this with basically the feedback. We got some feedback in EMBO Andy.

J

Hopefully we're getting feedback here as well, and please, if you can bring it up on the list, ideally so that we're not losing it through the minutes and once that's done, the plan is described in the draft is to have the working people working chairs, but maybe hopefully, also anybody else who has an idea, try to start circulating with a request for feedback that questionnaire to you know, vendors and operators, so I mean the obvious one is in a two mailing list right, there's internet, whom multicast, hopefully will remember all similar mailing lists in other parts of the world or you know specifically address and send it to operators that we know in the ITF right just sending it to pay more in bond.

J

You will not have as much an effect as sending it out to the individual operators. We all know here and then the process would be to designate a trusted party that collects the feedback and anonymizes it, and so the proposal here was Tim, Joan, I. Guess that's something to finalize by the working of chairs and put in the final question. Yeah.

B

Yeah so Tim Chum did this for him. Sparse mode and I have briefly talked to him and I.

D

B

It's okay doing it. That would be necessary. One thing, though, I see you know like we discussed and then BOOM do you draft them here? We.

J

Have on this slide is still sorry. I was totally back Gloria.

B

J

Slide is corrected so yeah.

B

So there is, there is a draft that we, you know need to consider later. Maybe we should adopt it or not, but I guess it.

J

Doesn't really matter that much right if we want to just in on data tracker, you know finalize it for eternity we can as well adopt it once we're done with everything so that it gets posted, but I mean having in RFC. Isn't you know much different from being able to send around the draft yeah.

B

So we can discuss that later.

J

Here, do we need.

B

To Mindless, hopefully we're getting that done before.

J

105 right so that we get through the process and then the story continues from there on. So can you click there? I can't click click.

O

J

B

This has shown to work. Can you maybe get out of full screen because it may have.

J

Right yeah, it did work um yeah, so we skip the ITF yada yada. Then there the introduction is kind of for the target audience the yada yada. Why we're doing this I think we explained this and then basically we're starting here with the intended audience and we've basically cut the questions were replicated then, and it slightly made them different between operators and vendors. So, let's go down. Obviously you know here. The first one is for implementers.

J

A lot of the questions are duplicated, but we wanted to make sure that people don't get confused, and so we duplicated between operators, members. So here's the implementation status, questions right, IGMP, v1, v2, v3, also very important, IGMP v3 lights, so one of the interesting outcomes, obviously in the end would be. Can we identify from the feedback enough justification whether to make IGMP v3 light or full IGMP v3? The final best recommended standard same thing for ml DB, 1 ml, DB 2? So and then it goes go further down.

J

So these are a little bit open-ended question because we felt a little bit that overwhelming customers with details would be too much in EM Bondi. We got the feedback that we may want to give an example list of features just as hints and I think that's one of the things we're going to do then very similar, go down to a3 implementation perspective questionnaire. That's your right! So this is also yeah. It would be lovely to to get feedback on on this implementation perspective.

J

That's also a little bit open-ended because we're trying to really compress the thing and not come up with a lot of detailed questions, but obviously that is always difficult to do then going down 3-2 deployment stages. So this is, you can go down faster here, all right, so you saw this was copy and paste and.

L

J

The operators deployment specifics are very similar. Just you know, are they deployed and yeah? Also the type of open-ended questions so yeah? We would love to get any further insight and also within the team are going to go back and revisit the latest state here. The the the one other feedback which I found to be helpful from Mikkel Abramson, was the bitching about the problem that in IPTV deployments he wanted to have SSM and then, ultimately, he got the answer.

J

Yeah we're doing IGMP v3, which just meant the setup box operating system supported IGMP v3, but the application was just sending an IG MP group membership report, so the application effectively didn't use as the same so and my proposal was that we do add a section, their application and asking basically, if applications that should use you know, SSM are not using SSM or something like that.

J

It's clearly somewhat outside of the original scope, which was just for PIM to understand the status of of the RFC's that we should get, because this would be an application question, but I think for us in Ambon Dee, and also trying to figure out how to deal with this problem that you know, IGMP v3 support by the OS is not good enough. The application also needs to do SSM how we can basically in the future.

J

Try to you know highlight that that as an issue better, so that was that there was a suggestion to add a section on that with you know, one or two very simple questions and yeah go to the end. I think that was pretty much it yep, please read and who has read it here, good, who has already posted comments.

J

Please post some comments to it on the mailing list right, so so that that we, you know, get really that insight and yeah any questions here.

B

One question that was raised is how do we reach out to the people that need to respond to this? So there's like vendors that go to the ITF, but it might be like hosts tech vendors that are not here at the ITF. Of course, this feels like nano go right pointer to your you know, communities I mean.

J

There are a lot of people that you know have connections to do to these folks, I mean we can try to figure out when we are at that point, or we can split it up so that the poor folks that say from Microsoft or from Google or a Linux folks, don't get overloaded, but I think we can. We can come up with some good listened. Have multiple of us divide that up yeah.

D

Toom winners from the UNH I. Well, you know we have a lot of people who do testing for MLD and IGMP at our lab. In particular, we do have a lot of MLD because of the US government test profile. We'd, obviously send this to all of those posts and random vendors to try to get them to respond. Excellent.

B

T

B

Have to look into the smell of.

T

B

B

A

B

She's British, to be honest, you program vacations. You.

O

B

Yeah I haven't seen.

Q

B

Explaining a few items first, first level versus charity. The second was pretty strict as well.