Session Date/Time: 23 Jul 2026 14:30
[00:00:26] Yingzhen Li: Can someone at the back close the door, please? Okay. Let's get started.
[00:00:42] Jeff Tantsura: Welcome to Vienna, to IETF 120 Routing Working Group. Please make yourself familiar if it's not well. You're expected to be familiar with it. In person participation, please sign the session. Please, if you want to comment, join online. If you are attending remotely, please follow the same procedure. Please make yourself familiar with the tool. And probably you would like to use a headset to make yourself better. Yingzhen, we collaborate on minutes, so please do help us to have good minutes. And we'll discuss and join the queue. Agenda for today, we are pretty busy. Please be on time. Don't abuse other times. Thank you so much. I love you. So milestone, we've finalized the incubation of fund. There's a formal working group we met today for in San Francisco. Are going to have full meeting to bootstrap work. Myself published data model for fun
[00:02:04] Presenter: for work. Yeah.
[00:02:08] Jeff Tantsura: So new way of working. We publish data models and develop protocols according to it. We've published no RFCs since last ATF, and now drafts adopted. And we've submitted two drafts for publication, the update to the RFP draft, thanks Gunter, AC, Yingzhen for work here- as well as multi segment SD WAN. Status of our documents on BGP PIC, we have received trivial and expect to have a new version. BFD stuff that kind of got split, if again, going to be discussed, and we are trying to get ready for Workgroup plus call. What else? The QoS model, we expect the authors to address commence. We have split the encoding for clean state protocols into separate draft, And now it's going to progress in working group LSR, in work that kind of stayed in routing work group. I believe we are getting close to working group plus call. It's an agenda today, so please please decide. The dst-src routing document revived. It's not being presented today for a long reason, but hopefully next time. And our GitHub, please let us know if you want to use GitHub. That's kind of the way of working we would like to see here. And that's all for Yingzhen.
[00:03:55] Yingzhen Li: So any questions to the working group or to the agenda?
[00:04:02] Gyan Mishra: So you can go back to the agenda.
[00:04:06] Yingzhen Li: Not, we'll go to the first presentation.
[00:04:24] Presenter: Yeah. Go ahead.
[00:04:29] Presenter: Hello. This is from Registry. I'm going to talking about SRv6 Egress protection. Here's the overview of our solution. It it provide faster failure for multi-homed egress scenarios. It has stateless in the middle and without control play extension. There are three important things for the failover mechanism. First, we extend the s h flag, b flag to indicate whether backup set and
[00:05:25] Presenter: the
[00:05:25] Presenter: primary source set in capital in as such. The second thing, we define a new PSD flavor. With this PST flavor, we can decouple the the packet if the SR to the SR flag is is zero one. We will describe the details in the next slide. The third thing, we we set the b flag in the SRG flag When in the end part, it will when the failure happened, it will switch the destination to the s r g. And first, we can see the as actually in cap, we extend the one one bit b flag. If the b flag is set to one, it means the backup set is in capital in the position of s r s r zero, and the prime set is in capital at the s r one position. The the right picture is the in capital when the b set the b flag set. This is the p PST flavor extension. The p s PST flavor applied to the VPN service VPN service such as the and the d t four and the d t six. And the the process is is modified when the SL left is zero or the SL net SL left is one, and it will describe the the packet and forward to the next next header. This is the protection mechanism. In egress node, it will calculate the prime pass and backup pass. Then it will in cap the prime so we see it and the backup so we see it in the SSH and the set p flag to one. Then for the prime egress node, it will assign a PSD flavor for the service CIDR. Then when the packet arrived at the Egress node, if it matched the the PST flavor, it will decouple the packet and forward the by the export packet. Then on the and the port, when the failure happens in the egress node, the protein and the part node will will look the s r two flag. If the p flag is set, then it will switch the packet to the s l zero, and then the packet will forward to the backup egress node.
[00:09:15] Yingzhen Li: We have someone in the queue. Do you want to ask the question now, or you want to wait until the after the presentation? Yeah. Go. Yeah. Sure.
[00:09:32] Weiqiang Cheng: Nizandolev, Ribbon. Can you can you just highlight the benefits comparing to the today's protection toolbox? I mean, what are the benefits, actually?
[00:09:47] Presenter: We expand the backup set in the s r two. So if the the failure happened in the the primary egress failure, it will it will forward in the packet to back up Egress node. It will faster switch in the and the port node. Not in the ingress node. We can first switch in the middle node. Maybe it will faster about one hundred millisecond. This is the example of Egress protection for the p one. When the p one calculate the c two's notice, it calculate the p three as the primary pass and the p four as the backup pass. Then in the p two, it will encap a p three VPN service and p four VPN service. Both are in the SIH. And then we'll settle the SIH flag, b flag to one. And then the packet will send by p one, p two, and then the packet will forward to p three. And then the p three search the the local SID. The local SID and the d t four is PST flavor. So it will ignore the the backup set, then describe the list packet and forward it to c two. When in case of the failure of p three, then the p two the the of p two found the b flag is set in s arch. So it will change the destination to S R G 0. Then the destination will change it to p four. Then the packet will forward to p p four. It will not wait till p p one to switch to p four. At least the history of our draft in version version five, we received a comment modification to behavior at the and the part node not followed after eighteen seven fifteen four. So in the latest version, we changed the the standard state to experimental, and now we add the s r two flag p flag to indicate the prime set and the backup set. Then during the process at the prompt and the port mode, we're handing a b flag and without waiting, I'd say, eighteen seven fifty four. We also add a cons consideration for SRV six complete completion. So our our solution is forwarding play faster, just simple and efficient. And we we we we we allowed any control play extension. And based on the source loader idea, we in cap prime and the backup sitter at the source node. So by the b flag setting to avoid in club incorrect destination change. Let's all we we are seeking for adoption call.
[00:14:40] Sasha Vainshtein: Any question? Sasha Weinstein. Do I understand correctly that the proposed scheme first of all, it may be not so important since this is currently go is going to experimental, but just for my understanding. If I understand correctly, it is up to the ingress p to insert two SAGs in the in the segment list. One for primary and one for for for backup. Right? And so, it and this will only work if only makes sense if the ingress p knows that the penultimate routers, whatever they are on the way to the egress p's and just recognize these flags. How so I think because if your p two if suppose that you start from p one, p one does everything accordance with what you have said and search to to SAGs. Sends it all, it reaches to p two, but p two is not capable of doing what you have requested because it it doesn't know that has to to drop the primary and start using secondary.
[00:16:20] Presenter: The failures which always in and the part node. Maybe the p two is not directly connected to the p three. Then it will detect the failure by multi hop b
[00:16:41] Sasha Vainshtein: f p. No. I'm not saying speaking about how p two p two detects the failure, which is a question in its own right. I'm question speaking. How can p one be sure that p two, which is oh, actually, all the routes on the path, where can implement the pros proposed procedure. What what this method is, I think, the message we have described suggest assumes that all the routers in the service six domain do exactly what you have said.
[00:17:20] Presenter: You mean p one does not have the router to p three?
[00:17:24] Sasha Vainshtein: No. What I'm saying that what is p p two is an outdated router which doesn't support this operation?
[00:17:31] Yingzhen Li: It sounds my understanding. In that case, it doesn't work. So if you look at the box number three, it's an ultimate endpoint. It cannot be a trans like, a regular transit point that understand I p v six only. So the deployment, that that's what he meant. The p two can be several hops away from the egress route.
[00:17:58] Sasha Vainshtein: That that that is fine. Okay. I'll send my question to the Yeah.
[00:18:03] Gyan Mishra: Thank you. Yeah.
[00:18:09] AC Lindem: I would have been up sooner, but I queued my question to the wrong working group that I joined. Anyway, AC Lindum Arcus.
[00:18:16] Yingzhen Li: Very helpful.
[00:18:18] AC Lindem: I I'm wondering, you know, the I I'm I I'm this solves the problem in a quite different manner, but this looks like a lot of the same you're handling the same failure scenario that the draft that's been around for seven years using MiR SIB solves. And you are even if it is I don't know. I'm not gonna comment on the elegance. You've invented new network programming and everything where we have this one this other draft for seven years. Can you compare it? And, I mean, you you can do it on the list. We're you're running out of time, but you see what I'm saying? Or say what's different about even if it's not, tell me it's not the same Yeah. It's type of failure.
[00:19:04] Presenter: It's not the same. The important difference, we we not we without the the control play extension, and we don't have less data in the in the middle routers. We just switch by the forwarding play. For the middle seed, it will use middle seed to encab and then forward it to another egress node. That's like important difference.
[00:19:36] Jim Guichard: But it's
[00:19:36] David Lamparter: it's the same use case.
[00:19:38] Presenter: Yeah. Yeah. Thank you.
[00:19:45] Gyan Mishra: Yeah. My question is this is proposing some new flags in the SRH header and all that. So why isn't it in the scope of six man or spring, but it is being discussed here in RTGW?
[00:19:57] Yingzhen Li: That's so cool. If you are changing SRH, you need to go to six man.
[00:20:04] Sasha Vainshtein: Yes.
[00:20:11] Weiqiang Cheng: This is. I'm also the cause of this draft. I think it yeah. Yeah. This draft now is experimental draft. And
[00:20:21] Yingzhen Li: But you are changing SRH.
[00:20:24] Weiqiang Cheng: Yeah. Yeah. Maybe we need to prioritize those things to six months also. Yeah.
[00:20:31] Jeff Tantsura: Practically, you need to figure out what you're going to change potentially in the future as well, Settle and present in all related working group that work on particular technologies. Here, you cannot change LSR related or six man related stuff. You can present it here, but then it needs to go through process in the relevant working group.
[00:20:58] Jim Guichard: I think you might have just said what I what I was gonna say. So but I'll say it anyway, Jim Gishar. So this b flag thing is going in the flags, which are unassigned, means that would need to happen in six man. Just to point that out.
[00:21:16] Presenter: Yes. Thank you.
[00:21:25] Jeff Tantsura: So for the next three to five action point on you is to engage with six men, explain what you're trying to achieve, and potentially present in San Francisco.
[00:21:36] Presenter: Yeah. Okay. Thank you.
[00:21:39] Yingzhen Li: So this draft and the one that's gonna be presenting next, they are trying to solve the same problem. My personal my individual comment as an individual no. My personal comments is both of them have their limitations. Maybe you should also mention that in your draft. Yeah. So yeah. As a comparison, so we ask the author of this draft to also to a presentation so people can understand
[00:22:17] Presenter: Yeah.
[00:22:17] Yingzhen Li: Them better and make a comparison.
[00:22:20] Huaimo Chen: So Okay. I don't know. Kinda getting me. Okay. Good afternoon. Good afternoon, Okay. Everyone. I will talk about our solution. Also, just like the last presentation, our this presentation is about multi home. And at the end of this presentation, I will talk about some differences between the mister Ling's chapter and ours. Okay. Okay. This is an update of our s r v six pass egress protection working in working group. The document has been on a long road, and the lead talk is about where that load has taken us and where it goes test. So I want to give a overlay overview of the draft and describe the mechanisms briefly, then show you that all the directory reviews and our broker to its solution. Okay. On the side two, the top ridge Topology-Independent Loop-Free Alternate in RFC 9355 protects the transit nodes and the links inside the, but it it doesn't not cover the egress node or the egress link of s r v six pass. In the real deployment, need a faster protection for the Egress node two. Our solution is using the mirror seat that is end dot and end point behavior type 74, implement to this protection mechanism. In PEB's forwarding table, we prepare the PA we prepare the PA's favor context identified by. In in the figure, when the primary egress PA or its link to the c two fails, the point of local repair, we call it the PLR for short. That that is the upstream node, p one here. It direct it directs the packets. It and send it into a backup egress PEB. PEB then force the backpackage in PEA's favor contest. That gives you protection for both the egress node and the egress link. For the PIR, namely p one here, which precomputes a backup pass, the protector PEB must first signal the protection relationship. Concretely, PEB must advertise the tube PEB, PA, mirror seed, plus the protected locators through the IGP. The IGP encoding method will separate it to another draft in LSR working group from version 24. And the protecting mechanism using the mirror state itself is unchanged since the first version in March 2019. What changed is how we describe it, define it, and then define it. Okay. In the slide three, I can describe the journey. The journey of lead draft spans more than six years. Let me walk through the milestones. It began in March 2019 and the published the very first version as a individual draft and the presented data at IETf-one zero four in Prague. The core idea, a mirror seed to protect the egress of SRv6 path was a layer from day one and the the mechanism itself has not changed the things. And then a year later in March 2020, Aditi formally adopt the document as a working group draft. And data adopt change the word to turn individual idea into a chart to work item of leads group. Then the document made through external review. In July 2023, our documenter, Shepherd, requested early reviews from all four directories. So we came back that summer. An IMT directory on revision 10, return ready. RTG directed on revision 11 list of protocol and security considerations issues. And the OPS directory also raised the issues. We closed all plan across revisions from 13 to 15. And by the April 2024, at revision 23, we invited the LSR working group to build the IGP encoding parts. That across WG engagement is what led to the a ITP encoding major and ultimately spin out as a companion ASR draft so that RTG working group owns the mechanism, and the LSR working group owns the encoding format. Okay. So and and then these months, July 2024, the two most recent reveals landed together on revision 24. In IMT directory on the right track with the five discussed items on motivation and address, and RTG directory had issues with 17 minor and the in its on and the procedure. Revision 25 closes every single one of them and separate IDP encoding out of out to data as a companion draft. Okay. In this table, I have presented a overview of the review and revision process. Okay, Len. On this page over the, I will explain important change to avoid a crossing work group reveals and to make the functional division of the document more clear. We separated IGP coding part in the version 24. The spreader document was submitted to the LSR working group and presented at the IETF 120 meeting. Then let me describe the struct structural change. Version 23 carried a full IGP encoding chapter inside the leads RTG working group draft. The is is is a sub sub tier list and the OSPF v three sub tier list. In version 25, the material is now a separated draft in the LSR working group. Namely name the draft h e s r s r v six meter seat, IGP encoding, and the the RTG working group draft. Reference it, no matter. RTG working group owns the mechanism. The Tringle is the pan an automated node, not the PRR. It is a pure data plan change with no IDP or BGP retentions. It protects the egress node, but not the link. And it requires the new PST behavior code points. And the two draft I think the two drafts are all for the scenario of multi home c, and they are complementary, not competing. Mirror see the forwards in the prey primary egress mirror, the context, and protects both node and the link. PSD forwards in the protect's own context with zero control plan change. You can pick the one that fits your deployment. Okay. Finally, our next work is supplied for the adoption of the companion draft. Okay. And I we will get it ready for the WGLC. Okay. Thank you. Any suggestion?
[00:31:38] Yingzhen Li: Sasha, are you in queue for question? Or is it from the last one?
[00:31:44] Jeff Tantsura: Sasha?
[00:31:47] Yingzhen Li: Are you in queue for question? Okay.
[00:31:51] Presenter: Okay.
[00:31:53] Jeff Tantsura: Thank you. And, yeah, please keep working on it, and, we'll get it ready for working last call as we progress.
[00:32:01] Huaimo Chen: Okay. Okay. Thank you.
[00:32:19] Aditya: Hello?
[00:32:23] Yingzhen Li: Yes. Please start your presentation, and you have control of the slides.
[00:32:28] Aditya: Yep. Thank you. Hi. I am I am I am Cisco. So this presentation will be regarding our draft that proposes Unica support for Vrrp. I'll start with why why this draft was submitted. So customers want VRRP in their deployments. Many of these new deployments where VRRP is required in recent years do not support multicast. Some examples are like cloud deployments, l two constrained deployments, virtual virtualized networks, and the the overlay connections, etcetera. So because multicast is not supported, these networks require unicast support for VRRP. Because of such customer requirements and because there was no VRRP standard for unicast, the implementations out there or the implementations done varied a lot. From our interactions in the IT of space actually, there is a new draft in VRRP space put out by a service provider and an open source implementation. That draft assumes Unicast standard is there. So from our interaction in in IT space, we know that customers want want a standard for VRRP Unicast. So this draft aims at that by preserving the VRRP model. This proposal that we put for the this keeps the packet format protocol or the next head header number, the state machines state machine, virtual IP, hand virtual max semantics, all those things same. We also aim at keeping the configs and the operations very simple and intuitive. Yeah. In in this slide, the slide points to the evaluation that we did prior to the work on the draft. We see a lot of interrupt issues, which the cons customers are concerned about. So with respect to mode or transport, in some some implementations where unicast is configured, multicast is multicast packets are also accepted, and some don't accept that. Some implementations used UDP to to transport the VRRP advertisements in in unicast mode. So thereby, the the protocol or the next head number does not does not honor the 112, the number that was assigned for VRRP. With respect to peers, we have seen single peer and multi peer support. And if they are in drop if there is an in drop together, this can cause packet rejection when source checker is actually enabled. Some some implemented Unicast for both version two and version three. The the checksum interpretation actually is done differently by different vendors, actually. By the way, this ambiguity has been corrected in the latest VRRP standard that has been put put out. The TTL and the hop limit checks also vary across implementation. Some one of the two fifty five, one hop. Some go for configurable multi hop implementation. Some implementations preserve this v I virtual IP, virtual MAC for stop redundancy. Whereas some just use VRRP state machine for route ownership or or the route reprogramming in cloud. Some use it for role selection. Some only expose VRRP Unicast in cloud deployed software. So these are some of the interrupt issues that we we identified. Now coming to this draft, in our proposal, the key aspect is the unique cast mode where so we are proposing a unique cast mode where multicast remains the default. This aspect leads us to the second point. When when unicast mode is there, we need a a peer list or a configurable peer list. So that that is the second aspect that we have in this draft. We also have the yang model augmentation for this in our minds, but we are waiting for the idea of work in in VRRP yang model work that work to finish. So we have mentioned this in the draft. So in the upcoming new new versions, we once that draft is done, we'll add it in in our draft. Now with respect to the advertisements that needs to be sent, the packet remains the same except for the destination address. So we actually send a copy to each peer. And for for I p v six, the the checksum also will will will change. Now on the receiving end, the receivers will only accept the packets from the configured peer list. The TTL and the hop limit, we have not touched it. It's still two fifty five, and that needs to be enforced. Regarding the host facing behavior, we have not changed anything in this draft. Only the advertisement delivery has changed. So so to to conclude the the this draft is only easing the current standard, which is tied to the multicast. This and and to allow the a a unicast mode, and it explains how unicast mode should work in a very simple way. So That that's it. Thanks for this slot, and feedbacks are welcome. Hi, AC.
[00:38:27] AC Lindem: Hey, Salinda. My Rakesh, hi, Aditya. So is this a point to multipoint network then?
[00:38:34] Weiqiang Cheng: So the the Because it doesn't support
[00:38:36] AC Lindem: it doesn't support even not not only does it not support layer two multicast, doesn't support layer two broadcast either. Or if it does, you don't you don't wanna use it because of the overhead.
[00:38:52] Aditya: Yeah. So we the customers that we have seen have not explained clearly whether in where it is. One thing we know is in cloud deployments, it's not there. So they they have deployed it in cloud. We have also seen where multicast is supported. They are still going for unicast. We have seen that also. Regarding point to multipoint, we'll I'll I'll check that part if anything is there and then come back to you.
[00:39:21] AC Lindem: Okay. Yeah. I mean I mean, I'm not talking about the point to multipoint LSP or anything. I I'm just talking about the, you know, the physical connectivity because it's not a shared it's not a shared media land. It's not an eight zero two dot x of any type if it doesn't support broadcast, vault slash multicast. Right?
[00:39:47] Sasha Vainshtein: Yeah. Yeah.
[00:39:48] Aditya: I I I agree. But one one thing is that I we have seen a customer which supports this on the LAN itself. They are using Unicast. They do not when we asked, we have not got an answer why they do that, but we have seen them doing it.
[00:40:06] Weiqiang Cheng: They might be doing some kind of
[00:40:08] AC Lindem: encryption or something and not telling you about that. Yeah.
[00:40:11] Aditya: Okay.
[00:40:11] Jeff Tantsura: Okay.
[00:40:13] Aditya: Thank you, AC.
[00:40:18] Yingzhen Li: Any other questions? Okay. Thank you.
[00:40:23] Yuying Chi: Yeah. Thank you.
[00:40:43] Jeff Tantsura: Who
[00:40:45] Yingzhen Li: is presenting this one?
[00:40:49] Xiao Min: Hey.
[00:40:50] Yingzhen Li: Xiamin. Xiamin.
[00:40:53] Xiao Min: Hello, everyone. I'm Xiaomi from telecom. This chapter title is, do have to pause when when the child's then three in YL network. Sorry. Okay. I can't control the slide.
[00:41:27] Jeff Tantsura: Do you want us to move slides?
[00:41:32] Xiao Min: Maybe in the network.
[00:41:36] Jeff Tantsura: You should be more precise. Okay. Let's just control the slide. Okay. Okay. Us know. Okay.
[00:41:43] Xiao Min: But the versions this right grows in demand of for con computing and storage resource in AI, demand models, and distribute storages. Intelligent compute centers are interconnects through wise to provide much pieces collaboration to compensate for the interest of for is a big sufficient control and storage in research space. Yes. Think it is a improve it. Resources efficient. The already tested flow control is wide widely deployed in r c e v two. It works to about pipe pet loss caused by congestion. Probably the development of TFC in once we have faced challenges. For examples, the deep wind distance between two loads is to a in constant system of permits safety upload. Inhalement for flows with disease, such as head of line, bug, dead deadlockers, and even congesting and fuges when will be implied in one. This document, please provide a solution that is they will say cost plan transparently for waiting the UI and not require the the loads invoice to support TFC flow contract capabilities and end to end flow contract between AI disease in connected. Slow wise can be realized with minimal impact on network performance. Next slide, please. This is the PFC post frame format. PFC post frame is a is late is late a marked cast frame. The destination MAC address must be the mark pass address, and the source MAC address must be basic MAC address of TFC frame sending port. It is only sent directly collected upstream node you know, to oppose their traffic. Next slide, please. Type case went to IDCs are in collected slow bands. The tunnels, for example, SRMTS, SRM basics, base headline, is like published between the ingress t and the ingress t to have it. Myself RDMA tried between these days. An example, you type two AIPCs are being collected through s r v six color in advance. Here, use the encapsulated t f c frame for format. The top layer is activate six header, and the middle layer is s r h, and the voucher layer is already f f c frame. Next slide, please. T f c post frame processes. When congesting occurs in the destination IPCs, the t f
[00:45:03] Jeff Tantsura: c
[00:45:03] Xiao Min: frames are stepwise then to the destination gateway. Similarly, net this ticket may stepwise as it's relay literally collected the upstream Egress key load to pause their their traffic by sending a t f f c frame when congested at the the same port. The Egress key leads to pass at TFC frame and the that is a legal TFC frame. The Egress key load encapsulates the TFC frame based on tunnel encapsulation protocols, then wets it to the in immediately trace it load, which in turn where the trace spend spendly to the upstream load until it reached the increased load. The increased load the capture list to TFC frame and then replace the the source MAC address in the outage of TFC frame with the MAC address of is port directly connected to the source and the state gateway. Drive west through the source is a gateway. Next, please. Next, please.
[00:46:28] Yingzhen Li: Now it's showing slide number six.
[00:46:32] Xiao Min: Oh, yes. Okay. Two above settings. Due to the much longer transmission is at this tensor wise comparing the internal assays. The t f c frames waiting from the ingress t to the ingress t required a significant interest initially. To avoid the pax loss caused by overflowing the receptor. The destination the secret will at least to reserve more buffer for the Congress County and priority care of the necessary port. Reserved pathways stating of the for the priority care of the necessary port at the destination is the gateway is required to meet following condition. That is both sizes, grade line, and the average is the same right right. My last to I'm ready to save the matter. Not right by the forwarding delay of the PFC frame from the this latest is a gateway to the source is a gateway. Left. Yes. Left slide, please. Oh, okay. Next steps, welcome adding comments or suggestion. So we have to find it according to the the feedbacks. Thank you.
[00:47:55] David Lamparter: David? David Lampunter. If you can go back to the previous slide, with any kind of realistic WAN latency, these buffers are going to be giant if the bandwidth isn't trivial. Have you tried this actually? Have you, like, seen what kind of impact it has on the actual flows going on top of this on on their flow control that they may have? What what kind of latency have you tested on this, or what kind of latency are you looking at here?
[00:48:24] Weiqiang Cheng: You.
[00:48:29] Yingzhen Li: Oh, okay. Thank you. Thank you.
[00:48:39] Xiao Min: What did they delay from the from the destination to say as they get away to the source. They are exist mainly many measurement method including active method and passive active such as so I I I I And that is this arm.
[00:49:10] Jeff Tantsura: I'm not sure it's clear. Let me rephrase this question. You need to configure headroom to accommodate all pedestrian flight after you start pausing. At 400 gig, you'll require about 50 k per each microsecond delay. So going into thousand kilometers, you're in gigabytes of buffer. Moreover, you need to know exactly what buffer to configure. Right? That's what you do in data centers. It's important not to overblow buffer as well as not under configure it. So would you be able to measure the distance exactly or timing exactly? The question is really practical. Right?
[00:50:02] Xiao Min: Second question is it's part of a good part. You you are to the
[00:50:20] Yingzhen Li: the
[00:50:44] Xiao Min: Actually, it's the is larger. It's it's a lot bigger, and I we imagine imagine.
[00:50:58] Jeff Tantsura: I think we should take it to the list.
[00:51:01] Yingzhen Li: Yeah. Please. Sasha.
[00:51:04] Sasha Vainshtein: Yeah. Sasha Bernstein. I wonder if this proposal, which includes manipulation of MAC addresses of post frames, would work with some security mechanisms like, for
[00:51:21] Andrew Stone: instance.
[00:51:29] Joel Halpern: Joel Halpern, HPE. This strikes me as backing us slowly but carefully into a really awkward situation. I note for example that somebody in their in this processing sequence has to adjust the pause frame duration presumably, but I'm guessing by twice the actual latency of the wide area network, which as Jeff suggested earlier, is an interesting difficult to know and critical parameter. Having to adjust the message contents makes it even harder.
[00:52:10] Xiao Min: Thank you questions. For the further question, we we can discuss it in the meeting at least. Thank you.
[00:52:25] Jeff Tantsura: Last comment, if you are going to respond to Sasha, in most cases, if it's implemented outside of MUXET envelope, so if you're in one situation and most people do use MUXET, the answer should be how it's going to interwork.
[00:52:44] Andrew Stone: If
[00:52:49] Yingzhen Li: you didn't understand any of the comments you received, you can send questions to the list. Okay. Thank you for your presentation. We'll go to the next one.
[00:53:12] Ka Zhang: Okay. Hello, everyone. This is Ka from Huawei. And today, my talk my topic is elastic bandwidth aware routing framework. And we all know that IGP normally computes the shortest shortest path in a network for package forwarding without taking account the traffic information and the invoice information in the network. And in the real network, unexpected congestions may occur if only the shortest path is used for IP forwarding. And there are two typical cases. The first case is that the link will degradation all the fit all the partial of the link on the shortest path failure. And the second case is that the the traffic flow may incur increase dramatically in on the shortest path. In these two cases, the IGP protocol will not converge, but the congestion may occur, and it will keep it will continuously persist for a long time. To solve this problem, we propose a solution, the EBR solution, which is to alleviate the link congestion caused by the unexpected events timely. And the main idea of EBR is that we will integrate the IGP with SR strict pass and distributing the traffic among the primary pass and the multiple load balancing alternate pass based on the based on the perception of the link congestion and the bandwidth information of the whole network. And the process of EBI can be divided into four steps. Step one, we'll collect and advertise the link bandwidth information. EBI enabled the nodes needed to collect the physical bandwidth and the utilize the bandwidth of the outbound links. And the the bandwidth information is the k input for the for the conjunction determination and the load balancing. And the the advertisement of bandwidth information can be achieved through IGP advertisement by using the existing IGPT metric extension for the physical bandwidth and utilize the bandwidth. And then the step two is the load balancing alternate path calculation. The load balancing alternate passes are calculated on the device and used for load balancing when the primary path is congested. It is calculated by IGP itself. And the IGP will use the LSDB information together with the bandwidth collected to calculate each path to to calculate the alternate path for each the the source destination the source to each destination in the SPF piece. And the the load balancing alternate path should be calculated in advance to allow quick treating of load balancing when local link congestion is detected. And, also, the multiple multiple alternate paths and the primary paths should be disjoint as much as possible. And the the load balancing alternate passes are encoded in SR strict SR pass, which is to avoid the loops. And the number of alternate passes can be configured by the depend on the network topology. And then step three, the traffic distribution upon congestion. The traffic distribution distribution is triggered when a local link congestion is detected. The determination of the link congestion depends on a configurable congesting stress threshold. For example, if the utilized bandwidth of the primary pass have have up to 8%, then it will trigger the link or congestion the traffic distribution. And the UCNP is used to distribute the flows among the the passes, and the weight of each pass is determined according to the bandwidth information of the pass. Once the weight of each pass is determined determined, it will not change and unless new congestions are detected on the links of the primary or the load balancing alternate passes. And then step four is the traffic reverting. When the primary pass is restored from the from congesting state, the traffic on the load balancing alternative pass will revert to primary pass. This process restores the network to the original state. And there are two conditions to revert the traffic to the primary path. Condition one is that once all traffic is switched back to the primary pass, then the bandwidth utilization of the bandwidth of the primary pass dot cannot exceed the the post threshold. And the the second condition is that the condition one should be met and sustained for certain period of time, which is called the restore period. And the post the post to restore threshold and the restores restore period can be configurable. And then there are some operational condition considerations for the bandwidth information advertisement to avoid increasing the load of IGP. First, the interval of two advertisement must not less less than the minimum advertisement interval, which is configurable. And then if the minimum advertisement interval expires and the the change of utilized bandwidth is over a certain percentage since the last advertisement, then ad advertisement should be sent. The recommended value is 20%. And then if the minimum advertising interval expires and the consumption of the physical link bandwidth is over a certain percentage, which was not noted in the previous advertisement, then an advertisement and an advertisement should be sent. The recommend value is 7% 70%. And in order to prevent the cluster of IGP message messages on the receiving nodes, a jitter can be introduced. And so there are two d two huge advantages of our solution. The first is that we can avoid the secondary congestion because the available bandwidth of load balancing alternate passes are considered during traffic distribution, and the weights are depending on the available bandwidth of the end to end pass. And the second, we our solution can comp compatible with legacy devices. The routers that download to support EBR can also be used in the load balancing alternative passes as long as they can advertise the bandwidth information. And now the EBI solution has already been been implemented and the trailed in the field. And we welcome comments and the calibrations, and we will refine the document accordingly.
[01:02:47] Yingzhen Li: Okay. Start from Andrew.
[01:02:52] Andrew Stone: Hi. Andrew Stone, Nokia. In the abstract, it makes a statement that centralized traffic engineering can't do this in a timely manner. I was wondering what is a timely manner with this solution.
[01:03:06] Ka Zhang: Yes. Maybe the centralized optimum optimization is always in minutes, and our solution can optimize the traffic in seconds.
[01:03:22] Andrew Stone: If that was the case, I'd be quite concerned with the flooding of bandwidth in seconds.
[01:03:27] Ka Zhang: Yes. Maybe the the period of flooding can be configured. And, also, between the two advertisement of the bandwidth, there will be a change. Maybe we we have we recommend there there will be a 20% to change from last advertisement to us.
[01:03:53] Andrew Stone: Okay. Thanks. I see the lineup, so I'll park it there.
[01:03:56] Jeff Tantsura: Thank you.
[01:03:57] Ka Zhang: Okay. Okay.
[01:03:58] Sasha Vainshtein: Sacha Weinstein, if I understood correctly what you have been presenting, and please take it with a grain of salt, the decision to start offloading traffic from the congested link to alternative paths is taken individually by the router Yeah. To which this link is local. Yeah. In this situation, how can you guarantee that this decision will not result in overload of the links on on alternative paths, which are used by shortest path traffic between that normally doesn't doesn't involve your node.
[01:04:46] Ka Zhang: Yes. When we are offloading the traffic, we will take into account all the whole path the whole path bandwidth utilization of the alternative path and make sure that the traffic will not will not make the new congesting in the alternative.
[01:05:12] Sasha Vainshtein: Do do you mean do you mean that somebody is is would be almost supposed to measure actual bandwidth utilization and to distribute this information in a timely manner?
[01:05:26] Ka Zhang: You mean the there are two different nodes which are doing the.
[01:05:30] Sasha Vainshtein: There are there are hundreds of nodes in your network.
[01:05:32] Presenter: Yeah.
[01:05:33] Sasha Vainshtein: Yeah. What you are supposed to do? What's my understanding? Maybe I'm Yes. Everybody must
[01:05:39] Ka Zhang: Yeah. I understand.
[01:05:41] Sasha Vainshtein: Everybody knows it's the physical bandwidth of its earnings. Yeah. What you are saying, in order for this proposal to work, everybody must measure actual utilization with some reasonable fragment frequency and advertise it say in IGP also probably quite quite quite quite fast because otherwise, because utilization is supposed to change. I think that this should be this I have strong suspicions that this will not be scalable for that and it should be presented to the LSR group because what you are proposing is a substantial change in which traffic engineering parameters today are advertised in IGP. Nobody does it every few seconds, as far as I know.
[01:06:46] Weiqiang Cheng: Sorry. This is Wei Chang Cheng. I'm also a co author of the draft. I I would like to give a a shorter response. So, you know, here, the congestion, I think it's a long live congestion. So for the microburst, I don't think that is what we want to cover. So that that for the long live congestion and that this function works very well. In fact, the channel mobile have deployed those things in our network. It was fine.
[01:07:19] Presenter: Thank you.
[01:07:22] Tony Lee: Hi. Tony Lee, HPE. Could you please compare and contrast this to tactical traffic engineering?
[01:07:30] Ka Zhang: Yes. The traffic engineering is always used for the, maybe the specific pass. For example, from a certain source to a certain destination. And this solution is used for the IP routing. Yeah. And for the best maybe for I'm best
[01:07:55] Tony Lee: talking about generic traffic engineering. Okay? There was a specific proposal called tactical traffic engineering that's been presented here multiple times, and you seem to have Xerox copied it.
[01:08:08] Ka Zhang: Maybe we are
[01:08:11] Co-author: I'm the of this draft. I think I can answer this question. Yeah. I think the EBR and the TTE are two different solutions for courses on their same problem, but I think they are different solutions. This the EBR the key difference between EBR and TT is that EBR utilizes the bandwidth information of the whole network. This is what TT does in their solution.
[01:08:45] Tony Lee: Yeah. Thank you.
[01:08:54] Yingzhen Li: And any other questions? You are saying the solution has been implemented and tested. So maybe in the future, can share with us some real data so that may help people to understand.
[01:09:12] Ka Zhang: Okay. Okay. Next time, we'll update the information. Okay. Thank you.
[01:09:19] Yingzhen Li: Thank you. Okay.
[01:09:37] Presenter: So it's been late, so I'm sitting in the dark balcony to present it this work. So I'm fine from.
[01:09:50] Yuying Chi: Okay. Hi, Cherry. Can
[01:09:51] Presenter: you hear me? It
[01:09:54] Yuying Chi: seems like I can't turn the page.
[01:09:57] Presenter: Oh, sorry.
[01:10:02] Yingzhen Li: Who is presenting?
[01:10:06] Yuying Chi: It's me. I'm calling from China Mobile, but there are something I can't turn the pages. So maybe you can help me turn it. Hi, everyone. I'm I'm currently from China Mobile. Today, I'm presenting our newly submitted draft, GIC architecture for AIDC. This draft is the initial version, and we are here to introduce the core concepts, gather early feedback, and we are very much looking forward to your comments and questions. At present, the network has became the performance bottleneck in AI clusters. AI clusters are scaling fast from 10 thousands to over a million GPUs. Cluster performance comes down to four factors, including GPU power, chip count, network efficiency, and effective run time, where network efficiency is often the weak point. So the fabric architecture directly determines the scalability of the cluster. This is why we need to rethink networking for AI, and this is exactly the problem GIC is designed to solve. AI data center networks are currently facing three quick performance challenges, which are also the main reasons why traditional Ethernet is difficult to adapt to large model training scenarios. First, AI workload produce a small number of massive, synchronized elephant flows. Such large AI flows cause load imbalance and harsh collisions. This is why we need to move from flow based distribution to packet based ring. Second, in cast occurs because all centers start transmitting simultaneously at the beginning of a collective communication cycle. So without a credit based admin admission system, the egress port of the QR switch can be easily overwhelmed. Third, new AI architectures like MOE are breaking the assumption of stable communication patterns, which increases traffic randomness. So GIC aims to tackle all these three challenges. It use packet screening to elements load imbalance and credit credit based authorization to prevent the traffic incast, and it used dynamic path selection to handles randomness. So in this draft, we introduced GIC architecture for AI data center, which is designed to minimize congestion and improve packet interactions through credit based control, packet screen, and the reordering. At present, we have work at present, we have working prototypes, and early data shows that GIC achieves significant performance gains compared to Rookie. This draft presents one of the implementations currently adopted by AIDC, and we hope to receive your questions about the GIC architecture and your feedback on relevant technical designs and schemes. As depicted in this picture, we divide the network into three functional layers. The control layer with synchronized or distributed controllers, the network layer with standard close topology, and the computation layer with GPUs and NICs. Well, our draft focus on network layer implementation, and we also require information exchange and collaboration between the network and the computation layers. For example, the control plane needs to know which CPUs are communicating to preallocate credits. GSE mainly introduced three key features. First, credit based authorization ensures the last hop has sufficient bandwidth before transmission begins. Second, packet aggregation, which aggregates packets into uniform size segments for efficient forwarding and balanced load. Third, improved eCMP. It's with packets evenly across all links while preserving order. In addition, GIC works with existing mechanism like PFC and ECN as complementary safeguards. This page shows how GIC works end to end through a concrete example. GPU one connected to leaf one want to send traffic to GPU 20 connected to leaf three. Before any data transmission, GPU one needs to know whether the link between leaf three and GPU 20 has sufficient bandwidth. First, the g p u one sends a credit request to g p u 20. This request credits the link state on the last hope and whether the link bandwidth is sufficient. The request and response messages has
[01:15:32] Yingzhen Li: Hold on. Your voice is breaking up.
[01:15:42] Ka Zhang: Hello?
[01:15:43] Huaimo Chen: Probably cannot hear you either.
[01:15:46] Yingzhen Li: Can you hear me? We cannot hear you. Is there a backup presenter on-site?
[01:16:04] Jeff Tantsura: I think the issue is here, actually. Sandy can present.
[01:16:12] Yingzhen Li: Yeah.
[01:16:13] Yuying Chi: Hi. Can you hear me? Is the connection recovered?
[01:16:17] Yingzhen Li: Yeah.
[01:16:21] Yuying Chi: Excuse me. So I can restart at this page.
[01:16:27] Yingzhen Li: Maybe you want to repeat this slide.
[01:16:31] Yuying Chi: Yeah. This page shows the so this page shows how GIC works end to end through a concrete example. This in this scenario, GPU one connected to leaf one, it wants to send traffic to GPU 20 and connect it to leaf three. So before any data transmission, g p u one needs to know whether the link between Leaf three and the g p u 20 has sufficient bandwidth. So first, g p one sends a credit request to g p u 20. This request requires the link state on the last hop. It it queries whether the link bandwidth is sufficient, and the request and response messages has a specific format, which will be defined in the following versions. G p o one only starts sending after traffic after g p o 20 respond with a successful grant. And once the grant is the credit is granted, packets are aggregated into uniform sized containers or segments with a GIC header. These containers or segments are then evenly spread across eCMP links at the network layer to achieve near optimal load balancing. So here's another scenario. It's it's it's moved GSE to the cross port scenario. G g in this in this scenario, GPU one wants to send traffic to GPU x in another port. The credit negotiation will be between Leaf one and SuperSpy. Leaf one can negotiate credits with multiple links connected to core switches from multiple SuperSpy switches. So in this scenario, GIC have several key points about deployment flexibility. If the port uses switches from a different vendor, this point means the remote the remote port, it uses which is from a different vendor that do not support GIC. And it we we will restore the original packets before sending it to the core layer. And this GIC only guarantees reliable transmission within within one port. If the other port also supports GIC functionality, GIC encapsulation can be maintained throughout the entire process and guaranteed by full link or multiple segment links. This means GIC can be incrementally deployed in multi vendor environments. In this page, we briefly introduced the GIC header. In this draft, we introduced a new GIC header for tran for traditional IP forwarding. It does not easily support hop by hop credit signaling. So so GIC uses a new Ethernet packet type. The header serves two purpose. First, data forwarding. Packets are aggregated into uniform slide segments or containers, and each packet carries a GSE header with a sequence number for reordering. Second, control signaling where the header carries credit request and the responses messages for credit negotiation. The key fields includes include the destiny destination, port ID for credit as authorization, priority, entropy for stable eCMP harshing, and sequence number for out of order assembly. Switches need to support GSE header recognition and forwarding. So in conclusion, we believe GSE offers a so in conclusion, we believe GSE offers a practical approach to AI networking. We have laid out the architecture, the core mechanism, and deployment scenario in this version of draft, and we will add more details in the future versions, such as detailed credit detailed credit request and response mechanism and header formats and the detailed packet aggregation and container construction mechanism. So we are happy to take your questions and comments. Thank you for your time.
[01:21:04] Jeff Tantsura: It'd be great if you go a bit more details on credit loops and also great stuff that we have observed in credit based networking and how you deal with it with centralized controller. You know, none of this is new. We've seen this in InfiniBand to some degree, and those are well known technologies. Those are non well known issues. So I think you should cover them in the draft.
[01:21:31] Yuying Chi: Of course, we will cover it in the in the in the in the future versions.
[01:21:37] Presenter: Thank you.
[01:21:42] Yingzhen Li: Thanks.
[01:22:09] Weiqiang Cheng: So hello, everyone. I'm Wu Chang Cheng from China Mobile, and I will present the enhanced ECNP for AI cluster. So the back end is that, you know, AI training traffic is really challenging for the networking. The reason is that the very large flow and the high requirement on the reliance. And the flow number is also very limited. So and the is very big. So for the network, if you want to get the low tailor latency and predicted performance, is really hard. When we see the ECNP, traditional ECNP, you will get the elephant flow collision seriously. So we need a improvement solutions. And here, we will provide two optimization solution, one based on ingress group, and the other is based on egress group. The whole solution is based on the symmetry of the architecture. If the traffic from GPU is relevant to balanced, and you can use the ingress group solution. And if the traffic to GPU is balanced, and you may prefer to use the egress group solution. Here, let's start from the ingress group solution. It's very easy, and you can group the ingress interfaces and give them index. And based on the index map to the traffic to the eCMP group so that the different indexed traffic will be mapped to the different outgoing outgoing line so that you can avoid the the collision. This is the basic solution for the ingress group. And here is an example. As I mentioned, the group you you group the ingress interfaces and perform the load balancing based on the index within the group. Then you can make the load sharing more balanced. You you can see within the group, there will no collision. And because the group and the group are in deep independent, So it it also make the collision between groups allies. So this is the basic idea of the solution. And the e egress grouping based mechanism is a little bit complicated. We need some extension to the such as the BGP community. And the the egress leaf switch should advertise the group ID and the switch ID to the ingress switch. And based on the group ID, ingress leaf switch will map the traffic to the different EZMP outline outgoing line. So that based on the egress group ID, you can make the traffic load balance wire. So this is the basic idea. And here is an example. It's very easy. You can see based on the group ID, which are advertised from the egress leaf switch, then you can map the traffic to the different e CMP group, then you can get to the load balance through the whole network. And then here, we need some extension to the BGP community, as I just mentioned. We would like to have the maybe a switch ID and the group ID. And based on the information, you can get the load bands wire. And then now the both solution, we have verified in our big AI data center, and it works wire. So next step, we would like to get more feedback. And maybe we would like to ask for adoption. But before that, maybe we need to present something in IDR because we need to extend the BGP community. So that's all. Any comments?
[01:28:31] Jeff Tantsura: Just not sure. It's working group share. What what do you want with this working ATF? It's local behavior. You could use something like site of origin community to encode exactly that. What would you like to standardize here?
[01:28:50] Weiqiang Cheng: So yeah. I mean, if we need some extension for that
[01:28:55] Gyan Mishra: Yeah.
[01:28:56] Weiqiang Cheng: I I think the BGP extension is one way we can do that. Right? Based on if we can have some extension standard that will be benefited for the different users. And especially, you know, for the operators, we would like to have a much source of switches. If a switch vendors can implement the draft or the that would be beneficial for the operators. Yeah. Okay.
[01:29:37] Tony Lee: Hi. Tony Lee, HPE. How does your solution deal with congestion?
[01:29:45] Weiqiang Cheng: Meaning for the con congestion? I I think load balance just one way to avoid the congestion, but it will will not solve all the problems about the congestion. But the you know, ECMP. If you use the traditional ECMP, you will get the elephant flows collision dramatically. That will worse the congestion. If we optimize that, and you can get to the byte performance. Yeah.
[01:30:33] Tony Lee: Seems to me like you're missing half the solution here.
[01:30:37] Weiqiang Cheng: I I think it the solution have optimized the the congestion problem, but you can never solve you you can never solve all the congestion problem based on a little balance only. Yeah.
[01:30:57] Yingzhen Li: Okay. So as an individual contributor, how do you handle out of pack out of order delivery? You're still facing the same problem.
[01:31:10] Weiqiang Cheng: Yeah. I mean, there are several different solutions?
[01:31:13] Yingzhen Li: No. No. I mean, once you have multiple pass, you have out of order delivery for the same flow.
[01:31:20] Weiqiang Cheng: No. The the this will not introduce out of order of a packet because it's based on the flow.
[01:31:29] Yingzhen Li: Oh, okay. So you are still doing the same high sync?
[01:31:32] Weiqiang Cheng: Okay. Yeah.
[01:31:34] Yingzhen Li: Okay. As working group share, you do aware, you know, consider you know, let's assume there is consensus in the community about this proposal. The IDR encoding need to be Okay. In IDR. The BCP encoding need to be in IDR. Yeah. Not here.
[01:31:51] Weiqiang Cheng: And, yeah, we present it here, and we also will apply some slots in the future in IDR to see. Yeah.
[01:32:01] Jeff Tantsura: As to IDR, I think I mentioned it already, side of origin community allows you in code router ID plus two bytes. You need nothing. Really?
[01:32:12] Weiqiang Cheng: Yeah. Thank you.
[01:32:21] Jeff Tantsura: Thank you.
[01:32:37] Presenter: Yeah. Okay. Can you hear me?
[01:32:46] Yingzhen Li: Hello? You can start.
[01:32:48] Presenter: Hello? Okay. Okay. Okay. Good afternoon, everyone. I'm from China Mobile. I will introduce our updating the distributor inference network about the policy name, use cases, and requirements. Already planned the first version in at the ITF one twenty four, and this time, I will I will focus on the up updating material. Next next slide, please.
[01:33:20] Yingzhen Li: You have control of the slides.
[01:33:23] Presenter: Okay. Oh, oh, good. And okay. Let me just recall the draft motivation quickly. We view AI as in two distinct phases about training and inference, which I introduced about something of the training. So I this draft focus on the inference, and we consider agents as a kind of specific AI inference. And as AI inference cost decreased very quickly and the number of AI inference application and the inference API invocation is growing faster. So it's a bring a big challenge for the network, for them, for the the the billions level of concurrency and the the stable low latency requirement for the real time inference and some kind of new enterprise secure inference use cases that also bonds new network at completers. And so for the problem statement section, the draft already described several funding fundamentally limitation about the centralized inference architecture, such as stability problem, the latency is too much, and the reliability. And and based on the community feedback, we already have add security security challenge for the also for the distributor inference, including or not from the model extra extra action and the data leakage from the intermediate nodes. Also, we have added agent influence problems. Network, we think that it it's like how to handle for them the agent identity, agent completed discovery, and also about the agent dynamic state for communication. We add as a we add some program program statement on this subject. And also for the usage use cases, we have write about seven use cases in the draft. Use case one to five cover enterprise in different inference, h cloud collaboration, dynamic routing, and the security scheduling, and the private and the privacy splitting inference. And based on the communicated feedback, we added two use cases for the agent inference and in and for the agent intercommunication. I will introduce several use cases. For example, for for the the okay. For the the model splitting inference, in last IETf in Shenzhen, we invited a customer from the hospital to introduce these user cases in the same meeting. The hospital need AI to help doctors with health care and the for their research, but the data and the users promote promote should not be allowed to to leave the hospital campus. And, also, some a lot of hospital, they don't you know, they had they they they didn't have bigger AI computation infrastructure of their own. So in this use cases, it's about to split the AF inference. For example, put the first and the last inference layer in the hospitalcampuscomcomputation and put the rest middle layers in third party cloud and maybe 100 kilometers away. In this case, network should provide the lossless and the high bandwidth. Didn't mistake connect connectivity to transfer the hidden wear wear wear wear wear wear the next use case about two agent related use case, and the first one is AI agent inference service. It cover three communication types, human to agent, agent to agent, and agent to tools. We add some description. And for the next one is about agent inter intercommunication case. We can say there are a lot of there are several different agent communication protocols. They can communicate with each other, but but what what if the different agent a different agent protocol, how how how can they communicate each other? So we believe maybe agent inter communication gateway is needed to solve this kind of problem among different agent protocols. Just very similar, like, the the the at the beginning at the '8 '19 eighties were designed to solve the different interconnection protocols between different networks. And, also, we summarized some requirement about agent communication required a stable, low latency and need agent based skill discovery and security mechanism. And based on the new use case above, we have updated the requirement requirements accordingly. For the for the split inferences scenario, we add a requirement that the network should protect the intermediate representations and network should stable low loss days. For the agent use case, we add the requirement about agent identity and also agent authentication and the fine current entity about the also reason. Especially, we propose agent influence the job level AA network AA framework. It's similar with home bandwidth home broadband a a today, but for the inference job level. I believe the same a a mechanism should be extended to austatic the AI influence and the AI agent. And also, I think similar with the home band, the your ask function maybe could also be a trust also at the age to perform the verification before the AI inference granting access to the network resource and get to the inference service.
[01:41:18] Presenter: Okay.
[01:41:21] Presenter: We welcome communication feedback to help you enrich the use cases. And also in the last stage, we were deeply to analyze the gap between the requirement and the the nowadays protocols, and then maybe draft maybe we are have new draft for the gap analysis. Okay. Thank you.
[01:41:48] Yuying Chi: Tony.
[01:41:52] Tony Lee: Hi. Tony Lee, HPE again. Was there a routing problem buried here somewhere? I'm sorry if I missed it.
[01:42:05] Presenter: Maybe for the okay. I I I submit this thing at g g w g because I think there are no good place talking about the the the the inference. And, for the inference acceleration, I think we we we can have some the the the the routing schedule routing and the the scheduling mechanism.
[01:42:38] Tony Lee: Okay. Well, so without a routing problem, I'm sort of wondering why we're here.
[01:42:51] Presenter: So it's it's a
[01:42:53] Jeff Tantsura: I'll try to reply to that, the one we allow the presentation. Usually, when kind of new architectural work comes in, we tend to allow people to do the zero zero presentation kind of to explain the problem space. And then we look much stricter if it belongs here. You know.
[01:43:16] Tony Lee: I understand we have a broad charter. I support that. There is such a thing as too broad.
[01:43:25] Yingzhen Li: Tony, I understand your point. For this specific draft, I think if there is depends on community interest, if we don't see more discussion on the list, this draft probably won't be presented in RTCW again. Any other question or comments? Okay. Thank you. So we'll go to the next presentation.
[01:44:07] Presenter: Good afternoon, everyone. This is from China Mobile. And on behalf of our colleague from China satellite network group and city, the topic is geographic based routing cellular networks. So traditional routing are designed for stable topologies, but the radio satellites network are changing quick very open. The the topology may change every ten to fifteen seconds. That brings some challenges like the convergence time and the massive flooding. So if there is some some something can make the rushing a little bit stable, that will be good for us. So the basically, the idea is that satellite movement triggers frequent routing updates, make network wide synchronization of the routing state extremely difficult. We want to achieve two object objectives. One is to reduce the total volume of routing entries while mitigating the routing churn caused by the set satellite mob mobility. We are doing that by introducing an intermediate routing layer that is time variant address, which means the satellite address will be changed periodically based on the geographical location. Because the geo geographic area is known in advance, if we design the address allocation scheme carefully, we can eliminate the need to learn the global routes. Also, from the user point of view, if the access address is from the satellite is stable, that will be easier easier for the for the user terminal to to the satellite satellite. So the the the basically, where is the this this this slide shows where the GR's graphical geographic routing is running. That's just running between the u here, you know, picture shows the UT and and the GS between UT and GS. UT is a user satellite terminal connected connecting user network and the satellite to the next satellite. GS is a ground station that connect connect satellite to POP and then to Ethernet. So this slide shows how the address is encode the the addressing coding scheme. On the right part of this this this page, We you we we just we just show that that that we are we are inspired by the over the h s three encoding, but it can be something else. The main purpose is to build a multilayer hierarchical address addressing capability from continental continental scale to the fine grained city. On the on the left page of the left page, this is a shows an example. One that's there there are there are many, many cells. One parent cell can have seven child child cells, and the child's cells can have also. It's all the child child cells. By that way, it can perform hierarchical routing, narrowing down the down to the destination geographical scope from cross granular granularity to to fine granularity layer by layer. And the the in addressing coding scheme is fully compatible with IPv6 or IPv4 address format. So here is an example. On the bottoms on the bottom of this of this this page, We we we show how the how the routing is works because the GRC address is a a intermediate layer.
[01:49:49] Jeff Tantsura: So
[01:49:51] Presenter: it need to resolve to the real next hop or the real direction because one satellite has four at least four directions, the north, and it has four interfaces, north and south, west, and the east. So we if we find the correct direction, the package will be forwarded, then we can can can can do the right routing. So so the the routing is the result resolution to the right next hop is actually to find if the find the correct direction of the egress interface on a particular slide. So that can be simplified fine to find if the next hop is within the orbit or in the neighboring orbit. So so to decide if that that's next hop is within our outside this orbit, that is some some kind of because we have the GRC destination address mapping mapping to geo geographic location. That is that that information know in advance. It will give us some rough idea on which direction it should be forwarded. That can be used to judge if the destination is in the same orbit or in the other orbit. For the interorbit, we only need to know if that's if that should be routed to the another orbit, we only need to know which satellite within this orbit should be is connecting to the neighboring has neighboring on the other orbit. So by knowing that is we this can be simply running an IGP within that orbit just to discover the neighbor with another orbit. That that is quite that is that that that it doesn't need to flood all of the routing information across all of the orbits. So it's like some kind of design in ISS. I remember that should be some DNP or some some some bits that's that can instruct the level level one, the node to node, which node is connected to the is a level one and level two node. So so it's kind of it's also kind of a time slice slice the routing, and it's it is compatible with existing hardware, and it should be there should be a global controller to compute the routing table in advance for the for each satellite.
[01:53:19] Jeff Tantsura: So
[01:53:23] Presenter: that's all. I think I want to get more feedback from community and working group.
[01:53:34] Tony Lee: Hi. Tony Lee, HPE, yet again. Some time ago, Dino Feranacci posted an inter interesting draft on using Lisp and geographic addressing to solve this exact same problem. Could you compare and contrast your solution to his?
[01:53:56] Presenter: I'm not aware of that that, so I maybe I can do some comparison Response is a mail list.
[01:54:07] Tony Lee: Okay. I'll put a link to his draft in your in the chat.
[01:54:11] Presenter: Thank you, doc. Thank you.
[01:54:13] Yingzhen Li: Maybe to the list. Okay.
[01:54:24] Andrew Stone: Hello. Thank you for the presentation. Maxime Pierrot from RSPS Lab. In general, as a comment on the approach, I'll be more interested into trying to fix the existing protocols instead of inventing a new one such that we can more easily benefit from the ecosystem of implementation of techniques and tools that are already existing. Your approach seems to put more responsibilities on the UT and more trust, maybe in a sense. So it will be very tied to what you're using in the access network, and it's not only about satellite routing, but it's also about the access network then. And so in this case, for five g non terrestrial, I'm I'm not sure how this, this kind of solution could work. So it is maybe one solution, but not the one solution, that will solve all the problems that we have. Thank you.
[01:55:18] Presenter: Thank you. Yeah. That should be some some of the routing work should be done on the. That's that's correct. So thank you.
[01:55:39] Yingzhen Li: No more questions? If not, I think we are done with other presentations, and we have five minutes left. Any questions to the working group? No? Okay. Then
[01:56:00] Jeff Tantsura: Before we say goodbye, unfortunately, we didn't do the AIDC meeting with the Zietf. When we tried to book a room a couple of hours after they've opened, they've all been booked by the same person. It's like a dust attack, for better or worse. So we'll talk to OSG or I'm not sure what to do with it, but we have very exciting agenda for next ATF for you. Thank you, and see you in San Francisco. And now we don't have any plans for post election. Jeff,
[01:56:41] Aditya: not speaking on behalf of the IESG, but you could always do an interim.
[01:56:48] Jeff Tantsura: Sure, but one person should not be allowed to book like most of their own for most of the days. It's weird.
[01:56:59] Tony Lee: Oh, yeah.
[01:57:01] Jeff Tantsura: I was talking about rooms available for side meetings.
[01:57:05] Yingzhen Li: Different topic. Let's discuss that offline. Yeah.
[01:57:09] Aditya: That is something that I cannot talk about. So no comment.
[01:57:25] Jeff Tantsura: We did it again. Yeah. Thanks.
[01:58:11] Yingzhen Li: Now I'm a good class.
[01:58:15] Jeff Tantsura: I'll complete the first.