- NANOG - lists.nanog.org

Re: Favorites (Re: UUNET peering policy)
by Sean Donelan 16 Jan '01

16 Jan '01

On Mon, 15 January 2001, Paul Vixie wrote: > After all, in an actual "media", the content providers collect money from > the networks who distributed their wares, and those networks then sell the > eyeballs to the highest bidder. Fortunately, the internet isn't a "media". In the actual media, the government intervened multiple times in how many local television stations a network could own, how contracts between content studio providers and networks broadcastors could be structured, how much marketshare a single cable company could have, and so forth. Now we see companies such as Disney using their "must-carry" power to strong-arm cable companies to pay for things like the Disney Channel and put it on the standard tier offering. While AOL/Time Warner negotiates by disconnecting stations like WABC/New York from their cable system. In other cases, it is nearly impossible for a new cable-only network to get on cable systems, unless they sell part equity to the cable systems. So you end up with companies also owning their suppliers, and in part determining how much those suppliers will charge themselves. AOL/Time Warner then gets to tell the local franchise board, Turner raised its rates again, we have to raise our cable prices to recoup the extra cost. Should the government intervene in the Internet the same way? Should the FCC impose a "must-carry" rule for the Internet? Or a "must-peer" rule?

1 0

The Cidr Report
by Tony Bates 16 Jan '01

16 Jan '01

This is an auto-generated mail on Fri Jan 12 12:00:00 PST 2001 It is not checked before it leaves my workstation. However, hopefully you will find this report interesting and will take the time to look through this to see if you can improve the amount of aggregation you perform. The report is split into sections: 0) General Status List the route table history for the last week, list any possibly bogus routes seen and give some status on ASes. 1) Gains by aggregating at the origin AS level This lists the "Top 30" players who if they decided to aggregate their announced classful prefixes at the origin AS level could make a significant difference in the reduction of the current size of the Internet routing table. This calculation does not take into account the inclusion of holes when forming an aggregate so it is possible even larger reduction should be possible. 2) Weekly Delta A summary of the last weeks changes in terms of withdrawn and added routes. Please note that this is only a snapshot but does give some indication of ASes participating in CIDR. Clearly, it is generally a good thing to see a large amont of withdrawls. 3) Interesting aggregates Interesting here means not an aggregate made as a set of classful routes. Thanks to xara.net for giving me access to their routing tables once a day. Please send any comments about this report directly to me. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. ------------------------------------------------------------------------------ CIDR REPORT for 12Jan01 0) General Status Table History ------------- Date Prefixes 050101 95475 060101 95482 070101 95512 080101 95490 090101 95422 100101 95551 110101 99200 120101 96318 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- AS Summary ---------- Number of ASes in routing system: 7237 Number of ASes announcing only one prefix: 3821 (1389 cidr, 2432 classful) Largest number of cidr routes: 637 announced by AS701 Largest number of classful routes: 1652 announced by AS1221 1) Gains by aggregating at the origin AS level --- 12Jan01 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS10501 2 1 1 50.0% PacLink AS10390 2 1 1 50.0% TELECHECK AS10240 2 1 1 50.0% MOTLEYFOOL AS10173 2 1 1 50.0% KSNET.Inc AS9995 1 1 0 0.0% Japan Network Information Center AS9991 1 1 0 0.0% Japan Network Information Center AS9983 1 1 0 0.0% Australian Bureau of Statistics. AS9982 1 1 0 0.0% PAICHAI UNIVERSITY AS9979 1 1 0 0.0% KOREA EXCHANGE BANK AS9978 1 1 0 0.0% The University of Seoul AS9974 1 1 0 0.0% KOREA SECURITIES COMPUTER CORP. B AS9973 1 1 0 0.0% KEB Futures Co. AS9968 1 1 0 0.0% Kyobo Life Insurance AS9962 1 1 0 0.0% Sunchon National University AS9960 1 1 0 0.0% NEW C&C CO.,LTD. AS9954 1 1 0 0.0% Kunsan National University AS9953 1 1 0 0.0% Hyundai Eng. & Const. Co., Ltd. AS9951 1 1 0 0.0% D3C Net AS9950 1 1 0 0.0% INT Co.,Ltd. AS9935 1 1 0 0.0% AGNS-Customer-KW AS9928 1 1 0 0.0% Crystal Internet AS9927 1 1 0 0.0% A Multihomed ISP Company AS9912 1 1 0 0.0% Quality Internet Services AS9879 1 1 0 0.0% OGILVY ASIA/PACIFIC AS9877 1 1 0 0.0% Ngee Ann Polytechnic Computer Cen AS9875 1 1 0 0.0% PT. Pasifik Satelit Nusantara AS9871 1 1 0 0.0% JC Entertainment Co. AS9868 1 1 0 0.0% Catholic University of TAEGU HYOS AS9866 1 1 0 0.0% LGCAPITAL AS9862 1 1 0 0.0% YES24 CO. LTD For the rest of the previous weeks gain information please see http://www.employees.org:80/~tbates/cidr-report.html 2) Weekly Delta Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report 3) Interesting aggregates Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report

2 2

Re: UUNET peering policy
by Paul Vixie 16 Jan '01

16 Jan '01

sean(a)donelan.com (Sean Donelan) writes: > In the past, some providers have specified peering requirements such > as "must use a Cisco 7000 with SSP". Not only that, we used to insist on particular brands of DSU/CSU. <winge> > If you are concerned about congestion, you should specify a performance > requirement covering congestion, not some internal architecture design > of the other network. How the other network chooses to solve the congestion > problem should be up to them. Congestion problems on the other guy's network are of course their problem, and you're right that backhaul from the peering point "inward" is not something a peering agreement ought to cover other than in the most general terms ("thou shalt not bother to boost the speed of our peering connection if the only effect it will have is to move the point of congestion one hop further toward you" or some such). I was referring, though, to congestion over the peering connection itself. This is very much the proper domain of a peering agreement, since it controls the benefit (or lack of such) each party will receive in exchange for their effort. Interestingly, some peering agreements insist on certain topological points because one or both of the "peering partners" have weak backbones toward some of their peering points. For example, "if we reach 10Gb/s in Walla Walla, then we agree to add the next 10Gb/s in some other city." > By saying you should treat the other provider as a black box I mean you > should be able to tell if the other provider is meeting or not meeting > their performance requirements WITHOUT examination of how much they are > paying for their circuits, what type of routers they are using, or how > they design their internal network. I completely agree. (I changed your "with" to a "WITHOUT" above, btw.) -- Paul Vixie <Paul.Vixie(a)MMFN.COM> CTO and SVP, MFN (NASDAQ: MFNX) AboveNet, PAIX, and MIBH are subsidiaries of Metromedia Fiber Network, Inc.

1 0

Re: Favorites (Re: UUNET peering policy)
by Paul Vixie 16 Jan '01

16 Jan '01

sean(a)donelan.com (Sean Donelan) writes: > > "Favor"? What, precisely, connotes "favor" in this regard? > > Sending more, or receiving more? And: why? > > Which side of the debate do you want to take? Neither. The argument had better not be about last mile costs, since those are actually comparable when you count them per bit-mile rather than per customer. Nor is it about last mile margins, since if someone is charging $19.95/mo for a service that costs $25.00/mo to provision, then expecting companies who are less stupid than that to go ahead and do some bizarre kind of "profit sharing" anyway is just insulting. I don't see a "favor" being granted here, either by the side who transmits more, or by the side who receives more. Both sides had better be charging what it costs them to provide the service, plus some kind of margin to keep the shareholders in the game. Failing to do this, even if for competitive reasons, does not create liability against those who manage to do it right. After all, in an actual "media", the content providers collect money from the networks who distributed their wares, and those networks then sell the eyeballs to the highest bidder. Fortunately, the internet isn't a "media".

1 0

Re: Favorites (Re: UUNET peering policy)
by Paul Vixie 16 Jan '01

16 Jan '01

rmeyer(a)mhsc.com (Roeland Meyer) writes: > To top it all off, it is not all that clear that AboveNet has no retail > transit feeds. ... I had no idea (that this wasn't clear). There is never a telco circuit between Abovenet and a customer -- it's always a private right of way, usually a piece of fiber but sometimes copper. Abovenet's customers include ISP's and IAP's and ASP's and so on. Your word ("retail") isn't accurate since Abovenet's customers also include IP bandwidth consumers, not just resellers. But it's absolutely true that our equipment is always colocated with the customer's equipment. Sometimes it's our location, sometimes it's the customer's location, sometimes it's a third party's location. But it's always some shared location, thus the term "colocation". If there any other questions about Abovenet, please address them to me privately unless you're REALLY SURE that all of NANOG wants to hear the question (and my near-inevitable answer.) -- Paul Vixie <Paul.Vixie(a)MMFN.COM> CTO and SVP, MFN (NASDAQ: MFNX) AboveNet, PAIX, and MIBH are subsidiaries of Metromedia Fiber Network, Inc.

1 0

FBI and new year's eve DOS
by Chris Beggy 16 Jan '01

16 Jan '01

The LA times is to report today on FBI interest in New Year's Eve DOS attempts: http://www.drudgereport.com/flash32.htm Chris -- Information may want to be free, but fiber optic cable wants to be a million US dollars per mile. -- Shawn McMahon <smcmahon(a)eiv.com>

5 4

peermaker and brain spikes
by Rick Irving 15 Jan '01

15 Jan '01

Hey, Worldcom! Contact me. Mail Administrator wrote: > > This Message was undeliverable due to the following reason: > > The following destination addresses were unknown (please check > the addresses and re-mail the message): > > SMTP <Peermaker_Secure_id_Help(a)lists.wcom.com> > > Please reply to Postmaster(a)imlists1.mcit.com > if you feel this message to be in error. > > >-------------------------------------------------------------------- >

1 0

RE: Favorites (Re: UUNET peering policy)
by Roeland Meyer 15 Jan '01

15 Jan '01

To top it all off, it is not all that clear that AboveNet has no retail transit feeds. I personally know of a few ISPs using AboveNet facilities. They re-sell Covad DSL and bring the Covad feed into their AboveNet cage, they re-route it up from there. Of course, they are also doing this with ELI. The thing is that they use the AboveNet internet backbone and the Covad telco backbone, in an AboveNet cage, to refer to the specific example. AboveNet is not in the position to know, or care, they just sell the cage and the internet backbone. Since Covad is also in SJC, and they only sell telco backbone, they don't care either. The titular ISP, works the margins (as always). > -----Original Message----- > From: Sean Donelan [mailto:sean@donelan.com] > Sent: Monday, January 15, 2001 10:37 AM > To: nanog(a)merit.edu > Subject: Favorites (Re: UUNET peering policy) > > > > On Sun, 14 January 2001, Paul Vixie wrote: > > sean(a)donelan.com (Sean Donelan) writes: > > > If you look at Abovenet's traffic graphs, you'll notice > Abovenet has a wide > > > variety of traffic balances with different providers. > Some in Abovenet's > > > favor (such as 3:1 with Sprint, 5:1 with Teleglobe) and > some in the other > > > provider's favor (such as 1:3 with Exodus). ... > > > > "Favor"? What, precisely, connotes "favor" in this regard? > Sending more, or > > receiving more? And: why? > > Which side of the debate do you want to take? > > > The traditional arguement is a network composed mostly of a > few large data > centers, with lots of servers sending traffic is getting a > "free ride" on > the network which built out nationwide and has POPs in every LATA. > > UUNET deserves a return on its investment on all those > wholesale dialup > POPs and circuits to underserved rural areas. Abovenet is just cream > skimming in a few large metro areas, while UUNET does the hard work of > carrying that extra traffic imbalance. Abovenet selling > "cheap" bandwidth > because it doesn't have the cost of delievering the traffic that UUNET > has to pay. > > The opposite side is Abovenet has invested a lot into its > sites and MFN > into its networks. It just choose to do it in a different > way than UUNET. > Its more expensive to lay fiber in metro areas than rural > areas. It costs > a lot of money to operate the centers. Whether the traffic > is being paid > by the millions of $19.95 dialup users on UUNET's wholesale ports or > by the hundreds of hosters in Abovenet's sites, the traffic is paid. > > >

1 0

Access Numbers
by John Paul Martin 15 Jan '01

15 Jan '01

Our ISP is exanding into other areas. Where can I find a list of what numbers certain cities can dial locally? We want to get the best location and phone number for the buck. Thanks in advance, John Paul Martin

4 3

RE: Access Numbers [OT]
by Scott Madley 15 Jan '01

15 Jan '01

It's a bit pricey, but the LERG by Telecordia is the best implementation of rate center homing. It pretty much has everything you need to use in a carrier-class enviroment. However, unless you have CLEC status you are tied into the local ILEC's rate centers. http://www.bellatlantic.net/cgi-bin/npa-nxx/ Show's look exchanges for the Bell Atlantic area... I'm sure other RBOC's have these as well. Cheers -Scott -----Original Message----- From: Mark Radabaugh [mailto:mark@amplex.net] Sent: Monday, January 15, 2001 9:42 AM To: nanog(a)merit.edu Subject: RE: Access Numbers [OT] Not that this is of much use to most of you but for Ohio it is published on the PUCO web page at http://www.puc.state.oh.us/pucogis/easmaps/EASMAP.HTM Very useful for figuring out where to put terminal servers. You might try your own state Public Utility Commission - at least in Ohio the local calling area is a regulated function. Mark Radabaugh VP, Amplex (419)833-3635 mark(a)amplex.net > -----Original Message----- > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of > deeann mikula > Sent: Monday, January 15, 2001 7:53 AM > To: John Paul Martin > Cc: nanog(a)merit.edu > Subject: Re: Access Numbers [OT] > > > > On Mon, 15 Jan 2001, John Paul Martin wrote: > > > > > Our ISP is exanding into other areas. Where can I find a list of what > > numbers certain cities can dial locally? We want to get the best location > > and phone number for the buck. > > i don't see that this is nanog material, unless we want to use it as a > springboard to begin complaining about a certain incumbent carrier... > > however, the answers are easy: > > *your local phone book should have pages in the front which should > list local calling areas, usually with a table of exchanges. > > *call your local operator by dialing zero, and ask > them if, with your calling plan, you can call NXX-1 from NXX-2 > toll-free. if s/he says s/he can't tell you that information, ask to > talk to their supervisor, because, as the entity billing you for such > calls, they should be able to tell you what their billing structure > is. (this is the most reliable method.) > > if anyone knows of a centralized listing, i'd love to see it. this is > something that i deal with everyday, and it can be messy. generally > we get a table of "this NXX can be dialed toll free from these NXXs" > from whomever is providing our virtual NXXs. however, those lists > have proved incorrect in the past, and we INSIST that our phone staff > tell our customer to check their access number using the above > methods. > > deeann m.m. mikula > > network administrator > telerama internet -- http://www.telerama.com > abuse@telerama.com/spam@telerama.com > 1.877.688.3200x501 > > >

1 0