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