April 1999 - Test - lists.nanog.org

NETOPS PLANNING: april 23-25 in Washington DC
by Sean Donelan 20 Apr '99

20 Apr '99

Those ISPs without equipment in Washington DC may not be aware of it, but from April 23-25 the city will be a bit chaotic. The NATO meeting will have 42 ministerial delegations in town on those dates. What's this got to do with ISPs? Hopefully not much. However, its been a bit difficult getting accurate information from the US Secret Service about exactly what streets will be closed, and precisely which areas of the city will be in the exclusion zone. For example, it is unclear whether we will be able to enter a building that faces a closed street. Several major Internet circuits and facilities happen to run through and adjacent to these zones. A backhoe incident is unlikely. However, many facilities will be running unattended. It may not be possible for us or other ISPs to get into the area or our facilities at 3am to reboot routers. Please have patience, if they go down, we will get them back up as soon as we can. I may have a bit of trouble trying to explain why a person with a Missouri driver's license needs to get into the area. If you are not familiar with Washington, DC; Mae-east is located well away from the excitement and should be unaffected. However, other ISPs may also have equipment in the central part of the district, and may have similar problems to us. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

2 1

Re: The future of NAPs & IXPs
by Vadim Antonov 19 Apr '99

19 Apr '99

All is well but you missed one of the most critical issues with the current IXPs: lack of scalability. The private point-to-point interconnects are at least as fast as backbones. Fixing IXP scalability issues requires somewhat radical departure from the current router architecture; such as being done by terabit router vendors. In other words, even if multi-party IXPs are more cost-effective, they are currently (and in the near-term future) unable to handle the load. Also, the number of interconnects (IXPs or direct) cannot be large because of flap-amplification properties of the inter-backbone connections. (BTW, O(5) can be an arbitrarily large fixed number, simply speaking :) --vadim William B. Norton <wbn(a)equinix.com> wrote: >For what it's worth...I just finished a paper that highlights the trade >offs between the direct circuit interconnect model and the exchange point >interconnection model for ISPs. The paper discusses the operations and financial models (taking into account the circuit costs, cost of exchange participation, cost of dark fiber, etc.) and the implications of these strategies across the # of interconnection participants and bandwidth utilization between the participants. To cut to the chase, the major points from the paper: >1) For ISP interconnection, direct circuit interconnection is financially >attractive for low #s of connections (O(5)) of relatively low bandwidth >(DS-3/OC-3). >2) As the bandwidth and # of interconnections grow, the exchange point >interconnection model proves much more scalable for two reasons: First, as >bandwidth grows between participants, ISPs are able to aggregate >interconnection traffic over increasingly large pipe back to their cloud, >yielding potentially significant economies of scale. The direct circuit >interconnection does not provide for this aggregation since the pipes are >destined to different plances.

3 2

DOD mulls Internet disconnect (Re: The future of NAPs and IXPs)
by Sean Donelan 19 Apr '99

19 Apr '99

>> providers to troubleshoot, etc. The greater the dependence on >> interconnection, the more hardened you want that interconnection environment. > >It's worth pointing out, as a sidebar to that, that the greater the >dependence on interconnection, the more hardened it's _feasible_ to make >that interconnection environment, assuming you've rolled your numbers >right. Staying on the proper side of that curve is important... Don't fall into the trap of thinking you can harden anything enough. The Internet was built on the assumption diversity buys reliability better than hardening. To this day, it seems to be a hard thing to do in practice. It is much easier to adopt the bunker mentality, and try to protect it all behind one big wall. Which doesn't work much better in practice, but pays consultants a lot better. Normally, I wouldn't assume Lt. Generals understand technical matters very well, prefering instead to listen to majors and below. I have no clue what the Lt. General is thinking changing .mil to .com will do for security. http://www.fcw.com/pubs/fcw/1999/0419/fcw-newsdod-4-19-99.html I wonder if the Lt. General realizes the damage he may end up doing. Some of us "outsiders" have long relied on information from the military web sites to help us improve the design of our own infrastructures. Which in turn the government relies on to carry out its mission. It is a fallicy to think you can provide the information needed to protect the network to just one or two "cleared" companies. I'm not "cleared," yet I still need provide information assurance services to my clients. It would be a shame if a hacker chopped three "zeros" off a defense spending bill. I thought the government had figured there is more interdependence between all levels after all its critical infrastructure studies in the last couple of years. Sorry, I just had to vent. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

2 1

Re: The future of NAPs & IXPs
by William B. Norton 19 Apr '99

19 Apr '99

Ed- Sorry for the delay in posting a response; there were issues with the nanog-post list. Who created that thing anyway ;-) At 03:09 PM 4/15/99 -0400, etignor(a)rhsmith.umd.edu wrote: > >I would like to know what net professionals think about the future of NAPs & >IXPs. For what it's worth...I just finished a paper that highlights the trade offs between the direct circuit interconnect model and the exchange point interconnection model for ISPs. The paper discusses the operations and financial models (taking into account the circuit costs, cost of exchange participation, cost of dark fiber, etc.) and the implications of these strategies across the # of interconnection participants and bandwidth utilization between the participants. To cut to the chase, the major points from the paper: 1) For ISP interconnection, direct circuit interconnection is financially attractive for low #s of connections (O(5)) of relatively low bandwidth (DS-3/OC-3). This is due to the fact that ISPs typically pay only half of the cost for the direct circuits between each other while they pay the full freight for the big pipe into the exchange. ISPs may want to use the exchange for a POP, but barring use like that, if all you want to do is exchange traffic with these other 4 folks into the foreseeable future, the direct circuit interconnect model makes some sense. 2) As the bandwidth and # of interconnections grow, the exchange point interconnection model proves much more scalable for two reasons: First, as bandwidth grows between participants, ISPs are able to aggregate interconnection traffic over increasingly large pipe back to their cloud, yielding potentially significant economies of scale. The direct circuit interconnection does not provide for this aggregation since the pipes are destined to different plances. Secondly, operationally, fewer backhoes in an exchange, fewer local loop providers to troubleshoot, etc. The greater the dependence on interconnection, the more hardened you want that interconnection environment. 3) Several of the exchanges also provide for the centralization of content allowing additional transit sales revenue that potentially dwarf the cost savings highlighted above for interconnection. The direct circuit interconnect model doesn't allow for this additional revenue opportunity. 4) The analysis finds that facilities-based ISPs win big since (being able to exploit WDM technologies) they can seamlessly grow the pipe(s) into the exchange while the direct circuit interconnection model can't take advantage of this level of aggregation. IMHO, these are the most compelling reasons the IXP will be around for some time. I can make the white paper with the plots and data available to you if you like. >Given UUNET's inclination to peer only with national backbone providers, what is >the future of settlement free peering arrangements? > >Will non-profit, cooperative organizations that require multilateral peering to >participate (LINX) survive or thrive going forward, or will we see more for >profit NAPs run by Sprint and co. run the non-profits out of business? There are some scale issues that come into play that non-profits have to grapple with. For example, the resources required to build and operate a commercial grade operations environment from scratch (building close to fiber, HVAC, Generators, UPSes, Power, Security Systems, 24/7 Staffing, etc.) with sufficient redundancy excludes most non-profits from at least the high end of the market. Part of the challenge is achieving the critical mass to take advantage of economies of scale to compete. Another issue is, even if a non-profit could, what would be the motivation to expend the capital? Is it in their charter for a non-profit organization to do so, and why would that non-profit organization want to compete against a for-profit doing the same thing? In the US, IRS regulatory issues pop up too, and the tax exempt status may be challenged if too much revenue is generated in this new line of the business. >Will co-operative IXPs proliferate in regional markets? Will this give small >ISPs, acting collectively, more leverage with the larger carriers (Exodus and >GTE )? > >I know these aren't truly operational question, but peering and transit is an >issue that will have an impact on the international infrastructure and may >result in increased regulation in the future. Are there other lists where >people might have some thoughts about these issues? The answers to these two are too long (and contentious) to answer here. Since you're in Maryland anyway, I am chairing a panel (with Dave Diaz, Bill Manning, and Dave Rand) in a few weeks at ISPCON in Baltimore that will discuss several of these topics. We'll be focusing on definitions and highlighting experiences in the field. This might be of interest to you and we can talk off-line there if you want. Bill ---------------------------------------------------------------- William B. Norton <wbn(a)equinix.com> +1 650.298.0400 x2225 Equinix Director of Business Development

2 1

Call before you dig
by Sean Donelan 18 Apr '99

18 Apr '99

woody(a)zocalo.NET (Bill Woodcock) writes: >Okay, so basically the deal was that there were a zillion (like 200) >different "call before you dig" hotlines for different areas, and you had >to track down the correct one, and there weren't a lot of penalties for >not having one for an area, et cetera. Then in 1997, there was a federal >house bill to unify it all, it carried over to 1998, and then actually >passed around May or June sometime, as part of the Omnibus Federal >Transportation act. The upshot of that is that there's one 888 number for >the whole country now, and states lose a portion of their federal highway >funds if they don't get the utilities which their PUCs regulate to >participate in the program. Its still a bit early to tell if the One-Call legislation made any difference. Only two quarters of information has been reported, and one quarter was down, and the following quarter was up. However, there are still a lot of cases where the excavator did call, but the utility either didn't mark, marked the wrong place, or didn't mark all the lines. As Bill points out, the Department of Transportation is the federal agency in charge of One-Call. States can get a $1M-$5M federal grant for setting up a One-Call coordinator for their state. But there is no national GIS database, nor any truely common way of describing where everything is. After getting a call, the One-Call people will forward the information to the listed contact for all registered utilities in a particular geographic grid. It is then up to each of those contacts to go out and mark their clients' lines. Sometimes a group of utilties will hire a common contractor to mark all of their lines, other utilties send their own people. Sometimes a utiity will forget they had lines in a particular area, and fail to register that grid with the One-Call people. Some companies consider their maps proprietary, and won't allow anyone else to see or use them. Other company maps are just plain wrong. With deregulation, there is no longer just "the phone company" or just "the water company." Multiple companies may have the same type of lines in an area. The marking contractor for one company won't necessarily mark the lines for a different company (or even a different subsidary of the same company), or even alert the excavator he know's there is another company's lines he didn't mark. Its kinda of like another ISP trying to get the SPRINT NOC to open a trouble ticket. There is a bit of tit-for-tat going on. Even after you have all the colors marked on the ground, you are never really sure just what's missing until you start digging. National Call Before You Dig = 888-258-0808 -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

2 1

SEMI OPERATIONAL CONTENT - outage info
by scott w 17 Apr '99

17 Apr '99

Seems an auger took out 3 OC-192s in the Dallas area. Can we get back to the t-shirt thread and make it an auger instead of a backhoe? :) That's 29.859 Gbps! Or 387,072 DS0s! I hope that since the outage affects many of us the flamethrowers will be on stun only (not kill... ;) scott

3 2

Re: Sprint 1999 NOC contact drill
by Sean Donelan 16 Apr '99

16 Apr '99

Well, there was another major fiber cut today (Friday) partioning a couple of large networks, so I stopped calling before I made it through the entire list. I'll pickup where I left of on Monday. For those interested here is the preliminary count so far 62 attempted contacts 45 verified working contacts It seems to be going slower this time due to a large number of ACD systems with very long waiting times and which usually drop the call after you've been on hold for a while. There have also been a large number of mergers in the last year, and phones are being forwarded in some very bizzare ways, to people who really have no idea what they are doing. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

The Cidr Report
by Tony Bates 16 Apr '99

16 Apr '99

This is an auto-generated mail on Fri Apr 16 12:00:00 PDT 1999 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 16Apr99 0) General Status Table History ------------- Date Prefixes 090499 58050 100499 58045 110499 58080 120499 58147 130499 58117 140499 58177 150499 58448 160499 58374 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: 3500 Number of ASes announcing only one prefix: 1134 (0 cidr, 1134 classful) Largest number of cidr routes: 0 announced by Largest number of classful routes: 815 announced by AS701 1) Gains by aggregating at the origin AS level --- 16Apr99 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS271 355 147 208 58.6% BCnet Backbone AS4293 290 183 107 36.9% IMCI AS226 206 100 106 51.5% USC/Information Sciences Institut AS174 586 492 94 16.0% Performance Systems International AS577 270 177 93 34.4% Bell Canada Backbone AS4755 168 78 90 53.6% Videsh Sanchar Nigam Ltd. India AS2493 219 131 88 40.2% iSTAR Internet, Inc. AS1785 457 369 88 19.3% NYSERNet Backbone AS3749 141 63 78 55.3% TECNET AS4200 167 96 71 42.5% AGIS (Apex Global Information Ser AS1267 94 24 70 74.5% IUNET-AS AS7496 96 30 66 68.8% Power Up AS7545 110 46 64 58.2% TPG Internet Pty Ltd AS1221 445 381 64 14.4% AARNET-AS AS7046 258 197 61 23.6% UUNET-CUSTOMER AS4740 339 278 61 18.0% Ozemail Pty Ltd (ASN-OZEMAIL) AS7657 180 121 59 32.8% The Internet Group Limited AS1239 526 467 59 11.2% SprintLink Backbone AS10928 110 52 58 52.7% UNKNOWN AS72 92 40 52 56.5% Schlumberger Information Network AS719 464 412 52 11.2% LANLINK autonomous system AS3493 233 182 51 21.9% INTERLINK AS5674 80 36 44 55.0% PBI-NET-BLK AS3737 110 70 40 36.4% PenTeleData Inc. (ASN-PTD) AS803 74 38 36 48.6% SaskNet Backbone AS7745 39 4 35 89.7% BIGSKY-AS AS1 505 470 35 6.9% BBNPLANET AS7122 111 78 33 29.7% MTS ADVANCED Network Policy AS4307 32 1 31 96.9% SVINET-1 AS11515 32 1 31 96.9% UNKNOWN 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

Survey
by Ira Richer 16 Apr '99

16 Apr '99

The FCC has chartered the Network Reliability and Interoperability Council (NRIC) to address a number of issues about the reliability of communications systems, primarily traditional telcos. One of the issues being addressed is a determination of what information about outage data is being collected by "other industry segments" -- i.e., communications industries other than telcos. This includes, e.g., cable, satellite, paging, and ISPs. Wearing my hat as Executive Director of IOPS, I am a member of the subcommittee that is doing this work. In order to get as broad a response as possible from ISPs, I am sending this message to the NANOG mailing list, soliciting your participation in a questionnaire being conducted by the subcommittee. If you might be interested in participating, please send an email note to John Healy, who is copied on this message. He will then send you softcopy of the questionnaire. All data collected from companies will be protected and treated as proprietary. The information will be aggregated on an industry-wide basis and not by company. The questionnaire is straightforward and will take very little time. I encourage you to support this data-collection effort. Ira Richer

1 0

ARIN Whois unreachable at 0220 MDT
by John M. Brown 16 Apr '99

16 Apr '99

It would seem that ARIN's whois server is not responding as of 0220 MDT.. Traceroutes show *** after dca1-core4-fa6-0-0.atlas.digex.net (165.117.16.4) I don't know if thats the upstream side for ARIN or not. Just an lert...

2 1