[v6ops] Re: [E] New Version Notification for draft-mishra-v6ops-variable-iids-problem-statement-01.txt

["Philipp S. Tiesel" <[e-mail]>]

Hi Daryll,

> On 28. Sep 2024, at 07:53, Daryll Swer <[e-mail]> wrote:
> 
> In the cloud, I can’t:
> - If I go with a /64 per VM at my employer, the subnetting math over all aggregation levels
>   tells me I will also need a /16.
> - If I go with a /80 per VM I could fit our whole SaaS business in a /32 …
> 
> I'm not sure what you mean by “in the cloud”, are you referring to your own in-house on-prem IaaS infrastructure, where you are the owner of both underlay and overlay networking?
> 
> If the answer is yes, then, you don't need a /16 for /64 routed to each VM over ia_pd.

First, we are talking here about a extra large use-case anyway… 
“in the cloud” means a hosting SaaS/PaaS on all continents except Antarctica, 
10+ IaaS providers (+ our own data centers)
100+ infrastructure regions
10k+ VPCs

As the workload is not evenly distributed, one would need quite some bits to fit all aggregation levels with the same numbering scheme. We have a decent address plan based on /80 per VM, but shifting it 16bits to the left would require us to burn at least one /16 or go back to IPv4 thinking in address planning.

I just want to make you aware that a /64 per VM does not work when thinking at the scale of AWS, Azure, GCP, … and given the aggregation levels they have (VPC, VNET, VM).  

AVE!
  Philipp
> 
> 
> 
> On Fri, 27 Sept 2024 at 22:00, Philipp S. Tiesel <[e-mail]> wrote:
> 
> 
> > On 19. Sep 2024, at 18:38, Gert Doering <[e-mail]> wrote:
> > 
> > Hi,
> > 
> > On Thu, Sep 19, 2024 at 04:29:31PM +0000, Jeremy Duncan wrote:
> >> Here's some basic math: the year 9,000,000:
> >> https://samsclass.info/ipv6/exhaustion-2016.htm
> > 
> > Totally missing the point.
> > 
> > (... and with ARIN starting to allocate /16 to, basically, random
> > ARIN members to are willing to pay, the top level numbers also are
> > changing)
> 
> I also watch this with worries… but by focus is not so much on end users but on cloud infrastructure.
> In the corporate/office networks, I can afford a /64 per host. 
> 
> In the cloud, I can’t:
> - If I go with a /64 per VM at my employer, the subnetting math over all aggregation levels
>   tells me I will also need a /16.
> - If I go with a /80 per VM I could fit our whole SaaS business in a /32 …
> 
> A /80 is also the PD size AWS uses for VMs and other competitors start standardising around.
> That very well fits the use case… a /64 per VNET, a /80 per VM, a /96 per container.
> 
> Having a /80 or /96 on SLAAC would make VMs on developer laptops or 
> linux-bridges in a server VM much easier to deploy, but making /96 
> the new standard for physical hosts would also completely defeat the purpose.
> 
> I guess a good rule would be: 
>  - A /64 is the smallest prefix that MUST be used across administrative boundaries.
>  - A /80 or /96 can be used in virtualised environments that belong to the same administrative domain.
> This rule could be enforced by standardising variable IIDs in a way that they SHOULD be 
> turned off by default on physical interfaces or interfaces that may cross administrative domains.  
> 
> > 
> > Gert Doering
> >        -- NetMaster
> > -- 
> > have you enabled IPv6 on something today...?
> > 
> > SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Ingo Lalla,
> >                                           Karin Schuler, Sebastian Cler
> > Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
> > D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
> > Tel: [phone]         USt-IdNr.: DE813185279
> > _______________________________________________
> > v6ops mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
> 
> AVE!
>    Philipp S. Tiesel
> 
> --  
> Philipp S. Tiesel
> https://philipp.tiesel.net/
> 
> _______________________________________________
> v6ops mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]

--  
Philipp S. Tiesel
https://philipp.tiesel.net/