- Test - lists.nanog.org

NANOG topics so far
by Susan R. Harris 17 Sep '97

17 Sep '97

Greetings - here are presentations we've lined up so far for the Oct. 27-28 NANOG: - Update from the IPPM Working Group - Vern Paxson, Lawrence Berkely Lab - Routing Analysis and Tools from the Internet Performance Measurement and Analysis Project (IPMA) - Rob Malan, University of Michigan - Plans for the Internet Routing Registry Transition to Routing Policy Specification Language - Cengiz Alaettinoglu, ISI - Update from IOPS.ORG - Speaker TBA - Freely Available Statistics Reporting Agents: A Practical Review - Stan Barber, Academ Consulting Services - Internet Routing Registry Cleanup Efforts - Curtis Villamizer What other topics would you like to hear about? -------------------------------------------------------------------------- Susan R. Harris, Ph.D. Merit Network, Inc. Phone: 313.936.2100 srh(a)merit.edu Senior Science Writer Fax: 313.647.3185

1 0

Re: Traffic Engineering [was Chanukah [was Re: Hezbollah]]
by sob＠academ.com 17 Sep '97

17 Sep '97

> Doing traffic engineering right is hard. The telcos have it down pat > for their voice networks, and telco-based ISPs often have applied > this design expertise to their ISP network. Having a person do > traffic engineering can save the ISP big bucks. I agree that traffic engieering is important and doing it well is hard. However, I can point to many cases that demonstrate that the telco folks don't have traffic engineering down pat for their voice networks. The great majority of the cases show up in two areas: InterCO trunking and Inter-provider (telco-to-telco trunking). Of course, it just may be the telcos I deal with here in Texas. I can't speak of direct experiences with everyone in the country. -- Stan | Academ Consulting Services |internet: sob(a)academ.com Olan | For more info on academ, see this |uucp: {mcsun|amdahl}!academ!sob Barber | URL- http://www.academ.com/academ |Opinions expressed are only mine.

2 1

Re: need contact info
by James A. Farrar 17 Sep '97

17 Sep '97

At 08:39 PM 9/16/97 -0700, Rick Horowitz - Network Administrator wrote: >Of course, he neglected to mention, "Good luck getting a straight answer >about anything from MCI. You're better off calling your psychic if you >have a network problem involving MCI." > Be nice Rick, our NOC knows what a pleasure its been talking to you. We still have that picture too. Nice touch. -Jim

1 0

Problems configuring cflowd
by Demetrius Christian 17 Sep '97

17 Sep '97

Hello, Im configuring Daniel Mc Robb's and John Hawkinsons cflowd. I plan on running this on Solaris 2.5.1. I had some problems compiling it and then can't seem to get the cflowd.conf config file to be parsed properly. I am using gcc 2.7.2.1 and having problems with lex. I changed ~/apps/cflowd/lexer.lex to include the following: %e 16000 %p 14000 %k 14000 and took out one of blan lines around the '%%' line. I then made some changes to the Makefile and removed the -CF option from lex -CF. After these changes I could compile the software ok. I however keep on getting problems about a left parentheses in cflowd.conf when I try to start the daemon. Has anybody compiled this under Solaris? Did you manage to get it sorted out? If so I would appreciate any assistance to get this running. Many thanks Demetrius !

1 0

Re: need contact info
by Mark Kayser 17 Sep '97

17 Sep '97

As an "MCI" person here is the number to the INOC. :) 919-677-5566 This has been the NOC's number for the past 2+ years. The 800 number if you are interested is 800-977-4662 but to report a problem you should try our ISP group first so that a ticket can be opened to track the issue. Here are the numbers: 281-276-4231 or 800-663-9932 These numbers did just change as this group just moved to Texas. This may have been who you were informed to contact before. Sorry for the confusion. These should be the correct numbers. Hope this helps. --Mark Kayser MCI Technical Support -----Original Message----- From: Sean Donelan <SEAN(a)SDG.DRA.COM> To: nanog(a)merit.edu <nanog(a)merit.edu> Date: Monday, September 15, 1997 8:31 PM Subject: Re: need contact info >>> Since NANOG seems to have turned into directory assistance, does anyone >>> know the preferred, listed, international phone number for the MCI NOC, >>> not a 1-800, or 1-888 number. Hopefully a number that will be in service >>> longer than three months. All the non-1800 phone numbers our MCI sales >>> person locate seem to be DID numbers to individual's voice mail or stop >>> working when the person leaves MCI. >> >>919-677-5566 > >Cool, so far four non-MCI people have sent me phone numbers for >MCI. The interesting thing is they each sent me a different phone >number. > > 703-715-7056 > 703-715-7292 > 919-677-5351 > 919-677-5566 > >Anyone else care to play? >-- >Sean Donelan, Data Research Associates, Inc, St. Louis, MO > Affiliation given for identification not representation > >

2 1

RE: Physical transport media
by Brian Holt 17 Sep '97

17 Sep '97

I'm wondering if there are any concerns for possible lawsuits arising from people slipping and falling from the use of /dev/null. -- Brian Holt Technical Support Engineer Nap.Net, L.L.C (414)747-8747

2 1

Re: too many routes
by David Paul Zimmerman 16 Sep '97

16 Sep '97

>Some people seem to view CIDR as an opportunity to >subdivide their traditional 'Class B' networks. I would classify >most of these announcements as 'mistakes' because they usually also >announce the supernet, and have the same path. I could see the intentional announcement of both if you've got diverse -- but ultimately equal -- paths into your B. So site X might advertise B.0/17 to normally receive the low half of the address range, site Y might advertise B.128/17 to normally receive the high half, and both sites would advertise B/16 so that if one site went down in that scenario, the other's B/16 advertisement would take over for the failed site's /17. In a normal case, though, you'd see the /16 and /17 with the same path. Does this pattern seem to apply to any of the announcements you see? dp

1 0

RE: Physical transport media
by Chris A. Icide 16 Sep '97

16 Sep '97

How about we use a ferritic material that has been permanently magnetized. Then we can line the pipes with supercooled electro- magnets to keep the magnetized BB's orientated in the correct manner. And when the boys in congress get some silly idea in thier heads, we can pull the end off of some of the pipes into the DC area and have a few .17 caliber rail guns on our hands..... Chris ---------- From: Scott Landman[SMTP:Scott_Landman@zd.com] Sent: Tuesday, September 16, 1997 1:59 PM To: michael(a)priori.net Cc: nanog(a)merit.edu Subject: Re: Physical transport media I would suggest using a material that isn't write once/read many in order to save having to dispose of all those BBs. How about plastic balls that could be recycled for use by simply melting them down and reforming them. Also, how do you suggest keeping the balls properly aligned so that the laser can read them? In a liquid, the BBs will rotate on all axis due to turbulence. How about grooves so the BBs will ride on rails? >Also, larger bandwidth facilities may be represented by volleyballs, >basketballs and in the near future, cageballs. :) I'm looking for venture capital for a new laser based technology called LTM. This stands for Liquid Transport Medium and it consists of lasers which holographically engrave datagrams on steel spheres the size of BB's which are then injected into the transport pipes in conjunction with a clear lubricant that serves as the liquid transport medium to carry the datagram spheres to their destination where the datagram is read from the spheres by another laser. The sphere may then be routed down another transport pipe, or, if it has reached its final destination then it is shunted off to a government data archive center in order to meet the new data access requirements that are before Congress. ******************************************************** Michael Dillon voice: +1-650-482-2840 Senior Systems Architect fax: +1-650-482-2844 PRIORI NETWORKS, INC. http://www.priori.net "The People You Know. The People You Trust." ********************************************************

1 0

Re: IP b/w out of NA
by Randall S. Benn 16 Sep '97

16 Sep '97

At 09:53 PM 9/11/97 +0200, you wrote: >Is there any place I can find more info about the aggregate IP b/w out of >North America? How many OC-3s to Europe and to Japan? Is there 600Mb/sec >of b/w from NA to Europe? Any help and pointers appreciated. I was recently looking for this kind of info myslef. Seems that most of the connectivity maps, etc. that I came across were a year or 2 out of date. FWIW, I have a collection of links concerning international L1, L2, and some L3 connectivity on my ISP page. By no means a complete reference, but it might give you a start. Randy Benn http://www.clark.net/pub/rbenn/isp.html

7 7

Chanukah [was Re: Hezbollah]
by Kent W. England 16 Sep '97

16 Sep '97

At 05:03 PM 14-09-97 -0400, Dorian R. Kim wrote: >... One of the >things that needs to be engineered into building and maintaining >national/international backbones is traffic accounting to an arbitrary >granularity that paves the way for better traffic engineering and >bandwidth projections. There are already ample tools to to per-prefix >matrix of traffic right now. Tying this in with good sales projections >will alleviate much of the last minute fire fighting. > >This will most likely never be 100% accurate and precise, but there is >no reason why we can't get a better handle on bandwidth forecasts. (say to >95% percentile) Dorian; I don't want to throw cold water on the value of planning and foresight, but in terms of predicting traffic patterns it has never worked on the Internet. It sounds good and that was the argument that all the mainframe networkers made to us early Internet networkers -- Why can't you tell me upfront what your bandwidth requirements are going to be? Don't you know exactly how many terminals you have and where they are and what application keystrokes are going to be pressed at any given time? How else can you guarantee response time in your network? This Internet stuff is stupid. It'll never work. Somehow with the way that HTTP/HTML caught fire and Internet-CB (aka VocalTec and CUSeeMe) took off, I would be loath to think I could project my backbone needs with any reliability based on *historical* projections. > >Furthermore, with the deployment of WDM and Internet core devices moving >closer to the transmission gear, if you have access to fiber, getting more >bandwidth may become as straightforward as using an additional wavelength >on the ADM that your router's plugged into. > >-dorian > > > This I like a lot better as a design technique. Throwing more bandwidth at the problem almost always works (unless the transport protocol is broken). Like Peter Kline said, Turn up the speed dial upon onset of congestion. Simple. Effective. Then again, creating a data architecture for the web (a problem that has been recognized, but not addressed in the last five years) would eliminate much of the backbone bandwidth demand. What would happen if -- presto -- a data architecture for the web showed up one day? A lot of backbone bandwidth would become surplus and a lot more edge bandwidth would be needed ASAP. What does that do to historical projections? --Kent

1 0