On Thu, Nov 28, 2019 at 10:38:29AM +0100, Michael Richardson wrote:
> > I can see that for conventional management tools. I will just observe
> > that GRASP discovery doesn't need to be seeded with any well known
> > addresses (except the GRASP LL multicast address) so GRASP is completely
> > indifferent to how NOC hosts get their unicast addresses. In fact we
> > could easily create a full NOC discovery mechanism over GRASP. I built
> > a MUD Manager discovery mechanism in the hackathon yesterday, and any
> > NOC server could be discovered the same way. It's probably worth
> > re-reading RFC8368 before discussing further.
>
> We will have quite a number of convential management tools in the NOC.
> The need to be able to reach out from operator desktop to equipment with SSH
> (or gosh... telnet?) will persist into the future, and it's why we built and
> secured the ACP.
+1 - my currently hibernating drafts for NOC integration are trying to
close the most basic gaps for that.
> Many existing services will need names, and while putting ULAs into DNS might
> surprise some IPv4 operators, I think it's completely sane.
Enterprises have put rfc1918 addresses into DNS forever. Alas, it only
works with hacks because DNS does not have the concept of different
scope/zones of notes/addresses with accordingly different access
control. But those hacks are fairly standard.
> A question will be how to connect the current crop of management tools to the
> ACP. This can be done by literally connecting desktops via ACP Connect.
Right. The ACP spec defines the two most sane models to do so, but there
are a lot more options achievable through configuration alternatives.
> Another way will involve putting bastion hosts (ssh-jump-hosts) into the NOC,
> as well as hosting virtual desktops on hypervisors connected via ACP Connect.
Right.
CHeers
Toerless
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
