Dear Mathew:
0) Appreciate very much for your professionalism. Technical discussions
over cyberspace like this are very challenging because the lack of
instant feedback. One person could write a long essay without knowing
that it is already off the track. Compounded with not knowing the other
person's background, knowledge, current situation, etc., it takes some
effort to zero into the essence for synchronizing the two parties. I am
glad for your patience and persistence in drilling into the topic of
your concern and pressing me for the answer. This is the only way to
move forward.
1) From what you detailed, I believe that I now know the gap between us.
What I have been describing is EzIP's proposal of enhancing CG-NAT, not
deploying a brand new network. It is implicit that everything else in
the current CG-NAT shall not be touched. That is, simply replacing
100.64/10 netblock with 240/4 netblock will complete the first and key
step of the EzIP deployment. All of the existing CG-NAT configurations
and operations that you referred to are not to be disturbed.
2) As to the "umbilical cord" versus "single point of failure",
"multi-homing" concerns, I was talking about EzIP from network
architectural point of view, which needs only one physical channel. This
does not prevent additional facilities for operational considerations
such as traffic volume, load balancing, reliability, redundancy, etc.
That is, it is implicit from the way that Pt. 1) is presented these are
not to be removed.
Hope this quick brief response brings us back on track. Let me know if
the above makes sense. Then, I will work on other topics.
Regards,
Abe (2022-11-24 04:41 EST)
On 2022-11-23 22:36, Matthew Petach wrote:
On Tue, Nov 22, 2022 at 8:26 PM Abraham Y. Chen <ayc...@avinta.com> wrote:
Dear Tom: *
[...]
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.)
Hi Abraham,
I notice you never replied to my earlier questions about EzIP deployment.
I'll assume for the moment that means my concerns were without merit, and
will leave them aside.
But in reading this new message, I find myself again rather confused.
You stated:
"Since each RAN is tethered from the existing Internet core by an
umbilical cord operating on one IPv4 public address,"
I find myself staring at that statement, and puzzling over and over again
at how multi-homing would work in the EzIP world.
Would a given ISP anycast their single global public IPv4 address
to all their upstream providers from all of their edge routers,
and simply trust stable routing in the DFZ to ensure packets arrived
at the correct ingress location to be mapped from the public internet
into the RAN?
Or do you really mean that every RAN will have one giant single point
of failure, a single uplink through which all traffic must pass in
order to
reach the DFZ public internet?
If your regional network is a housing subdivision, I can understand the
model of a single uplink connection for it; but for anything much larger,
a single uplink seems like an unsustainable model. You mention Tokyo
Metro
in your message as an example. What size single uplink do. you think
would
be sufficient to support all the users in the Tokyo Metro region? And
how
unhappy would they be if the single router their 1 public IP address
lived
on happened to have a hardware failure?
Wouldn't it be better if the proposed model built in support for
multihoming from day one, to provide a similar level of redundancy
to what is currently available on the Internet today?
Or is EzIP designed solely for small, singled-homed residential
customers, and is not intended at all for enterprise customers
who desire a more resilient level of connectivity?
As I noted in my previous message, this seems like an awful lot of
work to go through for relatively little benefit--but this may simply be
due to a lack of essential clue on my part. I would very much like to
be enlightened.
Thank you!
Matt
--
This email has been checked for viruses by Avast antivirus software.
www.avast.com