- NANOG - lists.nanog.org

NANOG isn't NANOG anymore
by Craig Klingler 19 Nov '00

19 Nov '00

I'm working with a Japanese Company and for the first time realize what it means to say the Internet is Global. This company has a Tier 1 domestic backbone in Japan (covering the country of Japan and connecting to the Japanese major peering points). They also have partial ownership in undersea cables (fiber)that extend from Japan to the United States and Japan to the UK. So bandwidth and networking are not the problem. I'm sure my information is dated, but at one point I thought that 80% of all Internet traffic gets switched in the United States. Now, having studied the traffic patterns for our Japanese company and how much of the traffic stays in country, I would say I need to see some more data. But, I think I can safely say the United States handles the "lions share" of the global IP traffic, and will continue to do so until distributing hosting and caching make an impact. However, The NA in NANOG shouldn't apply any more. Political issues aside, at least ICANN saw fit to established three governing bodies for naming, ARIN, RIPE/NCC and APNIC. I write this more of an appeal, as this Japanese company wants to establish peering (not transit) in the US, and although by name, I recognize many of the "good old boys" in the Internet Tier 1 Backbone discussions, I am not one of them. I have read this list for some time now, but this is my first post. I have seen conversations ranging from graduate school discussions to school yard scuffles, so I am ready for my share of daggers. My question is, how does the Internet get opened up to new International companies, such as the one I am working for? I know this has been tried before via Savvis and a recent group that I know Exodus is part of. I also recognize there is as much brilliance in NANOG as there is sarcasm. If this was a business issue, the suits would have made their zillions and moved on, which is why I'm writing NANOG. Thank You, Craig Klingler klingler(a)onramp.net

1 0

NetRail Issue at MAE-West
by Joe Budion 19 Nov '00

19 Nov '00

NetRail's NOC currently has ticket 636 open for an outage at MAE-West. At least one NSP (SprintLink) continues to route traffic into the black hole of NetRail at MAE-West (the two also peer at AADS and other spots.) An equipment swap is needed to repair the equipment in question. Time required is unknown. This has been a day-long outage thus far. They claim to still be working the issue/ticket. #5 sl-bb21-stk-5-0.sprintlink.net (144.232.9.206): TTL Exceeded, ttl=251, 61 ms #6 sl-bb22-stk-15-0.sprintlink.net (144.232.4.242): TTL Exceeded, ttl=250, 60 ms #7 sl-w1-mae-1-0-0.sprintlink.net (144.232.8.1): TTL Exceeded, ttl=249, 60 ms #8 No response (): , ttl=, ms #9 at-1-1-1--3.pr1.Dallas2.Tx.us.netrail.net (205.215.61.106): TTL Exceeded, ttl=245, 992 ms #10 No response (): , ttl=, ms #11 at-0-2-0--0.tr1.Austin2.TX.us.netrail.net (205.215.63.157): TTL Exceeded, ttl=243, 681 ms #12 Zyan-100M.tse1.Austin2.Tx.us.netrail.net (209.44.90.74): TTL Exceeded, ttl=243, 180 ms ...lovely routing loop... TraceRoute - Saturday, November 18, 2000 14:36:52 #6 sl-bb21-stk-5-0.sprintlink.net (144.232.9.206): TTL Exceeded, ttl=251, 60 ms #7 sl-bb20-kc-11-0.sprintlink.net (144.232.9.205): TTL Exceeded, ttl=252, 60 ms #8 sl-bb20-kc-8-0.sprintlink.net (144.232.2.118): TTL Exceeded, ttl=252, 60 ms #9 sl-bb21-kc-8-0.sprintlink.net (144.232.2.117): TTL Exceeded, ttl=252, 60 ms ...and back to "normal"... #6 sl-bb20-chi-10-2.sprintlink.net (144.232.9.118): TTL Exceeded, ttl=251, 40 ms #7 sl-nap1-chi-0-0-0.sprintlink.net (144.232.26.237): TTL Exceeded, ttl=250, 30 ms #8 ameritech.netrail.net (206.220.243.58): TTL Exceeded, ttl=248, 40 ms #9 at-1-1-1--2.pr1.Dallas2.TX.us.netrail.net (205.215.61.113): TTL Exceeded, ttl=245, 91 ms #10 ge-0-0-0--0.tr1.Dallas2.Tx.us.netrail.net (205.215.61.149): TTL Exceeded, ttl=244, 100 ms #11 at-0-2-0--0.tr1.Austin2.TX.us.netrail.net (205.215.63.157): TTL Exceeded, ttl=243, 110 ms ...very flaky... It takes a different route every minute ;-) Unfortunately only one of the three passes traffic at an acceptable rate... Best regards, joe =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Joe Budion Client Services Representative DSL Provisioning www.CISP.cc - Changing Internet Speed & Performance -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

1 0

general PA and PGH uunet outages
by deeann mikula 18 Nov '00

18 Nov '00

i just got off the phone with uunet. kudos to them for the new feature of updating their telephone message with master ticket number for widespread damage. i learned from their message that is a fiber cut affecting PA, NJ and NY, even before i spoke to a tech. however, i was calling cause only one of our t1s dropped out. turns out i was one of the first callers (where's my prize?!) about another generalized problem, this one affecting some switches in the PGH area. master ticket for the PGH area is #308557 master ticket for the PA area is #cns308532 (this tt# transcribed quickly from message!) deeann m.m. mikula network administrator telerama internet -- http://www.telerama.com abuse@telerama.com/spam@telerama.com 1.877.688.3200x501

1 0

UUNet/Telia peering problem...
by Craig Holland 18 Nov '00

18 Nov '00

This is a message I sent to my netops team here, thought it might concern some of you, sorry if it doesn't. Anyone have some contact info for Telia NOC? FQDN can be completed w/ yahoo.com. <snip> It seems the telia router that peers w/ UUNet in NY is having BGP problems. Trace from thor.europe (same network as the tunnel router) to 157.130.252.102 go through xo/concentric net. this should go directly to the peering point in NY: thor:~$ traceroute 157.130.252.102 traceroute to 157.130.252.102 (157.130.252.102), 30 hops max, 40 byte packets 1 fjv1-r (194.237.109.204) 0.532 ms 0.321 ms 0.355 ms 2 fjv2-r (194.237.109.205) 0.522 ms 0.388 ms 0.340 ms 3 ov-i7-feth2-0.stockholm.telia.net (193.45.4.13) 0.511 ms 0.269 ms 0.282 ms 4 193.45.4.5 (193.45.4.5) 0.698 ms 0.697 ms 0.736 ms 5 sto-b1-pos4-0.telia.net (194.17.1.90) 1.071 ms 0.679 ms 0.690 ms 6 ldn-hex-b1-pos0-0.telia.net (193.45.4.90) 31.872 ms 32.470 ms 31.879 ms 7 ldn-th-i3-srp4-0.telia.net (193.45.0.133) 32.562 ms 32.706 ms 32.732 ms 8 gige5-0-llb-x-lx.TH29.core.rtr.xara.net (195.66.224.29) 32.767 ms 32.087 ms 32.020 ms 9 gb1-0-llb-x-many.TH30.core.rtr.xara.net (194.143.163.133) 32.794 ms 32.644 ms 32.069 ms 10 po1-0-llb-th30.HU1.core.rtr.xara.net (194.143.164.190) 99.123 ms 102.819 ms 99.080 ms 11 ge6-0.dist2.hud-ny.us.xo.com (64.220.3.82) 99.386 ms 98.748 ms 98.838 ms 12 p1-0.tran2.nyc-ny.us.xo.com (64.0.0.65) 99.486 ms 99.598 ms 98.875 ms 13 ge9-0.tran1.nyc-ny.us.xo.com (64.220.0.241) 99.257 ms 99.248 ms 99.387 ms 14 p0-0.tran1.was-dc.us.xo.com (64.0.0.41) 103.277 ms 104.095 ms 103.252 ms 15 a1-1-0d821.web1.ash-va.us.xo.com (208.36.132.34) 105.032 ms 106.652 ms 105.172 ms 16 208.36.112.100 (208.36.112.100) 105.834 ms !X^C ...You can see the proper path outbound from inferno.ny-office: inferno 17:32:55 ~ $ traceroute 194.237.109.250 traceroute to 194.237.109.250 (194.237.109.250), 30 hops max, 40 byte packets 1 63.99.168.1 (63.99.168.1) 1.033 ms 0.756 ms 0.786 ms 2 673.Hssi5-0-0.GW1.NYC2.ALTER.NET (157.130.252.105) 4.665 ms 291.ATM2-0.GW4.NYC1.ALTER.NET (157.130.252.101) 4.455 ms 4.002 ms 3 143.ATM2-0.XR1.EWR1.ALTER.NET (146.188.177.50) 4.286 ms 4.410 ms 176.ATM2-0.XR1.NYC1.ALTER.NET (152.63.18.50) 5.091 ms 4 193.ATM7-0.XR1.NYC4.ALTER.NET (146.188.178.53) 4.801 ms 195.ATM6-0.XR1.NYC4.ALTER.NET (146.188.178.82) 8.586 ms 193.ATM7-0.XR1.NYC4.ALTER.NET (146.188.178.53) 4.806 ms 5 189.ATM7-0.GW12.NYC4.ALTER.NET (152.63.22.73) 4.850 ms 5.015 ms 4.927 ms 6 Telia-gw.customer.ALTER.NET (157.130.5.74) 5.007 ms 5.262 ms 5.099 ms 7 ny-b1-pos1-0.telia.net (209.95.129.206) 9.794 ms 4.775 ms 13.205 ms 8 193.45.4.93 (193.45.4.93) 100.808 ms 100.937 ms 100.883 ms 9 193.45.4.2 (193.45.4.2) 111.213 ms 99.878 ms 101.399 ms 10 yahoo1-ov.k.telia.net (193.45.4.10) 103.977 ms 104.201 ms 103.846 ms 11 f0-1.telia-tep-rtr1.europe.yahoo.com (194.237.109.250) 111.320 ms 112.737 ms^C ...So, it seems UUNet is listening to BGP from Telia, but Telia isn't listening to BGP from UUNet. thanks, craig

2 1

Re: BGP testing?
by Sean Donelan 18 Nov '00

18 Nov '00

The MERIT folks had some records of real BGP traffic of millions of packets, and could play them back. You might poke around www.merit.edu. On Fri, 17 November 2000, "Timothy Brown" wrote: > Does anyone have a script or a series thereof to do large-scale BGP testing? > I'm looking for scripts that will generate and nail down several hundred > networks of varying sizes, and/or fake peering relationships with a similar > purpose, and/or do things that don't meet the BGP protocol standards, etc.

1 0

BGP testing?
by Timothy Brown 18 Nov '00

18 Nov '00

Hey folks, Does anyone have a script or a series thereof to do large-scale BGP testing? I'm looking for scripts that will generate and nail down several hundred networks of varying sizes, and/or fake peering relationships with a similar purpose, and/or do things that don't meet the BGP protocol standards, etc. Thanks for any responses. Tim

1 0

UUNet
by Alba, Victor 17 Nov '00

17 Nov '00

Is there anything happening with UUNet, all our traces die at this point: POS7-0.BR2.NYC9.ALTER.NET (152.63.22.229) [AS 701] 288 msec 252 msec 232 msec * * * -Victor

1 0

IETF NomCom needs IESG nominations
by Bill Woodcock 17 Nov '00

17 Nov '00

This only appears to be non-operational at first glance. As there are every year, there are IETF Area Director seats which the nomcom needs nominations to fill. Specifically, we need people with operational experience, and we need nominees in the Internet and Routing areas. Volunteer in your own defense, or nominate someone you think is smart and has been slacking lately. All you need to do is mail a name and email address to nomcom(a)ietf.org. The rest of this is the announcement which Bernard Aboba wrote for distribution within the IETF: _____________________________________________________________________________ The 2000 Nominations Committee is now soliciting nominations for the open slots on the IESG and IAB. Since WG chairs work with the members of the IESG and IAB on a regular basis, and are intimately familiar with the IETF process, chairs have unique insight. Please take the time, even if it is only a few moments, to send us your thoughts. Members of the community are encouraged to nominate candidates for any of the positions which are up for re-filling: IESG Terms ending in March, 2001: Fred Baker IETF Chair Scott Bradner Transport Randy Bush Operations & Management Patrik Faltstrom Applications Thomas Narten Internet Dave Oran Routing Jeff Schiller Security IAB Terms ending in March, 2001: Harald Alvestrand Ran Atkinson Rob Austein Steve Deering Tony Hain Geoff Huston Members of the community are encouraged to contact the nomcom to nominate someone for any of these positions, to provide input relating to potential candidates, or to provide comments regarding the past performance of incumbents, which will be considered during the deliberations of the nominating committee. Comments sent to the nominations committee will be kept in confidence. As noted in RFC 2727 "all deliberations and supporting information that relates to specific nominees, candidates, and confirmed candidates are confidential." Self-nominations are accepted. The deadline for nominations is midnight Monday, December 16, 2000. Early input is desirable so that candidates may be interviewed during IETF 49. The members of the NomCom can be contacted individually at the addresses below or collectively at nomcom(a)ietf.org. Additionally, the members of the NomCom will be identified at the IETF by a marker (as yet undetermined) on their name tags. People are encouraged to take advantage of the opportunity to talk to the members of the NomCom about nominations and other issues related to the IAB and IESG membership. The 2000 Nominations Committee Phil Roberts <qa3445(a)email.mot.com> Stuart Cheshire <cheshire(a)apple.com> Perry E. Metzger <perry(a)piermont.com> Bill Woodcock <woody(a)zocalo.net> Hadriel Kaplan <hadriel(a)nortelnetworks.com> Alain Durand <alain.durand(a)eng.sun.com> Vijay Srinivasan <vijay.srinivasan(a)cosinecom.com> Hal Sandick <hsandick(a)nortelnetworks.com> David Robinson <david.robinson(a)ebay.sun.com> David Allan <dallan(a)nortelnetworks.com> Non-voting members: Bernard Aboba <aboba(a)internaut.com> (Chair) Avri Doria <avri(a)nortelnetworks.com> (Past Chair) Leslie Daigle <leslie(a)thinkingcat.com> (IAB liason) Allison Mankin <mankin(a)isi.edu> (IESG liason) The role of non-voting members (from RFC 2727) The nominations committee comprises at least a non-voting Chair, 10 voting volunteers, and 3 non-voting liaisons. The sitting IAB and IESG members each appoint a non-voting liaison to the nominating committee from their current membership who are not sitting in an open position. The Chair of the prior year's nominating committee also serves as a non-voting liaison.

1 0

Any "standard" name for ISP time services?
by Valdis.Kletnieks＠vt.edu 17 Nov '00

17 Nov '00

I'm currently composing a note to a software house, which is asking for permission to list some of our NTP servers in their software's config files. Before I do that, is there any "standard" for ISP's for naming their hosts that provide time service on ports 13, 37, or 123? Even if it's a list of "AOL users should try 'time.aol.com' first" rules, that might be an improvement.... -- Valdis Kletnieks Operating Systems Analyst Virginia Tech

4 4

announcing Jan 2001 COOK report contents & distribution list for cook report monthly summaries
by Gordon Cook 16 Nov '00

16 Nov '00

Announcing a distribution list for the monthly free summary of the COOK Report on Internet. You should expect to receive the monthly summary that is usually between 7 and 15 thousand characters long. You may get one or two other messages a month. This list is intended for distribution and not discussion. Anything posted to the list will bounce to me. I regard this as an experiment and reserve the right at my discretion to change list policy. The list name is Cookrepsum standing for Cook Report Summary. You may subscribe yourselves by sending a message to majordomo(a)compucomis.net with 'subscribe cookrepsum' in the body. To unsubscribe send mail to majordomo(a)compucomis.net with 'unsubscribe cookrepsum" in the body The who command is disabled to preserve privacy. Thanks to Michael Burger at compucomis.net for lending the use of his facilities. I will send the full summary out late in the day Thursday the 16th. To receive this and future summaries please follow the major domo sign up instructions for cookrepsum(a)compucomis.net above. ******************************** The COOK Report on Internet January 2001 (Vol.9, No. 10) ******************************** CONTENTS Packet Design Has Unique Research Role Seeks Improved Routing to Offset Problems Inherent in MPLS Judy Estrin, Kathie Nichols, Van Jacobson Want Cost Benefits of Convergence By Leveraging Strengths of TCP/IP Architecture pp. 1-7 Scaling the Internet via Exchange Points Many Players Jumping into Rapidly Expanding Global Market Technology and Business Model Issues as Seen By Equinix pp. 8 - 15 ITU and IETF in Agreement on ENUM Administration Letter from ITU to ICANN Blocks .tel gTLD Applications As Competition to ENUM -- Administration Modeled on Neutral Tier 1 Database Holder of Pointers to Records of Provisioned Services pp. 16 -17 Is-Is Bug Causes UUNET Route Flap pp. 18-19 ICANN Having No Authority to Create New gTLDs Lacks Legitimacy in US and Is Increasingly Rejected in Europe Dixon Explains How .eu Has Been Kept from Icann Control, pp. 20-21 DNRC Letter Documents ICANN Past Testimony to Show Duplicity Behind So Called Clean Sheet Study of Public Board Members pp. 21 - 22 Executive Summary, pp. 22 - 24 -- **************************************************************** The COOK Report on Internet, 431 Greenway Ave, Ewing, NJ 08618 USA (609) 882-2572 (phone & fax) cook(a)cookreport.com Index to 9 years of the COOK Report at http://cookreport.com Why ICANN is illegal. See 5 page version at http://cookreport.com/illegal.shtml and 168 page version at http://www.law.miami.edu/~froomkin/articles/icann.pdf ****************************************************************

3 2