<div dir="ltr">Mr. Chen-<div><br></div><div>I don't have any interest in continuing this discussion on this topic. Best of luck to you. </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Dec 1, 2022 at 7:44 AM Abraham Y. Chen <<a href="mailto:aychen@avinta.com">aychen@avinta.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Dear Tom:<br>
<br>
Have not heard from you since the below MSG. Could you please let me <br>
know if you have seen it, so that we can carry on by avoiding the <br>
repeated open-loop situation with this thread?<br>
<br>
Regards,<br>
<br>
<br>
Abe (2022-12-01 07:44 EST)<br>
<br>
<br>
On 2022-11-22 23:23, Abraham Y. Chen wrote:<br>
> Dear Tom: **** Please disregard an earlier partial transmission of <br>
> this MSG, caused by operator error. ***<br>
><br>
> 1) One look at the NANOG archive that you retrieved tells me that we <br>
> are the victims of the idiosyncrasies of the eMail system. Unlike <br>
> snail mails that are slow but reliable (There was a story that USPS <br>
> found a forty years old letter stuck in one of the mail collection <br>
> boxes on Boston sidewalk and then delivered it.), eMails are fast <br>
> (Once my eMail monitoring account started to receive a long message <br>
> that I was sending out, even before it was fully sent.) but <br>
> unpredictable from time to time. Unfortunately, most of us are <br>
> conditioned with its daily behavior and do not suspect the electronic <br>
> system hiccups (As Andrew Grove once said, "It is the software, not <br>
> the hardware."). To deal with this kind of issues in none-real-time <br>
> communications, I practice a discipline, started from VM and FAX, that <br>
> I will do my best to respond within 24 hours. I encourage my <br>
> colleagues to start reminding me (either repeat the MSG or using <br>
> alternative channels, such as SkyPe - My handle is "Abraham.Y.Chen"), <br>
> if they do not hear from me after 48 hours on topics that they expect <br>
> my response. This convention prevented much of the disruptions. <br>
> Looking at your comments, I definitely would have responded back then <br>
> if I saw them. One possibility is that I was in the midst of being <br>
> overwhelmed by NANOG posting protocols, such as the digest mode, <br>
> uni-code, personal writing styles, etc. and miseed your MSG. Anyway, <br>
> allow me to try carrying on.<br>
><br>
> 2)   "...Your proposal appears to rely on a specific value in the IP <br>
> option header to create your overlay....": Not really, as soon as the <br>
> 100.64/10 netblock is replaced by the 240/4, each CG-NAT module can <br>
> serve a very large area (such as Tokyo Metro and such) that becomes <br>
> the RAN in EzIP terminology. Since each RAN is tethered from the <br>
> existing Internet core by an umbilical cord operating on one IPv4 <br>
> public address, this is like a kite floating in the sky which is the <br>
> basic building block for the overlaying EzIP Sub-Internet when they <br>
> expand wide enough to begin covering significant areas of the world. <br>
> Note that throughout this entire process, the Option Word mechanism in <br>
> the IP header does not need be used at all. (It turns out that <br>
> utilizing the CG-NAT configuration as the EzIP deployment vehicle, the <br>
> only time that the Option Word may be used is when subscribers in two <br>
> separate RANs wishing to have end-to-end communication, such as direct <br>
> private eMail exchanges.)<br>
><br>
> 3) " ... to drop any packet with an IP option set that you don't <br>
> explicitly want because a significant number of routers kick every <br>
> packet with options to CPU, ... ": Yes, this was what we were reminded <br>
> of when we started our study. However, this appears to be another <br>
> Internet myth. Dr. Chimiak of the EnIP project (see EzIP Draft's <br>
> Refernce 13) told me that his team had successfully sent packets with <br>
> Option Words. Again, even if the existing routers do knock out packs <br>
> with Option words, the overlay architecture of the RANs allows the <br>
> search for those do allow this operation. Since the use of the Option <br>
> Word turns out to be an option to superceed IPv4's capabilities, we <br>
> should treat it as a consideration for future premium services.<br>
><br>
> 4) " ...Any device that still treated 240/4 differently would need to <br>
> be updated to treat it like anything else. .. ": Yes, this applies to <br>
> regions that desire to enjoy the EzIP characteristics. Since the root <br>
> of each RAN (or sub-RAN) still appears to be one of the current CG-NAT <br>
> modules, there is no change can be detected by other CG-NAT modules. <br>
> This avoids interoperability issues during the incremental deployment.<br>
><br>
> 5) "  ...Any existing filters that dropped packets with *any* IP <br>
> option set would have to be modified to permit the ones you define for <br>
> EzIP....":  Since EzIP is not going to activate Option Words initially <br>
> for enhancing the CG-NAT, this should not be a concern. In the future, <br>
> inter-RAN communication by subscribers would use Option words. But, by <br>
> that time, finite number of backbone / gateway routers among RANs <br>
> capable of preserving Option Words would have been identified. This <br>
> approach takes advantage of the hierarchical network configuration <br>
> that CG-NAT has already been practicing implicitly.<br>
><br>
> 6) "... ( At one point in the past, one big router vendor only allowed <br>
> you to configure an ip-options filter based on the IANA defined <br>
> values, not others. ) ...": Well, you are talking about the overly <br>
> intertwined relationship between one big roouter vendor and the IANA <br>
> which is sponsored by the former. So, this is not a technical but a <br>
> "busniess" issue. We have talked with "white box" vendors. One assured <br>
> us that EzIP can be quickly activated in thier programs if customers <br>
> do ask for it.<br>
><br>
> 7) "... This is a LOT of work and time for an overlay. ...": You are <br>
> probably visualizing a complete overlay network right from the <br>
> beginning. The EzIP approach is gradual and incremental as outlined in <br>
> the above descriptions. An EzIP deployment can be as small as a <br>
> residential network because it was how we initially figured out this <br>
> solution. It is based on parties who desire to participate, case by <br>
> case. Those who don't, do not need to do anything, nor could notice <br>
> any difference. All of these turn out to be the result of the <br>
> fundametal Internet characteristics that can transmit every bit of <br>
> compatible signals. Then, a sub-group of routers can link up with <br>
> compatible nodes to form a new network on their own, which can coexist <br>
> with, yet independent of the others (such as IPv4, IPv6, ARP, other as <br>
> reported by AMS-IX).<br>
><br>
> I look forward to your thoughts,<br>
><br>
> Regards,<br>
><br>
><br>
> Abe (2022-11-22 23:22 EST)<br>
><br>
><br>
><br>
><br>
><br>
> On 2022-11-21 18:46, Tom Beecher wrote:<br>
>><br>
>> 1) As requested, please be specific and speak only for yourself. So<br>
>> that we can carry on a professional dialog meaningfully.<br>
>><br>
>><br>
>> I will start by citing one of my own responses to you :<br>
>><br>
>> <a href="https://mailman.nanog.org/pipermail/nanog/2022-March/218291.html" rel="noreferrer" target="_blank">https://mailman.nanog.org/pipermail/nanog/2022-March/218291.html</a><br>
>><br>
>> I do not leave a loose end to any  technical<br>
>> discussion with substance.<br>
>><br>
>><br>
>> With the utmost amount of respect, you do.<br>
>><br>
>> Many people on this list have provided specific , technical issues <br>
>> with your proposal. Others have commented on non-technical, but <br>
>> practical considerations. In all cases, you have simply handwaved <br>
>> them away or not commented on them further.<br>
>><br>
>><br>
>><br>
>> On Mon, Nov 21, 2022 at 5:16 PM Abraham Y. Chen <<a href="mailto:aychen@avinta.com" target="_blank">aychen@avinta.com</a>> <br>
>> wrote:<br>
>><br>
>> Dear Tom:<br>
>><br>
>> 1)  As requested, please be specific and speak only for yourself. So<br>
>> that we can carry on a professional dialog meaningfully.<br>
>><br>
>> 2) Hint: I signed up to NANOG.org only early this year. So,<br>
>> whatever you<br>
>> have in mind might be from somewhere else. In addition, even<br>
>> though I do<br>
>> not have good memory, I do not leave a loose end to any technical<br>
>> discussion with substance. The revisions of the EzIP documentation<br>
>> have<br>
>> always been improving the presentation style for easing the reader's<br>
>> efforts, not about modifying our basic scheme. So, you need to be<br>
>> clear<br>
>> about the topics that you are referring to. Thanks.<br>
>><br>
>> Regards,<br>
>><br>
>><br>
>> Abe (2022-11-21 17:16 EST)<br>
>><br>
>><br>
>><br>
>> On 2022-11-21 13:23, Tom Beecher wrote:<br>
>> ><br>
>> >     1) "... for various technical reasons , ...":  Please give a<br>
>> couple<br>
>> >     examples, and be specific preferably using expressions that<br>
>> colleagues<br>
>> >     on this forum can understand.<br>
>> ><br>
>> ><br>
>> > Myself and multiple others provided specific technical rebuttals to<br>
>> > the proposal in the past on this list.<br>
>> ><br>
>> ><br>
>> ><br>
>> > On Mon, Nov 21, 2022 at 12:29 PM Abraham Y. Chen<br>
>> <<a href="mailto:aychen@avinta.com" target="_blank">aychen@avinta.com</a>><br>
>> > wrote:<br>
>> ><br>
>> >     Dear Tom:<br>
>> ><br>
>> >     1) "... for various technical reasons , ...":  Please give a<br>
>> couple<br>
>> >     examples, and be specific preferably using expressions that<br>
>> >     colleagues<br>
>> >     on this forum can understand.<br>
>> ><br>
>> >     Thanks,<br>
>> ><br>
>> ><br>
>> >     Abe (2022-11-21 12:29 EST)<br>
>> ><br>
>> ><br>
>> ><br>
>> ><br>
>> >     On 2022-11-21 10:44, Tom Beecher wrote:<br>
>> >     ><br>
>> >     >     1) "... Africa ... They don’t really have a lot of<br>
>> >     alternatives. ...":<br>
>> >     >     Actually, there is, simple and in plain sight. Please<br>
>> have a<br>
>> >     look<br>
>> >     >     at the<br>
>> >     >     below IETF Draft:<br>
>> >     ><br>
>> >     ><br>
>> ><br>
>> <a href="https://datatracker.ietf.org/doc/html/draft-chen-ati-adaptive-ipv4-address-space" rel="noreferrer" target="_blank">https://datatracker.ietf.org/doc/html/draft-chen-ati-adaptive-ipv4-address-space</a> <br>
>><br>
>> >     ><br>
>> >     ><br>
>> >     > For the benefit of anyone who may not understand, this is<br>
>> not an<br>
>> >     > 'alternative'. This is an idea that was initially proposed<br>
>> by the<br>
>> >     > authors almost exactly 6 years ago. It's received almost no<br>
>> >     interest<br>
>> >     > from anyone involved in internet standards, and for<br>
>> >     various technical<br>
>> >     > reasons , likely never will.<br>
>> >     ><br>
><br>
<br>
<br>
-- <br>
This email has been checked for viruses by Avast antivirus software.<br>
<a href="http://www.avast.com" rel="noreferrer" target="_blank">www.avast.com</a><br>
</blockquote></div>