Mailing List Archive

Saku Ytti <saku@ytti.fi> writes:

> I absolutely HATE testing, developing and supporting IPv4+IPv6, more
> than doubling my time, adding 3rd stack would actually not increase
> cost that much, it's the 1=>2 which is fantastically expensive. And
> costs are transferred to customers.

+1

> Those who have not done _anything_ with IPv6, have done the right
> thing from business POV, they've had lowest cost, least issues and
> have had other people pay for the improvements of the stack. And even
> today, I see no business sense deploying IPv6.

The state is not static. The difference is there for any (partially)
new deployment.

Adding new access infrastructure of any sort (Fixed Wireless is the
hype...)? Why would you want to continue being stupid even if you
implemented dual-stack for all your fibre, hfc and dsl customers? You
can save a lot by dropping dual-stack complexities in PGWs and FWA CPEs,
even if we assume most of the fibre/hfc/dsl value chain is reused.



Bjørn

On Mon, 6 Sept 2021 at 10:20, Bjørn Mork <bjorn@mork.no> wrote:

> Adding new access infrastructure of any sort (Fixed Wireless is the
> hype...)? Why would you want to continue being stupid even if you
> implemented dual-stack for all your fibre, hfc and dsl customers? You
> can save a lot by dropping dual-stack complexities in PGWs and FWA CPEs,
> even if we assume most of the fibre/hfc/dsl value chain is reused.

Can you? You need to offer IPv4 anyhow and all the complexities
related to that, i.e. some stateful box. Why would I offer in addition
to that IPv6, which is not being requested by anyone. And by anyone I
mean anyone I want as customer, as those who request it, are probably
going to be expensive to support and I need to subsidise those with my
regular customers, so I'd rather not cater to those.



--
++ytti

Saku Ytti <saku@ytti.fi> writes:
> On Mon, 6 Sept 2021 at 10:20, Bjørn Mork <bjorn@mork.no> wrote:
>
>> Adding new access infrastructure of any sort (Fixed Wireless is the
>> hype...)? Why would you want to continue being stupid even if you
>> implemented dual-stack for all your fibre, hfc and dsl customers? You
>> can save a lot by dropping dual-stack complexities in PGWs and FWA CPEs,
>> even if we assume most of the fibre/hfc/dsl value chain is reused.
>
> Can you? You need to offer IPv4 anyhow and all the complexities
> related to that, i.e. some stateful box. Why would I offer in addition
> to that IPv6, which is not being requested by anyone. And by anyone I
> mean anyone I want as customer, as those who request it, are probably
> going to be expensive to support and I need to subsidise those with my
> regular customers, so I'd rather not cater to those.


Exactly. The existing dual-stack deployments will die out as access
infra-structure is replaced.



Bjørn

All this is resolved using IPv6-only and IPv4aaS, the same way as cellular providers are doing with 464XLAT.

This means you don't need to invest in more IPv4 addressses (at some point you can even transfer some of them to the laggers), you still provide IPv4 service to the edge, but the access is IPv4-ignorant.

Reduced Capex and Opex in general.


?El 6/9/21 9:29, "NANOG en nombre de Saku Ytti" <nanog-bounces+jordi.palet=consulintel.es@nanog.org en nombre de saku@ytti.fi> escribió:

On Mon, 6 Sept 2021 at 10:20, Bjørn Mork <bjorn@mork.no> wrote:

> Adding new access infrastructure of any sort (Fixed Wireless is the
> hype...)? Why would you want to continue being stupid even if you
> implemented dual-stack for all your fibre, hfc and dsl customers? You
> can save a lot by dropping dual-stack complexities in PGWs and FWA CPEs,
> even if we assume most of the fibre/hfc/dsl value chain is reused.

Can you? You need to offer IPv4 anyhow and all the complexities
related to that, i.e. some stateful box. Why would I offer in addition
to that IPv6, which is not being requested by anyone. And by anyone I
mean anyone I want as customer, as those who request it, are probably
going to be expensive to support and I need to subsidise those with my
regular customers, so I'd rather not cater to those.



--
++ytti



**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

On Mon, 6 Sept 2021 at 10:48, JORDI PALET MARTINEZ via NANOG
<nanog@nanog.org> wrote:

> Reduced Capex and Opex in general.

Can you show the work?

--
++ytti

It is simple, most of your traffic will use IPv6. Depending on your network/customer base 65-85%.

You need less and less IPv4 addresses in the NAT64, less NAT64 boxes.

Less resources to operate IPv6-only vs dual-stack.

And because the IPv6 traffic is going up more and more with the time, you can keep reducing IPv4 addresses and NAT64 boxes. If you are using boxes that can be used for other functionalities, you even "recover" part of you initial investment.



?El 6/9/21 10:06, "Saku Ytti" <saku@ytti.fi> escribió:

On Mon, 6 Sept 2021 at 10:48, JORDI PALET MARTINEZ via NANOG
<nanog@nanog.org> wrote:

> Reduced Capex and Opex in general.

Can you show the work?

--
++ytti



**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

Grant Taylor via NANOG <nanog@nanog.org> writes:

> Hi Toke,
>
> On 9/5/21 3:07 PM, Toke Høiland-Jørgensen via NANOG wrote:
>> Well, that's what I used to do back when I didn't have native v6 and
>> ran into this issue: block v6 at the DNS level. I.e., simply filter
>> out all AAAA records for offending service providers. Pretty simple
>> to setup on your home router (it's usually one or a few TLDs per
>> service provider).
>
> I agree that it's not hard to disable AAAA resolution for ... obstinate
> domains. However, as you say, doing so means breaking DNSSEC more and
> more often. Of course it's possible to do that, but it's now a second
> thing that's being done per obstinate domain. :-(
>
> I've considered null routing / rejecting IPv6 traffic to prefixes
> associated with the obstinate domains, but that's not really a set it
> and forget it thing. Especially if ~> when the obstinate domains use
> shared hosting thus bring collateral damage into the mix. And yet
> another (3rd) hack ~> workaround. :-(
>
>> It does fail if your clients do DNSSEC validation, but if you do that
>> at the router (or not at all) it should just work :)
>
> Ya. I've been doing the DNSSEC validation on the LAN local recursive
> DNS server for this reason.

Yup, me too :)

>> And yeah, it's an ugly hack that really shouldn't be necessary,
>
> Yep. How many ugly hacks does it take before one starts questioning if
> said ugly hack(s) is (are) the proper thing to do?

Well, I come from a software background, so in my world the whole thing
is held together by duct tape and string anyway ;)

And while I can agree in principle, the nice thing about hacks is that
you can actually get those to *work*, whereas tilting at windmills to
get providers to do the right thing is much harder. So ideally you could
do both: deploy the hack(s) while waiting to get the proper fix deployed
a decade or two from now...

>> but I found it worked quite well back when I used it (a handful of
>> years ago or so), and it keeps IPv6 active and working for everything
>> else...
>
> If you're willing to (break) deal with DNSSEC, yes it does work.
>
>> Another solution that I've used on occasion is to do your own
>> tunnelling: find a hosting provider that can provide you a VPS
>> with a v6 prefix and do your own tunnelling to that. This works by
>> virtue of being "under the radar" of the service providers that do
>> this kind of broken filtering, providing you can find a VPS provider
>> whose prefixes are not blacklisted for some other reason (like being
>> non-residential or something).
>
> The operative phrase being "find a VPS provider whose prefixes are not
> blacklisted". :-/
>
> The workaround ~> hack is becoming more and more problematic year after
> year.

Yeah, I do realise that that particular workaround probably has (had?)
an expiry date :(

-Toke

JORDI PALET MARTINEZ via NANOG <nanog@nanog.org> writes:

> All this is resolved using IPv6-only and IPv4aaS, the same way as
> cellular providers are doing with 464XLAT.

Sure, there are a gazillion ways to provde edge access to both IPv4 and
IPv6. You can pick anyone you like. But the extra layers still do not
come for free.

And cellular providers give you a single /64. Not even useful as IPv6
access for anything larger than a single handset. Extending that /64 to
something you can use is non-trivial. How many providers have actually
done that?

And how many end users cared?




Bjørn

JORDI PALET MARTINEZ via NANOG <nanog@nanog.org> writes:

> It is simple, most of your traffic will use IPv6. Depending on your
> network/customer base 65-85%.
>
> You need less and less IPv4 addresses in the NAT64, less NAT64 boxes.
>
> Less resources to operate IPv6-only vs dual-stack.
>
> And because the IPv6 traffic is going up more and more with the time,
> you can keep reducing IPv4 addresses and NAT64 boxes. If you are using
> boxes that can be used for other functionalities, you even "recover"
> part of you initial investment.

You're assuming that IPv6 is required. There is no reason do do that in
the current Internet. IPv6 is still optional. The number of users who
care about IPv6 access is very close to 0 and dropping.

And as demonstrated in this thread: Even the few who still do care are
not willing to pay extra, or sacrifice anything, for IPv6. They will
run off to your competitor as soon as they discover the price is lower
there. Which it will be since they saved a lot by building and running
an IPv4 only access network.



Bjørn

* bjorn@mork.no (Bjørn Mork) [Mon 06 Sep 2021, 15:08 CEST]:
>And as demonstrated in this thread: Even the few who still do care
>are not willing to pay extra, or sacrifice anything, for IPv6. They
>will run off to your competitor as soon as they discover the price
>is lower there. Which it will be since they saved a lot by building
>and running an IPv4 only access network.

Is that why cable operators are shifting to native IPv6 + CGNAT for
IPv4 instead of following your advice to build only native IPv4?


-- Niels.

Given that, with NAT, IPv4 address space will last forever and
that people still insisting on IPv6 requires NAT, there is no
point to deploy IPv6.

Even for architectural purity, NAT44 can, but NAT46 and NAT64
can't, be improved to have the end to end transparency.

Masataka Ohta

On 9/6/21 5:04 AM, Toke Høiland-Jørgensen via NANOG wrote:
> Well, I come from a software background, so in my world the whole
> thing is held together by duct tape and string anyway ;)

Don't forget bailing wire.

> And while I can agree in principle, the nice thing about hacks is that
> you can actually get those to *work*, whereas tilting at windmills to
> get providers to do the right thing is much harder. So ideally you
> could do both: deploy the hack(s) while waiting to get the proper
> fix deployed a decade or two from now...

Yes, it's usually possible to get one or more hacks to work well enough
to achieve the desired immediate goal -- $NextStreamingService to work
on $SignificantOthersDevice.

But, how much time and effort ins required for each
$NextStreamingService that comes down the pipe and the associated
ill-will of $SignificantOther?

> Yeah, I do realise that that particular workaround probably has (had?)
> an expiry date :(

When is the proper time to give up on hacks and take one, relatively
simple, step backwards to avoid all subsequent time / effort / ill-will?



--
Grant. . . .
unix || die

Users don't care about IP at all.

They just want to make sure that their apps keep working.

If you switch them to IPv6, and they have faster access for IPv6 enables sites and apps (40% faster time to complete HTTP get), and they don't notice that the WAN is IPv6-only, because inside the LANs they still have dual-stack, problem solved.


?El 6/9/21 15:08, "NANOG en nombre de Bjørn Mork" <nanog-bounces+jordi.palet=consulintel.es@nanog.org en nombre de bjorn@mork.no> escribió:

JORDI PALET MARTINEZ via NANOG <nanog@nanog.org> writes:

> It is simple, most of your traffic will use IPv6. Depending on your
> network/customer base 65-85%.
>
> You need less and less IPv4 addresses in the NAT64, less NAT64 boxes.
>
> Less resources to operate IPv6-only vs dual-stack.
>
> And because the IPv6 traffic is going up more and more with the time,
> you can keep reducing IPv4 addresses and NAT64 boxes. If you are using
> boxes that can be used for other functionalities, you even "recover"
> part of you initial investment.

You're assuming that IPv6 is required. There is no reason do do that in
the current Internet. IPv6 is still optional. The number of users who
care about IPv6 access is very close to 0 and dropping.

And as demonstrated in this thread: Even the few who still do care are
not willing to pay extra, or sacrifice anything, for IPv6. They will
run off to your competitor as soon as they discover the price is lower
there. Which it will be since they saved a lot by building and running
an IPv4 only access network.



Bjørn



**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

You're confusing things.

The fact that cellular providers, actually cellular equipment vendors, do not implement DHCPv6-PD, doesn't mean that you can't use DHCPv6-PD for assigning IPv6 prefixes using 464XLAT in broadband.

See RFC8585 and RFC8683.


?El 6/9/21 14:56, "NANOG en nombre de Bjørn Mork" <nanog-bounces+jordi.palet=consulintel.es@nanog.org en nombre de bjorn@mork.no> escribió:

JORDI PALET MARTINEZ via NANOG <nanog@nanog.org> writes:

> All this is resolved using IPv6-only and IPv4aaS, the same way as
> cellular providers are doing with 464XLAT.

Sure, there are a gazillion ways to provde edge access to both IPv4 and
IPv6. You can pick anyone you like. But the extra layers still do not
come for free.

And cellular providers give you a single /64. Not even useful as IPv6
access for anything larger than a single handset. Extending that /64 to
something you can use is non-trivial. How many providers have actually
done that?

And how many end users cared?




Bjørn



**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

On Mon, Sep 6, 2021 at 2:55 PM Bjørn Mork <bjorn@mork.no> wrote:

> And cellular providers give you a single /64. Not even useful as IPv6
> access for anything larger than a single handset. Extending that /64 to
> something you can use is non-trivial. How many providers have actually
> done that?
>

I am sitting here on a 4G broadband connection provided by the
cellular provider "3". I am using the Huawei B535-232 CPE provided to me by
"3" as part of the contract. My IPv6 configuration, which I
received completely automatic without having to do anything or even know
about it:

Router IPv6: 2a02:aa7:4620:e76b:5a02:3ff:fe04:506
My computer connected through a LAN cable to the
router: 2a02:aa7:4620:e76b:1870:3bef:4272:5
My android cell phone connected via wifi:
2a02:aa7:4620:e76b:d199:f9b2:7103:3a05

As should be obvious the /64 provided extends to something larger than a
single handset here in a completely trivial way. The CPE is simply bridging
the /64 provided.

Yes I would be more happy with a prefix delegation of some size but this
works too. It is still better than the IPv4 which has to go through NAT.

Regards,

Baldur

Grant Taylor via NANOG <nanog@nanog.org> writes:

> On 9/6/21 5:04 AM, Toke Høiland-Jørgensen via NANOG wrote:
>> Well, I come from a software background, so in my world the whole
>> thing is held together by duct tape and string anyway ;)
>
> Don't forget bailing wire.

Heh, true, although I think the baling wire-to-string ratio tends to be
a bit higher in the US than over here in Europe :)

>> And while I can agree in principle, the nice thing about hacks is that
>> you can actually get those to *work*, whereas tilting at windmills to
>> get providers to do the right thing is much harder. So ideally you
>> could do both: deploy the hack(s) while waiting to get the proper
>> fix deployed a decade or two from now...
>
> Yes, it's usually possible to get one or more hacks to work well enough
> to achieve the desired immediate goal -- $NextStreamingService to work
> on $SignificantOthersDevice.
>
> But, how much time and effort ins required for each
> $NextStreamingService that comes down the pipe and the associated
> ill-will of $SignificantOther?
>
>> Yeah, I do realise that that particular workaround probably has (had?)
>> an expiry date :(
>
> When is the proper time to give up on hacks and take one, relatively
> simple, step backwards to avoid all subsequent time / effort /
> ill-will?

Well, this is more a question for the philosophy department I'd say... :)

-Toke

On Mon, Sep 06, 2021 at 08:38:44AM +0200, Xavier Beaudouin via NANOG wrote:
> Hello,
>
>
> > I absolutely HATE testing, developing and supporting IPv4+IPv6, more
> > than doubling my time, adding 3rd stack would actually not increase
> > cost that much, it's the 1=>2 which is fantastically expensive. And
> > costs are transferred to customers.
>
> Dual stack is doubling dev time ? Ok... this is quite strange...

Nope, entirely normal and expected. Coding for one case is very
straightforward:

Do thing
Do other thing
Do this as well

Coding for two cases involves identifying each step which needs to be done
differently for the two cases and coding up the things to be done
differently:

if case1:
Do thing this way
elif case2:
Do same thing this other way
Do other thing the same way regardless
if case1:
Do this as well
elif case2:
Don't do anything

Adding a third case is *usually* not as hard, as you've identified at least
most of the places that need to be done differently for different cases, and
if you're lucky then some of the doings can be the same both ways:

if case1:
Do thing this way
elif case2:
Do same thing this other way
elif case3:
Do same thing in *yet another* way
Do other thing the same way for everyone
if case1 or case3:
Do this as well
elif case2:
Don't do anything

It's not just program control flow either; there's also data structures and
data storage to think of. That can end up being even *more* complicated
than the control flow, especially if you're interoperating with other
systems that need to consume the same data.

For example, in the IPAM software world, imagine you named a field
"ip_address", that contains an IPv4 address, and now you want to add IPv6.
But that database is also used by some other software (that you might not
even control), so you can't just rename it to "ipv4_address" and change all
the references in your code. Do you add "ipv6_address" and hope that
everyone figures out that "ip_address" *means* "ipv4_address"? What about
in the future, when you have the first device that is IPv6-only... what
goes into that "ip_address" field?

- Matt

this amazing thread is so new, fresh, and enlightening. why has no one
brought these facts and ideas up before? just wow!

randy

Regulatory enforcement by whom? Last I knew there wasn’t a world wide Internet regulatory body.



> On Sep 6, 2021, at 2:33 AM, Saku Ytti <saku@ytti.fi> wrote:
>
> ?On Sun, 5 Sept 2021 at 19:22, Bjørn Mork <bjorn@mork.no> wrote:
>
>> So where does that put us in a decade or two? Which protocol is
>> optional?
>
> If we don't get regulatory enforcement or voluntary commitments to
> sunset IPv4, we are doomed for dual-stack for the foreseeable future
> (decades).
> I absolutely HATE testing, developing and supporting IPv4+IPv6, more
> than doubling my time, adding 3rd stack would actually not increase
> cost that much, it's the 1=>2 which is fantastically expensive. And
> costs are transferred to customers.
> Those who have not done _anything_ with IPv6, have done the right
> thing from business POV, they've had lowest cost, least issues and
> have had other people pay for the improvements of the stack. And even
> today, I see no business sense deploying IPv6.
>
> Now if we'd know, all of our CDN, cloudyshops and tier1 will start
> dropping IPV4 at edge in 2040, this would create good business reason
> to start developing to IPv6, you'd know you need to have it, and you'd
> know you have finite window when you need to support both.
> And this is something we should commit to do, and everyone would
> benefit from the comment.
>
> --
> ++ytti

On 9/7/21 02:56, Randy Bush wrote:

> this amazing thread is so new, fresh, and enlightening. why has no one
> brought these facts and ideas up before? just wow!

Have no fear, it will refresh automatically in 2 years, again.

Mark.

> On Sep 6, 2021, at 12:27 AM, Saku Ytti <saku@ytti.fi> wrote:
>
> On Mon, 6 Sept 2021 at 10:20, Bjørn Mork <bjorn@mork.no> wrote:
>
>> Adding new access infrastructure of any sort (Fixed Wireless is the
>> hype...)? Why would you want to continue being stupid even if you
>> implemented dual-stack for all your fibre, hfc and dsl customers? You
>> can save a lot by dropping dual-stack complexities in PGWs and FWA CPEs,
>> even if we assume most of the fibre/hfc/dsl value chain is reused.
>
> Can you? You need to offer IPv4 anyhow and all the complexities
> related to that, i.e. some stateful box. Why would I offer in addition
> to that IPv6, which is not being requested by anyone. And by anyone I
> mean anyone I want as customer, as those who request it, are probably
> going to be expensive to support and I need to subsidise those with my
> regular customers, so I'd rather not cater to those.

You don’t necessarily have to carry IPv4 across your network with all the
complexities involved in that. You can do IPv4 at the edges with all IPv6
in the middle through a variety of techniques which are relatively trivial
to implement these days.

Hopefully this idea that “you need to do IPv4 anyhow” will die some day soon.

Unfortunately, nobody wants to lead because it comes with certain negative
commercial implications. Perverse incentives remain a problem.

The race is on:

Will we get IPv6 deployed before our similar failures with regard
to climate change (for amusingly similar perverse incentive reasons)
render the planet uninhabitable?

Owen

> On Sep 6, 2021, at 3:55 PM, Matt Palmer <mpalmer@hezmatt.org> wrote:
>
> On Mon, Sep 06, 2021 at 08:38:44AM +0200, Xavier Beaudouin via NANOG wrote:
>> Hello,
>>
>>
>>> I absolutely HATE testing, developing and supporting IPv4+IPv6, more
>>> than doubling my time, adding 3rd stack would actually not increase
>>> cost that much, it's the 1=>2 which is fantastically expensive. And
>>> costs are transferred to customers.
>>
>> Dual stack is doubling dev time ? Ok... this is quite strange...
>
> Nope, entirely normal and expected. Coding for one case is very
> straightforward:
>
> Do thing
> Do other thing
> Do this as well
>
> Coding for two cases involves identifying each step which needs to be done
> differently for the two cases and coding up the things to be done
> differently:
>
> if case1:
> Do thing this way
> elif case2:
> Do same thing this other way
> Do other thing the same way regardless
> if case1:
> Do this as well
> elif case2:
> Don't do anything

Sure, but most of this can be obviated with IPV6_V6ONLY=false.

From that point on, your software doesn’t need to know or care whether the connection is IPv4 or IPv6, everything looks like IPv6.

Owen

On Tue, 7 Sept 2021 at 19:51, Owen DeLong <owen@delong.com> wrote:

> Hopefully this idea that “you need to do IPv4 anyhow” will die some day soon.

Fully agreed, I just don't see the driver. But I can imagine a
different timeline where in 2000 several tier1 signed mutual binding
contracts to drop IPv4 at the edge in 2020. And no one opposed,
because 20 years before was 1980, and 20 years in the future IPv4
wont' anymore be a thing, it's clear due to exponential growth.

And we'd all be enjoying a much simplified stack and lower costs all
around (vendor, us, customers).

Why is this not possible now? Why would we not sign this mutual
agreement for 2040? Otherwise we'll be having this same discussion in
2040.

--
++ytti

On 9/8/21 08:50, Saku Ytti wrote:

> Fully agreed, I just don't see the driver. But I can imagine a
> different timeline where in 2000 several tier1 signed mutual binding
> contracts to drop IPv4 at the edge in 2020. And no one opposed,
> because 20 years before was 1980, and 20 years in the future IPv4
> wont' anymore be a thing, it's clear due to exponential growth.
>
> And we'd all be enjoying a much simplified stack and lower costs all
> around (vendor, us, customers).
>
> Why is this not possible now? Why would we not sign this mutual
> agreement for 2040? Otherwise we'll be having this same discussion in
> 2040.

I do not see why this is not possible now.

In fact, I'd go as far as saying that the proposal should be shortened
from 20 years to 10 years from today. 10 years is not unreasonable.

I'm not sure if there needs to be a separate "cabal" amongst the major
network operators that cover every corner of the world to agree to this,
as I expect more talking here on NANOG than action around this issue.
But I'd be happy to join and support such a cabal, with the backing of
my own management toward making this commitment, at least from an
African standpoint.

I know at least 3 or 4 other operators in Africa that would be willing
to commit to the same, either directly or by proxy with us.

Do we drive this through the IETF, or just have private, multi-lateral
agreements, as major operators?

I'm now just thinking of how we get this idea off the ground, and stop
talking too much.

Mark.

On Wed, 8 Sept 2021 at 10:25, Mark Tinka <mark@tinka.africa> wrote:

> Do we drive this through the IETF, or just have private, multi-lateral
> agreements, as major operators?

I have no idea, I'll ask our VP if we'd entertain such a contract and
if so what type of terms.

I imagine some website documenting who has undersigned. I also
anticipate we'd need an escape clause, like a company could go 'our
commitment will expire if these of our competitors do not commit'.
So we'd have a list of companies customers can pressure to commit in
order to put the contracts in-force.

This may be a naive suggestion, this is not an area I have experience
in. But I'll ask nonetheless.

--
++ytti