[arin-ppml] Rationale for /22
kkargel at polartel.com
Tue Jul 28 12:21:38 EDT 2009
> 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 126.96.36.199) 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
> * Renumbering when you change vendors.
> 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...
Size: 3224 bytes
Desc: not available
More information about the ARIN-PPML