Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches **Call for Adoption**

> On 9 Jan 2020, at 20:04, Ca By <cb.list6@gmail.com> wrote:
> 
> 
> 
> 
>> On Thu, Jan 9, 2020 at 9:41 AM <otroan@employees.org> wrote:
>> >    Stateful technologies, 464XLAT and DS-Lite (and also NAT444) can
>> >    therefore be much more efficient in terms of port allocation and thus
>> >    public IP address saving.  The price is the stateful operation in the
>> >    service provider network, which allegedly does not scale up well.  It
>> >    should be noticed that in many cases, all those factors may depend on
>> >    how it is actually implemented.
>> > 
>> 
>> Not allegedly.
>> The two mechanism-types do have different scaling properties.
>> The CGN type are pets (scale with sharding + HA mechanisms), the stateless mechanisms behave like cattle. I.e. you just add more instances.
>> 
>> Cheers,
>> Ole
> 
> eh, i don’t believe there is a meaningful scaling function difference.  I don’t know the details of how MAP works, the domains and dhcp dependencies always seemed like a Rube Goldberg machine,  but for 464xlat, if you think of DNS64 being an anycast and / or PREF64 as anycast... you just add more to scale horizontally.  Yes, each NAT64 needs a unique ipv4 pool, but it’s not an artisanal craft. 
> 
> A stateful NAT44 / NAT64 can also scale beyond 65k sessions / ports per ipv4 using a full 5-tuple... so if we are talking about pushing ipv4 efficiency, this cannot be beat. 

All solutions have stateful NATs. It’s just a question if you have one, two or three (in this case one is stateless though).  In a MAP solution the CPE NAT can also operate in endpoint dependent mode. 

It will not be able to utilize the IPv4 as efficiently as the CGN solutions. 

Where the CGN solutions are hard to scale has to do with robustness. Avoiding a single point of failure requires HA solutions (session synchronization) and sharding of the state space. Whatever you think, that’s a lot harder to do than a stateless solution. I have written code for both. 

Cheers 
Ole

> 
> 
>> 
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops