On Aug 6, 2011, at 3:40 AM, Mukom Akong Tamon wrote: > On Fri, Aug 5, 2011 at 11:18 PM, Doug Barton <do...@dougbarton.us> wrote: >> For example, if you reserve a /48 per customer but actually use the >> first /56 out of it, you are safe if _you_ need the other /56 for some >> reason, or if the customer needs to expand into the full /48. > > +1. Be generous in planning and then assign what makes operational > sense. Be sure to make sure that as you dole out smaller than blocks > to customers that requested from your RIR, you preserve your ability > to give a client a second block from the same aggregatable range. >
The way to address this better is to use allocation by bisection to your customers rather than giving them /56s. If you give a site a /48, it is very unlikely they will ever need an additional prefix for that site. Of course if you're talking about a customer that is using a single connection to you to feed multiple sites, that's a different issue and will require additional planning. For anyone that already understands allocation by bisection, you can skip the rest of this message. What I mean by allocation by bisection is simply issuing prefixes such that each issued prefix has the largest possible contiguous aligned space available for expansion. Let's assume 2001:db8::/32 as our starting point and that we are assigning /48s to 50 end sites from it. (I'm skipping the whole hierarchy to fit inside a /32 and keep the example simple). We'd assign 2001:db8::/48 for our own infrastructure and support machines. The first customer would get 2001:db8:8000::/48. The next customer would get 2001:db8:4000::/48, then 2001:db8:c000::/48. In the next round, we'd assign 2001:db8:2000::/48, 2001:db8:6000::/48, 2001:db8:a000::/48 and 2001:db8:e000::/48 This would be followed by …1000::/48, …3000::/48, …5000::/48, …7000::/48, …9000::/48, …b000::/48, …d000::/48, and …f000::/48. At this point, we've assigned 15 customers, and each of them could be expanded from /48 to /36 without invading any of our existing assignments. Continuing, we would assign the next 16 customers as: 2001:db8:0800::/48, 2001:db8:1800::/48, 2001:db8:2800::/48, 2001:db8:3800::/48, 2001:db8:4800::/48, 2001:db8:5800::/48, 2001:db8:6800::/48, 2001:db8:7800::/48, 2001:db8:8800::/48, 2001:db8:9800::/48, 2001:db8:a800::/48, 2001:db8:b800::/48, 2001:db8:c800::/48, 2001:db8:d800::/48, 2001:dbu:e800::/48, 2001:db8:f800::/48 That brings us to 31 customers all of whom have room to expand their /48 up to a /37 (though I wouldn't recommend doing /37s as they are not nibble-aligned, so, outside of exceptional circumstances, you would be unlikely to expand in place beyond /40 at this point.) The next 32 customers would fill in the 2001:db8:?400::/48 ranges and the 2001:db8:?c00::/48 ranges. This limits those customers now to /38s. Owen
smime.p7s
Description: S/MIME cryptographic signature