Re: [IPv6] Adoption call for draft-bctb-6man-rfc6296-bis

[Ted Lemon <[e-mail]>]

Is that a use case that the IETF would recommend in a standards-track
document, though? This is my point: it's not wrong to document this. What
I'm suggesting is that we shouldn't standardize it. We should not, e.g.,
have 7084-bis recommending it. Or anything else.

On Wed, Mar 20, 2024 at 10:34 AM IPv6 <[e-mail]> wrote:

> Lack of imagination (or maybe cursed knowledge) doesn't mean it only
> solves a single problem. ;-)
>
> It also solves something of an edge case where a leaf site is numbered off
> of a core site's static address space, but needs selective local internet
> break-out for bandwidth-intensive workloads (which aren't desired to be
> backhauled through the core site).
>
> (Sorry if it sounds niche; I didn't invent this construct. -_- )
>
> - Jima
> ________________________________________
> From: ipv6 <[e-mail]> on behalf of Ted Lemon <
> [e-mail]>
> Sent: Tuesday, March 19, 2024 19:19
> To: Nick Buraglio <[e-mail]>
> Cc: IPv6 List <[e-mail]>
> Subject: Re: [IPv6] Adoption call for draft-bctb-6man-rfc6296-bis
>
> On Tue, Mar 19, 2024 at 11:32 PM Nick Buraglio <mailto:
> [e-mail]> wrote:
> Agreed, happiness should not determine success. From what I have seen
> (which is admittedly limited) moving from experimental to a "higher level"
> RFC is typically accompanied by something like a deployment status
> document, e.g. the SRv6 deployment status doc here
> https://datatracker.ietf.org/doc/html/draft-matsushima-spring-srv6-deployment-status
>
> I think it's really important  to distinguish between "this draft solves a
> problem" and "this draft solves a problem that can't be solved already" and
> "this experiment has succeed and we can promote the document to
> informational or standards-track."
>
> I think we can all agree that this draft solves a problem. I think it
> solves exactly one problem: allowing sites to keep stable internal
> addressing in the face of renumbering by ISPs and/or changing ISPs.
>
> However, this problem can be addressed the way 7084 currently solves it:
> by numbering the internal network with a stable ULA and hosting services on
> addresses within that ULA rather than on a temporary GUA provided by the
> ISP.
>
> Problems NPTV6 does not solve:
>
> * MHMP (although it solves some aspects)
> * Internal address privacy
>
> So I don't actually think this document does anything useful for the
> Internet community. I don't mind that there is a document that describes
> NPTv6, but I don't think it should be standards track or informational, and
> I don't think IETF documents should normatively reference it.
>
> Regarding experiments, at least from a scientific perspective, an
> experiment needs to have a control group. If we wanted to know whether
> NPTv6 solved the problem in an easier way than dual ULA/GUA, we would want
> to set up an experiment where some sites continued to use IPv4, some used
> NPTv6, and some used ULA/GUA. As far as I know, no such experiment has been
> done, and no such comparison has been documented.
>
> I think the presentation Paulo has just done is the most interesting, but
> what we are not seeing is an answer to the question "how's it going, what
> problems do you have, etc."
>