+1 except that i somewhat doubt the "often" in your first sentence wrt.
networking.
but you didn't say networking, and there may be other domains where this is more
common.
For example, whenever there is an NP complete problem such as calculating an
optimum
set of loose steering path for capacity optimization in an ISP network, LLM with
probabilistic approximations of "optimum" can save a lot of time - we hope. But
i am
not even sure how much that is already used in networks.
What networking examples do you have in mind ? They might make good material
for the draft...
Cheers
Toerless
On Fri, Jul 17, 2026 at 10:00:12AM +0000, Artur Hecker wrote:
> Hi Toerless
>
>
> (Top-posting to shorten it).
>
> We are in a broad agreement here.
>
> On this bit: "Supporting better agent communication is an important topic
> that would be great for the IETF to pick up." - agreed, but we need to see
> which bit of it needs to be supported by the network/ the system between the
> agents.
>
> Two things:
> - we often used AI models in an "indirect" fashion close to what you ask for
> below. Concretely, we were using AI/ML, even RL, to select the best
> parameterization for an otherwise deterministic, flexible distributed
> mechanisms. This is close to "the best of the two worlds": you
> deterministically get a correct response regardless of how badly your AI
> model was trained + you can improve the efficiency to the optimum, including
> in situations where no closed formula / one algorithmic run optimization can
> be used. [It can be formulated a bit broader of course: instead of asking an
> LLM to solve a problem (e.g., a shortest path in a graph), constrain it to
> use the best available Tools, Symbolic Solvers, etc. (e.g. Dijkstra).]
>
> - The last part seems particularly important to me. Given that LLM/FM are
> naturally prone to errors, it would be good to point the community to the
> fact that we need not just a network OS, but precisely this protected mode OS.
>
>
> Regards
> Artur
>
>
>
>
>
>
> > -----Original Message-----
> > From: Toerless Eckert <[email protected]>
> > Sent: Friday, July 17, 2026 11:31 AM
> > To: Artur Hecker <[email protected]>
> > Cc: Brian E Carpenter <[email protected]>; draft-eckert-anima-
> > [email protected]; Anima WG <[email protected]>
> > Subject: Re: [Anima] Re: I-D Action: draft-eckert-anima-ai4an-00.txt
> >
> > Inline
> >
> > On Wed, Jul 08, 2026 at 01:22:19PM +0000, Artur Hecker wrote:
> > > Hi Brian, hi Alex, hi Toerless
> > >
> > > +1, I am also all for what you are writing there.
> > >
> > > I agree that it could be presented at DAWN or agent2agent lists/meetings.
> > However, maybe slightly differently from Brian, I think that most of the
> > current
> > efforts somehow concentrate on discovery of agents, yet I tend to see a
> > bigger
> > issue elsewhere. I do not mind discovery, but, a bit like Toerless, I fail
> > to see
> > what is so new about it, agents or not.
> >
> > Supporting better agent communication is an important topic that would be
> > great for the IETF to pick up. We did suggest aspects for it at last IETFs
> > CATALIST
> > non-WG forming BoF. I think the group that will best look into it so far is
> > DMSC,
> > not DAWN.
> >
> > > The document below essentially says: go away with the SDN controller and
> > > put
> > an LLM on top, which will auto-program the network from the high-level
> > intents
> > expressed by the owner. For this to work, the ACP, BRSKI and GRASP serve as
> > the
> > required and potentially sufficient foundation.
> >
> > More like the lowest common denominator. More would be better, but i think
> > you can't build something reliable without them. So definitely if we can't
> > agree
> > on nothing else of how to do network management with the help of agentic AI,
> > we hopefully do at least agree that it's a good opportunity to highlight the
> > importance of the ANI to do it reliably.
> >
> > > Personally, I agree with this vision, I would have loved that to happen
> > > way
> > earlier, but somehow community lost interest in that... Now, the whole story
> > about agents jump-starts the next chapter of the same story.
> >
> > Router software infrastructure is highly ossified, and even when it's being
> > re-
> > implemented, then folks who do it have no clue what they're missing out on.
> >
> > > Some remarks:
> > > - maybe instead of "heuristic" we should talk about probabilistic
> > > behaviour? As
> > per its definition, a heuristic is an approach to problem solving, which
> > might not
> > be optimal or rationalized yet good enough [cmp. Wikipedia]. I am not sure
> > LLM's answers are, in that sense, good enough, as they often turn out to be
> > awfully wrong at times. That's the reason we can't work with that in
> > critical
> > systems (yet?).
> >
> > Good point on terminology. And the core proposal of the draft effectively
> > is to
> > not let agents directly do arbitrary changes to the network directly, but
> > instead
> > let them program automation and control exhaustive testing of the automation
> > programming. All the stuff we would do without agentic AI too.
> >
> > Or said differently: Letting an AI agent directly reconfigure a network
> > every
> > router one-by-one instead of writing a program to do it is just like a human
> > doing it manually - becoming exhausted and erraneous and unpredictable when
> > it has to happen over and over.
> >
> > Obviously, we need to find good distinctions between this "LLM level
> > problem"
> > and e.g.:
> > the use of specific DNN for problems that can perfectly live with
> > probabilistic
> > solutions - such as traffic engineering.
> >
> > > - if we are serious about ACP/GRASP/BRSKI as foundation, we would need to
> > show that, even in spite of potential misjudgments by LLM or programming
> > errors done by it, ACP would always remain "the last Mohican": ACP should be
> > the last to fail, i.e. in presence of a potentially unverified programs
> > produced at
> > will by the LLM/foundation model, the ACP must act like an implementation
> > of a
> > protected mode in an OS, like an OS kernel if you will, preserving the
> > possibility
> > to repair/remove/terminate misbehaving programs. Such that we can have a
> > bunch of simple yet reliable tools on top of ACP to clean away any nonsense
> > introduced by LLM/foundation models, and, also very important, to be able to
> > isolate the effects of such programs by separating concerns and enforcing
> > "control app manifests" in a distributed system.
> >
> > Indeed. And maybe we should use the opportunity to write this up anew for
> > the
> > agentic AI crows to also come up with new better terminology. Instead of or
> > in
> > addition to ANI maybe call it the "Network wide OS kernel" - aka: more good
> > marketing suggestions more than welcome!
> >
> > Cheers
> > Toerless
> > >
> > > Regards
> > > Artur
> > >
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Brian E Carpenter <[email protected]>
> > > Sent: Monday, July 6, 2026 3:50 AM
> > > To: [email protected]; Anima WG <[email protected]>
> > > Subject: [Anima] Re: I-D Action: draft-eckert-anima-ai4an-00.txt
> > >
> > > Hi,
> > >
> > > I'm all for what you are saying in this draft, but I think you also have
> > > to address
> > it to the DAWN people and everybody working on agentic communications.
> > Look at draft-he-dawn-ipv6-agent-aware-framework, for example; it has very
> > little to do with IPv6. Maybe you should ask for a slot at the DAWN BOF?
> > (DAWN
> > = Discovery of Agents, Workloads, and Named Entities.) At least point out
> > that
> > ANIMA/GRASP has been working on discovery of agents since the dawn of time
> > (pun intended).
> > >
> > > Also, the trust boundary issue we just discussed re
> > > draft-soulard-anima-grasp-
> > router-problem-statement is going to be relevant. I see a clear clash
> > between
> > the type of trust boundary that BRSKI provides and how the agentic community
> > is looking at trust.
> > >
> > > Nit: s/autonomous/autonomic/ globally
> > >
> > > (We chose "autonomic" at the beginning of ANIMA, by analogy with the
> > > autonomic nervous system, so I think we need to be consistent.)
> > >
> > > Regards/Ngā mihi
> > > Brian
> > >
> > > On 06-Jul-26 11:28, [email protected] wrote:
> > > > Internet-Draft draft-eckert-anima-ai4an-00.txt is now available.
> > > >
> > > > Title: AI for Autonomous Networking
> > > > Authors: Toerless Eckert
> > > > Alexander Clemm
> > > > Name: draft-eckert-anima-ai4an-00.txt
> > > > Pages: 17
> > > > Dates: 2026-07-05
> > > >
> > > > Abstract:
> > > >
> > > > This document builds on the architectural foundation of the IETF
> > > > ANIMA "Autonomous Network Infrastructure" to propose an architecture
> > > > for in-network intelligence in support of network automation.
> > > >
> > > > The key aspect of this architecture is the use of AI programmed and
> > > > validated software running decentralized on the network.
> > > >
> > > > The IETF datatracker status page for this Internet-Draft is:
> > > > https://datatracker.ietf.org/doc/draft-eckert-anima-ai4an/
> > > >
> > > > There is also an HTMLized version available at:
> > > > https://datatracker.ietf.org/doc/html/draft-eckert-anima-ai4an-00
> > > >
> > > > Internet-Drafts are also available by rsync at:
> > > > rsync.ietf.org::internet-drafts
> > > >
> > > >
> > > > _______________________________________________
> > > > I-D-Announce mailing list -- [email protected] To unsubscribe
> > > > send an email to [email protected]
> > > _______________________________________________
> > > Anima mailing list -- [email protected]
> > > To unsubscribe send an email to [email protected]
> >
> > --
> > ---
> > [email protected]
--
---
[email protected]
_______________________________________________
Anima mailing list -- [email protected]
To unsubscribe send an email to [email protected]
