- Test - lists.nanog.org

Re: Traffic Engineering (fwd)
by osborne＠terra.net 18 Sep '97

18 Sep '97

> See, the really neat thing about the 'net is it *removes* the geographical > locality as a barrier. > > People have interests, very specific interests. The number of people > interested in following alt.barney.die.die.die are geographically > dispersed, but the Internet brings them together in a virtual community. > > Search engines, as primitive as they are now, make it much easier to find > whatever specific item you're looking for, and odds are overwhelming that > it's not on your neighbors server. So perhaps what we need is a way for search engines to determine what's "close" - geographically, politically, or speed-wise. This isn't particularly easy to do, but if it was implemented and only worked, say, 15% of the time, it'd still make things look that much faster. Idea: what about a search engine that understands a BGP table? I'm thinking that something like Hotbot, which returns search results with several places to find the same page, goes through a process like this: 1) perform the query. 2) if your query returns multiple places to get the same page a) look at the AS_PATH for the querying IP address b) look at the AS_PATHs for the found pages c) Determine and return the "closest" one - perhaps the one whose AS_PATH is most like that of the querying host. This is a bit rough (off the top of my head, first thing in the morning), but you could do a bunch with it. Search engines, for example, that optimize for search speed vs. retrieval speed, come to mind. Anybody out there have any spare venture capital? :) eric > > --- David Miller

2 2

NOOP: FYI on gTLDs
by Rick H. Wesson 18 Sep '97

18 Sep '97

Sorry for my non-operational post... I wanted you folks to know that the new gTLDs that the IAHC outlined in their final draft will be operational by Feb 7th, 1997. There was a meeting in New York, NY elier this month where many of the aproved registrars worked on issues surrounding the CORE database system. A draft RFP for the development of CORE is available at http://www.core.gtld-mou.org/ I thought you folks would want to start tracking the situation with gTLDs. You will have to decide on a Registrar to work with. You won't be able to get deligations in the new gTLDs from the Internic, and the forms and interactions will be slightly different. For more info please see the following URLs http://www.gtld-mou.org/ http://www.core.gtld-mou.org/ http://www.pab.gtld-mou.org/ Please don't continue this thread on NANOG as they hate me enough already. If you have questions read the web pages or mail me directly <rick(a)ar.com> =================================================================== Rick H. Wesson Internet Business Services rick(a)ar.com

5 5

Re: need contact info
by Sean Donelan 17 Sep '97

17 Sep '97

>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." Actually InternetMCI has improved a lot since I started dealing with their employees in early 1995. They still have several annoying habits though. But MCI is not unique. Keeping up-to-date contact information is a problem for lots of providers. Unfortunately, you don't realize the contact information doesn't work until you need to use it. Only then do you discover the provider only has a 1-800 number which isn't callable from your area, you can't send them e-mail because the network isn't working, and the contact page on their web server doesn't load. So once again, I ask all providers to please check your own contact information in the WHOIS database (I know it ain't much, but often its all we have) for an up-to-date e-mail address and internationally diallable telephone number. If you don't want to list your NOC, please list a contact that knows what a NOC is, and can reach your NOC. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

Re[2]: Traffic Engineering
by pkavi＠pcmail.casc.com 17 Sep '97

17 Sep '97

Good point re the changing patterns over time. Traffic engineering is not a one time activity, but something you should expect to do once a quarter. Measurement, trendline analysis, projections, and verifying the accuracy of the projections, and determining the reasons for inaccurate projections are all important parts of the process. In this way, traffic engineering is akin to writing a company's business plan--a dynamically changing document that helps you make decisions, rather than set in stone and oblivious to the outside world. Prabhu ______________________________ Reply Separator _________________________________ Subject: Re: Traffic Engineering Author: "Kent W. England" <kwe(a)geo.net> at smtplink Date: 9/17/97 10:19 AM At 09:59 AM 9/17/97 -0500, pkavi(a)pcmail.casc.com wrote: > > As a former network design guy who's done traffic engineering and > design (and redesign) on many networks (Internet and otherwise), I > disagree that traffic engineering doesn't work for the Internet. > Prabhu; Thanks for the treatise on network engineering. I agree that network engineering is useful and that there should be traffic engineers. However, the engineering managers must not forget to see the forest for the trees and must heavily discount the traffic engineering studies, when faced with out-of-the-box data. Here are some examples: > 2. Identify which % of traffic, if any, has regional locality. > For pure Internet traffic, the probability that the source and > destinatino of traffic are within the same metropolitan area > tends to be low (10% or lower for metros within the US). This is true only so long as the density of the Internet is low. This is so because so long as the density is low, few of your neighbors will be on the Internet and therefore local issues are irrelevant. However, at some point, the density of the Internet gets to a critical point, say 30% to 40%. At that point a pizza parlor owner says to himself "two out of every five of my customers are on the Internet. Perhaps I need a web page." And, suddenly, pizza on the Net makes a lot of sense and the traffic patterns shift. As the density grows to 90%, local traffic becomes dominant over distant traffic. Another example is distributed web hosting. When distributed web hosting takes off, your backbone will be heavily discounted and your peripheral interconnect bandwidth will be woefully short. Web traffic will zoom as performance dramatically improves, but your backbone bandwidth will drop. That breaks your traffic model. So, by all means, do your traffic studies, but be prepared to throw them out or re-write them when the environment changes. Then throw bandwidth where it will do the most good. :-) --Kent

1 0

Route Flaps at NAP's
by ramesh＠cs.ucf.edu 17 Sep '97

17 Sep '97

I have couple of questions on Route Flaps at NAP's. 1)How often do they happen? (per hour, per day etc) 2)When route flaps occur, on an average how many routes are flapped? Any pointers indicating the above statistics will be helpful. Thanks, -Ramesh

7 7

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