Brian E Carpenter <brian.e.carpen...@gmail.com> wrote:
>> Toerless, I am preparing a document on Operational Considerations for
>> Registrars: "Operational Considerations for BRSKI Registrar"
>>
>> I was reviewing section 8.1, on ACP connect.
>>
>> To allow for auto-configuration of NMS hosts, the ACP edge device and
>> NMS hosts using ACP connect SHOULD support [RFC4191]. The ACP edge
>> device should announce the whole ACP ULA prefix via that standards
>> Router Advertisement signaling option. It should also announce the
>> default route (::/) with a lifetime of 0. In result, NMS hosts
>> supporting RFC4191 will route the ACP prefix via the ACP edge device,
>> but will not route the default route via it.
>>
>> I don't disagree with anything you say, btw.
>> I think that maybe some explanation is in order here though.
>> I recognize the document is in it's final stage, but maybe a word or two
>> could be added here.
>> First, what is the "whole ACP ULA prefix"? Is it the /48? I think we
>> could say so.
>> I will send a pull request once I finish writing.
> Assuming it does mean the /48, that's an editorial clarification.
> (If it doesn't mean that, please explain.)
>> Second, if 6.10.2 defines the base scheme, and it's 8+40+2=50, why in
>> 6.10.3 does it
>> say "51*" above the "(base scheme)"? Is that a typo?
> Huh? That is not present in the -21 draft.
I seem to have been working from what was in github in order to better
provide edits. That was a mistake I now see as the github hasn't been
maintained. I'm fixing that...
I see that the -21 text seems a bit better, and the third paragraph mentions
the /48 explicitely.
I also see that the 6.10.3 is already fixed.
>> Generally, I think that NOC hosts should not autoconfigure (SLAAC or
>> stable private address) addresses, as they ought to be manually
>> configured. I am open to discussion here.
> 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.
Many existing services will need names, and while putting ULAs into DNS might
surprise some IPv4 operators, I think it's completely sane.
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.
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.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | network architect [
] m...@sandelman.ca http://www.sandelman.ca/ | ruby on rails [
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
