nanog mailing list archives
Re: IPv6 Routing table will be bloated?
From: Mark Smith <nanog () 85d5b20a518b8f6864949bd940457dc124746ddc nosense org>
Date: Wed, 27 Oct 2010 07:14:20 +1030
On Tue, 26 Oct 2010 12:19:30 -0500 Jack Bates <jbates () 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
Current thread:
- RE: IPv6 Routing table will be bloated?, (continued)
- RE: IPv6 Routing table will be bloated? George Bonser (Oct 26)
- RE: IPv6 Routing table will be bloated? Frank Bulk - iName.com (Oct 30)
- Re: IPv6 Routing table will be bloated? Majdi S. Abbas (Oct 26)
- RE: IPv6 Routing table will be bloated? George Bonser (Oct 27)
- Re: IPv6 Routing table will be bloated? Jack Bates (Oct 26)
- RE: IPv6 Routing table will be bloated? George Bonser (Oct 26)
- Re: IPv6 Routing table will be bloated? Blake Dunlap (Oct 26)
- Re: IPv6 Routing table will be bloated? Jack Bates (Oct 26)
- Re: IPv6 Routing table will be bloated? Scott Reed (Oct 26)
- Re: IPv6 Routing table will be bloated? Mark Smith (Oct 26)
- Re: IPv6 Routing table will be bloated? Mark Smith (Oct 26)
- Re: IPv6 Routing table will be bloated? Randy Carpenter (Oct 26)
- Re: IPv6 Routing table will be bloated? Franck Martin (Oct 26)
- Re: IPv6 Routing table will be bloated? Randy Carpenter (Oct 26)
- Re: IPv6 Routing table will be bloated? Franck Martin (Oct 26)
- Re: IPv6 Routing table will be bloated? Owen DeLong (Oct 26)
- Re: IPv6 Routing table will be bloated? Franck Martin (Oct 26)
- Re: IPv6 Routing table will be bloated? Matthew Palmer (Oct 26)
- Re: IPv6 Routing table will be bloated? John Curran (Oct 27)
- Re: IPv6 Routing table will be bloated? Jack Bates (Oct 26)
