- NANOG - lists.nanog.org

Draft NANOG agenda
by Susan R. Harris 12 Oct '00

12 Oct '00

Greetings - here's the draft agenda for NANOG 20 in DC: ------------------- SUNDAY TUTORIALS Time Topic/Presenter ---- --------------- 1:30 - 3:00 p.m. Introduction to Protection Mechanisms: How to Make IP Networks More Robust (Jonathan Sadler, Tellabs ) 1:30 - 3:00 p.m. Introduction to IS-IS (Abe Martey, Cisco) 3:00 - 3:30 p.m. BREAK 3:30 - 5:00 p.m. ISPs and Federal Privacy Law: Everything You Need to Know About the Electronic Communications Privacy Act (Mark Eckenweiler, Department of Justice) MONDAY GENERAL SESSION 9:00 a.m. Welcome, Introductions (Susan R. Harris, Merit & Cleve Mickles, AOL) 9:15 a.m. Panel: Meet the Regulators Robert Cannon, FCC, moderator ISP Reliability Pamela Aduskevics, ATT/FCC Network Reliability & Interoperability Council Wireless Developments Dale Hatfield, FCC Office of Engineering and Technology Broadband Deployment Rebecca Dorch, FCC Office of Engineering and Technology Cable Open Access Robert Cannon, FCC Office of Plans & Policy 10:45 a.m. BREAK 11:00 a.m. Carnivore Update (Marcus Thomas, FBI) 12:00 p.m. LUNCH 1:30 p.m. The Impact of Internet Policy and Topology on Delayed Routing Convergence Craig Labovitz, Microsoft Research/Merit Abha Ahuja, Internap/Merit Roger Wattenhofer & Srinivasan Venkatachary, Microsoft Research 2:00 p.m. Panel: Service Provider Route Filtering Danny McPherson, Amber Networks, moderator Randy Bush, Verio Vijay Gill, MFN Alex Bligh, GXN Tony Tauber, Genuity 3:00 p.m. BOF Intro: PGP Key Server Network Stability (Len Sassaman, PGP Security) 3:15 p.m. BREAK 3:30 p.m. MAE Evolution (Thomas Bechly, WorldCom) 4:00 p.m. Panel: Evolution of IXP Architecture Steve Feldman, Sigma Networks, moderator Paul Vixie, PAIX/MFN Bill St. Arnaud, CANARIE Lane Patterson, Equinix Mike Hughes, LINX 5:30 - 7:30 p.m. Beer 'n Gear Monday Evening BOFs 7:30 - 9:00 p.m. Peering BOF III (Bill Norton, Equinix) PGP Key Server Network Stability (Len Sassaman, PGP Security) 9:00 - 10:30 p.m. IP-Centric Control and Management of Optical Networks (Debanjan Saha & Bala Rajagopalan, Tellium) Very Short Reach (VSR) OC-192/STM-64 Interfaces (Russ Tuck, Pluris) TUESDAY GENERAL SESSION 9:00 a.m. Global Server Load Balancing Dmitri Krioukov, Nortel (Alex Kit, Winstar Communications) 9:30 a.m. Multicast Performance Measurement on a High-Performance IP Backbone (Robert Beverly, MCI WorldCom) 10:00 a.m. Towards Millisecond IGP Convergence (Centiz Alaettinoglu, Van Jacobson, & Haobo Yu, Packet Design) 10:30 a.m. BREAK 10:45 a.m. The Impact of P3P for Network Operators (Eric Brunner, Engage) 11:15 a.m. Identifying the TCP Behavior of Web Servers (Sally Floyd & Jitendra Padhye, Aciri) 11:45 a.m. A Request for Information about the Deployment of RED (Sally Floyd, Aciri) 11:50 a.m. Proposed Changes to the BGP Specification (John Scudder, Cisco) 12:20 p.m. SURFnet5: Building the Next-Generation Internet in The Netherlands (Erik-Jan Bos, SURFnet) 12:50 p.m. Closing Remarks (Susan R. Harris, Merit) 1:00 p.m. Adjourn

1 0

router damaged by cracker?
by Kai Schlichting 12 Oct '00

12 Oct '00

If we assume that the router mentioned in the following cracking incident is a popular model we all use: what other than zapping the FlashROM could this attacker have done? We all know that <big popular vendor>'s firmware source code has hit the pirate BBS's a year or two back : could someone have compiled a rogue image that can actually fry some router components (I can think of plenty of nasty things with serial ports transmitting too fast for their own good - and burn the driver chips) ? http://www.denverpost.com/business/biz1012d.htm

3 2

Power monitoring Re: Power Outage in Chicago Loop
by Sean Donelan 12 Oct '00

12 Oct '00

On Sun, 08 October 2000, Kevin Day wrote: > I'm currently about 30 miles north of the loop... at 12:46 the voltage > coming into the building here was 140-160 volts for several minutes(according to > our UPS). I'm wondering if the power was just going nuts everywhere else, > causing ameritech equipment to go nuts. Possible explaination for packet > loss? After my first summer in PG&E country, I've been wondering if there was a way for ISPs to share power quality data about the local utility. For the most part, every ISP in a region experiences the same woes and problems of the electric utility. Most ISPs are capable of at least minimal monitoring. If the shared data was limited to only the upstream side of the ISPs power system, it would show the performance of the utility; but ISPs could still keep any internal problems secret. While a power quality meter would be nice, even SNMP capable UPSes can report basic data. One of the reasons I'm interested is I've needed to research what things like the CBEMA curve really means, and discovered how little hard data exists about power and computer centers. Almost all the data comes from three studies in the 1970's by IBM, Bell Labs and the US Navy. Since then we've transitioned from mainframes to minicomputers to pc's; and the power supply industry is undergoing deregulation. Like most industries, there are academics who would love to crunch any data they could get. The question is how much data could we get. What's in it for ISPs? Essentially the same things as when IBM, Bell Labs and the US Navy did their studies two decades ago. What should we design our systems to handle? Are things really as bad as the UPS and surge protection vendors lead us to believe? What is "normal" power throughout the country? How severe can power get?

4 4

RE: BGP quandary
by Leo Nelson 11 Oct '00

11 Oct '00

I do not claim to be a BGP guru but here is my take. If my take is way of base I would like to here from our BGP guru's here Thanks leo -----Original Message----- From: Timothy Brown [mailto:tcb@ga.prestige.net] Sent: Wednesday, October 11, 2000 10:15 AM To: nanog(a)merit.edu Subject: BGP quandary This may be an obvious answer, but, like some obvious answers, you just never get the clue, even though you struggle over it. I have four routers in a network. Two of the routers have no external peers, two of them have two peers a piece. The diagram looks like this: p1(e) p2(e) p1(e) p2(e) / / / / .-------. .--------. | rtr_1 | | rtr_2 | `-------' `--------' | (i) | (i) .-------. .--------. | swr_1 |--------| swr_2 | `-------' `--------' | | ------------------------------------- | | | fw fw fw p1 (AS12345) and p2 (AS12346) are the same AS across both routers, but connected to different pops. so on rtr_1, p1 may go to sjc, but on rtr_2, p1 may go to lax, even though it's the different AS. !# This is a bit confusing to me p1(AS12345) is p1 no matter what rtr connects to it or where it connects. Same goes for p2(As12346). My quandary is this: I want to advertise my best path to swr_1 and swr_2. the line between swr_1 and swr_2 is a trunk; e.g., they're one piece of broadcast media, but they both have routing cards in them to process IP packets (and BGP). my problem is, rtr_1 is going to select a best path from p1 and p2, and advertise it to whoever his peers are. rtr_2 will do the same, but with the additional caveat that rtr_1 may advertise his best path to rtr_2, giving rtr_2 three paths to choose from in this example (assuming p1 and p2 only advertise one path to me a piece for the same netblock). !# This may be difficult to do if you want any type of redundant pathing. Both swr's will need a peering session (tcp connection) to both rtr's for redundancy(unless you don't care). Therefore I would suggest iGBP peering betwween the rtr's and swr's and not worry about the swr's making a decision. You can use dampening if you are worried about excessive cpu utilization. further complicating the issue, swr_1 and swr_2 have to accomplish the same task. i don't want those two boxes to have to deal with selecting a best path; I would like the best path pushed down from rtr_1 and rtr_2, but i'm not sure where i'm pushing it. !# The only way to get one "best path" pushed is to have only one peer, igrp or egrp or default route to the eBGP rtr. Ohterwise the routing protocol will make a decision on what route to inject into it's table based on the metric if more than one is recieved. the fw device will route to the swr devices, probably via HSRP, but if they don't do that via HSRP, they have to select an additional best path (based on network load) via IGP, deciding which swr to connect to (assuming they are capable of that). the swr devices will have to identify a way to route externally, which i'm also not sure of. I can see several options, all of which have significant disadvantages and weird routing behaviour. does anyone have any suggestions on how to solve this situation? tim

1 0

BGP quandary
by Timothy Brown 11 Oct '00

11 Oct '00

This may be an obvious answer, but, like some obvious answers, you just never get the clue, even though you struggle over it. I have four routers in a network. Two of the routers have no external peers, two of them have two peers a piece. The diagram looks like this: p1(e) p2(e) p1(e) p2(e) / / / / .-------. .--------. | rtr_1 | | rtr_2 | `-------' `--------' | (i) | (i) .-------. .--------. | swr_1 |--------| swr_2 | `-------' `--------' | | ------------------------------------- | | | fw fw fw p1 (AS12345) and p2 (AS12346) are the same AS across both routers, but connected to different pops. so on rtr_1, p1 may go to sjc, but on rtr_2, p1 may go to lax, even though it's the different AS. My quandary is this: I want to advertise my best path to swr_1 and swr_2. the line between swr_1 and swr_2 is a trunk; e.g., they're one piece of broadcast media, but they both have routing cards in them to process IP packets (and BGP). my problem is, rtr_1 is going to select a best path from p1 and p2, and advertise it to whoever his peers are. rtr_2 will do the same, but with the additional caveat that rtr_1 may advertise his best path to rtr_2, giving rtr_2 three paths to choose from in this example (assuming p1 and p2 only advertise one path to me a piece for the same netblock). further complicating the issue, swr_1 and swr_2 have to accomplish the same task. i don't want those two boxes to have to deal with selecting a best path; I would like the best path pushed down from rtr_1 and rtr_2, but i'm not sure where i'm pushing it. the fw device will route to the swr devices, probably via HSRP, but if they don't do that via HSRP, they have to select an additional best path (based on network load) via IGP, deciding which swr to connect to (assuming they are capable of that). the swr devices will have to identify a way to route externally, which i'm also not sure of. I can see several options, all of which have significant disadvantages and weird routing behaviour. does anyone have any suggestions on how to solve this situation? tim

1 0

Re: New Peering Point Mailing Lists
by Simon Lockhart 11 Oct '00

11 Oct '00

>BTW, it would be *real* good if the NAP's and ISP's can provide more >traffic statistics. It may help the customers to decide where and whom >to join, and help people who want to have a better understanding about >the network. I recall we used to have more traffic data a few years ago, >now, there is almost none in US. Currently, from what I have seen >recently, NORDUnet (http://www.nordu.net/) is the best ISP by far that >provides detailed traffic information.... I think you'll find that there's a few that are open (e.g. Abovenet http://www.above.net/traffic/ and ourselves [although we're not US based] http://support.bbc.co.uk/support/mrtg/internet/) A lot of the big corporates consider it confidential information (it gives away how good/bad they are or something). Simon -- Simon Lockhart | Tel: +44 (0)1737 839676 Internet Engineering Manager | Fax: +44 (0)1737 839516 BBC Internet Services | Email: Simon.Lockhart(a)bbc.co.uk Kingswood Warren,Tadworth,Surrey,UK | URL: http://support.bbc.co.uk/

2 1

Re: New Peering Point Mailing Lists
by Sean Donelan 11 Oct '00

11 Oct '00

Good idea. People interested in information about various exchange points, such as pricing, how much are cross-connects, who to contact, etc should start with http://www.ep.net/ It has links to essentially all of the functioning exchange points in the world. Most exchange points have web sites with contact information, and sometimes pricing and other details. I think more information is better than less information. On the other hand, it is very difficult to keep lots of different places up to date. Nevertheless, I'll end up subscribing to any list which has information. Disclaimer: I've run an XP in the past, and have a financial interest in companies operating several XPs. On Sun, 08 October 2000, Jeffrey Meltzer wrote: > Correct. I've created this list because in asking around a bit there > wasn't a resource for public discussions for those not currently in > the exchanges, and people seemed to not know where to post questions > to. (inet-access, nanog, isp-lists, etc). > > They're not necessarily just for NANOG type 'outage' messages, but for > general discussion on people looking for peers, finding out how much it > costs for a cable run, who to contact for info, and other general > chit-chat about the points.

2 1

Network Engineer (Cisco/StrataCom) Available
by Stephen K Davis 11 Oct '00

11 Oct '00

[If this information is not of interest to you, I apologize for the intrusion. As you draft your flame, please remember that I only sent a link and not an attachment. :) ] I am available for contract or sub-contract opportunities. Please find my resume at: http://www.geocities.com/skdavis HTML http://www.geocities.com/skdavis/skdres01.doc MS-Word Thanks, -Stephen -=*=-=*=-=*=-=*=-=*=-=*=-=*=- Stephen K Davis mailto:SKDavis@ParkAveTech.com Park Avenue Technologies, Inc. http://www.ParkAveTech.com 817-252-0792 office 817-252-0724 fax "This company is pledged to settle customer disputes through an arbitration program operated by the Better Business Bureau at Fort Worth"

2 1

Down UUNet DS3 in the SF area...
by Craig Holland 09 Oct '00

09 Oct '00

UUNet is having problems with a DS3 to the San Francisco area. All they would tell me is the TT # is 293854 and the remote router is in the LAX area. craig

1 0

Re: New Peering Point Mailing Lists
by Sean Donelan 09 Oct '00

09 Oct '00

On Sun, 08 October 2000, Jeffrey Meltzer wrote: > There doesn't seem to be any mailing lists existing specifically > for the public Peering Points. So, I've created a few. In my experience every public peering point has a mailing list associated with it. I've been subscribed to mailing lists for mae-east, mae-west, all the NAPs with address space managed by Bill Manning and ISI. I'm less familar with mailing lists for XPs outside the US, but most also have a mailing list associated with each exchange point. Sometimes the XP operator makes a big deal of only allowing certain people to subscribe to their list. But it is rarely difficult to find a member willing to forward messages. I'm subscribed to relatively few lists now, but I have messages forwarded to me all the time. I would prefer to subscribe directly, if only so I could manage my aliases better. But I understand a long time ago the XP operator promised its membership it would only allow other members to subscribe to the list, so now they feel they can't change the rules.

4 4