IPv6 Routing table will be bloated?

Tue Oct 26 20:44:20 UTC 2010

On Tue, 26 Oct 2010 12:19:30 -0500
Jack Bates <jbates at brightok.net> wrote:

> On 10/26/2010 12:04 PM, Nick Hilliard wrote:
> > In practice, the RIRs are implementing sparse allocation which makes it
> > possible to aggregate subsequent allocations. I.e. not as bad as it may
> > seem.
> >
> 
> Except, if you are given bare minimums, and you are assigning out to 
> subtending ISPs bare minimums,

Why aren't those subtending ISPs getting their own PI (/32s)?

> those subtending ISPs will end up with 
> multiple networks. Some of them are BGP speakers. I can't use sparse 
> allocation because I was given minimum space and not the HD-Ratio 
> threshold space.
> 
> > ARIN, RIPE and AfriNIC, for example, allocate on /29 boundaries. So if
> > you get an initial allocation of /32, then find you need more, your
> > subsequent allocations will be taken from the same /29, allowing
> > aggregation up to /29.
> >
> 
> My minimum /30 allocation per ARIN met a /27 in HD-Ratio thresholds. To 
> not be given the threshold space means no reservations for subtending 
> ISPs, no room for subtending ISPs to grow, and multiple assignments. If 
> ARIN only does /29 boundaries, I'll also be getting multiple /29's, and 
> not just working within a /27 per the HD-Ratio guidelines.
> 
> It's the mixed viewpoint that is the problem. HD-Ratio is useless as a 
> justification and as a metric which promotes route 
> conservation/aggregation if it is not used for initial allocations. 
> Initial allocations (including those handed out to subtending ISPs) 
> should all be as large as the immediate use HD Ratio permits. ie, If you 
> are immediately assigning X /56 blocks, your assignment should have a 
> length one less than the highest threshold you crossed. To assign any 
> less is to constrain the assignments, not allow for growth, and to 
> increase routing table size. It also circumvents and completely destroys 
> the concept of HD Ratio (as the initial assignments all are well in 
> excess of the thresholds for requesting much larger blocks).
> 
> 
> Jack
> 