- NANOG - lists.nanog.org

Re: withdrawal propagation (was E.E. Times?)
by Justin W. Newton 15 Jan '97

15 Jan '97

At 12:46 PM 1/14/97 -0500, Jon Zeeff wrote: > >> 0) Is this a bug, does it cause any problem whatsoever? > >If I'm not mistaken, lots of routers have had performance problems >caused by excessive rates of routing updates. > >Or did I misread various previous messages to this list? A BGP withdrawl for a route which is not in the routing table does not cause the router to update any routes and is hence not a routing update. I.e. removing a route that isn't there is not very processor intensive. Justin Newton Network Architect Erol's Internet Services

2 1

Re: withdrawal propagation (was E.E. Times?)
by Tony Li 15 Jan '97

15 Jan '97

Can you specify the bug/fix number for Cisco so we all can check to see that we have it installed? I think that the engineering special build number would probably be more relevant. ;-) As Ravi is out of cyberspace for a while (everyone congratulate him when he gets back!), Paul, could you please do the honors? Thanks, Tony

1 0

Re: Netscape MAE colocation?
by brandon＠rd.bbc.co.uk 15 Jan '97

15 Jan '97

> hopefully they and other high-volume providers would set up mirrors > *outside* the US so that folks wouldn't spend their bandwidth pulling their > (uncacheable) pages in. Or mirrors *inside* if you are already outside :) > ... do HTTP traffic analysis and the business > case show that selecting different locations for web servers is > "worth it"? Yes, b/w from the UK is expensive enough that we're working on a proposal to site a BBC server in the USA (and our volume isn't very high yet). Brandon -- Brandon Butterworth phone: 01737 836592 BBC Research & Development fax: 01737 832336 Kingswood Warren, Tadworth email: brandon(a)rd.bbc.co.uk Surrey, KT20 6NP URL: http://www.bbc.co.uk/

1 0

Remove from ListServe
by Tom Aellis 15 Jan '97

15 Jan '97

Subject: Time: 3:13 PM Remove from ListServe Date: 1/14/97 Would you please remove my name from the ListServe. Thank you in advance.

2 1

Re: withdrawal propagation (was E.E. Times?)
by William Allen Simpson 15 Jan '97

15 Jan '97

OK, I've read the article, and it's not very good. The author doesn't understand the terminology. Never-the-less, this is supposed to be a cooperative operations group, and we should be doing some operations! I've looked at the Cisco page, and a search on "BGP, withdrawals" does not find any mention of the bug fix release. So, I have some pointed questions! 1) What release fixes the problem? 2) Is the release free? 3) Where has Cisco announced the release? And, bringing the operations closer to home: 4) Has Merit installed the release? 5) Has CICnet installed the release? 6) Has MCI installed the release? 7) Have all the peers at Ameritech NAP installed the release? Once that is done, Craig will be able to see the effect of the bug fix at one NAP, and compare with other NAPs during the same time frame. Then, we will know if it was a Cisco problem.... WSimpson(a)UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson(a)MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2

6 7

Need help w/internet draft.
by Forrest W. Christian 15 Jan '97

15 Jan '97

I've been working on an internet draft on using NAT techniques for agreggating the core routing tables. I'm to the point that I need some assistance with general internet-draft writing practices. I'm hoping that someone can point me in the right direction or otherwise offer general assistance. The RFC's and other docs on the registrar's web site are of little real use. Technical suggestions are also welcome. What I've got so far is up on the web at: http://www.mt.net/~forrestc/route.txt Another question I have is related to the appropriate forum(s) to discuss this particular draft in. I have no desire to add greatly to the noise level in non-relevant lists. -forrestc(a)imach.com

1 0

Re: Questions about Internet Packet Losses
by Kent W. England 15 Jan '97

15 Jan '97

At 04:08 PM 13-01-97 -0500, Bob Metcalfe wrote: > > ... >Is the Internet's sometimes bogging down due mainly to packet losses or >busy servers or what, or does the Internet not bog down? > ... >If 30% loss impacts are noticeable, what should be done to eliminate the >losses or reduce their impacts on Web performance and reliability? > Bob; There has been a sea change in expectation for the Internet in the last few years from "did my mail get through last night?" to "why is this telnet so damn slow?" to "why don't my web graphics download faster?" Today's Internet is pretty astounding with respect to email delivery. I don't think we are anywhere near saturating the network with email. No one is complaining about a lack of email volume or timeliness of delivery (except for server scaling problems experienced from time to time by rapidly growing ISPs). Nobody cares much about telnet today -- the Internet is synonomous with the web, which means HTTP. The recent discussions on packet size distributions substantiates that. The web is slow, almost necessarily so. The web is a completely unarchitected data delivery system with some pretty significant flaws that make the web very sensitive to path delay. The relationship between data location and subscriber location is completely unarchitected. That's fine for hobbyist use, but not for large scale information delivery. But it is pretty mind boggling to me that people think that the Internet is creaky and clanky when the web protocol and data (un)architecture is what it is. As I say, the Internet works pretty damn well for email. Anything more sophisticated needs an architecture as well as a topology. The Internet topology today is pretty well engineered for an architected web. Once HTTP 1.1 is deployed, if web caching and mirroring business deals are made between content providers and Internet access providers, the data will end up in pretty much the right place and we'll see a much better match between the data flows and the topology. The web will be fast. And multicast Internet TV and radio channels can be addressed about the same way. Architect the channels and have content providers make transport deals with access providers. And from now on let the access providers architect the data systems. :-) Or at least re-architect the wildly popular apps before they grow too large. --Kent

1 0

Predictions for 1997 [humor]
by Paul Ferguson 15 Jan '97

15 Jan '97

See: http://techweb.cmp.com/nc/801/801colfrezza.html - paul

1 0

RE: Info on MAE-EAST
by Chris A. Icide 14 Jan '97

14 Jan '97

I thought the sizes were comparable as follows... 7010 ~7505 (5 slots, including 1 RP/RSP and 1 SP for the 7010?) 7000 ~7507 (7 slots including 1RP/RSP and 1 SP for the 7000) 7513 (13 slots, no 7000 series comparable) Chris ---------- From: Avi Freedman[SMTP:freedman@netaxs.com] Sent: Tuesday, January 14, 1997 11:18 AM To: Todd R. Stroup Cc: nanog(a)merit.edu Subject: Re: Info on MAE-EAST > Does anyone have any info on if MAE-EAST allows collocation of a 7507 now or > is it still stated that the size has to be about the size of a 7010. > > Please return email direct to tstroup(a)fibernet.net > > Thanks. > > Todd R. Stroup > Fiber Network Solutions, Inc. The 7507 is the same size as the 7010, give or take a few cm, I believe. And unlike Pennsauken, many at MAE-East have full racks available to them. In fact, Netscape has a bunch of purple beasties there (SGIs) last I looked... Avi

1 0

RE: Questions about Internet Packet Losses
by Peter Cole 14 Jan '97

14 Jan '97

People want/need information, Lots of it and lots of different kinds of it. They don't/won't wait on it. Packet loose limits the growth of the Internet by reducing the desire to use the Internet to move different kinds of information. The better it works the more we will all use it, until we get tired of waiting for it. Then we back off and: place a phone call, send a fax, turn on the radio, go to the library or the post office, turn on the TV, read a magazine or newspaper, Install a lease line, etc. ISPs that provides better quality of service will attract content providers and content consumers that want more from the net. As consumers become aware of the differences in service, low performance ISPs will decline in popularity for demanding consumers. Try and find a customer that says they like to wait 30 seconds for a web page. Several of the dialup nationwide systems are 30 second slow. As customers of slow ISPs see faster response from higher quality of service ISPs they will switch or continue to wait. As new solutions are made available to consumers like personal video conferencing, consumers will tend to higher performance ISPs. Even if a carrier delivers ever packet they receive to the Gigaswitch at an exchange point the customer doesn't care where the packet was lost. The increase in private crossconnects sends a message to the exchange points, while giving the exchange point some breathing room. In summation packet loose is here to stay. The amount will be determined by the free market system. P.S. If someone can prove they have better access than what I am buying now I'll plan on switching. AS7201

1 0