August 2002 - Test - lists.nanog.org

damping
by Randy Bush 11 Aug '02

11 Aug '02

for research purposes. we want to send a periodic announce and a withdraw of a specific prefix. but we don't want to hit folk's damping policies. does anyone damp a swamp /24 which does an announce / withdraw on a two hour cycle? i.e. announce at 0,2,4,... and withdraw at 1,3,5,..? randy

1 0

Responses and update..
by Scott Walker 11 Aug '02

11 Aug '02

I have gotten a massive response.. I am going to organize it all and give everyone a nice list... Just give me a few to organize it :)

1 0

Re: Do ATM-based Exchange Points make sense anymore?
by Nenad Trifunovic 10 Aug '02

10 Aug '02

Hello, Can you, please, explain why you didn't consider Frame Relay based exchange in your analysis? Regards, nenad >Date: Thu, 08 Aug 2002 08:11 -0700 (PDT) >From: "William B. Norton" <wbn(a)equinix.com> >To: nanog(a)merit.edu >Sender: owner-nanog(a)merit.edu >Delivered-to: nanog-outgoing(a)trapdoor.merit.edu >Delivered-to: nanog(a)trapdoor.merit.edu >Delivered-to: nanog(a)merit.edu >Subject: Re: Do ATM-based Exchange Points make sense anymore? > > >Hi again - > >A couple points (based on some interactions with folks privately). > >This is not an ATM is bad, or general ATM-bashing paper. It simply applies >the same Peering Analysis that ISPs are applying to determine if and when >IXes make sense. With the transit prices and transport prices dropping, >this is a reasonable question, worthy of greater analysis than "well, ATM >is expensive so ATM is bad." > >To give you a flavor, given a set of assumptions, OC-3 (155Mbps) transport >into an ATM-based IX has an "Effective Peering Range" (where peering across >them is cheaper than transit) of 75-90Mbps, while given the same >assumptions, Fast Ethernet-based IXes also at OC-3 have an Effective >Peering Range of 40-70Mbps. The "Minimum Cost of Traffic Exchange" for this >ATM solution is $122/Mbps while FastE is $80/Mbps. > >At higher capacity the interconnect analysis is more dramatic: Given the >relatively high price point of transport and port cost, the Effective >Peering Range for ATM/OC-12 Peering is a narrow 236Mbps to 375Mbps with a >Minimum Cost of Traffic Exchange of $69/Mbps. The GigE/OC-12 equivalent >range is 109Mbps-466Mbps with a Minimum Cost of Traffic Exchange of $25/Mbps. > >What was unexpected in this analysis was the Effective Peering Range Gap. >When an ISP upgrades the ATM OC-3 to OC-12, the gap between the Effective >Peering Bandwidth of the OC-3 (90Mbps) and the Peering Breakeven Point (the >point at which the Peering Costs are totally offset by the cost savings of >peering vs. transit) at 208Mbps is huge. This 118Mbps gap is where an ISP >should rationally prefer to purchase transit until 208Mbps can be sent in >peering relationships over the ATM fabric, and only then upgrade the >peering connection to OC-12! > >There is also an Ethernet EPR Gap but it is only about 40 Mbps, and once at >the GigE/OC-12 capacity, it gets you an Effective Peering Range up to 475Mbps. > >In any case, this is the analysis that the paper walks through, and since >the spreadsheets are in the paper, one can muck around with the assumptions >and cost points, key of which are: > 1) ATM OC-3 Port Cost $8000/mo, ATM OC-3 Circuit Cost $3000/mo, > ATM OC-12 Port Cost $17000/mo, ATM OC-12 Circuit Cost $8000/mo > 2) FastE Port & Rack Space $2500/mo, OC-3 Circuit $3500/mo, > GigE Port & Rack Price$5000/mo, OC-12 Circuit $7000/mo > 3) Transit Price: if you peer at OC-3, you probably pay $125/Mbps, >peer at OC-12,$110/Mbps > 4) ATM Overhead (aka cell tax): 20% > 5) Assumption that ISP upgrade capacity when avg utilization >75% >Effective Peering BW > >Let me know if you violently object to any of these data points. These are >culled from a lot of conversations in the field. The rest of the paper is >simply plugging these data points into the equations and analyzing the results. > >Bill > >At 04:36 PM 8/7/2002 -0700, William B. Norton wrote: > >>Hi all - >> >>I've been working with a number of ISPs on a research paper that builds on >>the previous peering research papers (Internet Service Providers and >>Peering, A Business Case for Peering, The Art of Peering, Interconnection >>Strategies for ISPs, etc.) that applies the Peering Modelling tools in a >>comparison of ATM and Ethernet-based Internet Exchanges. Both of these >>IXes are compared against each other and against the cost of buying >>transit. The paper applies recent price quotes for transport and transit, >>costs for ATM and Ethernet-based IX participation, to answer the question: >> >> Do ATM-based Exchange Points make sense anymore? >> >>I'd like to speak with additional ISP Peering Coordinators and Network >>Architects (preferable ones that have experience with peering across both >>ATM and Ethenet-based IXes) to walk through this paper and help me check >>that I have the technical and business details right. I would need about >>20 minutes or so on the phone to walk you through the paper, the financial >>models, the cost points, and get feedback on the conclusions...preferably >>sometime in the next couple weeks. >> >>If you are a Peering Coordinator I think you will find at least a couple >>of findings in this research *very* interesting. In any case, if you can >>help, please send me an e-mail at wbn(a)equinix.com and let me know when we >>could chat. >> >>Thanks - >> >>Bill >> >>PS - As with any these Peering White Papers, this white paper will be >>freely available once enough folks have walked through it and verify that >>we have things right. >> >>------------------------------------------ Abstract >>--------------------------------------------------- >>During the NSFNET transition from the Authorized Use Policy Internet to >>the Commercial Internet, several Network Access Points (NAPs) were created >>to facilitate the traffic exchange between the Internet Service Providers, >>two of which were ATM-based. Internet Service Providers were initially >>required to connect to three of the four NAPs in order to receive NSF >>funds (indirectly through their NSF-sponsored customers) during this >>transition period. >> >>During the years that followed, this requirement was dropped and the costs >>models of Internet Operation have changed dramatically. Technologies such >>as Wave Division Multiplexing and Long Haul Fiber Improvements have led to >>radical a decrease in the cost of transport and a corresponding drop in >>the price of transit. At the same, the cost of peering at ATM-based >>exchange points has not substantially dropped in cost, leading to the >>question in the Peering Coordinator Community: >> >> "Do ATM-based Internet Exchange Points make sense anymore?" >> >>In this paper we apply the peering financial models to this question, >>using current market prices to compare the price of transit against the >>costs of peering at ATM-based NAPs and Ethernet-based Internet Exchange >>Points. We build upon the previous research on Peering by introducing the >>notion of an Effective Peering Range (EPR) to describe the "useful life" >>of an Internet Exchange. We also highlight a potentially costly EPR Gap, >>an interim range between Peering Capacity points where peering is more >>expensive than transit. >> >>The financial models presented that produced the graphs are included in >>the Appendix so that ISPs can apply these cost models to their specific >>situation. > >--------------------------------------------------------------------------- >------------------------------------ >William B. Norton <wbn(a)equinix.com> 650.315.8635 >Co-Founder and Chief Technical Liaison Equinix, Inc. >Yahoo Instant Messenger ID: WilliamBNorton >

4 3

laissez-faire DNS
by jnull 10 Aug '02

10 Aug '02

<all the standard disclaimers> Those whom I'm speaking to know the security and routing vulnerabilities associated with name resolution. (others, some background: http://citeseer.nj.nec.com/schuba93addressing.html , http://citeseer.nj.nec.com/lioy00dns.html) Anyway, I wish I were providing solutions or even offering new information. Instead, I'm looking for some insight. It has come to my attention that some ISPs and most web-hosting companies I've researched allow their customers to freely configure their forward and reverse DNS through some sort of interface or ticket submission, neither of which goes through any sort of validation. This not only poses a serious security risk to their customers, but to any domain one of their customers choose to hi-jack. The argument of these companies is "there is not real validation process available" that "registrars list disclaimers with their whois information [that it may not be valid]" and "the hundreds of changes and discrepancies reported [each month] would cost too much administratively". While I see the validity in their arguments, I cannot help but to shutter at the possible repercussions of giving into such obstacles. Is it so impossible to implement an authentication process that could be script automated--at least weeding out all but the most dedicated poisoner? I've toyed around with a couple solutions I would like some input from "the inspired" before I attempt to publish anything. (And, props to Vixie for his work continuous work on Bind and those engineers collaborating on DNSSEC) j

1 0

The Cidr Report
by CIDR Report 10 Aug '02

10 Aug '02

This is an auto-generated mail on Fri Aug 9 23:00:01 PDT 2002 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. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. NEW: Check http://www.employees.org/~tbates/cidr-report-region.html for the regional version of this report. NEW: Check http://www.employees.org/~tbates/autnums.html for a complete list of autonomous system number to name mappings as used by the CIDR-Report. 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 amount of withdrawls. 3) Interesting aggregates Interesting here means not an aggregate made as a set of classful routes. Thanks to GX Networks for giving me access to their routing tables once a day. Please send any comments about this report directly to CIDR Report <cidr-report(a)cisco.com>. ------------------------------------------------------------------------------ CIDR REPORT for 09Aug02 0) General Status Table History ------------- Date Prefixes 020802 112557 030802 112425 040802 112467 050802 112471 060802 112574 070802 112311 080802 112696 090802 112833 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: 13412 Number of ASes announcing only one prefix: 8157 (4598 cidr, 3559 classful) Largest number of cidr routes: 710 announced by AS3908 Largest number of classful routes: 1210 announced by AS701 1) Gains by aggregating at the origin AS level --- 09Aug02 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS1221 1090 836 254 23.3% Telstra Pty Ltd AS701 1210 970 240 19.8% UUNET Technologies, Inc. AS17557 295 101 194 65.8% Pakistan Telecom AS6595 223 55 168 75.3% DoD Education Activity Network As AS852 546 405 141 25.8% Telus Advanced Communications AS16473 196 75 121 61.7% Bell South AS7018 798 680 118 14.8% AT&T AS4151 238 143 95 39.9% USDA AS19632 99 5 94 94.9% Metropolis Intercom S.A. AS12302 120 27 93 77.5% MobiFon S.A. AS7303 159 68 91 57.2% Telecom Argentina Stet-France Tel AS16814 105 20 85 81.0% NSS, S.A. AS226 171 88 83 48.5% Los Nettos AS1239 500 418 82 16.4% Sprint AS1 457 382 75 16.4% GENUITY AS7046 293 219 74 25.3% UUNET Technologies, Inc. AS577 267 193 74 27.7% Bell Advanced Communications Inc. AS2048 178 104 74 41.6% State of Louisiana AS4755 200 129 71 35.5% Videsh Sanchar Nigam Ltd. Autonom AS4323 411 340 71 17.3% Time Warner Communications, Inc. AS2149 327 257 70 21.4% Performance Systems, Inc. AS724 222 159 63 28.4% DLA Systems Automation Center AS4293 246 185 61 24.8% Cable & Wireless USA AS3464 165 104 61 37.0% Alabama SuperComputer Network AS19834 64 4 60 93.8% NetForce, Inc. AS10620 85 25 60 70.6% TVCABLE BOGOTA AS9498 86 29 57 66.3% BHARTI BT INTERNET LTD. AS5515 243 186 57 23.5% Sonera Finland Autonomous System AS16758 63 6 57 90.5% IKON Office Solutions AS3908 286 230 56 19.6% Supernet, Inc. Total 55400 42650 12750 23.0% 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

1 0

(no subject)
by dalph＠hushmail.com 09 Aug '02

09 Aug '02

On Wed, 7 Aug 2002, Ralph Doncaster wrote: > What would be useful in all this discussion would be if someone gives a > list of "good" root servers to put in my named.boot. > i.e. generally fast response time and no blocking prefixes What would be even more useful would be if you read up on how BIND works. As long as you have one reachable root server in your hint zone you'll end up with them all in your cache. - Dalph Roncaster Communicate in total privacy. Get your free encrypted email at https://www.hushmail.com/?l=2 Looking for a good deal on a domain name? http://www.hush.com/partners/offers.cgi?id=domainpeople

5 4

Re: your mail
by blitz 09 Aug '02

09 Aug '02

Absolutely..the corporate culture are whores, and not to be trusted...protect yourselves, use a throw-away email addy.. At 17:16 8/9/02 -0400, you wrote: >Don't forget general kookery where you make a customer mad, a >usenet poster, or some other irrational personality and they >contact your employer to detail everything they know about >you like posting to rec.cannabis, soc.motss, etc. It's >interferring in a business relationship, but most of 'em >don't care. > >I'm all for anonymity -- even here.

1 0

Fwd: WorldCom Fraud News: Man these thieves just don't quit..
by blitz 09 Aug '02

09 Aug '02

OOps..our looting figures have been revised upwards... >WorldCom Investor News: WorldCom Announces Additional Changes To Reported >Income For Prior Periods. CLINTON, Miss., August 8, 2002 - WorldCom, Inc. >today announced that its ongoing internal review of its financial >statements has discovered an additional $3.3 billion in improperly >reported earnings before interest, taxes, depreciation and amortization >(EBITDA) for 1999, 2000, 2001 and first quarter 2002. > >View full press release at >http://www1.worldcom.com/global/about/news/news.xml?newsid=4111&mode=long&l….

1 0

Re: your mail
by JC Dill 09 Aug '02

09 Aug '02

On 02:42 PM 8/8/02, Scott Granados wrote: > >Do people really almost get fired for what they write here? Sometimes, it's not "almost". Just 3 months ago: <http://www.merit.edu/mail.archives/nanog/2002-05/msg00208.html> >I would like to take this opportunity to publicly shame eBay, who decided >to fire one of their engineers for disclosing their "proprietary" methods >for defending against DoS in the recent NANOG thread. jc > I'd think >there would be more constructive things to do by management than read >nanog for questionable posts. If I were managing someone and they >posted their feeling on a subject and clearly said it was their own who >am I to have a problem with that. It might be in my best interest and >listen to them then silence them. > >On Thu, 8 Aug 2002, Ukyo Kuonji wrote: > >> >> Sorry, but there are valid reasons for posting anonymously. As one person >> that almost got fired from a company for expressing what was clearly marked >> as his own opinion to this list, I can attest to this. Some employers are >> concerned that you post during working hours, some are concerned that you >> use a work address, some are concerned that anything you say, no matter what >> email you use, will be considered as representations of the company's >> direction, even if it is clearly marked as not. >> >> I like helping and sharing my opinions, but I'm not willing to loose my job >> over it. >> >> UK >> >> >Date: Thu, 8 Aug 2002 00:13:22 -0400 (EDT) >> >From: Brian Wallingford <brian(a)meganet.net> >> > >> >Perhaps it's time to bar posting privileges from those who insist on >> >remaining entirely anonymous? >> > >> >I doubt that anyone who has anything substantive to offer would need to >> >use a hushmail/yahoo/etc. return address. >> > >> >The initial posts from Bandy, Vaul, et al were mildly amusing at first, >> >but the novelty wore out very quickly. >> >> >> _________________________________________________________________ >> Send and receive Hotmail on your mobile device: http://mobile.msn.com >>

4 3

Re: RFC 2870's applicability (Re: Deaggregating for emergency purposes)
by Paul Vixie 09 Aug '02

09 Aug '02

> > When I tell USG how I feel, they seem to ignore me. Your mileage may vary. > > True enough. But their machines could always be removed from the > list of known root servers, and I don't think that there's much they > could do about it. that is absolutely false, in several different ways.

1 0