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@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@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@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>
>