60 sites? Just ask for a /32. /kc
On Fri, Jul 07, 2017 at 01:07:54PM -0400, Oliver O'Boyle said: >Hello, > >If anyone out there could provide some input or advice on how to best >handle our upcoming leap into IPv6, it would be much appreciated. I want to >make sure we're playing nicely and not causing anyone any unnecessary grief >before we deploy. We're currently in the planning stage and can make >whatever changes we need to. > >Situation: > >We're an end-user org and qualify for a /40 assignment because we operate >over 60 sites and some of those are/will be multihomed. We manage hotels in >Canada only, but from coast to coast to coast and everywhere in between. >Our corporate network and org structure is optimized for three regions. We >also have, and continue to grow into, cloud infrastructure and foresee >wanting to bring our own addresses (.e.g., to AWS VPC when that option >becomes available). As such, an obvious design strategy would be to break >the /40 into 4 x /42's. However, due to an imbalance in national site >distribution, 50% of our sites are located in one region (Region A). >Additionally, historical and forecasted growth indicates that it's >perfectly reasonable for us to expect growth of an additional 16 sites in >that same region over the next 3-5 years. > >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. > >Ideal situation: ARIN assigns us a /36 and we don't need to worry about >re-addressing. Even if they can offer us contiguous space with a second >request to increase our assignment, we would likely need to re-address a >significant portion of our sites which would be painful and time-consuming. >Less ideal situation #1: Split the first level of subnets unevenly at 1 x >/41 and 2 x /42 and hope we can carve out some of that space for use in our >cloud infrastructure. This strategy would solve our Region A problem and >would keep Regions B and C from going to 68% and 34% utilization >immediately but it would mess up Region D and impact Regions B and C. >Less ideal situation #2: Split the first level of subnets unevenly at 1 x >/41, 1 x /42, and 2 x /43. This strategy would solve our Region A and >Region B problems but would constrain Region C and Region D future growth >options somewhat. >Less ideal situation #3: Drop the /48 per site default to somewhere between >a /49 and /53 and hope we don't bust out of those. This strategy would >allow us to keep top-level aggregation at /42's but would move the site >assignments off the nibble boundaries. >Less ideal situation #4: Keep 4 x /42's and hope we don't expand out of >them in Region A. This strategy would imply we don't wish for our business >to grow and is pretty risky. > >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. E.g., each room gets a /64 for all guest-internet devices >registered to that room. + IoT could result in the same rule (each room >gets a /64) or, perhaps a bit simpler, each class of IoT device is on a /64 >or each IoT vendor is on a /64. There will also be new applications that >come out with similar possible needs. With some of our hotels in the >500-1000 room range, we're looking at as many as 2000 /64's per site in the >next 5 or so years. Plus backoffice/admin subnets. > >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. > >Assuming we can't get a /36, my feeling is that less ideal situation #2 is >better than #3 is better than #1 is better than #4, assuming we're >following the following design best-practices: > >a) assign top-level aggregations evenly (which we'd be breaking a bit with >option #2) >b) reduce global routes as much as possible >c) stay on the nibble boundary as much as possible >d) default to /48 per site > >Any thoughts or advice would be much appreciated. > >Thanks in advance, >Oliver -- Ken Chase - m...@sizone.org Guelph Canada
