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

Sat Dec 3 03:36:02 UTC 2022

Dear Mr. Beecher:

0) Thanks for your reply to close the loop.

1)    " I don't have any interest in continuing this discussion on this 
topic.":    I am quite surprised by your nearly 180 degree turn of your 
position from your last MSG. The only thing that I could think of is 
that my last MSG provided the missing information that made the 
difference. I would appreciate very much if you could confirm.

Regards,

Abe (2022-12-02 22:35 EST)

On 2022-12-01 16:34, Tom Beecher wrote:
> 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 <http://www.avast.com>
>