Internet Engineering Task Force 104, 28 Mar 2019

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF104-INTAREA-20190328-1610

Description

INTAREA meeting session at IETF104
2019/03/28 1610

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

A

B

C

Welcome to interior light today.

C

C

So thanks all for coming, this is in theory at ITF, 104, the node well assume or I must know by heart like this time of the week.

C

So keep in mind that everything you say is on there ITF rules and we are. We have to comply to the ITF, only season procedures. So, as a reminder, minutes are taken, I mean the meeting is being recorded, your presence will be locked and the scribe. Please help describe to contribute the minutes. You have to let the link to the etherpad so Ron Bonita. Thank you very much for taking the minutes, but his also going to be presenting.

C

So if you can, can we have some mother volunteer to complete whatever is needed, someone else just for yeah, the ten minutes when run is going to present. Oh, thank you very much and if you can love your name on the ether pad it'll be appreciated. Thank you.

C

So blue sheets are going around, maybe not takers decided and Michael. Can you help us with the jabber? Thank you very much. I knew so for the jabber. Actually, we have at the date tailor that has asked specifically to get his presentation at the end because he has a conflict on the agenda, so he asked us to get a clue on the on the jabber so that he can run from there to here. So, if you can just say, goo is starting.

C

I think is the one before him and then he just give him a heads up. He will show up. Thank you. So the agenda will give you the quick update from the church lights. Then we'll have the provisioning. The mains are coming poly, presenting this time the Sox protocol from blast.

C

Then the probing interfaces Ron is going to give that generic multi axis convergence, encapsulation Jing Tom, will give them the GUI again. It was moved to the end from request and this this one was from Dave black David black, because he also has a conflict and, at the very end, we'll have Dave Taylor so a lightly different order compared to previous sessions, but mainly to accommodate people's and see blood, is arriving so perfect. So any comments bashing on the agenda.

C

On presentation, six.

C

Davis last so yes, if we can give him a heads up when who starts maybe calling his name out or something all right, so we have some updates. The fragmentation considered fragile, has been submitted to iesg for publication as BCP the other two documents that we have our generic UDP encapsulation int area. So we'll hear the presentation and the discovering protein domains also is on the agenda for presentation. We have one more announcement.

D

Just a quick note, draft carpenter, limited domain has been updated and Brian asked for to post feedback on the meaninglessness. He couldn't attend this time. Yes,.

C

Please, thank you. So the first one is Tommy Polly.

E

Alright, hello, everyone, I'm, Tommy, Polly and I'm, presenting our updates on the provisioning domain drafts on behalf of my co-authors, Eric and Pierre, and David and Lincoln, so first just make sure everyone's been paying attention. Keeping update I'm going to give a quick overview of how the protocol is working and then talk about the things that we've updated: the things that we're going to plan to update and the rest of the stats there.

E

So what we're defining in this document is a new are a option for explicit pvd's pvd's are provisioning domains that were defined in the multiple interfaces architecture.

E

The re option provides a PVD identifier, which is a cutie n pet name, encapsulate s-- other re options that are specific to that named PPD, and it may or may not be tied to the other information, that's advertised on that network via DHCP and then separately. This document also defines a way of fetching additional information about this provisioning domain.

E

This is available in JSON and it's retrieved from an HTTP URI and, amongst other things, it gives you the v6 prefixes that are provided by the PVD and that can help you detect some miss configurations on the network or help validate the configuration you do have just look at the format. Here is the current format. From the document of the PPD option itself, we have a sequence number to detect when changes are made. We have the PBT ID itself and then it contains other RA options within that.

E

We've gone over this before, but just here's a different way of visualizing kind of the relationship of different pvd's that could exist on the network. This is a complicating example to be exhaustive and all the different combinations and how things can relate from a client's perspective. So in the first case, let's say we have some arias coming from source address. A I could have multiple, explicit pvd's coming all from the same source. Address that have are named differently.

E

These can be related to DHCP. If there's a legacy flag in the RA option marked. So we could tell that these BSP options belong to all the information that comes along in this explicit DVD and that can be further related to any of the additional information we provide.

E

I could also have another source address, that's giving me both dhcpv6 as well as Ras, and those could also be linked, and then I could also have any other source address that I get information from can be implicitly treated by the client house as a PVD, even if it's not named so. These are kind of like the ecosystem, the zoo of all the different ways.

E

The client can detect these different provision, new domains, and each of these groups on the right are domains in which we would have separate DNS caches and the ways of using source, addressing here's a overview of what we have in the mandatory part of the JSON registry. We have a name we have when this configuration expires and the list of prefixes mentioned before. We also have the ability to extend this, and we list a couple of the optional attributes that can be added to this JSON registry.

E

So that's the overview as far as what we have updated since the last IETF, we added a section discussing the use of DNS within pvd's. A lot of this is already kind of implied by the PVD architecture, but we wanted to make it really clear when you're, using explicit, pvd's dns configurations that you have must be used in an isolated way per PVD. This helps you manage the split DNS scenarios that you may have.

E

One other thing that we call out is that you, this is not meaningfully improving the trust of your DNS provisioning.

E

Although so there's been discussion- and it's been brought up here before that, as we have more encrypted dns mechanisms like DNS over TLS or doe, there's a desire to have some sort of authentication about the validity of these configs.

E

Potentially, you could see this as a benefit. If you have a PVD that advertises a name and then, as we are fetching the information we can validate the certificate and the at least the authenticity of this name, that's being provided, it's currently not done in this spec.

E

But if some of those DNS mechanisms like doe, wanted to use pvd's to provision those DNS servers, they could potentially extend the attributes in the JSON format to also have ways of saying yes- and this indeed is my secure, DNS server and some way of validating or signing this information. So it's a tool, but this document itself does not provide the end solution for that. It's a stepping-stone along the way and there's also some asks for clarification and improvement of the rigor of our language in the IANA requests.

E

So we clarified the request for registries, so the two names of registries were asking for our additional information. Peabody keys. This one is proposed to use expert review to add entries and then there's the PVD options, flags, which is the options within the RA the flags within the RA option itself, and that we're saying will require standards action. We don't expect that would need to be updated very often and that's much more important to kind of have locked down.

E

So that's about it. On updates. Eric actually gave some thoughts to the list about how we can improve some some of the uses of our suggested headers and stuff. So if you want to summarize those that'd be great at the mic, I think we will kind of incorporating those other than that we have done Interop with this. We've used it for captive portal stuff and that's gone well. We believe the documents pretty stable will incorporate this, so we'll definitely want another Rev, but once we do that I believe the authors are all looking for.

E

A working group last call on this in to get a nice serious round of review. So thank you. Please share your thoughts.

F

Eric Cline, let me just do as you, as you asked, I think I said, for the inner are a header.

F

Why not just leave it alone type the code already has to be 0 type could still say 134, we could say the checksum has to be 0, but we could also say everybody has to ignore it, and then I was I also said, I kind of liked what they did with the universal IRA option, having JSON and see more options and preserving IETF sort of namespace and then also mentioning and or recommending ex foo is contrary to RFC six, six, four eight right which says I felt not so you just want to get rid of that recommendation.

F

E

F

Yeah I don't know, although what we would want to do for well, so that's actually, where the ietf prefix of things yes would mean. Other people could do other things. I I don't know how that actually works with six six. Four. Yes,.

E

So we'll do our homework on that essentially he's saying, rather than having the reserve namespace be the one with no prefix and make people do X for extensions. Take the IETF prefix for the document, ones that let people do whatever they want. Otherwise, and that's I think uh it it's a thought. It's.

F

E

Way to go, we appreciate that I, don't know if it's good or not, but.

G

Michael Rosen so well, I think this work is important. I think it's needed I'm a bit scared about. If we have understood all the ramifications like how to do this, and so on, you were talking about, you had done experimentation e captive portals. Yes is there! So if I read the captive Porter, we wanna find some description about what you have done. What actual code you've done.

E

G

Draft, it's not in.

E

The core architecture drafts, but it's referenced by them and it sort of crewmates an individual draft. It's slightly blocked on this actually having that be a real thing, but it does describe how we use PVD discovery to bootstrap cap deferral discovery and that's essentially what we did in our hackathon work. Okay,.

G

Those who was, it was a hackathon project. Yes,.

E

Good also, and what was it dislike- I thought it was not this one. It was a previous one. Okay, thanks that you to go yeah all right, so any other thoughts I know. Can we get people to commit to a review?

E

Yes, thank you. You will will make some updates if you could check the new one. Anyone else how many people have read some version: okay, how many people have read the recent version? Alright, so we'll pull based on your comments, repost and then we'll ask for review. What do we think about last call status after that? What's your impression juris? Well,.

C

So so far, indeed that the document is rather stable and we have to assure our getting to the queue we had asked the the security Directorate for for comments and we haven't heard from them. So that could be something useful. Two to three.

B

Campaigns and feedback before.

C

Before we go to to other stuff and then we have suresh on the queue.

F

B

Hey Tommy: hey thanks, Juan Carlos, that's like Prada, pretty much. What I want to talk about so I sent like multiple reminders to the sector: people the the chest has requested to review and I talked to Icarus. Also like it's Icarus, like you know, rolling off the iesg this week. So I'll talk a little bit to Roman as well to make sure that this gets done pretty soon, because it's been like I would think. Like its order of months like six months or seven months, we're.

H

I

B

I

I, remember correctly.

B

Okay, so, and so I'll just make sure this happens quickly. Alright.

J

Thank you so much thanks in response. Thanks great all,.

K

C

Thank you very much.

L

All right so I am glad and I'm going to I'm going to give you an update on our latest work on Lux v6. So in the latest draft we've introduced the concept of Sox sessions. This is exactly what you will expect. You gather a number of requests under the umbrella of session, and you expect that we expect there to be shared state at the proxy as well as at the client.

L

Now, shared state has been done since revision 1 of the draft, but it was done on a per user name basis, but multiple use cases have turned up, and this seemed like, like an elegant thing to go forward with so the first use case is tour now, as you can see on this slide, I'm visiting Wikipedia I'm, looking at the web pages for dogs and cats. Now, for various reasons, tour gives you the single circuit per bar domain so and the way they do it in a way that the tor browser does.

L

This is that it encodes it's the bar domain in the user name field, so it basically makes non-standard use of username and password authentication and there's also an option to change the circuit used for a particular site. The way that this is done is that the browser starts using a different password telling and the Tor demon gets the hint and starts using a different circuit. Now our sessions are a very elegant way to handle this.

L

The next use case is shared credentials. So let's say some someone has a couple of two different browsers running on their machine. Now. If the two browsers are using the same credentials, they are gonna have the same view of the token window. So here we've got X&Y hexam I think that the window is took tokens once 100 and X starts by spending token 1. There's some time passes. Why has no idea about what X has done so it tries to spend token 1.

L

Of course the token is out of the window and it basically wastes 1 RTT be copper before it can read the request. So at best we are gonna, see occasional wasted ITT's. On one client or another, at worst, one client can live lock. Another one, so few X&Y have similar aggressive workloads ever ex gotta head gotta head start and it got to spend it's tokens ahead of Y. So here, Y is only chance of of being able to spend successfully spend the token and have requests on earth is to be more aggressive than X.

L

Of course, if, when talking about buying backlogs, the clients using the same credentials can basically accept connections from that some other client was listening for and authenticated. Clients cannot make use of any fixtures that make use of shared state.

L

So we've decided to move the the share features using making use of shared state from we've decided to do it on a per session basis, rather than on a per for user name basis.

L

Now the the mechanism is rather simple, so the client asks the proxy to create sessions or to tear down sessions, and the sessions can also be torn down by the proxy whenever it feels like it either due to timeout or whatever, for whatever are the reason now, all of these options are part of what requests and authentication replies, so the grtt between the proxy and the remote server plays no part in their timeliness. So such sessions are rather straightforward.

L

So, aside from the kind and next fields that all option options have we have a tag field which signifies what kind of session option we're dealing with, as well as a option data an option, data field. Now what these types are is going to be crystal clear after I go through the next few slides and the option data is only used for conveying the session ID so establishing your session is rather simple, so the client places the session request inside its own stocks request.

L

It does the it goes through the authentication process if needed, and then the proxy replies with a session ID. The session ID is opaque session. It's no big sequence of bytes and the proxy is free to place anything in it, so it it can be just an integer. It could place some information and sir and encrypt it and sign it. Anything goes now. This first request is also part of the session that it initiated. So the client is free to make use of whatever functionality.

L

That requires the session, so you can request a token window. It can request the lesson backlog or whatever else now. A subtle implication of this is that you cannot initiate the session from within a session since the session request, since the request making the session request is also part of the session it initiated off for the request carry the session ID, this completely bypasses authentication and proxy, or replies with a session ok option.

L

Now, if the proxy doesn't like the session, ID authentication automatically fails everyone if the proxy does not require authentication in the first place and the proxy signal set by including a session valid option session teardown is also easy. So the client places the session tear down option and tells the basically Emma complete, tells the server that the session is no longer needed and it can delete all associated State. The proxy, of course, should maintain. It should keep some kind of timeout timer in case the clients, isn't friendly or the client crashes or whatever.

L

Now we also have untrusted sessions, so the session ID can easily be sniffed by a passive attacker and thus that the attacker can just hijack the session and bypass any authentication mechanism that are in place when a session is untrusted. The client must authenticate every time it makes the request. That's part of that session, but the very same we with this very same credentials that it's used to initiate the session. Now this is a bit of an open question.

L

Do we actually need this feature, because my my general policy has been that whatever can be done by running socks over TLS I'm, not gonna, handle in socks? So I'd, like your comments on that I kind of lean toward removing this feature?

L

We've aside from myths and other quality of life, changes for implementers that we've made in draft O six. We also done some future proofing so now, options have a 2pi length field, so you can place whatever you want inside of them. They are still limited by the next maximum number by the maximum options link. So you can out not have more than 16 K of options inside the message, but otherwise options have no individual options, have no limit on their length, so you can place certificates, JSON dumps of the proxy configuration or whatever.

L

So if you, this was done so that whatever other options, the IETF decides to standardize in the following years, they should be able to.

L

The semantics behind authentication methods have also changed, so socks5 stipulates that authentication methods can also negotiate some kind of encryption and that the data is encrypted now, in order to keep backward compatibility, we still allow them to negotiate encryption, but isn't it is no longer honored by Sox itself, so if you want encryption, run Sox off or TLS over over some other encrypted tunnel, and that's about it for me. Thank you.

L

C

You very much any comments or blood.

C

Okay, thank you.

M

Okay, rambha Menaka, Juniper Networks is a very short sweet presentation. Probing IP interfaces by virtual function, interface next slide.

M

Okay, this is an extension to probe RFC, 8335 and probe is the utility it's used for probing the status of basically on numbered interfaces. It's for pinging, an unnumbered interface. What you do is send an ICMP extended echo message to a proxy interface, and in that message you identify another interface, the probed interface, the one that you're really asking about, and the proxy interface gets. The message looks for the status of the probed interface. It's generally co-resident on the same device and answers and says yeah the interface that you're asking about is up-down whatever well.

M

In any event, we've had some success with it. We have an internal implementation inside juniper of RFC 8335, and we have a guy Oh sooner or later, that'll become part of our product. We have a guy working on checking it into FreeBSD checking it into Linux, but in any event, as we were doing this, somebody had a request right now we can identify the probed interface by address by interface name or by if' index.

M

The request was well I'd like to identify the probed interface by virtual function. Identifier and Jen says well, what's that? Well, in some PCI environments, that's a way to identify an interface, it's kind of like a if' index just in a different environment, so very short, sweet draft. We have a registry of all the ways that you can identify the probed interface. We need to add another entry to the registry.

M

And that's it we just need it's. A I could have read the draft to you while standing on one foot so not much to see here. The draft is only one one. You know five pager, please issue a call for adoption, and maybe we can get it through quickly.

C

Do you want to read it now.

N

So everything, just as a integral contributor here nice to see this RFC 8225 implementation. Could you tell so much which are using link-local only addresses yeah? Oh.

M

And by the way, more is coming in praise of link local addresses. We, we believed the only reason people aren't using unnumbered interfaces or link. Local only is because you can't ping them. This allows you to ping them.

G

Micro rooms that you should not make their statements, if you want to keep it short.

G

So I I know people who worry all kinds of worried about source address selection of the devices when they're making out I was going connections to whatever zone, so there's a lot more than them, pinging them, but yeah. This of course helps. But how do you determine and and interfaces is up like this- is just the highest status of the link.

M

Exactly I have to okay.

G

You have no idea if you can talk to anything or if there is anything there is just that the driver sets that the interface is out.

M

That's all ping goes when you ping an interface there's no guarantee the ping came in that interface and there's no guarantee the response came back out. The interface okay.

G

All you're doing is clearing the driver if the device is not going out that interface. Yes, right.

O

Yeah yeah hmmm.

M

Okay, so that's for reviewers! That's for call for adoption, yeah.

C

So any volunteers to review the document provide comments, hey Fred Eric. Thank you. Thank you very much.

C

We have zinc on the cube.

P

Hello, okay, you hear me yes,.

C

Loud and clear all.

P

Right great yeah, so this is Jane I'm happy here to present the introduce the draft on the generic multi-access protocols, and this is incorporation with sorry.

C

P

C

Getting a little further away from the mic it's getting too loud, then okay,.

P

Okay, how about now is it better yeah.

C

It's much better thanks. Okay,.

P

Yeah so so first talk about the motivation for this draft. So previously we have been working together on this multi access management services. I think the draft is almost finished and is right now going through this informational track in that draft. Basically, we are introducing this new framework where we can support management across multiple access.

P

For example, you can do pass adduction pass aggregation splitting switching and for that we need some kind of protocols to manage this process on the data plane. In the framework we introduced three options and the first option is the layer 4 approach using multi pass TCP and later on. We also add the multi pass quick and on the layer 3. We have two options: one is the IP over IP tunneling with GRE, which I believe there is some RFC.

P

That's already covered that kind of approach, and we also introduced a new approach which is a light version of layer, three encapsulation using a trailer base, encapsulation method, and so this draft is many to address this particular option, because we believe that myself is a fairly big topic. However, this encapsulation method is standalone, I mean itself can be reduced to scope. I. Think one of the feedback we got in the last presentation in the ITF is that the MEMS itself is quite complex topic.

P

It will take some time to actually moving forward, so the the and then there's adaptation layer. So the a temptation layer is just to send these convergence PDU over individual radio net access network, and then you can use different tunneling approach. Udp, tunneling, IPSec and client net address translation and pass through.

P

So those are just existing methods that, without requiring any additional protocols, ok next slide and in parallel there is efforts happening in 3gpp architecture group si to trying to define a solution to support access traffic, steering, switching and splitting switching a steering which is somehow aligned with our vision for the amounts, and this picture just showed one of the option to support a layer 3 aggregation using the Twitter based convergence method.

P

However, at that time, because the draft is still being defined a ITF in an early stage, so this part of work also being considered in the technical report. 2 3 7 9 3. If people interested definitely welcome to take a look, but this part of solution has been a kind of pause, a halt waiting for the IETF discussions, so you know, in other words, there is also a need to define a layer, three protocols to support multi access of multi, pass, aggregation or splitting.

P

P

So this is kind of a conclusions that I got from the at least er. Not yes. Basically, in the PR there's two type of solutions, one is layer 4, which is multi pass TCP at a time, and then there is also a TS as a function that is sit at layer, 3 or layer, 2.5 right below the IP, and at that time the discussion is that it needs the ITF to complete a draft and publish the protocols.

P

Then the suite EP can actually refer to this this work, so that is actually motivate asked to bring this to this particular parrot, which is the generic multi-access convergence encapsulation protocol as a standalone draft and call for kind of interest, and so, if we can get it adopted a working group documents so yeah. So that's kind of the other part which is in 3gpp. We also feel there is a need to define a new protocol to support this multi access management. Yeah thanks, like.

P

Next one yeah, so so in summary, the problem that we try to address is that we are seeing that access convergence operation at the layer, 3 is becoming very important.

P

Previously, this kind of operation is many support at the metaphor, for example, multipath TCP what he passed quick, but those of solution typically have a dependency on the OS on the applications. By supporting these factors in a 3-2 defeat.

P

Traffic and currently.

L

P

To use IP IP company by including this header information in the gie header, like, for example, sequence number, so so in this case the drawback is first of all, there is I py p turning overheads and also it is very difficult to introduce, because channel attack renews it for other purposes. So it's very difficult to to introduce new field yeah.

C

Yeah yeah: we have a couple of questions so.

G

Suresh said: don't do that, okay, instead a fresh road to me instead I said so. The encoding rush from the driver, the the mentioned 3gpp document, is not a TS, as he mentioned. It's only a study item. Yes,.

P

Yes, that's what I want to clarify it's a typo.

P

D

P

Call a stage three work is actually.

P

If this draft finalized some solution, we can develop an IETF is finalized. Before that the stage three work also called the ETS work, it is finished, then the solution can still be considered.

G

Okay, so one more comment from thrush here he says that it's not accurate to say that 3gpp work is blocked on IVF.

P

No I'm not saying block yes, nothing block, I'm, just saying solution that the only way consider it in 3gpp is that because we don't define any IP protocols in fact, rather than reference to ITF work. So in order to moving forward with this particular solution in 3gpp, we will need IDF.

H

P

So yes, I talked about this encapsulation.

P

Basically, what we.

N

P

N

That new encapsulation.

P

Not using a trailer based encapsulation- and this way we could add all the information at the end to avoid any IP IP tunneling, and we also have the flags to customize information which includes in the trailer.

P

This is a very similar to the eyepiece AK es PA encapsulation, where some information, also at the end in the transport alright. So next slide.

P

This is just an example: how we deal with lingo podcast encapsulation. Also, we can do multi packet of retaliation to improve the efficiency and indicate.

J

P

Recommendation especially when the multiple.

O

Access different mq sizes.

P

We can also perform fragmentation and the convergence we're, and this is just show how that can be done with this trailer base. It comes.

P

So, in summary, what we have seen is that to stop all the so-called multi-access convergence. Currently in ITF mam's of 3gpp, a TS SS has been developing solutions. Currently, in order to support aggregation, we only have to approach. One is at the layer: four. We can support either multipath TCP or multipath quick and the layer three, it's basically using reusing the GRE header and using IP over IP tunneling. So in this case we are focusing on layer, 3 solutions.

P

Instead of reusing the GRE header, we are proposing a new convergence protocol or encapsulation protocol based on trailer based encapsulation, and this will give us a flexibility to introduce, enhance the features as well as why avoiding any kind of IP IP tunneling overhead. And hopefully, if we can get something done in the IETF, then we can bring this back to 3gpp to have a layer, 3 aggregation solution, also being considered in the TS face.

P

So I think this is my last slide. So I guess thanks.

J

Thanks so questions comments, um Tom Herbert have you looked at goo? Yes,.

P

Udp encapsulation, yes,.

J

It, as you said, you don't want to be forced to nighty night Enoch. Encapsulation goo can do other forms of encapsulation, so it doesn't force you into that model. Yes,.

P

So IP over IP or any like layer for tunneling as well like UDP tunneling right. So this kind of encapsulations is try to avoid adding additional header at the beginning at the beginning of the packets, to avoid this kind of over hard. So I understanding that UDP or generic UDP encapsulation is also doing something like that and.

J

Why we see a lot of encapsulations using UDP? That's because it's compatibility with a network. If you introduce and IP protocol, you have absolutely no compatibility on the network. Devices may or may not even pass it, so it wasn't that we really wanted to do this in UDP. It was more like UDP gives us the best framework and the most compatibility with a network at a cost of a whole 8 bytes. So was it it's a trade-off that we've made in a lot of cases.

J

So from that point of view, I'm not exactly convinced that we need another transport protocol.

P

Ok, so I think probably I should clarify it. It's not really a transport protocol per se, because if you look at the the framework in the both MMS and ATS essence, they do have their own transport. So in other words, you could still do I P over IP tunneling if it is required, depending on your network right so also you can do in UDP, eternally like we have. If we can go back to the slides, 2 or 3 I believe there is.

P

Maybe can you come in, but go back to the slides too, and we have storage in the queue slice.

P

Yes, so you can see the way that we do. This is that we divide into two layers: the the convergence layer is really just responsible for aggregation and all those management purposes, so there for encoding those additional information and then and the individual transport we're doing the UDP donnelly options. If it's needed some time, you don't really need.

P

We have been testing this over, like a legacy devices by introducing a new IP protocol type or even just reusing, the existing IP prototype fact most of the layer to kind of switch, and then we have the IPSec tunneling or the other type of adaptation layer like like method, so I guess terrifies that refer to our points of the transporting the UDP Ptolemais is supported. Okay,.

J

P

Another question: why.

J

Go with the trailer based protocol everybo-- everything else is headers. Is there a reason for that.

P

Sorry I think it.

J

Is trailer based, GMA encapsulation? Why trailers there's a very, very hard.

P

J

P

Yeah, so the reason we want to use the trailer is that if we need to give anything at the beginning, then we have to do an IPO like eternally just like what we did with GRE right, but.

J

But you don't, you said you were introducing a new IP protocol, so the IP protocol could just say or a new protocol number. This just says this is the format you have this header before the payload. So then the client in your header row.

P

Yes, I think what you're referring to is that you can also introduce any information at the payload at the beginning of the payload right. Is that what you say.

J

Yes, just like in it's a header right, so you have header followed by Paila. This is the common convention.

P

J

Have to hop around it's really hard to process that from my protocol processing point of view. So unless.

P

There's a good reason: keep.

J

Stuff in the front and headers.

P

Okay, so I think.

K

What you're saying.

C

P

If we want, we can add the beginning of the IP header, because otherwise we have to add another IP header to encapsulate this right. So if we, what? The point is that we gonna add this information, IP header and the payload that is actually violating the protocol stack because after IP header is right. So if we go back to the last slide, if you go to the last slides, can we go to the I think there are some backup slides which show yes in this case.

P

So this is how we do this in the IP stack right. So there is information being searched at the beginning of the data as well as the end of the data. The whole point is right. We are looking at the transport in this case. We keep the IP header at the same and then then we just introduce the new information there right. So in our case, we really don't need so many information, so we just add all the information at the end. So this way the layer four header is still right after the IP header.

P

If we do something like ESP header at the beginning, then it will be hard for the host process for the two. If we wanna do anything back inspection, then you have to add this offset right. So so that's something that we want to consider, but obviously we can also consider I mean if there is really a need to insert at the beginning of the payload. We can also add that.

Q

Data paths, because the location of the ESP Trevon location of other trailers has quite a bit to do with what the data path has to do so on this diagram. Here, the crucial thing to observe is the authenticated double arrow, which is a second one under each of those. That authenticated indicates that the receiver is running over the data covered by that double arrow and is calculating and is calculating a Mac, a cryptographic integrity check. If you think about how data path has to work, you want to run get to the data path once so.

Q

You want the receiver to go running down data path, calculate that check, and then the trailer shows up right right when the check is has been calculated, you compare them and figure and figure out and figure out whether it worked now. The what we have here sounds like a forwarding data path where you'd like to know where you're going to send the packet as soon as you possibly can, as the packet shows up and how you're going to deal with it without having to wait for the whole packet.

Q

The show up and discover in the trailer how you intend to deal with it so long for, for those didn't, follow every detail here. Esp is a bad examine allergy unless you are doing some kind of integrity, check or other pass over the data that is required to correctly process the trailer CRC's in Easterner trailers. For the same reason,.

P

Let me reply to their comments. First of all, the the the purpose of this trailer is not for deciding which paths to use. So there is a separate compute logic to decide every each packet where they go regardless of how you do the trailer encapsulation.

P

The main purpose of this trailer is to carry additional information, in fact, for example, sequence number: when we split the traffic across multiple paths, then we can perform reordering operation.

P

You get this from the trailer and then perform reordering, and after this information and.

P

Q

So at the sender, you've got quite the flexibility of weird where to put what, because you're assembling your something the whole packet and everything else at the receiver, the packets moving onward. If that sequence number comes early, it becomes easy for for an equipment designer, say ooh. This is the expected sequence. Number I can cue this thing up and pipeline the packet out and get off my hands now, as opposed to with the design here, you're you're, basically forcing a buffering stage.

P

Even I mean the idea here is that the you have to get the whole packet to do the reordering. You won't be able to process this packet regardless, like if you just get a partial off the packet. Let's say you get first, first part.

Q

Of the inbound agreement, if the packets out of order you've lost one round of the game, and you must buffer to reorder, however, if the packet is in the expected order, it is possible to dump it through a fairly shallow, shallow, shallow pipe and out of here now, as opposed to paying storm forward buffer. There are hundred designs that do this in this space and others.

P

If, regardless, if it even is in order or whatever, then you still need to recover the whole pockets either remove the ESP header like here or because pocket you can send it out.

P

Q

Hardware, that does think you're claiming or impossible I think we're in agree to disagree.

G

Suresh had another question, given that MEMS is not on the ITF stream and has moved to the independent stream. Is there any ITF work that will use MEMS.

P

I think that we refer to is the MMSE ITF, but we do, as I mentioned, that we we do have the reference which we talk. You must try to use this, so the plan is that if we can define something here that we will be able to refer this as to 3gpp next release,.

C

R

M

C

So we move now to the next presentation.

C

C

Yep, so can we give a heads up to they fell it just the other day, Dave Taylor? No, no words thanks thanks. Yes,.

J

Thank you. Okay, I'm Tom, Herbert I'm gonna give an update on goo.

J

So we had some substantial reviews from Charlie Perkins David black Gary Fairhurst. Thank you very much. There were very good reviews. I think we're getting a lot of good feedback, so most of this presentation will be responding to those reviews. So I'll split the comments into two major sections. I tried to extract the most operative comments, so these are the clarifications and then next section we'll talk about a few more in depth. So Charlie mentioned that we needed an applicability statement that is in version 7 now. So please take a look.

J

One of the comments was: how do we prevent middleboxes from filtering based on gue options or good data and I? Think the short answer? Is we can't in some sense anything we send in plain text, is susceptible to middle box intrusion and middle box detection? What we do, though, is we do say: middle boxes should not look into the good payload or goo header. We also say they must not modify any of the UDP payload and we have the ability to authenticate the headers from modification and for the most secure setups.

J

We could use DTLS over the whole payload or GU frame, so would even be seen. David mentioned that we need a reference to draft an area tunnels, so we will add that in the next version.

J

J

We needed a normative reference to the gue extensions. So sorry.

Q

The car made from the bleachers dated black the draft interior channels isn't just a reference. You need a reference and some you need a you need a reference and some discussion based on the content of that draft. Okay, yes,.

J

Actually look through it most of the most of the things we covered already I. Think if you want there's a few things that aren't applicable, we need a normative reference to do extension, so there's a base go draft which we're mostly talking about here, two extensions, which is also in working group last call so there's a mistake in the last version of the draft that did not provide the right reference of where we pointed that out, and there was also comment that we are lumping tunnels and encapsulation together.

J

So this may require just a bit of clarification. Goo is an encapsulation protocol and it encapsulates by IP protocol number. So any IP protocol can be encapsulated in goop. Tunnels really are when we're encapsulating a packet IP ether IP that so this was kind of specified in the document, and we do have a little bit of handling for both those cases. So that might just be a terminology. Clarification.

J

Thank or he has a question.

S

Going first a bit like David I yeah, maybe you need more a little bit more text. Explanation about it because I see the two aspects. Yes and I, see you talk about two aspects, but I don't see a clear separation in your thinking when you describe the two aspects, I have different things. I would like to check off in the two different ways. So it's more than just kind of casting it aside and saying: okay yeah! So.

J

Well, I think they need definitions exactly what they are and then we can do some elaboration.

J

So therefore issues that I wanted to give a little more comment to the zero UDP checksum and ipv6 congestion considerations, condition controls the wrong word and then the question about it: GU being too flexible and extensible, and then why proposed standard so UDP a v6 checksum? This is something that has to be handled by all UDP encapsulations per RCA to 200 UDP checksum is always required for ipv6. However, that was relaxed by RFC 69 3569 36, under certain conditions. So the rules in goo- and this might not have been clear but there's three possibilities.

J

One is use the UDP checksum for both ipv4 and ipv6. That's actually the recommended approach. There is something in Google called a gooch exome. This is in the Akoo extensions. It does include a pseudo header, so it is an acceptable replacement, I think for the UDP checksum.

J

If neither of those are used, then we have the fall back to we're using a zero UDP checksum without any checksum covering the IP addresses. That is where we would talk about 69, 36 being applicable, so I think your point, David was basically that we didn't have enough description of the provisions for going to 69 36. My so my thought is we'd already did this in RFC 86 8086 for a GRE over UDP. Most of that should be applicable in this case. So I was thinking about cut and paste yeah.

Q

That's good I mean yet yes, and, and you got you got it right, the the the thrust. The complaint was a was a show, your work complaint, so it requires some design thinking, although if you had, although the go checksum should be, should be incredibly useful because the goo checksum gives you an out from the conundrum that is causing zero checksum headaches elsewhere, which is either you turn on the UDP checksum and it cost your pass over the entire data or you turn it off. You traffic goes.

Q

Heaven only knows where, and the goo checksum is is just is just a slightly larger head of header checksum. There.

J

Is one caveat that makes us interesting, so the UDP checksum works with net. The gue checksum doesn't really work with net because we don't learn. Middleboxes modifying and.

Q

We can have weight and- and we can have a bug versus feature discussion over some fine Czech beer anyway,.

J

So we have congestion considerations. Unfortunately, this was miss named in earlier versions of the draft. As congestion control goo does not have congestion control. We were trying to go for congestion considerations.

J

This should be nearly identical to RFC 8086, where, if the traffic is not congestion control, we have to have provisions within TMC a traffic management control environment. We should be able to apply the same rules in GRE over UDP, so again, I think that might be cut and paste from RC 8086 should.

Q

Be addition, I forgot my Zacapa my previous times david again to give you and probably gory something else to look at because we're working through some say these issues. I think particularly zero checksum with the genève draft in NV o3. So you might also look there for some useful text. I just got finished working a review of that one. So.

J

Hopefully, they're all all all UDP encapsulation should be kind of the same right. They.

Q

Should be similar, what's going to happen, is that some of the requirements in 69 36 are design time requirements in essence, 69 36 says: oh, it says, put on your thinking cap and make absolutely positively sure you understand the potential consequences of packets going to the wrong place and have come up with the best you can do for this protocol to mitigate them. So it isn't quite copy/paste but this book, but there is some more design. Thinking involved. Okay,.

S

Plus one think about what you wanted to global only in a controlled environment, if you make big, cleanse or then write text to clearly explain why it's not just for a controlled environment, so.

J

The the rule is I think if it's, if you're using non congestion, controlled traffic in a controlled environment, here's the provisions to allow that do not use non congestion, control traffic outside on the internet or externally. If it is congestion controlled, then by all means use it. There is one difference here.

S

By the way, I'm not mean enough to try and get you to compose a sentence live in front of us, so I'm quite happy to totally afterwards, because yeah I accept those different environments and you just need to be really clearing your applicability.

J

Yep so and then let's talk afterwards something yeah, there's a subtle and.

Q

8086 also has the framework that you used to do TMC and non TMC, and one of the things you can think about is whether to allow zero, UDP checksum for ipv6 in the general cases possible to say that you do zero checksum. Only in a TMC ebin general you've got flexibility. The end ata six has the framework with both environments and and give you some idea of how to write the applicable. These take me to figure out what's going on right, so.

J

I'm saying and most.

Q

J

Can be transferred, was.

Q

A little bit of design.

J

Q

I have the scars from getting adv six done, they're actually valuable.

J

Okay, so moving on, there was a question about flexibility and extensibility a little bit subjective, but I will point out that there's two parts, I guess to be inflexible or extensibility and go one is we have a concept of extensions and options? One is the protocol types that can be encapsulated so in the first case, who has a saying called flag fields which are very much like giri giri mechanism.

J

If we compare those two tlvs, they are very constrained and the designs will Sophy behind this was that, yes, the protocol is extensible, but we do not anticipate hundreds or thousands of of extensions or tlvs so because it's in this format a lot of the problems that you see with tlvs go away. So there's only one possible ordering for any given set of options. There's no concept here of ignoring unknown things.

J

It's very efficient I mean about the t cam and, as I mentioned, we expect kind of a slow growth of extensibility here, and that's also based on looking at other protocols like IP TCP, that had options and realizing that very few have actually been added and very very few. Have been used, nevertheless, we need the capability to be extensible, so the second part is the protocol field.

J

It was a little unique compared to many of the other encapsulations we encapsulate by IP protocol number, so that includes IP IP ipv6 and the normal things we think of encapsulation, but that also does include transport protocols, for instance TCP UDP SCTP, so that is is on purpose and the document does describe the processing of that to make it saying the basic processing is that the UDP and the gue headers are effectively an extension header in terms of processing such that when the process they're removed and the resultant is the IP packet followed by whatever is after the gue header.

J

That is the resultant packet, and this is I think this is maintains logic or logical approach. We do have to consider, for instance, if we're encapsulating a TCP header, so you have UDP gu tcp, where it is tcp get its IP header for the pseudo checksum, so that has to go all the way back to the initial header metal, so it bleeds into the transport versus tunneling cap. So, there's a little bit of difference: Sara Lee the processing difference.

J

This is all the same and implementation wise, but the what actually happens difference there's also private data in GU, which we do not specify the contents.

J

Anyone can put anything there, however, that has to be agreed by both endpoints network has no no say in this. Hopefully,.

K

Meuk 11, so, as you said, not network has no saying this and has to be agreed. Why do you need it on this layer? The.

J

K

Data, sorry, private.

J

Data, if we don't put it in people, will hack up the fields, but.

K

There's an extension field: you can extend it right well,.

J

So imagine I'm a private entity and I want to try and experiment or do something do.

K

J

We don't give them something extended.

K

J

Extensible but the fields have to be standardized right, so we can't one thing I should mention, so we can't say this flag bit is extensible or it can be used for private uses, because we have to specify a size for everything. So all the flag bits are associated with the size and so I can give you an example. So we try to extend GRE before and what ended up happening.

J

Is people end up overloading sequence, number and checksum field because they weren't used by hardware and it's ugly, but what I saw was we were using those fields for something completely different than they were designed for problem is that's a no, not interoperable. So if we ever ran something against another implementation and both were using these these random bits for different purposes, then that's a problem, so it's like in a sense it's like having experimental protocol numbers so we're just allocating this base. So.

K

It sends a little bit like you try to design something in the blue where you're not except you know what the problem isn't, what it will be used for and I. Don't think that's a good approach and the other point is: if you actually have a scenario we have like two tunnel endpoints that want to talk to each other and exchange data, then you might also want to consider just having a separate control channel for that right. So it's right just like not be a functionality that you want on this layer. At all sure.

J

There's there's a separate control channel.

J

Id, so one one difference: we don't want to rely on the separate control channel, so I want to make it clear that if you receive something you don't understand, it can be draw the there's another reason for this. It also allows us to extend the the protocol so, for instance, that previous description had a very ornate format.

J

So not everything is amenable to be in a flight field. What, if I, just put that in into the field itself? As long as my receivers understand? What's in that private data, then that makes sense now I don't have to go and consume a flag field. These are a precious commodity on purpose, so we only have 16 bits. So we want to make sure that the only things that are actually standardized in these flag fields are things that are universally important anything else. We want to go into kind of specific use cases.

E

K

To solve a problem by adding some more space, and then you will run into the same problem later on again.

C

Okay, so we have suresh on the line yeah.

B

So thanks, so one of the things I wanted to point out tom is that I have like one of the things that Gauri bought off was there's like insufficient justification for a lot of these extensions and because these extensions are present like the the protocol is like too vague and too loosely sculpt for it to like, be good enough for a proposed standard. So one of the questions like that's, actually two questions right. So can you trim some of these things and just like put in like some place for extensions without doing all the extensions?

B

That's one thing, and the second thing is like: why do you think this should not be an experimental protocol, so you go and play with this and come back. So those are my two questions so going forward. Okay,.

J

I can answer the first one, so we did split the protocol specification into two parts. So gue itself does nothing more than define the mechanisms, the extensibility header length and is relatively simple and straightforward. Then the second part is there: are they be base extensions?

J

For instance, checksum we've already talked about fragmentation that that's justified, I think from a lot of other discussions. So the purpose was to break those in into two parts and make that a separate discussion so the base encapsulation is this. It does not define any extensions whatsoever. The first. The next document is intended to be kind of the initial set of extensions.

S

Gouri it's going first, when I read it I had to read the other documents. It was a bit confusing. I didn't realize that there were documents at the time, but I found there was references across there were things that you had here, which you said you needed and they're in the other document. I'm not sure.

J

We said we need them as opposed to you can use them so okay, so we.

S

Can base out and.

J

Simplify it without requiring any of those extensions, it can be deployed with UDP encapsulation and gives you those values the extent so so. Security is an interesting example right, so we do want to have security extensions. Those are not required for every use case, so those are in the other document. However, it's logical to say, since it's extensible I will want to have security extensions and that's how I will secure the protocol.

J

There's a lot of pages of text and I didn't find it that easy to go through them so well, I mean so I think you can also compare this to other protocols. I mean sure this is not going to be different than the engine able to basically do the same thing. There will be a base protocol they're going to be defining a lot more tlvs, because it's designed for a greater number of tlvs. So again, all this to me, the whole question is: is somewhat relatives I.

S

I think cirrage captured my card I'd like to know what the reason is we're doing this, so I can check off whether these are the right set of things that are in there and I trust that the working groups looked at this and that they have that list. But you need to get it into the document. If your.

J

Reason for doing pretty own work.

S

Leach the different options, the the the format you've got, the extensibility of the form you've got I mean so so there's a lot of features. There's a lot of pages, there's a lot of options. They are dependent on one another, a little bit. Okay,.

J

So its own to be clear, there's two drafts, so are you referring to the base draft that defines a mechanism or the draft that defines the first I believe ten extensions on security talking as well as the Securities and the extensions okay.

S

All right, it they're only two documents: two.

J

Documents so there were references to some other documents, as have subsequently been removed to pare it down. So right now, I'll be current.

O

Version 80 have changed.

S

Since I read it only.

J

Ref yeah the current version of the graph. There are two drafts and working group last call the Gugu referee references, the extensions draft.

S

I'm always happy to eat again.

Q

R

Fred template from Boeing, so I just wanted to respond to the question about why proposed standard we're using Huey in four different, very diverse environments right now, we're having it evaluated in a company called free cuentas in vienna, austria, we're running in the Amazon Web service cloud, we're also running on a on a test airplane facility in Everett, Washington and I've got it running on my workstation right here.

R

So it's being used. Okay,.

B

Thanks yeah but Fred. Look if you can stay back at the mic.

B

That still doesn't mix like okay, so there's like lot of experimental protocols that are implemented and running right. So the question is, like you know: what is the right level of extensibility required for this?

B

That's really the experiment in my head right so like do we need this much this much extensibility in the protocol that that's the part I think like Gauri bought up and that's kind of like my question right, like you know how much extensibility do you mean how many tunneling protocols do we need how many extensions returning protocols do we need right and that I think like reach to me like an experiment right, like you know, we are gonna, try this and at the end, we're gonna come up with like the right amount of extensibility, not too rigid, not too flexible right.

B

That was my question so.

J

O

Just gonna leave it at the move. I'm.

B

Not gonna interfere in this, but that's a certainly a question that I've seen like you know, kind of in the subtext of like what good he said. What Dave said what media said and like when I read the document I like I would say really the right level of accessibility is just a question. I.

R

Understand and to be fair, what I'm running in my test environment so is the the direct encapsulation of UDP over IP, so I don't get involved with the extent I guess, but we do have a need for goe. That's.

B

Perfectly fine that and that's why I separated my comments to Tom towards the extensions document reading right and that and that's why I want to figure out how what needs to get done and.

J

Successful on that point, and so we we have the Shepherd for the gue draft. It would be great if we had a Shepherd for the extensions draft, because we haven't had this sort of review. So the fact that there's too many extensions in there really hasn't been been brought up before and I think that I think, if that's the argument and I I, why not just go and talk about that draft separately? Okay, unless unless you're arguing mechanism itself is, is the problem which again I will fall back and say compared to tlvs.

J

This is much less much more constrained and more controlled and it's impossible to add an arbitrary number of tlvs to the protocol. That.

B

Makes sense right so so Tom, the thing I wanted to say it's like when we decided to take this up in interior right. So one of the things I talked to you about is like this is going to lead to a larger body of work, yes or no right, and so interiors really like a place for doing like small things that, like don't, have a lot of follow-up book to do now. Right and for me, the extension stuff looks like a lot of follow-up work.

B

To do right- and you may not agree, you may say, is like very bounded and everything, but, like that's. The extension document is like serious extra stuff. Well,.

J

Right but it, but here working group last call for yeah.

B

If we decide like you know what we're gonna do with that, I think that then, like you, know it's easier for me to like decide what to do with this right, like I. Think like people are reading both the documents when somebody says okay,.

J

So so I am concerned. If we start going down that path, that will reset the clock, and this will be another long process, so my preference would be to to avoid that the gue draft stands on its own. In one sense, it is, if necessary, we could take out the the references to the extensions and say this is the protocol. This is the how you extend it, that that is really I. Think the higher order bit at.

B

Least, for me is to get that so that make sense Tom right because, like I think, the concern is like people need to read the extension document to make sense out of this like base document. Okay,.

J

So your recommendation is to remove references to the second draft yeah.

B

So this the standalone like for it to go along okay.

J

That's reasonable, okay,.

E

Tell me Polly um so yeah again, looking at the current I I think I agree that it'd be good to stand alone and with regards to kind of extensibility I think the issue is not for me at least like the number of extensions, but it's the number of degrees of extensibility, potentially in just the basic header, so I think, particularly when we look at the private data. That does seem a bit concerning so like.

E

If we imagine, if we just like left out the definition of a private data right now, it wouldn't I, don't think it'd actually change anything q, so we already have so we have flags for extension fields which, yes, you may not want to consume one, but you do have an option there. We have a version field which we'd always Rev to change the meaning of that, and you could even have another document in the future that defines when you have the header link. That goes beyond your extensions.

E

What to do with them so like we don't actually need to specify and reserved a private data here. Okay, so.

J

We still have all the flexibility in the future to extend it, how you want it, so you want to create another UDP sore area. Well,.

O

See what it is right.

J

Now we have these, we have these extensions, they have a certain length which we know there's a header length which should be different, so you have this void space. If you want.

E

To now- and it may be just simpler to say that until you have a definition in a specification for how this is used, do not use that space and it's easy enough for someone to come up with an experimental draft later. That says: I'm going to use this space as my private data for X and here's how I negotiate it. But until we have that definition, it's probably simpler to delete.

J

Data- and the definition is sorry- I have used this before, because I don't want to go and start stealing bits that that's somebody else may.

E

Be useful, it feels like there's not really defined mechanism for how to use this point of extensibility and it's the document would be.

J

Stronger I think so, if it gets past the point, then we can take out any reference to private data. I do want to leave the header length in yeah and just not comment on it.

K

Me I could have in I do agree very much with this Suresh and Tomi as well and and basically I just came to the mic to say like because sir set the right amount of extendibility, and that was like Tommy clarified. This is like you have so many different ways extended right and it's not clear why you have so many different ways and what the use case behind it it is and like from protocol design.

K

We know that this is like where the nitty-gritty bits are right like this is where it gets complicated, and this is where we have all the problems. So you need extendibility, yes for sure like deciding a protocol without extendibility is not right for hurt right way for it, but like yet right now, it's just like kind of random here and you could even go like one. You could. Even you could even take the extendibility space out and just use the version number to extend it first.

J

What is random, that's random in the mechanism or random, no.

K

Random without having a use case, because if you don't know what the use case is, then it's hard to design it correctly. So.

J

We don't know what the use case is for experimental TVs right. This can be used for anything, and people have used those for things that really weren't as good.

K

No, they were using for done use case for expenditure. This is usually to test utility and then come back. Instead is the right one right in the use case for general today, visas usually get already have like a couple of them in your protocol, because you know you need to eat them, but right here, I, don't see any of them and, like.

B

Especially it as.

K

It is an encapsulation protocol. You want to be careful about the number of files you want to use here. So.

J

The point of extensibility is to cover the use cases in the future. We don't know about right now,.

K

That you need some way to extend it right, one at least, and that has to be flexible enough to cover these use cases, and then you can figure out how to design how to use the space that you have in the right way. When you have use okay.

J

So you're, referring to the private data again.

K

J

K

Could break it down at this point because also, when I hear that they only use the base protocol without any extensions? At this point, you could even turn it down to just have a Russian number and yes.

J

That's one use case: we do have other cases there's something called remote, checksum offload, which is in in production.

S

So gory and yeah what does he need? The other one, the other use case just picture I believe.

J

May be good was using it as far as I know so. I have in.

S

B

J

The use cases I know.

B

This is in Linux.

S

J

People can use that if they wish. Okay.

S

And I would say the same as the other people who come to the night so far you can always book. She knew RFC, I, know and Suresh, wouldn't like you to begin your RFC here, but you probably could um in a short time, if there other people need other things. So not saying anything about your on your slack area or missing some of the extensions out yeah, that's okay with me anyway, but that might might make it easier for me to review it.

B

See I just wanted like further justification, so like I'm still open, if like Tom comes walking in here and tells me like, you know why it's needed for so specifically the remote checksum or Flores again referring to a GUI extensions right.

B

So it's kind of like nearly circular so like if, like this like somebody says like hey I, need this like it's getting done in the Linux kernel and I need this like yeah sure, let's talk about it at that point and that's why I sat down right like the extension is like a bit more contested than the base draft and that's why I want.

J

To kind of have a clean separation between.

B

J

But but obviously the lack of a standard doesn't preclude us from deploying this using this and bounine products based on the code, echo and- and it's not clear to me that that's required to justify it becoming a standard either. So we do have that we do. The running code is fred pointed out not.

D

The extensions.

J

Well so I'll talk to Fred, we had an extent. He needs an extension anyway. I guarantee.

R

C

Fred man, week of the night, okay.

R

I just wanted to say his document shepherd of the base queue draft. Do we have a way forward for this document to move forward, and can we imperil look at the the extensions Jeff in parallel.

B

Yes, I didn't mention it already: Tom and Tom agreed I. Guess right, I'd like to make the mood a standalone make it.

H

B

By itself, without, like jumping back to extensions at all, on.

R

Deck, okay and then I'll go, ask sorry, sorry Tasha! Well, so we asked is. Is it okay for me to be document shepherd of the extensions draft also it took as a chance, but I don't.

B

You know in honor is.

R

That okay I'll talk with you are fluid about that. Okay, thank you. Thank.

C

You very much thank.

B

J

B

Have another discussion continue on the email and I'll send in my idea, Val to like I kind of wanted to wait till this discussion before I sent it in because I have shared issues with Dave and Gauri? So if publishing you rebel cell in medieval right after okay.

C

So next is state.

G

C

Sorry, the hot mic over there.

I

Okay, so this is about if' types and so in case you're new I have a slide next slide there. It is okay, if you're a new to if' types, ancient history way back when mid-to was first defined. It included this notion of an interface table, so you can enumerate your interfaces in each interface has a type that registry is an ini registry of I have type values. It was most recently defined, meaning across different updates and so on and 2863 in 2000. That means the last time that this was updated technically.

I

Well, it's not quite sure I'll get to that in a minute was 2000. That means the time that the guidance for registering stuff was written was way before there was such a thing as I into consideration sections. Okay, this does use an expert review and the experts are Dana me and we wrote this document saying: here's what's happened over the last 18 years that are issues that we've had to deal with.

I

Okay, this was done in the if' mid working group, part of the internet area, the if' mid working group closed long ago, so welcome to the internet area by the way Justin just to make your life slightly easier. Suresh had said he's willing to 80 sponsor this document. If we want to do it that way, so, ok, that's appreciated.

I

C

I

Do want input from the from the interface community, which is now the internet area. Since there's no I asked networking group anymore, one of the last things that the IFP of working group did was it defined a tunnel mid which says, there's a particular if' type 131. That says it's an IP tunnel and it created a notion of a subtype or a tunnel type and in there you can find things like UDP encapsulation, GRE encapsulation, but not GUI, encapsulation hint-hint and it uses exactly the same process and experts as the if' type.

I

And so again, that's Dan and me currently, fYI, there's 296 AF type values registered and 18 tunnel type values that are registered. The majority of those are not from the IETF, but the IETF has some of the entries in both of them. That means most of the requests that we get do not come through the IETF. They either come through vendors or they come through other standards bodies. You know I Triple, E or itu-t, II and so on and so forth.

I

And so our attempt here is to say we have some designate experts that we've been operating on current practice for a while and our understanding of what the if' may have originally I have made working group originally wanted what 18 years ago, of which I was one of the people that was there and that's why I got stuck with being the expert after Keith McCleary was the designated expert before me, and Dan was ops area director for a number of years before ROM or management area director?

I

Okay, so that's the int, that's the intro to help. You understand a couple of the examples that are in there and there's three types of relationships that are kind of interesting. The first type of relationship is a sub type, so I mentioned there's a type for a tunnel and an example of a sub type is GRE. You can see, there's a tunnel type numbering space that when I of type is 131, then tunnel type equals 3 means it's a GRE tunnel. Okay, another example is I, have type 6.

I

This is a layering stack right because you can enumerate X goes over. Y goes over Z right, and so this is an example of a tunnel that goes over the top of Ethernet that goes over the top of SONET right. This is actually a valid example, and so here's an example where Ethernet and then at some point in time they was defined. You know Fast Ethernet, Gigabit Ethernet, with different numbers that came and has also have a lose later on.

I

Those things were obsoleted and said you should just use 6 right and shouldn't be defining alternate versions that are essentially the same. That's actually one of the discussions that and that's actually an RFC right, the one that says these are deprecated and just used this. That's the Ethernet like interfaces, nib, okay, okay, and so these are exempt. These are all examples from the IETF.

I

The point is that experts have to deal with similar issues outside of the ietf, and we want justification and so I'm coming here to write this document so that we can potentially claim IETF consensus rather than that designated expert said so because, right now, guidance is scattered around about four different places between the ANA websites and a bunch of RFC's that aren't easy to find. Okay, a third type of relationship is a sub layer is plenty of examples of things that asked for two different numbers or two different layers.

I

Okay, this is often the case when you have some multiplexing relationship or dynamic relationship. Here this point is there subtypes, there's potentially alternate values. It says: oh, this isn't quite GRE I want gooey, and so that's an alternate value, because it's not quite the same thing or maybe it is depending on which example that we're looking at and then there's sub layers where people want multiple of them and, of course, in this whole stack again, I only pulled IETF examples.

I

Right I could have constructed ones where everything in here was some proprietary one for a vendor, that's fine or from some other Sto. Okay, so over the last 18 years, we've run into five issues, and so the document covers those five issues. The first one is way back when this is first defined, it was nibs and there was mips, but nowadays we have things like yang modules and so forth, and so people said well do I need one of these numbers. What does this mean for yang right, and so the current practice is documented here.

I

This is not a change from current practice. In fact, RFC 724 took the if' type numbering space and created the mid module forum. To say, hey, look guys, it's not just about moves right, so this did it, but if you don't obviously find that RFC, then you end up with these questions. It says: I, don't have a mid. Why do I need an if' type number, or what does this mean for me? So in practice, Ayana actually maintains the actual registry in the form of a mid module and a yang module. Okay.

I

How many registries come in, you know some formal syntax, like XML I can go and grab the registry and XML. Here you can go and grab the registry in mid orang yang, mitten module format. So the draft clarifies current practice, which is if' type values are not tied to the having an existence of a nib or a yang module. You don't even need either of them. You can just ask for a type okay. This goes for tunnel types as well.

I

You can say: hey, I have gooey, but I have not defined a mid module or a gang module can I have an IFR a tunnel type value? Yes, can you have an if' type value if you convince us that it's not a tunnel? Yes, and here the about tunnel sight? Okay, oh, hopefully, that hint is getting across so I don't have to get across up at the mic. Okay, so examples of current uses of if' type values.

I

Okay, they are the values of a number of mid and yang objects like when you read the iaf table. They are parts of unique identifiers like if I want to identify the mid for either net or whatever they will show up in the object identifier for that mid, Orion module. They are unrelated to any data. Any native modeling language like maple yang their values, exposed by AP eyes right this operating system.

I

Api is you can go in query and I'll, say here's the numbers and, of course, there's various utilities that display it in graphical UI and command-line interfaces and so on. So these show up all over the place. So this is now mentioned in the document just for reference that says yeah. It's not just about Minton, okay, because the registry only mentioned nibs okay. So that's that one was pretty easy.

I

This one is more complicated and that's why I showed you the picture here, because we get requests sometimes, especially when it comes in from vendors, it says: I would like a particular value and we as designated experts, have to say. Are you asking it right? Okay, oh we're asking for a sub layer. Well, did you actually mean to ask for a tunnel type or vice-versa, or did you want an alternate value, or did you want a sub layer right, and so this is actually something that is not well documented.

I

It's documented, by example, and by some text in the original interfaces NIP, and so we kind of tried to pull these together, and here we're actually proposing an on next slide, new guidance that wasn't previously written down. That we believe reflects the intent of the interfaces. Networking group we want to see if yours idea of consensus on so here.

I

What's the problem: okay, I mentioned the difference between sub layers and subtypes right, and so the first problem is, we have an if' type or you can say, there's various I have types that come in or I have to take requests that comes in or mechanisms that people are defining by themselves are not sufficient to ensure interoperability with another implementation of the same thing. Okay, one example I mentioned was IP tunnels. Okay, you can't interoperate with another IP tunnel.

I

Unless you match the subtype right, it's not like GRE is gonna interoperate with Torito, or something like that. That does make sense right. Okay, so another example is you're, defining a layer and without having the same sub layer below it. Okay, you can't interoperate unless you have the same sub layer below it, for you ipv6 people. This means. Yes, it's your ipv6, it doesn't mean you can interoperate with another IP six node. You actually have to have a common link layer to go right. Same kind of concept right same thing happens at lower layers.

I

So what happens is if we get a request that says it's not intended to be an operable with itself. Okay, then, of course, then what should we do is the next thing that happens is another vendor comes in and says we have our vendor instantiation of that thing. Okay, do we give them an alternate value? Do we give them a sub layer value which comes out of the same registry right order? We give them a total type value. Okay, we have to have enough information here. What should we do? Okay?

I

So, partly we want to document what we think the future designate expert should do, and, secondly, we want to document what a definer should do to help us with the next request that says: oh I want to come in as a vendor and here's my instantiation okay. So this is the actual text out of there I'm not going to read the whole thing on to point out the bolded parts: okay, the bolded parts is kind of what I want to highlight and maybe get input on.

I

Okay, as the goal of this is to eventually get an IETF consensus document that we can use as backup or at least as guidance to us as to what to do us or the future desert and experts who replace Dan and I at some point in the future.

I

The first one is kind of an interface Tait, Minh tuff, what if' mid working group intended and maybe equal with the wording or whatever, but the intent of an interface type or subtype, is that his definition should be sufficient to identify an interoperable protocol. Okay, but in some cases you have to have something that goes below it or a subclass whatever to make it be: interoperable, okay, and so here's text about as I have type definition should discuss whether to use a sub layer model or a sub type model in order to specialize it okay.

I

So if I'm defining something that is met by itself, not interoperable and a vendor gets to plug something into it. Okay, whoever defines it should be the purses providing sufficient guidance to say whether the next person that comes along should be sub, classing it or so blaring it okay, and so we as designee experts, can then follow that guidance. It says look.

I

This is what the schema definition said, because, right now we have to try to figure it out ourselves and when the document is very hard to read, we're stretching our heads for a while and that you slows down the process and nobody likes that, neither us nor the requester, okay, and so in one of these, if you're doing a, if you're saying that a sub type is more appropriate, then you should define a registry like the tunnel meant, did okay and so in either case.

I

Give us guidance when defining one of those things so yep we'll absolutely grant things that for which are not interoperable with itself example tunnel, Lib on the author of that, but we defined a sub type model and other cases they define a sub layer model. Either of that is okay, but tell us what the intent is. That's our intent of this text. If you have guidance on the actual wording of this, let us know this. One was the easiest. One I mentioned that some registries are maintained and grabbable in XML format.

I

This ones grabbable in mid or yang format. What's happened. A couple of times is that in those changes it went to invalid syntax and there are tools that can see when programmatically and, of course, those tools broke, and so all this did, what does it says at a step? 9 a process to verify it with a syntax checker before publishing it, Ana has since done so, but this wasn't documented anyplace, and so this is a recent change, Nana process steps and so on the process.

I

Steps in the document it's now documented go number four is transmission values. I mentioned. One of the places that things can get used is an identifier of a data model or of an object in a data model, and that's where this transmission value registry comes in. Okay, it's like in the oid subtree, okay, there's a transmission sub mode and then underneath transmission is a number, and so that number is the transmission value.

I

And so today the transmission value registry is a subset of if' types: okay, with the same value jewelley with the same value and there's no guidance written down anyplace on whether an if' type allocation should also get a transmission value or not. If the requester didn't explicitly ask for one, so we have vendors and other scos that come in it says.

I

I would like a if' type for my favorite encapsulation they're, my favorite layer, 2 protocol that I used to find and IANA has to decide how to your, whether or not to grant them a transmission value. So what do they do? They ask the designated experts? What do we do? We scratch our heads and say we're just going to allocate one whether they like it or not, and here's why number one saves us effort if they come back later, they don't have to come back later right.

I

Let's work for us, let's work for them number two, the numbering space is not scarce right. It's not like! You have a fixed bit field. Ok, number: three! The fact that we don't have to decide right is the policy means hey. We don't have to talk about it right and number. Four there's actually no case on record we're having done that in the past would have caused any problem. Ok and so each time right now Ana asks us.

I

Should we allocate a transmission value, and we say yes, immediate responses, so we'd like to document that ok and say that is the guidance for future designated experts and in fact here's why? Ok, so there you go, if you ask for something and don't need it, we'll give you one anyway, eat your veggies, ok and the last one is also easily fixable, which is all the documents and the registries say to submit a request via email.

I

But if you go to Hana and you look at the list of registries, you'll find a nice little form for submitting a request for interface type. So people come in, ask us which way should I do it?

I

Do I use the email like this thing says or I need the webform that's over here and in practice they accept it either way believe it or not, and so we figured we'll actually say that so that people stop asking us which one to use now I will mention that when I review these slides with Ayane back back, she let me know add this Michelle. Let me know that is exploring how to do it in the future, with maybe a new registry workflow system, there's nothing.

I

We can tell people do right now, but just a heads up. That fact is not in the document right now, but that is something that we may or may not allude to in the document, depending on how IANA wants us to wear it. So, okay, it still be a form of some type, is what Michelle said for those remote okay, all right, that is it okay again, there is a document right now, the main thing we want guidance on or what feedback on it.

I

Specifically, this text, the document itself tries to make obvious distinguishing distinguishing fact, between text we pulled in from various other places in current practice versus proposed changes. Okay, it should be real obvious, because stuff was in like all caps as a prefix or anything, that's a proposed change that we want to, we believe, doesn't yet have IETF consensus. It's just been kind of up to the designated experts to decide and we'd like backing, and so we put that in all caps as a prefix. So anyway,.

G

This is the example.

I

All right questions.

G

Mike Abrams will say: is there any reason we shouldn't take the expert advice on the expert review process here in my expert opinion, no I didn't see anything here that seemed to be. You know, either/or. We should do anything. So you know you see, you've been doing a bang-up job for twenty.

I

Years nobody's complained, I will say.

G

That there is a.

I

Reason we have two designated experts on this one, because the guidance is a bit slim in some cases, and so we have two designated experts and so for anything that is non-obvious. We always have both of us check it, and we give the answer back to anta once we both agree and Michele's back there, not a so.

G

For money, this seems I'll trust you as an expert.

Q

David black, this seems good motivate me, take a look at the mid and the if'. The the if' nib is comprehensive. 9300 entries, including type 132 for coffee pot, yeah.

I

That's because that one was an April.

Q

1St RFC right, however, the the ton of subtypes is, with my light zone, a lot of date. So this what we got to do we sort of asked you what comes next question F after this is dealt with, and particularly given that I think the tones draft says that tunnel endpoints are interfaces. Should there be some kind of campaign to go, get all the tones we defined in the past. I, don't know how many years into this internal subtag registry do.

I

You have someone in particular because, like software is wanting to register happy in that t fairly recently, I mean fairly recently I mean when map T and map he went RFC. They were registered at that point, okay, and so what are the ones? Are you, uh let's.

Q

Say you mentioned that GUI doesn't have he's.

I

Not an RFC you yeah, yet, by the way you can get early allocation, you're not have to be should.

Q

Be in their draft, they should be getting hourly allocations. Arginine needs nori allocation. Pretty excellent is an RFC and doesn't have an allocation. There are there? Surely a number more where they came from you've been very creative with tunnels that.

I

Sounds like a great job for internet area and or the Directorate from the area, directors and the designated experts look forward to reviewing those requests.

I

Our whole goal in doing this is to cut down on the time it takes us to respond right, which makes everybody happy.

O

B

O

B

H

Is I'm gonna kick off a.

B

Procedure for this to go through baby sponsored stuff so I'm immediately thinking of like you know the in.

H

Do three is one of them? Software is.

B

Another one interior, six man, probably some ops of the ship- oh no to them saying this rafters there and inside the process.

I

Okay, I think that's it. Then I said that I've used all examples from the ITF in here, but, as you can imagine, this actually more requests. I think that we get from outside IETF, then we give them inside. The ITF is maybe about 50/50 yeah, okay,.

C

So I think the.

T

Loads, it's Michelle cotton with I, Anna I just want to say thank you for doing this. This is like role, model expert material. Any of you that want to be an expert in the future. It's a thankless job being an expert, but we very much appreciate it, and so thank you for the extra work you put into doing this. We love it when procedures get cleared up and when things are crystal clear for a future expert. So thank you. You should present more you're very entertaining and.

C

Just from the interior point of view, I think that it's true that we pick up a lot of garbage, but we also like to give to other groups. Yes, you're welcome to keep coming too.

C

C

Okay, so thank you very much everyone and enjoy.