1. Aggregation Methods and Allocation Strategies An overview of two Internet Drafts Brian Dickson briand@ca.afilias.info

2. Why IPv6? Why Now? Why? IPv6 is largely “green field” technology We've had the opportunity to learn from our mistakes...... but likely don't understand the lessons learned The underlying math often defies conventional wisdom Education is needed, both for us, and end users

3. Long Term View is Important Up until now, assignments have been done with a small “window” (3 months to 1 year)‏ The strategies that work best long term don't look anything like those that are designed to work on small blocks in small time-frames Early planning pays huge dividends long-term, and failure to plan results in eventual heat- death of individual LIRs (ISPs)‏

4. Side Issues Don't worry about HD ratio. If you aren't actually insane, it is virtually impossible to both run out of space and fail to meet the HD ratio Don't worry about running out of space. Worry about running out of FIB slots in your routers.  This means: Aggregate internally  And that means: Allocate Topologically !!! Show your customers what you are doing, and suggest to them to do likewise. It will help you, too.

5. What about “growing” assignments? Just because it seems easy to do, doesn't mean it accomplishes anything useful. Recipients of space, don't care where the next block is relative to the previous one. Really.  They care that it is big enough  They care about how easy it is to get  They care how often they will need to come back You care – you should want their next assignment to come from the same parent block. But, it does not need to be adjacent.

6. Long Term == 10 years or so Taking the long-term view lets you plan better for growth, and scalable network architecture Make sure your address pools are sized to meet the planned customer needs per pool. This is a bottom-up need, top-down design  Top down from a topological view-point  Bottom-up from a pool-size basis You can only aggregate what was allocated from the same block. This is your mantra.

7. Why sequential is bad It assumes flat topology. Unless you have a single router, this is bad. It won't scale, since you can't aggregate. Plan conservatively.  What if you had to use the same hardware for a very long time?  Could you sustain your customer growth? Customers might need different sized assignments. What then?

8. Why Bisection is bad It encourages (or even assumes!) recipients of space to (will) use Sequential assignments. It is order sensitive. The later a request is received, the smaller the available blocks will be. However, assignments will likely grow in size over time It is not topologically oriented, and won't scale over time for the same reasons as Sequential

9. Hidden dangers of Bisection Recipients compete with each other for diminishing resources (shrinking blocks)‏ The competition is highly local in the numbering space, not the geographic region It's all random chance – meaning unpredictable It isn't necessary! It's the only scheme that has a danger of not producing adequate HD ratios!!

10. What works well? Take your whole block, and set it aside. You will carve it up in big chunks first:  Determine the hierarchy of aggregation locations you will be using (be sure you are thinking long term)‏  Start at the bottom, add up the long-term customer assignment projections; round up to power-of-2  Do running totals up the hierarchy; round up at each level

11. Topological Pools Now, start splitting up the block into the top- level pools. Only take what you need at each level, from the pool immediately above it. At the bottom level, the block will be used for customer assignments. At this point, you don't care how the customer assignments get done. You can aggregate them, which is your main concern.

12. Customer Assignments You want to protect against big assignments in the future.  Small assignments are easy, big assignments are not easy.  You want customer assignments in any topological location to come from the same block.  This means, you want the assignments to be as optimally packed as possible  Customers don't need to grow – they need additional address blocks (eventually)‏  Optimal means later big blocks can be found

13. Optimal Assignment Packing Reduce, Re-Use, Recycle – works here, too Reduce – if you need to break up a block of free space, break up the smallest block Re-Use – if space comes back, treat it no different from other free space. Always use the smallest block that can hold a request Recycle – aggregate free blocks if/when possible Don't pool by size of block – it isn't necessary

14. RFC 3531 Concept for “rubber-banding” bit boundaries on assignments From above, looks like bisection From below, looks like sequential Both are bad, combining them keeps bad aspects of both Better to set hard limits, and start new blocks if/when needed Scaling never happens by accident!

15. Be Lazy Build tools to handle this stuff Tools don't lose sleep over the seeming chaos of the assignments done by the “optimal” algorithm. You shouldn't, either. Adopt this as an Informational RFC. Point your customers at this for explanations on assignment strategy and aggregation how-to's. Hard-code your aggregation blocks, don't rely on your IGP to do it. Don't flap. Don't do TE without NO-EXPORT applied.

16. It's Math, not Computers Don't worry if you don't understand it Feel free to ask for explanations and examples It's like bubble-sort versus quick-sort These are mathematical laws, not just models They can't be argued, they are factual Don't be ashamed if you supported bisection. You didn't know any better! If you do this, you might never need to get more address space from IANA/RIPE/whoever!

17. Thank You This is for the benefit of the community Having an RFC gives a permanent place to send folks to get a definitive answer It's advice, and can be ignored. I encourage my competitors to ignore it.  (Actually, not, we all lose if that happens...)‏ Author's address: briand@ca.afilias.info