[arin-ppml] Rationale for /22

[Kevin Kargel]

Top post, sorry.

So long as the longer mask allocations are the single and sole allocation
for the organization, and assuming that the organization would get a shorter
mask allocation if they cannot get the longer one, then there would be no
net difference to the global routing table size.  A slot is a slot.  

The problem comes when/if an organization starts collecting multiple long
mask allocations, each of which take up a slot (or two) when they cannot be
efficiently aggregated.  Another problematic scenario would be if
organizations were created for the sole purpose of getting a long mask
allocation for whatever reason.

If, on the other hand, the organization would opt to utilize non portable
space from an upstream provider if they couldn't get a long mask allocation
then there would be conservation of table size.  It might mean only saving
one slot out of two, but it would exist.

What I was trying last week (ever so badly) to get someone else to point out
were two points:

1. That if I allocate small space to my multihomed customer I can no longer
treat that space as part of my allocation. It is allocated to the customer
and must be routed as such. This creates complexity in my network.  If I do
treat their allocation as within my block then stuff breaks.
2. Given circumstance 1 a case can be made that the customer may as well get
their smaller allocation directly from ARIN, again assuming it is a sole
allocation.


> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of William Herrin
> Sent: Thursday, July 30, 2009 4:48 PM
> To: ARIN PPML
> Subject: Re: [arin-ppml] Rationale for /22
> 
> On Thu, Jul 30, 2009 at 1:56 PM, Leo Bicknell<bicknell at ufp.org> wrote:
> > I think many folks miss the most important item though when considering
> > the effects of minimum allocation size, or other polices that are
> > likely to affect the size of the global table.
> 
> Hi Leo,
> 
> If I may draw it back to the question I started with: Can you offer a
> well grounded reason to believe that changing the minimum allocation
> size for *multihomed* systems is likely to affect the size of the
> global table?
> 
> The only one I've been able to come up with goes something along the
> lines of, "If we reduce the minimum allocation size, more folks will
> multihome yielding more table consumption." That seems pretty weak in
> light of NRPM 4.2.3.6.
> 
> A couple of folks have said something along the lines of "you can
> aggregate mutlihomed users anyway," but as you know those arguments
> turn on some basic misunderstandings about how BGP works.
> 
> Another suggested that the minimums allow a convenient place to filter
> when trying to preserve older hardware a little longer, but as you
> know such filtering is just as functional (or dysfunctional) at any
> prefix size, not just the RIR minimums. At most, the RIR minimums give
> the BOFH somewhere to [disingenuously] point his finger when his
> customers complain.
> 
> Like you, still others have pointed out that if every single-homed
> user announced a route the Internet would collapse. That is not in
> dispute. RIRs assigning addresses to single-homed users would increase
> the route table size. PI for single-homed users is frankly a
> discussion for another era. In BGP/IPv4, that ship has sailed. My
> question covers only multihomed uses, and my real focus is multivendor
> multihomed uses where route aggregation is impractical regardless of
> who assigns the addresses.
> 
> So can you offer a justifiable reason to believe that changing the RIR
> minimum allocation size for *multihomed* systems is likely to affect
> the size of the global table?
> 
> 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
> _______________________________________________
> 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.
-------------- 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/20090803/9cfcd6fe/attachment.bin>