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