Re: Alternative Re: ipv4/25s and above Re: 202211240353.AYC

["Abraham Y. Chen" <aychen () avinta com>]

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