Re: Anyone got numbers on peering vs transit?
Bon soir, } On Fri, 5 May 2006, Aleksi Suhonen wrote: } A) does not pass a peering relationship }(i.e. is AS internal or passes through transit connections only) } B) passes a public peering relationship } C) passes a private peering relationship Mikael Abrahamsson wrote: } Judging from our perspective (TDC Song) my guesstimate is that we as a } nordic ISP with majority of traffic to/from Swedish customers do: } 50% traffic in Sweden } 25% Nordic (Oslo/Copenhagen/Helsinki) } 10-15% LINX/AMSIX } 10-15% transit I forgot to stress that I'm particularly interested in the ratio between private and public peering. Thanks for a swift response, by the way. :-) -- Aleksi Suhonen / Axu TM Oy Internetworking Consulting Cellular: +358 45 670 2048 World Wide Web: www.axu.fi
Re: Anyone got numbers on peering vs transit?
On Fri, May 05, 2006 at 10:11:31AM +0300, Aleksi Suhonen wrote: I forgot to stress that I'm particularly interested in the ratio between private and public peering. The answer is, it depends. In any given region, prevailing market conditions (the price of transit, etc), the costs of ix ports, the costs of colo and fiber xconns, the geographic distribution of peers, and the attitudes towards public and private peering are all going to have a huge impact. For example, public peering in Europe is FAR more pervasive than it is in the US. Obvious reasons for this include: European IX's US IX's * Largely run by non-profits* Largely run by for-profits * Largely un-associated with colos * Largely run by colo operators * Early adopters of new tech like 10GE * Significantly lagging on new tech * IX ports are generally very cheap * Same ports usually cost 3-8x more * Larger numbers of smaller peers * Smaller numbers of larger peers * Lots of language specific content * Lots of globally targetted content Obviously market economics drive public peering much more in Europe than in the US. To put it into perspective, the amount of traffic exchange by a single large IX (such as AMS-IX) is roughly equal to all of the IX's in the US combined. That same amount of traffic is roughly 1/2 (or less) of the the traffic exchanged by a single large network (such as Cogent, Level3, ATT, ATDN, etc) via private peering. -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
BGP Update Report
BGP Update Report Interval: 21-Apr-06 -to- 04-May-06 (14 days) Observation Point: BGP Peering with AS4637 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/PfxAS-Name 1 - AS855 53131 4.8% 95.7 -- CANET-ASN-4 - Aliant Telecom 2 - AS7015 29974 2.7% 10.2 -- CCCH-AS2 - Comcast Cable Communications Holdings, Inc 3 - AS4323 13502 1.2% 10.5 -- TWTC - Time Warner Telecom, Inc. 4 - AS15105 11385 1.0% 52.2 -- NETWORKTELEPHONE - Network Telephone Corporation 5 - AS3475 10425 0.9% 386.1 -- LANT-AFLOAT - NCTAMS LANT DET HAMPTON ROADS 6 - AS33783 10183 0.9% 95.2 -- 7 - AS17974 10139 0.9% 28.0 -- TELKOMNET-AS2-AP PT TELEKOMUNIKASI INDONESIA 8 - AS7029246 0.8% 12.1 -- AS702 MCI EMEA - Commercial IP service provider in Europe 9 - AS15290 8761 0.8% 28.5 -- ALLST-15290 - Allstream Corp. Corporation Allstream 10 - AS5778300 0.7% 78.3 -- BACOM - Bell Canada 11 - AS9340 8065 0.7% 35.4 -- INDONET-AS-AP INDO Internet, PT 12 - AS14654 7445 0.7% 124.1 -- WAYPORT - Wayport 13 - AS5839 7296 0.7% 304.0 -- DDN-ASNBLK - DoD Network Information Center 14 - AS7552 7044 0.6% 77.4 -- VIETEL-AS-AP Vietel Corporation 15 - AS9121 6665 0.6% 26.3 -- TTNET TTnet Autonomous System 16 - AS14410 6585 0.6%1317.0 -- DALTON - MCM, Inc., DBA: [EMAIL PROTECTED] 17 - AS30890 6556 0.6% 38.3 -- EVOLVA Evolva Telecom 18 - AS15611 6357 0.6% 83.6 -- Iranian Research Organisation 19 - AS23918 6278 0.6% 48.7 -- CBB-BGP-IBARAKI Connexion By Boeing Ibaraki AS 20 - AS2669 6251 0.6% 48.8 -- CDAGOVN - Government Telecommunications and Informatics Services TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/PfxAS-Name 1 - AS7684 4614 0.4%4614.0 -- SAKURA-A SAKURA Internet Inc. 2 - AS3043 2876 0.3%2876.0 -- AMPHIB-AS - Amphibian Media Corporation 3 - AS21027 2857 0.3%2857.0 -- ASN-PARADORES PARADORES Autonomous System 4 - AS14410 6585 0.6%1317.0 -- DALTON - MCM, Inc., DBA: [EMAIL PROTECTED] 5 - AS9747978 0.1% 978.0 -- EZINTERNET-AS-AP EZInternet Pty Ltd 6 - AS27016 945 0.1% 945.0 -- NRC-NET - United States Nuclear Regulatory Commission 7 - AS34378 908 0.1% 908.0 -- RUG-AS Razguliay-UKRROS Group 8 - AS16705 1721 0.1% 860.5 -- STORAGEAPPS - Storage Apps Inc. 9 - AS36565 726 0.1% 726.0 -- COUNTY-OF-MONTGOMERY-PA - County of Montgomery 10 - AS36000 656 0.1% 656.0 -- NHA-ASN1 - Northern Health Authority 11 - AS13436 654 0.1% 654.0 -- STELLATE-CCCLC - Stellate Partners - CCCLC 12 - AS4678 1942 0.2% 647.3 -- FINE CANON NETWORK COMMUNICATIONS INC. 13 - AS23917 1250 0.1% 625.0 -- BRIBIE-NET-AS-AP Bribie Island Net Multihomed, Brisbane 14 - AS16776 2396 0.2% 479.2 -- HOMESTORE-IBS - Homestore.com, Inc 15 - AS26467 426 0.0% 426.0 -- HYPERTEK - HyperTEK Corporation 16 - AS21260 841 0.1% 420.5 -- POSITIVE-INTERNET-UK-AS Positive Internet UK AS 17 - AS25435 1235 0.1% 411.7 -- TELESONIQUE-AS Telesonique 18 - AS10571 1202 0.1% 400.7 -- GEOACCESS-AS - GeoAccess 19 - AS4032387 0.0% 387.0 -- TASDAC - TASDAC 20 - AS3475 10425 0.9% 386.1 -- LANT-AFLOAT - NCTAMS LANT DET HAMPTON ROADS TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 59.106.255.0/2 4614 0.3% AS7684 -- SAKURA-A SAKURA Internet Inc. 2 - 209.140.24.0/2 2876 0.2% AS3043 -- AMPHIB-AS - Amphibian Media Corporation 3 - 62.81.240.0/24 2857 0.2% AS21027 -- ASN-PARADORES PARADORES Autonomous System 4 - 61.0.0.0/8 1937 0.1% AS4678 -- FINE CANON NETWORK COMMUNICATIONS INC. 5 - 61.8.114.0/241567 0.1% AS9476 -- INTRAPOWER-AS-AP Intrapower 6 - 208.28.80.0/21 1357 0.1% AS7013 -- NETSELECT - Health Sciences Libraries Consortium 7 - 65.119.232.0/2 1342 0.1% AS14410 -- DALTON - MCM, Inc., DBA: [EMAIL PROTECTED] 8 - 205.160.25.0/2 1337 0.1% AS14410 -- DALTON - MCM, Inc., DBA: [EMAIL PROTECTED] 9 - 208.46.29.0/24 1337 0.1% AS14410 -- DALTON - MCM, Inc., DBA: [EMAIL PROTECTED] 10 - 65.174.4.0/231286 0.1% AS14410 -- DALTON - MCM, Inc., DBA: [EMAIL PROTECTED] 11 - 207.43.166.0/2 1283 0.1% AS14410 -- DALTON - MCM, Inc., DBA: [EMAIL PROTECTED] 12 - 203.25.67.0/24 1243 0.1% AS23607 -- ITXPRESS-AS-AP itXpress Pty Ltd. Network AS ISP and DSL 13 - 205.70.0.0/241238 0.1% AS3475 -- LANT-AFLOAT - NCTAMS LANT DET HAMPTON ROADS AS5237 -- DODNIC - DoD Network Information Center 14 -
The Cidr Report
This report has been generated at Fri May 5 21:48:05 2006 AEST.
The report analyses the BGP Routing Table of an AS4637 (Reach) router
and generates a report on aggregation potential within the table.
Check http://www.cidr-report.org/as4637 for a current version of this report.
Recent Table History
Date PrefixesCIDR Agg
28-04-06183702 121040
29-04-06183886 121205
30-04-06183892 121170
01-05-06183957 121265
02-05-06184015 121081
03-05-06183721 120991
04-05-06183612 121112
05-05-06184095 121146
AS Summary
21993 Number of ASes in routing system
9149 Number of ASes announcing only one prefix
1494 Largest number of prefixes announced by an AS
AS7018 : ATT-INTERNET4 - ATT WorldNet Services
91299584 Largest address span announced by an AS (/32s)
AS721 : DLA-ASNBLOCK-AS - DoD Network Information Center
Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').
--- 05May06 ---
ASnumNetsNow NetsAggr NetGain % Gain Description
Table 183998 1211546284434.2% All ASes
AS4323 1287 256 103180.1% TWTC - Time Warner Telecom,
Inc.
AS4134 1121 284 83774.7% CHINANET-BACKBONE
No.31,Jin-rong Street
AS18566 937 188 74979.9% COVAD - Covad Communications
Co.
AS4755 917 219 69876.1% VSNL-AS Videsh Sanchar Nigam
Ltd. Autonomous System
AS721 1001 308 69369.2% DLA-ASNBLOCK-AS - DoD Network
Information Center
AS22773 655 54 60191.8% CCINET-2 - Cox Communications
Inc.
AS7018 1494 964 53035.5% ATT-INTERNET4 - ATT WorldNet
Services
AS6197 1007 480 52752.3% BATI-ATL - BellSouth Network
Solutions, Inc
AS19916 563 65 49888.5% ASTRUM-0001 - OLM LLC
AS855550 63 48788.5% CANET-ASN-4 - Aliant Telecom
AS17488 501 50 45190.0% HATHWAY-NET-AP Hathway IP Over
Cable Internet
AS3602 537 109 42879.7% AS3602-RTI - Rogers Telecom
Inc.
AS9498 567 150 41773.5% BBIL-AP BHARTI BT INTERNET
LTD.
AS17676 486 108 37877.8% JPNIC-JP-ASN-BLOCK Japan
Network Information Center
AS19262 648 281 36756.6% VZGNI-TRANSIT - Verizon
Internet Services Inc.
AS15270 414 50 36487.9% AS-PAETEC-NET - PaeTec.net -a
division of
PaeTecCommunications, Inc.
AS11492 631 274 35756.6% CABLEONE - CABLE ONE
AS812376 33 34391.2% ROGERS-CABLE - Rogers Cable
Inc.
AS4766 644 306 33852.5% KIXS-AS-KR Korea Telecom
AS22047 409 81 32880.2% VTR BANDA ANCHA S.A.
AS6467 364 42 32288.5% ESPIRECOMM - Xspedius
Communications Co.
AS18101 339 29 31091.4% RIL-IDC Reliance Infocom Ltd
Internet Data Centre,
AS16852 354 51 30385.6% FOCAL-CHICAGO - Focal Data
Communications of Illinois
AS5668 531 249 28253.1% AS-5668 - CenturyTel Internet
Holdings, Inc.
AS3352 310 29 28190.6% TELEFONICA-DATA-ESPANA
Internet Access Network of
TDE
AS8151 700 422 27839.7% Uninet S.A. de C.V.
AS14654 291 14 27795.2% WAYPORT - Wayport
AS6167 340 64 27681.2% CELLCO-PART - Cellco
Partnership
AS6198 507 242 26552.3% BATI-MIA - BellSouth Network
Solutions, Inc
Re: Tier Zero (was Re: Tier 2 - Lease?)
On 5/4/06, Aaron Glenn [EMAIL PROTECTED] wrote: On 5/4/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: why would anyone do that? --bill Some companies feel entitled to charging more for their routes than they would for simple transit. aaron.glenn John: Hopefully this comes out clearly, as writing can be more confusing than speaking... Are you getting at Inter AS /SLA/QOS that you would get from transit vs. best effort peering? Even that has some issues, the one that jumps out to me is hopefully clearly stick figure-diagrammed below: AS#x $--SLA--Transit ok... But... AS#x $--SLA--Transit -(second hop)--Customers/Peers---No Qos/SLA--- My point is it is hard to do anything beyond the first AS# for any SLA that you would be paying, since after that the packet switches to no money packets on a paid connection, pushing out the issue for things sent down that pipe... Peter Cohen
Re: Anyone got numbers on peering vs transit?
On 5/5/06, Richard A Steenbergen [EMAIL PROTECTED] wrote: On Fri, May 05, 2006 at 10:11:31AM +0300, Aleksi Suhonen wrote: I forgot to stress that I'm particularly interested in the ratio between private and public peering. The answer is, it depends. In any given region, prevailing market conditions (the price of transit, etc), the costs of ix ports, the costs of colo and fiber xconns, the geographic distribution of peers, and the attitudes towards public and private peering are all going to have a huge impact. For example, public peering in Europe is FAR more pervasive than it is in the US. Obvious reasons for this include: European IX's US IX's * Largely run by non-profits* Largely run by for-profits * Largely un-associated with colos * Largely run by colo operators * Early adopters of new tech like 10GE * Significantly lagging on new tech * IX ports are generally very cheap * Same ports usually cost 3-8x more * Larger numbers of smaller peers * Smaller numbers of larger peers * Lots of language specific content * Lots of globally targetted content Obviously market economics drive public peering much more in Europe than in the US. To put it into perspective, the amount of traffic exchange by a single large IX (such as AMS-IX) is roughly equal to all of the IX's in the US combined. That same amount of traffic is roughly 1/2 (or less) of the the traffic exchanged by a single large network (such as Cogent, Level3, ATT, ATDN, etc) via private peering. -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) Aleksi: Too add some to the great Ras, for us, much has changed over the years, as there has been more consolidation of facilities to be in, globally, as well as changes in hardware, decreases in public and private peering costs, cheaper fiber/dwdm, the end of atm, etc... So.. that being said, i would guess that many so-called large EU networks would have ~ 5% of their traffic on public exchanges, and many of those are not in USA exchanges or asian ones if their network goes there. I would also guess that the greater, smaller networks are more valuable to exchanges than the so-called larger networks from a financial perspective, since they are probably sending /receiving much more traffic. Some exchanges publish their customer's mbs of connectivity and you can draw your own conclusion from someone with 1000mbs vs. 1Mbs of peering capacity at an exchange. I think amsix is the one off the top of my head that tells who/where/mbs to the switches. Lastly, there are exchanges that allow for transit to be sold over them vs. not, and that would greatly increase the possibility of getting a larger network in there as well. Send me a private message if you want some specifics as far as i can give them about 1299. Peter Cohen
Re: Tier Zero (was Re: Tier 2 - Lease?)
On 5/4/06, [EMAIL PROTECTED] [EMAIL PROTECTED] karoshi.com wrote: why would anyone do that? Hopefully this comes out clearly, as writing can be more confusing than speaking... My point is it is hard to do anything beyond the first AS# for any SLA that you would be paying, since after that the packet switches to no money packets on a paid connection, pushing out the issue for things sent down that pipe... Are you saying that there *IS* a good reason why anyone would buy paid transit from all SFP providers? And that the reason is so that you have a contractual SLA with all of those providers? If so then two questions come to mind. Couldn't you achieve the same thing by having paid peering with the SFP providers? Assuming that you do have contractual service with all of the SFP providers and that there is an SLA in all of those contracts, how do you deal with the fact that there is no SLA (to you) on packets which leave the set of SFP networks? Packets could leave by going to a transit customer of an SFP network or by going to a non-SFP peer of an SFP network. Quite frankly, while terminology like transit, settlement free peering and paid peering are useful to analyze and talk about network topography, I don't think they are useful by themselves when making purchase decisions. They need to be backed up with some hard technical data about the network in question as well as the contractual terms (transit or peering) in place. It is not possible to say that a given network architecture is BETTER if you only know the transit/peering arrangements between that network and some subset of the other network operators. SFP operators will always be a subset of the entire public Internet. Membership in that set changes from time to time for various reasons. And the importance of non-members also varies from time to time, especially content-provider networks. --Michael Dillon P.S. I purposely did not use the term tier because I do not believe that current usage of this term refers to network architecture. It has more to do with market dominance than anything else and even there it is relative because there is no longer a single Internet access market.
Re: Multi ISP DDOS
On Thu, 4 May 2006, Martin Hannigan wrote: I hate to be the bearer of bad news to spammers :) but based on bluesecurity's tactics I can make a guess about attitude of their people and its such that DoS attack on them will only cause them more determination to continue and I suspect to majority of their users as well (and publicity is also likely to bring them more users). Moving the site to TypePad was incorrect way of dealing with attack though; but its actually not the first time I've heard of the site using a blog as temporary page while their primary site is down due to DoS... - some education on what blogs are good for is in order. But as it is looks like bluesecurity is moving to prolexic which claim to deal with just such situations. I hate to be the bearer of bad news to BS' VC's, but BS moving their DNS to UltraDNS and hosting to Prolexic was likely not part of the business plan. They ain't cheap. The spammers can now theoretically force them to spend all time and all their money responding to attacks. You know quite well that if they continue dos for too long law-enforcement would finally get interested... Now I really don't know UDNS and Prolexic prices but I have a feeling those hosting fees would be far from being their biggest expense. So I have to disagree with you that is what could bring them down, though I agree that as usual a lot depends on if their VCs want all this going - I just don't think hosting fees will be major reason for such a decision (unless BS self-funded which I doubt). The killer here is that they asked a lot of people a year ago whether this was a good idea and everyone said no. Yep and they were all right. Spammers: 2 Blue Security: 0 NANOG: -2 (vigilante time sink) Its more like: Spammers: -2 Blue Security: -1 Nanog: 0 (talk is cheap but results are...) -- William Leibzon Elan Networks [EMAIL PROTECTED]
Fiber maps of Minnesota
I work for a company that hosts services out of a datacenter in Minnesota. We're starting to plan the location of our next-generation data center, and we want to know if there is a place where we can get maps of local fiber-optic routes? We would like to see maps from several providers so we can ensure redundant connectivity. Does anyone have any hints as to how I can obtain such information? - Erik Amundson
Re: AOL 421 errors
On Thu, May 04, 2006 at 10:20:33AM +0100, Simon Waters wrote: ... That just creates Chinese whispers. ... This is a new term of which I had previously been unaware. What is it, please, and how does it relate to the Chinese country or people? Thanks. -- Joe Yao --- This message is not an official statement of OSIS Center policies.
Re: Tier Zero (was Re: Tier 2 - Lease?)
On 5/5/06, Peter Cohen [EMAIL PROTECTED] wrote: Hopefully this comes out clearly, as writing can be more confusing than speaking... Are you getting at Inter AS /SLA/QOS that you would get from transit vs. best effort peering? Even that has some issues, the one that jumps out to me is hopefully clearly stick figure-diagrammed below: AS#x $--SLA--Transit ok... But... AS#x $--SLA--Transit -(second hop)--Customers/Peers---No Qos/SLA--- My point is it is hard to do anything beyond the first AS# for any SLA that you would be paying, You can't *guarantee* better service once the packet leaves your provider's upstream ASs. However, there are hardware-appliance and connectivity vendors who make it their job to come very close, as long as the far-end network has at least one good, near-end reachable path. That's where the concept of route control (where BGP, with all the modern weighting frills, is not the final arbiter of route decisions) comes into play. Extending that concept, if *both* ends have some sort of route control in place, via the same vendor or not, you're even more likely to get good service quality even if the SFI providers in the middle suck at any given time. (ObAdvertisingSquelch: I have direct involvement in this subject, so I won't discuss vendor names on-list to avoid conflict of interest.) -- -- Todd Vierling [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: AOL 421 errors
Joseph S D Yao wrote: On Thu, May 04, 2006 at 10:20:33AM +0100, Simon Waters wrote: ... That just creates Chinese whispers. ... This is a new term of which I had previously been unaware. What is it, please, and how does it relate to the Chinese country or people? Joseph, See e.g. http://en.wikipedia.org/wiki/Chinese_whispers Erik -- Erik Radius [EMAIL PROTECTED]
Re: AOL 421 errors
I need no more references to Wikipaedia, thank you all. I had already looked it up, but after I sent my note. I need no more notes telling me that Chinese people talk funny, either. I had really never noticed that. -- Joe Yao --- This message is not an official statement of OSIS Center policies.
Weekly Routing Table Report
This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to [EMAIL PROTECTED] If you have any comments please contact Philip Smith [EMAIL PROTECTED]. Routing Table Report 04:00 +10GMT Sat 06 May, 2006 Analysis Summary BGP routing table entries examined: 187455 Prefixes after maximum aggregation: 103616 Unique aggregates announced to Internet: 91884 Total ASes present in the Internet Routing Table: 22087 Origin-only ASes present in the Internet Routing Table: 19218 Origin ASes announcing only one prefix:9153 Transit ASes present in the Internet Routing Table:2869 Transit-only ASes present in the Internet Routing Table: 66 Average AS path length visible in the Internet Routing Table: 3.5 Max AS path length visible: 23 Max AS path prepend of ASN (34527) 16 Prefixes from unregistered ASNs in the Routing Table:28 Unregistered ASNs in the Routing Table: 6 Special use prefixes present in the Routing Table:0 Prefixes being announced from unallocated address space: 13 Number of addresses announced to Internet: 1531319456 Equivalent to 91 /8s, 70 /16s and 20 /24s Percentage of available address space announced: 41.3 Percentage of allocated address space announced: 59.8 Percentage of available address space allocated: 69.1 Total number of prefixes smaller than registry allocations: 92349 APNIC Region Analysis Summary - Prefixes being announced by APNIC Region ASes:39523 Total APNIC prefixes after maximum aggregation: 16521 Prefixes being announced from the APNIC address blocks: 37242 Unique aggregates announced from the APNIC address blocks:18267 APNIC Region origin ASes present in the Internet Routing Table:2543 APNIC Region origin ASes announcing only one prefix:715 APNIC Region transit ASes present in the Internet Routing Table:390 Average APNIC Region AS path length visible:3.5 Max APNIC Region AS path length visible: 15 Number of APNIC addresses announced to Internet: 225017824 Equivalent to 13 /8s, 105 /16s and 127 /24s Percentage of available APNIC address space announced: 70.4 APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911 APNIC Address Blocks 58/7, 60/7, 121/8, 122/7, 124/7, 126/8, 202/7 210/7, 218/7, 220/7 and 222/8 ARIN Region Analysis Summary Prefixes being announced by ARIN Region ASes: 97040 Total ARIN prefixes after maximum aggregation:57517 Prefixes being announced from the ARIN address blocks:71278 Unique aggregates announced from the ARIN address blocks: 26403 ARIN Region origin ASes present in the Internet Routing Table:10690 ARIN Region origin ASes announcing only one prefix:4009 ARIN Region transit ASes present in the Internet Routing Table: 986 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 18 Number of ARIN addresses announced to Internet: 290145792 Equivalent to 17 /8s, 75 /16s and 70 /24s Percentage of available ARIN address space announced: 75.2 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863 ARIN Address Blocks24/8, 63/8, 64/5, 72/6, 76/8, 199/8, 204/6, 208/7 and 216/8 RIPE Region Analysis Summary Prefixes being announced by RIPE Region ASes: 37490 Total RIPE prefixes after maximum aggregation:25049 Prefixes being announced from the RIPE address blocks:34506 Unique aggregates announced from the RIPE address blocks: 23143 RIPE Region origin ASes present in the Internet Routing Table: 7951 RIPE Region origin ASes announcing only one prefix:4162 RIPE Region transit ASes present in the Internet Routing Table:1306 Average RIPE Region AS path length
Re: Tier Zero (was Re: Tier 2 - Lease?)
At 07:48 AM 5/5/2006, Peter Cohen wrote: On 5/4/06, Aaron Glenn [EMAIL PROTECTED] wrote: On 5/4/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: why would anyone do that? --bill Some companies feel entitled to charging more for their routes than they would for simple transit. aaron.glenn John: Hopefully this comes out clearly, as writing can be more confusing than speaking... Are you getting at Inter AS /SLA/QOS that you would get from transit vs. best effort peering? Even that has some issues, the one that jumps out to me is hopefully clearly stick figure-diagrammed below: AS#x $--SLA--Transit ok... But... AS#x $--SLA--Transit -(second hop)--Customers/Peers---No Qos/SLA--- My point is it is hard to do anything beyond the first AS# for any SLA that you would be paying, since after that the packet switches to no money packets on a paid connection, pushing out the issue for things sent down that pipe... Peter Cohen It was not about the SLA, although in theory, buying transit should give the provider more incentive to help. The off-list discussion was more about avoiding the dependency problem of peerings. A good peering involves multiple points of geographically diverse interconnections. The number and location of these interconnections would depend on the unique combination of architectures of the two peers. If an AS does not have the traffic levels to justify multiple connections into a neighboring AS, relying on a single interconnection point is a problem. Even if the interconnection does not go down, it might not be a good way to reach particular networks in the other AS. Instead, it might be wiser to tune traffic via a different neighbor using transit. In other words, it gives you the best of both worlds. Most traffic travels directly to/from the SFP provider that serves the corresponding networks (like a peer). However, one can use the transit option at will for particular routes. And, one can use transit via the other SFPs should any transit to an SFP fail (fiber cut, etc.) Given that transit is pretty cheap, it seems more cost effective, at lower traffic levels, to purchase single transit interconnections to all the SFPs than attempt true peering at a much larger number of interconnections to those same SFPs. This is getting pretty theoretical, but I was curious if such a business model was attempted. The original SAVVIS did this in part long ago, but to just three neighbors. (I think they are now part of CW now...I can't keep track of all these mergers.) It sounds like Internap is pretty close to this model, although I don't believe they have transit to all nine (if my SFP count is correct). John
