Internet Engineering Task Force 99, 18 Jul 2017

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF99-MBONED_PIM-20170718-0930

Description

MBONED PIM meeting session at IETF99
2017/07/18 0930

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

A

A London call that catfight warlock that wasn't there he slammed his head against on the hitch until I could cut it Justin to people going down. Ten you see, Kevin is just bring food to grab this video I'm clock to see so I can throw this over loading. Capsule event looks like you look at the video you by yourself and.

A

So what I love to win.

A

A

You can't test for genetic.

B

A

No, not that a white option, but he was wondering.

A

C

Did one minute ago.

A

So, like last Sunday's you don't we got to get to work groups, they never got one cheaper to stand. Modi.

A

C

That is their thought. They were gonna have a laptop for the main one. This laptop is just for that.

D

C

You send me new ones.

C

Is the projector on.

A

C

Hey Greg, can you rally it for a meeting cake er while I get these last sets of a note-taker.

A

C

Alright, okay, one last thing: we need to put up.

E

A

Everything right.

C

Yeah one of those.

F

A

You have anybody on you see right there and was there is.

G

It up there and no.

F

One guy we gotta be able to take it right here, I, just kind of greater yeah.

B

All right I'll do that.

C

Radium size idea: I'm uploading, the Tim, slides Tim.

D

Just give me the.

A

Silver beer: we.

C

Did not talk about the working group- beer, okay, all right, I! Guess we can commence.

F

Welcome to n low, indeed welcome to Prague.

C

C

All right we'll get started, this is M Bundy and we will be followed by PIM.

C

Let's see, please note the note note. Well the note well, this is the newest, the newest note well fresh off the presses.

C

And here's the agenda so first we're gonna, go through working group items with the chairs, Tim and Michael are going to talk about the multicast models draft they have to get going shortly, so we're gonna bring them up very quickly.

C

Toshi is gonna, give us the latest in the EM track. Em tres draft and hackathon update from jake and mike may be talking as well about the Wi-Fi draft. That's a late addition to the agenda. Anybody comments, Genda bash anything.

C

No, he all right, so uh active working group drafts the em trade stock went working group last call last year. Stig gave some great comments. The draft was revved based on the comments so fun and we have Regan another working group last call as a result of the changes to the dock.

C

We would like to have more folks comment on this more than one comment, at least to say you support it or don't support it. It's it's been around. Let's it's ready, but please comment on list what your thoughts are on that draft the peering vcp Tim thank thank is is the shepherd and he finished the right up. There were several knits and textual issues.

C

Percy has just updated that and has sent that off, and so that should be going very quickly. No, not yet that was Percy yesterday ended up changing it, so I guess Tim. All that's needed is take the new in and tweak your write-up, and so that can be fired off.

H

When it's in the queue, if there's knits around for comments from the ietf large.

A

H

Remanent, it stays and the cute doesn't go back to the working.

A

H

That's just normal.

D

You found are just running through the tool.

C

Alright other drafts, the multi has models info. No, actually, no, that's the yang models, and- and there is the multi cast models which Tim is going to talk about right right now. Actually, after he signs the blue sheet, so Tim you can come on up we're ready for you.

C

There never is, but.

I

C

Do sign the blue sheets.

I

Okay, so I'm just going to talk about this draft that we last discussed in Berlin, which I think was three meetings ago. The initial focus of it next slide was to document at a high-level multicast service models, discuss use cases in a couple of deployment.

I

Examples with the general idea as part of the message or key part of the message would be to recommend the use of SSM wherever possible, so he got some reasonably positive feedback at ITF ninety-six about the need to recommend SSM or promote SSM, but to also strip back on a lot of the other text in the document, things being things that documents being part and Miquelon I haven't updated it for a year, but we've now got some further vigor to have another go at it.

I

So next slide and I think what we really want to focus on. What the message was in Berlin was that we could do with a up-to-date, modern recent draft that promotes the use of SSM and advocates the use of SSM and Gabe's current up-to-date thinking as to why that's the case. So you talk about a lot in the working group, but there's no document that explicitly says that some quite old documents, but nothing recent.

I

So that's the proposal so ruvi we focus on case for SSM and to give an appropriate new title to the document rather than whatever it is at the moment. So hopefully that's not too contentious. However, there is.

I

You've thrown me off completely now by its new Voter.

J

I

K

That's not too contentious.

I

I

So hopefully, some of you at the back, if you can't read it, come to the front Lenny got in touch with Michael and I and Lenny's a co-author on this as well, and so hey I've, just seen this email on the internet, too multicast working group lists there's half a dozen emails, though there appeared in the last month or so the interesting bit of, which is that they're reviewing their.

I

How they're, deploying with the new backbone and what they'd like to do is to say we don't really need a SM anymore on the backbone we'd like to get rid of MSD PA and all the complexities of running ASM interdomain on the backbone. So there's a proposal there in that group that they essentially deprecated the use of ASM interdomain so I think that's something that we could consider. Also making a statement about in this working group and I think Lenny had it as part of the discussion on that thread. You can see the link there.

I

He was saying. Well, we can discuss this in the ITF and see what we wanted to say about that within the ITF. So hence I think this document, in addition to promoting SSN, could perhaps, if we choose to say a little bit about say, killing off but making it clear that we don't think as well. That ASM is a something we should be doing at least inter-domain next slide.

I

So the question is: do we want to take IETF action here? Is there something that we want to say so he gets the end of the slide. Stick before comments, you can just lurk being employed by Cisco to develop a multicast. You probably don't want multicast deprecated yeah. So do we want to take ITIF action? They do we want to write something up along these lines and if so, if we are deprecating SM, is it just the inter domain? Okay, so probably what we would say, but how would we express that?

I

What language would we use? How what would we do? Could we make up I mean MSD peers or only ever been experimental? Do you want to make that historic, but then it's got use within a domain as well. So that's not clear. Certainly, what David farmer, who wrote the email to the internet to list his drive? It was simply to make multicast simpler to operate on the Internet backbone and that's something that goodbye view in the UK and the Janet Network, which is the equivalent of the Internet to network in the States.

I

There's something I would certainly sympathize with, but then what about use of ASO on a campus we should probably- or should we just be saying whatever you do within your own domain? That's up to you but inter-domain. Perhaps we should be looking to make things simpler and just say: inter-domain is SSM and, as the chairs have just said, we've also just about to push the is G a document. That's BCP on how you do inter domain SSM, so that kind of fits quite well as well so yeah.

I

We can make our draft essentially a BCP status document promoting SSM. We can note the wording in some of the older documents that give the good reasons for using SSM, but also, we probably want to think about appropriate guidance for applications if you're writing an application to make it an SSL map application rather than an ASM one and all the associated things like how you would do source discovery, for example, next I think, there's cuff just a couple more sides.

I

So the other thing is here: if we're going to make some kind of don't use ASM into the main statement for v4. What are we gonna do about v6 it's one of the people involved with stigand Peko in the creation of embedded RP in the six net project, if it's shame to sort of throw the baby out so to speak, but I think we have to be fair. If we're going to say, don't do inter-domain ASM for v4, we should probably say the same for v6, even if it's relatively simpler to deploy.

I

So we could make the embedded RP RSC historic or we could just simply use some language that says it's not recommended in uppercase. We need to decide how we're going to express it there's also in by dear. We need to decide whether we're going to say anything about that promote it, or we need to think about what we're going to say, because it is an important thing. They also need to think about what's happening right at the edges.

I

With our champion MLD I'm, one of the co-authors of the ipv6 node requirements update, are a c64 34, so in there we've elevated mo DB to should 2a must be probably if we're gonna do promoting SSM. In this document. We probably want to have something in here and make this document be CP that says, IGMP b3 is a must for v4 as well.

I

I know the ITF is kind of saying: don't do new things would be for, but we can certainly I believe, make a statement about making IGMP b3o, essentially a must for v4 platforms and then there's the whole issue of how all this fits in with the applications yeah, which applications are dependent on ASM at the moment which applicant, if we're going to say, don't use ASM interdomain, which kind of aligns with the draft that Percy's finally got out.

I

What are the applications, if any that are going to be hurt by that, so we probably want some engagement with the art area to have that discussion. I would say next slide, so I think that's all the slide. So basically, what do we want to do here? Do we just want to produce a carrot? Do you want to produce a stick? Do we want a carrot and a stick?

I

Do we just focus on promoting inter-domain SSM? Do we want to promote SSM everywhere and in the ITF terms? How do we express that? Is there a lot of musts and recommended and not recommended in a BCP document? What do we do? Stick.

L

Figure with us, I could probably give you like 20 or comments and.

M

Luxury to see that's what email is good.

L

For but at least I'm happy to heavily encourage as a Sam, but I don't think we should deprecated ASM completely for it lock into the main multicast like between independent domains, like sort of like on the internet or whatever I think it's a great idea to say: use SSM huh yeah. But there are cases where people have first of all like interred intradomain, there's some use cases for ASM, partly because it allows discovery and.

C

There is associate or what discovery.

L

Basically is forced discovery you have, you know you have applications that need to bootstrap that basically have no knowledge so sources whatever when they start up so especially link-local multicast, but sometimes also at his site, local multicast, like finding your DHCP server or there's. You know lots of custom applications from arias vendors where they, you know like light bulbs or whatever ever they need to come up and say I'm here where, where should I? You know these.

I

Are things we can talk about it's rather, there yeah.

L

But the our case is also where people have you know doing inter domain multicast, but it's actually within sort of like one organization or there might be cases where you are an isp and you are working with appearing with a content provider and I.

D

L

Ssm would be best in that case, but maybe there are some cases where it's hard to move to SSM but I'm. Sorry, just on that point.

I

I think it's important thing to put in the minutes is: we need to identify things where it's hard to use SSM for summary, I'm.

L

Happy to say use the system wherever you can ASM should be an exception when it comes to embedded, RP I just want to say there are people using embedded RP to not just on the internet, and your case is like I said where we have multiple domains within one organization, how people have used, embedded, RP or are using, and so.

I

The language could be within organization rather than within a domain. Isn't.

C

A domain and organization.

L

Like sort of like a management domain or if you talk more about, say, team domains, kind of you know, and we have to think about the language but I mean.

I

You might think about you know international corporate enterprise network they're, spread across multiple, so.

L

I

Instance, yes, and.

L

Basically, you don't want to have like one single RP for all of your traffic. You might want to say, for this site. I have this RP this other site to have a lower our peer ight, but you still want to have a reach ability throughout your entire organization.

L

Just one more thing: I should like the idea of discussing this different models that, like you, have now in the draft, but for each of them you know it can give you some recommendations to say this is best for this purpose only use this. If you have to it's like that, so.

C

To just kind of summarize, you don't want to deprecate ASM altogether, it's valid and reasonable within a domain between domains. Where do you stand for? Is it just recommend, SSM recommend against ASM or fully deprecated ASM.

L

I'm happy to say should not use ASM or you know you better only have you should have a really good reason. If you want to use I'm.

I

Just not quite sure in the IHF language, whether should not yeah.

L

There's never do this unless you help you recommend.

I

It enough space, so we need to figure out what.

L

Your language, it's not recommended there was something like that. Well, they can explain a little bit. Os sm is more secure, easier to manage and things like that. Nothing.

I

Yeah I think most of us in the room would say: deprecating ASM completely is the ultra hard. Brexit is not something humans do yeah.

K

J holin yeah I, wonder if coward from the earth would be the appropriate language but yeah RFC 46 on eine. You might want to take a look at informational security and it I believe I've referenced. A few times makes a recommendation already about not using ASM, so you at least might want to reference it, but yeah. Thank you for this, or it's good and yeah I.

K

Look forward to seeing the revisions yeah.

I

I think the idea is to pull together all the previous statements made in past RFC's into something.

M

Because that's.

I

Probably ten years old now I would guess of that sort of vintage. Yes, but I mean I I. Think 4,600 is process anyway,.

N

I

N

Pulling together all.

I

The comments made plus the current thinking into you know a current document. I think is what yeah.

K

Yeah I, don't think it references for you, six or nine.

I

Selected that in the minutes, thank you.

K

Yeah I can send you a follow up going on with reference to it and then.

K

That must be all it.

O

So Michael Abramson Kowal through here I, have talked to people and I've experienced this myself that doing inter-domain ism is very brittle and breaks in weird ways and it's hard to operate and I think. My main thing here is I want to help those within their organization making this case. When someone comes along and say, I need this and I need to do ASM while all because product or you know vendor only supported that or whatever.

O

Then, if this document is there, that might help them to say it and look go back to the vendor and to get them to implement SSM instead. So the everybody agree on that goal. Yeah.

I

I think I mean that I think the point David farmers making is it makes doing this, makes it easier for the internet to as an ISP is they're, probably providing RP functionality for some of the campuses that don't run their own. But it also does help the people in the campuses because it simplifies and hopefully reduces the amount of trouble tickets they're following up because of problems for those, because.

O

I think sometimes someone comes along with and like I must have this. You know we need to. We bought this product already. We always spent this money and it needs a is them to work or we're. Thinking of that about it, and this product is cheaper and it does say, isn't a little so at least give them guidance on on this and helping in choosing perhaps a different solution and for implementers as well yeah yeah.

C

I think it's one of the great values that we as a working group can provide is direction. You know to app developers providing that direction years ago. Had we done that and made a stronger point about SSM inter-domain, maybe we wouldn't have had the propagation of so many SSM unaware applications. So I think that's it's something that we can provide great value in is given clear direction. So that's why I think it it's important to not be wishy-washy and say you shouldn't do this.

C

Unless you do do it, I think making a stronger statement of use, SSM inter-domain or do not use ASM entertain.

C

You know, as a best practice I think there's a greater value in that than to just simply say don't do this unless you have to.

L

Yeah, stick with us yeah, so, first of all, I think it's a good document and we need something like this and yeah. Maybe it should be that strong I mean there will always be some people that for some reason.

L

That, first reason might.

J

L

Say yes, I'm into domain, but they could still have a very strong, pretty massive saying you should not I think the biggest problem is application vendors.

L

Then the network and the host stacks, mostly support, are in period three and MLD version two today, but those applications don't support it and it's kind of hard for us, an enterprise or ISP whatever to go into application. Vendors and say you need to you know, change your application and maybe, if you have a strong message that might might help make it easier to come in supplication developers, you.

I

Know I just had a quick scan through the agenda for an art area session this week, but I don't see one I could contact the ADEs the art area Radiesse and see what they think about engaging with that lot.

P

Sooner I'm more for deprecating endearment, completely removing it shutting it down. I hate it, it I mean half of my bugs in from vendors, are usually related to multicast. So as little as possible code master cost code in the codebase would make smile would make my life easier and.

C

And just to be clear, you said deprecated for inter-domain or for everything the.

I

Questions the question is what we would actually do to achieve that it's not about making things like MSTP historic, because that can be used within a site, potentially so I think we need to be clear out what that means. We can say if we as a crew, to agree that how do we express it in the document this.

H

Is Greg as chair? Otherwise we don't have a police to enforce anything anyway. Yeah.

M

H

We do is we position and- and we can always fall back to that, because people come and ask what to do. Read the dot. It's there. So deprecated inter-domain I mean that I've been on that side. Since Lindy and I wrote that as a draft back in 2003 and unfortunately, embedded RP took off and things kept growing now we're back to this again and all the same problems exists and the only resistance I've heard for inter-domain was well. It might be hard.

H

That's not a reason why you don't do the right thing if there's applications that absolutely require it. Let's hear about them, but the only ones I know that absolutely required are really Enterprise, like you know: Walt garden applications. We don't see this stuff across the internet at large and the whole idea have this bi-directional broadcast domain was you know a cute idea in 89 and it's not the model that we're trying to finish today. No meeting requirements today, yeah. So there I've spoken.

Q

Sunny is on from DPS I know, MSTP is widely used. Maybe it's only in China I, don't know who the other country he.

C

Saying is, or is not widely used.

Q

As widely used in China but I, don't know, the other country is the situation. So I think that the SSM has important and the model voice SMS important tool, but it will not kill the MSTP or the impact energy. So I have a sim opening with Steiger and the braggers, though I think the word recommend is better.

L

And stick with us I actually might support deprecating MSTP.

L

If you take crap, you feel decrepit ASM inter-domain, then they might as well get rid of MSTP as well. We haven't you know we haven't solution for any cost RP with him that has been around for maybe 10 years and not many implementations and that's better than them STP. If you want to do any cost repeat within your domain, so don't really see much use for MSTP.

C

Yeah, can you so you say it's better. How is it better because it seems like it's the same thing, only a different protocol. It's.

L

Better in the sense that you're not trying to you know, send data packet over TCP s, you know some MSTP implementation.

C

You selling data packets of the pen registers.

L

But also you, you don't have to it's easier to manage it. The Annie Kuster P thing is a much simpler protocol. It's basically just relaying register messages. You don't have to configure MSTP, pairings and and policy for your pairings and yeah.

C

Don't you have to do all those things for PIM.

L

You have to say what are your other our peace inside your domain, but you kind of I mean I, recommend.

O

L

That the config of our piece- and if you do that within your domain, it's not that hard to say konishi router. So each of your piece that this is all my any concert piece I mean if you want to do ASM in intradomain, and you want it to scale, then I would say that any cost RP solution with them is the simplest thing, because that may.

I

Be something we might not be something we could mention in the document. Yeah.

C

I mean I would I, would I wouldn't make a mean just I would maybe disagree. I I think it's essentially identical anycast with them versus anycast with MSD p1 is sending it over TCP packets, sending it over pen registers but essentially they're operating in the same way you can figure them roughly the same way and the fact that you can configure a policy with one and not the other. You can kind of do it with the but I. Don't know, I. Think.

M

C

That's it's still within the purview of intra domains. I, don't think it really matters, I, don't.

I

Know if there is anything procedurally within the ITF in this timeless ation process, when you polish Dakin as experimental, where there is a time after which, if it doesn't catch on and get elevated, it should just be killed or whether there's twenty-year-old experimental RFC is out there that have been experimental for twenty years and will be experimental for another 20 years.

I

Well, that's one yeah! That's one option we have, but people can still use it. Even if it's a story who comes okay.

B

I

Mcbride I'd missed.

B

Our last exchange in the notes, so it's just the way it goes so I just wanted to applaud this effort. It's really good timing, as I mentioned last, the ITF for the last year, so I've been working on some emerging technologies like virtual route, virtuality and things like that and in some cases they're looking at multicast to do things like you know each view you look at in a virtual reality. It's a new SSM group, some kind of weird things, and so there there are some new applications that are being used.

B

Maybe even autonomous vehicles I'm not sure that we are planning to use multicast. The timing may be really quite good, although I don't know if they care about ITF, but it would be good to put this down now, so we Hilly's point it to him. What's the transport?

B

H

The transport to the end said virtual routing virtual.

B

Reality sorry AR VR, yeah yeah, not virtual routing, so in this.

H

Application application a.

B

Central location.

H

Like data center to multiple scene,.

I

While a presenting amount on 5g scenario, script, so yeah.

B

There's a lot of scenarios like: maybe we even need to do a document on that in this group actually but yeah. So it's it's a there's, a lot of different in healthcare and all sorts of applications starting to ramp up the use of applications like virtuality. So anyway, it's a it's I! Think it's needed! It's about time.

C

Great great comments, please, hopefully they make it into the minutes.

N

It's vodka Deutsche Telekom. We have quite a large IPTV deployment in the network using nowadays SSM, but in the the old product also used ASM, and it took us quite some headache to get our network part of the core at least and since moving to SSM. The operations department has much stable, more stable network. So, from our perspective, the support for duplication so.

C

Sorry I was gonna, ask I'm going to guess. The reason you started with ASM was because that's what the application did and yes, how difficult was it to get an SSM aware application the.

N

The application didn't didn't change, we did aesthetic mapping at the edge in order to get from ASM to SSM.

I

But yeah I, think that mean the document we could choose to include guidance on how to migrate from your current ASM position to the holy goodness of SSM yeah.

C

O

I

Can play a role? Where is this still.

O

A set-top box problem: yeah: okay, that's that's my take as well.

O

But there's like the state of set-top boxes is still that they don't really support this.

O

It's improving anyway, because that that's part of the reason here I would like this document. It gives you another hammer to hit the set-top box the vendors over and to say you need to support SSM, stop doing ASM only well.

N

To be quite precise, it's IGMP version three that the new set of supports yeah.

M

N

Therefore, there's no need for ASM anymore. That's.

I

Probably the only must we were put in the document is that hosts musts for our GMP v3.

J

But I mean we told the secret we, we failed on this so many times right. So these these customers get our setup box supports IGMP v3. Now we're done right. Are you sending Eskimo G joins what right. So it's yeah.

C

It's the only half way there you're only halfway there by supporting IGMP, because you actually have to use it. Yes, I mean.

J

We can still kind of you know, write an RFC one for wonderful SSM mapping. I mean we've thought it would go away. So we didn't write one, but.

H

L

Stay with us, yeah, so I think it might be good to mention SSM mapping the setup box problem yeah. It's our Jim Pearson three and you want to send us comedy joints, but you also need some kind of discovery mechanism right where the setup box actually can learn what the source addressed to Judy.

D

L

There is some application infrastructure was something you kind of need.

O

So Michael Abramson, hey I, can I can tell you one vendor that I had to go out like an experimental box and they had a configuration file where we configured the s. And so, if you had a program lit like a channel list, this was a setup box for TV. You could not have SSM with two different sources where which had the channels, so it was sourcing the channel. You only have one because they probably just like slap this on at later dates that they're actual like there.

O

There was no s in the aim, the actual application they just did the mapping in the device, its SSM mapping, but in the set-top box.

K

J holin the SDP does support SSM, so you can.

D

K

Mean there's there's a RFC about it: it's not the main SDP one yeah, so we'll just take tour. Listen yet so.

J

It maybe maybe, instead of having a draft about you, know SSM mapping. The draft should really be on the scope of where do source addresses come from right and then basically, the real solution is they come from the application.

M

J

The sucking solution is they come from a poor agent, many you know, and overpaid network administrator and edge devices right. So that way, you know we don't even have a separate document that people may look at as the ultimate truth, but we have a section. That's really, you know just saying this sucks. The other section is better.

J

C

That be part of this effort, not well I, don't know if you know what this effort is because you just walked in.

J

C

A separate document exactly.

J

Because I just walked in.

C

That I'll provide your opinion on the mailing list, so some before we move on one one last question now so just by a sign of hands who would be in favor of the draft saying having strong recommendations to use SSM and not ASM interdomain versus.

C

Deprecating ASM for inter-domain, so so just a quick show of hands a non-binding show of hands recommend recommending I'm.

J

Sorry, but there's a contradiction here is what what is the.

M

Standard, if what.

J

Is the standard for inter-domain I mean v6? Yes, we have embedded RP. We can say that before we four, we.

C

Don't have to miss that discussion.

J

C

J

C

That's what we're trying to make that's what we're trying to codify and document here, but.

J

We already don't have a standardized. Mstp is experimental indeed, but that could be made historic.

C

So raise your hand if you think recommendation and leave it at that: okay, there's a couple of hands: probably six or seven hands: okay,.

I

C

About six or seven hands, or so for strong recommendation, how about for deprecating.

C

Okay, it's roughly the same so we're about split.

I

Fifty-Fifty five things eight to five in sometimes the first one from here with.

C

I

First option was 80. Second, option was five, so it's not exactly convincing okay and you counted us. Oh no, I wasn't looking.

H

Yeah so 778 yeah.

R

So it's about half there's a yeah, so.

I

C

Split I think it was roughly roughly.

A

C

But we didn't count that diligently.

J

For a 50/50.

C

So let's take this to the list, but please express opinions on the list all right and thank you Tim and Michael all right who Toshi.

E

Okay, thank you. So this is again the Empress first into the revision, and the version number is now 17 next freeze, so the currently so Carrie actually sent a mail to the mailing is that he summarized changes from the previous version and he mentioned that he summarized the changes from version 16 to burgeon 70. But actually it's not true. He summarized all modifications from version 15 to 17. Actually so totally he mentioned about changes from the last.

E

From the 15th versions draft and this special thanks to Stig, we had several lots of comments and we addressed his comment and Levi stir plums, 15 to 16 and 16 to 17, so mainly the changes made for a tutorial, but the qualification is, of course it's really important. So I we can just summarize how we change from the version 15. So we revised the interaction to clarify the criteria for Korea and so on and because we miss something.

E

Sometimes we missed discussion description about land book point, so we clarified the empress support for by laughs of louder. All on the point, and also we had some.

E

Well, we should clarify that mass must be a capital mass or that must be kept out should so we had some difficulty to distinguish master and Kepler muscle kept I should so we scanned and the collected such kind of deviations and the broaden the description over circumstance in which Allah fly may be sent before the Emperor's reaches for stop louder.

E

This is actually the clarification for the considerable el arts and also expanded on the clarity discovery on section 3, which is a packet which describes the packet formats of our dating theories with the message and the 400, but it keep tlbs. So mainly, we clarified the LRS situation of getting the embody two theories, expertise and also ecology. The this is just a typo. We collected a minimum length requirement in Section three and also the in the falling code item in Section three added an extra feature of the result: Ellicott Lynch and section four point: two.

E

We mentioned how to going to interpret the meaning of the outgoing interface in a time noisy section, but we also clarified in the section four point two which is studied from the talk about outer interface, and we collected a clarify the steps which, by the for section four to two and these changes, including clarification of the handling or the other main, prohibits foreign code.

E

And in Section four point: five, we correctly the description for the number of offs field. Actually, the previous version. The version 15 was not really clear for the elimination of the number of hops, so we specify clearly this kind of a statement decreases number hops by number of the standardized from work that were just written in a lip line.

E

Minus one the minus one is in this expression accounts for the additional sunrise Mossberg appended by the gateways outer, because the if you, the emptor, is curly or request is leached to the gateway which may be a gateway or proxy or network, and so on. Then, the disk, a wave bleep right to the Emperor's clients, and then he continuously start the new clearly always request message toward the center wall on the pointer. So in that case the number of hosts must be decreased, collector II, so we created explain.

E

Actually we already explained this kind with scenarios, but we didn't mention about how we can just change the number of hops specified in our regional header. So we clarify these points and added more specific details and rewarding Corrections in Section. Eight point one and eight point two go to the next, so this is a change from sixteen to seventeen. Actually I already mentioned about these changes of raw in the last embody meeting. So we didn't the previous calculation for the clearly alive by the time.

E

The current calculation method for the query alibi time was not wrong, but because of the politics, 2008 recommends a clock at time, so we changed a little bit about a formula for getting the query alive our time. So this let call us description, was changed from the version 16 to 17. This is a looks like a big change in, but even though you used previous securely alive our time calculation method, the same result will be given. This is just to support a newer, POSIX recommendation.

E

So next, so that's for that's all for all changes from the version 15, so I think we can just start. The second working group Lascaux.

C

Hey Thank, You Tasha, just just for background. This draft several years ago was was submitted to ie SG. It got kicked back, and so it's gone through several revisions and it's it's. It's in second working group last call the first one like I said it was last year. What we really need is just comments back from folks in the working group.

C

So please take a look and at the very least you know mention whether you do or do not support the advancement of this we'd like to get a stronger consensus than just just Stig, and with that Stig.

L

Just quickly I think this is, you know, really important. It's been taking way too long. There's implementations of this. You need this fried people, six and just hope, it'll be published as soon as possible. Thank.

C

You, speaking of which would anyone be interested in document shepherding this.

H

C

His eyebrows yeah thank.

F

C

Yes, so if there are any, if there is anybody who's ever been interested in getting becoming a part of the process, document shepherding is is an excellent opportunity. So please.

H

Reach out to Greg or me just let you know it's actually very simple: there's a template! You follow, certain questions have to be answered. You take it through make sure that it's are clean and then you work with the authors and Rev while it's in the queue. It's not that tough, but it's a great way to kind of see how the process works.

C

Great, thank you. Okay, thank you and where that second working group last call I believe goes through next week, there's another week and a half or so left on that alright Jake. If you want to come on up.

C

This these are the the did. You revise it, send me a new document or you say.

K

John got pulled away by a network emergency, so I don't have any updates from him. Okay, all.

C

Right Club, so just a little background on this, there was at in Chicago you, you ran a hackathon for SSM and you ran another hackathon over the weekend, this time with involving spring and v6. So we asked Jake to talk about how the how the hackathon went and provide us some feedback. Yes,.

K

So um so I've managed to continue working a little bit on the AMT implementation, the one that was that was open-source some time ago of 2008 or something and I extended it with ipv6 support, and this is the gateway or the relay or both both both there they're working together and doing IP six and in fact, I would like to walk back something I said last time about not liking. The interfaces on the gateway I tried to find a better solution, but I'm happier with it now so.

K

Anyway, the the the spring part in particular is more kind of you know, John's particular network. He wanted he wanted to do spring. So this was just a you know, something we could do in into one day kind of hackathon scenario to try it out, I'm, not sure how generally applicable it will be. I think a better solution. Longer-Term was probably your or something, but but the same idea is is pretty simple: it's let's see go ahead and do the next slide out just yeah yeah.

K

This is just since, since Chicago I've done a few things in AMT and MC proxy and those are still just all open source, I think MC proxy is GPL the three maybe but the AMT is BSD and yeah go ahead. Next slide.

C

um Can you just mention that you you, you said you added v6 support? What was your experience and adding the six support as an implementer, adding v6 support to something that had v4 only was it a long, arduous process, or you know a couple hours.

K

I I was hoping for a couple of hours and, and it was really more like two weeks- you know some of that was had I memorized, all the RFC's I'm sure it would've gone quicker. You know there were a few surprises that took you know, somewhere between a few hours in a day each to debug, but it perhaps they should not have been surprised. As you know, just I mean you know, joins have to have a source address, that's link local.

K

We knew right so yeah they're a number of things just along those lines, but it really the you know it wasn't that bad, the the well so the raw packets also or are different in IP forum v6. So that's another thing to watch out for you have to you: don't get so that AMT wants you to start with the IP start with the two. So the the payload of the AMT data contains the packets starting at the IP layer for both v4 and v6.

K

The v4 IP raw socket gives you the IP header, the v6 IP or a socket does not so. This was also a surprise that took some refactoring, but you know it's all achievable and not that bad. So.

C

Might just be good to you know note some of the things you came across as bread comes for future implementers who need to do the same thing because I'm not sure there are many other implementations on the vendor side for v6 AMT, yeah, yeah well,.

K

Right, I I'm, not sure if.

C

It's there are any when I tried the when.

K

I tried to configure it in Cisco. I got a syntax here, so I don't know if it's there or not. Actually right now, I didn't pursue it that hard, because I knew I needed this anyway and.

C

I'll save you.

K

The time of trying in the Junos.

C

Thank you, yeah.

K

But yeah I mean it's: it's not that bad. It does work fine. You know it's a hack around a little bit of packet formatting, so at the hackathon it was some setup time. This was the first time I did a an AMT gateway relay device. On the same on the same note, and that that went fine, the.

K

And then I inserted the the sort of shim injector that would so segment routing at this is a contact change a little bit, but you just kind of stick a header in there and the network can unwrap it right and that gets the forward along the path that's chosen. So this was a requirement.

H

Just a question way: when you've got a read the Gateway in the same device, the AMT joined effectively that comes into that relay doesn't have a relay associated with it. So how did that device note which relay then descend.

K

So that's that's in my list of extensions I. Think that you want to you want to do the right thing to do or a way to do it, maybe is, is to do multiple gateways with source filtering right, so you wanna at least that's what I've been that's. What I've been thinking, so you want to have in general, you're gonna need to have.

K

So when you use AMT for replication you're going to need to have an association between the source, the the the relay that you need to connect to and the source address right in some form right.

H

So if it's at the application side that can come in the content, descriptor some sort right, you get source group right.

K

But then you don't get the then well, but if you do it that way, you don't get you don't get multicast across the network right, so you get. You then would connect your AMT gateway to the to the relay associated with that source. Well,.

H

Where's the Association come from right. If it's at the application layer, when I did the content descriptor offline, you know, out-of-band I can get all the information when I get it inside my routed path. I don't have that capability. What's been done in the past is a DNS entry. We look up at the source and evidene s, entry that shows the resource.

M

H

That yeah, that's kind of universal solution would work throughout or within a domain, or you know, often in demos like this. It's hardwired, you just stick it in and know, what's really to go, Thea.

K

So it was hardwired in this demo. What we're doing is is publishing a recipe for how to connect to our traffic. We would it. You know, I, think that standard to do that would maybe be a fine idea where you know we will say we will publish a sort of list of source multicast traffic available through relay discoverable with the source IP. So that's the that's. The general strategy that we're pursuing we're inviting just.

H

Like a static list like that or you have it in in DNS,.

K

Well, if we can so if we could do MT over DNS, then that would make it easy.

H

Or even a group source pair, they can be entered that way in that you have a relay associated with it, and you get that as a result and that could be done in the path and rotted device like that relay gateway, c'mon.

K

H

K

Right and that's that's where it would belong whatever the solution is I think there are several different ones, including static mapping list or yeah. We could we could. We could do a DNS based solution, I think, if anybody's interested, that's kind of that's uh that's kind of the easy part or an easy part, at least for when we're talking about when we're still talking about convinced individual networks to connect to our sources right.

K

So if there, if we end up with any consensus on the best way to do that, then great you know we'll go with it, we're very agnostic as to how that works. We just want to. You know want to get our traffic out there. If we had an Ambo and then we would use it, you know failing that, we will act whatever it works, yeah.

K

So that's kind of at least that's my position on it.

K

So basically, what John wanted is to not run him. He had some technical difficulties with it and he also couldn't he didn't think he could get EMT into a CMS cmts within a few years, but that he could get it in his EMT gateway gateway yeah, but that he could get it yeah.

K

Well sure we can go to the next one, but that he could get it within the cable modems. So he has an easier time with those. So that's what we that's, what we spun up at the hackathon this time, the this yellow box on the on the right side here is the is the gateway relay node.

K

The idea would be that there there's multiple C MTS's in the real network and each one has a different segment routing header that you would use that you would associate with it any joins that come from that source IP, the the network operator would configure the the mapping from from remote gateway IP to the appropriate segment routing header, and then you just replicate it once per destination inside the relay, and that's the extra hack that I added I'm not again I'm, not sure how generally applicable this is.

K

There might be somebody else that would like to do it this way, while we're we for beer to finish or you deployed, but.

K

Essentially, I mean this: this part of it was, you know, a half days effort and it's not it. You know you can clean it up more and make it more efficient. You could spend a couple days on that, but that's again you know this is this is low-hanging fruit at this point for for kind of achieving this kind of deployed, then, if you want to and okay, you know from our point of view really, this is the way we send our traffic.

K

So as long as you can receive it, then we don't care what happens inside your network. So if you want to do it this way, fine I'll give you the source, but at Arles yeah.

J

J

Is there an AMT IGMP join being sent from the AMT gateway in the home router? Yes,.

K

So the the the receiver doesn't nee to join the home router.

K

That is running, so this was on open wrt and it was running MC proxy with with the AMT gateway that gateway was configured with to know the the remote relay right so- and this is something you can do in the network- you can figure the the home router to understand what relays it should talk to by source right and so that join that joint is configured to talk to to talk to this relay and then this gateway is configured to talk to that really. So there.

J

Must be some trick on how the relay would know how high GMP joins on the same downstream would only need to be sent. I guess as one copy that magically from the cable modem would be, you know, be able to be intercepted in capsulated right for.

K

The to inject the shim and to only replicate once for the.

J

Downstream yeah.

K

For downstream yeah yeah yeah, that's the that's the part we added. That was a you know, a couple hours effort how.

J

Do you identify from from different home routers in the AMD relay which of them belong to a single, downstream lookup.

K

Table config a statically configured lookup table configured here at the relay, so there's a so you have the remote IP address from that gateway, and so this was an extra hack. This is not. There is no standard about this right and if again, if there's interest, then we could put it I'm, not sure long-term. This is the right solution. This is just what he wanted to do to get it deployed. Well,.

J

I mean other solutions like this like option 82 at least we have a signaling, so I'm, not sure if it's operationally feasible to see at this table right. So if there is any trick on how the cable modem and insert something that basically, you know gives this information like this option. 82, then you could get rid of this table right.

K

Sure yeah, so that was because.

J

It seems like some lightweight amount of work is possible for the cable modem right. So.

M

J

Yeah to figure out what the best thing is to minimize the administrative work on the relay right, yeah.

K

You're right I mean the the that that part again, this is the part that was added and it was low effort for his specific solution. So if he had wanted a, you know a different kind of look up from remote, IP lookup and that would have been fine. It's just I think that's just the way that networks as.

J

A UDP emptied and kept saying downstream. It's still normally empty in the upstream. It's just this new segment routing header and then that just basically strip segment routing got the native multicast Center on the downstream yeah.

K

Yeah so right and and so it and we just do it once per destination, even if there's multiple.

J

Of the cmts that can't weigh empty.

K

He didn't say it might be a constraint on upgrading the versions, I'm, not really sure I wish. He was here because the assured me he would be and then yeah but duty calls I suppose no.

J

I mean, let me know right: I may be able to help figuring out how we could.

K

Yeah I can put you in touch.

J

If you can yeah.

K

I mean maybe he'd be willing to pick a different vendor, rather than putting this in it.

J

That's basically what he has to live with, just rather the the brainstorm, how we could automate discovering, which type of you know segment routing header to do based on you know, the met, get getting rid of the manual met in table.

K

Again, beer is probably a better choice: it's just not not there yet and he he wants to be ready to go whenever you know, because, even if you know when you have twenty thousand downstream, even if you can just do the you know your 50 Meg's for your favorite five channels. This can be significant right.

J

How close you can put the MT relay to the cmts right? If isn't the same pop and you've got basically that they can read gigabit local Ethernet links, and basically maybe it's I'm, not saying it's good I'm. Just saying that you know the good enough is often the the enemy of the better, and so we should be prepared for dealing with it right.

K

And then vice versa, you know it's a faster deployment. Sometimes this is more important, so it really just depends. But again it's like I said this.

K

This is really just a sort of network. Specific implementation I think that there are probably better ideas, but you know.

J

Many vendors in that cmts space right and it's basically in the u.s. right. Okay, so I'm a customer right, so I'm interested and basically you know all the other MSO might simply pick up the same solution if it gets multicast. You know better into these networks right so I'm. Never! You know just again text because of hex just right, fair.

K

Enough I will encourage people I'll, try a little harder to encourage people to look for a better answer so this, but this is what we we tried out just to make sure it was something that was doable for him. I think he's willing to explore other options. Just you know this was the the one that matched with the way he wanted to do his network anyway, like he cares more about IP six. The new have multicast at this point, but that may change any day, but.

J

I mean you can still kind of bring beer in if you try it, for example, to terminate vir one hop before the CMPs ride. It we're basically having to do.

M

J

Workarounds to keep the CMPs simple question is what about the rest of the distribution network right I mean that's what we've typically done in the past as well and yeah.

K

This is a part of what drove this was what's already deployed and what is easy for him to to deal with today he doesn't mind running an extra box, but changing versions on his deployed systems is maybe harder depending yeah. Thank you.

K

Anyway, so the the AMT itself I think is getting to you know: I wouldn't want to run something on it, where I'm I'm on the hook for refunds, but not yet, but with six months work I would definitely I think that would be fine with too much two months work out.

K

Probably this is kind of my list for most useful things to do to it, and you know I think that stability and and make sure it's really not just interoperable with the existing solutions, but actually following the spec is, is the first and most important thing I'd like to have I'd like to be running multiple gateways for to do kind of the source mapping, so that the you know you configure a gateway to talk to a relay and to ignore certain sources. You automate that and and hook that up hook it up to support them.

K

You know I, think I, high performance for during path, I haven't I, haven't really stressed the the performance on this I mean. If you really need a high performance, you can buy the Cisco unless you need IP, six or maybe maybe by then it well, but you know, obviously at some point you might need the high performance path. That's going to be, you know, month and a half but entirely doable it certainly right now. It's like single threaded live event based forwarding.

K

So you know whichever box you're running whatever that can support is kind of what you're, what you're looking at there, but yeah I. Think it's a it's a good next step toward being a true, truly deployable system that that can actually meet the needs, for hopefully everybody who wants it and if I get time, I will be working on some of this in the in the months to come, but that's a that's an if and may depend on on. You know how likely it seems to that it will get used so yeah. Any other question.

C

Great thank you for telling us about it and any other any plans for future hackathons.

K

The hackathons one of my favorite parts so I mean I, always love to take a couple.

D

Days, it might not be the last. It.

K

Might not be the last I might be skipping a couple, a I plan to be busy this year, but but as soon as I can I'll come back and do something right.

F

K

C

So when one last thing Mike do you want to come up and talk and time wise, you're it so and- and you have the next working group after this so take as much time as you are willing to take from your own working group.

B

Give yourself the hook yeah. This would be very quick actually and sorry. This wasn't something I requested. It was just a last-minute thing because something Alvaro attended this week. So there's a draft that a few of us have in this working group with regards to multicast over Wi-Fi, the draft hasn't been updated for over a year it's been low on our priorities. We've had other things to do, but in this draft there are things listed of why multicast is a problem over Wi-Fi and why people use unicast.

B

Instead, things like lower about low reliability, no acknowledgments low data rates, and just things like that and my co-author Charlie. In the meantime, he met with a lot of people and I Triple E, who have also been working on this problem and within the internet area. He submitted a draft with some of these guys along the same lines of the draft that we have here with a few more details of what's going on in the I Triple E.

B

So as far as I know, right now in ITF there's two documents dealing with multicast over Wi-Fi and.

B

In talking to Lenny, we still think it's good to have that kind of a document here, at least describing the problems we may or mean.

C

Well remind us what those two! What's the difference between those two and what working groups, those two are in yeah.

B

So the differences are and I'm not sure, actually why there is one also in the internet area. The differences are that they took pretty much what we have in our draft and included much more details of what's been discussed with multicast and Wi-Fi in the I Triple E, which is worth the defining the the Wi-Fi specs. So that's really the difference and.

C

Your dock was considerations requirements. What problem.

B

Statement problems they have, and so overall he had a meeting. Saturday I was not able to attend, but just wanted to see what he, if anything, more, that you heard.

S

Cervelo ever thought a row needy. So on saturday we have the immense pleasure of spending seven hours with the I Triple E. We have this periodic iesg II, I, Triple, E or ITF AAA, actually coordination meeting, and so we discuss whatever yeah how? What do we need to coordinate, and so one of the topics that came up was multicast and wireless and honestly, the the session wasn't too well organized. There was one question that was asked what I feel like it should be.

S

What should we need? What should we do and I guess some pointed out? Well, both I guess sucks on the wireless interfaces and the actually said yep.

S

That's it. So the draft that that you're, talking about the Charlie and Dorothy and Carlin somewhere else published talks about some considerations, so you're gonna do multicast over 802. These are some things you need to think about. In other words, it doesn't necessarily solve any problems. It just says. Well, this is what you're stuck with now. The thing is that Wireless is not just Wi-Fi right. It's not just 802 11 and many of us have the side protocols or have assumed that protocols that we designed for Ethernet work on wireless differences.

S

Maybe we thought that a to 11 there's other problems, for they go to 15 for that, the other stuff that IOT uses, and things of that part of the discussion that was kind of interesting- was that some of the people that have been working on six low and sixth ish talked about some of the enhancers that they have made at the IP layer to make it better.

S

So, instead of waiting and hoping for the I Triple E to magically fix all of 802, they said well, you know we're just gonna go, do some things so, for example, in six slow when 6lowpan existed, they did some proxy, they changed. They were discovery for ipv6. They did some proxying as they were discovery now that is helping some of the broadcast traffic that has to go on in there, so one's just as well as maybe those things apply to other layers right, not just for IOT right.

S

So what came out of the discussion was? There are some specific things that we know don't work and that we should go fix, for example, that W section 436 according to the tests that they came up with about 20% of the time, doesn't work. So there's a really high probability that you sit in this room and you get a duplicate address just because it just doesn't work over the wireless interface.

S

There was no specific answer. What we came out of the meeting with is yes, we need to coordinate better return, everybody in the ADF, but no one said yet. We're gonna go fix it. Okay and you know maybe it'll is not what's working what's broken, maybe we made the wrong assumptions, and so you know right now we're sort of with this impasse, maybe I'm an assumption. Maybe they made about assumptions, maybe do both in MCN over I, don't know so when we do want to do.

S

Is you're there's a problem statement that you wrote, there's some considerations, but you know we can go back and forth forever or we could actually do something. So one of the things that that we wanted to over that meeting is you'll. Get some people together, I, don't necessarily call it the site team people together to actually work and talk about solutions to go.

S

Look at the solutions that exist in the IOT 802 54 part of the world, to get other people that do radio stuff that maybe understand how the radios and the wireless stuff work better and you guys the sand. Multicast needs and broadcasts and stuff like that better and you know figure out what can you things we need to do do or we just do them with able to stuff, or is there something that we can do to progress this and not just have me and other people.

S

Seven hours looking at I should believe people in pointing the finger back.

M

S

Yes, we're just not gonna go anywhere with that, so there's some people that were that meeting that working the ATF as well, that you're interested in working that I see here, but that you know could collaborate, some of you guys and again, I. Don't necessarily call this a design team, but if you want I can get you guys together and introductions and we can go from there.

M

Bernardo's uc3m just to comment that we presented last year last ATF, sorry in internet area, also experimental work that a colleague of mine did on 11 AAA is evaluating how multicast the different solutions work in a testbed with up to 30 notes, I think so. These guys I'm not involved in that work, but these guys are willing to to work in any air for like evaluating any solution over that desperate. That is available. So in case you wanna check that kind of does have a level 4 for that.

S

Sure that's great over again, so send me email like now. If you really want to do something this, and maybe in the next couple of hours, I can sit somebody out to some other break or something, and then you go do what you go do so good. Yes, thank you.

K

@J Colin were there a list of solutions that you talked about or tried or I mean? Is that written somewhere.

K

I wrote Earth Anna.

S

Again so the the minutes that we're just looking at them. Of course, we see nothing. The guys have been working with 2:15 for in 6 th at 6.

S

Lo, yes, there's a couple of RC or drafts they've been looking at they've been been working on, so we can get those one of the things that they also mentioned, that the ITF guys working on that I mentioned as well as if they thought that you know this could be applicable in other places, not just 54 but 11 or something else, and then it would be good for them to get more feedback as well right because it should be applicable.

S

It could be that you guys look at it and say well, yeah there were 54, but if you tweak this, it might work for other numbers as well. So no but I can find out.

M

Kind of Banaras again and I think that.

M

I think that they, in the other day that you mentioned there are some I, don't know solution, but doesn't consideration I think from what I recall them how to configure different things? If an IP protocols to better work in which.

B

They thanks Mike in Ellora yeah, so just.

C

To conclude, with.

B

Regards to what needs to happen in in Bondi, I think those discussions probably would be best to happen, but I still per see a need for the draft that we already have here. That's been accepted as working group to t be brought back to life, be updated. Torres made some comments previously about what needs to be added, so I'll commit to do that. Finally, and then we'll go from there great.

C

Look forward to that work.

C

Okay, any other comments, statements all right with that M Bundy is done, you'll see you in Singapore and it's time for pin.

C

And now these are blue sheets for pin, please sign them. This is a separate working group meeting. So don't don't assume that you just signed some bone D, so you don't need to assign sign these. Please make sure you've signed.

T

Sure, if they actually provided.

L

Yeah don't see my.

G

L

Welcome to everyone, if you need some note-taker, you would often use the same one I think for Buffum, Bundy and PIM, but you need someone else.

L

You think you can do it.

L

Okay, my kiss mike is scribing anyone wanna do the jabber yeah. Okay, thanks for got a jabber scrap. Okay, thanks, let's get started so this is PIM working group meeting.

L

Please find the blue sheets again at the pin once this is a note. Well, it's the same as you saw other in the embodied session. Hey. This is the agenda any comments on the agenda. Does it look? This look? Okay,.

L

All right so I'll talk a little bit about the working group status.

L

You have a pin the yang model that we requested publication. Oh and March, I. Don't think much has happened to that. It's in that publication queue.

L

There is some there's a new proposal and it's maybe more than a proposal for how to do configuration state in turn and configuration state versus operational configuration state. One question is better that the PIM model should be updated to to follow that.

L

That's something we need to discuss a think with our ad and it depends on whether other other young models for routing like interface model and other things, will be updated to use, use that there's the source discovery draft that is in the publication, requested q now there's explicit tracking draft that has been more or less dead for a couple of years, hoping maybe we can make some progress with with that. It's only some minor changes, the thing that I needed for the PIM explicit tracking yeah since right here.

L

It's actually are you planning to to update this sorry. Yes,.

E

Actually, just I need to say solely for the delayed response, but actually, according to the previous discussion, mainly raised by, follow a do IDs, we changed intended status from the proposed standard to experimental traffic, so the Civil War, many something like tone for explaining some function or providing some guidelines should be changed. And actually you have been now talking with one Cisco by and he is now interested in changing something like tone to suit the.

E

Experiment, documentation so will revise the draft soon and maybe and do I hope next idea, meeting I can present device draft.

L

Okay, thank you.

L

A lot of working group draft is the multiple upstream requirements that sin that has been kind of not updated in a little while, but there's a new update now and we'll talk about that later. This meeting, you also had a draft on dr load-balancing that we requested publication. Oh I think, three years ago and alia that was the ad back, then she had multiple comments and issues with a draft and the offers didn't didn't update the draft, so it kind of died, but there's a new revision.

L

Now the first want to get this done and here's a new revision that was just posted, so we should probably maybe next next meeting- have some presentation of that. What changes have been made and see if the working group is still interested in in in getting that published so probably have to do another last call and so on.

L

If well, first of all see if there's interest and if there's interest, discuss the changes and then do a new last call if we agree that this is something you want to do but yeah, if you like, have a look at the last version and see what you think.

L

You also have a your improvement draft. So there's no update now blind know. There are some ideas and thoughts about some changes to go in there and some plans to update it before the next ITF. So I'll probably discuss it in Singapore.

L

And then today we will talk about I am p.m. of the young model and they have an MS TP young model. That I think is more or less done, but they need people to review it. So please go and look at the models, see if it makes sense if you're a vendor does it match your implementations are able to support it before a provider ice P.

L

Does it I love what you need to configure and monitor and manage MSTP and you'll probably ask on the mailing list sometime after this meeting to see if people are okay with our working group last call, if you have any comments on that right now, please you're welcome to come up to the mic, but the otherwise we'll just check on the list.

L

So that's the status, any comments or questions.

I

L

I think they'll start for the first presentation and which is the multiple uplink requirements.

L

Multiple upstream.

M

Okay, my name is Bernardo City.

M

First of all, apologies for not having updated the draft for a while. So I will excite this. Yes to remind a bit the the cause of the document. The purpose is to define the functionality that I am PNL. The proxy with multiple interfaces should surely should support for different in different scenarios and actually also to commend those scenarios were those this MLV idmp proximal with multiple absolute interfaces are I require.

M

So the content of the draft is basically a prime statement, so why do we need to to document this to support proxy with multiple upstream interfaces? Some a scenarios have applicability. We will see more about that in the next slide. Then requirements started from those applicability scenarios that this upstream, with this proxy with multiple our sip interfaces, should support and some security considerations next slide please.

M

So we cover different scenarios of applicability in in the document. I will not go into all the details, but just least those in in the slide. For example, mult multi cos wholesale offer for SEO services, which you have, for example, increment operator and alternative operators providers and how to could use a proxy with multiple upstream interfaces and what are the requirements imposed by this scenario?

M

We have also the scenario for multicast resiliency, where you, when you may want to have multiple providers and I, have multiple option interfaces and use those to provide additional resiliency. You may do the same for load balancing to reduce the load on the metro network by having multiple interfaces so on and so forth, and we also consider him in all these scenarios. We have consideration for fixed and mobile networks.

M

Next slide, please so on. As I mentioned before. On all these scenarios, we tried to identify requirements. The details are in the in the document, but here in the table, we just summarized for each of the scenarios that are covered in the draft. The different requirements and impact that it may have- or those may have- for the multiple upstream interfaces support for the proxy next one please. So this is just a summary of the story of the document.

M

The key point is that in this revision we addressed the comments that we received from the previous version. Basically, the most critical one was the adding some some text on consideration on SSN ASM impact for the different scenarios, as well as some other things that we fixed. So we believe that the document is revving in the sense of identifying doing that you have identifying the requirements.

M

Of course, then there will be the need for the solution document solution document to to work on that, but I will be a different document for the working look to to work on.

M

So we believe that the document is ready and what we assume could we could do is to get some ore that we will benefit from having this additional reviews from from people in the working group and I know it's a part of working Google Scholar before that's up to the working group to decide, but we believe that the document is is ready for for making products. So any question or comments.

L

How many people have read this draft? Can you raise your hand if you read this person, or maybe even that recent version on the draft yeah, the multiple uplink draft? Have you how many people have read that see like three people, I read it perhaps Oh plus well myself and gave six people all the offers, have read the draft all right so yeah since you've read it? Do you think it's it might be ready for last call, or do you think feelers a need for some additional work before before that.

L

This for me as a regular participants, it seems really complete online, come Fink or anything in particular to even had.

L

So right so for Law, School yeah, how many people support doing a last call at this points.

K

Sorry Jake Allen I mean there's like a couple of you know, Ayana considerations to be completed right, I mean there's a couple like obvious tenets. Are you gonna rev it and then last caller need.

L

A feedback round, I guess the question is whether you know there's like fairly big changes needed or if it's a.

K

Minor stuff, okay, yeah support matter, yeah.

L

So I think we can do that as part of the last column, if that seems reasonable.

L

Yeah all right great thanks, so I'll do a last call after this meeting.

L

But yeah it's great that these some people read it and looking forward to getting some comments. Our last calls are usually way too quiet on the mailing list.

B

All right, we should probably do due diligence and ask if anybody feels it's not ready for last call just to be fair: okay, no hands.

L

Yeah yeah you're right. We should ask that, of course, if you do a last call and people say oh, this is not ready at all, then we'll no listen to that, but yeah. So, let's see the next one is the REM PM of the yang.

U

Hello I'm Lisa from Hawaii I prep, resent the mattress yawn design team to introduce the updating information for the a gimpy and Imelda Yamato.

U

Okay, okay, that's the word for for the working group document for the champion. Mrd llamado Judd and the the drafter have reviewed by the young doctor and this forum by the working group chair, stick updating according to the documents and it had passed the validations.

U

The first updating for the three levels for the configuration, the the first level, is the global level or whatever. That means the Tempe and MIT attributes for the entire routing system. It is not running on the interface, it's only for the instance or the in order or her whole system like the max entries or max groups. It's it's only a few parameters.

U

So then the second level is the interface global in the fixed global means that is applicable to all of the interface and that the interface has no configuration of specific interface configuration the it is not easy to explain and that I had give a example for that.

U

If you in the interface global level, we have config a parameter like interval is the 200 seconds, and if we have three interfaces and the e1 e2 and e3, if I'm, only one we have configure our interval is the 100 and the actual running states for the parameter Y on the a1, the 8mp Corinto is 100 seconds and the e2 and the history both has used. The global query interval. That is the 200 seconds, and the third level is the interface level interface level, as means the specific to the given interface.

U

It's only or running on the specific interface and the interface level has some different of range from the interface globe level, for example, that is the group policy or verify sauce substance a night o or the immediately.

U

Next, the other updating information about this one is the, as we have some common parameters for both the 8 MP and MRD, and the description only including the 8 MP. So this dispersion, we add the description for the MRD and the other is. The protocol version is different from the Olympian MRD, so we move from the common parameter to the separate definition like in the in the slide that we can see for the edge MP and the werden range is the 1 2 3 & 4, the MRD, the were only one and the two okay.

U

Other updating information for the revised description did here. The errors.

U

So it we want to apply to the working group, mr. Kaul, and any more comments.

L

Yes, I have one question: there's been a couple of presentations I've seen this ITF for some new way of dealing with configuration status as.

D

L

And you know intended state and what the actual status so I'm wondering a little bit. Anemia alvaro can comment on that, but it's the plan to update all the ITF like routing yang models, to support that and the question is: should we spend time on updating this to follow that and will the documents that we, you know the models that we rely on as well, if those will be updated shortly,.

S

Randy, so there was a statement that was put out a few weeks ago that all of you should have read, but I didn't memorize, but the saving talks about. Yes, how should the drafts be published with respect to the.

S

To the different states, I forget all the names how them trying to stay as far away from the Yak politics as possible and and yes, I- think. In the same it, it suggests that all models, when possible, should be updated to the format. I think it's called the LMDC Matt, so it should be updated to that. It does mention I. Think a couple of cases where the model has been done is deployed your operation on the all stuff that you know.

S

Maybe it's not worth changing, but that's pretty much the biggest exception, if you want to I, can dig that up and send it to the list just to make sure that everyone sees it I believe it went to the whole routing area, but it may have gone not to the working group list to some other list somewhere, I'm sure this chairs, we have it somewhere. If you don't I can look it up. Yeah.

L

Trying to see if I could displayed something here, but anyway there's this guidelines for young models offers the using a new network management data store, yes, architecture, all right, there's a draft on that and and yeah. If you can forward that email it. Yes, oh look and I guess the other question is also if we should do that to the pin model. I guess that might make sense, I mean that's already. You know we already requested that publish but I guess it's nothing has happened since.

S

They asked for that right. So let me because that's in my queue, let me figure out with the yank markers and figure out well yeah! Well, yeah I'll just figure out what they what they want us to do. Yeah.

S

So let me I'll take that extra Thanks yeah.

L

L

Yeah, so any other comments on the draft and should be considered last call I guess they maybe should try to figure out whether we need to make this other changes, but our other only other issues you see. Is it more less ready for last call or do people think there's something that needs to be done changed.

L

Should we ask for hands, so members just need to wait.

L

Okay, so apart from this, you had just discussed you need to resolve that. You think the draft is ready for last call you raise the hand, raise your hand if you think we should do a last call it supposed to resolve the issue with a configuration data store.

R

L

I think four five.

B

L

Yeah I should also add versus design team with people from multiple vendors and I assume that they all are happy to do free to go to last call.

V

L

V

R

L

Doctors, if you don't think it's ready for last call and you raise your hand. Okay,.

L

No okay, no one against! So all right! So we'll see what our Alvaro says and you know what info he comes back with and that's some discussion on the list about the configuration model and yeah and should the goal should be to be to advise. The draft is necessary and your last call before the next 30th yeah, okay,.

U

Because our job, too dependent on the routing I'd have routing and I'd have interface, the Amado yeah.

M

U

Should be revised percent where and we follow yeah yeah.

L

Yeah, all that makes sense, but yeah and in general I've been hearing that you know. People want ITF models as quickly as possible of people will start using low mighty of models so hoping that this can happen. Pretty quick, okay, all right. Okay, um we'll move on to the other yang model, yeah.

B

L

U

Okay, next I represented the Matt Acosta young design team to introduce the item P and Emily snooping llamado. This is the first time to give the presentation here so.

L

I can just ask one question so so I see it in the draft there's only one offer, but but all of those people work yeah.

U

L

U

That the chapter has not updated; okay; no, not not updating, hi, okay,.

W

U

U

This this version destroyed the structure for the item. Peon Mr D is looping Yamoto according to the HMP and mr t moto. So we we, we don't have the agreement of with the whole structure just a noun, so the chapter who needs to update after the meeting and so the effort from the mark as a young he's on team from the edison jabber and who are we under cisco? We want more winners or cameras involved.

U

This is the whole structure for the item he and emeriti snooping llamado disturb is this is the example for the MV smoking emily smoking is the same chester. The IP address is different.

U

The item he's duping yamato we we achieve for for now we get the equipment that we use, the are jumping enemies to give profile style to.

U

Render the model- and it includes the a global parameters like the for modding mode, explicit, explicit tracking and the aesthetic group and the sum sum operation or in state- is not a compliment. Incomplete its gesture, for example. Here is the sum group and the source information.

U

So the profile we refresh reference to the Igoe breach top rich model that the model, so we use the model from the profile style which can properly use in the Whalen or bridge domain.

U

So the process can be fully independently if defined and can be augmented and can be rare references and from other models easily and of war for adjusted to the breach, doorman or villain. But we have not discussed for the we si or European is.

U

So that's the RPC for the atoms to ping. For now we only define the clear the atom is looping groups.

U

This is some urns there's some problem we and it's empty, more should to go on and the one is how to extended. The activists. New team profile stare the model to support vaporized or European, and the second is how to define the operational state date.

U

So next we we wanted to involve more vendors and carers and need more comments.

U

B

G

Giveaway and mystical: okay, that's pretty good! No.

U

G

Mother, you mentioned.

G

L

Yeah, just like the other models, it's really important that people look at this because else you know you some. If you're a vendor some customer might come and say. Oh, we want you to support this RFC. But if you don't know, if your implementation doesn't cover all say, like mandatory things in the model, you will have a problem to support it and, of course, ultimately, this is for people to manage the devices, so they need to contain what info people actually need to get so I think that's important.

L

It's important that everyone has a look at this and have you thought about supporting, as it says, are jumpy sleeping? Have you followed a GMP proxying? What will it cover that, or would there may be some additional things to submit it, to support that? Okay,.

G

I think we proceed, we separated.

U

U

L

I'm not sure exactly I haven't fall about it. I'm wondering will a sleeping draught more or less automatically. Do you what you need for prop, seeing as well Laurie I'm, not sure I, think to think about there's also speeches from broadcasts for him and doing a sleeping model. I think you know there wasn't discussion on like a mailing list, so.

Q

L

And they also had some model I think that they proposed. So if it's good to compare the models, I'm not sure have done that.

L

So we are guess at this point, your soul, working and trying to agree on some of these things in the design team.

U

L

I know: are you interested in adoption now it's too early to consider adoption I think.

U

It's not ready action.

L

So I think we should just encourage people to look at the model and provide comments on the list and, if you're interested you're also welcome to join the design team, it's animal from the ITF or anywhere that is interested in working on these models. So.

U

If you have a meeting on every Monday night, I remind the evening for for the Beijing hi yeah.

L

Yeah some either early mornings or late nights, all right, okay, as a please, if you have comments now, that would be great. Otherwise, please, please have a look at the draft and see what you think.

G

G

I, don't think so just make sure I don't forget them.

L

R

L

Okay, yeah great, if you can do it.

L

All right, so this is about him. We like people up here for prefixes over ipv6 next hop first presented last time by Ashutosh Gupta. He could not be here today he's the main author of this I've been involved a little bit myself and I'll. Do the update this time next slide?

L

Please and I might actually want to skip this one right now, let's go to this alright, so so, with multi costs with with him, but multicast engine, only he care about RPF, and when you want to select him join, you needed the RPF to find out what is the next hop towards the source or the RP and with PIM Merce person for you? Basically, you need to send an ipv4 to him join and it has to be sent to an ID before. Thus the nation's you need to find your ipv4 next hop. Send that join.

L

The problem, though, is there are people that are deploying this thing, this RFC 55:49, where they basically use ipv6 BGP to do both before in the six. They don't want to have separate earrings for both v4 and v6, so sort of having a single control plane for both before and the six wrapping, and this works pretty fine for unicast, but for for multicast or payment. Particular. The problem is: if the next hop is a v6 address, how do we find out what before destination, to send up him join to?

L

If there's only one pim neighbor, we can kind of say: okay, hopefully that's the guy. We should simply join to that's- maybe not that's great, but it's possible. If there's more neighbors, we need to have some way of resolving this and the the previous draft mentioned like three four alternatives and basically discussion.

L

Last ITF they concluded on this one simple solution which is to use the address list option which already is in 4601 and the new PM sparse motifs back at the standard, but in the in the spec it says that, basically, you assume that the address list has the same address family as the pin message normally and in the ARB see it says it should be the same.

L

Family and people have been using this implementing this for ipv6 just basically, the problem is, you need to send up in join to the primary I, just like a link, local address or your next topic, but sometimes people have a static route. So they're aware the next stop is a global address and we're used for v6 use the address this option to safari device to say here are my other addresses.

L

So if you RPF results to one of those, you know which link local address to send a joint to, and we figure we can use the same mechanism in this case. So basically have a four device with you. Send the address this option in a before hello and saying here are all my v6 addresses. So if the next stop is one of those v6 addresses, then you know what every four addresses. So in a way, it's the exact same mechanism, as is standardized already. It's just that you are kind of crossing address families.

L

So this one yeah thanks. So basically, if you look at this topology, you have a multicast host they're, just five five, five five to the far left behind are one and let's say r2- should send a pin, join well towards Eskimo G towards five five five five. So it needs to look up the RPF and in this case this Buffy 406 deployed. We have our before address in the six address for our one one column column, one and one one one one.

L

So we kind of want. We do have RPF look up using our the routing we got from the EG p v6 other LRC numbers. You get every six next up, four: five: five, five, five! Basically people say it's like one common common one, but we need to resolve this one one one one somehow. So the idea is if our one cents on hello and saying here are my v6 addresses, we would see that our one column, column, one is one of those.

L

So then they know that the actual pin neighbor to send a joint to is 1 1, 1 1, all right any questions so far. Okay, then I guess go forward. 2, slides, okay, so I started already mention this, so basing, basically using the address this option, that already is standardized and the way we use it is as before, except we are crossing at his family's. That's the main problem next slide and yeah this.

L

This has already been deployed or implemented and deployed by at least one Cisco customer and we're looking for adoption, and it can maybe be just an informational document saying this is something you might do. The one problem, though, is the pim RFC says 461, and what and also than the new internet standard draft says that did the secondary neighbor addresses should be on the same family as the primary address.

J

Tom Secord, so is the join for the v4 stuff. Then still an ipv4 multicast, yeah yeah.

L

The only problem is that they only get the v6 next up from the their routing. Ok,.

J

Well, you know, I'm was just wondering if the do we have so there is no interest to only have a single address. Family team, adjacency.

L

Maybe there could be, but at least as far as I know, from these deployments, there's both before and the six configured on the router interfaces, but I see what you say, though I mean, if you just wanted to transport me for multicast, maybe you could still use v6 p.m. signaling to receive it for multicast.

J

So the the address, the the address extension stuff is in the pin, v4 hello or in the pin, v6 hello. It.

L

Doesn't say it's not specific to our family and in the RFC. It just says that you do a hello where you can list. You know additional addresses, okay and the and the, but it says that the the address family of those addresses should be the same as address other hello itself.

J

So if we wanted to try to, you know, go the same direction as I guess. The unicast signaling is which is kind of trying to converge on everything over v6, then I think the minimum recommendation should be that that before mapping is the hello option in the v6 in hello right because, for example, one other logical next step would be. Let's say what is my preferred solution to transport the pim messages? So maybe we don't care about them anymore.

J

But let's say we just build a v6 port connection and in that v6 port we would also say yet. You can still send joints for crappy v4 traffic but kind of making. You know more and more before, just like a service that I can easily get rid of then in the v6 transport. So.

L

I think your what your part is saying is then also that you could send them. You six other consent, app enjoin that has a v6 address destination address like in the IP header, but it might contain right if four.

J

Addresses like before s, comma types and I will only, for example, build a single TCP connection. Right I mean one of the problems of I mean. Yes, we haven't made I, think a lot of deployment progress with port, because people may not understand the benefit, but given how it's you know about the fast convergence in a reliable fashion, especially when you have a lot of TV programs and they fail over, then definitely it would be useful not to have you know two competing connection.

J

146 144, but basically have been a single TCP connection, and you can also prioritize your v6 joints over your before joints right so kind of getting into that v6 direction. You know somewhat further I. Think within this draft. The minimum and I'd say is that you know prefer doing that option v6 so that we can, you know, get rid of before and considering something like next step being before n v6 in v6 port. So logic is just you know, yeah.

L

So yeah I mean there's also people that are trying to deploy v6 only in their in their core networks, and but they might still want a chance to actually deliver before payload so yeah. That can.

J

Be useful, I'm, just saying right, I think it's! The the first step is trying to make the control plane. You know v6 only and before more like a service in that v6 transport plane right, getting rid of the native v4 multicast packets. That's a different challenge. Right I mean then we've looked at other solution that, but that seems to be a little bit more more working, not necessarily yeah.

L

One thing, though, I would say: I would prefer you know as Laura. This I would prefer to just have this like a separate thing. It's it's just a lot of use of an existing option. So it's a fairly simple document and easy thing to do, but to do what you said, you know with using say a v6 conjoined to ask for before traffic. Whatever that really needs to. You know revise that the PIM spec, because it says that it must be the same address family well,.

J

You know I'm I can see an author's wish to be as simple as possible and leave all the options up to the implementations. I just love to see even protocol drafts to be you know, preferring in their recommendations what we would consider to be the best operational practices and I think that would be to have the hello option in the v6 p.m.

L

And the other comments.

L

I know whether I should ask this: is the author, or maybe something the chairs should consider, but as a as an author I would like some guidance, maybe whether area it's worth trying to you know see if the working group wants to just do this or if we should, you know make him, maybe make it like a bigger effort. Oh no.

B

Ok, so how many people have read this draft by the show of hands? One? Two: three: okay, sweet: four, four.

L

And a half of myself, okay,.

B

And so we need more people to read it, but I guess of those four that have read it aside from Stig.

B

Is this a work that you think that we should be doing here in this working group and go as far as adopting this into our working group? Show your hands? If you think it is okay, so we got four hands? Okay, so who think? Who thinks that this should not be something we work on in this working group?

B

Okay, so that's a good sign Stig! We should I'll, take it to the list and then.

L

You want to know, though, do people think it's interesting to look into what or less commented on you know about. How can we, you say with sixteen joints to to basically join me for multicast or.

J

Most of my comments didn't necessarily have to go in this draft right. That's just kind of the type.

M

J

Know dual dual plane: where do we want to go? Alright, I? Think? That's that's a good thing to think about, but maybe all in EMBO, Andy and I was thinking the minimum thing we could do in this one which might be sufficient for this document would be to put the preference in there that you know by default. The address you know the before addresses should be in the pim v6 I think that was the only impact to this draft. The other stuff I think goes beyond.

M

J

Draft- and you know raises the operational question: where do we want to go yeah yeah? Would you say.

L

All right, so maybe I should just you know: yeah I'm, gonna. Ask another question: that's a chair. They'll sit down, lafurgey, that's okay! So thanks all right.

L

Yeah so yeah, it's not I was wondering about adoption, but I know if you're ready to do that. Yeah and.

D

L

When I check on the list them, okay, thanks.

L

Okay yeah, so speaking,.

D

L

A chair yet I think also. It could be interesting to look into what role is mentioned, and maybe it's something worth discussing an amble des well to see whether you know people that deploy multicast, where it's useful to kind of do if form of the cast with v6, signaling and so on.

L

Maybe talk to a few when eyespace and see if they are considering deploying anything like that or not.

Q

B

Everybody sign the blue sheets, raise your hand if you have it alright with that. Thank you all.

L

Right, thanks to you in Singapore and they'll, do a joint meeting when I'm only I expect next time.

T

Yeah I mean this makes sure we get emotions, I, don't know you need the size of English sheets. Oh that's true! Yeah! It's true much circle. I, usually do that you.

B

Should have another, we should have any draft.

V

L

Must be aware, but pricing.

N

L

L

V

L

I think, like this VPLS document, talk about prop seeing as well.

L

I'm not sure myself, I think about what difference.

W

W

L

Mean I, don't have much just say about it.

V

But a few minutes.