[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