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