Thanks, Jima. I'll review the slides. Without complicating the issue, we're trying to address a number of challenges at the same time. There's no regional backhauling at this time. Each site will be reachable via the internal network but will also independently announce it's assignment to its ISP(s). There are many reasons for this model, some of which I like and others I don't! We do plan to coordinate address assignments/aggregations with the ISPs to reduce global routes and unwanted conflicts/overlap.Unfortunately, there's no real hub in each region and the ISPs are not region-specific. We inherit a bunch of stuff and then need to find a way to jam it into something that isn't completely broken... we've done a lot of cleanup and re-org of services but there's still a long way to go. IPv6 should help us get there, however. Agreed with the /48 but ARIN doesn't appear to agree with our justification for a /36 thus far. On Fri, Jul 7, 2017 at 1:33 PM, Jima <nanog@jima.us> wrote:
On 2017-07-07 11:07, Oliver O'Boyle wrote:
We would prefer to summarize at the /42 level, announced from our last-mile providers. There are 3 primary last-mile providers so this strategy would help significantly reduce the number of global routes being injected. If we split regions evenly at /42 and if we follow the /48-per-site best practice (which I believe is justifiable in our situation - see below), Region A will be at 50% usage immediately. Adding 16 more sites brings it to 75% usage in only a few years. The other regions would be at ~33% usage (Region B) and 15% usage (Region C) and will see moderate growth in 3-5 years. Cloud will initially be at 2-4% usage (Region D) but will also grow quickly within 3-5 years.
If you're backhauling each region (even effectively via your upstream), I'd take a look/listen to these two slides: https://www.youtube.com/watch? v=rWJZfShWE6g&t=12m46s (Honestly, that entire video is worth watching if you're preparing to make your initial IPv6 PI space request -- it's a very informative presentation, and is fairly authoritative.)
Net-net, if "hub 1" is supporting 30-ish sites, with projected growth to 46-ish, you could possibly make the case for allocating a /40 per hub, and a /38 (or maybe even /36) overall. (There's only one /38 assignment in ARIN region, FWIW.)
I feel the /48 site default is justifiable because of the various
applications and services that are currently, or could likely be offered at hotels.
If it's a site, /48 is justified as per ARIN requirements, period.
I think the ideal situation is out as ARIN policy wouldn't allow them to
assign us a /36 at this time. Unless someone knows something that can help us here.
Might. I'd file the request, as long as you have a logical addressing plan to justify it.
Jima
-- :o@>