On Mon, Sep 25, 2017 at 09:40:20AM -0400, Michael Richardson wrote:
> brian> Toerless explained elsewhere why he thinks the duplication is
> brian> needed.
>
> I read that after my email.
> I simply can't agree.
I don't think i was suggesting duplication. I was suggesting for
one document to define an extensibel objective and the other draft to
extend it.
The extensibel notation i was suggesting would also result in the
definition of a brski-enrol service name that would be useable outside
of ACP, eg: when you just use DNS-SD without ACP in some instance of BRSKI.
> >> ====== section 11
> >> This document may be considered to be updating the IPv6 addressing
> >> architecture ([RFC4291]) and/or the Unique Local IPv6 Unicast
> >> addresses ([RFC4193]) depending on how strict specific statements in
> >>
> >> I don't like this statement. Either it violates the spec, and updates
> it, or
> >> it does not. I do not think that it violates. This is not a
> multi-link
> >> subnet, this is a prefix that is not on-link.
>
> brian> As readers of the 6man list know, this has been a very contentious
> topic.
> brian> I think it's safer to duck it in the ACP draft: say what we do,
> but say
> brian> nothing about RFC4291 etc.
>
> I agree.
I can easily remove the whole section 11 from the ACP document and we can bring
it
back if/when 6man review is asking for it, no problem.
> >> It is possible, that this scheme constitutes an update to RFC4191
> >> because the same 64 bit subnet prefix is used across many ACP
> >> devices. The ACP Zone addressing Sub-Scheme is very similar to the
> >> common operational practices of assigning /128 loopback addresses to
> >> network devices from the same /48 or /64 subnet prefix.
> >>
> >> It does not. Brian? Do you concur?
>
> > Put it this way. The ACP doesn't assign ULAs using DHCPv6. It doesn't
> assign
> > them using SLAAC. It doesn't use conventionally sized /64 subnets. So
> in that
> > sense it is like RFC 6164 ("Using 127-Bit IPv6 Prefixes on Inter-Router
> Links").
> > But we don't need to apologise. As you say, we're simply assigning /128
> > addresses to (virtual) interfaces using our own scheme. And we're
> relying
> > on BCP 198 (RFC 7608) which says that routing prefixes can be any length
> > up to /128. If you want to cite anything, cite RFC 7608.
>
> Toerless, do you want text to say this?
Always happy to get text suggested, but please also with a fitting place,
especially if you do not like section 11. And then do not blame me if we
again get more and more explanatory text into standards sections ;-P (which i do
like, but which normal IETF reviewer usually bitch about).
> draft> The goal for the 8 or 16-bit addresses available to an ACP device
> in
> draft> this scheme is to assign them as required to software components,
> draft> which in autonomic networking are called ASA (Autonomic Service
>
> mcr> We are not providing 8-bit or 16-bit IIDs.
> mcr> We are providing 256 or 65536 /128 addresses which are conveniently
> mcr> aggregated for routing purposes.
Hmm... I guess you are implying but also prefer not to explicitly say:
-> If an implementation wants to pick any shorter than /127 prefix from thiss
block of addresses to assign to a subnet, then it's up to that implementation
to argue how such an implementation will fit the IPv6 architecture. The
ACP document does no require or prescribe any such approaches.
> draft> In practical terms, the ACP should be enabled to create from its /8
> draft> or /16 prefix one or more device internal virtual subnets and to
> draft> start software components connected to those virtual subnets.
>
> mcr> No, don't say this, and don't do this in practice. Create /128
> routes to LL
> mcr> address of the internal VM and configure the /128 as a loopback
> address
> mcr> inside the VM.
>
> brian> So yes, I concur with Michael.
Ok, let me see how to best deal with this all.
>
>
>
> --
> Michael Richardson <[email protected]>, Sandelman Software Works
> -= IPv6 IoT consulting =-
>
>
>
--
---
[email protected]
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
