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

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Thu, 1 Oct 2020 07:32:22 +0000

Hello Brian,

I believe that we agree... notably on ULA being the right choice for ACP IMHO.

My proposal is to remove all the justification text around the choice of ULA and only have the 2 lines below in my email (so nothing about RFC 1918 at all).

Finally, I also agree with your "Frankly it's not optimal ... Case closed.)"

-éric

-----Original Message-----
From: Anima <[email-masked]> on behalf of Brian E Carpenter <[email-masked]>
Date: Wednesday, 30 September 2020 at 22:02
To: "[email-masked]" <[email-masked]>
Subject: Re: [Anima] Erik Kline's Discuss on draft-ietf-anima-autonomic-control-plane-28: (with DISCUSS and COMMENT)

    On 01-Oct-20 03:14, 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

    Logically, I agree. Frankly it's not optimal to hold up this document for a completely external point. V6OPS couldn't ever reach consensus on draft-ietf-v6ops-ula-usage-considerations so I don't think we should try to do the equivalent here in a single paragraph.

    (If you want the running code argument it's easy: distributed GRASP applications survive unplanned renumbering of the uplink because they prefer ULAs. Case closed.)

       Brian

    > 
    > -éric
    > 
    > -----Original Message-----
    > From: Anima <[email-masked]> on behalf of Toerless Eckert <[email-masked]>
    > Date: Wednesday, 30 September 2020 at 15:55
    > To: Erik Kline <[email-masked]>
    > Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, The IESG <[email-masked]>, "[email-masked]" <[email-masked]>, Sheng Jiang <[email-masked]>
    > 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-masked]
    >     https://www.ietf.org/mailman/listinfo/anima
    > 
    > _______________________________________________
    > Anima mailing list
    > [email-masked]
    > https://www.ietf.org/mailman/listinfo/anima
    > 

    _______________________________________________
    Anima mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/anima

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 1 Oct 2020 13:06:51 +0200

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

-- 
---
[email-masked]

---

From: Erik Kline <[email-masked]>
Date: Wed, 7 Oct 2020 17:07:32 -0700

I've read the text in -29, and I do think it's much better.  Thank you.
The "counterpart" sentence is followed immediately by "There are important
differences", and maybe that's good enough.  (Still concerned about this
one sentence being taken out of context, but I'll just have to remain
vigilant and point out the missing context if/when I see such things).
Thank you.

Cleared my discuss.  Thanks for your patience and effort!

On Thu, Oct 1, 2020 at 4:06 AM Toerless Eckert <[email-masked]> wrote:

> > Cc: "[email-masked]" <[email-masked]>, "
> [email-masked]" <
> [email-masked]>, The IESG <
> [email-masked]>, "[email-masked]" <[email-masked]>, Sheng Jiang <
> [email-masked]>
> > Subject: Re: [Anima] Erik Kline's Discuss on
> draft-ietf-anima-autonomic-control-plane-28: (with DISCUSS and COMMENT)
> >
> >     Inline
> >