Internet Engineering Task Force IETF 114, 28 Jul 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF114-PANRG-20220728-1730

Description

PANRG meeting session at IETF114
2022/07/28 1730

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

A

A

B

Okay, I think we can just give people a few more minutes to get back from lunch.

B

B

Okay, I think we can do some slow start. Welcome to energy brian with us removed, appreciated, staying late, okay, so rtf note. Well, please take a look if you have not seen it many times this week and if even if you did still take a look.

B

uh Housekeeping, uh please please scan this qr code, so your name can appear as attendee. uh If you want to ask the question, I would appreciate if you use on-site to meet echo, but there are not so many people today, but still it does make chairs life easier. If you use the application to join the queue, so I can manage the view from one place and if you're participating remotely, please keep your video off.

B

So again I was going to say: please wear the mask, but everyone is doing it already great yeah. Oh completely forgotten. We need meanness, taker.

B

B

I think we need to either like random number generator to randomly select people in the room come on. I guess we really need this.

B

Really, thank you very much I'll. Buy you a drink after.

B

uh Agenda, I think I got the time wrong, but so ignore the time slot time zones are hard for me.

B

So what we have today I'll be speaking for a few more minutes, and then we gonna have quite a long, interesting discussion about cyan and nicola going to talk about it and brian, and I will keep the room in order and then we have two presentations each for 15 minutes. One is overlay, routing problem statement and the second one is separation of data path and data flow sub layer.

B

So any last minute agenda questions, suggestions, comments, disagreements about what you're going to talk about.

B

Okay looks like we all good, so what's happened since vienna, so we had an interim on san architecture. There is a link to materials from the slide deck. If you don't know where to find the interim materials and we passed, the research group last call for pass properties, but we're currently painting the updated version. So I think even shepherd write up has been done as soon as uh rhiz submits the updated versions. We're probably going to advance the document, and that's all I have for brian any comments. Did I miss anything.

C

B

Okay, so then we move to san an you're going to share the slides or you want me to press prison.

B

Oh beautiful look yeah, I'm grinding you. Technology works.

D

All right I'll get started.

B

Yes, like stay close to the mic, probably okay, yeah.

E

All right, so, okay, the slides, are here good. uh So, first of all uh hi uh everyone, my name is nicola from 88 zurich, and today we will be looking at scion. The next generation internet architecture, specifically we'll be looking at a component analysis.

E

So before getting started, I wanted to quickly touch on some background information. We are not going to talk about how cyan works in details today, we are not going to give an overview. We have already done that before. So, if you want to know more about that, please refer to the existing draft that we have been discussing at the interim meeting.

E

The draft is linked in the slide deck, but I'll still give you a very quick overview about what scion does and what it is just in case. You have not heard about it before. It is a pathway, internet architecture. It is inter-domain and when designing it, we focus on certain properties.

E

First of all, availability and availability means not only availability in case a link fails but especially availability when there are adversaries in in some parts of your network- and this is very important when you do build something that has to be deployed inter domain, where there's different domains and not they, they don't necessarily mutually trust. Each other security is also a very important component.

E

I'm talking about routing security, so.

E

Making sure that traffic cannot be redirected and ultimately scalability when it comes to being able to deploy scion on a large scale, were all very important when designing the architecture, so it started as a research project back in 2009 and the architecture somehow slipped out of the lab. So today it is in production use by a few isps, mostly in europe and specifically in switzerland. The inter-banking network is now being migrated to zion.

E

So whenever you pay some money from one bank to the other, then these banks have to send some bits to each other, and this is being migrated to use zion.

E

That means that we have gained some deployment experience and there's also several uh implementations, which is why uh oops, I'm sorry why standardization is uh quite important right now and that's why we're having this um this discussion here. So what happened so far? Let me just get to the right slide before getting to uh to the discussion. I wanted to just remind uh of another property of scion, and this is the property of isolation domains.

E

So in cyan, autonomous systems are grouped into isolation domains and they are the big circles that you see in this in this drawing here and each node represents an autonomous system.

E

It is very important to remember this structure, because each isolation domain has its own root of trust, and this is independent from other isolation domain, and this property is quite important to understand how the architecture works. This is also important because of scalability, because the routing process is somehow split into an intra isd and into an inter isd.

E

So just keep this in mind and we'll get back to this concept later what happened so far, so we have been um discussing scion already at the itf 113, we had some discussions at the routing area open meeting. We had a site meeting uh to brainstorm about possible next steps, and so I wanted to thank the chairs of banerjee for actually giving us for now a home where to have discussions about the architecture.

E

So back in june, we actually presented a first overview draft that describes the architecture from a high level and during that discussion there were quite a few uh questions about uh about zion and that's what we're going to try to look into today. So the questions specifically were mostly about scion and its components.

E

Scion is designed as a system, so there's few components that interact among each other, and there are quite a few questions about what each component does and what the dependencies are between those components. There were also questions about what protocols are we used? What protocols are not reused and eventually why? So, today, we're gonna, try to uh dig into these aspects.

E

We are not uh gonna be looking at the motivation, I think. In our last discussion there were some mentions of a gap, analysis draft and in the end it seemed to me that it was more important to focus on the components rather than on the gap analysis, so we will not be focusing on on the gap analysis today.

E

So I guess we can get started and we can start the discussion about components by the way. If you have questions, I think we have impul time later. So if you can keep them for the end and then we can uh yeah, we will have extensive time for for discussing that.

E

So when you want to send traffic on uh on scion well as an end host going bottom up, you basically need to have a data plane that is doing pocket. Forwarding and scion is path, aware, meaning that cyan packets actually contain an as path inside the bucket header and the data plane is taking care of well getting this path and then doing the actual forwarding.

E

That means that the data plane has a dependency on something that has to provide these network paths and since ion is focused on security. We want this network path to actually be authenticated, and that's why we have a control plane in scion that is taking care of uh figuring out, uh basically discovering routing information and disseminating it to the data plane.

E

In order to authenticate this network path, it is important to have some cryptography that can basically do this authentication, and this is why the control plane is actually relying on the cyan control, plane, pki to uh basically get certificates and authenticate um this information and scion has its own pki exactly because this, this authentication process is based on the trust model that is provided by isolation, domains the big circles here in in the drawing.

E

So let's start looking at the first component in more details, let's go from top to bottom and let's look at the control plane when it comes to the control plane. We mentioned how flexible trust is a very important property of cyan.

E

So we want each isolation domains to have its own roots of trust, and this is what we call trust, root, configuration or trc that you see um in the drawing each ise has its own roots of trust, and it is independent from other isds, and this allows and hosts in scion to flexibly, decide who they want to trust and who they don't want to trust.

E

So this feature, for example, is quite used in the banking network, where, basically, banks can have communication among a subset of trusted parties and another very important property that we wanted to have in scion is to is to have to make sure that in case an entity is compromised.

E

Then the security of the whole isolation domain cannot be compromised, and this is why, within the isolation domains, there is actually a voting mechanism in the pki, so that very important changes to the trust and to the certificates have to be carried out only if there is consensus- and this not only prevents that a single compromise entity can somehow take over the whole isolation domain, it also makes sure that governance is somehow multilateral, and this is also something that we see works pretty well in in the finance network.

E

So when it comes to inputs and outputs. When we look at this component well, the pki is quite independent, so there is only a minimal need of some initial bootstrapping information, so autonomous systems have, to initially, let's say, meet, have a ceremony to prepare their initial certificates.

E

There needs to be time, synchronization between autonomous systems, so that certificates can be verified, and besides that, there is not really other strong dependencies when it comes to the to the pki and what the pki does to the whole architecture is that in the end, it provides this trust policy expressed as a trc, and then it also provides each cyan autonomous systems with a certificate, an a certificate that then is used for for routing.

E

So moving on to the next component, the control plane is the one that is actually doing the routing and, if you think about it in terms of input outputs well, the idea is that the control plane starts from unexplored topology.

E

uh It doesn't know anything about paths, and the goal is that we want the control plane to be able to figure out network paths. So we want the topology to be explored and we want this to be done securely. So we want each, let's say a path segment to be actually authenticated, and that's why this component takes basically the certificates from the pki also as as an input, and it relies on them for for authenticating path. Information, so the control plane basically does this process that we call path, exploration and in detail.

E

It is called beaconing, so that's how it it explores the topology once this topology is explored. These segments are actually made available by the control plane to end host. So another function is to disseminate this routing information from the control plane within an autonomous system to end hosts that actually want to communicate.

E

There is authentication that means not only on pot segments but also on um control messages, so that basically, a scion host receiving a certain message can be sure that this was created by the entity that claimed to have created that that piece of control message in addition to this scion is multi-path, and that means that the control plane has to be able to provide multiple paths to end hosts, and we want this to happen also somehow scalably, which is why we use this uh concept of isolation, domains to split the routing process into an inter isd and intra isd, and this two two level two tier hierarchy somehow helps with the scalability.

E

So, as an output of the control plane, we basically get this authenticated segments, and these are really hoped by hope so per aes and interface, and this is what, in the end, is made available to the data plane. The data plane is the one that is doing the actual forwarding in scion, so it takes these segments from the control plane.

E

It also relies on these authenticated control messages and what the data plane does in the end is to really create packets with a full path uh path inscribed in the header. You can see this in in this little drawing here, and this is what is actually used by scion routers, then to do the forwarding as an input you can think of application requirements as being part of what is demanded to the control plane.

E

So if you have an application that is latency sensitive, for example, you can ask the science control plane, give me a latency optimize path and well. uh The data plane will basically um select a path that that can give you this property.

E

The fact that path is actually inscribed in packet headers is very interesting. First of all, because routers then become very simple: they don't have forwarding tables, so there is not really need for dedicated hardware, but segments are authenticated at each hope uh in routers, and this is actually happening with a very simple as operation.

E

So it is something that can be offloaded uh by any cpu, which also makes scion routers very easy to deploy on any, let's say, commodity hardware. So in our implementations I think we can run uh up to like some 100 gigs on a let's say, commodity server, and besides, that one property of the data plane that was really part of the design is that cyan is only in inter domain.

E

So it only functions when packets go from one as to the other when it comes to inside an autonomous system cyan by design reuses what what is existing. So that means that the existing, both routing protocol and the existing forwarding plane can be reused. So that could be, let's say, an mpls or an igp or segment routing, and so in the end, the data plane is what is uh providing this inter domain.

E

Multi-Path communication multi-path is also interesting for availability because and hosts have the ability to switch path in case something breaks, and this is also important to keep in mind that selection in scion is really pushed to handholds, which helps keeping the network and routers relatively simple. Another design property. To keep in mind is that cyan uh splits, uh basically locator and identifier uh when it comes to routing so routing, happens based on these isd and is tuples and end hosts can be addressed with existing addressing schemes so existing deployments they use ipv6 or ipv4.

E

So I think that's that's it when it comes to the components in detail. So to summarize, uh we described how cyan relies on three fundamental core components for um for the architecture to function. We have seen how the pki only requires some initial bootstrapping information and then it basically provides certificates and trust policies to the control plane.

E

The control plane is the one responsible for doing the actual routing, which is basically discovering the topology and then making this routing information available to the data plane. The data plane in the end is the one constructing end-to-end path and doing the actual forwarding which, in the end, gives you this inter-domain multi-path uh communication.

E

So just a sec, so before wrapping up, I wanted to briefly mention how cyan interacts with existing protocols when it comes to the control plane. Pki we mentioned before the truss model.

E

Scion has these isolation domains and each one of them has its own roots of trust, and this makes it somehow difficult to reuse existing pkis, for example the web pki, where all the root cas are item potent- and this is very- this- is very different in zion, and I think this is something that basically motivates our approach and adds this concept of multilateral governance on the implementation level. uh Well, the pki reuses x-509 certificates, but of course, then, on top of it, you have all this voting mechanism to, let's say, find contentions.

E

Consensus among the uh autonomous systems are administering an isd and so on. So that's what makes the control at the control plane pki a bit unique on the control and data plane. We mentioned before that cyan reuses intradomain, whatever is existing, so both in terms of routing and in terms of forwarding- and this was by design another- let's say topic that is somehow close to scion is rpki and people might think. Okay they're trying to do the same thing, but cyan does provide you authenticated path, information, but keep in mind.

E

I mentioned that n-host addressing is not really part of the core scion. So that means that scion does not really have prefixes and there is not really a prefix, let's say, origin authentication in cyan, which is why, if you look at cyan transition mechanisms that are not part of this draft and this discussion, but we do have some proposed transition mechanisms from let's say ip to scion and all those mechanisms they do actually build on top of rpki in order to do uh basically prefix origin at the station.

E

So I think the two technologies are somehow potentially uh complementary.

E

One reason for scion having its own control plane is that messages are all authenticated, and this is something that I think we don't see in many protocols. So we think this is something novel that cyan could also contribute and yeah when it comes to the data plane and host addresses are reused, so there is not really need to change that.

E

There are some gateways that are needed in in case you have uh that's, let's say, coexistence between uh cyan and the existing word, but we believe that in the end the amount of change needed to introduce cyan is is reasonable, but at least you don't have to rip off all of your network in some way.

E

I would like to summarize. Basically, we discussed how cyan has three main components. This is really the bare minimum that you need to deploy. Cyan in your network data, plane, control, plane and pki.

E

We have seen how the pki is the more let's say, independent one in the sense that it does not really rely on any other components, but then we have also seen how the data plane and control plane they, uh let's say hierarchically- rely on each other in order to provide certain properties.

E

So I think now we have quite some time for a discussion. First of all, uh there is our draft and keep in mind. This is really a zero zero. So it's something we try to put together rather quickly. So we welcome your feedback on the draft. We actually already got some some feedback, so I wanted to thank the people that have been um reviewing that.

E

um I hope this helped to clarify uh what scion core components are and how they depend on each other. I think we can go more into the details in some directions. If you have specific questions, I think the goal would be to pave the road for future.

E

Work on on scion could be within the ertf eitf, so we first of all want to advance the two existing drafts and hopefully make them of better quality, but we also want to get started at some point with the initial science specification, so the idea is really to document what exists already. What is deployed today, and we believe that doing that might also be a very good way to first lay down what we have today and then pave the road for uh later on, uh eventually, standardization so having more work and getting to work together.

E

On on this- and this could be done here or well- we don't know yet. So. Thank you for your time and yeah, I'm looking forward to to the.

C

Discussion so nikola. Thank you very much um applause. uh So uh I had one quick question with my rg chair hat on first um and then well get people time to get into the queues to ask questions. I saw a couple in the in the jabber room that the zulu room that I'd like to see you know come up with the microphone, um so you said, you'd like to see or you'd like to advance the two existing drafts.

C

um Are you talking about publishing those as rg drafts within panargy or just getting them like im, improving their state right? So, for example, I read the the um um decomposition draft.

C

uh I think that this presentation was a way better presentation of the decomposition than the decomposition draft was so there's like, which is you know when we came into the interim. That's what we said to to prioritize so well done, um but are you looking to publish those as as rg drafts.

E

uh Well, first of all, uh yes, we had two more weeks to do some thinking uh this kind of exercise. I think it was very helpful also for for us to do some thinking on components and we definitely had more time for the presentation. So this extra two weeks, we uh we did a lot of brainstorming, so we'll definitely try to uh improve that draft, um that the.

C

Please take that as a compliment on the presentation, not a complaint, about the draft.

E

Yeah yeah absolutely but um yeah. We got some better ideas later on, let's say after the draft submission deadline was closed. um When it comes to improving that, and so ideally it would be great if we could uh document the existing it could be within the research group. um I think what we are looking for now is just to get some feedback from from the community.

E

um So definitely interaction with the research group would be, I think, positive for for now, I'm not sure if we could get some of the drafts to have to be- let's say an informational rfc or something like that. But I think this would be clear over time.

C

Thank you very much with that. The queue is open for questions and discussions.

C

I'm going to call out eric klein because he had some very good questions but alvaro coming up. First.

F

That's the thing: uh hi alvaro, futuroi technologies, um so understand. There are three components: um how independent are they can I have the control plane but use a different, pki or authentication mechanism?

F

Once I resolve the routes in the control plane, can I use a different data plane uh or or or do we need the three components, and I know that the three components make up scion, but if we needed to develop them or standardize them or or implement them or whatever independently, uh you know what are the dependencies can? Can we, if we finish the control, plane, work for example, but we don't have the pki work.

F

Does that mean we can't do anything or I'm just trying to figure out if there are alternatives or flexibility with the dependencies.

E

Yeah, so having the whole system or components working together, I think helps you to achieve most of the properties you could. I think you could use some of the components independently, but you would lose some of the properties, so I think I have some backup slides at the end about this okay yeah. So it was kind of.

E

All right, so I think it really depends on components so, for example, the pki I think the pki is the one that is a bit on the easier side, because it does not really have uh external dependencies and all all that it does is that it provides you. This per isd, trust model. Where you have your own routes of trust, you have the voting. You have a way to update certificates over time, and so this is used by the control plane, but it could be used by um by other things.

E

So, for example, we have a scion extension that basically derives symmetric keys between any two autonomous systems in the architecture and the symmetric keys could be used for anything they could be used for encryption for authenticated, uh authenticating certain messages.

E

So there is actually also a draft about that um by my colleague, juan who is actually, I think, um also um in here in the call, and so I think this could could serve some kind of purpose, even if you have it um by itself when it comes to um the other components. So I'm thinking, for example, the control plane.

E

Well, the way it works is that it relies on this concept of isolation, domains, for example, for scalability, because the routing process is somehow segmented into this intra and inter isd. So it does need something that that mirrors this concept of of isolation domains, but you could say: okay, I deploy a scion network as a giant single isolation domain.

E

I think you might bump into some scalability issues and you might bump into some governance issues, because maybe, instead of having this voting process that you have in the pki, maybe you will have a single certificate authority that that, in the end, is in charge of administering the whole, the keys for keys for the whole network.

E

So I think this could somehow work, but I think it would lose some of the properties on the control plane, but it does not exclude that somehow things could um could work by themselves, but I think there would be more open questions about how to do this effectively when it comes to the data plane.

E

um So what the data plane needs in scion is basically this authenticated path segment, and here one of the key things about scion is that you authenticate those segments uh with all this control plane and this pki and truss model and so on. So if you were to deploy uh scion network um without the control or a plane or pki, I think if you have something that can authenticate this segment, I think you could somehow make it work, but you would also lose some of the properties there.

E

So maybe you might end up with something just like uh maybe inter-domain segment routing with with authentication on top of segments, which could still be in some way a contribution, because I'm not an expert in segment routing, but my understanding is that there is not really authentic authentication so far and segment routing, for example, is, is meant to be deployed in a in a in a control environment in inside a domain, a trusted domain, so that could maybe help in some way, but it would open more questions.

E

So I think overall, the answer to your question is: we could have some components working somehow independently. They could give some benefit, but it would be more limited than having the all all three of them um somehow working together.

G

uh Eric eric since uh brian called me out brian, do you want to jump ahead of me here or are you fine behind me.

C

Yeah no go ahead. I just had um nicola said something and it raised another question so I'll I'll bring that up later go ahead.

G

uh I'll just uh run through some of the questions that I was asking in the chat that juan was kindly providing some answers to, and maybe you have some other. I think the first thing I asked was: um are existing deployments uh amenable to any changes that standardization might lead to if there's something backward and compatible?

G

Is there going to be a bunch of people who are actually kind of like complaining that no no? We can't change anything.

E

That is a very good question, uh I'm personally not let's say in charge of those deployments, so I I don't think I can answer that.

E

But since we have some deployment, I think a key step towards standardization would be to first document what we have existing and what is somehow deployed today and then take it as a base for doing some more longer term. Standardization work whether they would be willing to change um yeah. As I mentioned, this is uh not something that I could.

D

E

Or commit because there is, I mean, there's isps, there's the banking.

H

E

What I've heard um from the past is that uh if you compare scion today to the let's say very researchy scion that we had a few years ago already, several things actually changed um change a bit even in let's say in in parts of the header- and this is because, with some deployment experience, um people realize that some things that were initially designed they were, they could be optimized.

E

So I think, for example, some header fields were swapped in position to make it a bit more efficient to uh to parse them on routers and so on. So I think there is a margin, but I'm not in control of those networks and, uh oh sure,.

G

This would be uh one's reply was that the isps many of them have been asking about a possible standard, uh and it seems that there's reasonable belief that they would be happy to use a standard process. That's what he said yeah. I also asked if there was a life of a packet or even like a life of a socket kind of summary. uh He pointed at some documentation and described some stuff in the chat, including like a an initial phase of like getting getting.

G

The client actually gets all the paths itself and then chooses paths it wants to use. How long does that usually take? Can that be pre? Can some how much like pre-computation or pre-caching can be.

E

Yeah, that's a good question, um so I believe we do have a life of a so there is um a book that we have been working on in the past years that I think that is uh called the complete guide to science and in there there is a description of uh let's say, a life of a packet. If I'm not mistaken,.

A

E

Is also one that we also have an older book from a few years ago. That also has this chapter, but, as I mentioned, few things changed, so I would recommend to. um I would point you to the latest version um when it comes to fetching paths. um Well, so there has to be an initial pass, lookup from end host to get these past segments.

E

uh These segments have a certain lifetime, so they can actually be cached at different layers. So the way it works, I'm not gonna, compare it directly to dns, but you can think about it uh in terms of something similar to uh dns lookup sure.

E

So there is some initial extra latency of some milliseconds, but it really depends on where you want to go and uh whether the the server you're actually asking for paths already has this path information, because, for example, if you want to go from one isc to another one, there has to be like uh I'll, say: recursive. It is not exactly recursive, but there has to be. uh There have to be a bit more lookups, but once the core has all those segments the next lookups, they will not incur the same.

E

Latency, so the answer is, it depends um but think about it as a the ns-ish um like um way.

G

There was, there was some other uh stuff. I asked about also about the um if the path, if the path list is in every uh packet, uh how big is the header- and, I think juan said- there's like an extra 80 bytes over uh ipv4 header size? Yes, which implies that there's a maximum path length.

E

uh Maximum path length, I'm um I'm pretty sure there is one, but I'm uh I'm not recalling that. I'm not sure there's some colleagues that are in here, I'm not sure if they they remember that. What I know is that usually with each path, then you also get a path mtu. That, of course, depends on on the links that you have along the path and on the path header, because of course the header length is uh variable variable um and sorry. What was your other question.

G

When the question was how long? What is the max path length.

E

G

Happens to networks that are outside of the math path, max path, length.

E

I would have to um get back to you, I'm not sure if somebody else in uh there are some some colleagues that are remote and I'm not sure if they they know about that, but the path is usually an as path, so cyan paths are per yes, so for each as you have incoming interface, outgoing interface and yes, so it is usually not something that you would expect to be more than I'm not sure.

E

A certain number of autonomous systems.

G

Okay yeah. I clearly need to learn more, but thank you, but.

E

E

I think brian is in the queue or.

C

Yeah, let me click the buttons, um so uh I was looking at sort of like these slides here. The can we use x alone. Can we use like why alone? Can we use z alone? um I think that's one good way to to look at these questions. um The the other way to flip it around would be to say: hey. Can we take for any of these components?

C

Can we replace them with something that is already in sort of like the itf internet ecosystem or something very much like it right like so, um for example, uh I think you make a pretty good case that the data plane on its own is probably the least useful thing, and the pki on its own is the most useful thing um but like what would it look like to, for example, take um the cyan pki um some representation of this ion control plane like so that the path beaconing mechanism right like so, I assume you bring that to the ietf and the first thing we're going to do is change the indian-ness of it right because it's like you know, control um change, control, lives at the ietf and it's what we did to quick on the first day, um the, but then like use some existing piece of the ietf ecosystem for the data plane right, because I think I think you made a pretty good case of the data plane on its own is the least interesting thing it's like.

C

Could we use yeah? It looks a little bit like lisp. It looks a little bit like segment routing. Could we use like the sr headers for the the intra domain data plane, but then, like connect the control plane into like you, use the control plane to disseminate the path information that then shows up in the segment routing headers, for example,.

I

C

That's just that's the that's the easiest way I could think to sort of like say: well, we're not going to boil the ocean at first and we're going to reuse, something that exists and is implemented and standardized in the itf. But there are other. You know there might be other ways that you could could replace. The data plan did juan want to come in and answer that question, or did he have a different question.

J

um I have a different question: okay, cool.

E

Oh okay, so going back to your your question um whether we could use um an existing protocol uh well I'll, just start with saying that I'm not a segment routing or lisp experts, so we have been looking at how they work, but I think investigating how actually the physical disease would require a bit of further analysis.

E

So I think I have a slide about just comparing the protocols, but my tool is stuck.

G

E

Just give me a second, and I think we will.

E

So yeah we were mentioning, for example, um lisp.

E

So when it comes to cyan versus lisp, I think the idea of separating routing identifiers and locators is somehow common and when you look at transition mechanisms that we did not really get into that much, I think there are some similarities in the sense that lisp and cyan both have, let's say a edge point that acts as a bridge between um between the list part or the scion part, and the regular and host ip part. So in scion this is called sig scion to ip gateway and in this.

E

uh Well, I I don't remember how this is called, but I think it is like a lisp router or something that does this um kind of encapsulation.

E

So I think there are definitely um similar problems that um that, probably where we can probably find some synergies um when it comes to to this concept, but lisp is only doing um it's only uh having this, uh let's say: two-tiered routing, and there is not much about multipath. There is not much about authentication, um so I think the core focus of each one of the two protocols is is very different, but yeah, I'm not sure how much they could be potentially integrated, but I definitely think ideas.

E

Maybe there could be some um cross-pollination of ideas between between the two, especially when we look at transition mechanisms, which I think is a discussion that we will have to have. We just did not um have it at um yet here, because we are trying to now look at the let's say bare: minimum core components.

E

When it comes to segment routing um well, as I mentioned, I'm no expert there, but the idea is that segment routing is intra-domain and zion is inter-domain, so I think they could potentially cooperate in some way where you use segment routing inside an autonomous system and cyan inter a yes, let's see if that tool starts working again.

E

Sorry about that.

E

And okay yeah, but besides that, um I think the key difference is really about uh trust and the trust model um segment. Routing does not really have much much about um about working uh between untrusted entities. So when it comes to your question, could we use one with the other? I I think there could be some synergies, but we we would have to do more thinking about it of how this could in practice, work when it comes to the details, but definitely there's some.

E

There could be potentially some little overlaps, but usually the scope is very different because of the trust model because of what the protocols do and so on so.

C

I know a lot less about segment routing than I should um to be honest, um but, like this slide is super interesting to me, um because we have a bunch of properties that we want over on the left side um that are missing from the right side and it's like okay, the paths are authenticated that that path, authentication is basically coming from the control plane um and then there's sort of like some encapsulation stuff, which you know the internet has made a tunnel. So I don't really care.

C

You know how many different layers of of headers you have to put on a thing in order to make it work, but.

I

C

Is would there it seems to me there might be some way to take this path, authentication and the ability to run an untrusted domain from the control plane and integrate it into something that looks like set segment routing for like the packets look like sr packets and can be handled by devices that can do segment routing, um but you like, I want to figure out if there's a way to take things from the left column of the slide and wedge them into the right column of this slide.

C

Does that make any sense right like if you get the? If you get the path authentication, if you get sort of like the tr, the the ability to do untrusted deployments from the control plane, could you dip segment routing in that somehow and then get the best of both worlds like this is an in-kuwait idea? I don't.

C

I think we should probably take that offline or to the list, but, but I like this slide, just sort of like gave me an idea. There.

E

Yes, this is one of the slides that we uh added after submitting the draft and uh yeah, but it definitely needs some more brainstorming. So I would be happy to um continue the discussion about this off on the list. Excellent, I will.

C

Stop talking with you, then thank you very much.

B

J

Thanks jen um hi, everyone just wanted to go back to the question that eric had about how happy would be the stakeholders of this moment to participate or even to welcome a standard about like any of these three components for china as a whole, so I mean as as more and more entities are joining the scion network. They are using money and and resources to participate, and it is for them quite dangerous to just have one like single entity managing everything.

J

So for them, it's quite critical to have to actually have a standardization process that everyone agrees upon and that multiple partners can can build routers and can build all that knowledge as well. So that was just to build up on that.

J

H

Yeah, it could have been um so indeed thank you for this presentation. This is a really nice setup and and helps a lot to understand the different components and every and how everything fits together, um and it did help me to understand uh what's needed much better and- um and I think it has become clear to you- maybe in the meantime, based on all the questions discussion- that we won't be able to take like everything together and do everything at once.

H

So we have to go step by step, so I found most useful that you had on all these slides. You had this box called functions and properties, or actually I didn't find it useful that is called function properties, but because, like these are two different things, um but the function is the most interesting part um that we can standardize here right and so can you maybe go back to slide number eight.

E

If give me a second, it is a bit okay.

H

Yes, so I think here the two, the first two things are actually functions and the rest are properties. Yes, so the properties are more requirement for protocol, but the functions are something that we want a protocol for, and maybe this is actually a very good starting point here, um because and now you can correct me if I'm wrong, because I'm really not a.

D

Rounding expert.

H

At all, um but um past exploration and dissemination is something that we don't really have a protocol for, and that could also be useful for a lot of other use cases and protocols. So maybe that's the first step. We can talk a little bit more about in detail.

E

Oh yeah, absolutely so. First, thank you for the feedback. I'm happy that this helped. um As I mentioned, this was also an exercise for ourselves. So there was a lot of thinking in the background to try to get this, but I think definitely also echoing what brian was mentioning. I think both the pki and the control plane are probably the more interesting components that I think would also bring some value around. So um thank you for your input. I think we can um and.

H

It's understand to me that even those two functions here are not completely independent of the pki right so like even if we start here, we probably there's something we need to think about the pka so but like yeah, we need a starting point. That's the point.

E

Yes, yeah and I think concretely the starting point could be yeah, either the pki or the control plane or or roughly uh yeah. I think there's already some well, I would not say consensus, but some some ideas that yeah the data plane, maybe is uh less less important for now. So thank you for your input.

B

I

I thanks uh ken calvert university of kentucky. um I just want to say- and I don't know as much about segment routing as I should either, but I could swear that. I saw something somewhere about extending segment routing to the inner domain area and I don't remember if it was a draft or something submitted to a conference or what.

I

But I would just observe that I think if, if you think about that happening, I I it's hard for me to see how you would avoid ending up with something. That's the equivalent of scion's isd isolation domain in terms of the trust structure.

B

Yeah, I guess alvaro, has an answer.

F

F

There's all kinds of names for domains right so in the segment routing architecture talks about second routing domain. uh A second.

G

F

Can be one that has multiple ass so in traditionally we talk about multiple lasers, we say enter the main right, but there are networks that have the operators that have multiple as's and so their segment routing domain can go across as boundaries.

F

So, yes, segment routing can work across as's. If we think about the isolation domain, that's similar to you, know one operator or one administrative domain with multiple aces inside so yeah. That is possible to go across um across across domain owners.

E

But I have a follow-up question about that is: um are these asses assumed to be under the same administrative entity.

F

Because it is correct, that's what I said: yeah, because the thing.

E

Is in cyan within an isd, autonomous systems are at least a design is thought in a way that autonomous systems are under uh they're, basically different administrative domains, which is also why you have the voting process in in the pki, because well we assume that there is some shared level of trust, so asses could be in the same jurisdiction or in the same industry, but they are not necessarily absolutely the same administrative domain. So I think that threat model behind it.

E

Then it would be a bit different from um from the one that you have in segment routing. If you assume that all the yeses are part of just like a gigantic.

F

Network it's different. I was just saying that, yes,.

E

Okay, thank you.

B

uh Media, I still are you still in the queuing? Okay, I'll, remove you uh well, I do not see you on the queue, so I put myself in the queue to ask very, very stupid question. So I assume this requires the changes on the host or some kind of proxy sitting there right. Yes, so basically does it like how does it work for a host which might want to talk to some science destinations or internet destinations? How does it practically would work on a host.

E

Yes, um thank you for the question uh I'll just look here, so people can hear me um so yes, this is uh correct, so there is roughly two ways to um to communicate. Scion. I think there is a slide about deployment. I purposely did not want to talk about this because we have several transition mechanisms.

E

Several proposed transition mechanisms- and I think all of them would require their own discussion, because it's quite um it's quite big, but in a nutshell, you basically either have a native scion host that basically has currently a piece of software that supports uh doing this path, lookup and so on and can talk to other scion hosts or you have a gateway in the network. So this is what we call a cyan2ip gateway, and this is what is used in deployments today.

E

So then there is a boundary between the scion domain um and uh the end host and, of course, all the path policies and so on. They're all configured on uh on this edge device called the scion to ip gateway.

G

E

Yeah there was a slide about it, roughly so yeah. There is a little slide about it. There is this basically purple device and in existing deployments either it is basically deployed on somewhere close to the cpe. At the customer side, where traffic is encapsulated encapsulated or some isps in switzerland, they started offering like uh what we call a career grade, uh scientoip gateway where they run this inside their core network and when you wanna go to some destinations that are behind scion, then traffic ends up on on this gateway, and then it continues over cyan.

E

Besides that, there is some proposed transition mechanisms that, let's say, aim at coordinating this gateways on a large scale, but that's that's a whole different discussion.

B

So I don't oh brian.

C

I keep looking at these slides and then like it's like wow. This is a really great slide. I want to talk about it, um so uh I really like this diagram uh thanks for drawing it. um It occurs to me that one really interesting question that we could ask is: let's look at it at deployments. A and b here.

C

um First right, like um you, have a network and you put a bunch of scion hosts on your network or you have have hosts where you have like a you know, a dual stack thing so that you can actually run cyan applications versus you have a network and you plop a sig on your cpe, and that sig is actually going to be a relatively cheap thing right, because it's a scion, router and zion routers are relatively cheap right like this is not there's not an enormous investment that you have to make, or not a lot of forklifting that you have to do to get deployment b to work.

C

It'd be really interesting to see like a lot of the sort of deployment of things in the networking space.

C

Look a lot more like b than a right like because you know deployment day requires you to touch every endpoint and you have to touch a lot of those endpoints before you get the benefit of what's going on in the endpoint, whereas you can get a lot of the benefits of this, not all of them right like so, for example, if I'm you know, if I'm sort of like doing some sort of taps future thing where I have uh a um an application that really actually does want to control network access to the path for different um sort of like differentiated services.

C

For for different things, then I really need you know. Since that's that's running on the endpoint, I really need that on a what do I get if I just do, b right like if I just went and and like downloaded sort of like you know the scion thing onto my uh onto my my tourist omnia and then like now, I have scion at home. What do I get get from that? I think that's not a question to answer right now, necessarily, but I think that would be a good thing for that.

C

Like you, you said a couple of times: it's like we're not going gonna get into that, because we have some some transition mechanisms.

C

uh I'd said in the interim uh sort of both with my individual and my chair hat on that, like a an exploration of those transition mechanisms, would be super interesting for the ietf community in general, because it's like hey you've, actually deployed a future internet thing that works with the present internet. Transitions of this case are hard.

C

You know what what are the? What are sort of the incremental benefits of of of doing this? I think this is like sort of a work example of doing that sort of thing and, like the question that I'd leave with is like okay, we have this vision and we're going to scionify the internet. um If you only get to deployments that look like deployment b here, how big of a win is that right?

C

If you never get the rest of of like, if you, if you never have a you know, the vision never gets to the point where you have a bunch of scion enabled endpoints, where you only really are doing path. Selection from the gateway right like so the past selection rules and policies become a thing. That's under the local network. Administrators control kind of like in the present internet, as opposed to under the endpoint, is like what do you get from there? What is the? What is the if that's as far as it goes?

C

What's the benefit, because.

I

C

Think there are, I don't know what they are, but I'd really like to see that that sort of explored in future work.

E

Yeah absolutely so, I think there were also some discussions last time about documenting deployments and transition mechanisms.

E

To this point, I think two things one of it is that there is different transition mechanisms with different maturity, so designed to ip gateway is the one that is used today in production. But there are some research proposals um about other transition mechanisms. So, for example, I think there is one that is, it will come out at usonic security in well, I'm not sure when it is, but in a in the next month, um describing more of a back one approach to that.

E

um But of course, these other ones are more research and for the discussion of today I think I wanted to focus more on what is actually really uh deployed and productive.

C

And that is the stake. That's that's cpe deployed to the customer side or that's.

E

Basically, yes, that would be roughly b b and as well d, so both of them are are somehow deployed.

C

When it comes to getting closer, yeah b is the most interesting for me from like a from a from a standardization standpoint, because it also gives you a deployment and operations model that isn't that far from the current deployment and operations model right, like you, have people who own local networks and you're giving them more, you know even more internet you're, giving them new things that they can do that they couldn't do before it'd, be interesting to look at what those are right, as opposed to you know a like getting to full native song on everywhere.

C

You got to have the browser vendors on board. You've got the os vendors on board. You got to have like you know. You might need to do. Nick, like that's. A much bigger left, whereas b is absolutely is, yes, seems.

E

C

E

So this is why uh the current deployments they both they basically follow, b or d and when it comes to benefits um well, of course, you get full benefits if there's two scion hosts or hosts behind a scion gateway that talk to each other, which is why I think the early adopters are these kind of ecosystem industries like banking, where you have lots of actors that need to talk to each other, and they need to do it with some extra reliability that they do not get over the internet.

E

So when it comes to like the the business or, let's say, benefits of deploying scion these ecosystems, like finance or transportation or healthcare, I think in there's now a poc being run for adopting scion for connecting healthcare institutions in this in this kind of market. I think scion has a very interesting positioning somehow or can provide some interesting properties um when it comes to the past awareness, security and so on. So that would be, I think, the the first step, the more concrete use case.

E

The other ones would be more, uh of course, require more change and would perhaps come later on. I hope that somehow answers your question and it was um okay.

B

J

Yeah sorry to bother again just just wanted to.

K

To talk exactly what what about what adrian was asking, what brian was asking um I we have to talk about this as well. Definitely as nico said, but uh we believe that the scenario at a that will that will never happen so.

J

Clarify that meaning that there is so much existing software and so much compatibility that we will, I believe, or we believe that we will always have this kind of gateways in the middle to allow backwards. Compatibility for many I mean for many many years possibly forever, but to be honest, but also a mix between a and b would be um would be very welcome. At the beginning, everything is b and then there are so many hosts that understand.

J

Scion and their applications can take full advantage of the multi-path and multiple properties like also qas and and so on, because they see, of course the gateway has has limitations. As brian said it's only, it will only do its job up to the taste of those admins, so whatever flavors they want to use for the pads and so on. So that will not that will not transpire to the host applications directly but yeah. We definitely have to talk about this. Yes, thanks.

B

So no more questions comments.

E

Maybe I'll I'll just try to wrap up um in just generally asking or commenting like uh for next steps. I think we definitely got a lot of good input um today. So first thing. So uh thank you all for um your comments. They definitely help us to um to do some more thinking about it, and I think that will also help us iterating, especially on on the component analysis track, so expect to see an update and we'll be happy to discuss some of the open points on on the list.

E

um When it comes to further next steps. uh Yeah, we were wondering if um perhaps working on the specification could be uh interesting. As I mentioned earlier, it would be probably difficult to reach rough consensus right now, and it would be very beneficial for us to at least document what we have today in terms of deployment.

E

So I was wondering if I'm not sure the chairs or the audience have um opinion about that.

D

E

Or, if not um yeah, we will wrap up. Oh, I see brian is around.

C

Yeah, so um actually I wanted to ask a clarification question on that. Well, you're talking about documenting the current deployment. um This would be the specification of what is is currently deployed or a deployment report like. Would it be a specification that pro of the protocol is currently deployed, or would it be a report on the properties of the deployment this is currently deployed, so it makes sense like which which do you, which is more useful for you.

E

I I was thinking so I think there is different things. This could definitely be useful documenting the deployment, uh but I was also thinking somehow having the the low level specification of how things work today, just to have it as a starting point for starting to discuss um about what you know each component, I think so far we got the direction that the control, plane, pki and the control plane are more more interesting.

E

So I was thinking more, let's say in starting to uh work on some of those components or start starting having a documentation there, but in parallel we could also um yeah focus on uh deployments um all.

C

Right, no, no I just wanted to. I was just asking clarification impression for what it was. You were asking for. Yeah I like, uh I think, that's definitely worth writing down.

C

um I would want the research group to take a look at that before we made a decision as to whether we would adopt it as a research group document for publications rfc for this stream. I think I think we still kind of don't really know how we want to break this work up and bring it into the irtf and the ietf right, because I mean like if the goal is standardizing some of these parts of things, then you know step one is writing it down in an id, and you know.

C

Maybe we have a discussion about that and split those documents up and some of them go to other working groups or to their own working group and some of them stay here um yeah. I think it's definitely worth starting to write things down um uh sort of in the id format, because I mean like once it's once it's there.

C

It's not very much work to like shuffle it around right.

E

Yeah, that's what I mentioned. I I I meant yeah.

H

I could event again so I I similarly got potentially confused by the term specification here, and so you have this other draft, which is describing the whole architecture but you're you're talking about writing wardraft. So are you talking about that right? So.

E

I'm I'm. I was talking more about uh writing other drafts uh with the like protocol. Let's say specifications so just.

H

Documenting what we have today, how it works- and you already said it now- you say multiple drafts right. It's like it's different components that probably go into different documents right. I.

E

Mean I think we have the three core components and it would be. I think it would be a lot of material if we were to have everything together so yeah. I was thinking about the three core components: the control data plane and pki um yeah. I was basically referring to that yeah.

H

Okay, so specifications.

E

Yeah, that's why I mentioned I mean in the end, uh it is very important also for us to do thinking I think, for uh for people in the groups to do some further thinking, especially when we want to look at more technical uh questions. I think, then we have to start looking at more in-depth, uh because now we're really looking at. Let's say we had an overview now we're looking at the properties and sooner or later, we'll have to get to um so.

D

E

Level bits and that way we can also then think, if we can, I don't know integrated with segment routing or, um but I think it is important to have this somewhere. So I feel this is probably would be a meaningful next steps that that's why I was um proposing that yeah.

H

Definitely agreeing, I think the point I want to make is already like try to think of think how you can break this up into smaller pieces, so we can actually take some of these pieces and start working on them in the ietf um eventually, rather than putting everything into one big document. No.

E

Yeah absolutely so, it would definitely be at least three three documents for the core components and then there's transition mechanisms. There's we have a lot of work ahead, um but yeah the idea was to document it first, so I'm not sure if there could be, maybe even an informational document uh uh being worked on first uh and then uh having.

H

Something you should just write it down and don't worry about what.

E

H

With it later,.

E

Okay, that's clear: we have some work to do.

C

So so, as it turns out, I put myself in cue to agree with everything myria said before she said it. um I think that's the way. We need to go um one thing that I noticed in reading the draft uh and then uh looking through these these slides and then just got this discussion at this presentation.

C

Is it really shows the the benefits of sort of like you're thinking the scion team's thinking of getting into this decomposition right, like so actually sort of digging into it? I think, has improved your concepts and gotten us a lot closer to the goal of figuring out what we're going to do in the irtf and what we're going to do in the ietf, and I'm convinced that, as you do the detailed decomposition of these things into these three specifications that you're going to have more benefits to the thinking process.

C

Of that, I think that things are going to fall out of this, and it's going to be like. Oh, why didn't you? This is obvious. This is the way to go. I don't know what that is yet because I haven't read the drafts yet, but yes, yes, you have a lot of work ahead of you.

C

um I commit to reading all of this stuff um and uh and helping me make it better, um and we should probably, after colin talk about next steps within the rg chair hat back on uh as to setting up um a pace of interim meetings. That will make sure that we, you know, keep the energy up on this, uh because I'm really excited to see how well it's going- and I think you know if we get into a situation where it's like okay.

C

Well, now we're not going to think about this until london, then we're we're missing an opportunity.

B

And brian, I don't know in the chat uh jeff mentioned that it might be an option yeah of uh bringing it to routing people yeah, but having like yeah.

C

That would be that would be yeah. That would be super cute. I think I think I want to write, get at least the control plane, pki and the control plane documents to the point where they're readable before we do that, because because I I'd like the routing people to throw arrows at the specifics as opposed to the concepts it seems like, it would be more um uh more beneficial to to talk details so.

B

A

Hi, uh I think brian and miria said a lot of what I was going to say already. uh I think the the I think it's possibly premature to think about uh what are the next steps?

A

What's what's going to be standardized and what isn't, I think, the the act of writing down the specification here, the act of decomposing it and specifying it will, I think, make it very clear what is ready for standardization, uh where the open quest questions, which uh perhaps this group perhaps updates the irtf, could look at and um similarly, I think someone mentioned the independent stream in the chat. I think that that might be a venue for publishing a snapshot of what you have now. But again, the main thing, I think, is to start writing down.

A

um Writing things down decomposing it writing the writing down what you can specify and then separately writing down one of the things where there are open questions, as you specify it and then over time. I think it will become very clear which bits are research. Your research on which bits are standards ready.

E

Thank you, um yeah we'll definitely keep writing for the let's say, short term in the foreseeable future, and I think this will help us move forward.

C

So I think we can take my last question to the list, but um this is more of a holiday schedule question if we were looking at the last couple of weeks of september um for an interim or maybe the first week of october, is that going to give people enough time to do anything or do we want to do something? That's maybe um like because the the london meeting is toward the beginning of november right.

E

Yeah, I think yeah.

C

um So, like I guess we could, we could do something anywhere from the from the sort of the end of september to the middle of october, uh and the look on your face um suggests to me that you're more interested in toward the middle of october than toward the end of september.

E

Yes, okay, yeah, the thing is um yeah we have to. Maybe we can talk, talk, offline and see, but uh yeah.

C

E

I think me and uh yeah the other folks that can do like really work on writing. We will be um either busy or out for a while in september, so um so yeah mid september late september would be a bit um okay, tricky.

C

Cool all right, that's good input, I'll I'll start the thread on the list from that.

C

Thank you very much.

B

Okay, thank you very much.

C

B

Do have a little bit more.

C

Time here is there anything else that you want to know from the people in this room today nicola is there any?

C

I think you got a lot, so you know no is a perfectly acceptable answer.

E

I think I got a lot, I'm still processing and we'll be processing in the next few days, um so yeah. I will also start writing uh um we're preparing towards uh writing down some of the specifications while iterating on the draft. So I think this will be definitely enough input and yeah if we keep the momentum and keep discussing and entering meetings or so on. I think this will uh bring us a long way forward. So all right, I'm very happy and thank you all for.

C

E

Spending so much time on on scion.

B

Thank you, okay. So now, let's move to the next presentation about overlay, routing problem.

L

This is gong and I'm gonna present this uh problem statement.

B

You want to present yourself or you want.

L

B

L

Oh, no, you can't you can share the screen. Actually, it's not it's not a long.

B

Slide whatever yeah.

L

Okay, then, should I start.

B

Yeah please: okay,.

L

Okay, good day, uh my name is gongli and I'm from huawei, and it's my pleasure to pre present our uh problem statement of overlay routing and in the internet application, and actually what we're gonna present is a complementary part to actually what you discuss today. I think we can have good discussion after that next piece.

L

Okay, as we can see, actually internet is uh incurring totally a new generation from before we call mobile internet all the way to the uh immersive or real-time and interacting internet and, for example, the real-time communication traffic actually have have been growing. uh Almost three thousand percent have since the core weight, and maybe it's gonna be more right now and also the vr and er already have expected a huge annual growth in this decades, and also a very hot term, like called metroverse.

L

I think everybody already heard that I think it's going to be one of the ultimate kind of scenarios in this immersive internet, but in the meantime, actually uh this kind of development need much higher and more strict requirements about networking, quality and network transmission in terms in terms of like latency uh throughput packet loss and jig and so on.

L

However, actually, there is a huge tightening gap in this internet kind of application scenario. With what area and the public, we will say, cross-domain networks, because first, every traditional internet is originally designed to just for connectivity and the best effort, delivery and also the inefficient, I would say, very inefficient uh routing protocol.

L

The bgp actually is basically um the path is computed based on the isp business relationship instead of performance, actually, there's no performance guarantee, and actually it is noted that some a path between the locations within asia actually will go, will be routed through some peering points, all the way to america. There's a therefore um have like extra latency uh greatly and also some reason are the ones, for example, 5g and sdn, but they are all operating in a single domain. Therefore, you cannot do this kind of end-to-end solution with cross domain in the crosstalk networks.

L

uh Next, please.

L

And therefore, actually recently- and I would say, an old technology has been revisited- it's already networking and it can provide better path, selection in the internet and, right now, I've seen, I think, a lot big ott service providers already deploy these kind of overlay networks with their private infrastructure to provide better performance for dedicate their their own service and in the oral networking. Basically, multiple pops point of prices are deployed worldwide to relay the traffic and also in the network. There can be uh private circuits or the public were based on purely public internet.

L

For example, huawei deployed this kind of over networking based on a hybrid mode, with private circuit and also public internet, and also, for example, akamai and agro they deploy purely on on the public internet and some big ott. Actually they have their own backbone network, but conceptually there are also some other networking and basically in in the oral networks and an endpoint can use already for the path and instead of the direct internet pass to maybe for to achieve like lower latency or bypassing some congestion points.

L

uh Next next page piece.

L

Okay, and actually the the current overlay routing part, is, can be shown as the light figure and uh is computed conceptually logical, uh logically centralized, but actually the whole path can be decomposed into two segments, the first one.

L

We call the access from the source to the access point where the ingress were the destination to the egress point, and actually this part, the routing work basically is like the access point, selection process and the source need to uh get the address of the access controller and ask the controller to assign the access point either ingress or egress, based on some geography, location or latency and inside the network.

L

We call the backbone segment and the english segment actually is only maybe composed with like hundreds or like pairs of nodes, and basically the controller can configure the auction path in the backbone. You can find always find the option pass from ingress all the way to the egress.

L

However, in this kind of diagram, actually there are three main problems we observe uh the five. The first one actually is. The local optimal is not always the global, optimal. Okay, it's more like our nitro subway system and even if you find the closest or the best access point and you'll find the best path within the backbone. But in the end-to-end perspective it's not always optimal and we do have a real example in the figure. For example, if the user from the zimbabwe wants to send traffic to thailand- and one way is the black path.

L

Actually, you find the closest ingress point and which is south africa and hong kong and you have the the good path between them, but the whole latency is around 250 milliseconds, but instead you don't have to do this. You want to achieve the global ultimate. You can the demo. We can find a further access point, which is actually dubai. It's not shown here and it's in the middle and also the thailand can also access it to dubai.

L

And just one point: you can relate the traffic and the total uh latency is only 160 milliseconds, but this green path actually is, is not able to be found in the current diagram or not mentioning to use that, and the second problem is about complex signaling, basically to uh in the current uh framework the source need to.

L

If you want to send anything, you first need to have the dns request to get the address of the destination and then, if you want used over the networking and you need to uh get address over the access controller, and then you ask access controller to the access point, and so many kind of like complex signalling and the third problem is basically the motivation of the p energy. Basically there's zero uh information about the path.

L

At the end point, there is no pass on awareness and if, for example, for different kind of traffic, sorry different kind of service, you cannot have the flexibility to choose a path. Next page, please.

L

Okay, then, to address this uh problem, actually we propose some potential extensions and actually there are in three places. The first one is about the end to end joint pass computation.

L

Basically, you can compute the entire overlay path, including both the access segments and also the background segments just to give the entire over the path, and also this end-to-end controller can be can play as a root, dns server. Okay, then, therefore, to configure the path you can just use or reuse the dns tunnel.

L

Basically, whenever the source I want to send anything to the destination, for example uh the ietf website, and you need the address. Okay, you need to query the dns, but in the meantime you can have the overlay path request together with the destination request, and just you just need one route and again has you know the dns, a recursive kind of query, and it can return you the address of the destination together with the entire overall path and uh and of course, you need some extent.

L

You communicate based on the edns, the extension of dns, and maybe you need a kind of new uh option code for this kind of request and the third extension actually is.

L

Whenever you have a dns response, and you already have a central path, and here the path can be can include, for example, the the list of the pop, and also it can include some past property information, for example, about latency and bandwidth, and you can choose from them and based on based on the dns response, and then you can just use simply use source, routing or second routing.

L

I think you already talked this a lot, but actually here the difference, is uh you just directly use segment source routing at the very first point at the end point and uh encapsulate the package, for example, if what you want to use path, 1, 3, 4, 5, you just give the list in the packet header and the send to the send to the network, and also the all the pop or the folding node, doesn't need to maintain the routing state and it can for the traffic based on the information in the header and all the way to the destination, and uh basically that's our next page piece yeah.

L

This is just some uh first uh thoughts and I think it can be very complimentary to the ic at one work and we are very we'll be very happy to like collaborate with everybody else to try to document this problem state and, let's see how we can proceed yeah. That's all! Thank you.

B

uh Okay, any like comments from anyone.

B

B

H

B

Some, I suggest you ask for any like feedback on the list right because well, I guess not everyone on there who is reading the mailing list is in this room right now right. So I do not see anyone like rushing to the microphone to give any comments.

B

So I suggest we just start with that, because I think the first thing we need to find out if there is any any interest in the room to like work on it right. Some, okay, okay,.

E

B

Okay and we're going ahead of time, great so hiroshima floor is yours. I am.

B

Yeah, yes, okay,.

B

If you want here like, I guess, people might hear you better if you do that, but it's like up to you.

D

Keep my face this direction so um can I.

H

Yeah yeah, please please, go ahead.

D

Okay, so yeah good afternoon, everyone, I'm chris kasaei uh from white project and preferred networks. um I'm going to talk about the separation of data paths and data flow suppliers in the transport area. This was originally indeed for the tsb working group, but I think this kind of discussion should be here because this is related to past data paths. So um next next slide please.

D

So this is the motivation. As you know, the internet is uh oh really, uh that is right now and the um it was uh yeah. The principal of the internet was the end to end, but we have more and more smaller network gears in between the end host.

D

So, for example, we have our qis middle box and then we now have the new distributed computing technologies such as the powersup model, machine machine communication and edge computing and in network computing in network computing is a little bit uh difficult for me still, but we have more middle boxes in the network, so I think the end to end principle is now over. So we need to think about how to our review, how to design the in the future internet so the according to the rrc 1122 and 1123.

D

Do we have three layers and four layers link layer, internet layer, transport, layer and the application layers and uh yeah the link layer and the internal area is okay, so internet internet layer provides the um entertain reachability, but the transport layer implements too much so the next slide, please. So no, no problem yep. So the ip loading is a based on the hub hope.

D

I have a strong evolve or nature with a single or multiple uh cues in the router but transport layer, some of the functionality of the transport layer, end-to-end functionality, so, for example, reliable data communication. The transmission integrity check are the end to end functionality, so the levelers do not need to do nothing. So data path is just a data path, but there yeah, of course, in addition to the reliable data communication flow control for deletive buffer management, is a dam performed by the end host and the transportation security is also performed on the endos.

D

However, we have some stat dependent function functionality, so the end host needs to know about the data path. So, for example, the we when we perform the past empty discovery, we need information of the mtu on the database. That is that that is accomplished with the icmp now, but we uh sometimes we have many problems with the possibility discovery so so, and the congestion control is also performed on the end host.

D

However, the uh congestion is actually occurred on the routers or data paths in between the levels so and the eachine exclusive condition notification is implemented in the letter to um notify the condition information to the end host. So some of the functionalities on the transport layer require the information of data paths.

D

Moreover, the several meter boxes request to know the waypoint, and this kind of meter boxes may have a state of the data flow, so we need need to implement some kind of the waypoint aware routing technologies, for example, the firewalls are implemented at the gateway or the transparent, transparent protein could be implemented, with the uh I mean deployed with the policy based routing, so the transport layer needs to be aware of the data is for some functionalities. So next slide, please so and more. uh We have more password data communication here. So multiple has multiple.

D

We have multiple protocols, we have http mptcp, mp, click, mpdccp and so on, so that these protocols should be passed away so that we can use the two two or more database efficiently and the aqm is aware of database. Actually, it's aware of the two of the database and in addition to this, we have more emerging technologies such as the pub mtm communication edge computing network slicing and in network computing.

D

So this is achieved these new technologies achieved with the program network programmability, so the the infrastructure of the ip leveling becomes more smarter. I mean so next slide please.

D

So this is the this stress shows the problems with the transfer current transfer portrayal problem uh protocols, so the kind transport protocols are tightly coupled design, uh so I mean so all components of the transport layer. Functionality are integrated to the one protocols so, for example, click.

D

That is a very good protocol, but that has a many functions in one protocol. So if we want to make a mp quick, standardized the we need uh some kind of the reinvention for the click, although we have an mptcp or http for the multiply protocol, so it is very difficult to develop the new transport layer protocols.

D

So quick is okay. I think, because that is a test transport layer, but if we need some uh health or cooperation from the ip layer, for example, if we have a ecn for the congestion control, that would be better, but if we want to design such kind of a feature that cooperate with the ip layer and the transporter layer, I think we need to um abstract the current transport layer layer to in order to develop the both epi-friendly and transport air friendly network extensions.

D

So next slide, please.

D

Thank you. So I have uh just reviewed the transport layer functionality here, so I think we can separate the transport layer functionality into two separators. Two functions are two more functionality.

D

One data path and the other is data flow. So, regarding the data path, um that is uh the state race or purpose state that that handled the purpose state or that is a state status for the data flow that is uh handling the pass-flow states. So for the database layer we have our functions as the trajectory or waypoint handling, bi-directional connection, resource monitoring for congestion control and congestion control data from much much bridging.

D

This is the similar to the quick connection, so the quick connection can multiplex the multiple date flows. Over the I mean multiple streams on the one connection, so this is the similar to the quick idea and the database reflects one of the data fracture data function is the patent duplication, so I think there there was another research group for watching grouper. It was talking about the fake on the tcp protocol, so I think that this kind of the uh the duplication replication could be a database functionality.

D

On the other hand, as for the uh regarding the data flow, the sub layer, the retransmission or flow control, that is, for buffer management for the received side and the flow prioritization, entertainment security and um inverse multiplexing for modbus protocol uh could be a data flow functionality. So I separate this functionality into two. So next slide please.

D

So this is my proposal so for the future development of the uh transport auto protocols and as well as the ipl extension to the ip. So um so this is the what I said in previous slides. So I don't think I need to mention more, but this kind of the uh um layering, so the database layer is above beyond the ip layer and the data flow layer is above the uh database area. So the data path layer protocol can multiplex the multiple data data flows already connected.

D

There could be a bi-directional connection of a unidirectional one, so the data, so data flows are multiplexed over the data path that this means that so next slide please.

D

So um this is the uh one of the use cases. I I'm thinking about the main use cases now and I'm uh reviewing the other transporter protocols. Tcp, quick, http and so on, but this is the uh I I have only. uh I thought I had only ten minutes, so I picked up one used case here so recently we have lots of machine tool, machine communication devices in iot.

D

So if you're downloading something in you, I mean human download, something you are aware of the some kind of the network. So the best effort is working fine, but for the machines machine, don't think machines, don't think so they are trying to send a packet, send a file as much as possible at the maximum rate. So if we use the best effort model that may cause some troubles in a standard problems, so if we can have some help from the network side.

D

So if you can know the congestion information or some kind of priority information feedback from the network side, we can coordinate arbitrate. The flow priority flow priority. So if we have uh two kind, two types: two priority data here uh high priority: one: the low priority one low priority y is just for archive and the high priority. One is for the data processing and we have.

D

If we have the data transfer for the archive and if we, if the height priority data is started after the uh the the data transfer of the or operator and then the this data path may have a congestion. So if we have the uh feedback from the router uh on the for the from the datapass layer, uh the this uh low priority date, transmission could be controlled. I mean arbitrate and the data more lower data rate so that we can have a higher rate for the higher priority data.

D

So this is very similar to the ecm. So for the this use test, the next slide please. So this is the kind of pseudo um flow diagram.

D

So I don't need to say anything more, but this scenario could be achieved with the tcp ecn and dhcp, but if we can have more sophisticated or more extended information from the data path, we could have a more better condition, control, algorithm or certain things. So, the recently we have the sum of our data center uh transport layer protocol implement the streaming telemetry to get the more precise information on the buffer on the data path.

D

So if we we're going to use that such kind of information, I think the separation of the data from the database is useful. So next slide please.

D

So this is the last slide from me. So thank you for giving a time here so the I think uh this is very related to the uh past priority here. This is a uh related to the uh data path.

D

So so I wanna get the feedback from you and I'm going to continue the discussion on the uh that gap between the hubble hub and the end-to-end uh mechanism between the uh ip layer and the transport layer and from the people into database and data flow, and I'm gonna, I'm working on the reviewing the existing uh transport layer, protocol functionality, and uh so the third item is the. What we want to ask you here, so I want to um yeah as the internet is a kind of that is right.

D

So, but I don't want to create a clean slate architecture, because the internet is a great architecture, but we need to fix or modify some of that. So I wanna uh discuss you, uh discuss the architecture for new communication model and distributed computing here.

D

So if you have any use cases that could be uh helpful um with the separation of the database and data flow separators, I want to know those kind of use cases, so that is the I want to do and as a protocol development, I think uh I need to review the existing existing existing transport layer protocol, but I want to develop some kind of uh example, data path and data flow protocol using this architecture.

D

So that is the my next steps and this I want to get the feedback on the the architecture for future.

D

Data communication for better world, so thank you so thank you very much.

B

Okay, thank you. I think we have glory in the pew.

M

Yeah I'd just like to say thank you for the clarity in your talk. That was really clear. What are your plans for the next europe? Are you going to work on this more.

D

um Yeah, I I needed to um work on this item in uh the tsv working group so that we can publish the uh new layering model, but before doing that, I think it is better to discuss uh the uh the existing uh protocol and future uh potential models or potential um use cases, because the um this is the uh not for the past. I mean this. This is informational, but uh uh this will be for future. So I wanna work on the uh historical review and the future discussion here.

M

I would love to see more of this discussed in this research group. It's. It was really good. Thank you for your talk.

B

C

I am putting myself in the queue as an individual uh second in gory. um This is a discussion that we've had at various levels of clarity in the ietf for a long time right, like so trying to figure out kind of how to take these transport layer functionalities and make it work in a cooperative way and the network that we have- um and I I really like the clear like this. This framing of this is a really interesting way to take it. So thank you very much for the presentation.

C

um I think um one question I would ask is so like that, uh speaking as a proponent of the the long dead plus buff, um which was a previous attempt at having this discussion, I think about five six years ago, um I'd ask if you have seen uh the rfcs that came out of the ib stack evolution program on path, cooperation and wire images. um I can.

C

I can follow up with you offline about that, there's like a couple of things that that I think, might actually um help you with the framing of the historical, uh the historical discussion as individuals, so no chair hat on. I also think that sort of um we've done a good service to the community as this research group, when we've looked at sort of like the history of of interaction between the transport protocol or the transport layer and the rest of the network, so so spencer's draft uh this.

C

This work looks like it's very much in the same lines as that. So so I would love to see this discussion um uh uh continue in paneragy as well. um So thank you again.

D

Yeah, thank you. So I think that this or work is also related to the uh this morning. Discussion in the edm uh yeah. That is a I'm, not sure what that's! What what? What that? What stands for, but uh electronic.

C

D

Yeah yeah, so I think that that is also related right.

E

D

Under me, something.

C

uh Evolution, deployability and maintainability yes, but the joke is electronic dance, music, so yep.

D

Thank you. Thank you. I'm going to continue this work, so I want to send the email after this session, so please give your feedback uh from this research group so that I can work on the uh this work more more harder, and I want to discuss these kind of things among the or this research group and among the itf community. I think so. Please give your feedback I want. I want that.

C

We still have a little bit of time. Does anyone else, anyone else in the room or or in medeco, want to come up and and give some feedback not on the list.

C

Going once going twice cool we'll take it to the list thanks again, thank.

B

You very much thank you, okay, thank you. Everyone, thanks for taking notes, appreciate it. Okay, so it looks like we have some action items and some reading to do it so see you, london or actually on the sign interim sometime in october, and we can get like 11 minutes back.

B

B