Fwd: Alternative Re: ipv4/25s and above Re: 202212010732.AYC Re: 202211220729.AYC

Thu Dec 1 21:34:13 UTC 2022

Mr. Chen-

I don't have any interest in continuing this discussion on this topic. Best
of luck to you.

On Thu, Dec 1, 2022 at 7:44 AM Abraham Y. Chen <aychen at avinta.com> wrote:

> Dear Tom:
>
> Have not heard from you since the below MSG. Could you please let me
> know if you have seen it, so that we can carry on by avoiding the
> repeated open-loop situation with this thread?
>
> Regards,
>
>
> Abe (2022-12-01 07:44 EST)
>
>
> On 2022-11-22 23:23, Abraham Y. Chen wrote:
> > Dear Tom: **** Please disregard an earlier partial transmission of
> > this MSG, caused by operator error. ***
> >
> > 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
> > snail mails that 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 its daily behavior 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
> > communications, I practice a discipline, started from VM and FAX, that
> > I will do my best to respond within 24 hours. I encourage my
> > colleagues to start reminding me (either repeat the MSG or using
> > alternative channels, such as SkyPe - My handle is "Abraham.Y.Chen"),
> > if they do not hear from me after 48 hours on topics that they expect
> > my response. This convention prevented much of the disruptions.
> > Looking at your comments, I definitely would have responded back then
> > if I saw them. One possibility is that I was in the midst of being
> > overwhelmed by NANOG posting protocols, such as the digest mode,
> > uni-code, personal writing styles, etc. and miseed your MSG. Anyway,
> > allow me to try carrying 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. Since each RAN is tethered from the
> > existing Internet core by an umbilical cord operating on one IPv4
> > public address, this is like a kite floating in the sky which is the
> > basic building block for the overlaying EzIP Sub-Internet when they
> > expand wide enough to begin covering significant areas of the world.
> > Note that throughout this entire process, the Option Word mechanism in
> > the IP header does not need be used at all. (It turns out that
> > utilizing the CG-NAT configuration as the EzIP deployment vehicle, 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.)
> >
> > 3) " ... to drop any packet with an IP option set that you don't
> > explicitly want because a significant number of routers kick every
> > packet with options to CPU, ... ": Yes, this was what we were reminded
> > of when we started our study. However, this appears to be another
> > Internet myth. Dr. Chimiak of the EnIP project (see EzIP Draft's
> > Refernce 13) told me that his team had successfully sent packets with
> > Option Words. Again, even if the existing routers do knock out packs
> > with Option words, the overlay architecture of the RANs allows the
> > search for those do allow this operation. Since the use of the Option
> > Word turns out to be an option to superceed IPv4's capabilities, we
> > should treat it as a consideration for future premium services.
> >
> > 4) " ...Any device that still treated 240/4 differently would need to
> > be updated to treat it like anything else. .. ": Yes, this applies to
> > regions that desire to enjoy the EzIP characteristics. Since the root
> > of each RAN (or sub-RAN) still appears to be one of the current CG-NAT
> > modules, there is no change can be detected by other CG-NAT modules.
> > This avoids interoperability issues during the incremental deployment.
> >
> > 5) "  ...Any existing filters that dropped packets with *any* IP
> > option set would have to be modified to permit the ones you define for
> > EzIP....":  Since EzIP is not going to activate Option Words initially
> > for enhancing the CG-NAT, this should not be a concern. In the future,
> > inter-RAN communication by subscribers would use Option words. But, by
> > that time, finite number of backbone / gateway routers among RANs
> > capable of preserving Option Words would have been identified. This
> > approach takes advantage of the hierarchical network configuration
> > that CG-NAT has already been practicing implicitly.
> >
> > 6) "... ( At one point in the past, one big router vendor only allowed
> > you to configure an ip-options filter based on the IANA defined
> > values, not others. ) ...": Well, you are talking about the overly
> > intertwined relationship between one big roouter vendor and the IANA
> > which is sponsored by the former. So, this is not a technical but a
> > "busniess" issue. We have talked with "white box" vendors. One assured
> > us that EzIP can be quickly activated in thier programs if customers
> > do ask for it.
> >
> > 7) "... This is a LOT of work and time for an overlay. ...": You are
> > probably visualizing a complete overlay network right from the
> > beginning. The EzIP approach is gradual and incremental as outlined in
> > the above descriptions. An EzIP deployment can be as small as a
> > residential network because it was how we initially figured out this
> > solution. It is based on parties who desire to participate, case by
> > case. Those who don't, do not need to do anything, nor could notice
> > any difference. All of these turn out to be the result of the
> > fundametal Internet characteristics that can transmit every bit of
> > compatible signals. Then, a sub-group of routers can link up with
> > compatible nodes to form a new network on their own, which can coexist
> > with, yet independent of the others (such as IPv4, IPv6, ARP, other as
> > reported by AMS-IX).
> >
> > I look forward to your thoughts,
> >
> > Regards,
> >
> >
> > Abe (2022-11-22 23:22 EST)
> >
> >
> >
> >
> >
> > 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.
> >> >     >
> >
>
>
> --
> 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/20221201/55fc37a2/attachment.html>