Re: Fwd: Alternative Re: ipv4/25s and above Re: 202212010732.AYC Re: 202211220729.AYC
Nothing you have said has changed my thoughts or opinions on this proposal. It still has many direct technical deficiencies , not to mention continuing to rely on a status change of 240/4, of which there is no forward movement on actually happening. I no longer have interest in continuing the conversation because you have generally replied with hand waved 'solutions' to issues pointed out by many people who know what they are talking about, and there's no reason to think that will change. So again, best of luck to you with this endeavor. On Fri, Dec 2, 2022 at 10:36 PM Abraham Y. Chen wrote: > 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 > 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 stu
Re: Fwd: Alternative Re: ipv4/25s and above Re: 202212010732.AYC Re: 202211220729.AYC
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 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
Re: Fwd: Alternative Re: ipv4/25s and above Re: 202212010732.AYC Re: 202211220729.AYC
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 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
Re: Fwd: Alternative Re: ipv4/25s and above Re: 202212010732.AYC Re: 202211220729.AYC
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" i
