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

[Ed Horley <[e-mail]>]

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 <
[e-mail]> wrote:

> 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/v6ops
> >
>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>


-- 
Ed Horley
[e-mail] | [phone]
Advancing Cloud, IoT, and Security with IPv6
https://hexabuild.io
And check out the IPv6 Buzz Podcast at
https://packetpushers.net/series/ipv6-buzz/