Alternative Re: ipv4/25s and above Re: 202211211223.AYC

Tom Beecher beecher at beecher.cc
Mon Nov 21 23:46:00 UTC 2022


>
> 1)  As requested, please be specific and speak only for yourself. So
> that we can carry on a professional dialog meaningfully.
>

I will start by citing one of my own responses to you :

https://mailman.nanog.org/pipermail/nanog/2022-March/218291.html

I do not leave a loose end to any  technical
> discussion with substance.
>

With the utmost amount of respect, you do.

Many people on this list have provided specific , technical issues with
your proposal. Others have commented on non-technical, but practical
considerations. In all cases, you have simply handwaved them away or not
commented on them further.



On Mon, Nov 21, 2022 at 5:16 PM Abraham Y. Chen <aychen at avinta.com> wrote:

> Dear Tom:
>
> 1)  As requested, please be specific and speak only for yourself. So
> that we can carry on a professional dialog meaningfully.
>
> 2) Hint: I signed up to NANOG.org only early this year. So, whatever you
> have in mind might be from somewhere else. In addition, even though I do
> not have good memory, I do not leave a loose end to any  technical
> discussion with substance. The revisions of the EzIP documentation have
> always been improving the presentation style for easing the reader's
> efforts, not about modifying our basic scheme. So, you need to be clear
> about the topics that you are referring to. Thanks.
>
> Regards,
>
>
> Abe (2022-11-21 17:16 EST)
>
>
>
> On 2022-11-21 13:23, Tom Beecher wrote:
> >
> >     1) "... for various technical reasons , ...":  Please give a couple
> >     examples, and be specific preferably using expressions that
> colleagues
> >     on this forum can understand.
> >
> >
> > Myself and multiple others provided specific technical rebuttals to
> > the proposal in the past on this list.
> >
> >
> >
> > On Mon, Nov 21, 2022 at 12:29 PM Abraham Y. Chen <aychen at avinta.com>
> > wrote:
> >
> >     Dear Tom:
> >
> >     1) "... for various technical reasons , ...":  Please give a couple
> >     examples, and be specific preferably using expressions that
> >     colleagues
> >     on this forum can understand.
> >
> >     Thanks,
> >
> >
> >     Abe (2022-11-21 12:29 EST)
> >
> >
> >
> >
> >     On 2022-11-21 10:44, Tom Beecher wrote:
> >     >
> >     >     1) "... Africa ... They don’t really have a lot of
> >     alternatives. ...":
> >     >     Actually, there is, simple and in plain sight. Please have a
> >     look
> >     >     at the
> >     >     below IETF Draft:
> >     >
> >     >
> >
> https://datatracker.ietf.org/doc/html/draft-chen-ati-adaptive-ipv4-address-space
> >     >
> >     >
> >     > For the benefit of anyone who may not understand, this is not an
> >     > 'alternative'. This is an idea that was initially proposed by the
> >     > authors almost exactly 6 years ago. It's received almost no
> >     interest
> >     > from anyone involved in internet standards, and for
> >     various technical
> >     > reasons , likely never will.
> >     >
> >     > On Fri, Nov 18, 2022 at 10:52 PM Abraham Y. Chen
> >     <aychen at avinta.com>
> >     > wrote:
> >     >
> >     >     Dear Owen:
> >     >
> >     >     1) "... Africa ... They don’t really have a lot of
> alternatives.
> >     >     ...":
> >     >     Actually, there is, simple and in plain sight. Please have a
> >     look
> >     >     at the
> >     >     below IETF Draft:
> >     >
> >     >
> >
> https://datatracker.ietf.org/doc/html/draft-chen-ati-adaptive-ipv4-address-space
> >     >
> >     >     2)  If this looks a bit too technical due to the nature of
> >     such a
> >     >     document, there is a distilled version that provides a
> >     bird-eye's
> >     >     view
> >     >     of the solution:
> >     >
> >     > https://www.avinta.com/phoenix-1/home/RevampTheInternet.pdf
> >     >
> >     >     3)  All of the above can start from making use of the 240/4
> >     >     netblock as
> >     >     a reusable (by region / country) unicast IP address
> >     resources that
> >     >     could
> >     >     be accomplished by as simple as commenting out one line of the
> >     >     existing
> >     >     network router program code. I will be glad to go into the
> >     >     specifics if
> >     >     you can bring their attention to this almost mystic topic.
> >     >
> >     >     Regards,
> >     >
> >     >
> >     >     Abe (2022-11-19 22:50 EST)
> >     >
> >     >
> >     >     On 2022-11-18 18:20, Owen DeLong via NANOG wrote:
> >     >     >
> >     >     >> On Nov 18, 2022, at 03:44, Joe Maimon
> >     <jmaimon at jmaimon.com> wrote:
> >     >     >>
> >     >     >>
> >     >     >>
> >     >     >> Mark Tinka wrote:
> >     >     >>>
> >     >     >>> On 11/17/22 19:55, Joe Maimon wrote:
> >     >     >>>
> >     >     >>>> You could instead use a /31.
> >     >     >>> We could, but many of our DIA customers have all manner of
> >     >     CPE's that may or may not support this. Having unique
> >     designs per
> >     >     customer does not scale well.
> >     >     >> its almost 2023. /31 support is easily mandatory. You should
> >     >     make it mandatory.
> >     >     > Much of Africa in 2023 runs on what the US put into the
> resale
> >     >     market in the late 1990s, tragically.
> >     >     >
> >     >     >> Its 2023, your folk should be able to handle addressing more
> >     >     advanced than from the 90s. And your betting the future on
> IPv6?
> >     >     > They don’t really have a lot of alternatives.
> >     >     >
> >     >     >>> To be honest, we'll keep using IPv4 for as long as we
> >     have it,
> >     >     and for as long as we can get it from AFRINIC. But it's not
> >     where
> >     >     we are betting the farm - that is for IPv6.
> >     >     > And yet you wonder why I consider AFRINIC’s artificial
> >     extension
> >     >     of the free pool through draconian austerity measures to be a
> >     >     global problem?
> >     >     >
> >     >     >> Its on Afrinic to try and preserve their pool if they wish
> to
> >     >     by doing things such as getting it across that progress in
> >     >     addressing efficiency is an important consideration in
> >     fulfilling
> >     >     requests for additional resources.
> >     >     > Instead of this, they’re mostly ignoring policy, implementing
> >     >     draconian restrictions on people getting space from the free
> >     pool,
> >     >     and buying into various forms of reality avoidance.
> >     >     >
> >     >     >> But see the crux above. If your RiR isnt frowning on such
> >     >     behavior then its poor strategy to implement it.
> >     >     > So far, AFRINIC has given a complete pass to Tinka’s
> >     >     organization and their documented excessive unused address
> space
> >     >     despite policy that prohibits them from doing so. However,
> >     AFRINIC
> >     >     management and board seem to have extreme difficulty with
> >     reading
> >     >     their governing documents in anything resembling a logical
> >     >     interpretation.
> >     >     >
> >     >     > Owen
> >     >     >
> >     >
> >     >
> >     >     --
> >     >     This email has been checked for viruses by Avast antivirus
> >     software.
> >     > www.avast.com <http://www.avast.com> <http://www.avast.com>
> >     >
> >
>
>
> --
> This email has been checked for viruses by Avast antivirus software.
> www.avast.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20221121/c0dd079c/attachment.html>


More information about the NANOG mailing list