[ppml] Policy Proposal 2002-3: Micro-Assignments forMultihome d Networks

[Leo Bicknell]

In a message written on Mon, Aug 25, 2003 at 03:32:32PM -0400, jlewis at lewis.org wrote:
> Unless there are many networks filtering on RIR boudaries (anyone know how 
> many do this?), what's the routing table / routing table growth difference 
> between a network getting their /24 from C&W vs from ARIN if they are 
> going to have their own ASN and announce it to multiple providers as a /24 
> either way?

Hidden in your question is a number of subquestions, and I think it's
important to enumerate:

1) Will the routing table size be an issue?

   As long as there are several providers who don't filter, and
   they don't have problems then I don't believe this is a huge
   issue.  Some providers may be filtering and/or get broken by
   this change because they are running too close to the edge and/or
   are too cheap to upgrade.  I suspect for pretty much all the
   major carriers this is a complete non-issue.

2) Will people filter /24's in non-portable space?

   The answer is almost surely yes, some people seem to always filter
   based on ARIN (and other regisitries) minimum assigned size, and
   want to never allow more specifics.

3) Will people filter /24's assigned by ARIN?

   In general, probably not.  If ARIN clearly states it is assigning
   /24's from a particular block, I believe almost everyone will
   support that feature.  The filtering crowd tends to overlap a lot
   with the "support the standards" crowd.

That said, there are people who will do type #2 filtering, and not
#3 filtering, and thus would see much more "growth" with a proposal
that implements type #3.  However, I come back to my point in #1,
if many (most?) providers do just fine without filtering I see
little reason to worry much that the filteres will have great issue.
Indeed, they probably even have more headroom on this issue, on the
whole.

> The only obvious downside I see is application fraud by networks wanting
> to get their own /24 without satisfying the multihomed requirement.  
> Maybe add in that if a network is not consistently multihomed for X
> months, they have to give up the block, or it begins to go up considerably
> in price.

In my mind there should be no multi-homing requirement.  It's to
hard to police.  Rather, make this option expensive enough that,
on the whole, only those who need it will purchase.  For instance,
if you can get IP's for "Free" from your upstream, or fill out arin
paperwork and pay, say, $1000 per year, virtually all the people
who don't need it won't pay for it.

> That would just cause a flood of applications on the first of each month, 
> assuming there are considerably more than 200 nets that would take 
> advantage of this policy change, and they're aware of the 200/month limit.

I was thinking of a holdover system, that is first come first served,
process 200 and then wait until the next month to pick it up.

That said, feel free to review ARIN's numbers on how many they request
today.  I'm quite sure 200 is way high, and aside from a possible small
initial inrush has no chance of actually limiting things.

> Why do you think there will be any growth?  Short of the fraud issue
> mentioned above, all these /24's are already in the global routing table.

There will be short term growth, as both networks are announced as
people move from one to the other.  I think there will also be long
term growth, as people who were unsure if they could properly
multihome with a non-portable /24 (eg, due to others filtering on
a /19-/20 boundry) begin to multihome with these new ARIN assigned
blocks.

So yes, I see growth.  Growth measured in fractions of a percent, or
maybe even the first digit or two in the extreme case...nothing that
will cause the net to come to a standstill.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20030825/748b7f03/attachment.sig>