**Session Date/Time:** 21 Jul 2026 14:30

[00:01:16] **Sheng Jiang**: What?

[00:01:21] **Toerless Eckert**: Either this product from that guy over there has a bad clock or that clock over there is wrong. I fear as well. Yes. And if that's what the conference is operating on, who knows?

[00:01:37] **Sheng Jiang**: Shall we start?

[00:01:38] **Toerless Eckert**: Yeah. Let's start. Can someone please close the door in the back? Thank you very much. Okay. Welcome, everybody. We're here at the, animal working group meeting. And, just for the process wise, obviously, please understand the note well. I'm not going to read it out again. You by now, you should have seen it a couple of times, civilized and friendly and factual on the work. And when you're in the room, please make sure that you are locked in to one of the options in room or just with the application in the back in that. I think some people walked in and not doing that, so very much love to have correct accounting for the people in the room. And, also, if you can contribute to the meeting notes, the URL is there. That's what you also see on the agenda. Now, we quickly wanna go through the chair slides, the Anima, adopted working group documents. Primarily, the BRSKI documents are wonderfully coming to being finished going all through ISG. The existing cluster is unchanged. I I'm not sure if this is actually new, but they have on the RFC editor page this wonderful graphics now that shows the dependencies between all the documents. We've got four in the queue, one from another working group depending on it, one that we're simply holding back after ISG review not to go to RFC editor to make it a little bit easier in case we still have last minute changes from one of the unresolved dependencies. But I think as soon as the constrained stuff is is is also going through the ISG, then this will finish. So which brings us to the the documents where still there is ongoing work. So we've got voucher and proxy. Is going to talk about that today. We've got constrained GRASP that's also going to be presented. We have a part document. We'll we'll we'll get outside of the the working group meeting here back to the authors and validate that. We've got the service auto deployment. I'm not sure if anyone is here that there was unclear status for me. So I'll That's also packed.

[00:04:17] **Sheng Jiang**: Also packed. Okay. Closer.

[00:04:19] **Toerless Eckert**: Okay. Then let's put that in the chair slide now. It's just a quick kind of the service deployment also packed. And then we've got eighty three sixty six bis, which the authors, I think, made a lot of good progress. It's now on the ADQ. Hopefully, he is very happy with this. I'm not sure if there's anything relevant to be said to the working group. I think lead author is a little bit voice challenged. Esko, is there anything you would like to say about this, or are we fine on?

[00:05:04] **Esko Dijk**: K. I can say something. So we have several new versions, I think, since last IETf. I even saw right now a new version was released, so it's going well. So that's mostly addressing comments from the IESG and IANA, I think. So that's my view on the thing, and Michael is handling those comments. So for any details Mhmm. Go to Michael, basically. Thank you. Alright.

[00:05:40] **Toerless Eckert**: Okay. And then I've also put my update on discovery here in the chair slides so that we can focus more on the new work. So thank you very much, Stuart, again. We had a great review from him. I started the feedback last ITF, and, hopefully, now the, the review is finished with the version that I checked in three weeks back or so. So I rewrote and shortened the abstract and instead extended the overview kind of the way it should be. I hopefully correctly answered the concern, for the text being confusing with respect to DNS SD and details by outlining that we've got two key differences, I think, over typical DNSSD deployments. One is that we're trying to do fully automated client implementations as opposed to, I think, lot of DNSSD that's very much having humans in the loop, making selections. And the second one is that we're seeing more and more constrained devices where likely big, you know, existing libraries like a Vahi or so will maybe not be usable. So that's why I felt as an author, it was useful to add a couple more of these implementation details that usually you wouldn't need to to to worry about. Of course, there's there's a lot more detail independent of DNSSD for automatic failover in the discovery, right, when you discover multiple instances and you fail over very quickly. Those are generic and not specific to DNSSD. So that was that. Improved the terminology definition that was claimed. And then I'd yeah. English as a second language excuse, so I used Claude to to do another revision, which actually was very nice as a spell checker. You need to put in guardrails to not repeat mistakes it always likes to do so that the XML has guardrails now against those, but it also found one or two logical errors. Like, I had not in or not was missing. So it's so as a spell check, I can I can actually nicely recommend it, but I also recommend to put it into separate revision so that people can easily identify what was actually done by an AI? And I think that's even more so when you let it for example, which I haven't tried, like, improve the English. Right? So which maybe I'll try in another draft or maybe when I talk with RFC editors. So I'm I'm not sure about that yet.

[00:08:10] **Stuart Cheshire**: Yeah. Just a quick comment on that subject. Mhmm. I've been experimenting, trying to work out what AI is good for and what it's not good for.

[00:08:18] **Sheng Jiang**: Mhmm.

[00:08:18] **Stuart Cheshire**: And one of the things I will say it's very good for is being your proofreader. Mhmm. Instead of asking a human being or sending it to the mailing list and getting lots of emails with spelling mistakes, I just asked Claude. I said, please review this document for spelling, grammar, punctuation, and general readability. And I don't have it write the text. It gives me answers just like a human would. And I I meant to say, it is better to do something, and I typed, is is better. And it's a silly typo. I didn't notice it proofreading it. And and Claude spits out all of these things, and that, then I fix them, and I don't have to get emails from 10 people telling me the same thing. And I think there's a huge value. It makes it easier for people reading it

[00:09:08] **Sheng Jiang**: Mhmm.

[00:09:09] **Stuart Cheshire**: If they're not constantly stumbling over spelling mistakes and grammar mistakes and punctuation mistakes. If they can just read smoothly and focus on the content and not the style, I think it's enormously valuable. So I am a big proponent of using AI for that step. Yeah.

[00:09:25] **Toerless Eckert**: And I think maybe one key part is it does it on the markdown. Right? So whatever you're using because I I always had with other spelling checkers problem with a lot of stuff in markdowns, and it ignores all of the markdown stuff accordingly.

[00:09:38] **Sheng Jiang**: Yeah. Is that I'm not sure we are in the best timing or the worst time here because we do have, you know, something very helpful for us, but we could possibly be replaced by them someday.

[00:09:57] **Toerless Eckert**: Okay. So then when I when I finished that, I I asked my co chair to ask for a couple of early reviews from other working groups or areas that I know are relevant here. So those came in, but it was too late kind of last week for me to finish that. But I think once I'm through those early reviews, we can go into a working group last call. Okay. So where are we? Okay. So wanted as chairs, we wanted to talk a little bit about the future work. So we had, in the past two years, a little bit of reluctance to quickly adopt a a new work because a lot of the core contributors for many of the proposals have been tied up with the ongoing working group documents. That's always kind of something area directors don't like. Right? So, oh, let me start new work, then you you delay existing work. So with this queue now nicely finishing up, we wanna get back with also the documents parked in mind and ask for adoption. So, for example, I've I've put in a document for DNS discovery over GRASP, which I think would be great also for for our upcoming topic of discovery of, you know, in the context of AI agent or any distributed animal work. Similarly, I think Brian has a new proposal on on on grasp. So if you have anything similarly that you were proposing recently and, you know, didn't think of having enough time to put it through or so, please bring it up on the mailing list. And then towards, you know, other new work that we think would be interesting. I think there there are two big recognitions. We had this long story of intent, you know, being something we couldn't figure out what to do about it. We pushed it back to NMRG, and now we know that the intent language is simply whatever you talk to an AI agent that helps you. So that problem is seemingly off the table. There is still a lot of cool intent stuff to be done, and we'll have presentations about that. And then the other one was we had, in our last recharging discussions, added ASA, you know, agents in the network to do things, and we saw very little proposals for good standardized agent specification. And I think we came also to realize that this is because if we're going to have automation, it's going to be a lot more customized and driven by AI in terms of that we're also going to see a big shift in the way that automation is now being done and that the old approach that we've thought about be before, you know, 2021 is probably not going to be sufficient anymore. So if whatever you you are thinking of can already be expressed purely by it's it's an agent in the network without, you know, anything that's newer specific to AI, you you can obviously already bring it to the table, but we've specifically been thinking about what is it that, you know, agentic AI brings and wanted to consider that as as an ask for a recharter to make it easier to work on those topics as well. So here is our first step at the proposed recharter, so let me quickly read through that. So the NMR Working Group has standardized for network management and operations, core infrastructure protocols, enabling communication amongst agents, whether in the network as autonomic service agents or ASA or outside of it in the network operation center. This autonomic network infrastructure, ANI, suit, includes grasp for agent interaction including discovery, ACP for a secure zero touch communication fabric indestructible by agent mistakes, and BRSKI for enrollment along with their extensions. RFC ninety two twenty two provides ASA guidelines, though it was written before AI powered agents emerged. This mature standardized substrate can now support AI powered network agents with unified communication capabilities. Advances in AI algorithms like DNNs and LLMs have greatly expanded network agent capabilities, but the underlying network behavior models and infrastructure requirements remain unchanged. As network agents grow more intelligent, gaps will emerge. The animal working group aims to identify these gaps, extend the ANI, and specify additional data and communication models to support new scenarios. Below are some work items already identified in addition to completing extending existing ANI ones. So the first one being documents for new network agent communication use cases, including AI and data center, distributed IoT agents, agents on routers, not managed agents, and so on. The second one is the gap analysis for adjective network automation, such extending the ANI for better network agent life cycle management, operational mechanisms for agentic development, and deployment of network agents. Third one being protocol extensions for newly raised communication requirements among network agents, including but not limited to grasp rendezvous, grasped routers, trust model among AI powered network agents such as role based certificates, network intensity construction, and mapping onto the ANI model. And the final one, agent definitions of new information data or data structures for communication among network agents. So I think we have some set of candidate milestone documents for that as well. So that's the next step that we we we need to collect and and relate to this list. And then I think we're we're off trying to propose that to our AD and, of course, with with the working group as well. So that was kind of our thoughts on on how to go from here given how we're kind of draining our queue of of work and should have more free cycles now to work on the new work. So, again, if you'd already presented in recent IETFs on work where we kind of were too busy all to to pick up things, remember your responsibility as a proponent of your work. Bring up your recently submitted, like, in one twenty five, one twenty four drafts to the mailing list again so that we remember to look at it and consider it and see how it would fit the Anima work at the existing charter or especially when you think it's it's somewhat outside of charter but could kind of be when we when we do the Charter. And I I I have in my slide deck, I think, hopefully, a nice graphical way to to explain this Charter extension. So and, of course, if you have any questions about process or so, always feel free to reach out in private mail to to us chairs if if you're not if you don't like to think you're asking stupid questions. And I guarantee you, there are no stupid questions, only stupid answers. And, yeah, please feel free to ask. Yeah.

[00:17:04] **ISI Participant**: Hello. From ISI. There was a both previous for agent discovery and so the agent discovery within the scope. So it's different. It's the same. It's what kind of discovery are you agent discovery are you intending to do in this?

[00:17:25] **Toerless Eckert**: So the the agents we're talking about would be agents that the network management team in a in a network operations is interested in. Right? So it is inside a single service provider network or inside in a single enterprise network or, at best, a large federation. So this would not be discovery over the Internet.

[00:17:44] **ISI Participant**: Okay. So it's a subset inside the network. Okay.

[00:17:48] **Toerless Eckert**: Well, I think it's also much more a subset of the functionality. Right? It's not basically kind of humongous data models of describing that stuff. So it's a much more lightweight, sane, really kind of simple things we're we're looking into to automate things to just take manual configuration out of the picture.

[00:18:04] **ISI Participant**: Thank you

[00:18:05] **Esko Dijk**: very much. Yeah.

[00:18:07] **Sheng Jiang**: I mean, people can have different understanding for the same terms and particularly the agent here. We would like to emphasize that in this working group, no matter that's before or in the future, we would like to working on the network agent, which means that's the agent that serves for networking to, you know, get the network devices configured or management managed or gets operated. That's it. Thank you.

[00:18:46] **Toerless Eckert**: Okay. Was there any other questions? I think the queue is empty. Yeah.

[00:18:50] **Sheng Jiang**: Please go ahead. Go ahead.

[00:18:53] **Toerless Eckert**: Thank you. Oh, that give me one second.

[00:19:02] **Esko Dijk**: So put it a little bit higher. So we're on to the first presentation, Alan. So this is two drafts in one. So I'll start with the first one. Both of them, are related to constrained BRSKI. So in this world, we, don't have agents or at least yet. We don't even have a a network of routers or an ANI, but, this is more in the world of IoT mesh networks. So I'll get started with the updates. This draft has been around for a while, but we are now getting to the end, I believe. So to recap the goal for people who are new there, the constrained brewski protocol is a protocol for secure onboarding. So the devices that are onboarded are constrained IoT devices running constrained network technology, such as, those based on six low band. You can see an example network here on the left. So on the left is the constrained network side that uses constrained communication, low bit rates. For example, the COAP protocol, care is taken to to minimize, message sizes. And on the right part, there is a regular HTTPS communication over the Internet. So, basically, the new device, shown at the bottom left wants to onboard the new net, the network, which it does doesn't know yet. The network itself also doesn't really know the new device, so there's no initial connection possible. But, thanks to the onboarding protocol and help of the registrar there and the Mazda server, which is from the manufacturer, the new device can basically onboard. So there's mutual authentication between the domain that accepts the new device and the new device itself. Now on to the updates. So what what has been new since, last ITF where this was presented, 01/25. So there is some new functionality. So, the, basically, join proxy discovery methods that is, used from the other draft I will present soon is now updated. So that means this draft also needed to be up updated with, in terms of the examples. So this discovery uses COAP link format discovery. So it it's basically an unsecured, let's say, not yet authenticated discovery, methods where, basically, the only thing that is discovered is, okay, what are the devices that can help me onboard and on which port do I need to contact, those devices? So this is the new, format shown here. And compared to the previous methods, it's, simpler and more compact. So that's now implemented. And content wise, other updates are that, detail has one point two and one point three. Details are now added. So these are the Cypher Suite details. And the idea is that's kind of required for improved base interoperability. So as a default, if you don't define anything else in your application profile, then, you can at least use these base, cipher suites. Plus, we have, editorials and fixes. Yeah. This is also worth mentioning. So there was this ITF, hackathon work, which is, something I did. No no other team members, yet. And turned out it was also not not really needed because, I first have to get this whole system up and running, interoperating with myself before I try to do it with others. So that will come maybe in the future. So these are all, open source components here that are compiled, together in specific ways, also across different projects, across different languages to make this possible. So this basically, yeah, simulates the entire chain that you see here with all the devices, but not physical devices. It just runs on one laptop, it's easy to get in and out of IETF meetings. So, yeah, that basically uses a network simulator to, simulate the left part. So these the six low power network that's based on the threat mesh networking protocol. So that's an I p v six based measure mesh network protocol that is mostly used for consumer home technology at this moment. Met Meter is an important user of this. So it's available in commercial devices and also has open source components, which I'm using. And that connects to the, yeah, basically, the the more web services written in in Java. And that's all, yeah, kind of test test setup to to test the basic flow and verify that what we specify in the draft also can actually work. More updates since one to five. So we got a good detailed Shepherd review, so thanks to for that. I was looking into it, and there were lots of comments, but actually lots of good comments. So I'm now processing still, and I still need to provide a response. That will take some time. I do expect some changes due to the review. So what we found also was there were some comments on specific parts about management of IoT devices after onboarding. And I thought, well, it's maybe easier to have that whole topic instead of, yeah, having it half specified. Just leave it out of scope. So focus purely on the onboarding and, put any, like, device IoT device management considerations in another document, which could be in another working group even. So that needs to be seen, whether Anima fits there or could be, ACE or LAMPS, which is also doing EST updates, I believe. So that's the plan at least, so to make the, yeah, draft for more focused. So any remaining open issues? Well, I didn't find any apart from the processing of the Shepherd's review. There is also no open issues on GitHub that actually require work. I think Michael opened some issues for himself to check things, so, I'll leave that to him to check. Perhaps a good thing is also to continue with the interop work, so that that means the setup I tested at the hackathon.

[00:25:49] **China Unicom Presenter**: So

[00:25:52] **Esko Dijk**: that's next on the agenda. So now I think we are moved to the other draft. Let's see. Yeah. So, I already stated the goal here. So, what if we could, for next hackathon, for example, onboard an IoT mesh mesh network of, like, 200 devices and and measure how long it takes, example, how that works. That will be a great test to see, and that's also possible, with the simulator. K. Then on to the second draft. So this is highly related, constrained join proxy. So this is one specific element that is used in the on boarding. It has its own documents. So we, move back to the same picture here. Now there is a new item highlighted. So that's the JP there or join proxy. So this is a functionality that can live in, many devices that are part of the mesh, even old devices or router capable devices. So those are the devices that can help new devices to onboard. So they allow a very, basically, constrained class of unsecured communication just for the purpose of onboarding and only when onboarding is enabled in the mesh. And they forward that traffic instead of checking the cells. They forward it to an entity, in this case, the registrar. And that will do the actual, checking and establish the DTLS session. So we have a draft to specify that. What did change there? So, title changed now using the newer onboarding terminology that we decided on. Some stricter guidance on mode selection. So, that's because we defined two modes, stateless and stateful, depending on the, yeah, memory available in the constraint devices or, basically, security based choice. There's now better definition for the new protocol scheme, JPY, that we use for this protocol. So the URI is now better defined. And the main thing is the change of the discovery method. So other devices to discover the join proxy have a default method to do so. It's not necessarily the only method, but we wanted to provide at least one default method, which is now using shorter message sizes. And that was kind of designed in cooperation with the core working group. Now next steps here, there's not much to do. Maybe refer back to the work of the previous draft, and we, yeah, just wait for the dependency draft to complete also. And then this one can progress, I believe. Okay. I think that's it for the presentation. So not sure if there are any questions, but feel free to ask also after the meeting.

[00:28:55] **Toerless Eckert**: Thank you very much. Thank you. Thanks.

[00:29:00] **Sheng Jiang**: So what's next? That's normal.

[00:29:06] **Toerless Eckert**: I see. Somehow I'm okay. Yes. Clicker.

[00:29:18] **BUPT Presenter**: Hi, Charles.

[00:29:20] **Sheng Jiang**: Yeah. How are you?

[00:29:22] **Toerless Eckert**: Yep. Well, I'm I'm still

[00:29:24] **BUPT Presenter**: Yeah.

[00:29:24] **Toerless Eckert**: There we go. O three. Constrained. Confirm selection. Very cool. And now you should be ready. Please go. Is that Yeah.

[00:29:36] **BUPT Presenter**: I'm around. So I start hi, everyone. I'm from Beijing University of Post and Telecommunication. I will present the latest update of cGRASP corresponding to the version zero three Jet. cGRASP aim to bring grasp based atomic networking to castrate environment, especially IoT networks. cGRASP will replace TCP with CoAP while keeping the basic GRASP procedures. In cGRASP, messages are encoded as stable payloads over CoAP discovery and the flooding using nonconformable multicast request of ground negotiation and synchronization use confirmable client post exchanges. Since IETF one two five, we made several important updates. First, we simplify the basic GRASP profile by deferring support for weight method to future extension. This keeps the base profile smaller and easier to implement the the own chemistry devices. Second, we request second, we revise the discovery mechanism. Further, we refined the discovery relay mechanism. First, we separated seagrass that session state from CoAP exchanging state. Finally, we updated the normative procedures and method examples for negotiation, synchronization, discovering, studying, and relay. On the implementation side, we have migrated the prototypes from TCP based GRASPI to work based on c GRASP. The unicast interaction and multi cast relay mechanism are already implemented. The first key update is the simplification of the cGRASP profile. So main design decision here is to defer a wait message support. Wait message is used for in standard GRASP. However, in CoAP based environment, this introduce additional complexity. When wait message is used, the the negotiating state must remain available even when no CoAP exchange is active. Resuming the negotiation may also require the previous respond the previous responder to initiate a new COAP request. That creates a can solve a role reversal and make state management more complicated. For castrate notes, this complexity is not ideal for the base profile. Therefore, the current design decision is that the base cGRASP profile does not support wait message. If an application needs more processing time, it can either use an appropriate negotiated timeout or terminate the current negotiation and initiate a new session later. The second key update is the discovering relay mechanism over coapt. At at each relay hub, the relay terminates the incoming CoAP exchange and rearranging a new CoAP exchange on each eligible outgoing interface. This design is CoAP exchange stays local to each hub while keeping the SIGGRAPH session stays stable across the whole discovery procedures. So relay also maintains relay state. For discovery, each relay entry each each each relay entry records the incoming interface. It's various it's various upstream transport endpoints and upstream CoAP token for rewards past response voting, the relay matches the downstream response using the token, verifies the Seagrass fashion ID and the initiate locator, and then forwards a response message upstream as a new unicast 2.05 content response. The thought upstream token is used for the upstream response while a fresh med while a fresh message ID is generated. We have also developed a prototype implementation. The implementation has four layer. The first is ASA application layer. Below that is the Seagrass protocol energy. The third is the is a co op adapt station layer, which provides a socket like API and a bridge logic. As a button, we use CoAP client server and the relay components based on on the AIO CoAP library and use the UDP port. The call migration logic will use the existing graph stable messages and ASA state machines as much as possible. Currently, the UniCast negotiation, synchronization, discovery, and flooding, and the multilink relay has all been implemented. This slide shows the current end to end validation scenarios. We built a multilink topology to test both the end to end workflow and the relay behaviors. The current validation covers three main parts. First, the discovering relay and the reverse parts response response forwarding work expected. Second, negotiation and synchronization over has been validated. As far as the flood relay, geothermal case separation, and the loop count boundary handling has also been tested. For next revision towards zero four, We plan to continue both draft refinement and the protocol work. On the draft side, we will complete the discovery transaction life life cycle. This includes response window management, multiple, response handling, and the related cleanup. We will also further, clarify the scope of the base cGRASP profile, especially unsupported or optional graph features, such as wait wait message and rapid mode. Another important task is to align the normative mechanism description, protocol examples, and implementation behavior. On the protocol side, we will close the remaining gaps in relay semantics and state management, complete multi response discovery processing across multiple relay hubs, and perform more end to end functional validation and performance evaluation. We also plan to consolidate the prototype for reproducible testing and future and for future experiments. That's all my presentation. Thanks.

[00:39:52] **Toerless Eckert**: Yeah. Thank you very much. If your implementation is meant to be open source, it would be great to include in a draft a pointer to it. I I couldn't find one. And if you don't have a public location, I I mean, the animal working group for GitHub or so is always open for that type of work.

[00:40:13] **Sheng Jiang**: We have to plan to make it open source, but still before that, there are some license issues. We has to do some produce procedures. Okay. Any questions? Alright. Shall we move? Yep. So could you grab my slides?

[00:40:37] **Toerless Eckert**: Yep. I will. You wanna stay put, sit?

[00:40:41] **Sheng Jiang**: No. You can just do it for me. Yeah. Okay. Actually, you guys can see this meeting, we have a longer time for the nonworking group documents. Hopefully, that's a one of the a signal way where, you know, move on to have new work items. This draft was actually first submit last December, but we didn't give any presentation on last meeting. By that time, we are not sure even it's belong to the or not. So it was wasn't it has it didn't have the name in the document name. We resubmitted it as, you know, for the animal working group this meeting just on Sunday, so the the name changed. Okay. This is the traffic amendment for particularly for the AIDC. Why why the AIDC traffic amendment is different from the conventional traffic management. That's because the phases of AI workloads and resource allocation jointly ship AIDC traffic patterns. Synchronized AI traffic generates traffic burst network hotspots and compute idle intervals whenever communication stores We visualize as trailing inference traffic burst on the right of this page. This burst traffic chain follows a clear sequence, compute workload stage, drives compute resource placement, which then determines which then determines packet translation state and creates variable pressure on optic link cap capacity over time. By saying this, we actually means the traffic management in AIDC is not only about the networking itself. It actually gets input from other perspective. There are four key drives drivers behind this new traffic behaviors. First, the not scale training and inference workload. Second, periodic creative communication between computer nodes. Third, strict latency and job complete data lines. Force, the comp compute placement directly affects traffic locality across the infrastructure. Those factor together brings several network challenges. Traditional static planning and manual orchestration fail to adapt to repeatedly fluctuating traffic and resource conditions, which is is exactly why we need the autonomic traffic management solution based on the autonomic network infrastructure we produced in working group. In this AIDC use case, our primary objective stays focused on traffic management in AIDCs. As you can see in the diagram, four key inputs fit into the core functioning automatical traffic management. Those inputs are application requirements, complete state, packed network state, and optical network states. All four sets of information jointly drive our autonomic traffic traffic control logic. As the output, the decision generated by autonomic traffic management function are all traffic control oriented. We complete forwarding paths, transmission routes, flow priority, traffic splitting the tiers, and light path utilization schemas. The Anima-, in I, particularly, GRASP play a role as synchrony foundation here. Within this framework, network agent exchange application requirements and network state via use case specific grasp for objectives, then those agent negotiate and finalize the traffic management actions. This is the distributed workflow approach. The core premise here is the local ASA codelayed without a global cross domain controller. This workflow unfolds in five steps. First, topology and resource awareness. Second, multipath explosion provision. Third, resource negotiation, then policy deployment, and finally, resource release. Next, we broke down two design dimensions this of this distributed workflow. The first is multi resource domain specialization. We have dedicated ASR covering application and complete package network and optic network domains. Those ASRs share state information and negotiate traffic management actions through grasp objectives that would customize from the AIDC use case. The second dimension is decision layer, which splits decisions by time scale. We can support faster local response for short term adjustments, including multipass routing, route control traffic splitting, and queue priority training. For long time scale adaptation, when performance scans can be achieved, the workflow handles complete placement placement adjustment and light path provisioning. This is a hybrid orchestration approach. The core value of this schema is global correlation paired with distributed executing and repeat local adaptation as stated at the top of the slides. At the top layer sets a centralized controller holding a full global cross domain view. This central entity connects and coordinates four domain specific function modules, the application manager, compute orchestrator, package to network controller, and optic network controller. Believes, those domain modules, we deploy distributed, ASAS to deliver local response and real time feedback, which enables faster on-site adjustment without waiting for central scheduling every time. We also list the type two hybrid policy examples here to clear clarify practical capabilities. First, the basic traffic control, including pass rates priority and traffic splitting. Secondly, workload placement adjustment conducted in core collaboration with the compute orchestrator. Third, light pass provisioning handled together with the optic network controller. This hyper hybrid orchestration model combines the global visibility of a centralized controller and the low latency local reaction capability of distributed ASAS. For this meeting, our goal is to validate the use case and refine the end market. Our next step will be refine the scope of the AIDC, autonomic traffic management. We try to keep the draft the draft framework oriented and avoid over specific mechanism.

[00:51:21] **Toerless Eckert**: What? Oh, I I thought you were were done with the slides?

[00:51:24] **Sheng Jiang**: No. That that's my last. No? You have the control of it. Last page. It's at

[00:51:36] **Toerless Eckert**: 60606.

[00:51:38] **Sheng Jiang**: Yeah. Uh-huh.

[00:51:38] **Toerless Eckert**: No. Wait a second.

[00:51:39] **Sheng Jiang**: No. No. That's that's that's yours. Sorry. I said it

[00:51:44] **Toerless Eckert**: looked like what would fit for? Yeah.

[00:51:50] **Sheng Jiang**: Last page. Yeah. Oh, where are we? Yeah. We try to keep this draft framework oriented and avoid over spec failing mechanisms for now. We will clarify across application complete, packed network, optical network domains. We will align a grasp usage with Anima, including information exchange state, synchronization, resource negotiation, and the policy synchrony. We have several questions we would like to get answers from Anima working group. Is the traffic management ASA in the scope of Anima? I guess so. Is a distributed centralized controller leading hybrid framework label? That's technique. Should the draft remain at the framework level or including examples, grasp for objectives, and interaction flows. This document is currently informational document. If we think we should define the a use case specific grasp for objectives that has to be changed to standard standard track. Right?

[00:53:38] **Toerless Eckert**: Yeah. So I think we're unfortunately running a little bit out out of time, so I think we have to take the question to the list. Would be good if you Sure. If you if you do that so that and and I'll review that and others, hopefully, of course, as well. So we can make progress there. So let me

[00:53:57] **Sheng Jiang**: try to Grab off the Yep. Ten minutes later. Okay.

[00:54:03] **Toerless Eckert**: So I wanted to give a quick overview of of of two drafts we started to work on coming from the high level architecture that was given handed down to us from NMRG ten years ago forming the group, starting with intent and resulting in what we've done so far. But the whole point of intent was never really resolved well. We sent it back to NMRG, and now we're seeing changes with AgenTik AI. But how can we actually safely use AgenTik AI in autonomic networking? And right now, what we're seeing is still that, you know, people are talking about, you know, self driving networks. But what that really means is that there is a more and more intelligent network operation center with AI, and the network itself is not really self driving. So we went back to the original design goals, which actually long after we and NMRG and NMI had defined it, was recognized by the industry, which is that intent is the only way to drive forward all the different criteria on on growing networks. Right? Scale density, agility, and speed, and stability, and security. Right? Typically, you're starting to improve on one, you make the network larger and you make it faster, it becomes more unstable. Right? And and so on. Anytime you improve on these and these things started to happen in the industry at large in 2018, 2019. And now with AI, obviously, are looking a lot more into doing even more intent based networking using AI. So if we look at what NMRG had produced on intent, it's RFC ninety three fifteen, so very current. But we hadn't actually looked into use of AI and agentic components in here. So this is basically what the NMRG draft is that that we've posted is looking into. Here's a little bit of the starting point. We're seeing already very good work like in NMO-up, another site, to use agents on the lower side collecting information, analyzing, and reporting it. We see very little in the on the side where we're creating really autonomic control loops and changing the network, making it work better autonomically. And that's, of course, clear because of all the risks involved in letting agents make decisions about network behavior. And that's obviously where Anima comes in and where we're getting over to what is in the second draft that that that we posted for NMR. So, for example, that the lower control loops here with analyze, validate, learn, plan, and render is something that could happen very well autonomously in the network as part of intent based networking. And then the question is, how do we build it? So the draft I don't wanna go into all the details that I've I've written here, but so there are a couple of strategies that people can think of on how to use these LLMs. Right? And the first one, obviously, is LLMs could run the autonomic control loop. They make mistakes, and the ANI already allows them to make the mistakes and repairs them because it can never disconnect itself from the network. The second one is we're using LLMs only for the safe operations like optimizations in traffic engineering. Another even more interesting answer when I was talking last IETf with several people is that the LLMs are actually primarily tools to help you develop automation. Right? So when you have small automation agents, most people don't have all the detail in, know, in in a network operator all the knowledge about programming these things. So you have a lot better help in there now with LLMs. So summarizing all these different options of how, you know, the agentic functionalities we have now can be used towards the more intent based autonomic network function. That is basically the scope of the document. And to I I have a slide here details, which I may skip in most details, going back to some of the really core use cases that theoretically are very simple that the ANI enables, but due to lack of adoption haven't been done, which is a lot of automated network protocols already don't have automated security. And then the IATf even started to do automated security for these protocols, CARB, and it failed, right, because they couldn't all agree on how to do things. So you simply do things nonstandardized, but you do it through Anima developed, you know, automation agents. Right? So that that would basically and and we had done prototypes even ten years ago and earlier to show how simple it is to, for example, automatically negotiate keys and therefore automatically secure your network. Right? So that's one of our oldest example with a lot of anima originally started by security people, but, obviously, there are a lot more examples where this comes from. So here's basically the the outlook slide in terms of what this document proposes of how to extend Anima charter, and that was in in the charter slides already. If you if you see the red one on the bottom, that's what we've primarily focused on, autonomic network infrastructure and the classical ASA, the the classical agent that is there. And so what we think for really intelligent agents, whether they're LLMs themselves or DNNs or programmed, we we want, of course, the ability to them to be agile handled from the network operation center lifecycle managed, downloaded, be able to run there safe, that if they misbehave, they don't create problems on the routers. So those are all the things that in the classical case, where we were really thinking about monolithic network devices that didn't allow to dynamically download third party software. And with the LLMs, I think that's basically out of the picture. Now if we have old network equipment that cannot do it, there is a simple, you know, answer to that, which is in every pop or so kind of location where you have a bunch of routers, there's also always a provisioning PC. So we simply need to explain a little bit how to expand Anima into that, and then we get to the same type of solution just across a few devices. And so that's basically the the target goal to explain a little bit how to really get to an autonomic network that with the help of AI agents in the various forms becomes a lot more autonomic and leveraging really the whole storyline of intent based networking, not only to collect data and enable the human to do the rest, but also to create autonomic control loops. So that was hopefully very fast to leave, you know, more space for the other presenters. Any questions here on this? I I know I'm always too fast, but here it actually helps, I hope. So and please take it to the list. Right? So if you have

[01:01:26] **Sheng Jiang**: any Questions to the list.

[01:01:28] **Toerless Eckert**: Yeah. Exactly. So what was it? I was five. Right? So then we have

[01:01:36] **Sheng Jiang**: Six.

[01:01:37] **Esko Dijk**: Yep.

[01:01:37] **Sheng Jiang**: Six. Yep. Yep. Do I have to click? Yep.

[01:01:49] **China Unicom Presenter**: Okay. Hello, everyone. I'm from China Unicorn. Today, I'm going to talk as a presentation is program statement and gap analysis for the automatic networking with AI powered automatic service agent, the AI-ASA. So, firstly, I will give you a brief introduction. So we see the analyst already provide the trust infrastructure for the, automatic service agent, the ASAS, through the post gate, SAP, and the grasp. So meanwhile, with the development of the agentic ad, it's able into the distributor reasoning and the collaborative network automation and the related work is also emerging in the and the other agent related, both, etcetera. So the key question is, therefore, is not whether GRASP can carry the AI information, but what additional symmetric communication authorization and trust contents needed for the interoperable AI. And there are some related to work list here. You can find the user website. So based on before we have to do the gap analysis, we have showed a scenario size, a use case for the we have the, draft is, describes the congestion relief mechanism as you with, with these devices. So I don't want to, talk about the detail of this draft. And from here, we want to to to see if for the traffic model and the monitoring and the distribution can be used to use the algorithm and also the agent. So it can may achieve the opt optimal scheme to redirect the traffic and to achieve the automatic relief. And based on this this overview and this image, we need some GRASP and animus work to support the AI-ASAs communication. And next, before last IATf-one hundred twenty five, we have to show the consideration of AISAS. And according to the WG comments, and we do the proper sediment and gap analysis, we to study how grasp can do and does there has a gap to achieve the AI assisted communication. So there is first issues we concerns is communication patterns for the data intensive AI is a exchange. So, basically, traditional, the a the ASRs can to, negotiate some traditional signaling. The data is that way. So for the, RM, with RM, it may exchange the large reasoning context and also the model generates the content, and it's like a a video stream. It's a real time stream. So and, also, they may need the one, two way information. So there is a a gap we we think is that yeah. I think, the anima is designed. It can achieve the discovery and the negotiation and to communications. So it may should define AI-ASA. Maybe we need a and not a technical gap. Maybe it's a gap to to describe how to AI-ASA communication and how to use the GRASps to achieve the things. So in this in this gap, we have the on the main list, there is a brand Brian gave us some comments, and they also have the draft to use the graphs to discover the two ASAS. And then They can switch to, the app app layers. They can do, their, communication based on the TCP QUIC or the, eight way and other, protocols. So next is the second problem we think is symmetric interopter alterabilities for the dynamic objectives. So, there exist in the comparison is a fixed, COPA objective values. But the also designed the dynamic, the private objective without the NA, registrations. So there is a problem is, we can set the objective value to the any and can provide some flexible and you can fit any you want to describe. But for the diff developer, it has may not to share the same understanding of the objective meaning and concerns with different developer with all also different variants or the trust contest. So there is a maybe we can to define a common symmetric model for the dynamic generator AI extender objectives. Also, there is potential directions we can to combine the machine readable method and also the some natural language or the AI generated content to give the ASRs more AI capabilities. Okay. And there are some we have studied some potential work for our future work. First is the ASR communication patterns. So this we as based on the Anima, we think the graphs can support the discovery, rendezvous, and negotiation. So maybe we need the the documents, how to use it to achieve the AI-ASA communication. And then also, they need the one there are I saw there are the one to many distribution tract, but it's parked. So maybe for the future, we can analyze the it can to how to support the streaming data with the agent to do the inference. And second is self describing objectives. It's maybe we can explore the common structure for the dynamic generated objectives. And last but not least is this thing is important, but we can to further study the secure and the trust consideration for the AI because the AI, it can to generate some some error or or something, so we need to consider the security and the trust. Okay. The next step, can to continue the analysis for the automatic networking with AI with unmask working WG. And, also, yeah, we should there are some overlap with another agent involved and the WG activities. So but I see we think the anima is mainly focused on the AI infrastructure for the network infrastructure. Maybe we can narrow down our scope to do the for the work. Okay. And any questions and comments is my presentation. Thank you.

[01:09:46] **Sheng Jiang**: Let's take questions in the minutes. Okay. Thank you. Thank you very much.

[01:10:07] **Toerless Eckert**: It would be grasped through routers, I think. It's here, I hope. Clicker and I think which one?

[01:10:27] **Sheng Jiang**: This one. Yeah. These these two back and forth. Yes. Hello, everyone.

[01:10:33] **Grasp Routers Presenter**: Today, I would like to present you a draft which I recently submitted to the work to the mailing list. It's called grasp routers. It's a problem statement. And before I dive into what's inside, I would just like to say a few words about the context because there have been a lot of questions on the mailing list about this. What we are trying to build, we are using Grasp a bit outside, I think, of the traditional use. We are trying to build a cloud environment with grasp. So we operate servers, but we usually don't have control over the network and especially the networking devices, which is a big problem for us because in grasp, you usually need the routers to be able to relay some messages, which we cannot enforce because we have no control over the networking. The routers may reside outside of different administrative domains, and we we cannot, like, ask the administrator of the network to change something. And about general environment, we operate for now ACP free, but it might evolve and the draft can also work in ACP environment. And we use a stripped down BRSKI EST architecture. So we just basically, we don't have a MASA because we we operate we have we we operate the server ourselves, so we don't really need to authorize them. So we just have a registrar. The join proxy is also left out. So very, very simple infrastructure. And so what we are experiencing, basically, is what I called in the draft a discovery problem. So negotiation can work inside of our environment because it's basically unicast, so any node can reach any other node. But since we have no control over the networking, sometimes we one node tries to discover an objective, which is on another subnet, and the router in between the two subnets has no support for grasp, so it cannot relay the discovery message. And so for that to in order to solve that, we I am proposing and draft to introduce a new kind of type of node, a new objective, which is the relay node. The idea, there are two mode of operation. So either you have a, like, subnets with a lot of nodes, and then the relay node is just one of these node. It is a normal objective. You can negotiate the relay, and it just serves so as shown on the picture below. One node would multicast as usual the discovery, which would reach the relay inside the subnet, and that relay would be either preconfigured well, not either. It would be preconfigured to know the address of the other relay, which would upon receiving the like, the first relay would send to the second one. And upon receiving, the second one will dispatch it via multicast as if it just crossed the router, which it cannot cross because of the constraint. So this is the first mode of operation, and there's a second mode of operation, which is simpler, which we want to use in our case. It's when you have subnets with a very reduced number of nodes and a large number of subnets. So in this case, introducing one relay in each subnet is maybe not the optimal solution all the time. You might want to have simply one big Relay globally, which would then forward to all of the all the like, to all of the nodes it knows. So about implementation, this is a problem statement. So we we have I have a draft implementation, which I wrote just to try and experiment, but there's no fixed like, nothing is defined about how this will work and and everything right now. So everything is still debatable. So what neck what's next? The draft is more or less ready. Many questions have been raised about the security, but since this is problem statement, I might just leave the security out of it right now and put a general statement saying, like, communication between the node and the relay should be, like, should be inside a secure environment or anything. The only security concern we have here is communication between the two relays because all of the rest is basically ACP, so there is no need to redefine the security within the subnet. And so the main question why I'm presenting this today is, I'm wondering if the working group would be interested in having such features. I saw that in the new charter, there there are some mentions about getting drafts to work through. I don't know if it's this kind of use case that you had in mind, but, anyway, I'm wondering I think I think we still have a bit of time for comments. I managed to get presentation short. So, yeah, tell tell me if you have some interest in it or some questions about it maybe.

[01:16:02] **Toerless Eckert**: Yeah. Time for one quick question or so. I think we're running now a minute before time.

[01:16:09] **Grasp Routers Presenter**: A minute. Wow.

[01:16:10] **Toerless Eckert**: Yeah. Thank you very much. I I think, you know, these these type of use case and extension of graphs to make it work across what I would call in in graphs terminology a different underlay is is perfectly fine. If if it requires the, you know, ACP free ANI that I was proposing as a draft, right, we can obviously talk about, you know, that being a good reason to adopt that as well. Right? But I'll I'll have to go back and and and see kind of what I think overall of the quality in terms of adoption. Right? But, otherwise, I I think please make sure that you have people that review the document. Mhmm. Right? I mean, look at the phases here. Reach out to them individually kind of if you're interested like any any any of the other new proposals. Right? So only to vet the interest in the working group for that, and and then we can go forward. Right? So let's just keep the discussion on the list alive so that we can get to an adoption call.

[01:17:16] **Grasp Routers Presenter**: So yeah. So maybe I'm not so familiar. How does it like, when should I call for adoption?

[01:17:21] **Toerless Eckert**: So I I I think the the the main point would be to to to see some explicit feedback in terms of people have reviewed that and find it interesting. Right? So I haven't been able to check all the mails. I think some some people like Brian or so may have completely reviewed it. Right? I think we had our last

[01:17:38] **Grasp Routers Presenter**: I think I think Michael had a look at it also. Yeah. So he's not listening.

[01:17:45] **Toerless Eckert**: Yeah. Yeah. Your pictures. Yeah. So and and and I I need to put in all the stuff we talked about it kind of a little while ago, so I had too much other stuff. So now it's just we we just need to get organized on the mailing list again to basically get towards an adoption call.

[01:18:04] **Sheng Jiang**: Okay.

[01:18:04] **Grasp Routers Presenter**: Thank you.

[01:18:05] **Toerless Eckert**: And and, you know, whenever that takes longer than you think, there's always, you know, animal chairs kind of always, you know, people wanting to do good stuff kind of can always kick the backs of of of the chairs to make sure that that it's driven forward.

[01:18:19] **Esko Dijk**: Yeah.

[01:18:19] **Grasp Routers Presenter**: Yeah. We'll write to you in a few weeks if you have not reviewed it. Exactly.

[01:18:23] **Toerless Eckert**: Yeah. Okay. So let me see. So I think you have, I think, two presentations. Or five minutes together. Yeah. Ten ten minutes together at most. I think that's what we have left.

[01:18:47] **Chao Zhou**: Okay.

[01:18:49] **Toerless Eckert**: Or eight use cases.

[01:18:53] **Chao Zhou**: Hello. Hello, everyone. My name is Chow Shao, and my topic today is network animation for of AI agent instances. This is the current situations here. So the agents call in internal resources to us and also external resources. But as a view of the network, it cannot identify who which the agent is. And, also, the current the current authorization and authentication schemes are also happens in app application layer. So the network admission adds early control boundary and application author authorization remains the same way. So here is the problem. So one IP address can represent multiple security subjects in this scenario that you can see there are three agents and other processes running on the same IP address of the same devices, but the network cannot attribute traffic to a specific agent instance. So here is the current model, which is the first step is the network which should which are availability, and the second is agent authentication, and the third is the service authorization. But, currently, the application layer authorization is not enough because the network is already exposed before the application decides this. And so this is another scenario that several agent shared the the same gateway, and the gateway may tear apart the one complete TLS connection into two parts. The first part is connect established between the agent and the net and the gateway, and the second part is established between the gateway and the external services. So at this point, the gateway must preserve protected per agent contents for every request. And this is the missing functions verifiable agent binding, so I will not give a detail of this page. So here is our functional model verifying, bound, and enforced. First one is the agent instance and plus evidence. We bound them together. And the second is the network admission function, and third one is the network enforcement point. So I will not expand on this page because I don't have much time. So let's take the next slide, please.

[01:21:36] **Toerless Eckert**: Next slide, please?

[01:21:37] **Grasp Routers Presenter**: Yes.

[01:21:53] **Chao Zhou**: So in the previous slide, we talked about the network identification and the network admin admission. So in this slide, we will talk about the access control, which is the scope down access control. So this is the same similar scenario that the autonomous agents break traditional authorization assumptions. So in this scenario that multiple agents access to the network through the gateway, and through the gateway, we access the multiple services. But the agents dynamically select targets and tools across services, so we cannot guarantee or we cannot know in advance which services which service or which agent that we the previous agent want to access. And the deployment security needs agent recognition plus tax bound scope enforcement. So here is the previous scenario that multiple agent and other process running on the same IP addresses. But this risk but in this scenario that per agent has its own task, and each task request different privileges and different authorization scope. So but the network cannot see each of them. And in the network, we'll be just can see a shared attachment context, not the agent's task. So this is the target model. The first step is to identify identify the agent traffic, and then the second is to evaluate task policy, and the third step is to enforce a scope down. So what if a scope down is to combine the basic privileges of agent and is task intended like like the intent based scope? So we get the intersection of these two scope, so we call it scope down. So in one sentence, only the privilege required for this task can be enforcement. So this is the two scenario. The first is the cap enterprise, and then the second is home network. So both of these two scenarios require the network to identify the agent first and then to enforce the task based measurement of the network. So there is a common issue because network identity is too broad too broad for the agent I run workloads. So this tells the same story, and this is the architecture to identify, to reduce, and to reinforce. This is the three deployed models, but we although they differ in Magnumium, but each must ensure that agent privilege are only narrows. So this is the security and price requirements bound to the designment. So this is the draft problem statement draft, so there will not be a concrete solution. So that's the of these two slides.

[01:25:22] **Sheng Jiang**: Thank you. Okay. Yeah. Thank you. Thank you.

[01:25:25] **Toerless Eckert**: Any questions here?

[01:25:31] **Sheng Jiang**: We'll finish, Harry. Well,

[01:25:36] **Toerless Eckert**: you've got five minutes to finish the session if we have no other questions standing out.

[01:25:43] **Sheng Jiang**: Do want to do some?

[01:25:46] **Toerless Eckert**: No. I'll leave it to you. I'm opening your finishing.

[01:25:54] **Sheng Jiang**: Actually, you know, we are not we expect we can finish earlier because we we have many new proposals, each of them has a lot of detail. But thanks for speakers to jump through those details. I think, you know, this meeting could be something, you know, kind of turning point for group because we are almost complete, you know, our autonomic networks infrastructure components, particularly for Brassky, which will take us much longer than we thought. But we reached the time we can, you know, be more open to new works, and we believe annual working group has creates very good foundation for, you know, network management or network operating functions to be in the world. That's including the agents network agents we may call. And, you know, actually, earlier, we received very little proposals regarding to the autonomous service agent because, you know, it seems it's a concept too advanced. People don't know how to really realize it. But now it seems the AI stuff actually powered, you know, these possibilities. And we can see, you know, no matter the the neural network algorithms or the language models. They they can help, you know, those agents to be easier for between the human operator and the net network configurations. So we are hope we can get more also, more input from the in dashboard on how to use the AI powered agent to management our network. And but by saying so, we still remains, you know, what we should do here is on two points. First, we would like to see those new network agents utilize our matured automaker network infrastructure components as much as possible. I didn't mean we have to stack on it, but we hope that's matured protocols or technologies can benefit those new network agents use cases. And secondly, we would like to self limited us into network operation. Yeah. I mean, there are too many generic application. Most of them are, I mean, application level agent. Most of them are, you know, for human whatever the human communication. And here, as IETf, we should not cross that nine to be too generic. What we want here is still, you know, how to make the networking easier, how to make the atomic or and to our network configuration, analysis, and management. Right? Okay. Basically, I just have my five minutes. So, hopefully, see you guys next meeting. Thank you very much. Here we go. What's what's happened there? K.