Subject: [Anima] some comments about ACP connect

From: Michael Richardson <[email-masked]>
Date: Fri, 15 Nov 2019 22:20:25 +0800

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.

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?

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 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.

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 17 Nov 2019 12:51:12 +1300

> 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.)
 
> say "51*" above the "(base scheme)"?  Is that a typo?

Huh? That is not present in the -21 draft.
 
> 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
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima
>

---

From: Toerless Eckert <[email-masked]>
Date: Sun, 17 Nov 2019 07:31:58 +0100

Thanks, Michael.

Given how i may not 100% observe the github, make sure you also send
email when oyu have proposed fixes.  Please also use the latest xml on
datatracker as the authoritative soucrce. I already missed one
github feedback from you earlier. I apologize, but i am not the
fluent github user yet.

>    but will not route the default route via it.

I can not find this particular version of the paragraph in any version.
Which version of the ACP draft is this from ?

> I will send a pull request once I finish writing.

The document is not using the term "whole" in conjunction with "ACP
prefix" and the acronym section (2.) defines "ACP (ULA) prefix(es)"
as /48 bit prefixes.

> say "51*" above the "(base scheme)"?  Is that a typo?

The 51 below the (base scheme) in 6.10.3 was fixed to 50 in revision -09.

> It seems that we could advertise a 6.10.3 non-zero "Zone" on the NOC ACP

Yes, except that you would then need to figure out how to assign fitting
/64 bit host-parts with Registrar-ID and Node-Number to non-autonomic
devices on that autonomic-connect LAN. Hence the introduction of the
Manual addressing scheme that does not have this expectation against the
/64 host part.

Aka: use the manual addressing sub-scheme. Where "manual" means
"not managed by registrars".

> We might want to set L=0 here. 

Probably faster if you spend some in-person cycles with me on those
parameters as i do not have those route advertisement details memorized
as much as you may have.

> listen to RAs for the ACP route so that we can have multiple routers, etc.

The whole idea of the text is to exactly allow for whatever host-address
part allocation people feel most comfortable with and not predicate any
preference. DHCP, SLAAC, whatever. The only thing the document tries to
say is how to ensure that hosts which are multi-homed with such an
acp-connect LAN being one of its subnets - would route all ACP
prefixes to the ACP edge node, but not a default-route.

So i hope we are in violent agreement here. If you think there is text
missing, plase suggest.

> line with the view above.

Thanks
    Toerless

---

From: Toerless Eckert <[email-masked]>
Date: Sun, 17 Nov 2019 07:38:24 +0100

> (In my code, I gave preference to ULAs over GUAs, but GRASP doesn't even

Rereading Michaels sentence again after my previous email answer,
i would lke to double down on what Brian said:

today, there is a lot of manual configuration of NOC server IP addresses
on each route for various services. The DNS-SD drafts i wrote (expired,
to be revived, when i got ACP off my back) are exactly to overcome this
problem by learning via DNS-SD (ACP GRASP as transport ;-) those NOC
host services.

Once you have this service discovery, NOC hosts do not need well-known
IP addresses anymore, but can use SLAAC, or DHCP on the ACP connect LAN
- whatever the operator prefers. Of course, ther is IMHO no need for
DHCP, but its likely that in the non-ACP part of the network, some
service parameters may still be learned from DHCP (such as DNS servers),
and i have seen few deployments that tried to combine DHCP service
discovery with SLAAC address assignment. Besides, there is also litte
address tracking with SLAAC, and operators like to be able to track
addresses. Aka: As long as we do not have stronger arguments either way,
i wouldn't get into the middle of the SLAAC vs. DHCP debate. I just
want to make sure that we do not need well-known IP addresses.

Cheers
    Toerless

---

From: Michael Richardson <[email-masked]>
Date: Mon, 18 Nov 2019 13:13:11 +0800

Toerless Eckert <[email-masked]> wrote:
    > datatracker as the authoritative soucrce. I already missed one github
    > feedback from you earlier. I apologize, but i am not the fluent github
    > user yet.

I suggest that you take the files off of github then :-)

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 19 Nov 2019 08:59:28 +0100

> I suggest that you take the files off of github then :-)

Nah, github is perfectly fine as a great storage location without
necessarily succumbing to the single-file diff-version management terror ;-)

Kidding aside:

I will improve in my skills to master this, just takes time.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 28 Nov 2019 10:38:29 +0100

> 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.

    > 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  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [