[arin-ppml] Rationale for /22

[Kevin Kargel]

> Hi Kevin,
> 
> I thought the problem was a large number of disaggregate announcements
> from an org's single network topology needlessly fill expensive TCAMs.
> I'm not aware that the size of the announcements has anything to do
> with it; just the count. Right?
> 

Correct, count is meaningful, size is not.  Having said that, a small size
allocation increases the likelihood that a near future additional allocation
will be needed, thereby increasing count.  It will be increasingly likely
that the additional allocations will not be aggregable (is that a word?).

> Anyway, we're talking about multihomers here, so I don't think we're
> talking about adding new route announcements at all, are we? We're
> talking about folks who are announcing a cut-out /24 from an ISP's
> larger block (NRPM 4.2.3.6) and allowing them to announce a direct
> ARIN assignment instead. Same address count. Same consumption in the
> routing table. But without all of the nasty problems associated with
> cutting a /24 out of an ISP's block.

I thought we were talking about new portable allocations directly from ARIN
unrelated to the ISP's current allocation.  I will go back and read more
closely.  If this new allocation is not contiguous with the ISP allocations
then it will generate a new table entry.

> 
> Some of the problems with cutting a /24 out of an ISP's block include:
> 
> * Causes major grief with reverse path filtering / spoofing
> protection. If the ISP implements this at all, multihomed cutouts have
> to be explicitly excluded. In effect, ties the ISP's hands with
> respect to his internal network management.
> 
> * There are some funky issues with BGP which make withdrawing a cutout
> route a lot slower than re-establishing an independent route.
> 
> * Grief with SWIP reporting errors that cause administrative hassles
> getting the addresses announced properly.
> 
> * RIR boundary filtering that causes multihoming to malfunction during
> major network partition events (when you most want multihoming to work
> right)
> 
> * Renumbering when you change vendors.
> 
> 
> Regards,
> Bill
> 
> 
> 
> --
> William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
> 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
> Falls Church, VA 22042-3004
-------------- 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/69ca7dc1/attachment.bin>