Internet Engineering Task Force 102, 18 Jul 2018

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF102-IPPM-20180718-1330

Description

IPPM meeting session at IETF102
2018/07/18 1330

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

A

B

Okay, we're gonna go ahead and start so, if you're presenting you get to see your slides down here, if you're watching, you can see the slides over in the meet echo or you can maybe even log in to meet echo- are there's just some problem with getting the signal off.

B

All right so hi I'm Brian Trammell, co-chair of my ppm. This is AI ppm. I, see a lot of familiar faces, um so I'm assuming pretty much everyone's in the right room. um Hialeah welcome.

B

I'd like to first introduce our new co-chair Tommy poly, um to be running things today, basically um yeah, okay, so everyone welcome Tommy and let's have a meeting all.

C

Right welcome to IPM everyone I'm looking forward to joining you and apologies. If I don't know, everyone super well right now, but I trust that everything will go great. So, let's just go through the ministry via. So here is the note. Well, you have seen it before make sure you do note it it's slightly changed. Yes, note it! Well!

C

Yes, we are so sweater is taking notes for us. Do we have anyone who's going to be jabbar, scribing, okay, Brian! Thank you, alright. So a quick status update on just the some of our working group documents that we're not going to be talking about this time. We have two documents that are in the RFC editor q1 is the ipv6 Edition 2, 2, 3, 3, 0 and I think that one is just in the edit state. So it's nothing particularly new to update their the team.

C

I'm being draft does have its Ayana marking gone through and it's just I think it has a dependency on another draft reference and yeah, miss Roffe, so I think that's just waiting on the underlying document. Yeah great and then we also have a working group working group last call on the T web test document that went out a little bit ago and that ends today. I think we've only had a couple responses, I'm just saying yeah, it looks fine. If there are any other concerns, please bring those up. Excuse.

D

Me only have this small screen. Yes, we can all right.

B

C

B

Should hopefully be fixed as soon as possible, yeah.

E

B

One person who has not yet said that 14:1 test is okay to stand up and say it's okay, so that we can say, we've got enough people who paid attention excellent, um yeah, okay, perfect good, it's good! So working with last call is now complete. um We will I guess it do we have a shepherd assigned to that already I'll take a look and um yeah okay, yep, we'll get it moved along. Thank you.

C

So we have a fairly packed agenda, so let's get moving on we're almost at the end of our five minutes for administrivia.

C

So we're doing that we have updates on the initial on the metric registry and the initial content of that registry from al following that, we will have a number we'll have a update on the IP pm route Draft and then a whole chunk of IOM updates.

C

Following that, we have two other drafts that are not working group items yet but have been brought up in a hat to the list that have had some discussion so we'll be going through those and then at the very end we have some time allocated for lightning talks. These are going to be limited to five minutes at most each and we will get through them as we have time so any agenda bashing on this.

C

Alright, let's go.

E

F

I'm al Morten representing a okay, well, everything else works perfectly so I'm al Morten, and this this is the initial registry contents draft that you see displayed there that we've been working on, obviously for a long time, but that's the draft that feeds into the performance metrics registry draft, which has another long list of people and has also been worked on for a long time. So they're really quick summary because I want to get to the discussion. I think you're gonna quickly assess the fact that I would like to see this done.

F

I would like to see both of these done and now I can see nothing. You can't or they're there. So anyway, let's see what happens perfect great now, everybody's back online. Even me, so here's the quick overview by the way who's read these drafts. In any version, there are okay, several hands coming up. Thank you. There's a I mean there's a lot of years of work here, so if you're interested in I ppm at all, this is something you really ought to be.

F

Taking a look at because I'd like it to be done as I said. So we're solving a problem here, all the original rfcs for loss and delay and so forth. They were written with great flexibility, we're adding precision here now so that if you make the measurement according to the way the registry specifies it, and you do all the things the registry says you're at least starting out with two fairly identical measurement systems. You can Prost I still probably do a few things wrong, but you know with you.

F

You can't fix everything like that stupid thing, so it really applies to all of these active, passive and hybrid I've. I want to be sure that that's that's clear here, so a passive measurement people and hybrid measurement people- you should be reading this.

F

This is the first time we've had no substantive provisions in the registry itself, so that means we're also closing in on you know the truth and or point of diminishing returns.

F

This is what the registry looks like in a graphical form where you can see. We've got these different categories of summary metric definition, methods of measurement, the outputs, administrative info, all that sort of thing. So that's the quicky quicky summary. So here's what happened in versions, 7 and 15 respectively. This is going to hit all of you, authors and editors.

F

Rfc 2-1-1 9 was updated by RFC 8174 and, as Tommy just reminded us, we've had a couple address just moving through iesg and we got dinged on the fact that neither one of them referenced 8174, which updates the terminology in a nice way. If it's capitalized. Now it's supposed to be taken as this definition, so everybody needs to do that. Enough said: we've revised the passive tcp metric Yakov Stein provided comments as as planned.

F

It would still be good to have a look at the heuristics for the methods of measurement there and my friend Brian Trammell who's here somewhere. He's he's offered to supply comments on this a few times. I really hope you could find good moment.

G

F

We can we can definitely improve the heuristics if we get the Bessemer review there. So we clarified thanks to ignosi Asst. You know SEOs comments, mail with me DNS, which is in Section six. It's a response time and responsible isometric we've clarified that that's from the user perspective. There was some thought that we might do some more complicated things measuring DNS. What we're? Not it's, just this simple thing that everybody else does they do the user measurement so discussion points we got here in like a minute. That's pretty cool!

F

So now now is when you all sort of rushed to the mic and give me feedback on these critical points of interest for a DNS response, time and loss. We need a way basically to track the fact that a given request has either been responded to or not, and for that we need the equivalent of a kind of sequence number something to determine correspondence between the and subsequent requests that we make.

F

So the offering here is that we could use a random source port or we could try to Populi populate the ID generation, which may or may not be supported. Brian.

B

Frankly, I'm speaking as an individual, so random source port is part of type P, which means you might get different paths um treatment. So don't do that. Okay, DNS has an ID field right, yeah, the query Radian, so you can just actually just just do that well. Register yeah does.

F

Anybody have any feeling for how well that's supported, though that's just a question: I wait.

B

So no I mean you, wait, there's a there's, an ID in the query and the response refers to the ID so like yeah, it doesn't work if you don't use it. So it's not a very.

D

B

It's not a very big space right, so you're, actually, then limited I. Think it's like sixteen bits.

B

That's 16 bits big enough big enough. Well, it means you can't have more than 64 K outstanding things to the same server at the same time. So it depends on I. Don't want that!

B

You might not want to do it. Somebody saying it's a limitation then you'd have to actually talk about it. Okay,.

F

B

You note that it 16 bits and then people who want to stress test DNS servers, will understand they got to go to another IP.

F

B

Yeah, so that's.

F

16, that's great okay! Let's consider that well, actually we're not going to consider resolved until Malini speaks. Thank.

H

You, you know not to throw a bunch of monkey wrenches into this, but DNS is getting encrypted all over the place and, being all different and I mean I totally get that I know. I know, I mean I get the you know, I mean that the transaction ID indeed, is there in unencrypted.

F

H

F

The you were the endpoint we're the end point here so we'll get that we're we're we're in the in the world of relieved opacity, so.

H

So this is only for for non-passive yeah.

F

There's acting this.

H

Is active? Okay,.

F

Yeah yeah: okay, thanks!

F

Yes, all right! So that's one! So then we have this other point in section, 8 we've got this one specific metric for UDP, one-way delay and loss, the probability variation and things like that there too, and we left this open so that people could provide, have have some flexibility about the the packet stream that they're, generating and so forth, but I'm I'm. My tendency is that we should make this fixed time parameters or fixed parameters that we choose for the for the packet periodicity, for example, in the packet size.

F

So any thoughts on that and does it end? Does anybody have any preference? In other words, would you like to sort of keep this VoIP like that's the typical thing for periodic.

F

No opinions all right so we'll try something and we're gonna make it fixed and and if we don't review it, then we're all going to live with it. How about time I there are tons of measurement systems that do something that's very VoIP like so I. Don't think we can go wrong if we go that way, but good thanks.

F

Alright, so next steps open issues for TCP out of review, we've I think we solved DNS response time and the end, the other one I'm gonna, take a shot at I know that we got input basically from the XR block. Folks, Rachel you, you were thinking about adding some metrics.

F

You guys looked at the I went to the meeting you guys looked at the at the registry.

F

Jonathan was kind of flipped out by the size of the document and how big the reference, though each entry was, but but it's an RFC to you know, so it has the function of of being an RFC for these things as well. So yeah I think you guys agreed to work on some new metrics, just nod or say no she's, coming to the mic.

I

Yeah yeah so uh yeah in the last meeting we discussed this and I think yeah. Some people may think that you know have a registry but be useful yeah. Some people may still think it doesn't have value to do that. So.

F

I

People apply on something.

F

So this may not happen. That's.

I

Not hot I think I need to see people how how many people interesting this and won't you contribute in this draft I think so. Maybe it's doing more discussion, but actually current the except rock doesn't happen in new work and have our.

F

I

This time, so we so.

F

That's a factor to God yeah, okay,.

E

That kind of the remind you make sure you share your name with Rachel.

I

C

I

Rachel from Holly yeah thank.

F

You and innocently the blue sheets up here for folks coming in late. That might want to sign it all right. So really the TCC TCP section URIs --tx, is where we're looking for more review and that's it for this one. So I. Thank you for your feedback today and the status reports and stuff like that cool. Thank.

C

F

C

It also just one comment on that, because I'm fairly new to these since I was reading through these documents, they are quite long but I think they're, very well-written, they're, very good introduction to the space, and so not everyone did raise their hand on this for having read it. So I encourage you to go through it and do get feedback, because these are important.

J

F

So this is a completely different talk on a completely different draft. It's the advanced unidirectional route assessment, which I'm doing with not Ignacio is the first person there. Yocum is the third and Carlos is the fourth and I'm al.

F

So here's our here's our quick background. We got this going really in draft form. Far before I see our ATF 1999 and we worked it through to adoption in 101 got lots of good comments along the way so that it's jumping quickly to the good verbal feedback. We got from the last session that we needed to qualify what can be discovered here for the kind of the active and traceroute methods, and we've actually done that three times in the text now so there can't be missed.

F

We've got the new methods where we even move them now into the methodology section on temporal composition and this routing class see that we've been talking about and waving our hands about. Those are in the new methodology section we're kind of referring to addition, existing tools there for sure in terms of parish, trace draft.

F

In fact, when we started this draft, Bryan's first advice to us was start with parish, trace, wrap, and that was a good place to start and then the I/o and am stuff appeared as we were working on it, and that was another place to start in the hybrid space, so that we also had comments about- let's incorporate MPLS in here somehow. So we generalized our definitions to do that.

F

But now we've actually got a proposal for an appendix which we included in the draft text from rüdiger guide that talks about MPLS and carlos has reviewed it. We've got some few things to fix there anything else on this, oh yeah, and on this on the reporting section, we basically said: look there's a place. This RFC, where we talked about storage of trace routes. That's in in retrospect, that's not going to cover everything we talked about here and I. Think I'll get to that in a moment.

F

Actually I'm gonna, because I'm in control, I'm just gonna, go! Do that so you know trace routes are composed of hops. Each route is represented as an ordered graph. So this is the ordered Oriya graph for a single member route and with with by designating the host with this hij terminology, we can. We can actually make a kind of a multi-dimensional tupple here.

F

It has to include the host identity, but all the rest of the things here are optional, like the arrival interface, ID departure, interface, arrival, timestamp and a round-trip time measurement that went along with with that information.

F

So this is what a route ensemble looks like skipping the source node, and so this one would cover you know multiple cases anytime. You have a unique route where some of the hops change now you've got a different member of the ensemble. So that's the quick background here all right.

F

Yes, so in version 2, as I mentioned, we've worked hard on temporal composition for route metrics. Why? Because, if you've ever done trace routes and then done it again and done it again, a lot of them, the results are highly continuous repeatable. You get the same answer many times. That's the way. To put it the spot.

F

What you would basically do is is kind of reduce your repetitive tests, so the cases that are interesting and we're kind of saying that that really the load balancing places are the ones that you really want to look more and more often, but we've got your wrist except they look. If you see anything else, change in a spot check of the other things that you think are constant. Now you got to rerun the whole thing. So so that's what we've got in there for temporal composition. It's not a predictor of the future.

F

It's just using the past to try to reduce the amount of test time that we're taking up.

F

So now we've identified that there are some load balancing cops in our trace route and what we've observed there is that load, balancing hops treat packets of what we're calling a routing class see equally, and we talked about this route, this class-c concept many times it originally appeared in our original framework, and we have let's say enhanced it and and better defined it in the RFC 77 99, which talks about active, passive and the hybrid methods of measurement and it it would potentially be a metric parameter that we would use in this work.

F

So going back to our terminology, each member root of a root ensemble has a routing Class, C and I should say the I should say the thing about why I'm, using this word routing this adjective routing, there's there used to be Class C addresses, and it came up in discussion that people flipped out that we thought we were talking about Class C here for the old address space. You know the class classical address space, we're not we're not it's a different. It's a fully different class seat here.

F

So so, as I said, each member of the route has a Class C, so there's a synergy with the temporal composition. In that now you know the kinds of things that we're interested in determining about the load balanced portions of the path, temporal composition actually helps us determine those and and avoid testing around them. So we think it's very useful to know. In fact, it says that both in twenty three thirty and seventy seven ninety-nine- and then your line is how useful is it come on pay attention? Everybody, let's get with the program here.

F

This is supposed to be an active discussion. You know, I think it's hybrid, so route measurement at a midpoint. Has anybody ever heard of this? Does that mean anybody ever done it?

F

It becomes important when you make a midpoint passive offers observation of a stream that you can only sort of observe and because you observe that stream having a problem. What happens next, you want to figure out where the problem is right. Maybe it's got a round-trip time larger than you might expect. Well, where's, the congestion half or the delay variation. That's causing that round-trip time to expand.

F

I think this is a great idea, but what can we do this well at the hackfest I hacked around with spoofing the source, IP address and I figured this would work and and and- and it actually has to work if you can observe both paths. Through your observation point and and that's one of the things that we at least in this path, that you should be able to do, the bad news about spoofing your IP address or somebody else's IP address- is that now they're going to get unexpected?

F

You know a destination, not reachable from certain points along the path, probably not good, not good, but and it, but it's an interesting way to start this. You know to sort of see: okay. Is there really stuff out there that we can look at so it turns out. The end-to-end flow conforms to a specific routing, Class C.

F

So it's going to have a lot of flows around it in terms of source, address and destination, address, source port destination, port and protocol, which will also fit in that same routing class C, and now, when we're at this midpoint, we can launch new flows, we can examine the RTT to intermediate hops and we can perform other diagnostic measurements from that midpoint and and they'll follow the same path as long as they're part of the Class C, that our flow of interest has helped us to define, along with the examination of the route, so I think that's a cool thing and I think it also is partly answered to the question of.

F

If you guys measure this RT T at a midpoint, are you going to do with it? This is one of the things we could do with it. So it's plus any comments on that. Anybody want to help I.

F

Don't want to go first next time.

B

No I don't help I, don't.

H

B

I do want to help hack on some tools and I'm going to I. Don't think he's here so I can volunteer on his behalf on a volunteer. Yari yard also do some hacking on these tools cuz. This is so it's interesting to me that, like traceroute is kind of old and boring and dead not dead, but I mean so if you look at, if you look at like almost all different, like you know, most of the trace routes, sort of in open measurement now are done on right.

B

That was nodes because it's a huge network and if you look at though at the code in the right that lets note, it's actually got comments from Van Jacobs and in it. So it's like the original trace right yeah, but it's old, there's other stuff that you can do in this space. That's really interesting! So I'm gonna put my chair hat back on now. um A lot of this stuff is actually new. We're developing new algorithms for traceroute like stuff so Rory's interested in this, which is why I'm volunteering them yeah.

H

Take a look at.

B

The document and and look at his sort of he's doing a little bit of hacking around on stuff like this, um and it makes me wonder about the status this document. So what is it now?

B

What are we targeting? Oh, in other words them for the milestone? No well, no, like so intend to status, intended document status, Oh.

F

B

Track yeah yeah.

F

Okay, hmm but there's I mean when we're talking about methodologies, yeah and we're talking about tools to back up the methodology. Great and and I've, like I, said: I've started hacking around with parish traceroute the MDA. You version.

K

F

It for me it's all about results, presentation, yes,.

G

We determine what.

F

Class C is writing class C that helps us determine you know what other things we can do from that vantage point.

B

Okay, all right I bet, that's still good, all right thanks. Okay, all right.

F

And give their comments, so we've got some to do's, some of which we've done. Actually, we did the first one about investigating parish, trace routes, v6 capability it we have to have some other stuff to do there, especially adding cautions about the methods we've already added questions about the metrics, but you can, but you can probably say some things too, that are useful about what happens when you use good measurements, badly. uh I think and we did an MPLS appendix so, but we've got more to do with that.

F

So we need to complete the work items. Working group and authors continue. Your review of the temporal methods, the classy methods, the multi, multi point, detection, multi path, detection, algorithms, stuff, look at look at tools for this I think you'll find that that's valuable all the material.

F

All the material on that topic is in Section four and we're still looking for review for the later sections, which Ignacio is the primary primary author of and where he's used the round trip delay to do analysis to find things like congestion points and stuff like that determining link types and so forth. So that's um all to do I think! That's it yeah yeah! That's it.

C

Any more questions coming to that volunteers.

F

To review the draft Leah.

C

Great Thank, You Leah all right. Thank you out. Thank.

F

You thank you all.

C

Right next up, we have Frank and many IO am dr.

A

K

Even looks cool, so this is an update on a variety of drafts and a couple of new drafts and Mickey is here: it's gonna go a help with a raw export draft.

K

So we'll talk about the the main data graph that we have adopted for awhile now and we're talking about a couple of individual contributions for now that we're hoping to get adopted very soon on encapsulating iom data into the expand, GP age and eve GRE, and now so ipv6. There's a new draft on that and well. The obvious question is: how do you get the data off box?

K

We have an export draft for that now, so that the D capsulated note can go on to export the data, we're not munching around with the data we're just exporting it, which is why it's called well export and then mostly as an FYI. The SFC working group between last meeting and today has adopted a draft on Io I'm, Ana's, HN, encapsulations or making progress there, and they also adopted the prove of transit draft so to actually prove that a packet made it through a sequence of hops.

K

So that's related week.

K

One topic that came up- and it also spilled over to a couple of other area mailing lists- was that the section that we had on layering iom data wasn't really entirely clear, and so we updated that one section with yet another well half sentence basically saying well, you can have iom data in one protocol like the expand, GPE or genie for NS h and if genève happens, to run over ipv6, you can have iom data in the layer below like the v6 layer as well, and it doesn't necessarily need to be kind of from the same operator up this way.

K

So you can go and put that data, because well, the one link might be operated by the guys who runs OpenStack and harass the jean-yves overlay and the underlay might be by the v6 underlay operator. So we try to go and clarify that. Hopefully, that's good enough for everybody by now, because, while after proposing that language also publicly we've not really seen any further comments. Well, we also clarified and that's based on a comment of Tom Herbert.

K

Is that once you do the encapsulation, you should closely follow the recommendations for reuse of port numbers or use of port numbers and 7605, which basically says well. Udp port numbers are not globally unique. If you haven't well, have an uncontrolled environment like the global internet, so don't touch content just because it carries a genève UDP number. The content might not be genève. So don't blindly update information in transit nodes because you believe it might be iom data carried within genève. Don't do that it's there.

K

So there is a must, not statement for kind of global Internet deployment in the various encapsulation drafts we're going to discuss in a second, then we also started to do the laundry that we have, probably that we promised in the last meeting largely around the security section and many thanks to tell to go and do that work. So there is now a variety of potential attacks that you can go do if you have IOM present.

K

So obviously, you can fake the IOM data to make the consumer of iam data believe that the information well leads you to failures that don't exist or you can kind of capture failures or hide failures in a positive and a negative way. You can well expose Network information to people who shouldn't know that. Well, the network information is there, so you cannot get an understanding of the network topology, despite the fact that you don't want to go and expose that you can use it to consume resources because we add data to the package.

K

So we increase the packet lengths, that's potentially bad. If it's uncontrolled, we consume resources, that's potentially bad if it's uncontrolled, so all of these things are potentially bad if they're, uncontrolled, the good thing is, I um is defined for a constrained domain for an operational domain as opposed to it runs on the global Internet. So all of these things need to be taken into consideration, so we've basically listed all the bad things that can happen.

K

One thing that came up also with the layering discussion and I touched on. That, briefly, is if you have a genève layer and the other v6 layer, underneath we always refer back in the document. Like all the information that we have an old ID, a interface ID, that's all its own namespace. It all relates to a domain, an operational environment.

K

Do we ever in any shape or form on the wire or anywhere else identify that domain at name space? We don't so, let's say an area that we still believe we want to go and do some cleanup on, because we refer to the network domain.

K

So we refer to the namespace, but we don't carry the namespace identifier anywhere because yeah, if you have that namespace identifier, if you just export data, then well, the exporting information would not only have the individual node ID ie 13 or interface ID 25, but you also have the contacts that tells you. Ok. This is the namespace that this information is relevant in.

K

So what we want to go do and that's a proposal and I want to go and hear or feedback from that is add a namespace identifier to well top-level iom data so that you can say well. This is the namespace that I refer to and all the additional data that I have is to be understood for within this particular namespace and well. If we had this, it also helps us with some ambiguity and some additional requirements that we've seen floating around.

K

So there is a couple of graphs that we've even seen being read out here about limitations that you see with the current IO, am data field definition, so people dream off additional fields for specific use cases you can say well, there is a couple of fields in IO am today that are almost free format. We had app data, for instance, app data is 32 or 64 bits free format.

K

Well, so it depends on the namespace how you interpret that now. If we have a clear linkage to the namespace well, then somebody can say well, this app data means GPS geolocation for my Pacific use case, or it refers to a template ID like what the me IFA guys want, so that an individual note can say well, I updated just this portion of the overall data in the IOM feel as opposed to all the things or I can say. Well, this app data is to be interpreted as well into packet gap.

K

So if we have a clarification of this namespace I think we make it far more clear that certain things are really contained within a context, and so I'd love to hear more comments on that later on, as we go through the discussion, so that I think is the updates or the considered updates for the data graph. Then we have a bunch of encapsulation graphs and we briefly discussed them in the last meeting and they haven't really changed much above and beyond the discussions on layering. So we added a couple of additional notes there.

K

So we have an a capsulation graph, 4vx LAN, GP e, and the format is almost always the same. So we add the IOM data fields, just after the typical shim header that you would use for one or the other encapsulations 4vx LAN GP. We use the next protocol header and then you typically have the typical structure and I I.

K

Think I can't walk there because then the mics not working with me, you have an IU, am type you have the header length and then you have an indication for what the next protocol would be so that you can go and chain the whole thing in that's what the exam, GB and genève genève doesn't really provision for anything next protocol structures, but genève has the benefit or the ability to go and carry till these in its own header environment.

K

So in genève we're just using the available POV format capability so that you're using in geni, if you're, using an option class for iom and then the type is either one of the four types that we have in IOM: ie pre-allocate a trace, incremental choice and two and and to end or or approve transit. And so then again, you just slot in all the data that you would naturally have in an IOM context that we've done with the reformatting earlier on. In the last revision, the the IOM space is almost self-contained by now.

K

The same goes for GRE and with GRE I. Think that's the de-facto and the easiest way to go and do I am over r-e, for because all you would need is spend four bytes to go and slot in the GRE header there and then well. You can go on again dump in the before and from the IOM information. And what is new and just recently published. Is we have a draft for ipv6? By now?

K

The information was roughly out there because we had a an informational draft that we put out early on, mostly just to appraise everybody of what can be done to showcase that IOM can be carried in v6 options and well, if you read through the draft, it basically just says: well, you use the option of choice that you have in v6 the extension header to go and slot in the the IOM data.

K

So that means for a e2e you're using destination options because they're running into end and for everything else like incremental and pre-allocated trace, as well as P ot you're, using hop-by-hop options and well that's basically it so. We just need coat points for those things from six-man and some same just it's not gonna, be a just, probably because.

B

We're touching hop-by-hop.

K

Right and that's, but that's it and I hand over to Mickey for a discussion on raw export and then well. We can go and have a closing discussion on. Maybe the the namespace ID and other of things that Mickey's gonna go bring up. Think.

L

Okay, so rock sport.

A

K

L

So everything we just talked about was pretty much in the data plane. How do we carry all this fun? Io am data from one node to another node, you know. Eventually, we want to get it off the network, so this figure is just explaining what we think raw export is and why it's a problem that we're trying to address so the green on the bottom packets are going through a bunch of nodes. Some node decides okay, I'm I'm done with this stuff, maybe up the at the edge of the domain.

L

Take out all that iom data that we have now. What do I do with it, and we're saying that in order to really optimize the data plane, nodes and those IOM nodes at the bottom, we want to make the export as simple as possible. So raw export means we're basically taking chunks of packets and I OEM headers, stuffing them in a simple format and getting them off to some data processing system.

L

From that point on whether the data processing system does analytics itself or it then aggregates in or interprets or processes info and then punts that up to an analytic system, whatever you want right, there's there's many options for how to put the pieces together. So the goal here was as simple as possible for the data plane nodes, the exporting node does not interpret aggregate or reformat IOM data before it's exported we're offloading all that to the data processing system.

L

So when we looked at what can we do for the format of getting all this stuff off of the system? Ip fix is commonly used for flow related things today, it's more statistics, but you can also do packet, sampling and various things like that, and so we took a course look at IP fix and figure that it has a lot of the things that we might need and there's just a few extra information elements that we could add and then we would have a full format for doing all this raw export.

L

One thing I note just the bullet on the bottom: that's not actually in text it's in the draft, but depending on your implementation, if you're highly optimizing the data plane, often in Hardware you're, probably not going to support the full flexibility of hey, you know tell me what template you want and so on. You may find that implementation does a small number of fixed formats that it can highly optimized and that it will adjust alignment constraints and such so that it can process that at billions of packets per second.

L

So among the IP fix information elements that already exists that we can just use. We have an IP header packet section and note that an IP header packet section it starts with the IP header, but depending on the length of that packet section, it can keep going into various headers after that, including possibly IO a.m. that is embedded within. You can do the same thing with Ethernet using datalink frame section and there's other things. There's a section exported octets and forwarding status. If you're reporting drop packets, then you'll find forwarding status of great interests.

L

Basically, the first three bits are telling you did I forward the packet that I drop. It did something else happen and then the next five bits like if you're dropping you can give you can specify why the packet was dropped. So what we wanted to add, we wanted to add a few information elements. So one is report Flags. Maybe that should be renamed, but it was just trying to give a kind of the broad categories on why I want to report this particular info, so did I drop. A packet did I see congested queues.

L

Is it just a fro that matched a Knakal or something else I said: hey I want to know about all about these flows, encapsulation type, if it's none, it's just a pure.

L

What's in the data draft, if it's one of the others- and you start with the shim header that Frank just explained in the various end caps, you go continue on into the I um data and possibly continue after that, and when you have four data chunks corresponding to the four type shion's of IOM that we have today the pre-allocated incremental and an edge edge and proof of transit.

L

So once we have all those it's up to you, how you want to put them together, but we thought it was useful to list some examples of how you might layout these information elements in a template. So of course it's not mandated to use exactly this template. The simplest way to go would be to only have we have most of the info, just in an IP header packet section, and then it's long enough that it continues on into the IOM data.

L

After that, you still may want things like report flags and maybe a forwarding status other than that you you throw a length on it. You're pretty much done another way to go. You could use the IP header packet section just as more for the outer fields to tell you what the flow is. You can identify.

L

What the flow is that you care about and then pull out some of the IOM and phone put it on top and you can do various combinations of which things are fixed length which are variable length and so on, so that pretty much covers. What's in the draft, I did have some questions and I sent a more detailed message to the mailing list, but these were more around. There are certain fields.

L

If you look at the definitions of information, almost like IP header packet section, they had a certain restriction, so you have to put things like section exported architects. In certain cases you may or may not be allowed to put padding and it just seemed like you could cut out a few bytes if we updated those, but that's kind of an open question. Can we change the definitions of fields?

L

Basically, if you go to the ANA registry, you see all the stuff today.

L

B

So I'm just gonna go ahead and get in line because me so I, Brian Trammell, um not as chair. Actually as one of the designated experts for the I Anna IP fix information elements. The short answer to your question is: read: RFC 7013 and dry again, the most of the changes that you're proposing here are non interoperable with existing implementations. As far as I see, right, like you, actually likes relaxing restrictions that might break collectors that are relying on those restrictions. However, this is not a very scarce number space.

B

We have it's like you, get 15 bits and we're down in the 400s now so um so you're.

L

Saying if there's enough of.

B

A win it might make sense to do IOM specific packet section by ease right so design. What you want. The downside is that you know existing collectors will have to then get the update but you're talking about changing a definition that might break those existing collectors anyway. So it's the same amount of time for the existing collectors. Update. Okay um through is data line frame section not deprecated. I thought we deprecated that one I, let me go actually have a look at the at the I was.

L

B

Yeah, it would have been, it would have been deprecated along. Oh no! No! No! No! No! Sorry! No, that one's good! No sorry that I thought it was a section offset. No, that's fine, yeah um yeah! So short answer, read: 1713! Okay, um slightly longer answer: reads already: thirteen, and and really consider whether you want to reuse these II's, because I don't think you can tweak them to be exactly what you want. I think you can basically create new ones by reference.

B

Like optimizing them will break them. Yeah.

L

This was all optimizations, it's a few bytes, it doesn't rate break the underlying yeah.

B

Right, yeah or you can, you can also use suction, offset I didn't see suction offset anywhere in the document, so yeah actually I thought.

L

B

L

So take a look. It.

B

L

In there, yes, it wasn't clear to me that it's a big win in terms of Freight.

B

Yeah intergrate did actually I. It slows you down quite a bit so yeah. So a little bit of history like this was all done for for a completely different effort, called PCM yeah.

H

B

So it was kind of optimized for that, but not really um so. Yeah I definitely consider whether or not these are really what you want, because the what what you're trying to do to take the IOM information out is semantically different enough from just random parts, the IP header that it might make sense to define to do ie anyway. It's not that big a deal so I guess.

E

I mean you're already.

B

Defining your I using the document so one more long, really great think yeah.

L

B

H

Million elkins ever two different kinds of comments, one functionally and I'm from a higher level. This is extremely cool, very good data in a you know that if we can kind of like I, if I'm understanding it correctly, you're gonna grab all this stuff passively and then search and just take the IOM data, which is very cool yeah.

H

But you know there are a lot of enterprises have huge passive data capture devices which are taking the whole packet, no I'm, saying and and I'm just I'm just thinking this stuff out in my head, so I'm just I want you know: do you have a you want to talk about that to think about a little bit or discuss or offline.

L

I mean the thought here was that you're getting iom data at your edge nodes, whether they do any stateful processing to figure out which things they want to export, which things they just want to don't want to export because they think it's redundant, that's always an option. Usually you wouldn't do the entire packet.

L

You would do some chunk of the packet, and you know they're already words and like those IP hat or any packet sections and such that you shouldn't do the whole packet, because it's security and this and that and so on it refers the various documents and discussions that have been done earlier.

L

I'm, not sure if I answered what you're like yeah.

H

Yeah we can talk offline, I, guess what I'm saying is on a lot of enterprise networks. There are huge packet capture devices already that are capturing the entire packet, including the I/o I, mean, of course, I mean the IOM data comes with it. It's just. What's that huge packet brokers? You know having said that, having said that, this is very cool, because you know you're not having to filter and stuff, and it's just the data you want. Is that kind of your point. Yeah.

L

So yeah the hope was to do this somewhat intelligently, that, based on the data that you were receiving, you could actually decide what you want to keep and what you don't want to keep just.

B

Know we are running up on our time here, so let's cut the line and make this quick yeah. So this is I'm relaying jakob Stein who, as you know, job or who is basically raising the point that any time you're taking bits of packages they're flowing by and exporting them that may raise serious security issues. I'll also note that the on that point um when piece and went through the whole process, there were a lot of 2804 concerns.

B

So is this wiretapping or not right so be be prepared in sort of the later process of this yeah.

L

I mean Russian.

B

Will be asked the.

L

The quick answer was to take exactly the text that P Sam did in the IP header packet section and frame section, but we are whether that's enough we'll.

K

L

Discussion that was yeah.

K

Yeah and I think to the earlier note- and this is why you have this two-step approach shown in one of the diagrams earlier right, so you strip the information off the packet and then you might propose or further process it and that one step taking it off and and handling somewhere else might even be in a contained same box still right and that might mitigate some of the security concerns, but it might not be lay the same entity.

K

Iud couple data plane and maybe the brain or the control, plane, portion and I have another question: can you go to the final slide? No, no one further just quickly chat about next steps. Please yeah yeah.

L

Okay, so so next step, so the I um data draft has been fairly stable and there's a question whether we're ready for a working group last call.

B

Does anyone object to working group last call on IOM data?

B

Alright well, go ahead and start one. Probably after this meeting I mean I, guess we can do it like right now, huh wait.

K

So the name splays identifier- we still want to go an all.

B

M

B

Yeah so um yeah crank crank the revision and ping bitshares, um maybe hard I'm going on vacation for this for a couple weeks. But Tommy knows how to yeah push the buttons so.

N

Just not on the data, but on the encapsulations, of course one is genève. Has the ethertype field for next protocol just like GRE does, and it would be nice if there's a rationale for them being different to have that articulated, because otherwise you're just adding complexity, I, don't understand yet why I'm sure there's a reason if, but please take a look at that, and also the packet format for the GRE version doesn't reflect 2890, which updated the base G re SPECT. So it should really do that. Particularly people are doing. You know implementation.

N

So minor points on the namespace question: how I I like the idea of namespace it also lets you do different administrative domains. You can have the ability to say strip out information when it's crossing a point, so I think it has a lot of power. It also lets you handle, say overly under play. Situations I think it's got flexibility beyond I'm, not sure you thought of it beyond.

N

Just clarification of the meaning of the fields involved. I think it lets should do some really useful administrative policies.

L

So the encapsulation draft, so three of them have existed now over meetings and so for those three. We were wondering if we could call for a working group adoption on the vehicle and GPE Genevan GRE.

J

Sure is that someone want to do a list. Let's take that question.

M

Cool even I should have prepared better I guess, but it wasn't the original plan to bring this to the working group so actually work on those protocols.

B

Yeah, so the idea was to bring them here, because there was not a whole lot of interest, but to have all of the discussion echoed over to those lists and to have the working group last call also split out into the to the appropriate working groups of encapsulations. It's basically is the encapsulation here, but the point of the review here is to make sure that it all works well with IOM and the point. The review there is to make sure it isn't break the end caps, where.

M

Those draft presented at the respective working groups already.

B

Frank, can you speak to that.

K

So in Geneva we add that discussion GRE not so far as far as I know our v6- definitely not because that's brand new, but again so that the problem that we face and we we started the other way around right. Nsh was okay, the genève people in nvo 3 I'm, not saying that they couldn't care less, but there was a load of not a load of energy. There. We talked to the list guys on the Excel and GP and the lights.

K

The problem is that you typically start from scratch and explain all the contacts and then you a load of questions on IOM as opposed to we need a coke point guys. All we need is a coke point from you guys, and so we thought that that's mature it here where people have the context and if people in I ppm think this is okay, then we go and well discuss the protocol related aspects, but not the I um related aspects with the respect of Winkle I, think that was the rationale because sodding the other way around.

K

Well, you present and then next one right so.

H

K

Don't have the contacts that might not even care about the contacts because they don't care about ivy. I ôm right, because there you have yet another person asking for a coke point and that's okay. As.

C

Far as adoption here you're just discussing- and I think we can follow this up on email or on the list, but he would make sense probably to at least make sure that all of the other groups are aware of that, at least in some form, before we adopt anyone other given draft.

C

So if we've already talked about genève, maybe adopt that one but let's, but if we want to do them all at the same time, let's make sure that all of the relevant groups are aware of it, at least before we continue work on that right, including six-man yeah.

E

Thank you, okay, yeah yeah that'd be great. Please do that.

B

C

Okay and we should get moving ahead on our schedule, if that's okay,.

C

N

As frank, it said point a point of and they're moving us here, so you get the focus. I don't think that, due to scheduling etcetera, that there's been a lot of looking at the impact of some of the Appalachians but they're like the impact of it, it sort of be nice to at least get routing directorates, or you know RT gwg or this kind of thing, I, don't think. There's any concern, I, don't think. There's a territory argument about!

N

Oh here do them there I think consolidating the work in one place with people who really care about is clearly being very beneficial for the work it's getting the eyes on, but doing cross adoption working group adoption calls or something would be helpful.

N

The excellent GP is interesting because, as far as I know, the excellent GP isn't standardized or being standardized, there's, not an RFC for it. It's explicitly their will. At some point, I mean assuming that nvo 3 does what we agreed on a while ago. Eventually there will eventually be an informational document saying the excellent GP. It was a choice that was not selected to be standardized, but I feel like it's different.

N

N

There's not a it's anything that type could point. You need an ether type once you have an ether type, you can do all sorts of fun things right. It is, but but that's the piece it's going to be complicated for the excellent GP one. That's also at stake. So on.

M

So I think what we need to do is I. Have a look. I need to have a look at all these documents, because I didn't, but for for the I think it's actually just the decision of the other working group to redirect this work to this working group. It's not that we can decide it over here, so it probably makes sense to coordinate between the chairs and the ATS. What to do but I mean both is possible right.

M

You can like the question is where to actually adopt it and right around the formal process but like having working a joint working group. Last call and discussion can also have them in those groups where, wherever there's more interest like, even if you get it adopting the other working group, you can still presented here and discuss it here.

K

M

Recommended me.

B

M

B

Was before you were ad so I mean you can.

M

It might be no, the promise might be recommendation. It might be different recommendation for each of these documents right, I, think for actually for six men. The official recommendation is to have it not in six men right right that yeah.

B

We already had that with uh with video, so.

M

It's still the case that you should go there and let them know that it exists, but we can do it here for everything else. We have to check on.

B

M

B

Okay, thank you very much and reminder for people on microphone discipline. Please state your name. There's been some confusion in the chat room. So Giuseppe. Can you put yourself in the queue here we go all right um so.

B

Hello, hello, yeah, so just uh yeah we didn't get the request in for remote presenting. So if you can just tell us next slide, we can we can do that for you, okay,.

O

This is an update of the multi-point alternate marking draft, so we changed to works on things after the long term meeting. So the disease's light gives you a recap about the document change. We moved from 0 to 2 0 to version and then to 0 4. We got uncomment after Londo meeting I want to thank algae, Intel Rachel for the feedbacks, and there is a list of the main points that have been modified in during the last batch.

O

So in summary, we detail better the description of multi point approach, the example of the cluster, the algorithm for cluster partition. We have more details from delay. Particular there are a two way of my measurement one that is, there is multi-point cut very this approach and the other one that is based on single path bases, and then we add the new section on timing aspect that extend the corresponding section of air FCAT. 321 I want to thank thanks, Alfred these quit bullyin put so next.

O

So in summary, multi-point alternate marking is the RFC a treatment, one development.

O

So this is an announcement of this refseq, because the arab CH 321 is valid seems to be valid only for point to point, but in this draft we want to extend this definition or any kind of unicast rules not to Monica's not are not multicast but to any kind of unicast pros, but in general and multi-point to multi-point probes and in particular the multi-point alternate marking approach adds flexibility to performance management, allow an Orchestrator to control and in particular to enables the dynamic, dynamic performance and monitoring, because there is possibility to configure the desired performance measurement statistics depending on the needs and on the status of the network.

O

So next yeah. This is the basic base idea, that is the cluster pack across general. If we have a multi-point to multi-point network, we can find the partition of these networks with sub networks, and the clusters are the smallest sub networks, where the packet rows property is valid, so pocket rows. Property means that the number of packet incoming are equal to the number of out to in path.

O

So, in general, the network clustering approach is very useful because without a natural clustering we can monitor only the entire network or single probe. Otherwise, with network clustering, we can use the natural caustic or Ethan to perform the needed degree of detail. So we can make clusters zooming on the network, like a figure. Next.

O

Okay dislike so a simple algorithm cast a partition, so this is a new paragraph that handed.

H

O

Some comments received so in general there is a two step powdery. The first step is to group all the links where there is the same starting node and the second step enjoying the cupid links at least one ending node in comma. So in the figure we can see that all the nodes we put the first step, we can have five groups and with the second step, the group number two and group number three join you to have the cluster, so in general that in that net multi-point partner, fine.

O

This is just to give you an example on how to apply these to step out during next life. This is a very new section that has been used after being from owl in general. Of course, if we have a lot of source nodes that mark our topic, we can have an alignment in marking intervals of each marking the nodes, because in general, if we have an endpoint network, we can have multiple marking nodes. So we have to define the measurement intervals, and that case we have to consider the misalignment in the timing that consideration.

O

So if we, if we want to talk about the precision of this methodology, we have to consider these alignment between markings of structures in terms of different lengths of the marking intervals and different offset, and you know that marking method need to work that the available continued interval will be greater than zero.

O

So, if we consider the the misalignment of between the marking nodes will be added to the deal that already includes error and network delay, the condition that must be satisfied that must be satisfied is always the same and is that the available contain interval must degrade, and this give you the new conditions that make multi-point marking metered useful to just in this conduit.

O

So next, okay, these are described the measurement approach that can be distinguished into two possible ways of measurement.

O

The first way to perform the delay measurement is a multi-point at basis measurement. So in that case, the delay value is representative of the entire multi-point path. This means that example, that we want to apply the min delay. The min delay is difference between the mean time stamps of the set of output nodes and the set of input nodes. So the mean clay is representative of boot appointment. Otherwise we could. We can apply the same measurement on single packet basis measurement, so it became a point-to-point measure, but it is based on the multi-point path.

O

That means that multiple paths just use Erdem that aid to couple the the samples between input, nodes and output nodes, single marking based on Priscilla's packet, cannot be used because the batch boundary not valid in multi-point approach. Double marking were neglected, marking words the little limitation at the time, detailer laughs, but there is no time to explain this.

O

Hashing is a more general solutions, because clusters simplify the coupling of symbols and marking meet or done called the table to a specific rapidity go next, so this slide details a little bit more about hashing sampling, so that is detailing into FC 5475.

O

The combination is to RFC give an easy way to perform the delay, because we can use the basic cache so methodologies, where they alternate, marking split the continuous flow into marking batches and these anchors, the hashing samples for for each video. This is simple way to apply the aschen methodology, but to utilize a cache in a number of simple depends on packet pre.

O

Otherwise, we should use a sort of dynamic cache that can be applied with an iterative value it where it is possible to use a number of sample is almost constant or each marking period and detail of diesel. Karate vulgar and statistically converge for each mark Imperial to a value to a constant value of over a simple, also, in that case the iterative algorithm in detail within the draw. There is no time to describe so next.

O

This is a typical use case. We have also mentioned in.

H

O

Summary of this presentation, so in.

H

O

Multi-Point or ultimate marking allows a flexible dynamic. That's the end of the performance management, because, if you have our the controller can configure a row row performance management so without examining, and only if we we experience some pocket release like you can go in deep and we can detail about filtering criteria and cross the partition in order to perform a detailed analysis. So this is the what we means for dynamic performance measurement, and there are two ways: one way is the filtering and the other way is in the faster cause.

O

Cluster can be also combined between each other. So next, okay, just the last slide that so this methodology are the new points of you to do ultimate, marking method. It adds flexibility, dynamic performance measurement, Nichols or use other techniques that are actual technique, for example, that is not so used, but the coupling between ashing technique and multi-point ultimate marking is varied, and that, since that we had a lot of comments, we want to ask for working group adoption.

B

So hi thanks, Giuseppe I, don't think we're gonna one calls for adoption this time around we're still trying to drain the queue, hopefully between now and Bangkok, at the latest, at Bangkok cuz. She a show of hands here. Who's read these records draft okay, so we have a few um I think it yeah. It seems it seems perfectly reasonable. It's doing adoption call, but we do try to keep the sort of the docket of the working group a little bit.

B

Slimmer, we're gonna get um so there's one working group last call that's done we'll see if we can get another one out, I think stamp is getting pretty close to done as well, and once we get those out, this will be next up. Okay, okay, cool we'll keep working on it right, like I, mean there's the there's. You know if running it through and then adopting, and then you know we can also adopt and do a relatively quick jump to wgl see as well right.

B

So it's the thing is not to have quite such a big list of currently active crafts. So alright. um Thank you very much. Okay,.

O

Thank you, Thanks.

B

So no meaning, if you come on up, we are running sort of like a bunch of minutes. We give you a 15 minute slot. You have 14 minutes max. If you can go even faster that'll. Let us get to even it at least one of the Lightning talks, which is remote, so yeah.

H

Okay, this one hour, this draft combines the marking, method and also PDM, and the reason we did it is because PDM is in two end and marketing has airing marking needed to be v6, v6 stuff and we wanted pass stuff. So these are the PDM fields. That's that's RFC 8250. I believe we already have it and that's the end-to-end information and you know you can get the round-trip delay. It's all in the destination options header, but what we don't have is the one-way path, delay and or the middle box stuff.

H

So marking has some real interesting things about. It is that you can batch packets together and look at the timestamps and stuff, and you and you can do average packet delay so with giuseppe. We were talking about it and it looked like this might be a way to meet both our ends. So now, I'm gonna stop talking a little bit slower here. This is actually the only slide, that's worth looking at sorry Janell, but this is the only slide. That's that's of interest. What this has.

H

This is the hbh header and you can see the top part and, if there's a pointer here, the top part as the the marking stuff, you can see the marking, the marking type and the reserved field, and the idea is this- will go from middle box to middle box, whatever you consider a middle box to be, and we've all thrown that around a bunch as to exactly who is going to update this, what we want is to know when I say we I'm talking about the you know the enterprises that I work with and some people from ISPs who've looked at.

H

It say this is a quite a deal of interest to them as well is like as it's going along the hop. Where is the packet getting messed up? Where is it stopping who's who's doing what with it who's the last guy that touched it? That was of interest, and so that's. What's in here, we've been through a bunch about what exactly middle box identify your means, we're very open to yeah very open to comments on that.

H

There is a protocol called MB TLS or some call MC TLS, and it's it's a relatively immature right now, but they've got this concept of a middle box identifier. Some people have suggested the ipv4.

H

Address but I don't know how you get that in a 16-bit field, but anyway, we're will open real open to that Brian yeah keep going yeah, we got it, you know they say this is the only one of interest we room for five middle boxes. It'll wrap around the last EM field is the last person, the last middle box who identified so you can quickly hop down to updating the one that you've got that we're putting this. This is not gonna. The packet length is not going to change. The source is going to put out.

H

The whole thing is a no field and then every metal box along the way. It's going to say this is who I am. This is when I got this packet. This is real data. This is the real packets. This is not a an active test. This is hybrid measurement. This is not a test packet I mean you could devise a test with it, but this is real, live actual data, and so he'll just say this is when I got it and and of course you would not want to do this all the time.

H

We're envisioning you do this. When you have a problem and then of course people say yes, you have the problem and then you've just exacerbated the problem by adding all this data and yeah. Okay, I know I know, but it's still I think could be super helpful. So yeah any comments on this thing. Hi.

B

Sarah I'm speaking as individual I had questions aren't so like PDM. The scope, and here is single administrative domain right. So you could essentially you remember, box identifiers can be assigned by configuration by Fiat or by some central controller, correct PDM.

H

Is not single administrative domain bTW PDM is the is, is internet wide? This could be single administrative domain I. Would it be, as I said, I've already had people from ISPs say this would be very cool and they would like to have it so I would I would hope. This is not single administrative domain. So.

B

Middle box identifier needs to figure, it's gonna, be simple: that's gonna be outside single minutes later. The main middle box, identifier needs to be bigger. You're gonna need some way to do.

B

Iii almost kinda want to just say, read the plus drafts and do that instead, but you're gonna need yeah, you need to be bigger. You're gonna need some way to handle integrity, protection and you're. Gonna need some way to like if it costs the administrative domain, where you're not really sure who's gonna be messing with the stuff, then you need to go a little bit more complicated than what's here. I have another question: just really clarifying I'm gonna try and make this real quick. So we can get to Ignacio.

B

Why are there pockets serial numbers on each hop? Is that like a count of the number? Is that like a pocket counter of the number of packets? But it's seen or no.

H

No, it's kind of like you know the packet number, it's like our packet sequence number. What this tells us is how far this packet get for it got dropped essentially, but.

B

It's the same for a real opera know.

H

P

B

Keeps it keeps a packet sequence number like it goes up by one for every packet. It's a it's, a okay, okay, that make sense.

H

It's yeah and in combination with marking cuz, if you got a block, a packets, no I think it's anyway. Anyway. We, yes, yes, yes, yeah.

K

Are just echoing some of the stuff that we've had to deal with timestamp? What kind of format are you gonna go use, yeah.

H

I know I know this is yeah version, 0 0.

K

I'll be nice to go and get these things fleshed out. Yeah.

H

Yeah yeah yeah, no, as I said we're putting this out, and you know it's getting feelers getting feelers from everybody. It cuz I. Think our first thing is: do people think this is useful and then and then we'll continue work on it? That's that's kind of where we are right now. If people think it's useful, we think it is, but we want to do long. You know validity testing yeah.

H

You can comment to me privately if you want to okay yeah, but we're also real open to collaborating with you know, Frank and and that's what then, you know other people too and whatever any comments. Otherwise them will let some other people have a chance to speak. Okay, thanks.

C

All right, thank you. So much yeah I think there's some comments. It does sound interesting, but we just need more fleshing out.

B

Please say comments the list so um Ignacio we got you five minutes, go ahead and pull it up. So um here he comes good yeah.

Q

If we, if you could put because this is okay, thank you well just this is a proposition to get synchronizing internet clocks in secure way and who is needing which application measurements. Our our working group localization cryptic coins games, and there are surely another applications next please well. This is this chart represent more or less the road that you can get in different protocols, and the idea is our protocol is the green one SiC you can get frequency synchronization in some kind of secure way. Next slide, please!

Q

Well! The idea is that it packet it sign it in a different way.

Q

Their role is around 20 microseconds, we synchronize frequency and it's a client-server, a simple software distribution, but if there are symmetric part paths between server and client, you can also do an absolute clock synchronization, and this is related with the another draft that we we got here.

H

Q

Other one and you can clone you, you can get the code of the the idea in that link next slide. Please, and this is the updates that we we got from the first to the second version. New router is added through the gap we stress at the frequency objetive and we compare with the IQ related standards and we provide detailed information about security issues and also an example of some kind of limitation in with ntp in some rationals of the internet. Well, this is all I, don't know if I can get the question or not.

E

Could you beat that.

C

All right, no questions at the mic right now. Thank you.

B

E

Sure we have time for the next one all right.

E

Chanin just.

C

Very quickly you have to which one do you want to give being man all right? Let's hear that.

D

This is the young leader model for Iran. Last time we presented this in London and we have several comments from Greg and the Rashaad, and we make the for Iowa option profiles as features for flexibility. We modified the ACL live reef to align, waster is their latest ACL model and we add a demean configure container for a clear hierarchy.

D

Noaa also modified the security considerations into the ionic considerations. Here's the overview, the Iowa madhuri is organized as a list of profiles and each profile associates one a flow with the corresponding Iowa information.

D

We use the filter to identify a flow and there are four sub profiles, each of which relates to a one-hour mean capsulation types as defined in the Iowa Nevada draft and the Marco Island data types can be encapsulated into the same I-I'm header and sub sub profiles, including the pre-allocated, the trace and profile, the incremental tracing profile, the proof proof of transit profile and edge to edge profile and for the the we imported this proof of trusted profile to actually from from this proof of transit document, and there was a discussion in the Middle East whether to incorporate this profile directory into this era.

D

Miyamoto. Finally, we discuss with Frank and we we decide not to do this. We decide to live, live it separately and independently and then next we welcome more comments and we also hope this can be adopted as one Google document as the Ahram data Java is already stable.

D

B

All right, thank you very much, umm IOM folks that sound like a plan. Okay, um so.

K

I mean yeah finally, soft nurse yeah I do like that word, given that I'm co-authoring, so I do think it's useful and it needs to happen and we need something configuration for IOM all right and well that's the game in town. Let.

B

Me ask you another question: would you be scared if the chair is imposed an experiment on your yang model by Fiat um we're looking into using github for Frank model development, as opposed to the document stream for inside the working group, I've been asked by some of the net rod people if we can try that out, I have no idea what it is. I'm gonna find out what the actual details are on Friday.

B

um So, if that's, if that's not scary to you, then we would try that with this, when we yeah right, yeah, okay, so well, yeah well we'll try and bring this in with the other gigantic pile of IOM documents sometime between now and we're gonna count, but we're gonna count all the end. Caps is one document against the document cap, but um because otherwise we'd never be done right. We have the phrase condition on the number of documents that work so yeah. So um we're not gonna.

B

Do the call for adoption now we'll do it with the rest of those we're gonna look into how we would manage the TN model with this new process that I don't know anything about. Other than github um and from there cool all right, thank you very much that was IP p.m. we will well I. Won't Tommy, we'll see you all in Bangkok.

C

And for the lightning talks that we did not get to apologies for that, and if you want to send out any summary of that information to the list that would be appreciated as well and.

B

If you haven't signed the blue sheets, keep please come up and sign the blue sheets.

B