Re: [v6ops] WGLC for draft-ietf-v6ops-rfc3849-update-01

[Ed Horley <[e-mail]>]

I agree with the point and would prefer a reserved GUA space allocation
that IANA reserves for documentation.

If we don't want to use a reserved GUA space (using syntax that could cause
potential issues for others), we should consider my original proposal to
also have a lab prefix. See:
https://datatracker.ietf.org/doc/draft-horley-v6ops-lab/

I would prefer to have several documentation prefixes that are easily
identified as separate networks and are sufficiently large enough for
manufacturers and enterprise organizations to document lab, test, model,
and validate designs, architecture, and configurations before deployment
and potential before an allocation request.



On Mon, Dec 18, 2023 at 8:31 AM Bob Harold <[e-mail]> wrote:

> Any training that wants to show the bits and bytes will need real hex
> characters.  And a large prefix is needed in some cases.  So I would prefer
> d0c0::/12
>
> --
> Bob Harold
>
> On Mon, Dec 18, 2023 at 11:21 AM daveb <[e-mail]> wrote:
>
>> At 07:33 AM 12/18/2023, tom petch wrote:
>> >From: v6ops <[e-mail]> on behalf of Brian E Carpenter
>> ><[e-mail]>
>> >Sent: 16 December 2023 19:45
>> >On 16-Dec-23 20:49, Rob Foehl wrote:
>> > > On Fri, 2023-12-15 at 16:45 -0600, Nick Buraglio wrote:
>> > >>> Do we really want to more special address space / RFC1918-like
>> > space in IPv6?
>> > >>> If nothing else it has real operational cost. Everyone must
>> > update their edge filters.
>> > >>>
>> > >>> While I'm skeptical that more documentation space is needed.
>> > >>>
>> > >
>> > >> One critical detail is that we need to ensure whatever it is
>> > that we end up with makes it into bogon filters and other BCPs for
>> > routing security.
>> > >>
>> > >> WGLC ends today, so any further support or non-support should be
>> > voiced ASAP.
>> > >
>> > > I wasn't going to wade into this, but with the original /20 somehow
>> > > ballooning into multiple /16s or a /12...
>> > >
>> > > As a practical matter: meh.  It's a minor nuisance to have to update
>> > > prefix lists in all of the requisite places.
>> > >
>> > > As a matter of principle: completely opposed.  While it may be a minor
>> > > nuisance, the number of changes required globally does add up, and I
>> > > don't recall seeing any attempts at a cost-benefit justifying that
>> > > effort.
>> > >
>> > > Moreover, the plausible uses seem to fall into a few cases for which
>> > > practicable solutions exist:
>> > >
>> > > - Documentation of a real network: use the real prefix(es).
>> > >
>> > > - Documentation for a specialized audience, e.g. RIR justification:
>> any
>> > > arbitrary placeholder will suffice.  They'll be fine.  There's even a
>> > > TBD::/20 right there in the draft...
>> > >
>> > > - Documentation for educational purposes: again, any placeholder will
>> > > suffice, as many as deemed necessary.  ispA::/28, ispB::/24, ...
>> >
>> >I like this argument. Maybe it is worth documenting (not a joke).
>> >We could have a convention that non-hex letters are used for examples,
>> >perhaps with a default byte being wxyz. Thus 2xyz::/16 could serve
>> >as an example GUA prefix.
>> >
>> ><tp>
>> >The RFC police will not be happy with this.  Documentation values
>> >are used for documentation and using real values has caused enough
>> >damage in the past.  Using semantically impossible values e.g.
>> >omg::/16 will fail the checks when used in examples in RFC which is
>> >most RFC containing a YANG module (since the IESG pressure authors
>> >to include examples).
>> >
>> >Using semantically impossible values will require updating all the
>> >tool chains, whoever and whereever in the world they are.
>> >
>> >Tom Petch
>>
>>
>> Isn't a primary goal of YANG to create device configurations from
>> documentation?   If so then wouldn't it be more likely to see what
>> are 'documentation-only' prefixes show up in routers (emulators, lab,
>> test, even production) where those prefixes could fail anyhow,
>> requiring someone to go back and use legal values?
>>
>> Maybe a simple translator associated with the YANG model can be added
>> to convert from the arbitrary prefix(es) to the actual prefix(es)
>> getting the best of both?
>>
>> An arbitrary, or otherwise descriptive but far from real-looking
>> prefix seems to be the most clear use for documentation-only purposes.
>>
>>
>>
>>
>>
>> >See if you prefer this:
>> >
>> >
>> https://github.com/becarpenter/misc/blob/main/Multi-prefix%20operation.md
>> >
>> >to this:
>> >
>> >
>> https://github.com/becarpenter/book6/blob/main/6.%20Management%20and%20Operations/Multi-prefix%20operation.md
>> >
>> >     Brian
>> >
>> >
>> > >
>> > > The recurring theme being *documentation*, which is of course the sole
>> > > stated purpose.  The space actually being configurable in any capacity
>> > > or usable for any other purpose is at odds with at least 3849 section
>> 3
>> > > and the (somewhat self-contradictory) revised section 3 in the draft.
>> > > Any such addresses would not, by definition, be documentation; any
>> > > proposals for same, cf. mentions of lab space, ought to stand on their
>> > > own merit.
>> > >
>> > > More documentation space isn't necessary -- not from GUA space,
>> anyway.
>> > >
>> > > -Rob
>> > >
>>
> _______________________________________________
> 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/