Internet Engineering Task Force Interim Meetings, 31 Mar 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: 6MAN WG Interim Meeting, 2020-03-31

Description

6MAN WG Interim Meeting, 2020-03-31

A

Good morning,.

B

C

C

C

C

C

A

Morning, everyone.

D

A

Good morning Bob oh yeah I'm having my coffee, I'm, good I,.

A

B

B

B

B

B

B

B

B

B

B

B

E

E

E

E

E

E

E

E

E

E

A

A

A

A

A

A

A

A

A

Hurt you I can hear you ooh.

F

A

A

Mute. Thank you.

A

G

G

G

G

Lo, you hear me.

H

I

You so everyone feel free to join the jabiru and ensure you write your name in the blue sheet, which is only the pad if you can get all that working before we started finding this time.

I

I

I

I

I

I

I

I

B

B

B

B

B

B

D

D

D

D

D

D

D

A

A

Good morning, I think we'll get started now.

A

Welcome to the six-man virtual intern, we're not sure if this is IETF 107, but since we didn't have a session at ITF, 107 I think we will start soon. You can hear okay.

H

We can you okay,.

A

Good yeah, so I think we're gonna try allowing the speakers to turn on their video.

A

In addition to the slide, oh, that works that that's causing problems for people. We can stop doing that. Okay early next slide.

I

All right, so these are sort of virtual meeting notes taken from the rules that is, she gave us. This is the first of with scheduled two sessions idea, idea hundred and seven I will see if there will be. We have just gave you one now, we'll see. You know from the experience here if there's interest in doing the other one as a virtual one as well to get into the microphone queue we just fit 2 plus Q into the WebEx chat Q.

I

If you want to remove yourself and that's the only thing that the WebEx chat, that I use for everything else goes into the into the jabber room, I, don't think we will do any harm so consensus taking on the mailing list. Of course, we'll have discussion and bring all the calls to the mailing list. After this meeting, I have phones when you're, not speaking, remember to state your full name. When you are speaking, the blue sheets go on to the ether pad.

I

The link is on the presentation, or it's also on the agenda agenda in the data tracker, as well as all the materials. If you want to see directly for yourself so I think this is the first entry meeting we have in about 20 years last, one was in Grenoble if I remember correctly, isn't that right book if.

A

You catch about right, though it's the first time, we've done a virtual, you know one the previous ones are all face-to-face. That's.

I

Right and so denote well my place as it always does tonight. If meetings we have the jabber ian, I see not a rule. It's very useful to be only for this meeting. I think so. Please join that. If you're able to Barbara's taking notes for us, Joel Halpin is doing jabber scribing and the presentation link is there and again find the blue sheets.

A

A

We're doing the introduction, jen is doing a talk, I mean we're first doing the working group drafts and then for active internet drafts go through Jen's, creating neighbor cash increase on first up routers we're going Fernando is presenting the the best document for privacy extensions.

A

This is in in work, call we're hoping to get to the point of closing, lit out and there's also the operations and maintenance segment routing graph. That's also been working with glance call, and then we have four individual graphs, the minute marking extension header graph, the transmission over multi-link network interfaces. The credit is presenting improve robustness, stateless sort of configuration by Fernando and then also a problem statement regarding IP address usage, also by Fernando.

A

A

Okay, all I do and do.

I

It the next one, yes and that's the document status.

I

So since the last IDF we have all published one RC I was bit long in the tooth, so glad to get that one out the door, that's RC, 87 54, which is the segment routing header for ipv6. We have two documents in New, York see a tricky. It's the ICMP limits document and the pref 64 in our a document.

I

Suresh was very good at cleaning off his backlog before handing the baton over to our new lady, every clients of South America. So there is nothing submitted to the is gene or their history. Anything in the IDF last call.

I

We have two documents in working group last call both on the agenda today. It's the privacy, extensions document, RFC 49 this and it's the OEM for same and routing document I also have two working group documents. Currently it's the path into you hope, I hope option which is not on the agenda and it's to be just neighbor discovery, which is movie agenda.

I

Yes, I think that's all from the chairs. It's just a reminder of the new document format. We have also pointers to the d-type experiment. We're running with regards to like each have experiment. We should even that's probably something we can discuss a little bit more on the mailing list. Now that we have a little bit more information on it, so I think the next one in the queue is Jen. Do you wanna come up and stand in the pink box? Please I.

G

Could explain Duncan zip in the box I am pin box. Can you hear me we.

I

Can hear you perfectly fine great.

G

Sir good morning so creative neighbor recursions, the first hope routers I, am quite sure. Everyone has read the draft, but just in case next slide. Please.

G

Sir quick recap in case you have forgotten about what this drop is about. Actually, so it's a problem statement when hosts start sending traffic from a new address arrives to a router, maybe in the same router, maybe actually another one.

G

If you have multiple routers as that router might not her neighbour cache entry, was it Alice and the router is doing address resolution all the little packets except the first one are usually dropped, which is kind of updated, so the proposed solution is host could advertise the addresses using unsolicited an ace because apparently it's what neighbor advertisements for and routers might create a stale entry when they receive unsolicited mega, and there is no cache entry for that address next slightly what actually changed since last 8 years, when the draft was adopted next slide, please so not many changes.

G

Actually, thanks for everyone who commented some clarification test was added regarding a destination address of such an unsolicited, an ace. The current proposal is to send such an h2 all the routers multi customers. The reason is, first of all, it would allow the packet to reach all personally, because in many scenarios you might have multiple routers, for example. First hope redundancy where P between them, so routers host is usually st.

G

Jim traffic might not be in the routers return flow are going through, so mark has made my day a very good comment, which added to the text that actually increasing the multicast level significantly by doing this, because we basically making horse to send one- is the tane instead of a router sending multicast. In essence at least multicast address to address resolution, the basically replacing one multicast break it with another.

G

Also, if the network happen to have a modest look and configure that's even reducing the multicast noise, because such packets will be only sent two routers, not all hosts on link next, slightly mark also suggested that hosts might use RFC 68 and send ipv6 multicast packet as a unicast is a red packet wrapper same destination address or to the router MAC address.

G

I am Not sure it's a good recommend that at least solution, because again it might mean not all the routers would receive that packet, because in this case we basically relied on the host to know about every single router on real.

G

So it kind of introduces condition here and, as a result, isometric our traffic case might not be covered, because, if ro, if host, is using router a to send traffic and it would send such a sorry state, a nato set router the returned traffic going through another out there without the cover and the most interesting k.h.

G

It's cutting potential disruption. So I spent some time trying to look at how the proposed mechanism might break something, especially in case of optimistic, a duplicate address detection because in this case basically host might start sending traffic and Salem canceled his tetanus from an address which potentially might be a duplicate at one. Next, slightly.

G

So, first of all, if entry already exists on a router in any state, except in complete, no changes right, it will be unsolicited. A neighbor is overwrite a flux set to zero Salas the flux set to zero, so any existing entry will not be updated. What happened if the entry is an incomplete state, so it basically means that there is a rightful owner which is on the network just saying in return tracking just arrives and another host. Let's say: host B join the network and start sending unsolicited 10 days before a dad has completed.

G

So would it cause any disruption? Next,.

G

So what happened normal right before we implement the proposed mechanism, so it will statement draft explained we have a kind of packet loss for period between the first packet arrives to the router and the router received solicited ma from a address off next slide. Please, if we, if the host wiki that address, starts engine cancel each the Tenet's and router updates neighbor. Currently what happens during the time new and might be created until the rightful owner responds to a name like in this case the MP will be updated with rightful owner.

G

Mac address said to read: basically, I do not see how traffic can be interrupted, so no changes here. That's a good news. I have not actually updated the text in the drama, but I think this scenario might be clarify it a bit more, so it will be a 0 1 next slide. Please.

G

The summary is incomplete and no changes. The traffic will be restored as soon as the rightful owner responds with sunny Stephanie next likely.

G

The most interesting corner case is what happened if there is no and disruption happens. So after a discussion of the mailing list with Pascal I realized, he ate with a draft probably needs to be clarified, and this is actually a corner case. I'd left the group. So what happened?

G

If there's a rightful owner, let's say, host a which has an address it hasn't been sending in it received any traffic to the router throughout them doesn't have, and it was that address and that host just wakes up and starts engine condition in traffic exactly in the same moment as another host I came and configured the same address in optimistic step. Next, like this, so without unsolicited a is creating any entries on the route. What happened here? Router sends multi customers. It's a basic.

G

The moments me and router start dropping traffic, all packets arriving for the address a and it creates an incomplete empty.

G

If you have two hosts with the same address, one of them in an optimistic state, both hosts will respond, and even if the host beers on the first and it would create a ritual entry in the router as soon as rightful owner responds as the entry will be updated and because that enabled have other overwrite flag set to one and from that moment of time the connectivity is restored all right. So it's a normal behavior how it happens now next slide.

G

So now everything might become slightly complicated. Let's say: unser Easter today managed to arrive before the first packet arrives to the rotor.

G

In this case the stale entry will be created and if that fails during the delay phase, because as soon as packet received, the first packet arrived to the rotor and routers trying to send rocket the entry will move to delay state because that would normally detect the failure in one second right. We can expect that that failure will happen during the delay. Spec right in this case, the worst case scenario shot sent. Any customers would not get any response from host B.

G

Then it will switch to sending multi customer and from moment the multicast and SS, and they basically going back to the original scenario. So next slide. Please.

G

Worst-Case scenario might be the rightful owner might experience delay up to eight seconds again if events happen. At the same time, the owner has been receiving any traffic through the router, so there is no cache. Entry and duplicate address happened before the traffic arrives to the route. By the way, I have a question to the audience. Do we know if any router implementations actually using the data plane right? If you move and tree frog delay to reachable next slightly.

G

Because in this case, it's actually quite bad scenario, probably if the entry got into reachable stage that obviously the delay will be much longer to restore the connectivity but I have not seen or outers actually doing this right. My impression is, they do not normally watch for data play traffic, so I'm not sure like. Is it corner case bad enough? So we should not be doing this. Oh it's way too many things happening at the same time. The probability is quite low. I.

G

Think next slide, please I think that's all I have so yes, I, said I think there is a one scenario: man proposed mechanism might make situation worse, but on the other hand, it's a quite a lot of things happening at the same time. Yes, on.

I

So is there any questions for Chen.

I

It seemed like a very quiet room, and so we discussed this draft both on a mailing list and in the last IDF and I think and Bob and I have spoken about it and I think the plan was to take this fairly quickly through the through the working group. As far as we see it, we believe this is ready for a working group.

I

Last call: are there any objections to that to do any anyone see any problems taking this draft fairly quickly into working with last call, and if you have a question, just put the plus Q into the WebEx chat, and we have.

G

One comment: so we have basically two drafts right, one. It's problem statement on a which is in v6 hopes and another one. Is this one so I not sure, but I think maybe it makes sense to have the joint last call for bosses in because honestly, Fred it'll go for the last call for problem statement, draft and v6 ops until we going to the last call with this one, because let's say we decide that this solution is not good enough right.

G

So there's a problem statement draft which actually talks about various solutions and proposed one in particular might need to be changed. What do you think.

I

Well, we could certainly last call them together. I mean well yeah, I, guess. Typically, the problem statement would get go before the the solution document I believe we discussed as well. If it was necessary to actually publish the problem statement.

I

I mean we can certainly talk to the v6 upstairs to see if we can coordinate a working group. Last call.

G

Because, basically, let's take problem statement graph, discusses various approach to the problem. Right we can Pizza router or we can suggest the router should actually use a data plane traffic to trigger neighbor discovery for himself all right if the router she's a data plane traffic flow for from the address which it doesn't have a neighbor cache entry right, actively resolution and so on. So there are various also could be done.

G

So I think this should be published, because it's explains why we suggest in exactly this mechanism and not something else and actually those drafts to so currently. At the problem statement draft refers to this. One is a normally from this. One hesitates a informative reference, because I think it's simplifies things so the reference to each other. Okay,.

I

Super we have worn the cube, and then we have Phenom do afterwards. Warn please thank.

J

You Warren Kumari I, just want you to reiterate that this problem was originally discussed at v6 UPS. The issue was raised and v6 UPS. The consensus seemed to me. Well, that's a real issue: let's try to fix it. No actually it looks like six man's the right case to do it. So you know just six UPS. These except seems very supportive of the problem.

I

That's good, you know thanks a lot I'm wearing a hanbok, please phenomena go.

F

I found that the other document of in was quite useful as a companion to this one, so it must be. It might be useful to do the two together, or at least even if we don't I, would like the b61 publish to.

I

Okay, good yeah, let's okay, so I, think Bob and I will take an action into to coordinate with with v6 ops and we'll take this to the mailing list as well. Obviously, but it sounds like we should go ahead and who didn't you working with last call I'll.

A

Just add one thing to this: I mean there are lots of funds in the ITF we're developing requirements. Documents is very useful to figure out what we want to do, but they don't always get published. Sometimes it's harder to get consensus on a requirements document than it is on the actual and actual solution, but we will certainly talk to the v6 upstairs and throughout what they want to do and Warren.

I

Will get the last word on? No, he drifts microphone line. So then he will like they will move to the next presentation.

A

I

So Fernando you are up for the 4141 base. Working group last calls status. Please yeah.

F

Thanks good morning or afternoon or whatever applies to you, so this is a presentation about the last update to the 49:41 B's document next slide, please so as a kind of recollection of the recent history of this document. Of course, it's a revision of 49-41.

F

We had a working group last call starting on January 9, and so this presentation tries to summarize the recent comments and unchanging that have been applied to the to the document next slide.

F

One of the issues that was raised and was discussed on the mailing list was about concerns about the possible impact of using multiple addresses or many addresses. If you want my sense of what has been the outcome from the working group discussion, this is an issue that is not specific of 49-41, but it's a general issue of slack.

F

Essentially, slack is kind of like anarchy when it comes to never configuration have much control as to you know how many addresses each node configures, so it's not really specific to 49:41, but still there was agreement that the document should say something about this. So, in response to the discussions that we had on mailing list, essentially, we did two things. First of all, we included specific text on this stuff in Section four, the text was circulated on the mailing list and was agreed upon with the folks that participated in the discussion.

F

At least another thing that we did was to reduce the body's lifetime value. That was one month sorry one week, not one month from one week to two days and that effectively changes the number of concurrent temporary addresses to two from the usual seven that you'd have with a body lifetime of one week. Next slide.

F

Then there was another question about whether temporary addresses should be enabled by default or not. You look at 49-41. It says that the use of temporary addresses should be disabled by default. It.

G

F

A number of reasons for that one is, you know the applications that my one long-lived connections and fail don't last for that long. It also gives a mention about the possible impact on network elements read as the outcome from the working group discussion. Obviously not everyone agreed on this is that it would be about signal for the ITF to to recommend disabled in a mechanism that is in in some way meant to improve privacy and in support of this I think we have essentially two BCPs.

F

First one is on purpose in money monitoring and the second one is in is on host, address availability recommendations, which essentially already says that God should be alone. You know use addresses aside from that, which is recommendations that even with 49:41 recommended temporary addresses should be disabled by default, all popular ip6 host implementations that I know of enable temporary addresses by default, so different distributions of Linux, OpenBSD, those etc next slide.

F

And then another one, this is the last one. There was some discussion about extent to which temporary addresses help privacy, 49:41 itself was called privacy, extensions for ipv6 slack, the discussion on the working group. What I read from that is that temporary addresses help address base where activity correlation talking about privacy- probably impresses imprecise. If you want and I agree with that, even I have always thought myself that aim of extension to call them privacy- extensions- probably wasn't the best possible title.

F

Privacy addresses so also you know limit the time window during which host is exposed be via an address that is exposed, as suppose as a result of active communication, meaning that you know, if somebody knows your address or how long they can use that address, to communicate with you, obviously, with temporary addresses they do have a lifetime. So you know eventually, even if your address becomes known at some point. It's not reusable anymore.

F

That purpose and another thing that you know came out as a result of their discussions of the working group is that now this is a revision of 49:41, so doing essentially is trying to address flaws in 49:41.

F

So the question, if you know, if false thought that the privacy extension sorted temporary, address extensions, you know we're useless or they don't add much the subject. You know for a different. You know different document that are going to obsolete.

D

F

The working group discussion we try to change all if not most, of the instances of of the of the world privacy and try to focus on achieve at least also includes the title so rather than you know, keeping the title privacy stations to ib6 like we changing it to temporary, address extensions, which is more precise, I would say- and we try to clarify you know throughout the document whenever they are used, there was a use of their word.

F

Privacy, try to change it to temporary addresses and try to focus on what the document is is doing, because at times saying privacy might mean different things for people send different inspect. I also set different.

F

F

The last one or two month we publish two revisions of this draft revision notes years. I was meant to address there. A working group class called comments if I remember correctly. The first working chairs provision and we've recently published a recent 0-8 was meant to.

F

Where is the second working cheers debut Southers I guess our question is: if there are any further comments and if not it's ready to ship for publication.

I

Super Thank You Fernando, so please join the microphone queue. If you have any comments, I think the in a fundamental question here is, you know: do people feel that their last call comments have been addressed sufficiently and if so, I believe this should be ready to shape, will confirm that on the mailing list? But you know this is your chance to to come in and state. If, if you don't believe, that's the case.

A

Yeah and I noticed there's some comments in the chat room so like yourself in the queue.

I

So Alex are you, you are first, please.

H

Yes, so you know this is Alexandra Petrescu. Thank you for the opportunity to be in a queue and a very brief comment. Is this privacy about the address or about the interface ID.

I

You might be on mute you at least we can't hear if you're responding.

F

I

F

Try to you know, stay away from the privacy and I would say that. First of all, these documents about addresses, not interface IDs. The two are related, but.

F

The same thing, so this document is about the use of temporary addresses, of course, in.

F

C addresses, if you want, but you know, as I noted during the presentation. I think it's better to you know, try to stay away from the word privacy, because that means different things for different people, so I think it's better. These temporary addresses these services do or what this document does is. You know specify a mechanism allows implementations to produce temporary address system addresses that obviously have a limited lifetime.

F

Is supposed to help we.

F

Or average base neighbor activity correlation another stuff prefer to not use the word privacy because I don't think it. It leads to more disagreement that that it should.

H

Yes, if I may reply, thank you for the comment. Yes, the indeed privacy itself has many different interpretations and ok. So my comment was whether well we, this document has a mechanism to design privacy for IDs, basically randomizing them, but that is probably used as if.

G

H

Always the same prefix and it's always the prefix 964 but I know this comment is a this relationship to the PLN is a stretch so that that is all I wanted to say. Thank you. Our.

I

F

To help- and it helps better in you know specific scenarios like you know: if there are multiple systems on the same subnet work in any case, even if, for example, you have a single node in the same subnet, you always use the same interface identifier, then I can write away and without giving any further analysis.

F

No, assuming that different communications correspond to the same system, if I am changing the interface IDs, even if I am the only guy on the on the subnet, at least the guy, you know doing the neighbor activity or relation as to do assumptions that, in that case, I'm the only fork on the subnet. So it's not as trivial or asked by the way as it will be the temporary addresses, but anyway, as I said, I think it's better to you know talk about this as worried.

F

Us, like you, know, specify some mechanism or producing temporary addresses and, as such, the consequences are this or the implications are. These are supposed to talk about privacy because still much broader topic. That's what revision last revision 0-8 has tried to address and if you know, if I understood coming from I, think that some of the comments from ollie.

I

Yeah and we have one more question from Logan by the way phenomena: can you come a little bit closer to the microphone, we'll turn up your game a little bit and I would bigger Logan. Please.

I

Mine is more of a comment. I believe we should be ready to ship this at once this document to deed to our new ad. Okay, thank you for Nando, then. So far, you are up next to stand in the pink box. Please say next when you want me to announce this lines. Hi.

K

I

You hear me well.

K

We can hear you well, oh great, thank you so I'm gonna cover as a v6 onm updates. Basically, all the updates that are through last call faces document on my on behalf of my authors quarters as well as next slide. Please contributors next slide. Please.

K

So here's a bit of history of the draft the work is started almost close to three years ago there has been 11 revision of the draft since individual submission. The working group call started on December 4 2009 teen.

K

We are using a github where we've been posting incremental changes and communicating on the meaning list. There has been 17 commits to the github repository during this. We promoted them in two different round. One was version 3 and then one was version 4 where we took the last repository and posted religion, for it has been active. Discussion of this draft on the mailing list would like to thank all the folks that have contributed and have provided comments.

K

Next slide, please in the next few slides we are going to go over summary of comments and as well as what shape is, were made in the draft to address those comments.

K

So first one is we remove the TLB section. There were comments from Ron Bonica, the first male in this list. The next male is pointed to male from Greg, and the third one is appointed to me as forum and then Queen and basically the question was that if the draft doesn't have a use case illustration for TLV, then why do we have this section and authors agreed and we removed the LD section?

K

The next comment was regarding illustration for offline processing. This is like some comments that were around some clarification or the old flag processing. The first in this list is a common, is a mail from Joel Harper and the next one is a discussion that happens with the Greek and what we did is we added an illustration section or a flag processing that essentially illustrates and focuses on. Controller-Based has a one am use case.

K

The illustration is created so that we cover both node their support or flag, as well as a services nodes or endpoints that do not support or flag the go flag is optional and also known as service is cable node that are on transit.

K

It is orchestrated side that we can make it clear to the reader on how a flag is to be used, and then the next one is the ICMP error, reporting section. That was a comment from Zen Queen, and the comment was this: that if there is no change to the base icmpv6, then why is that? What is the point of reporting it in this draft? We remove that. Obviously, the draft relies on the base ICMP v6 processing, as as is without any change, so there was no need as such, and this section has been removed.

K

The next row is really about adding normative text for the onnum process that had been mentioned.

K

Among other people, they were common from jewel hopper and on Bonica, where they were asking for what happens?

K

We need some normative texts on what happens when packet is is given to the one in process and what we did is we added some amateur texts of that nature. The rest of the details are implementation, specifics and we point that out as well in the draft really clearly- and this is how we address these comments.

K

The last row in this table is regarding the discussion that happened on the n dot. Otp said where the reference is from email conversation with your Harper, Greg, menisci and and many others, and the point was this again- that since the drug does not have use kiss for this specified, it is better to move it to a place where the use case would be specified. So we removed the end or OTP said as as to add, read that comment and next set is.

K

So then, now the next set of comments are mostly for clarification. Texts that was needed and were asked for. The first row here is on the scope of a flag for passive onm. Essentially, there was a comment like how the passive enemy is, how the flag is used, and it was confusion of the scope and also we did clarify that all of that the passive of flag is used for passive venom and that lead to the next set of question that Greg and other has on the mailing list.

K

Is that what is the relationship of this passive onn? When is in its you own em work that is going on and.

K

Essentially, the point there was that we added text. In short, the point is that NH 2 nm carries the metadata that is related with the packet in in the packet itself, so.

I

K

I

You want to take a question. We have Joel and Greg in the microphone Keith. Okay, do you prefer.

K

That we go over this and then we take question open the we prefer. We take it down. Well, if you think well, why don't you finish the slide and then we go through maybe better that I go over and then we take question sure.

K

So we were on the relationship between is 200, nm and and and the classify MN by a flag and passive when M biofloc is a controller base when n, where copies of the packet is sent to a controller for correlation wariness to own M, is a mechanism where the own M data actually go in the packet itself. So that is the difference and that that has been very clearly clarified. Both through illustration, as well as through normal attacks or ordinal numbers, gets.

G

K

Set of question, which is the row number three here is there were discussion with with respect to 1 M consideration if there is any or with VSP sits and the answer to that, while there is no special consideration needed to handle TSP sips- and this has been clarified on the mailing list, there was a discussion with jor Harper, Brian, carpenter, Drake and others, so that clarification tax is now in the draft last, but not the least on this list is the comment that we receive from you from Lua Anderson, and that was about.

K

There was a clearly missing entry for I, any consideration for Oh flag registry. That was gladly added with the draft next slide. Please and then the next set of questions are related with editorial changes. So you are anderson, provided a very detailed review with approximately 36 comment. We have addressed all of them and those has been act bylaw.

K

There are two comments there are pending and they are listed as to be done item in the next slide, but many times you are for such a detailed review is greatly appreciated and we had waited a review from zen coin as well, and these comments what the comments were also in this review doesn't mean that they're only you a tutorial.

K

There were other comments as well to her address as either clarification, tax or substantial changes, but here is that they were additional comment that was related with a Tori changes and those are addressed and and the same apply with the comments that we received from Ron Monica and they have their words on editorial changing requested. Those changes had been made. There was a detailed review done. A min and those detailed reviews had been responded. Back min has responded back on the list on one pending item and that would be addressed as well.

K

There were two your comments in great emails as well, and those comments have been addressed. They were any comments from right, carpenter as well and those are address. There are other machinist comments as well from other folks and and- and they have been addressed, this list is not exhaustive, expect is so on. The pending changes, like I mentioned Lua, had detailed view with citizens coming.

K

The two commenter pending that will, that requires adding more substance to introduction and extract today would be editorial in nature and then changing notations for interface addresses that are use, and that would be editorial in nature.

K

So we have I mean we acknowledge that these two comments have been not address and we do plan to address them very shortly. The bomb Bob Hendon kindly had comments on the XML file sent priority to the author, and these are again issues with the XML file. We do acknowledge that we have not get chance to address tone, but we will address then gladly. The none of this comment will require any substantial or normative change to the document.

I

Next slide, please do you want to take questions on these ones now so far before we move on to those two last ones and Joe happened, do you want to go first, please.

L

Please you said that you had a illustrations of obit processing to address my comment and you added illustrations, but that doesn't address my basic problem with the description of the obit processing. The description describes something that is entirely internal to the device and does not describe the actual behavior that must be performed.

L

The description says must make a copy send to control with a timestamp. Well, that's not it's, not an external observable, that's not something we standardized at all the question that you met. The document needs to address is: what does the router actually have to do with a packet that has the obit set?

L

Control is not what the router actually has to do with the packet.

K

Okay, so there is a pseudo code that is nominative need for what why supposed to do, how device implement that is really an implementation matter. We know.

L

But but so far the pseudo code you have there is entirely about internal behavior. It is not about what is the external result of the öbut.

L

You cannot require a device to make a copy of a packet, because you can't tell if the device made a copy of the packet, which is what the pseudo code says. That's not an external observable when a device you're not normally specify internal behavior. When.

K

A device I realize is that it can support obeyed. Did it externally known that it it will do this operation at fall, telemetry operation? It will make a copy of the packet for telemetry operation. Now how that's.

L

Not a meaningful thing to do. I have a real basic problem with this document because of this.

A

Question Joe: could you propose some text on the list how this could be resolved? I.

L

Actually do not know what they intend to do. This is really a case of I can't propose text because I do not know what the expected behavior is your the process.

K

L

Is not the externally observable behavior you.

K

Look at the illustration, the installation.

L

Is not the normative definition I'm? Looking at f11, oh flag, processing, one nice thing about this I'm, looking at it as we talk, you can say it illustrates it, but you haven't defined what the required behavior of the device is I. Think I.

K

Mean they, the thula core, which is the normative behavior? No.

L

The pseudo code you have here is an entirely internal behavior. What is the external normative behavior? What is it that is required to be done externally? Visibly it.

K

Also attacks on externally visible elements that talks about a limit read the copy of this packet, which is externally visible. What is expected from it and that could complement it with the illustration I think what would be good is if you can have a look on the illustration section would be happy to have another colleague as well with you or discussion, to give your.

L

Illustrations that they do not tell me normatively what you expect the device to do and I'm sorry Bob I understand that normally sent text is the appropriate response. But when I don't know what the document is actually telling me to do, I have a problem and I have a very basic problem. My rule for this stuff is always if this is approved as an RFC. Is this something I can implement? I do know what to tell my implementers to implement from this, but.

K

They implemented that I will remember this the distance formation so but I mean this has been implemented. So anyways I think the point that is okay. We can we're happy to talk with you even set up a WebEx call to come to a tax, explain and then come to an understanding of what you are expecting, because what is not clear to us is what you are expecting beyond, above and beyond what it is. In the document we have external behavior. We have internal Kuroko.

K

We have illustration: let's, let's work together, to see how we can document it to exercise as I sound.

L

Like a good happy to talk to you further, but I had raised this multiple times and you have not dealt with it. Fine I do not think it can progress until this is solved. This is very, very basic to the function of the document. That is this.

I

Is something we have to take to the list? I mean if there are other people who you also see Joe's point I'm sure it would be helpful if they could also try to express it. You know differently, so we can see so we can get some help figuring off. You know what's missing here in the description on the old flag, but I think we have to take it to the list.

L

To take it to the list, I'm happy to have web conversation by phone or WebEx or whatever.

K

Would be really happy with.

I

So we have in a microphone to Gregg Mirsky and please, yes,.

M

Thank you. Apologize I didn't get a chance to read the latest version, so I cannot say what this I want to make two comments. First, I think that your interpretation of om crucification, they RFC, 77, 99 and old flag as a passive om, is incorrect because you are using this and you're modifying the packet, so it would be a hybrid om.

M

Second I still believe that what you try to achieve with the öbut is achievable, with the current IO am or in situ area, because the work on in situ OEM continues in IPP and working group, and currently now we have what's called as direct export function, which achieves the same thing that you try to make happen with the all flat as I understand, so I would still want to discuss.

M

Continue our discussion on what's the difference between using old flag and using IOM approach and I would appreciate to be part of the discussion on the topic that Jo brought up because I do have my concerns there, as well again before their new text, but I'll read the text and now coming to the list. So that's probably it.

K

So, first of all a germane things so regarding whether this is really a passive or an Emma or or a hybrid, we can definitely talk this in terminology. Nothing.

K

The point regarding how it is differ from any of the IOM work, so here the motivation is to get this data from only segment endpoint, because these are the nodes that are well suited for information of they're very well suited points in the network for trafficking, giving the other than were burning Network with all the information they provide information. So so that is, there is one aspect that we can.

K

We can certainly talk a little bit more with you on this Greg and we will set up a call as well like that we discussed the normative text we talked about, which you all as well with you and address your comment.

I

Thank you and, and we have Romanick you can you have the last word please wrong question.

B

About, let me make sure I understand the mechanism say for a minute: you're, not pinging, you're, just sending a packet to a CID and the packet reverses the IGP least. You just send an ipv6 packet destination addresses. That said, there's no SRH involved at all. Now you decide that you wanted to hang the CID so would have to include an SRH, so that'd be first.

B

It in the path would be the end.

G

B

And the second one would be the same said you I have that right, I.

K

B

What's bothering me is that the data plane traffic as no SRH in it and ii o am traffic, has an sr h in it. Presence of the sr h may actually change the result. Instance of somebody's filtering packets, with extension, headers pain, won't get through when, in fact, the data packet will.

K

Yes, there's a fair comment run how.

B

Do we fix this.

K

We need to I think would take this comment. This was not raising the list prior.

K

We would take this comment and contact you if you know the mailing list or or we're taking notes here, we will for sure come back to this. Okay.

B

Sounds good thank.

K

I

Okay, so far, that was the microphone to you, so we, if you want to run quickly through the rest of the slide, that would be great a little short so.

K

So, essentially, with respect to the deployment implementation intraoperatively, there are six known deployments of the drafts in production occurred and there are additional and disposed deployment. Our implementation status as well, that is noted in the deployment draft, which is mention, is a source on this page. So we can have a look and all the deployments for this drug, because I just talked about it. For that word platform that have shipping code with this.

K

This, including including right now in, will refer to interoperability. They were interrupt done at e EA NTC in 2019, there was as well the multi vendor in shopton and NTS for Congress or showcase. It will cover M Congress, and there are authors are aware. Offs was interoperate retesting between vendors. They were privately done.

K

All this information is publicly disclosed, except the private details on the SMC department instead espera next slide. Please.

K

We will, as we mention we will address all the pending comments. The comment discussion that happened today and like folks to review revealed enforce, send any additional comment on the minimalist or you can reach us, and one question for the chairs is that maybe it's a good opportunity to explain to the group the expected unit of the good hub, because that's what we have been using, but it would be good to get that clarified, because I think there was some confusion during the use of github, both from authors as well as.

I

Right so yeah this is older, so I was the one who has been trying to push for the use of github here with somewhat mixed results. The intention was for to focus the working with more on the document itself, an actual text changes.

I

So what I you know was hoping was that the people, the reviewers, would could input requests for individual issues as the founder and those pull requests in github would then gather consensus or not, and then the document shepherd would press the you know because fuss on those changes just like we do with source code and then, if there were the discussions on the issues themselves would be happen on the mailing list.

I

You could have that discussion on github as well, but it's sort of discussions quickly diverge from from sort of the text itself, so you know it seemed like they would do better on the mailing list, but it has been you know so far. I, don't think we have seen any pull requests. So it's early, you know, so this is sort of back to the IGF Montreux proposed text.

I

If you won't change his proposed text and and if you have text, please do too much pull requests, but but that's pretty much us as far as it goes, and it is an experiment, you're free to propose text in in the mailing list, with all the new as we have done. You're marking them as all the new, as we have done in the past as well.

I

Yeah that that's pretty much is it was it anything else you wanted clarification home so far, no.

K

No, that sounds good to me. We've been, we found that ahead of uploading. A word on github for incremental changes is very efficient, so I think that's from the experience. That would be the feedback and we continue to use it and and because it always yeah, this change had been addressing. Guitars I would look at there and then we can promote a few versions.

K

I think it is I mean.

I

A hopeless it was really that we sort of built I, think you know working with consensus around each pull, requests and committed that, and- and you know by the end of it, it would be no sort of onerous for the issues when your revision came out and everyone was aware of what changes were made. I.

I

Don't think we've quite gotten to that point yet, but but at least we sort of experimenting with the tool to see if it does help us as a group of people trying to do some collaborative editing on a document but we'll see, but takes a lot so far for the a chemical update. I think we need a new revision right that that's at least at least clear, and this finishes the working group documents. The next one is gives epi on the ipv6 application of the alternates marking method. Let's say individual document disappear. Are you ready?

I

N

Can you hear me, we.

I

Can hear you well cool.

N

Yeah, hello, everybody- this is just happen, one of the culture of this draft. This is an update of the pv6 application or the alternate marking nighted. Okay. Next.

N

Just to give a quick recap about methodology, so maybe I don't know. Many people is familiar with this methodology, I hope most of the folks. Anyway, they alternate marking methodologies, no I'm performance measurement technique. Particular it can be classified as I breed or also passive, depending on point of view. The reference documents, RFC 8321 and also the duty point of mark draft at ease in RFC editor q.

N

So the basic idea is to batch the packets by is reaching the value of a single bit. This way we can group the packets and count the packet loss along the pot and, in addition to packet loss, it's possible to measure also the delay, particularly in single marking methodology. We can measure first and last packet. Delay of a group of packets are also average delay. If we want more, informative, I can delay matrix.

N

We it's better to use a second bit marking, so it's the suggested and the most suitable wastes use to beat so the so-called double marking. Next.

N

H

What about ipv6.

N

So why we are proposing this draft. The main requirement for the application of this methodology is the marking field. Since we need a marking field, we have to identify it and in particular, we already working on a graph that analyzed the different different alternatives.

N

The marking field and, in the end the best choice was news of the an option adder that can be bought up by up or destination, depending on which kind of performance measurement we want to enable. In summary, the alternate marking application is very straightforward and seemed very simple because it does not affect the packet behavior, just the source node.

N

Only the source node writes the option adder to mark our natively the flow and both the intermediate nodes and the ending nodes may be configured to support this option other or not, but this does not impact the traffic and the measurement in the measurement can be done only for the nodes that have this option enabled, while for the other nodes simply the metric is not done, but nothing happened.

N

In the end, the alternate marking methods allow both by open head to end measurement. So next.

N

Yeah, the the better way to apply these methodologies to generalize the alternate marking data fields and so a new TLV. We want to introduce this new to be to be encoded in the an optional.

N

We follow the option, either format and you can see the red box, the generalized data fields, so we had the two marking fields the lost bit and the delay bit. We had also a flow monitor flow monitoring identification. This is requirement. This is required for some general reason and deployment experience. In particular, the destroy identification helps to reduce the per node configurations or apps to be reduced.

N

For example, the number of access lists on the router that we need to serve the flow seed simplifies also the counter sampling, especially in tunneling, and so on, so to avoid deep packet inspection to find the right, encapsulation and so on, and also it is the data export incorrect collect.

N

While we also identify the first three bit of the option type because, as also I mentioned before, we need three zero values, because the this option can be skipped if recognize and data don't change and root. Only the source. Node set the marking bits next.

N

Okay, as encapsulation header option, we can, we can have different alternatives that we can evaluate. For example, if we use this option address this Nisshin option, the measurement can be done only by the node in destination. Address I thought by up option is the best way, because every route around the path with this feature enable can make measurement.

N

There is also we also mentioned the option of the SI R htlv, but in this case every node that is a nap in the yessiree in the SL path, can be you can do the measurement and the same behavior can be, can be obtained with the destination option, together with the SI rage in this case, or so, every node that is an entity, can make the measurement in any way we clarified. Also, after some discussion of meaningless, we clarified the usage of the sh t.

N

V is still under discussion within the community, so it's not the preferred solution. For now, an in general hop by up and destination option are the most suitable ways to implement alternate marking, because it's valid for ipv6 in general, including also the some case of sh.

N

N

From the zero one version, so we got several comments on my list from bobble Tom on drying and thank for raising the discussion. As I said, these fruitball feedbacks had to clarify better the scope of our graph to help to analyze how to encode the TLD for alternate market application, also adjust the wording somewhere and updated references.

N

We also added the definition of three high order: bits of the option type in the very last version and a new quarter as a joint, maybe some last conversion before I think we, our next slide, will be the last one yeah, the next step that we we think that we are from an agreed way to apply alternate marking and also its extension, that is in alpha. Sierra talked you and the others considered the draft ready for working group adoption. So anyway, we are open to questions comments and.

I

Ok, excellent, this happy Eric, no sorry wrong! You are first in the queue.

B

Ok, first I do think this is an interesting experiment. I'd like to note a couple things: first, it's based upon or FCAT 321.

I

Dropping a beat, at least from my side, will you try to beat sorry the microphone and speak up a bit? Thank you.

B

I'll be a little louder both of these documents that this draft is based on our experimental or targeted for experimental. Another thing is: there are some security issues that remain to be worked out.

B

I think it might be a good idea to progress this document as experimental and at least for the time being experimental code points for the option. Identifiers.

N

Regarding regarding your first point, yeah do I write motor Fiat, 321 and multi-point Altmark draft experimental. There was also some discussion, particularly during the ad review of the multi-point of mark draft about the scope they media suggest to change into informational, but anyway, experimental and informational, nothing change. We can consider borderline between experimental and informational, but anyway, be.

B

Interesting I'm, sorry, good and.

N

Anyway, this is not the main, the main purpose here, so the idea is to because water, Fiat, 321 and multi-point mark draft are more focused on the methodology. That is general. If you want to make since to apply this methodology, we need space in the packet header.

N

We cannot make FEC at 321 and the other one and the multi-point draft has standards, because we cannot stand out the dots, and that does nothing because we are just talking about a methodology that is transport agnostic, so it can be applied to ipv6 to be.

N

We also have a drafting beer that is standard track because it applied the RFC 283 21 to the beer to the multicast traffic, and it is following the standard track, because in that case, in beer we are asking for 2 bit to implement and to encode the alternate marking application, and it is basically the same thing that trying to do with ipv6. So we aims to define, beats and also we have defined generalized to encode the alternate marking application and to make it in order to go beyond the experimental.

N

That is the experiment that is described in the RFC 8321, and it is just to explain the motivation. It's.

B

Not clear to me that that experiment has concluded yet, would you be averse to using experimental code points until it concludes.

N

It's not an experimental code, so the the methodologies is I think is already completed, I mean the the basic methodology is already completed and it is applicable if you, if.

O

N

Look at both RF EC 8321 and also the new cramming RFC.

N

It's what completed from all the point of view, because it investigated all the expect of the deployability of these methodologies. But the only things that we need to deploy is the space in the packet header. Otherwise we cannot. We cannot deploy this methodology, there are already experimental deployments, but in telecom italia network and also as a product. That's another product presented that are already deployed, but anyway, to make it applicable and standard. We need to follow the standards track, in my opinion, in order to really define the field that apply this method.

I

Okay, thanks for that egg is happy. That's a discussion. I think well to continue the status on this document on the list. I have Eric go back and then they recline all right. Please go thank.

E

You late, it is Eric back here without any head here. First Tuesday P! Thank you so much for the document. As a side. Note I really wonder whether it's really not a waste to spend a complete extension header just to con transport to bits, but, okay, so I depart I really want the. My real question is about using the hop-by-hop extension header, in this case, typically measurement.

E

My understanding are done and to end, and in order, if you are using hop-by-hop, it means that, if you're out on the path we like to have a huge amount of credibility issue, because it needs to remember all those measurements compared to the end-to-end and I'm pretty sure as well, that you know that hope, I hope expression, others are still quite drop a lot over the Internet. This fishnet there it's a little bit better on this.

P

Any comment on the just yes.

N

Yeah I I know that I buy up options is not is not, we can say recommended, but in order to see a ATT thousand two hundred, it is also stated that in case there is a strong motivation or the user job of IAP it can be defined. But a part of that you can consider that the hope by the intermediate nodes don't need to need to read.

H

N

Option option either, and so they don't need to handle or modify the content of the option either. So maybe this can be easily managed by Browder instead of other kind of option either. When you have to put information in this case, you just need to read the marking that is set by the source node. So these.

E

N

You can read, it means.

E

That the CPU sees it through the page and again this version 0 1, so that's open for discussion. Of course you may want to continue this on the list, but just pay attention on this I think I'm good work. Thank.

I

You thank you every client, you get the last word from this draft.

O

Thank you, their client, no hats sort of similar to Eric's comment. Actually I was wondering with respect to hop by hop or how about versus destination option, whether or not there was value in having both that you might use destination for sort of just end-to-end measurements, and you might, if you say, wanted to do something across across your own networks. If you were running a multi, continent-wide backbone network, and you wanted to try out some stuff, you could use the hop by hop options.

N

Yes, that's options.

O

N

It's correct because the scope of the draft is to define the general TLV, the general option that can be included, but as of May up and also with destination, option, of course, and also I also mentioned the case of V. But it will be in the future if it will be used. But for now we can focus on bottle by up and nation option.

O

Yeah I guess there is I was turned, there's lots of text about hop, I have word destination and it was not clear if you were attempting to choose just one or any optional. We are having the same format for both both options. The.

N

Idea is to to leave the choice to the implementers, maybe better, maybe also if the draft will be adopted. We can continue the analysis and together with working group, to understand what are the limitations for each kind of deployment and so on. So that is the idea for now to leave both options open for deployment ation and then we'll see, yeah.

O

Thanks very much thank.

I

You thank you kiss happy Fred Templin, please step up in the pink box.

D

Do you hear me okay, we.

I

Hear you perfectly fine go ahead. Thank you. Okay,.

D

Okay, so this is a document title transmission of ipv6 packets, over overlay, multi-link network or omni interfaces. Let's go to the next chart. Please.

D

So in terms of agenda for this talk, I'm going to get some background in motivation. The mobile node mobility service architecture model, the Omni her face model is off I'll, be discussing about the maximum transmission unit. Link-Local addresses a new option called the Omni on router discovery, registration, a conceptual, a multi-link selection, algorithm and then state document. The next.

D

Let's go to the next chart.

D

Okay background: the international civil aviation organization is designing a worldwide ipv6 based aeronautical telecommunications network within in protocol services. It's going to be known. The 18th IPS each aircraft, mobile node, is assigned a unique mobile network prefix from an aggregated mobility service prefixed by the mobility surface service. Prefix Authority, for example, like a would be the authority for the mobility service prefix for the ATN IPS.

D

So if the MSP is a slash, 32 then slash 56, M NPS can be assigned, and then the aircraft acts as a mobile ipv6 network aircraft that connect to the ATN IPS would be a multiple air-to-ground wireless data links and these data links off and have diverse properties. Some examples are video mode. Eleda axis sack arrow Max and there will be others, so we need an air-to-ground interface for multi-link coordination and that's what this document is about and again document is titled transmission of ipv6 packets.

D

Over overlay, multi-link network interfaces, we've received receive substantial review input both from the ICAO working groups and from my ATF members and they've resulted in significant improvements and the dip Draft has been reissued with alignment to the six-man working group and members of the ICAO communications panel. Working group by mobility subgroup have issued a for action liaison statement on 329 requesting standard attack publication next chart. Please.

D

Okay, now I want to talk about the overall architecture for mobile notes in the 80s.

D

So on the right again, you see a block of the of a mobile node in the upper portion of the diagram, and it has multiple access network linked connections over those access network link connections, the mobile node sends native ipv6 packets and they are received by an access router that connects that access network to the rest of the global worldwide aeronautical telecommunications network. So you have native ipv6 packets on the access network interfaces.

D

The access router serves a proxy between the access network and the global Internet, where an internetwork, so the access router performs encapsulation on the design interfaces on behalf of the mobile network, acting as a proxy within the mobility service that the worldwide connected Internet work, there are mobility service endpoints that support distributed mobility management in, in particular, each mobility service, endpoint tracks, a subset of all mobile networks in the global I net.

D

Okay, let's go to the next chart and what I want to do now is to look more detail at the architecture of this mobile node that we had in the previous diagram. The mobile node has a virtual interface known as the omni interface and that's the nodes. Virtual interface connection can configure it over multiple, diverse, underlying a net error phases.

D

So the again there would be SATCOM el Dax aeramax would be examples of these. These interfaces, the omni interface of science and v6 link local address known as the omni link, local address and that's used for neighbors messaging and the access network interfaces are an unnumbered interfaces underneath the the the omni interface. So there's no IP address assigned to the connected access network at the interfaces in the omni interface. The moment owns logical attachment to what's known as the Omni link, which preserves the non-broadcast modal axis link model.

D

The Omni link incorporates the mobility service and spans the worldwide Internet work again, in this case the etn IPS for further traffic management. Next car police.

D

Maximum transmission unit, we are saying that the Omni interface maximum transmission unit is 90 180 bytes. That number came for RC 2492, but there was a strain of earlier RFC's with that number was motivated from and that's the number that we're gonna be using from the Omni in her face. So only the Omni interface MT is exposed to the ipv6 layer, while the underlying aim interfaces may have a wide variety of diverse em to use that could be smaller than 90 180. For example, 1280 1400, 1500 cetera the traditional approach.

D

When, when an ipv6 packet comes into the omni interface, it would drop the packet that was too large for not selected underlying interface and returning the internally generated packet too big. But we want to do better than that. So we have a new approach where, within the omni interface will perform link-local RFC, 24, 73, encapsulation, ipv6 and ipv6 encapsulation then apply a p6 fragmentation to the aina, an interface MTU size. The link local destination then gets to reassembly and it can optionally return advisory packet to bags if reassembly becomes problematic.

D

This provides us with lossless path. Mtu discovery the source is going to dynamically, adjust to any Advisory packet to big messages with no loss, and it supports sizes up to 9 kb jet Gigabit Ethernet jumbo frames across any access network link type. So the number of 9180 is not the size of the physical data link units, underneath what it is is the size that the receiver needs to be able to reassemble next chart. Please.

D

So the Omni ace assigns Omni link-local addresses and the way that we form link-local addresses for the Omni interface is that we take the aircraft's mobile network prefix or the mobile notes, mobile network prefix, and we embed them the preface within the interface ID of the link, local prefix fe80, colon colon, slash 64.

D

So, for example, from the mobile network, prefix 2001 DB 8 1000 2000, the corresponding omnia link local addresses fe80 colon colon 2001 DBA 1000 2000 Omni compatible mobile node ipv6 compat ipv4, compatible mobile node Omni lol ace are assigned from fe80 Quan Quan ffff Cohen V for adder, so, for example, for ipv4 address, 192 dot, 0 dot, 2.1 the omni link, local addresses FA 0, colon colon ffff, not 192, dot, 0, dot, 12.1.

D

The mobility service assigns link local addresses from the prefix fe80 / 96, so those addresses would be fe80, colon, colon, 1, 2, 3, etc. Up to Fe F F F F F F, the ipv6 link local subnet router anycast address is already defined in RFC. 42 91 is fe80 colon colon, so that's that's used as defined in RFC 1491, and we reserved a block of future use of dresses, fe80 : F F F F F through all apps.

D

So this is under the assumption of the / 64 prefix length, the ipv6 addressing architecture changes to permit future prefix lengths of 65 or longer the Omni link. Local address format is going to be able to accommodate up to / 118, so that provides a speech proofing in case we get to the point where we have prefixes longer / 64 chart. Please.

D

Now the Omni interface is going to be using a new ipv6 neighbor discovery, option type called the Omni option. It's going to appear on ipv6, neighbor, discovery messages. We need a new type defined by Jana Jana and the Omni option. Header includes a prefix length and our flag to be used for source address, based prefix registration, so, for example, in an RS message, if the source address was fe80, Quang Quang, 2001, DB a12 again, this would be a an omni link local address.

D

If the prefix length was 56 and our want one meaning to register, then the mobility service will register the mobile mobile network, prefix 2001 DB, 8, 1, 2, / 56 in the routing system. You can think of this as a stripped down version of delegation, because all we're trying to do is register the prefix in the routing system. Since the mobile node already knows it's prefix. All it's asking to do is for the mobile mobility service to register the prefix in the routing system and then within beyond the option.

D

There is a list of sub options that follows that has multi-link and mobility service parameters, and you can see below the format of the sub options and the currently defined sub options that we have pad one pad in life index, two bolts of two different types: mobility, service register and mobility service release next chart. Please.

D

So the option includes what we call if' index tuples and there's type 1 and type 2 IFM. Next tuples. Both types include an if' index that identifies the underlying access network interface and I have type which is the type of the I in that interface very similar to the way I FNX knife type are used in in network management provider. Id is set to the access network service provider, and then we have a link quality metric with one being the lowest 15 be in the highest.

D

Zero means that the link is down type 1 s, tuples include a vector of two-bit preference values, preference values 0 through 63 correspond to the 64 IP differentiated service code points, P, 64 and above our additional traffic selectors. They could be based on application, port numbers, IP address ranges, etc, and each p value includes a two-bit value, 3 to 1, meaning high medium or lower disabled.

D

For this particular I F index, and then we have a type 2 I have the next tuple, which includes an RFC 60, 80, 8 format, traffic selector and this could be used for flow, binding, encodings and ipv6 neighbor discovery messages without record, requiring adjunct mobility messages next chart. Please.

D

So then router discovery prefix registration using the Omni interface. What happens is that the mobile node will send router solicitation messages with omni options and they'll be sent over individual a net interfaces that are configured underneath the omni interface when the access router receives the router solicitation, it notices the omni option and then coordinates with the mobility service. The axis router then returns router advertisements with the omni option and any auto configuration information that would normally delivered be delivered in a solicited router advertisement message.

D

So what the mobile node does is sends initial router solicitations to register its mobile network prefix and an initial set of up a net interfaces. So, for example, if needing it, video mode 2 is up. You send a router solicitation over the via de element 2. If the SATCOM is up, you send a router solicitation message over the route, the the SATCOM etc. So the RS messages are sent from within the omni interface over and up underline any other interface.

D

The process is coordinated from within the mom knee in her face and it's opaque to the ip6 layer. So all this is going on below the ipv6 layer, the access router processes, the RS message and conveys the omni option. Information to the mobility service mobility service injects the mobile network prefix into the writing system. Caches the prefix length and moment moment are prefixed in IFA indexed tuples and then the mobile mobility service directs the access router to return.

D

The router advertisement message to the mobile node again with an omni option and with non zero router lifetime. If the prefix registration was too successful, otherwise, zero mobile node receives the re confirmation and then the access router will be set to forward packets between the mobile node and the mobility service next chart. Please.

D

Next chart, please thank you. So after the initial registration, when in Ain a face transitions to up the mobile node, sends an omni RS message when it interface transitions to down the mobile node, can send an unsolicited neighbour advertisement message over any up a net interfaces with an if' index tuple for the down interface, with link set to zero.

D

So, for example, if I'm IV diamo to goes down I've sent in a UN a over the SATCOM, the mobility service gets it and then takes the video mode to link out of its selection process for for trafficking selection. The mobile node departs from a current mobility service endpoint. It can send an RS or u na over any up, inter in an interface to release that mobility service endpoint. When the mobility sir mobile known associates with the new mobility service endpoint, it sends a RS or RA over any up interface with a mobility service register.

D

Now one thing that's interesting about this is that with when we have multiple mobility service, endpoint servicing the same mobile node, the RS are an RA message. Skinning can include multiple register IDs in a single RS message, so I could send a single RS message over, for example, my video mode to link, and it would register with multiple mobility service endpoints with a single message and that's that that amounts to a very large saving of messages over low data rate access network links.

D

So then, finally, when all the mobility notice unknown faces of transition to down or if the prefix registration lifetime has expired, the mobility service with bras the mobile network prefix from the routing system start please so now that all this has been set up. Because of all the are sorry messaging.

A

Can you we're sort of running out of time here when you could go to the next slide and then allow? Firstly, this next one? Certainly we can.

D

Skip ahead to that, one thanks, mom thanks! So so really what we need to talk about now is the status of this document in next steps. This document has been a work in progress in working group by the mobility subgroup of ICAO since March of 2019, and it's now published as an IETF internet draft yeah there's the draft name.

D

We have code, that's an advanced stage of development and testing in linux, based network emulations and early aviation testbed trials also other relevant trials, such as enterprise network mobile devices and in our liaison statement, we've requested the IETF to adopt the work. It's an example of an ipv6 over fus back. It uses the new ipv6 in the neighbor discovery, option notice the omni option that needs to be standardized and it uses a new link. Local address format, notice, the Omni, Omni link, local address format and we're requesting standards track, RFC publication.

D

So for what we're asking from six men is for additional review input and if co-authors would be interested and also asking six men to adopt the work as a six member working group item and now I'll break for questions. Thank you.

I

Okay, so we have one question from Alexander: Alexander: let go yes.

H

Hello Fred: are you okay, yeah, so I have several questions. Some are more details on how level higher level and I have put them in the double for reference. I suspect there is not enough time to discuss them all now, but this NLA really for matter on the on the omni interface, looks like a link. Local address that integrates in its interface ID part, the mobile network, graphics and an example is given on slide number seven with mobile network prefix. That fits well because it has a prefix of maximum four hex Ted.

H

You said 56 bit, and but it is a good thing. It is not a 64, so it is 56 but good good. The mobile network prefix also could be. Could it be more like 64, for example, five hixton's, so.

D

Alex and done is we've said that for prefix lengths up to slash 64, those prefix bits we're going into the the 64 bit interface, identifier of fe80, colon colon, slash 64 for pretty links longer than 60 for the additional prefix bits would begin to be encoded in bits 10 through 63 of the ipv6 link local address. So what this allows us to do is in the future.

D

If we were going to allow previous is longer than 60 for those prefix bits would appear in bits 10 through 63, since the addressing architecture has fe80 colon colon, slash 10. That allows us to encode up to a /, 118 proof.

H

Okay, perfect. Thank you very much. That's all for me.

I

Eric Cline you're next and then we have esta Silva lost and then we have to move on all right. Please yeah.

O

Eric line, no no hats, Thank, You, Fred, um I. Think, okay, let's set aside I, see a colon colon slash ten, because I think there are some issues there right by convention. It's 6054 that's available on the link, but I guess you're going to say this is different for this particular link. But I had a question about like. If we set aside the MTU reassembly, the MTU, the link specific variable, MTU and reassembly issue.

O

Is there any reason this couldn't just be a regular Rooter with the slash 56 assigned to internal addresses and doing link local communications on each link? Moving moving is forwarding plane from interface interface, interface separately, so.

D

You're asking whether that the virtual interface model can be lifted and just exposed the underlying access network interfaces to the ipv6 layer instead. Is that your question assuming.

O

The MTU reassembly issue could be punted to the look to the lower layer yeah. So there.

D

Are slides beyond my backups here that I think we have time to go into Eric I'd like to ask you to go to those charts and look at what they're talking about in terms of Viet advantages in the rationale for having the virtual interface some of the points that will be included. There are things like the fact that you don't have to get care of dresses. If you will the access network interfaces, if you use the virtual interface.

D

So that means that, since you don't need to get well I'm going into an exhaustive list if I start but I'd like to direct you to those charts and if he could take the discussion to the mailing list on that.

O

There was some some of this was being able to register a connectivity over links where you like on slide 11, where he would seem to lose some face sharing.

O

Well, you know, there's no there's no, but he seemed to rest seemed to indicate that you could register connectivity link's without actually sending packets over them, but there's a certain fake sharing about being able to make sure the link is up that you can communicate over it and register by it, but I'm, perhaps III said I'll believe them I'll read your backup slides, you know I'll, uh maybe I'll beat it up. Thanks.

O

I

You so Esther silver, please state your name and your next and last in the queue. Thank you thanks.

Q

Ollie solo, we care actually just a question Fred, it's a simple question actually is: what's the relationship between the only interface and the existing mobility solutions like it might be v6, or at least all that.

D

So I think the background about our discussions in IKEA are not widely known to the IETF Sallah, but I'll just mention that we are looking at multiple mobility service solutions for the aeronautical telecommunications network there with Internet Protocol service and to that you mentioned, are two of the solutions that are being proposed, but the Omni interface is tended to be and is generic to whatever the mobility solution would happen to be.

D

That has chosen for the ATN IPS, it's strictly the air-to-ground interface and the mobility solution would then be triggered by the air-to-ground interface messaging and there's not any favoritism given to any of the mobility solution. Candidates. This is meant to be a generic interface.

I

Do you want to more on this draft before we.

A

Yes, thank you yeah, so I think this is all very interesting. I'm pleased to see this work, being you know, brought to the ITF I think there's a lot of work. You know the liaison is sort of a work in progress at the moment, but I. The one thing that I would like to personally like to see is that some more just at least more justification to understand. Why there's a lot of things here which are not well beyond at ipv6 over crew spec, it's proposing new nd options.

A

You know a bunch of things and I I'd like to see more justification for why those things are necessary. Why I sort of I think to Eric's question? Why why can't I be p6 just be used as currently defined? What you know? What is the benefit here? It's it's adding a lot of complexity, I realize this is for a particular sub domain, but I think there's gonna need to be a lot of discussion over some of these issues, but we will do the list. Thank you.

I

Okay, thanks a lot Fred. We are seven minutes before our ending time. If people are mind running a little over, we might do that. Fernando has asked to swap he's lost. Two slides, I think he's that correct Fernando want this one. First, no.

F

No just keep the other one. What I meant is that if we run out of time, I prefer to do this, one with you know appropriate time and just postpone the other one so that we don't just dump rush. Let's.

I

Let's try and see if we we can do both we'll see how much time this one takes and and decide. Okay, yeah go ahead: okay,.

F

So this is a presentation about improving the reaction of ipv6 slack to flash free numbering events. This is a topic as being discussed a lot both on the six-month mailing list and on the basic swaps mailing list next slide.

F

So essentially, there are a lot of you know different scenarios. Some are more common than others in which you might have a horse connected to a network and all out of the sudden another configuration changes or you know somehow their rotor just banishes the left-hand side. We have a very common scenario in which we have a CPE router that is doing prefix delegation with the ASB and, at the same time, is doing slack on the on the home network.

F

One of the scenarios that might happen- and that is common- is that, for example, the CPE roller crushes boots and it gets a different prefix leased from the ISP. In most cases, the CPE rotor, just it just doesn't record on stable storage, the prefix that was leased before so when the rotor reboots. It has no knowledge of the you know previous prefix that was leased. It starts advertising a new prefix on the local network and all the notes on the local network. All the hosts keep stale information.

F

There are many different scenarios in which this kind of thing can happen, as I have mentioned on the six one mailing list, we have a basic subs working group. Hiding item discusses the problem in detail, so this presentation and the correspondent draft focus on the protocol updates that will be necessary to improve SELEX response to pre numbering events, but the problem statement and the problem itself is discussed in detail in a physics, ops working group item next slide.

F

So when considering you know, protocol updates that would be necessary or would be valuable to you know, improve the reaction of select to remembering events, number of things that or a number of aspects that are interesting to to consider one is about signaling. For example, we have two options in some scenarios: the router itself that trigger the renumbering event continuous operation.

F

It may be aware of this daily information or me, or it might be unaware of this tale information sample, in one case, the rotor crashes, which the router had stored on stable storage, the information about the prefix being unknowns, so the router we boated it now got a different prefix list from the ISP. It's aware that the information has changed. So it's somehow in the position of trying to deprecate that information. In other cases the rotor might be unaware of the stale information.

F

That would be the case, for example, if the router reboots, it's least a different different prefix, but the rotor doesn't record unstable storage prefixes that are leased by the ISP. In other cases, we could have, for example, the rotor just disappear. For example, the rotor just crashed, or, for example, a switchboard, was moved to a different villain, so we had a router that was advertising information and just you know that rotor somehow disappear, whether because the rotor itself disappear or because, for example, as I mentioned, a switch power was moved to a different billon.

F

Another thing to consider is where we might, you know, apply improvements, so you can apply Pullman's on the host side or on the router side.

F

If you apply the router there, the improvements on the on the hot side- and that means that, in order for house to benefits from these improvements, they don't need for the robbers to be updated and that's all that's, of course valuable. On the other hand, you know if apply improvements on the rotor side. That means that, even if we have host implementations that have not been updated and improved, it can nevertheless yet timelier way to these four number elements. So what our draft tries to do is to pursue improvements in all of these areas.

F

On the hot side, and also on the rotor side, but we think that the what's I host site improvements are a particularly valuable because you know as soon as you implement them, no matter whether the rotors have been updated or not. It can already react way.

F

F

So I try to summarize improvements that we are proposing in this few slides. So if you look at current specification, for slack specifies they prefer lifetime for prefix information options of one week in a slide says one day, but that's incorrect. The current fall preferred lifetime is of one week. The fall valid lifetime is of one month. Of course, that's the equivalent of setting timers that will never go off.

F

So whatever document proposes is on one hand to change a lifetime or prefix information options and routers and select or set their is lifetime as a function of the router lifetime.

F

Currently, what we propose is to set the preferred lifetime of prophets information options to the router lifetime and the Ballad lifetime as a function of that, if I remember correctly, we set it to n is the router lifetime and we currently set N to 48.

F

That means with a default default value for the roller lifetime will use a prefilled lifetime of half an hour and we use a ballad lifetime of so we use the preferred lifetime lifetime from one week to half an hour and we reduced a ballad lifetime from one month to one day the other hand we also proposed to cap they receive lifetime at host. Of course, this is useful when your horse is connected to a network and then and the local router is still using the default values currently specific in RFC 48 61 correctly.

F

So we our document, poses to cup. They prefer a lifetime. Router lifetime The Ballad lifetime n multiplied for the road of lifetime currently being developed on to one day. So that means if the advertised had lifetimes are longer than that, then use those life stands. This means, for example, when it comes to the host site improvement, even if the router, for example, disappears, the host can recover later next slide.

F

There is another issue: if you look at section by point five point: three I think e of RFC 48 61. It essentially prevents the valid lifetime in Apio. Reducing valid lifetime associated with a corresponding addresses do anything smaller than two hours. That means that, if you were sorry, if you receive, for example, a Pio with about a lifetime of of zero day receiving cost is to ignore PA.

F

This is, if I understand correctly, it was specified in this way for security reasons.

F

You know, from our point of view, make much sense to just these PII or just or to specify the it was to be ignored, because, from the point of view of from the point of view of an attacker, if an attacker wanted to, you know just implement, for example, a denial of service attack. It has like it's even other attack vectors like, for example, food costs with bogus POS or wrote information spoof rotor advertisements with a lifetime of zeros, so the you know the router itself is disabled, etc, etc, etc.

F

So, from our point of view, it boils down to you know: you implement first hop security or you don't, because if you don't, the attacker had so many different directors that know well, it has other options other than you know, sending pios with a ballad lifetime of zero.

F

On the other hand, if you prevent hosts from reacting to the iOS that have a valid life that smaller than two hours, then you prevent, like a time layer reaction to remembering events in situations in which router the local router is aware that you know network configuration information next slide and finally, we also specify a couple of alternative algorithms. They are meant to do the same thing, so I'm just going to describe one of them, but the other one is very, very similar.

F

The idea is for host to actually try to infer when there were configuration information, as has changed. For example, this would be the scenario in which, for example, a router crashes gets different, prefix leased from the ISP and starts advertising these new prefix. Now, if the router has not recorded previous prefix on stable storage, it will start announcing a new prefix for outer configuration.

F

Obviously, at the same time, it will cease advertising the previous prefix. So the idea is simple from the host point of view. If you see that the same router that was advertised in a previous prefix as sees advertising that prefix and has started advertising annealing graphics, that should be taken as an indication that network configuration information has changed.

F

So what we do is essentially try to implement that, like try to deprecate the stale, prefixes open, received of route revert iseman from the same router Ras that sees to advertise ceased to advertise the previous prefixes as a kind of improvement to the algorithm. We try to unfold the processing of ollas and the process utilized and the processes of global puffiness. So what the algorithm does is this?

F

You receive a rubber advertisement from the same router as before the rotor that was advertised in a previous prefix RA Alberta is new, but it's in the previous prefix. What you do is you reduce they prefer lifetime and the ballad lifetime. For that. Previous prefix we currently do is reduce the prefer lifetime in the order of a few seconds just to accommodate the theoretical scenario in which the configuration information may be split into multiple word advertisements.

F

We reduced the ballad lifetime. If I remember correctly, we reduce it to an to the other of about half an hour, or maybe even obviously, they, the ballad lifetime is reduced to much longer, and we do the same thing for you, a lace if you receive the prefix, that is, advertising au la, but it doesn't advertise the previous usual day. You reduce the preferred lifetime and develop lifetimes accordingly.

F

At the same time, if the prefix was being advertised by multiple routers, then you essentially disassociate these Perfect's with this specific router. We are talking here about the cases where we are having scenarios where the network is using multiple prefixes. In summary, you know this algorithm is able to deprecate prefixes when a new prefix is being offered by the same router. The same role is not has cease to advertise the same prefix but another way if the same router from which we got the configuration information.

F

It's now advertising the different prefix, and it's not advertising the previous one. We try to reduce their lifetime values so that these prefixes get replicated in a more in a timely manner.

F

F

Implementations so lately we have been working in on implementations of the things we did implementations for a number of demons which are used in different operating systems, so these slides are tries to summarize existent implementations when it comes to using the lifetime values that are employed by router implementation. We implemented this in different demons.

F

Our ad is the demon by OpenBSD our DVD, which is the human employee in Linux. Normally we have an implementation for RT, a DB which is the demon employee for previously so.

I

For now, no, since we were running over I wonder if we should start on the microphone queue now.

F

They are summarizing this light, so fantastic.

I

So we have gen Philip and the Eric said Jen. Do you want to start? You wanted I.

G

Wanted not the previous one I guess about life time with cooler out there a lifetime? Yes, so sorry, I have the properly read latest version of the draft, but does it mean if I am dragging one of my router and the router advertises zero lifetime?

G

The PIO will get zero preferred lifetime and zero well at lifetime. I will get a video player, I deprecated and became invalid, which might be actually very undesirable behaviour.

F

Your roller is the only rubber that is advertising. This prefix.

G

So if two routers advertises the same prefix and the hostess getting an array with zero router lifetime, you still not deduplication the previous right. Exactly so, but does it be like the router will be advertised it the preferred lifetime of zero in the PIO I.

F

Don't mean by before so what we did, for example, in the implementations that we have, if you are not setting the preferred lifetime explicitly yeah the default is, should be to other type the same lifetime as you do.

F

G

I think it's kind of dangerous for default. Behavior, let's say I have a router I have two routers and I'm going to drain. One and I did not specify explicitly lifetime in configuration. So now the first router it will put zero pair your preferred lifetime well, which will indicate to host. Oh, please duplicate the prefix I think you should be very careful about dealing with zero lifetime in arrays in zero router lifetime in all right. What router she'll be there? Okay,.

F

I meant, to be honest, um I'm not sure if we had considered- and we have consider that specific case, but I mean point taken and we'll take this into according to the next revision. Thanks. Thank.

C

You and Philip, okay, so first, a general comment: I think this is an important thing that should be soft, and certainly changes on the host would help to solve this quickly because it will take forever for all the routers to get updated. The thing that has me worried about is the inferring stale information thing.

C

It seems that the algorithms that Fernando is working on a fragile are not reactive, since I introduced an issue with if you alternate normal global user, unique address in your lace and now the algorithm has become more because it has to do separate processing for your lace. But even then it's not clear if we should build in just one type of your lay into a house and then later be stuck. If we want to have another, you Elaine my concept and then find out that it's going to fail.

C

So I think that that's part of the draft. It really needs a lot of work and it's a different way of approaching those algorithms, because this doesn't seem to work to me.

C

So that's my comment. Yeah.

I

Time's up times that won't Philip I think that's a very important, very important comment. We have to be sure that we end up with not the less robust protocol coming out of this I think we should. You know, work together and thirdly, look at other protocol implications here. So thanks thanks a lot have the arocs so Belgian Eric, first and.

A

By the way, we're back so scheduled to end it 45 minutes after the error, I'm, not sure what will happen we will find out in about a minute. So, okay.

E

So what makes me cut me off? Okay, hello, Anna! No! This is a ring rank here, also on slide six, it's typical for wrought advertisement to be sent multiple times by the router, because all the messages and all the UPS in the route advertisement can really longer than a single array. So it could be common that one pair we send in rutterbat iseman one and another Pio is sending rutterbat Iseman number two, so different, whatever ties one from the same router.

E

Furthermore, there's also possibility that and quite common nowadays that uncertified multicast it arrays and not sent every minute, or so they are sent much longer when the frequency is much higher, simply because we want to reduce the numbers of multicast array. So basically the assumption where you buy this was a graden is maybe need to be reviewed right. Oh I,.

B

E

Differently, but from the same routers in different areas and frequency as much lower than you expect.

F

Actually, the the two algorithms consider this like, for example, both algorithms considered, like all of the options, might not be included in the same message.

F

That's why, for example, in this algorithm that is described in this slide, we don't set the preferred lifetime to zero right away, but we set it to in this case to five seconds, because we are assuming that if the router is splitting the information into multiple arrays, then that time of five seconds accounts for the received of those different arrays, for example.

F

E

In this case, in the case of the multicast array, you can miss it by Wi-Fi. There's another issue right multicast over Wi-Fi I lost.

F

That's correct and there are two things like: essentially, you can accommodate, for you know to those cases by setting these two values. You know they prefer lifetime that you said the PIO and the lifetime that you said the a ballad lifetime. You said so in this case you could say that the five seconds is more aggressive. Now, if you wanted to accommodate, for example, to two other cases like you know, when the options are split into multiple messages and the packets are lost, etc, etc, etc. These lifetimes could be increased.

E

Okay and then kind of defeat purpose of your trust, any we need to work on this. That's basically my point. Yes, if you're aware about this, no more multicast and chaos and from the similar than different arrays, then looking back on this further.

F

I checked with team and I haven't seen myself any case where they are actually sent in multiple different arrays.

F

Obviously, there's a trick.

G

F

You can react more.

E

My understanding is that your draft is basically a host behavior, not the route, the behavior, so you cannot infer, but whatever we want to. Okay.

A

E

I

Think we have one last comment from Richard Patterson, please go and then we'll end.

R

So on the topic really I, think I was going to reiterate, fernando's I, guess beyond how the videos are generally seen in the same array, but it wasit is supported. It could be in separate ones, but also we could look at triggering rooted solicits, perhaps including the PIO option in the solicit. It's a bit more of a I guess a reactive approach, as opposed to just a committing timers.

I

We definitely have to continue this on the on the list, I think and- and do you know some thorough reviews and discussions on this I think that has been very useful Bob. Do you want to see the save the year? Yeah we'll run our time, so we skipped for normal second sessions. We have to do that on the mailing list, but the Bob do you want to see, say the farewells and summary? Yes.

A

Thank you yeah. So thanks for everyone for joining Olli and I will talk about whether we want to schedule a second interim meeting. I think this generally worked pretty well, we could do the talking and then there were some other things we had queued up for our ATF 107. That obviously haven't happened, so we'll we'll be back in touch on that I think the webex and general work pretty well so wish you all.

A

Everyone be safe and well we're living through some very interesting times that I think we'll all remember for a long time. So thank you very much and take care.

I

And next time, we'll promise to do a hammer.

L

I

Care of everyone.