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

[Ted Lemon <[e-mail]>]

Right. That's the multi-provider problem, not the renumbering problem.
NPTv6 doesn't fully solve the multi-provider problem. Moreover, we know how
to solve the multi-provider problem, and indeed Jen Linkova, who I would
say is highly qualified to speak on this topic, explained how to do it
today in v6ops.

On Wed, Mar 20, 2024 at 1:45 PM Brian E Carpenter <
[e-mail]> wrote:

> Ted,
>
> On 20-Mar-24 16:28, Ted Lemon wrote:
> > It will come as a shock to all, no doubt, but I read the document, and
> specifically those bits.
> >
> > The problem is not that this document doesn't solve that problem. It's
> that it is not an unsolved problem: we do not need this document to solve
> that problem.
> >
> > As Lorenzo pointed out, if you use ULAs for your internal servers, and
> also distribute whatever GUAs you get from the ISP through your network,
> you never need to renumber your infrastructure because your ISP changes
> your external GUA prefix. We don't even need to update source/dest address
> selection to deal with this: you just do not use addresses in the
> ISP-provided GUA in your configurations. So e.g. your internal DNS /only/
> publishes the ULA, never the GUA. If you give your routing infrastructure
> routable addresses, the addresses you configure are from your ULA.
> Basically precisely what you would do if you were using NPTv6—the only
> thing you change is that you also propagate the ISP-provided prefix for
> external connectivity.
> >
> > This should behave much better than NPTv6, because there isn't a weird
> transition point at the edges of your network where magic happens that is
> not seen internally.
>
> My understanding is that this is considered operationally unworkable today
> by site netops people. What I have been told about this is summarised here:
>
>
> https://github.com/becarpenter/book6/blob/main/6.%20Management%20and%20Operations/Multi-prefix%20operation.md
>
> Not being a site netops person myself, I'll say no more.
>
>     Brian
>
> >
> >
> > On Wed, Mar 20, 2024 at 1:19 PM Brian E Carpenter <
> [e-mail] <mailto:[e-mail]>> wrote:
> >
> >     On 20-Mar-24 15:08, Ted Lemon wrote:
> >      > 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.
> >
> >     Huh? While I don't think the applicability text in the draft is done
> yet, the "Address Independence" and  "NPTv6 Applicability" sections already
> describe use cases that are not otherwise satisfied.
> >
> >     RFC 8678 is worth reading at this point, and the draft should
> certainly reference it.
> >
> >          Brian
> >
> >      >
> >      > Op wo 20 mrt 2024 om 11:04 schreef IPv6 <[e-mail] <mailto:
> [e-mail]> <mailto:[e-mail] <mailto:[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] <mailto:[e-mail]>
> <mailto:[e-mail] <mailto:[e-mail]>>>
> >      >     Sent: Tuesday, March 19, 2024 7:43 PM
> >      >     To: IPv6 <[e-mail] <mailto:[e-mail]> <mailto:
> [e-mail] <mailto:[e-mail]>>>
> >      >     Cc: Nick Buraglio <[e-mail] <mailto:
> [e-mail]> <mailto:[e-mail]
> <mailto:[e-mail]>>>; IPv6 List <[e-mail] <mailto:
> [e-mail]> <mailto:[e-mail] <mailto:[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]
> <mailto:[e-mail]> <mailto:[e-mail] <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] <mailto:
> [e-mail]> <mailto:[e-mail] <mailto:
> [e-mail]>>> on behalf of Ted Lemon <mailto:[e-mail]
> <mailto:[e-mail]> <mailto:[e-mail] <mailto:
> [e-mail]>>>
> >      >     Sent: Tuesday, March 19, 2024 19:19
> >      >     To: Nick Buraglio <mailto:[e-mail]
> <mailto:[e-mail]> <mailto:[e-mail]
> <mailto:[e-mail]>>>
> >      >     Cc: IPv6 List <mailto:[e-mail] <mailto:[e-mail]>
> <mailto:[e-mail] <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
> <mailto:mailto> <mailto:mailto <mailto:mailto>>:
> [e-mail] <mailto:[e-mail]>
> <mailto:[e-mail] <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
> <
> https://datatracker.ietf.org/doc/html/draft-matsushima-spring-srv6-deployment-status>
> <
> https://datatracker.ietf.org/doc/html/draft-matsushima-spring-srv6-deployment-status
> <
> 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."
> >      >
> >      >
> >      >
> --------------------------------------------------------------------
> >      > IETF IPv6 working group mailing list
> >      > [e-mail] <mailto:[e-mail]>
> >      > Administrative Requests:
> https://www.ietf.org/mailman/listinfo/ipv6 <
> https://www.ietf.org/mailman/listinfo/ipv6>
> >      >
> --------------------------------------------------------------------
> >
>