[arin-ppml] Submitted to ARIN Consultation and Suggestion Process

[Owen DeLong]

On Aug 21, 2011, at 12:27 PM, William Herrin wrote:

> On Fri, Aug 19, 2011 at 4:02 AM, Owen DeLong <owen at delong.com> wrote:
>> I'm talking about the coming day when the transfer markets have
>> sufficiently exploded the routing table that the DFZ providers are
>> having to make route acceptance decisions.
> 
> Hi Owen,
> 
> That's unrealistic. Assuming the /24 barrier remains in place (and
> there's no good reason to assume otherwise) the terminal size of the
> IPv4 table will be well under the maximum that can be handled by a
> cost-effective router.
> 
By my count there are ~15,000,000 /24s in the usable unicast
IPv4 space. Please explain to me how the terminal size of the
15,000,000 route table will remain well under the 1,000,000
route maximum in a cost-effective router?

> The IPv6 policies (failing to standardize on specific prefix sizes
> from fixed-prefix blocks) are far more likely to resulting in table
> size problems than the IPv4 transfer policy. Without anything to
> constrain it, 2^48 is enough more than 2^24 to be a problem for the
> hardware.
> 

If there was any likelihood whatsoever of seeing 2^48 prefixes, sure.
The reality is that is massively unrealistic and the combination of
large provider aggregates (2011-3) and other constraints (there
aren't 2^48 end-sites to give /48s to in reality), etc. will prevent us
from getting anywhere near that.

> Nevertheless, your original point is a strong one: Reporting transfers
> which disaggregate existing blocks would "provide a valuable tool for
> the community and the AC to evaluate the effectiveness and any
> negative consequences from the transfer policy."  As a community we're
> exploring uncharted territory with for-pay address-only transfers. It
> seems like it would be appropriate to study them carefully and in
> great detail for the first little while.
> 

Agreed.

> For that reason, I SUPPORT your suggestion.
> 

Excellent. The good news is that it's useful for both purposes.

Owen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2105 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20110822/ed65da65/attachment.p7s>