Session Date/Time: 21 Jul 2026 09:00
[00:00:13] Yongxing Zhu: Looks good.
[00:00:30] Dan Voyer: Welcome to the srv6 working group. Ops. Ops. Srv6ops working group.
[00:00:39] Dhruv Dhody: Good. Just
[00:00:41] Dan Voyer: so you know, you're not in the spring working group. This is the ops -srv6 working group. My name is Dan Voyer, my co host Dhruv and WeiChang. We're happy to welcome you and host you for this session today. This is a IETF following the note well. This is all your contribution, and usually we write this so everybody can work respectfully between each other. I'm just gonna leave it there so you can scan the barcode to read more on it. Okay. So MeTo is not just a video or a a shared environment. There's also many other tools. For example, the note well, and every the session will be also recorded accordingly and then will be streamed over YouTube later on. So we encourage you to log in. That's how we know when you join the working group. You will see also the hands. So if you want to talk or go to the mic, please make sure you join the queue by pressing the hand even if you're remote or in the attendance. We will be taking the minutes, but if there is any volunteer that would like to help us taking the minutes, please just flag it in the in the chat. There's already a hands up in the queue.
[00:02:40] Dhruv Dhody: Yeah. Reach out. Reach out. Hands up.
[00:02:43] Dan Voyer: Oh, Richard. Are you testing the hand, Richard, or you do have actually a real question?
[00:02:52] Richard: I it's been there for a while, so it must
[00:02:53] Dan Voyer: be Okay. So the s r v six ops, we also have a a git that you can go see every presentations that we have through a work session are going to be hosted and posted on that git. This is something that we maintain, Dhruv, myself, and WeiChang. Status for the document that are being adopted in the working group. So we actually have the srv6-deployment that is being adopted as a working group item as well as the summaries. And we hope to have other documents to be adopted this week. And we also received a liaison document with the ITU for the srv6 DPTM. This is just for information. You can go and see the information on that item. Okay. For agenda, the agenda is full pack for our session. We're going to start with a few presentations and Nick from DT is going to present the adoption and the move toward SRv6. Then we have nice presentation on the migration from MPS to SRv6 accomplished by China Telecom. We have Ahmed talking about the SRv6 in the context of Sonic, and then we move to the normal draft review over the session. Is there anything that you would like to change? Thank you. We're going to start with Nick on the SRv6 approach. It's coming up.
[00:04:57] Ahmed Abdelsalam: Just a second.
[00:05:02] Nick Leymann: Okay. So yeah. Good morning. I am going to talk a bit about our, let's say, plans for s r v six in our networks, not only a single network. I'm going to talk about a couple of networks. So first of all, a bit of, let's say, context and motivation. So, I mean, as as mentioned, I'm not only talking for DT Germany, but for DT as a group, which also covers all countries. And what we did over the last couple of years, we basically came up with a strategy which is called horizontal digital architecture, which describes how our networks should evolve in the future and which direction we are going to move. One of the building blocks is the, let's say, pure IP network layer, so for core networks, access aggregation, and so on. And the decision here was to go with s rv6 as a technology. So not so much with MPLS anymore, but we want really we want to harmonize our networks. We want to harmonize the architecture blueprints, protocols, things like that. And that was the reason why we said, okay. If we look what kind of protocols are coming up, in which direction are the networks moving, s r v six was our choice. I think it was the the right point in time because what we also saw I mean, you probably know that especially larger ISPs are not the fast moving thingies here on the planet. So that means I think we we were right in time because we saw that s r v six got a lot of momentum, not only, let's say, in standardization and so on. So the standards basic standards are all there, but also implementations. And we also saw other ISPs implementing s r v six in their networks. So that means it's basically ready for end to end deployment, which also includes, for instance, connectivity into data centers and further download only, let's say, to an MPLS work like a PE device, but also to CE devices and things like that. We tried that with MPLS fifteen years ago. I would say some of you probably know seamless MPLS. We failed because MPLS was not really suitable for doing the extension up to data center level or access nodes. That was kind of complicated. Also, if you take our scalability into account, so we have different networks and the scale the number of nodes we are talking about are somewhere in the range from, let's say, a couple of hundreds up to 50,000 nodes, which we want to address. Yeah. Okay. What we also yeah. That's better. What we also saw is this new features are now more coming up with s r v six compared to other technologies. So that means if you really want to be, like, at the edge and want to deploy the new features, you should do it with s r v six. And another thing is migration. I think the the path and there's also another presentation today. The path from MPLS to s r v six is kind of straightforward. I think the migration usually, it's complicated, and I wouldn't expect would expect also that it's nothing which will go, let's say, in a couple of months. But I think all the tools are there in s r v six. The setup we are we have is I mentioned I'm talking about not only the DT network in Germany, our core network. I'm also talking about the networks in the other countries. And every, let's say, subsidiary runs its own network. For instance, in Poland, T Mobile, Poland runs their own networks, their own AS, and so on. And the idea was to have a group wide activity to include all the responsible people responsible for our network architecture in their countries in a single group and to discuss in which direction we are planning to go. So we came up with a blueprint, and the intention was really to develop a kind of harmonized IP network architecture. And what we, of course, also found is if you look on the existing deployments, of course, it's not a single vendor and it's also not a single architecture. So we are talking about even if you only look at the core networks, for instance, like five, six, seven different vendors in the networks with different capabilities, Also, the network architectures are different, for instance, depending whether you deploy fiber, DSL, or cable networks. And we also saw a lot of different topologies. So that means if you are talking about a group wide approach, that doesn't mean that we have to we want to force people towards a new architecture. We want to give them more like an the blueprint into the hands. And if they consider, for instance, a life cycle for architecture and something like that, they should basically use that blueprint instead of coming up with their own ideas. So that was the intention. Another thing is which is important, also the connectivity between the networks. At the moment, everything is done via traditional transit peerings and things like that. But in the future, it might be of interest, for instance, to offer services end to end, not in a single network, but across several networks. And that's also something we took into account when coming up with the s r v six blueprint. So some things which we basically also looked into more detail. When we started initially, there are still the discussion with versus So most of the scenarios we see are also doable with On the other hand, is basically what everyone is implementing and which is what is well supported. So it means that we definitely will go with a microset approach for all the networks. We are also looking not only on the core networks. That was our starting point. But we also said, We have certain scenarios, for instance, where we want to extend connectivity into the cloud. So not only having, like, a physical network edge, but also virtual network edge. So how do you integrate those virtualized routers running somewhere at the hyperscaler into your existing infrastructure. A key point was addressing because we want to be able to interconnect networks, for instance, without renumbering and all those kind of stuff, which means that we want to have an addressing scheme which is kind of harmonized and unique across all the countries. That means that, for instance, that a country or network can have some kind of ID ID. And the ID is kind identifies the network so that we do not end up with, let's say, overlapping addresses also for srv6. So that was one of the key points in our network, which took a while. So I think we discussed that probably, I would say, for eighteen months or so because also of the different sizes of the networks and the different requirements. It was not so easy, but now I think we have an idea in which direction we are going to move. Another thing, of course, was I mentioned that earlier, the environment or environments we have at the moment in the different network. So they are it's nothing is basically aligned here. Everyone has his own network. And especially if it comes to things like migration and so on, everyone will start at a different time from a different network. So that from a different, let's say, vendor landscape and also from different features and stuff like that. So which means that this is probably something which needs to be taken into account by the persons which are locally responsible for the network, so there will be no centralized approach for that. And what we also found that there were already a bunch of pox running in dt group with s r v six. So that was also, I think, a nice outcome because usually, we talk, of course, to all the other countries and so on. But having, like, a focus group as a idea to come up with a harmonized strategy for certain things is probably a good approach. And also in Germany, for instance, we did quite extensive tests for our next generation mobile access and aggregation network with srv6 a couple of years ago. And also, all the results will probably go into this kind of activity. Another thing is besides the, let's say, pure migration of core networks is also the integration of data centers. So how do you interconnect with s r v six, the data center, or even into the data center? So that's something we are looking into. But we honestly, we don't have a clear view now. So we are looking on the use cases and the different scenarios. We are collecting ideas and so on. We are also collecting requirements from our data center guys for connectivity. But there are definitely different layers. For instance, you can either do a connection based on, let's say, more an overlay model where you go with srv6 up to the service chain in a VM. Or you are, let's say, two levels below and you consider, for instance, extending a layer to v p EVPN or something like that, not only to a DCI data center interconnect or LER router, but also directly into the data center. So I said, we are currently at the moment looking into those scenarios. And the advantages we see is that we if you look on how many routers usually between a network edge and the data center functionality you have, you might be able to save one or two of them. And also, there is no technology break. So that means that you can do s r v six end to end instead of, let's say, terminating domain number one, stitching it to domain number two with different tools, and all those kind of stuff will hopefully then disappear. That's one of the use cases I mentioned earlier. We are also looking how we can extend connectivity into the cloud so we don't have a physical box sitting somewhere but a virtual box. How do we connect those virtual routers to the existing physical networks? And with s r v six, we also had some pox with that. It looks probably more straightforward compared to other technologies because most of the networks support I p v six anyway, which means it's kind of easy to have at least the basic connectivity. And then you can put s r v six on top of that. So in summary, we have a harmonized strategy for all the members of dt group and in which direction we are going to move. The strategy includes the use of s r v six. We are not forcing the different countries with a, like, a plan and timing and stuff like that. So it's up to them how long it takes, but at least they have some guidance, including us, how we basically move. We have a single paradigm for forwarding and control plane and so on. And, of course, what we also have is a bunch of well defined standards. So it's really that we can point if you're doing RFQs and stuff like that to a well defined set of RFCs or upcoming RFCs. And also, for us, it's a kind of natural evolution of the existing MPLS networks. You could, of course, go to srmpls and then to srv6. Many other I ISPs are going directly from MPLS to srv6, and we are also on that kind of path. So we are really doing evolution from MPLS as a, let's say, older technology technology to a more flexible approach based on s r v six. That's all I have. Questions?
[00:16:56] Dan Voyer: Thank you. Is there any question for Nick?
[00:17:07] Tom Hill: Hi there. Tom Hill, British Telecom. A very interesting presentation, so thank you very much for for giving it. The part about the cloud interconnections and and working with virtual routers in the cloud, What is your kind of security model for that? Is that limited to Direct Connect only, or do you have that work over the
[00:17:27] Nick Leymann: That's a good question. It depends a bit on the connectivity model. So the basic idea is that we can run it everywhere. But I would expect or the expectation is that we have, in that case, still some kind of border routers protecting our core network against potential things, for instance, which could go wrong in cloud cloudified environment or something like that.
[00:17:47] Tom Hill: So is there any transport security for for IP? Or
[00:17:51] Nick Leymann: That depends who we we are partnering this, what they have in terms of capabilities.
[00:17:57] Tom Hill: Yeah. So IPsec? Or
[00:17:58] Nick Leymann: It could be. Yes. It could be. Okay. It's not decided yet. I mean, I we are doing POCs at the moment. I think there's no additional encryption or something like that. It's more direct links, partnering, and so on. But in the future, if you go into the real deployments, I'm pretty sure that our chief security guys have also some requirements in addition. Yeah.
[00:18:17] Tom Hill: Yeah. Mine too. Thanks. Toby?
[00:18:21] Dan Voyer: Toby. Yeah.
[00:18:27] Toby: Really great information. Thanks. One thing that I was wondering on the IP addressing harmonization, there's this big back and forth between using global space versus the five f slash 16 stuff. Like, how do you deal with, like, spoof protection, which would speak for the five f versus, like, uniqueness around
[00:18:48] Nick Leymann: So we will go with the five f and an additional format for that below the five f. So we had a bunch of discussions also with global, local, whatever. And especially for the harmonized approach, we we said five f is the way to go. Yeah.
[00:19:04] Toby: So you expect everything private connectivity, basically.
[00:19:09] Dan Voyer: Question from the chat briefly. Did you encounter any challenges in the migration? Did you encounter any challenges for migrations?
[00:19:18] Nick Leymann: Well, I mean, we are not migrated yet. So at least not for the network in Germany. So I I guess I can answer the question, like, in two years or so.
[00:19:27] Dan Voyer: In two years
[00:19:28] Nick Leymann: Or three years. For
[00:19:29] Dan Voyer: Reshab. But the next presenter actually can have a good story for a lesson learned in migration.
[00:19:35] Dhruv Dhody: Yep. Yeah.
[00:19:39] Richard: Thank you.
[00:19:50] Thomas: Hello,
[00:19:54] Yongxing Zhu: everyone. I'm Yongxing Zhu from Time Telecom. Today, I'll sharing I'll have a sharing of the experience of a migration of our NPS network to s r v six. We have employ we have migrates both of our service to the srv6 network. Let's have a look at the our network before 2020. There are about three IP backboons in telecom. The first one is tunnel tunnel tunnel net, which is for public service. The second one is the the thing two, which is for voice and business services. The second one is the DCI, which is designed for the DC connection, DC connection across the country. There are also two network, IP network in the area of the city. The fourth one is the IP map, which is mainly for the pub which is mainly for the home service and the business service. The second one is IP run, which is for the for the redo back backhaul and business service. Thus, there are lots of network in TAN Telecom. There are over seven seven hundred networks in the telecom. Since they are built in different phases, there are lots of protocols in the network. As for the control plane, there are it is OSPF, v two, v three, v three four plus, RDP, r RSVP. In the folding plan, there are before b six and amperes. This brought brought a great pressure for us, especially in CapEx and OpEx. Besides that, separate separate network for different service services led to different service experience, which which was rather troublesome for us. So we plan to that's the network reconstruction, upgrade, and the server migration to achieve the unified unified service carrying via simplified and unified portal stack. Then we hope to flexibly steer traffic via network programmability and enhance network reliability via fast recovery technologies such as p r r v six PRV. Under the motivation, we deploy an e two e r r v six, enabled IP network to guarantee service performance. We built the cloud for the IP map to uniform recurring business, home, and customer services as well as cloud services based on our statistics. Then we reconstruct IP by pool to provide e to e connection among months, IDCs, and hops based on r s v six. During the in the process of the migration, subject migration, there are two modes to four different scenarios. The fourth one is the current mode, The which is suitable which is suitable for scenarios where the ratio of a self sufficient capability devices is less than 50%. In this scenario, we directly migrate RMPS networks to r r v six so as to ensure smooth network evolution and minimize the migration period. First, we deploy a greenfield SRV6 network, then migrate the SRV6 capable access net devices from Ampere's network into SRV6 networks to enable migration of their attached services. At last, we replaced the remaining legacy access devices with other six capable ones, then migrate the corresponding surface to the s r six network. The next one of the macro mode is brownfield more brownfield mode, which is suitable for scenarios where ratio of our services capable devices is no less than 50%. To enable our services capability, our network devices to carry a surface and gradually replace our paired only devices with other offices enable enable once. First, we enable as our visit function on all as our visit capable devices. Then we prioritize Azure v six based service carrying during the coexist period. After ingress under the egress, node both support Azure v six, then the other phase six capable services are covered by e two e as of a six panel. After ingress, all egress nodes don't support as of six. Then subsidies are carried across the amperes and the others have received domain through interworking technology. At last, we gradually replace the remaining amperes only devices. Nowadays, there are only 10% of the of them remaining in the network. There are many approaches for each working of the SRV6 and the RMPS networks. Here, we take the interworking of r m p s r three v pin and r r v six v pin as an example. In this in this slide, the the the yellow part is the amperes amperes enabled IPMAP IPMAP. We call the old one. The blue part, we we call the is the SRV6 enabled, qualified IPMAN. We call the new one. The two one the two network collects which data through ASPR and the belief to perform the interworking. We build the IP addresses between the ASPR and the BRIF. That thereby into thereby extending the IDP no domain and RPS handles from RPS enabled IPMAN to BRIF. The VPN VRR, that is VRR, distributes the VPN routes to belief to be which which then to which then routes from VPN address family to EVPN. Then use it with the PDF performed translation on the on the following plan. If the packet is forwarded from r r v six domain to r r domain, the belief will invoke the roots reorginate process. And the package will be forwarded in the opposite direction in the belief on the belief. IP address allocation is the foundation is the foundation of the SRv6 network. We unify we uniformly allocate as IPv6 address to reduce routine maintenance complexity under security risks. Firstly, we allocate service addresses and the infrastructure addresses separately. Then allocate IPv6 address, GUA. Based on service category and regional division and enabling efficient efficient routes aggregation within domain. Here is an example. First, we allocate different r r v six seed blocks for pattern, business, and home services service tops. Then allocate flash voltage as a as r r v six seed blocks in the unit of province. Each province further allocates r r v six seed blocks on a per metric basis. With the IPMA or Metaport, also unit of the IPMA. Assigning the locator according to a network devices and the flex slices. Routing, in routing protocol, we unifiedly we uniformly deployed the edge p and the BGP in other v six node network to simplify the control plan. We deploy the IDP IDP protocol that is to say that is is is it is to simplify the configuration and operation. Here in the slide, we can see there are two easy process separate easy process. The green part the green part, we call the access layer of the of the of the IP map of the IP net network. We deploy the a d the process 11. The the the blue part, which is aggregation and the courier, we deployed as a process 21. The two process were separated. We repeat we redistribute routes between different IDP processes via routes process to maintain isolation. As for BGP, we deploy the MP BGP to carry both I p v I p v four and I p v six routes concurrently. Network operation and measurements for r r v six network is is is indeed the principle for SRV6 network. Besides the traditional OM and OM two, we utilize network telemetry to collect the detailed information of network and devices on demand. We also use the alternate alternate marking solution to achieve precise in band measurements of a packet loss that is under jitter. Alternate marking is actually a series is based on a series of I ITF standards, including after '93, '41, '93, '42, and the ninety nine ninety nine forty forty seven. Let's wrap it up. First, we formulate different migration strategies. That is the greenfield mode and the brownfield mode according to different scenarios so as to decrease the CapEx and OpEx and the complex complexity of our migration. We did deploy the r f v six seed compression. And we uniformly allocate the allocate and granular granularly partition partition the I p v six addresses to reduce management complexity. The fifth is we perform seamless service interworking via route re ordination between different address family and the label to see mapping as the into working node. At last, we have network operation and the measurement via network telemetry and out out alternate marking. That's all for today.
[00:33:57] Dan Voyer: Any questions for the presenter?
[00:34:08] Dhruv Dhody: Himanshu Shah from CNN Networks. Did you come into a situation where an egress PE who's doing who's a dual stack, who's doing, who's capable of s r v six and s r m p l s and is doing an l three VPN, let's say. Does he advertise a single, l three VPN route with the BGP prefix in and and peer with an RR who's doing both, I p v four, ingress PE, and the s r v six capable ingress PE? Did you have to advertise two route? Did you come into a situation where you had to do an l three VPN peer ship with an SRM PLS purely and SRV six purely? Two. No. So Did yeah. You Okay. Go ahead and explain.
[00:35:14] Yongxing Zhu: Sorry. I I I I'll hear more more detailed explanation to answer your questions. Yeah.
[00:35:38] Dan Voyer: A live translation.
[00:35:42] Dhruv Dhody: Without AI. Without AI. Yeah. Yeah. P one
[00:35:48] Yongxing Zhu: this is this is a fly. Okay?
[00:35:53] Dan Voyer: Okay. Can you send your question in the mailing?
[00:35:56] Dhruv Dhody: Yeah. Yeah. You Just to just to reiterate. Right? It's a good question. One is an l three VPN or SRMPLS, same WRF. Okay? P e two is same WRF, l three VPN, but doing SRV six, and p e three is capable of both. Okay? In the same instance. Yes. You know, did you cover that and how did you
[00:36:21] Yongxing Zhu: Of lot. Okay. Thank you.
[00:36:22] Dhruv Dhody: Yeah. Dan.
[00:36:25] Dan: Yeah. Dan BGP. Two questions. Was there a specific reason why not moving to Micro-SID or you said? And the second one being, was there another also specific reason to switching address families from EVPN to l three from l three VPN to EVPN?
[00:36:44] Yongxing Zhu: We didn't use the alpha v six comp compression. Since we have a a plan at a calculation, that's in our network. The end to end pass, even in the s r v six t, s r v six policy and hop by hop, there are about in 95% of the scenario, there is is the the the the hop the hop the hop number is less than 10 less than 10 less than 10. So we without the the the the the The the the the the the the the translation is we can put it the
[00:37:56] Richard: Yes. You have the control.
[00:37:57] Ahmed Abdelsalam: Okay. Thank you. Good morning, and thanks for the church for giving us opportunity to give this update. My name is Ahmed Abdelsalam. I work as part of Cisco. And this is a joint presentation with AD from Alibaba. Important disclaimer before we start the presentation. This is a joint presentation with Alibaba team, but the work that we're going to present here is like a journey of five years. There are much more many more contributors to this work. I try to highlight it in different parts of the presentation, but it's just important to make it clear at the beginning that that's not the work of these two people listed here on the presentation, but it's much larger team from different, let's say, operators and vendors. So this is, again, to give you a bit of update on the s r v six in Sonic as a journey for the last five years and where we are now in terms of deployment, in terms of feature support and what is the ecosystem behind this. And I will start actually from the deployment because right now, s r v six in Sonic is deployed into, let's say, one or at least in in the biggest AI data center right now at in the Microsoft Fairwater DC. But also it's deployed in Alibaba at the ECORE network, which is a DCI network at Alibaba. This work has been a contribution from multiple operators and vendors in the ecosystem, including Cisco, Microsoft, Alibaba, Broadcom, and Nvidia. And in terms of feature set that enable those deployment, we have a lot of or a big list of of feature set. The first one I I would highlight is basically the AI back end feature. And this is basically an s r v six static fabric where everything is programmed aesthetically. The routing for for for the s r v six locator and SID is done statically. So there's no need to IGB any IGB or BGB inside the fabric. Then the classic use cases for s r v six, including layer three VPN, the GRT use cases both for I b v four and I b v six, The static underlay or or underlay with with ISIS. And some of the feature also that has been added, is interesting is the s r v six SID manager, which something to make sure we align with all of the drafts that we have at IETF for the SID addressing and interoperability between Sonic and the different vendor implementation. Then a bit to give you an update on where, when did we start this collaboration and how it evolved over the time. And the chairs gave me a question or a hint to share with attendees. It's basically what were the insights from the journey of the srv6 implementation in Sonic for the last five years. And if there is only one thing that we could share as co author of this presentation, is really the commitment. If you really need to build something in open source, and I think there is a workshop after this for open source, is really the commitment. You cannot come to an open source stack, just implement something and go away. The next time you will come to implement a draft, people will not even accept your code. So really commitment and being willing to fix bugs when when people see when people find them, adding new feature, etcetera. It's very important. You cannot just use open source as a way to prove that your draft is implemented, but you need more commitment to, how to say, to open source. Please, if you decide to implement any draft in open source, make sure you give the maintainer of that open source stack and how to say, the confirmation that you are committed to maintain that code afterwards. Otherwise, why would they take it? So starting this journey in 2021, that was the beginning of the s r v six microsite in Sonic. And it didn't start just as Cisco and Alibaba as I highlighted at the beginning. It was an ecosystem engagement and we get the support of srv6 in the first component of the SONIC, let's say, stack which is the SONIC. I will go a bit into the details of the different layers of the Sonic and how it's different from vendor implementation in the next part of the slide. Then one year after Alibaba started their, let's say, own operating system, what is called AliNOS, and it's based on Sonic. One year after continuing adding new feature and support into Sonic, that what that what led to the deployment of of Alibaba DCI network. And in order to take this farther and enrich the s r v six feature in Sonic, we started that PhoenixWing initiative. And it was again to build an ecosystem around srv6 in Sonic to add, to understand from operator what are the requirements into Sonic and how we can work in an ecosystem to enable them. So that was the first deployment for srv6 in Sonic. Then around, let's say 2025 last year, we started also another important engagement on Sonic, which is basically how to enable the SRv6, the required SRv6 feature in SONIC for the AI back end deployment. And as I mentioned, this is something that is completely static. So all of the SRv6 SIDs are allocated statically. They are programmed statically. The route for all of this SID is done static with non dependency on IGP or BGP. That was quite some work. We contributed around 120 PRs into the different component of the Sonic stack. And as you know, Sonic does two releases per year, one in May and one in November. And as part of the May release of 2025, all of this srv6 feature required for the AI back end has been already, let's say, merged in that release and officially become part of the release. And that's what was used as part of the Fairwater DC deployment at Microsoft. I don't have the time to share all of the details about all of this deployment and implementation detail, but I make sure to leave you some of the links here in the presentation. Then what is next and what do we do in 2026 as we work now? As you know that for AI infrastructure is growing. So basically you need in order to train the current model, you need extremely large number of GPU. You don't have enough power to fit all of the GPU in a single data center. So it's typically deployed in multiple data center. And you need a layer to connect those data center, what is known in the industry as AI scale across network. And in order to enable those network, there are some specific requirements that you need more than what you need inside the data center in terms of traffic engineering and fast reroute. And what we are working on right now is to enable those capabilities in terms of topology view that you need for all of the traffic engineering and the fast reroute and adding the traffic engineering and fast route capabilities as well. There was multiple presentation on this at OCB this year in Barcelona. And we have also an IETF draft that explain how you could do the fast reroute in those topologies. Because what is specific about those topologies is really it's a BGP only fabric. How can you do this traffic engineering and faster route in those fabric? In the last part of the presentation, I go very quickly on how what is actually something because every time we do this presentation, we get the question from the audience. What does it take in order to enable a new feature? Or what did you do in terms of srv6 in order to enable this into Sonic? And if you look you in the, let's say, or you try to search this, you get a lot of terminologies. What is Sai, Sonic, SDK, etcetera. How can you put all of those things together in order to enable a new feature in Sonic? So if you look at all of the definition, you get something like this, you you really it doesn't say much. So what we decided to do is to look at what the vendor knows looks like and how Sonic is match or different from those. If you look, you have the base layer, which is the hardware with with the p four and the SDK. On top of that, you have what is called SI, switch abstraction interface that unifies those merchant silicon. So I can program any merchant silicon from any vendor using the same APIs. On top of that, are still on the vendor side. That's what's called the hardware adaptation layer. Then you have the RIP, FIB and all of the protocol stack. If we look at SONIC, basically what is common between a vendor NOS and SONIC is the ASIC and the SDK. It's not a different ASIC, it's not a different SDK, it's the same ASIC. On top of that, but I get ASIC from many different vendors and I need to run SONIC on all of those different merchant silicon. So that's where the SI layer comes in to unify those ASICs. Then we have the SONIC stack itself on top of that, that provides kind of the FIB functionality or the forwarding chain. It's a set of databases maintain all of the routes next to hubs, etcetera, etcetera. And then on top of that, you need the RIB and the routing stack. This what the FRR routing stack provide inside the Sony. Another question that we typically get on this presentation, why would someone use Sonic instead of another, let's say, NOS from different vendor? It's basically the main goal is to have the same NOS with the same NOS bound API, but running on top of different on different ASICs. And how can you consume the sonic? There is also different ways to consume that sonic, either you do it your own. So basically, you have to bring all of these different components and build your own sonic. That's, I would say, if you are not a hyperscaler, that's model typically does not does not scale. And you have the different vendor that provide their sonic or version where you get all of the feature or all of the support features that you get with normal normal NOS. The last thing that or or answering the question or what does it take in order to support a new feature inside SONIC is basically to enable that feature across all of these different layers that you see. You need to have it supported in the SDK. And then on top of that, you need to have the site API to uniform to uniformly program this feature across the merchant silicon. I would say that's the most complex part because you need to get all of the merchant silicon or all of the silicon vendors to agree on one way to program this SDK. So it's a it's a it's a bit of, let's say, complex process, but there is a community for it. And and typically, this is reviewed in a community and and there is a consensus on on those APIs. On top of that, you need the Sonic player in order to enable that feature. And I think the the most critical component, especially if you are bringing any routing functionality, is the FRR routing stack because that's where all of the routing logic is done into into SONIC. And what we did in order to enable SRv6 in SONIC for all of these different deployment and the use cases that you have seen is basically to enable SRv6 across all of this all of this different layer. So to conclude, because I think we are almost on time, SRv6 in Sonic is mature. You can see all of the the list of feature that that is supported in Sonic. It is already deployed in some of the largest hyperscaler deployment either in the in DC at Microsoft or in DCI at Alibaba. And it's it enjoys a very rich ecosystem with both vendors and basically operators as well. Thank you.
[00:51:42] Richard: Questions then?
[00:51:43] Dan Voyer: Is there any yep. Go ahead, Alex.
[00:51:49] Alex: Hello. So first of all, thank you for the presentation. It's great to see that Cisco is that much contributing to the open source and to the community. Through the through the slides, you mentioned that you are were providing PRs to the code base of Sonic, FRR, and SI.
[00:52:12] Tom Hill: Mhmm.
[00:52:13] Alex: The later one makes me a little bit anxious because there is no open source side, for example, for Broadcom. Can you please provide more details for which side, for which chipset you are providing PRs?
[00:52:28] Ahmed Abdelsalam: Okay. So basically, if you look at the size, the size is two pieces. What you see here as a one component, there are two pieces for the size. There is the API to program. So that's common across all of across all of them. But every vendor has to provide a kind of implementation to that side into their SDK. So I would like how to say, in order to to to you need to get this implementation from the vendor itself. But the SCI API is is open source and and common across across all of the vendors.
[00:53:01] Alex: Okay. I think it's very important clarify clarification that there is no open source SCI, and there are vendors that are still trying to trade you with the software. The open the the the SIE API is open source. OCP SIE is all for for for everyone, but implementation differs.
[00:53:22] Richard: Toby? Yeah. Toby?
[00:53:26] Ahmed Abdelsalam: Thank you.
[00:53:30] Toby: One question, Toby. One question. Did you what endpoints did you use? Mostly NTT or ND? Because I noticed FRR, both FRR and Linux kernel still seem to have very buggy DX implementations. Are you not using that at all? Because you're saying it's stable.
[00:53:50] Ahmed Abdelsalam: It really depends on which in which layer you at the SI layer, all of and the SI and the Sonic, all of the behavioral support is both NDDT and NDD dot x. The the the the the where the NDD dot x implementation is missing is in FRR.
[00:54:10] Toby: Okay. Well, I guess it doesn't use the Linux kernel. Right?
[00:54:12] Tom Hill: So okay. One
[00:54:17] Richard: comment a quick one. I think maybe it got lost. This thing, when I when we were asking as chairs, one feedback that we needed was more from Sonic implementation and its deployment at Alibaba. What kind of feedback that you can give operational feedback that you can give from the s r v six community, something that we could reflect in our documents, in our BCPs, in our informational documents. So I was hoping maybe you don't have to answer that right now, but just think of that aspect as well when you are interacting with our Okay. S r v six ops. Thank you. Okay.
[00:54:50] Ahmed Abdelsalam: Thank you.
[00:54:50] Thomas: Next.
[00:54:55] Richard: No. No. No. Join the queue, please.
[00:54:57] Thomas: There there are some
[00:54:58] Richard: There's still some questions. Yeah. Please.
[00:55:01] Amr: Yeah. Amrushad, so the question, which is not a technical technical one, more kind of a release process thing. So you explained how it's complicated. You need to make changes in all those spots. How long does it take? I mean, I don't know whether you get the latest FRR or you wait for a stable release. Let's say you need to make changes in all those. What kind of time span are we talking?
[00:55:24] Ahmed Abdelsalam: Is it months? Is it years? So from perspective, they do two releases per year. So you have one release that comes in May and one that comes in November. And as part of this release, you get a specific FRR release. So the first thing to do in order to make sure that feature is part of Sonic is to make sure it is supported in the FRR main line. And you have to wait until the Sonic picks that FRR release. So I think, I don't know, I cannot give exact number, but it's on six months, let's say, basis.
[00:56:05] Richard: Q, quick question, Very quickly. Q?
[00:56:10] Dan Voyer: Q?
[00:56:12] Keyur Patel: Yes. Can you hear me?
[00:56:13] Richard: Yes. Go ahead.
[00:56:14] Keyur Patel: Oh, okay. Super. Hey. This is from Arcus. Two points for you. One is this seem like a and this is a note to chair. This seems like a lot of marketing presentation. Would be great to see in a a service six ops exactly what Dhruv said alongside with what kind of scale you gave. And the second comment I have is specifically directed to your presentation and riding on top of what Shasha said earlier, the first commenter, that Sai is not open source. What you are trying to say as part of being a Cisco employee that your part of Sai probably is open source, but other chip vendors implementations aren't open source. And if they are not, how do you sort of tackle that part? And how do you claim vendor agnostic or vendor into a product hardware chip interoperability, particularly when certain features are not available? I'll take my questions offline.
[00:57:12] Dan Voyer: Can it's Okay. Can you maybe send your question in the mailing list? We'll just move to
[00:57:18] Keyur Patel: Sure. Just make it
[00:57:20] Justin: very quick. Very quick. So I want to thank working together for two years, implementing this in the far out has been great experience. It's very different from my previous with Cisco. With regards to data centers, it's predominantly UN with UA in some other cases. Haven't deployed it, so I can
[00:57:36] Ahmed Abdelsalam: Thanks, Jeff.
[00:57:39] Alex: Thank you so much.
[00:57:40] Dan Voyer: Thank you. Michael, you're next.
[00:57:42] Nick Leymann: Yep.
[00:57:48] Dan Voyer: Thanks, Ahmed, for the presentation.
[00:58:08] Yisun Liu: Okay.
[00:58:11] Michael: I'm just gonna hold this.
[00:58:12] Richard: Yes.
[00:58:12] Michael: Okay. So this is gonna be a pretty brief update. This is a draft we've been working on for nearly two years. It provides migration guidance to s r v six from various data plane technologies. We've received some great feedback over the years, and the changes since the last IETF are as follows. We received some good really good comments, very thorough comments from Edward, and we made a lot of changes, terminology, and removing stuff that didn't need to be there and changing in some terms, throughout the draft. Added bullet points to just make it clear. So thank you to Edward for making the time. We didn't incorporate all of his proposed changes, but most of them we did. Puppet and last time, last IETF made a comment about RCPT coexistence with s r v six. And so we included a paragraph on that per his suggestion. We included the RFC eighty four twenty six, which provided that coexistence recommendation. And so that's some new text that would be good to review. So this is the last slide. So we have provided an update. We will provide any further updates that we may receive from Bess. We did send an email, but it was only a couple weeks ago. Because we have a section on VXLAN migrating to s r v six. And since that's kind of their thing, we were requested to get some guidance from Beth's. So we will we'll update the draft if we receive anything from them. We'll update it based on any feedback that we have today to see if there's anything that we're missing. We'll continue to make progress on some comments that we received kind of at the very beginning that we maybe haven't thoroughly responded to yet. One of the ones was how to migrate certain sections of a network at a time when we can't migrate the entire network to s r v six. We haven't been in a particular hurry with this draft. It's already proved useful to us to provide people to this is some steps you can take to migrate. But we seem to be moving closer to be working group last call ready. I think we're inching towards that. So that's it. Any comments or questions? Some things that we may be missing.
[01:01:03] Dan Voyer: Going once, twice. That's it. Very good. Thanks for the two minute.
[01:01:09] Dhruv Dhody: You got it.
[01:01:12] Richard: You.
[01:01:15] Dhruv Dhody: Weissong. Next one. Weissong.
[01:01:34] Yisun Liu: Hello, everyone. I'm Yi Sun Liu, Chain Mobile. Today, I will introduce the s r six deployment and operation problem summary on behalf of my co authors. This is the first presentation after the draft was adopted. And we have received a very valuable feedback in the adoption process. Thanks for the Laura and Yao Liu and Jimin and Edward. The first the first one, we we have a update for the migration. We expanded the migration scope to the VPN services, included the l two VPN in that clarification that the including VPWS and the VPRS. That is in addition to the l three VPN. One, discussing the service interruption avoidance. The second part is that for the past performance visibility, we rewritten we rewritten the the to better clarify the limitations of existing embed measurement methods and the lack of mature material tools for the s r v six specific met metrics. And the third part for the adjust planning, we added a concrete example demonstrating the how conventional per domain prefix allocation leads to nonaggregatable seed blocks, followed by optimized hierarchical scene that enable the root aggregation and make the efficient compression seed. For the third part of the security, we added a new appendix atom for the the the problem x seven, securing s r v six across the access network and the cloud network and the ADC networks. So we also added the acknowledgment for the providing feedback and the contributions in in the adoption process and in the individual draft first. So next, I I will give a very quick review of of this draft this draft mainly focus on the problem statement and not not not include the the potential solutions. So the the the problem one is that how to the part the first part is the s r v six network migration. The problem one is how to smoothly migrate from the existing enterprise networks to s r v six, make to ensure the service continuity, interoperability, and minimizing the deployment complexity. So the problem two is how to achieve the the scalable and the simplified end to end interdomain communication using s r v six. The second part is the s r v six net network with a visualization. A visualization that the including the the problems three and the problem four. The problem is that SRS six specific parts performance state collection is incomplete and inefficient. So the problem four is that the multisource state, like, for example, the BMP, IPFIX, and YAMPush, Let's the automatic collaboration and integration. For the third party, the Srv6 address planning include two problem, problem five and problem six. Problem five is that existing I p v six address planning efficient for the SRC's structural requirements. Problem six is that interdomain seed allocation causes efficient address utilization and hidens the root aggregation. This example is added in this new version that it is a comparison for the conventional and the correctional address planning and the optimized address planning. So we can see that in the conventional address planning so the address space is this continuous and no aggregation. So for the optimizer, as as as a six oriented continuous, and we can make the e three aggregation. So the the first part is that the s f s r v six traffic steering and protection. The problem seven is that we have various s r v six traffic steering methods existing. So make it difficult to selecting the appropriate one for each scenario. For example, we the popular master for the BGP color community, but it lacks granularity. For the flow spaced traffic steering method, it says, for example, the BGP flows back, but it now scale for the larger flows, large number of flows. So the the selection depends on the network architecture, service requirements, resource constraint, and the operation costs. For the problem eight, the s r v six problem, there was protection mechanisms, but selecting and coordinating the optimal solution is challenging. So we have multiple mechanisms of protection for the protection, for the parts, for the node, for the service, but different strategies for the different locations. So coordinating and the the the this existing mechanisms remains challenging. So the last part of of this problems is that the challenges by the net different network type. So, for example, for the data center, for the campus, for the carrier networks, we have different key challenges here. So this is the the list of the potential DOPs. So that's all. We want to ask a more review of this draft.
[01:08:50] Dan Voyer: Is there any question? Thank you.
[01:09:14] Jakub Horn: Hello. Good morning, everyone. Oh. No worries.
[01:09:20] Tom Hill: No worries. I
[01:09:22] Richard: was replied. Sorry.
[01:09:24] Dan Voyer: You were complaining about something.
[01:09:30] Yisun Liu: Hello. Good
[01:09:32] Jakub Horn: morning, everyone. My name is Jacob Horn. I'm on behalf of authors of this draft. I wanna do just really, really brief update today. So what we have done since since last time, since Shenzhen, we created a new version, version two. And besides some editorial changes, there is one significant change we added based on the work group request. We added replace CCIT compression section into the into the draft for completeness because there was a really strong push. It should be complete because those two compression mechanisms are together in one RFC. So we edit that particular section. The format which is compatible with thirty two sixteen, which is the common microsite format was used. And you can read the section and provide the the feedback on on everything on MicroSet part and the the replace it part. Any contribution is really, really welcomed. We appreciate your experience, well, your view, operator's view for for their protocol network because every network is slightly different. And because of completeness and most of the service providers have already deployed s r v six along. And according to this draft, I would ask our group for adoption adoption call as as quickly as possible because I think it's it it can be important important in the future. And that's it. That's it for me. So thank you. Thank you very much for your attention.
[01:11:05] Dan Voyer: Is there any question for Jacob? Is there anyone that thinks the the document is not ready for working with option? So we'll start the process for working group adoption in the mailing list.
[01:11:24] Thomas: Thank you.
[01:11:25] Dan Voyer: Thank you. Ahmed, you're back.
[01:11:38] Ahmed Abdelsalam: Okay. All right. So someone has a question. So this is to give you an update on the SRv6 for the AI back end draft. I will I will do this update on behalf of the authors of the of the draft. A bit to give you a quick reminder of the, let's say, the scope of of the draft. This draft discussed the use of s r v six microseed in the AI back end to provide and all of the benefits of that in terms of deterministic past placement and and using and providing minimum MTU to solve this problem with a congestion feedback loop to have a fast fail over and also being something based on the standard that has been done here in IETF. One of the important updates that I would like to give you in that is in alignment with this draft is the recent publication on the use of srv6 together with MRC to build a resilient AI supercomputer. And here, there are three many three main elements that that comes as part of this of this paper. First is the use of the MRC, which is multi bus reliable control and extension to the ROC protocol in order to provide things like ECN, out of order delivery and use things like packet trimming, etcetera. The second element, which is multiplane, is basically splitting, how to say, getting the maximum radix of the device in order to be able to fit the maximum number of GPUs only with two layer instead of having a third layer, which is makes a lot of sense to save the, how to say, the power consumption for this third layer, etcetera, etcetera. And the third element, which is the core of this draft, is basically how srv6 is used in that AI back end to first provide a kind of deterministic way of steering the traffic and also the simplicity of of the operation because now you don't you don't rely on any IGB or BGB and MRC on the, let's say, on the source can realize those problem and and solve and solve them. But also the the use of s r v six in order to do kind of deterministic probing in order to detect the good passes and the bad one and being able to alternate between between them. So we added some of this content in the draft. So what is new in this release or revision of the draft is we we added a new section to explain the statically provisioned fabric and how it simplifies the operation of the fabric. Also, added an update on this MRC plus srv6 deployment by the operator that have joined the draft. We have couple of new co authors for the draft from Microsoft and Oracle, and the draft has reflected their deployment already. And the last step, we really welcome the feedback from the working group on the draft and any comments. And I think we based on the, let's say, on the ongoing adoption of this mechanism, we ask the working group for adoption. Thank you.
[01:15:14] Dan Voyer: Any question for Ahmed? Oh, yes. Go ahead.
[01:15:21] Justin: Justin, I think you definitely need to talk about complexity of the thing. Right? Fabric is very simple. The complexity is something thousands of many years of work to make it work. Right? So, I think you need to explicitly state that complexity didn't disappear. The way to configure a service, but the way to control them, to monitor them, it's an extremely complex thing, and it should definitely be explained. So you didn't make it just simple. You just moved the complexity over the board.
[01:15:52] Ahmed Abdelsalam: Yeah. Okay. Thank you.
[01:15:56] Dan Voyer: Any other questions?
[01:16:00] Ahmed Abdelsalam: Okay.
[01:16:01] Dan Voyer: Next. Next day? Yeah. You're you're next.
[01:16:04] Thomas: Next day
[01:16:04] Dhruv Dhody: is also yours.
[01:16:07] Ahmed Abdelsalam: Okay. So this is also an update on second draft, the use of s r v six for DC and N1 front end. I will do the presentation on behalf of this of the authors of the draft. Again, to remind you what is the scope of this draft. The draft discussed first the problem statement and challenges with legacy design in terms of protocol translation and limited traffic engineering end to end And in terms of service insertion and the need to configure, let's say, a full mesh of of tunnel, etcetera, and the dependency also on ibv4 loopback inside the inside the fabric. And the solution that is provided in in this draft is how to use srv6 in between both in the front end DDC and the the one. And we explained in the draft the benefits of such approach in terms of elimination of protocol translation, the enhanced scalability by removing those translation gateway and having a simple way to do service chaining and insertion. And also in terms of optimize the overhead and the use of native ibv6 without any dependency on ibv4 loopback inside the fabric. What is new in this revision of the draft? We added to a report of two use cases from a customer, Nebius, that was presented publicly already, and use case from Dech Telecom, which Nick has already presented already today. And we explain also the DC integration model and how to feed the underlay overlay and services. And also we give some illustration on the unified srv6 architecture. There is also a new author that joined the draft, Nick, and you have seen his also presentation that is alignment of this deployment report. Last thing, we ask your feedback on on the draft, and we would like also to request the working group adoption from from the working group.
[01:18:28] Dan Voyer: Questions? Okay. Thanks. Thank you.
[01:18:50] Wataru Sima: Hi, everyone. I'm Watanmi Sima. I'll present about s r v six service function training deployment. This work has two object objectives. First, we want to demonstrate on s r v six SFG deployment based on another Spring draft and share our experience in a managed site environment. Second, we sorry. Second, we want to summarize the operational considerations. This architecture has three key features. First, comprehension management using SDN best for playing architecture. Second, simple forwarding. We use SRL service functions called called and dot a m. With with these functions, we don't need SFC proxies. Third, standardized protocols, psep, BGPRS, and BGP prospect. We use the Cynet I p v six backbone operated by NII across three data centers, Hokkaido, Kanagawa, and Okinawa, spread from north to South of Japan. Each site has OpenStack based NFV infrastructure. We deployed a remote video production service. It switches between multiple video sources and does transcoding, color correction, and captioning, all in the srv6 network. We deployed this architecture without modifying EV's existing CyNet I p v six backbone network or router. Based on on this deployment, we found several operational considerations. First, service seat uniqueness. Within the same locator, the function value must be unique, but a node may assign its own seat independently. So if the controller assigns the end to end values alone, a collision may occur. We need a coordination mechanism to solve this properly. However, in this deployment, we took a simpler approach. The service function manager checked which value were currently in use and decided the value. Second, component placement. In a multi site deployment, each data center runs its own independent virtualized infrastructure manager. A single VNF manager manages all of the v I m's. So operators still see a single centralized view. Also, the application, the controller, and the managers communicate with each other. To reduce exposure to inter data center network failures, minimize the latency and make monitoring easier, we placed all three components in the same data center in this deployment. Third, failure recovery. First readout maintains connectivity, but does not guarantee the service levels state consistency. Traffic may be redirected to another service function instance, but that does not have the same processing state. So service functions must be designed to hand handle this. For example, through buffering, state of the synchronization, or idempotent processing. Finally, observability. Correlate correlating state across network, data centers, and application layers remain difficult and is still performed manually. A unified merge merge layer observability framework is essential of at scale. Network layer monitoring was not enough. Sorry. Network layer monitoring was not enough. We also needed application layer verification, comparing inputs and outputs at each service function, not just at at the source and destination. A packet mirroring s r v six endpoint behavior could help make this easier, I think. Summary. We demonstrated a deployment of the s r v six s f c. This implementation was
[01:23:38] Thomas: What? Thomas. Yeah. One one comment. This draft based on the SFC draft in spring. That draft have not been published as an. Right?
[01:23:55] Wataru Sima: As we published?
[01:23:57] Dhruv Dhody: Have not been
[01:23:58] Wataru Sima: No. We published to the as a risk architecture draft at Spring.
[01:24:05] Yisun Liu: Okay. Yeah. I mean,
[01:24:06] Thomas: in the s f SFC draft that that's draft that have not been published. Right? Okay. No no problem.
[01:24:19] Richard: Thomas? Yes.
[01:24:20] Thomas Graf: Hi, Thomas. Can you just jump to the observability slide? I think it's the second to last slide.
[01:24:28] Wataru Sima: And I think I'm last. Right?
[01:24:30] Dan Voyer: Yeah.
[01:24:31] Thomas Graf: Exactly. So here, just one I think one further.
[01:24:36] Ahmed Abdelsalam: Sorry.
[01:24:37] Amr: Go. Can you go I
[01:24:38] Wataru Sima: will go for what what sorry.
[01:24:40] Thomas Graf: For the So the ops yes. Enable multilayer observability. I have a clarification question on correlate multi layer state for troubleshooting. Can you detail a little bit on what are the challenges there?
[01:24:55] Wataru Sima: We want to see the it's a bit louder state and our network function state. If the video traffic not sorry. Not modified by network router, the network we want to check the network function state and end to end state of router. So we want to check the this state at on the single viewer or single controller.
[01:25:30] Thomas Graf: I see. And that would be the data plane visibility you're referring to. Is that correct?
[01:25:37] Wataru Sima: Yes. So we want to acquire the data the data plane with our ability. At this time, we we can't activate.
[01:25:47] Thomas Graf: I see. And this is also regarding multiple encapsulations perhaps?
[01:25:52] Yisun Liu: Yes.
[01:25:53] Thomas Graf: Okay. So maybe there's just work in currently in ops AWG about IP fix Mhmm. Where there is some, let's say, gaps in the RFC seventeen eleven specifications on, like, multilayer encapsulations. So maybe that could be interesting to review.
[01:26:10] Wataru Sima: Thank you. I'll check with.
[01:26:12] Ahmed Abdelsalam: Sure. Thanks.
[01:26:16] Dan: Then BGP, can you go back a few slides on the diagram with the three data center? Okay. So I don't know if you explained this through the I I haven't seen it in a draft, but what happens for in flight packet? Let's say if your service function in the can the middle DC goes down. How do how do you react to this?
[01:26:39] Wataru Sima: Yes. At this time, we deploy the we deployed at this this data center. This is the edge of the sign at I p p six backbone. So the packet forwarding through the these data centers.
[01:26:53] Dan: Yes. So it goes from data set, like, addend to Data Center 1, k Kanagawa, then Okinawa. What happens if the the packet goes from the end, but then Kanagawa goes away?
[01:27:04] Wataru Sima: Because sorry. We I I don't write this slide. The video source separated the sorry, split it at Japan, for example, Okinawa or Iskawa or so on.
[01:27:18] Dan: Okay. Well, maybe we can talk offline or through the list. Thank you. Thank you.
[01:27:25] Dan Voyer: Any other questions? Okay. So this will conclude the the ITF one. Oh, is there another presentation?
[01:27:36] Richard: We had one if time permits, and since we have three minutes, so we'll give three minutes to Yeah. Yeah. Two minutes.
[01:27:42] Dan Voyer: We'll try in the speedway.
[01:27:46] Linda Dunbar: Okay. I I'm just give a very quick update. So this was presented at last IETF. And this time, we added a new use case for this particular problem. We have this China Southern Power Grid. They provided real use case for this. So on the left side is their previous network. And so they have two types of network. One is the data patch dispatch network, which is all encrypted traffic. And they have the the network, like, call integrated network data network that is not encrypted and just regular network. And today, they are actually have to do two layers of network and encrypt it. If they wanna go to different zone, they have to go through jumping over integrated network. And in the they're in the process of upgrading their integrated network to s r v six. And during this integration, they would like to use the the control plan, the BGP control plan, to control the IPSec parameter distribution so that they don't need two separate control plan. So they are in the process of allowing this dispatch data network traffic and to be integrated with IDM. And still, the dispatching network need to be encrypted. So that's their current use case. So what they really need, if I just put a takeaway of what they need, is really the s r v six have two type of traffic. And one is the regular data network is not encrypted. Another one is encrypted. What they really need is using the BGP to be able to distribute those in which traffic need to be encrypted, which traffic doesn't need encrypted. So, here's the data plan, desired data plan. They need auto header still to be s r v six so that the s r v six can forward the traffic based on the policy. And the inside s r v six header, they will have this ESP protected. So that's the data plan. For the control plan, what they really need is for the two PEs to be able to talk to each other saying, hey. This this route, this prefix is to be protected. And they need a new tunnel type saying this is ESP protected payload. And Aina has assigned the the code for this particular tunnel type. So that with that tunnel type, they can tell the other end this traffics is ESP protected. Here are the associate IPsec parameters, which has been defined by the IDRs tunnel encapsulation. So here is the actual control plan. Okay. So, my time is over.
[01:31:00] Richard: Time is over. Can you just go to the last slide?
[01:31:01] Linda Dunbar: Okay. My last slide is really we would like to call for working group adoption. And also, we need people give comments if there's issues with this new tonotype for the ESP protected traffic also the SRV6. Thank you.
[01:31:21] Dan Voyer: Thank you. Okay. So now this close the session from 01:20 ITF 01:26. Hope to see you guys at in San Francisco. Or we don't have time. We have to close. So thank you, and see you in San Francisco.