Re: [Anima] Erik Kline's Discuss on draft-ietf-anima-autonomic-control-plane-28: (with DISCUSS and COMMENT)

[Toerless Eckert <[e-mail]>]

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 <[e-mail]> on behalf of Toerless Eckert <[e-mail]>
> Date: Wednesday, 30 September 2020 at 15:55
> To: Erik Kline <[e-mail]>
> Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, The IESG <[e-mail]>, "[e-mail]" <[e-mail]>, Sheng Jiang <[e-mail]>
> 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
>     [e-mail]
>     https://www.ietf.org/mailman/listinfo/anima
> 

-- 
---
[e-mail]