[arin-ppml] Rationale for /22

[Kevin Kargel]

> AFAIK, there are no ISPs allowing customers to multihome with less
> than a /24 currently but many who are allowing those /24s.  So if that
> Org gets a /24 from ARIN or a /24 from it's ISP, there is the same 1
> entry in the table.  

This is incorrect.  If the Org gets a /24 from it's upstream ISP there is
the same entry in the routing table.  If the Org gets a discontiguous /24
from ARIN there is an additional entry in the routing table.  

What it boils down to is whether or not the Org's ISP can aggregate the
netblock.



And when that Org needs another /24 (and the ISP
> did not reserve the adjacent one and the customer does not want to
> renumber) and the ISP hands it another one, or ARIN hands it another
> one, there are the same two entries.  There are two main differences
> here though:
> 1) If ARIN policy requires that any Org with a /24 that wants more
> space be required to return the original /24, then we end up with one
> /23 instead of two /24s in the table.  This is more likely to happen
> than most ISPs requiring renumbering because of all those pesky sales
> teams and account managers...
> 2) If ARIN is giving space to a greater portion of all multihomers,
> then ISPs have less excuses not to better aggregate their own space.
> Load balancing should never require de-aggregation down to /24s.

But if ARIN is handing out the /24's instead of the ISP isn't the likelihood
far greater that the /24's will not be agregable?  I doubt that ARIN will be
able to only hand out /24's that would be.

> 
> Unless you stop allowing Orgs to multihome with less than a /22, there
> will be longer entries in the table.  Perhaps we could actually slow
> routing table growth by allowing them to get there space from ARIN
> (since they will be getting and announcing it anyway)?  Or do you
> think that getting space from ARIN will be so much easier than getting
> it from an ISP that Orgs will flock to /24s and cause more growth in
> the table than we currently see?

It is not an issue of ease, the issue is portability.  Orgs want portable
space so that they can avoid renumbering and be provider independant.

I have no problem with extending the minimum mask length so long as it is
tied hard to a requirement that anyone with a long mask have only one
allocation, and to get another allocation the long mask netblock must either
be aggregated in to the new allocation or returned.


> 
> ~Chris
> 
> >
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed to
> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.
> >
> 
> --
> Chris Grundemann
> weblog.chrisgrundemann.com
> www.twitter.com/chrisgrundemann
> www.coisoc.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3224 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090728/fac6a272/attachment.bin>