Alternative Re: ipv4/25s and above Re: 202211220729.AYC
Abraham Y. Chen
aychen at avinta.com
Wed Nov 23 02:34:07 UTC 2022
Dear Tom:
1) One look at the NANOG archive that you retrieved tells me that we
are the victims of the idiosyncrasies of the eMail system. Unlike the
snail mails are slow but reliable (There was a story that USPS found a
forty years old letter stuck in one of the mail collection boxes on
Boston sidewalk and then delivered it.), eMails are fast (Once my eMail
monitoring account started to receive a long message that I was sending
out, even before it was fully sent.) but unpredictable from time to
time. Unfortunately, most of us are conditioned with the normal speed
and do not suspect the electronic system hiccups (As Andrew Grove once
said, "It is the software, not the hardware.). To deal with this kind of
issues in none-real time communication, I practice a discipline started
from VM and FAX that I will respond within 24 hours. I encourage
colleagues to start reminding me (either repeat the MSG or using
alternative channels, such as SkyPe - My handle is A"Abraham.Y.Chen"),
if they do not hear from me on topics expecting responses after 48
hours. This convention prevented much of the disruptions. Looking at
your comments, I definitely would have responded back then if I saw it.
One possibility is that I was in the middle of trying to get used to
NANOG posting protocols. I was probably overwhelmed by the digest mode,
uni-code,etc. issues. Anyway, allow me to try carry on.
2) "...Your proposal appears to rely on a specific value in the IP
option header to create your overlay....": Not really, as soon as the
100.64/10 netblock is replaced by the 240/4, each CG-NAT module can
serve a very large area (such as Tokyo Metro and such) that becomes the
RAN in EzIP terminology. Each RAN is tethered from the existing Internet
core by an umbilical core based on one IPv4 public address. This is like
a kite floating in the sky which is basic building block of the
overlaying Sub-Internet when they expand to cover the entire world.
Throughout this entire process, the Option Word mechanism in the IP head
doe not need be used at all. (It turns out that utilizing the CG-NAT
configuration as the starting point, the only time that the Option Word
may be used is when subscribers in two separate RANs wishing to have
end-to-end communication, such as direct private eMail exchanges.
On 2022-11-21 18:46, Tom Beecher wrote:
>
> 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> <http://www.avast.com>
> > >
> >
>
>
> --
> This email has been checked for viruses by Avast antivirus software.
> www.avast.com <http://www.avast.com>
>
More information about the NANOG
mailing list