- Test - lists.nanog.org

RE: [Possible OT] California, and running off of generators for e xtended periods
by Richard Welty 16 Jan '01

16 Jan '01

John Fraizer [mailto:nanog@EnterZone.Net] wrote: > I believe that you will find that it is no economical to run > on generator > when on-mains power is available. The fuel is only one factor in the > overall cost of running on generator. Mechanical wear and tear is the > number one cost. The cost of power is will have to increase much more > before it becomes cost-effective to self-generate. i'm familiar with a NYS government agency which ran their generators for an extended period because, ignoring maintenence costs, it seemed cheaper to use generated power. they learned their lesson when they got the bill on rebuilding their generators. richard

1 0

RE: [Possible OT] California, and running off of generators for e xtended periods
by Karyn Ulriksen 16 Jan '01

16 Jan '01

Not sure about others, but we are already supplementing our Edison feed with our backup power supplies. If we didn't we'd be meeting brown out conditions. We have the diesel generator scheduled to go online when our battery reserves dwindle to a range that we have determined. Why? Hassle. Seems the appropriate way to work. Diesel is noisy and creates bad neighbor relations. Pick a reason. K Irvine, CA > -----Original Message----- > From: Matt Clauson [mailto:mec@dotorg.org] > Sent: Tuesday, January 16, 2001 9:30 AM > To: nanog(a)merit.edu > Subject: [Possible OT] California, and running off of generators for > extended periods > > > > Allo, all... Watching what's going on in California, it > occured to me, > and some of my colleagues, that the major colo and data centers (for > example, but not focusing on, Exodus, Colo.com, etc.) could > assist in the > power crunch that California is having by shifting part, or > all, of their > loads over to generator power -- one would think that a) > diesel fuel is > still cheaper than electricity in California, price hikes lately > notwithstanding, and b) the goodwill generated by such an > endeavor would > be good for the company. Admittedly, some sites with only > limited battery > UPS power cannot do this, at least not so early in the day. > But it seems > to me that at least a few datacenters and major facilities > could switch > over to independent power and just keep fueling the generators. > > Question: Why would (or wouldn't) your company switch your datacenter > loads to generator (or other off-mains) power sources, if you had the > capability and/or capacity? > > Comments invited, especially from companies in CA, or with > offices/datacenters in CA. Comments will be aggregated and > (re)posted at > a later date. > > (note: this is posted from my personal account. This inquiry is NOT > related to my employer or employment, but is posed for information, > speculation, and discussion among the NANOG and Internet communities.) > > --mec >

2 1

Re: Access Numbers
by David Lesher 16 Jan '01

16 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. There is no such list, esp. free. For a LARGE sum of money, some firms will sell you a best-guess, but I betcha they CYA themselves but good. The LERG will not tell you. Best 1st order: the local white pages and a map. -- A host is a host from coast to coast.................wb8foz(a)nrk.com & no one will talk to a host that's close........[v].(301) 56-LINUX Unless the host (that isn't close).........................pob 1433 is busy, hung or dead....................................20915-1433

4 3

fwd ppml: ARIN asking about SWIP procedures
by Bennett Todd 16 Jan '01

16 Jan '01

I thought folks in this forum might be interested in possibly replying to the matter in this note from ppml, and got the author's permission to forward it to this list. I'm trying to set the Mail-Followup-To header on this note to the ppml(a)arin.net list, not sure if I'm getting it right, but I think it would be appropriate if any replies were directed to the ppml list, as that's what ARIN is watching for this solicitation of public comment. ----- Forwarded message from ginny listman <ginny(a)arin.net> ----- From: ginny listman <ginny(a)arin.net> Subject: Just to clarify Date: Thu, 4 Jan 2001 08:20:07 -0500 (EST) To: ppml(a)arin.net Hi, my name is Ginny Listman. As of early December, I am the new Director of Engineering here at ARIN. In a meeting yesterday, to discuss database changes, the following policy issue came up. Apparently, there have been some upstream ISPs that have assigned some networks via SWIP, where later the downstream comes back saying it should have been an allocation, ie they want a maintainer id so they can assign/allocate further on down. In most cases, RSG has been granting the downstream's wish, creating the maintainer id, allowing them to further assign/allocate. Many times, it is just a minor error in the SWIP template, and shouldn't be a big deal. However, would there ever be a situation where the upstream would not want the downstream to be assigning/allocating? Should ARIN be responsible for notifying the upstream? We have be processing these request because we do not want to delay the downstream's business. Do we need a written policy to define how we should be processing such a request? ----- End forwarded message ----- I believe this matter is on-topic for nanog; if I'm mistaken my apologies, and please do let me know. Note that this forwarding to nanog is my fault and not the fault of the original author. -Bennett

5 6

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

16 Jan '01

On Mon, 15 January 2001, Paul Vixie wrote: > > 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.) Thanks. Yes, that was my intent. Its amazing what a difference half-a-word can make.

1 0

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