[arin-ppml] Rationale for /22

Chris Grundemann cgrundemann at gmail.com
Tue Jul 28 12:03:20 EDT 2009


On Tue, Jul 28, 2009 at 09:53, Kevin Kargel<kkargel at polartel.com> wrote:
> I believe that the reason there is not a huge problem with unaggregated
> /24's is that there are not very many unaggregated /24's being delivered.

A quick look at the routing table on one of my employer's peering
routers shows 155,060 /24s currently, not counting any from our own
AS.

> Current wisdom says it is a bad idea, so people are not doing it, so there
> is not a big problem.

Unfortunately a lot of big ISPs are doing it, take a look at NANOGs
Weekly Routing Table Report:

"
Analysis Summary
----------------
BGP routing table entries examined:              292250
   Prefixes after maximum aggregation:           138369
   Deaggregation factor:                         2.11


ARIN Region per AS prefix count summary
---------------------------------------
 ASN   No of nets  /20 equiv  MaxAgg  Description
 6389     4241       3643         324   bellsouth.net, inc.
 4323     1899       1050         386   Time Warner Telecom
 1785     1713        714         139   PaeTec Communications, Inc.
 7018     1511       5907        1047   AT&T WorldNet Services
20115     1423       1461         678   Charter Communications
 2386     1272        670         924   AT&T Data Communications Serv
 6478     1242        275         315   AT&T Worldnet Services
 3356     1190      10960         441   Level 3 Communications, LLC
11492     1128        208          12   Cable One
22773     1077       2604          66   Cox Communications, Inc.
"

As others have stated, this may actually allow those ISPs to better
aggregate their space - because they won't have to allow the smaller
announcements to keep from breaking their small multihomed
customers...

> People very rarely poke sharp sticks in their eyes, so there is not a big
> problem with eye injuries from intentional sharp stick jabs.  I do not
> believe that poking yourself in the eye with a sharp stick should be ok
> because there is not current evidence of a problem from that action.
>
> A few extra routing table entries from infrequent gratuitous /24's is not a
> problem.  If we start flooding the tables with them it may be a problem.  As
> I said before this will be self limiting because of the finite number of
> /24's to hand out.
>
> I am not stomping my foot and saying there will absolutely be an issue, I
> would just like to be reassured that it has been considered.

Agreed, is there a way to quantify the increase in demand (if any) for
/24s should ARIN be the one handing them out, instead of ISPs?

I think the larger concern may be a faster burn of ASNs?

~Chris
>
>
>
>> -----Original Message-----
>> From: Scott Leibrand [mailto:scottleibrand at gmail.com]
>> Sent: Tuesday, July 28, 2009 10:22 AM
>> To: Kevin Kargel
>> Cc: ARIN PPML
>> Subject: Re: [arin-ppml] Rationale for /22
>>
>> Let me ask the inverse (or is it converse?) question:
>>
>> Do you have evidence that unaggregated /24's (still) break things?  I
>> haven't seen any evidence myself in the last 5 years...
>>
>> Thanks,
>> Scott
>>
>> Kevin Kargel wrote:
>> > I haven't been following this closely, sometimes work intrudes, but have
>> we
>> > all forgotten all the rationals that say that unaggregated /24's break
>> > things?  Or are we assuming that everyone will be able to handle huge
>> > routing tables or are we assuming that the /24 recipients don't care if
>> they
>> > can route beyond peers?
>> >
>> > I realize that IP's will become a smaller pool, so maybe the thinking is
>> > that when this triggers there won't be enough /24's left to
>> significantly
>> > affect the routing tables?
>> >
>> > I am still in the camp of "Keep doing what we are doing and when it runs
>> out
>> > it runs out."  Rationing is not always a good idea.  Trying to stretch
>> out
>> > resources indefinitely will be an exercize in futility.
>> >
>> >
>> >> -----Original Message-----
>> >> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
>> >> Behalf Of Joel Jaeggli
>> >> Sent: Tuesday, July 28, 2009 9:33 AM
>> >> To: William Herrin
>> >> Cc: ARIN PPML
>> >> Subject: Re: [arin-ppml] Rationale for /22
>> >>
>> >>
>> >>
>> >> William Herrin wrote:
>> >>
>> >>> On Tue, Jul 28, 2009 at 4:43 AM, Joel Jaeggli<joelja at bogus.com> wrote:
>> >>>
>> >>>> Bill Darte wrote:
>> >>>>
>> >>>>> Every effort to lower minimum allocations throughout the years has
>> met
>> >>>>> with resistance.  Each successful policy managed a 'bit at a time'
>> to
>> >>>>> ensure 'nothing bad happened'....
>> >>>>>
>> >>>> Realistically is it in the interest of a prospective multihomer to a
>> >>>> recieve a prefix that's likely longer than the one they already use?
>> >>>>
>> >>> Joel,
>> >>>
>> >>> I don't follow your logic here. Why would a multihomer request less IP
>> >>> addresses than he already uses, regardless of the minimum prefix size?
>> >>>
>> >>>
>> >>>
>> >>>> How quickly does one chew up /32s /30 /28s in the process of
>> >>>>
>> >> multihoming
>> >>
>> >>>> the internet facing infrastructure in a smple-multihomed network?
>> >>>>
>> >>> When I was at the DNC, I structured the network to justify a /22. I
>> >>> really wanted a /23 but a /22 was what I could get.
>> >>>
>> >>> I'm faced with a similar situation today. I need a /24 but I'll
>> >>> structure the network so that it justifies a /22. Just to be clear, I
>> >>> won't tell a single lie. I'll simply structure the network so that
>> >>> everything which could consume a public IP address does.
>> >>>
>> >>> I doubt my experience is unique. I expect that many if not most of the
>> >>> /22 end-user requests are similarly padded, not because the registrant
>> >>> actually wants that many addresses but because that's what they can
>> >>> get.
>> >>>
>> >>> Given the shortage of IPv4 addresses, why structure the policies so
>> >>> that we give anyone more than they actually want?
>> >>>
>> >> The minimum number of addresses that can be used may not in fact
>> reflect
>> >> the minimum that should be used.
>> >>
>> >>    For the purposes of minimizing fragmention.
>> >>
>> >>    Supporting basic network operation (it's nice when traceroute
>> >>    and pmtud work) because your intermediate routers are privately
>> >>    numbered.
>> >>
>> >>    Limiting the consequences of imagination failure, which may
>> >>    sound flippant but renumbering, requesting an additional block,
>> >>    or and point one and two are good reasons to make a potential
>> >>    multi-homer justify the assignment of a block of the appropriate
>> >>    size for that activity.
>> >>
>> >>
>> >>
>> >>> Regards,
>> >>> Bill Herrin
>> >>>
>> >>>
>> >>>
>> >> _______________________________________________
>> >> 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.
>> >>
>> >> -----------------------------------------------------------------------
>> -
>> >>
>> >> _______________________________________________
>> >> 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.
>
> _______________________________________________
> 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



More information about the ARIN-PPML mailing list