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

[Ted Lemon <[e-mail]>]

I would appreciate it if we could discuss the merits and not the
marketability of this proposal. When the IETF publishes a standards-track
or informational document, we are indeed recommending the documented
solution.

It’s fine for you to disagree with me, but as a general principle IETF
consensus should be based on technical arguments, not marketing arguments.
Of course we want whatever we recommend to be something the market would
use, but we don’t need to solve a problem simply because the market would
buy the solution to the problem. There should be an actual problem to solve
that is not already solved by an existing standard. That’s not the case
here.

Op wo 20 mrt 2024 om 11:04 schreef IPv6 <[e-mail]>

> Ted,
>
> I don't think standardization is necessarily the implicit (or explicit?)
> endorsement that you're suggesting it is.
>
> Some vendors already offer more or less the functionality in question;
> some network operators will implement this whether or not there's a
> Standards-track RFC outlining it (assuming they're not already). Not having
> an official-ish RFC just means they might do it more poorly.
>
> Or they'll just do N:1 NAT/PAT/"NAT overload."
>
> Or they'll just announce provider-independent space from every site (this
> would be a different kind of bad).
>
> Or they'll just continue to not adopt IPv6, because it can't do the things
> to which they're accustomed on IPv4.
>
> Technical purity aside, I'd rather have the least-bad option for the
> internet at large.
>
> - Jima
>
> ________________________________________
> From: Ted Lemon <[e-mail]>
> Sent: Tuesday, March 19, 2024 7:43 PM
> To: IPv6 <[e-mail]>
> Cc: Nick Buraglio <[e-mail]>; IPv6 List <[e-mail]
> >
> Subject: Re: [IPv6] Adoption call for draft-bctb-6man-rfc6296-bis
>
> 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 <mailto:[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 <mailto:[e-mail]> on behalf of Ted Lemon <mailto:
> [e-mail]>
> Sent: Tuesday, March 19, 2024 19:19
> To: Nick Buraglio <mailto:[e-mail]>
> Cc: IPv6 List <mailto:[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: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."
>