On Wed, Sep 30, 2020 at 02:14:25PM +0000, Eric Vyncke (evyncke) wrote:
> About ULA, why not simply keeping:
>
> " ULA: (Global ID prefix) A "Unique Local Address" (ULA) is an IPv6
> address in the block fc00::/7, defined in [RFC4193]."
>
> And nothing else of the existing paragraph. IMHO, there is no need to justify
> the choice
Eric: If we can not agree on a simple sentence comparing what we have in IPv6
with what we had in IPv4, we should stop writing RFCs or using IPv6.
Eliot: Thanks for the "analog" suggestion, but i think "analog" is semantically
close to "counterpoint", aka: suggesting a closer functional equivalence with
rfc1918 than there actual is, so IMHO it would not resolve Eriks concern.
Cheers
Toerless
>
> -éric
>
> ???-----Original Message-----
> From: Anima <[email protected]> on behalf of Toerless Eckert
> <[email protected]>
> Date: Wednesday, 30 September 2020 at 15:55
> To: Erik Kline <[email protected]>
> Cc: "[email protected]" <[email protected]>,
> "[email protected]"
> <[email protected]>, The IESG
> <[email protected]>, "[email protected]" <[email protected]>, Sheng Jiang
> <[email protected]>
> Subject: Re: [Anima] Erik Kline's Discuss on
> draft-ietf-anima-autonomic-control-plane-28: (with DISCUSS and COMMENT)
>
> Inline
>
> On Sun, Sep 27, 2020 at 02:52:17PM -0700, Erik Kline wrote:
> > Toerless,
> >
> > Thanks for taking the time to go through all this. Generally LGTM, but
> I
> > would like to iterate on the ULA text (nothing major).
> >
> >
> > > > [ section 2 ]
> > > >
> > > > * "It is the approximate IPv6 counterpart of the IPv4 private
> address
> > > > ([RFC1918])."
> > > >
> > > > I understand the intent but I don't think this statement is
> complete. I
> > > > think we shouldn't let this sentence out into the wild as is
> since it
> > > could
> > > > be read without any context nor even any pretense of interest in
> > > nuance.
> > > >
> > > > May I suggest:
> > > >
> > > > "It is often thought of as the approximate IPv6 counterpart of
> the IPv4
> > > > private address space ([RFC1918]), though it is in fact
> meaningfully
> > > > different in important and subtle ways [and upon which this
> document
> > > relies]."
> > >
> > > Thanks for not trying to talk me out of the comparison, which i
> > > successfully
> > > used to explain ULA to many customers. Your proposal is a bit too
> verbose
> > > for
> > > the terminoloy section, so it's now:
> > >
> > > It is often thought of as the approximate IPv6 counterpart of the IPv4
> > > private address (<xref target="RFC1918" format="default"/>). There are
> > > important differences though that are beneficial for and exploited by
> the
> > > ACP, such as the ULA Global ID prefix, which are the first 48-bits of
> a ULA
> > > address. In this document it is abbreviated as "ULA prefix".
> > >
> >
> > It's a statement of fact that this is how people unfamiliar with this
> space
> > view this space. It's apparently also a statement of fact that people
> are
> > still actively being told this. ;-)
> >
> > But I still think it's not quite right. For one, the real counterpart
> to
> > 1918 in IPv6 is the deprecated site-local prefix.
> >
> > Also, to say it's "often
> > thought of" in an IETF document implies more IETF folks think of this
> way,
> > when in reality I'm not sure that's the case.
>
> *cough* *cough*
>
> |> [ section 2 ]
> |>
> |> * "It is the approximate IPv6 counterpart of the IPv4 private address
> |> ([RFC1918])."
> |> ...
> |> May I suggest:
> |> "It is often thought of as the approximate IPv6 counterpart of the
> IPv4
> |> private address space ([RFC1918]), though it is in fact meaningfully
> |> different in important and subtle ways ...
>
> Aka: It is now your text that you would like to see revisited !
>
> > If you really want to leave this notion in (removing the sentence
> > altogether is good by me), perhaps we can wordsmith it a bit more. If I
> > may propose:
>
> How about:
>
> ULA: (Global ID prefix) A "Unique Local Address" (ULA) is an IPv6
> address in the block fc00::/7, defined in [RFC4193]. ULA is the
> IPv6 successor of the IPv4 private address space ([RFC1918]).
> ULA have important differences over IPv4 private addresses that
> are beneficial for and exploited by the ACP, such as the Locally
> Assigned Global ID prefix, which are the first 48-bits of a ULA
> address [RFC4193 section 3.2.1]. In this document this prefix is
> abbreviated as "ULA prefix".
>
> Successor is hopefully more correct word. Sure, site local prefixes
> where a successor too, but i hope i do not have to write
>
> "ULA is the (only surviving) IPv6 successor..."
>
> > OLD:
> >
> > ULA: (Global ID prefix) A "Unique Local Address" (ULA) is an IPv6
> > address in the block fc00::/7, defined in [RFC4193]. It is often
> > thought of as the approximate IPv6 counterpart of the IPv4 private
> > address ([RFC1918]). There are important differences though that
> > are beneficial for and exploited by the ACP, such as the ULA
> > Global ID prefix, which are the first 48-bits of a ULA address.
> > In this document it is abbreviated as "ULA prefix".
> >
> > NEW:
> >
> > ULA: (Global ID prefix) A "Unique Local Address" (ULA) is an IPv6
> > address in the block fc00::/7, defined in [RFC4193]. Sometimes
> > thought of as the approximate IPv6 counterpart of the IPv4 private
> > address ([RFC1918]), there are important differences that are
> > beneficial for and exploited by the ACP. In this document, the
> > "ULA prefix" refers to Locally Assigned Global ID prefixes, which
> > are the first 48-bits of the ULA address [RFC4193 section 3.2.1].
>
> Beside the counterpart wordsmithing,
> i do not like the removal of pointing out that the ULA prefix is the
> new benefit of ULA that we exploit with ACP. That was at the core of the
> explanation.
>
> > (I didn't think it was worth trying to get into the fc00::/8 vs fd00::/8
> > distinction in this glossary text.)
>
> I agree, but i do not see neither the glossary or the rest of the text
> doing that. The spec part just specifies use of fd00:/8 without
> discussion and the glossary just uses the ::/7 as thats what rfc4193 say..
> Am i missing something ?
>
> > > [ section 8.1.3 ]
> > > >
> > > > * Why is an RIO for ::/0 with a lifetime of 0 required? Doesn't it
> > > suffice
> > > > it set the default router lifetime to 0? Separately, are all
> nodes
> > > required
> > > > to be Type C?
> > >
> > > Check the new text, i hope it explains everything.
> > >
> > > Yes, type A and B do not support per-prefix auto selection of router,
> > > The lifetime of 0 is used so only Type C hosts will invalidate the
> > > default route for the ACP edge node, but not Type A/B hosts. Maybe
> there
> > > is another parameter combination that achieves this goal, but this was
> > > the easiest for me to assess/describe.
> > >
> >
> > This looks better, thank you.
> >
> > To be honest, I don't know what the point of Type A/B hosts is anymore
> (and
> > if it were possible to declare these anima deployments greenfield I
> would
> > recommend saying the default router lifetime MUST be zero in the RA
> header
> > to force clients to use a stack that works -- but that's just me).
>
> I would guess that A and B have been seen in the wild before 4191 was
> released and so the RFC was written to be inclusive. No idea.
>
> I have no idea how prevalent these types are, and the current described
> method may be a tiny bit more convoluted but seems to be more compatible.
>
> Given my deployment experience of enterprises withholding from adopting
> new network technology when it wasn't compatible with their oldest
> NMS equipment, i am a bit burned in promoting "hard cut" solutions, and
> this ben an OPS area draft instead of e.g.: RTG is a good excuse for that
> approach ;-))
>
> Cheers
> Toerless
>
> _______________________________________________
> Anima mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/anima
>
--
---
[email protected]
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
