Subject: Re: [v6ops] About draft-horley-v6ops-expand-doc

From: Ed Horley <[email-masked]>
Date: Mon, 24 May 2021 08:01:27 -0700

Eric,
inline below

On Mon, May 24, 2021 at 12:00 AM Eric Vyncke (evyncke) <[email-masked]>
wrote:

> [Without any hat]
>
>
>
> I just saw draft-horley-v6ops-expand-doc in the tentative V6OPS agenda so,
> I read this very short IETF draft and have some quick comments:
>
>
>
>    - unsure whether V6OPS WG is the most suitable (e.g., could be INTAREA
>    or 6MAN) => it would probably end up as AD sponsored
>
> For full disclosure, I'm an IETF noob - so it was a guess which group
would be most suitable for submission. If you, Russ, Fred, and others say
it belongs somewhere else, then it belongs somewhere else. Happy to take
direction on this.

>
>    - should the status be BCP ?
>
>  I have no idea if it should be BCP so I don't have a strong opinion on
this one. If someone else has a stronger opinion let me know?

>
>    - there is a usual limitation of max 5 or 6 authors per I-D
>
> Again, don't know a lot about how many authors, etc. This idea came about
from all of us talking about how it would be useful, so we just put all of
us on it :)  It is lazy but it gives credit to everyone who helped validate
the idea.

>
>    - suggestions to the author: let’s start a discussion on the V6OPS
>    mailing list (or one above)
>
> Am I don't this right?

>
>    - unsure whether re-using the 6bone prefix is the best choice, any
>    unicast prefix out of 2000::/3 could be used
>
> I wanted to avoid doing another large block out of 2000::/3. Just felt
since 6bone was already the lowest precedence in RFC 6724 and on every
bogon and block filter already, we could do something useful with the old
space. It also means all the existing documentation, examples, blogs, etc.
out there leftover from 6bone automagically move to documentation without
the authors changing anything. Plus, I feel it is a tip of the hat to what
6bone provided to the community. I think Jim Bounds would have approved of
this, it means 6bone continues on in a way :)

>
>    - IMHO RFC 4291 should be informative
>
> Fair enough.

>
>    - references to RFC3306 & RFC3513 are never used, let’s remove them
>
> Okay, I don't see a problem with that either.

>
>    - check also all the “nits” at
>    https://www6.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-horley-v6ops-expand-doc-00.txt
>    <https://t.sidekickopen45.com/s3t/c/5/f18dQhb0S7kF8c7MqBW4T_qld2zGCwVW8Jbw_88pTn5gW1SrRY23N1wTqW56dQ0g39DXxR102?te=W3R5hFj4cm2zwW4mKLT61Jz_WCW3LD2-b3NC1nGW43SPfD3SZ90SW4fNlyL49Nl2dW4fNSkD26QkHmW4mKDs_3K9DV8W43Wg2w3zgCH0W3T4FMr3SZ3v4W49HRqW1GC2Q8W3ZVdZ34kf6R8W4cfL8H45LM68W1GznWm1G8FG-4WtF41&si=7000000000648674&pi=7f3335cd-74e6-444f-aeb7-dc6c334f4aa8>
>
> Will do.

>
>    - fix some typos: “doumenting a multi-provder”, “non-routeable » ;-)
>
> Hahahaha, no one said I could spell or do complete sentences, I had
reviewers and an editor for my book!

> Hope this helps
Yes - very much so. Thanks!

> -éric
-- 
Ed Horley
[email-masked] | (925) 876-6604

---

From: Erik Kline <[email-masked]>
Date: Wed, 2 Jun 2021 12:32:35 -0700

<no hats>

The document says that the current /32 is not big enough.  There is one
example ("doumenting [sic] a multi-provder [sic] ISP network") that was
begun but never used to motivate what size is really needed.  Right now it
basically says "/32 is too small, let's use this old /16".

I think the document probably needs to provide a rationale for what size is
actually needed.  Maybe /16 is too big -- or even too small!

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 3 Jun 2021 09:12:39 +1200

Hi Erik,

I have no skin in this game, but:

>> An example of this limitation is apparent when doumenting a multi-provder ISP network address plan.

seems like a clear motivation for something shorter than /32, since /32 is a common size for ISP allocations (see ripe-738 for example). Agreed, a 
/24 might be enough.

Alternatively, of course, if the discussion of 0200::/7 as a "lab prefix" 
went anywhere, it could also be used as a doc prefix.

Regards
   Brian Carpenter

On 03-Jun-21 07:32, Erik Kline wrote:
> <no hats>
> 
> The document says that the current /32 is not big enough.  There is one example ("doumenting [sic] a multi-provder [sic] ISP network") that was begun but never used to motivate what size is really needed.  Right now it basically says "/32 is too small, let's use this old /16".
> 
> I think the document probably needs to provide a rationale for what size is actually needed.  Maybe /16 is too big -- or even too small!
> 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Ed Horley <[email-masked]>
Date: Wed, 2 Jun 2021 14:54:31 -0700

Brian,
We (the same group that drafted the documentation prefix doc) actually
already have another draft in the works for a "lab prefix" and by some
strange convergence of fate, it was 200::/7 that we picked. We did that
before we got the email about that prefix being used for that software VPN
project, the universe can be weird sometimes. We can discuss it all more
when we submit that one shortly. But if it helps clarify, there you go. Our
goals (well, maybe I should say my goals) were:
Documentation prefix that is large enough for vendors, manufacturers,
providers, consultants, students, etc. to be able to write about use cases,
designs, operations, and other things w/o having to "borrow" in use,
reserved, or other random IPv6 network prefixes.
Have a separate lab prefix that is large enough (200::/7) for vendors (et.
al.) to build out example lab configurations and do so with the possibility
of contiguous prefix ranges (technical ULA can't do that?) to lab up route
summarization, or anything else that might require that. The goal would be
a GUA that does not have a precedence value below 40 (::/0). That prefix
would be added to filters/bogon but otherwise should behave as expected for
lab scenarios (again ULA precedence is 3, so IPv4 is preferred for
dual-stack labs) issue. Also, this allows some larger government agencies
to build out "common" labs and not have to assign specific agency GUA space
for that function.
Try to not assign GUA prefixes from allocated RIR ranges unless these are
either reserved and deprecated already.
Try to not assign GUA prefixes from IANA ranges that are held in reserve to
keep future allocations contiguous and easier for RIR's to manage later.
Try to go big on how many networks we could get so that we wouldn't have to
ask again - hope was one and done?
- Ed

On Wed, Jun 2, 2021 at 2:13 PM Brian E Carpenter <
[email-masked]> wrote:

> seems like a clear motivation for something shorter than /32, since /32 is
> a common size for ISP allocations (see ripe-738 for example). Agreed, a
> /24 might be enough.
>
> > I think the document probably needs to provide a rationale for what size
> is actually needed.  Maybe /16 is too big -- or even too small!
> >

-- 
Ed Horley
[email-masked] | (925) 876-6604
Advancing Cloud, IoT, and Security with IPv6
https://hexabuild.io
And check out the IPv6 Buzz Podcast at
https://packetpushers.net/series/ipv6-buzz/

---

From: Fred Baker <[email-masked]>
Date: Wed, 2 Jun 2021 15:42:42 -0700

> On May 24, 2021, at 8:01 AM, Ed Horley <[email-masked]> wrote:
> 
> Am I don't this right?
> 	• unsure whether re-using the 6bone prefix is the best choice, any unicast prefix out of 2000::/3 could be used

I would strongly suggest using one in the IPv6 documentation prefix (2001:db8::/32 RFC3849) unless you have an excellent reason to do otherwise.

---

From: Erik Kline <[email-masked]>
Date: Wed, 2 Jun 2021 16:31:00 -0700

On Wed, Jun 2, 2021 at 3:43 PM Fred Baker <[email-masked]> wrote:

> >       • unsure whether re-using the 6bone prefix is the best choice, any
> I would strongly suggest using one in the IPv6 documentation prefix
> (2001:db8::/32 RFC3849) unless you have an excellent reason to do otherwise.
>

This was why I was interested in "just how big do we need".  For example,
if 256 /32s are sufficient then a case might be made for expanding the doc
prefix to 2001:d00::/24 ("dee hundred is the doc block", kind of thing =).

But, again, that requires knowing how much is *really* necessary.  (In the
absurd case, we obviously can't allocate a 2nd IPv6 Internet just to
document the workings of the 1st IPv6 Internet.  :-)

---

From: Fred Baker <[email-masked]>
Date: Wed, 2 Jun 2021 23:08:56 -0700

There was a previous proposal to enlarge the documentation prefix; I don't recall the I-D. One of the arguments was that it needed to be useful to describe BGP exchanges in a multi-provider network, which would mean at minimum having something larger than a /32 for each of several networks in a worked example. I won't argue the case, but I note that it was raised.

> On Jun 2, 2021, at 4:31 PM, Erik Kline <[email-masked]> wrote:
> 
> This was why I was interested in "just how big do we need".  For example, if 256 /32s are sufficient then a case might be made for expanding the doc prefix to 2001:d00::/24 ("dee hundred is the doc block", kind of thing =).
> 
> But, again, that requires knowing how much is *really* necessary.  (In the absurd case, we obviously can't allocate a 2nd IPv6 Internet just to document the workings of the 1st IPv6 Internet.  :-)