Re: [Anima] some comments about ACP connect

[Brian E Carpenter <[e-mail]>]

On 16-Nov-19 03:20, Michael Richardson 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.
 
> It seems that we could advertise a 6.10.3 non-zero "Zone" on the NOC ACP
> Connect "LAN"?
> 
> It seems that we ought to sending a Routing Information Option for the
> /48, and a PIO for the specific /64 above.
> We might want to set L=0 here. 
> I understand that we advertise ::/0 with lifetime=0 because of RFC4191
> section 3 analysis.
> I don't know if type A,B,or C hosts are common out there, I think that
> rfc4191 is widely implemented at this point, so I suspect most hosts are
> type C at this point.
> 
> 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.

(In my code, I gave preference to ULAs over GUAs, but GRASP doesn't even
care about that).

    Brian

> I do think that they should
> listen to RAs for the ACP route so that we can have multiple routers, etc.
> *
> I will be making a few more specific recommendations in my document in
> line with the view above.
> 
> _______________________________________________
> Anima mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/anima
>