My understanding is that when setting up a ClawdBot, that one writes a kind of manifesto to explain what it's goal is supposed to be. This document sensibly connects that to Intent Based.
A challenge that I had when deploying ACP and BRSKI components are virtual
appliances is that they... being virtual... do not come with an IDevID.
They don't even come with a sensible https certificate that could be used to
login the first time to configure them.
I have some idea how to break this logjam, and perhaps unsurprisingly, it
involves a recursive (well: two layer) application of BRSKI.
I spent some time looking at
cloud-init: could an EST/RFC7030 flow occur there?
Or could the local (cloud) infrastructure generate a keypair (private
key+certificate) and
inject that in, as many cloud-init mechanisms are inheritely one way.
(A virtual ISO file attached to the virtual CDROM interface is one such path)
The answer was mostly: yes, but the absense of any *server* side cloud-init
systems to modify was a problem. It seems that it's a problem for cloud-init
developers too!
I think that the autonomous agent workload space has a similiar problem in
that it does not clearly come with any identities, and this, again, becomes a
bootstrapping problem. An initialized (virtual) TPM is a place where it
could be solved, but that (again), involves changes to the cloud/hypervisor
infrastructure, and therefore is hard to experiment with (at scale).
{I read that ESXi has some answers, but none of them great}
} This solution is to simply set up the architecture such that the LLM
} is not making decisions in the network, but instead it is primarily
} programming the actual network automation software.
I think that this is very sensible thing to state.
We have lots of automation systems, both standardized, semi-standardized
(like: RESTCONF with vendor-specific YANG modules), and vendor-proprietary.
They is no reason for the autonomous agents to go below that level, and there
are significant safety advantages to being at this level. My experience in
building ISPs over the decades is that as the vendor-automation systems
have become better, they have demanded increasingly unreasonable amounts of
resources to operate, and they became tools of vendor lockin.
(I'd even the word "oppression")
I watched a few videos from a major vendor's annual event last year, where
they had gone all in on LLM automation, which spoke their platform
configuration language directly. Wow. I was even more afraid of that lock-in.
90% of what I think ISPs want (but their own managers never get), is good
asset management, configuration/change control with a way to consistently
deploy templates for different services. Except for the resource hog noted
above, that's were I saw things going... but the asset management was always
rather poor. https://github.com/cvicente/Netdot is still better, but maybe
it has died.
Back to the document: 3.2, Network Simulation.
If one had sufficiently good similuation environments ("digital twins"), then
one probably wouldn't need any expensive autonomous LLM stuff. Or any senior
staff.
Juniors could make mistakes and learn and the like... it's exactly where the
simulation is *inaccurate* that causes problems, and drives the ongoing need
for virtual-out-of-band access and smart people.
I thik section 3.3 is going someplace, but I'm not sure where.
--
Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
** My working hours and your working hours may be different. **
** Please do not feel obligated to reply outside your normal working hours **
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list -- [email protected] To unsubscribe send an email to [email protected]
