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

[Bob Harold <[e-mail]>]

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