- Test - lists.nanog.org

Re: Quiet...test
by William B. Norton 05 Dec '97

05 Dec '97

OK - thanks all. Just checking. Bill At 03:11 PM 12/5/97 +0000, Jim Dixon wrote: >On Fri, 5 Dec 1997, William B. Norton wrote: > >> Seems quiet - someone suggested the list broke...just testing. >> >> Bill > >(Ssssssh. They're asleep.) > >-- >Jim Dixon VBCnet GB Ltd http://www.vbc.net >tel +44 117 929 1316 fax +44 117 927 2015 > > >

1 0

Re: IP over SONET
by Paul Ferguson 05 Dec '97

05 Dec '97

You should be aware that there is at least one existing mailing list for technical (IETF) discussions of Packet over SONET/SDH -- Bill Simpson set up the pppsdh list at pppsdh(a)greendragon.com. - paul At 04:26 AM 12/5/97 -0500, Bradley Reynolds wrote: >I have created a new mailing list >to discuss IP over SONET. >It has been created to provide >a forum for discussion over anything >from implementation to application >to viability. > >Send all subscription requests to >ip-sonet-request(a)iagnet.net >with a body of "subscribe" > > >brad reynolds >ber(a)cwru.edu > > > >

1 0

IP over SONET
by Bradley Reynolds 05 Dec '97

05 Dec '97

I have created a new mailing list to discuss IP over SONET. It has been created to provide a forum for discussion over anything from implementation to application to viability. Send all subscription requests to ip-sonet-request(a)iagnet.net with a body of "subscribe" brad reynolds ber(a)cwru.edu

1 0

Re: @HOME problems
by Nicholas Bastin 04 Dec '97

04 Dec '97

On Wed, 3 Dec 1997, NANOG sysadmin list wrote: > Is anyone here aware of the source of seemingly random packet loss to and > from home.net? We have a T1 from @home and I've been getting about 75% packet loss on it for the last couple weeks. We've got a ticket in, but nobody seems to know what the heck is going on. Best I can tell is all my traffic gets to MAE-WEST with only 1% - 2% loss, and then starts timing out. Of course, anything within the @home network is just as quick as usual. Nick Bastin System Administrator - World Trade Internet Communications

3 3

Invalid announce for 15/8
by Edvard Tuinder 04 Dec '97

04 Dec '97

Hi, Has anybody outhere any idea as to why AT&T Japan (AS 2915) is announcing the 15/8 network from HP? I'm not getting anywhere near HP this way.. Amsterdam1>sh ip bgp 15.0.16.68 BGP routing table entry for 15.0.0.0/8, version 7637408 Paths: (2 available, best #1) 5583 4000 2915 194.235.74.237 from 194.235.74.237 (194.235.236.21) Origin IGP, localpref 100, valid, external, best Community: 8251:5001 5496 174 71 71 71 195.86.26.2 from 195.86.26.2 (194.165.94.235) Origin IGP, localpref 100, valid, external Shouldn't GIP/GSL (as4000) be filtering this bogus announcement? Thanks, -Ed -- Edvard Tuinder Cistron Internet Services Finger ed(a)cistron.nl for PGP key ``I must fear Evil, for I am but mortal and mortals can only die''

2 2

Re: [nanog] @HOME problems (fwd)
by NANOG sysadmin list 04 Dec '97

04 Dec '97

But the problems originate from home.net, not sprint, apparently ---------- Forwarded message ---------- Date: Thu, 4 Dec 1997 00:12:14 -0500 (EST) From: NANOG sysadmin list <nanog(a)seersucker.millburn.net> To: Stephen Balbach <stephen(a)clark.net> Subject: Re: [nanog] @HOME problems Sprint/Pennsauken, NJ... On Wed, 3 Dec 1997, Stephen Balbach wrote: > > What gateway to the @Home network? > > On Wed, 3 Dec 1997, NANOG sysadmin list wrote: > > > Is anyone here aware of the source of seemingly random packet loss to and > > from home.net? > > > > Thanks > > -=asr > > > > >

1 0

@HOME problems
by NANOG sysadmin list 04 Dec '97

04 Dec '97

Is anyone here aware of the source of seemingly random packet loss to and from home.net? Thanks -=asr

1 0

Horrible Service Agreements
by Forrest W. Christian 03 Dec '97

03 Dec '97

Over the last few months, I've been trying (without success) to find a provider for our second T1 to the net. Basically, all we want is a full-bandwidth T1 w/bgp4, to an upstream I am comortable with the quality of service of, and who can provide this to us (in montana) at a reasonable monthly rate. Finding a suitable provider hasn't been too hard, but the difficulty comes in when it's time to sign a contract. So far, we have accepted a proposal pending contract approval for TWO different potential upstreams. Both quoted a price of around 2500 per month including local loop. However, the contract terms include what I'm terming an anti-spam clause which generally states that if us or any of our clients or their clients decide to "prevent others from enjoying the internet" (paraphrasing) they can terminate us immediately and make us pay for the remainder of the year term. Each (or maybe better said one or more) of the contracts also included other terms which I felt were totally unreasonable. Such as not being able to mention the name of your upstream. Makes it kinda hard to tell potential clients who you are connected to. Another required us to upgrade our equipment based on whatever specifications they felt was necessary at that point. And there were more. Now, I understand the need to be able to terminate spam havens. I also understand the need to require your customers to use compatible and reliable equipment. Let me explain my problem -- Lets assume that customer "a" decides to purchase an account on our system to send out spam. We don't know he's planning to do this, but he does succeed in sending out 10,000 messages before we find out. Under both agreements, we can be immediately terminated without notice and be required to pay for the remaining time on the 12 month agreement. Regardless if we terminate the offending user as soon as we find out or not. Another example. Lets assume that someone in our upstream decided that we MUST have a $250,000 router to connect to their system. If we can't provide such a beast, we are immediately terminated and required to pay for the remaining year term. Both of the potential upstreams have been wholly unwilling to negotiate a contract in good faith to resolve these issues. I know that nanog is probably not the best forum for this, but I figured it might be a good place to start to look for a provider which can: a) Sell us a T1 line, with BGP4, with local loop to NPA NXX 406 443 for about $2500/month, on a year term or less. b) Not have such rediculous contract language. I'd also like to hear what types of contracts are actually signed by providers and if they are actually read before they are signed. You can reply to me directly, instead of on the list, if you'd like. -forrestc(a)imach.com

13 17

caching at windmills (i mean exchange points)
by k claffy 03 Dec '97

03 Dec '97

to: ISP's at mae-west we submit for your valued consideration a proposition http://www.nlanr.net/Caida/maewest.cache.html (first few paragraphs of web page included below) k and dw nlanr/caida (under we-run-commodity-infrastructure supervision from steve feldman (maewest), bill woodcock (zocalo), and david meyer (UO) ) -------------------------------------------------------- web caching as a viable Exchange Point Service proposed business-compatible model of web caching as a service provided at a NAP background NLANR has been operating a national public web caching system for about two years, as part of a research proposal sponsored by the National Science Foundation to architect and deploy prototype Internet information provisioning infrastructure. While the project has been an enormously successful `proof-of-concept' to the Internet community, especially internationally where it was received subjected to far higher and faster accelerating demand than we intended, participation in a cooperative global web caching mesh has for a variety of reasons been slower to catch on in the United States. A significant barrier to the use of caching by ISPs in the United States is the lack of a discernable pricing and business model to support caching as a commericial Internet service, either independently, packaged with a backbone service, or packaged with exchange point connectivity service. NLANR's project has allowed the development and deployment of a strong research code platform, as well as a prototype infrastructure that has recevied international recognition for its operationally pivotal role in the Internet. However, partly because of the tremendous success and resulting expectations of this `prototype' infrastructure, NLANR has not had the budget or cycles to pursue penetration of the U.S. commercial Internet market, partially expecting it to catch on from its own momentum. In 1997, NSF approved a follow-on award to use the by then globally-entrenched NLANR caching infrastructure for extended architectural investigation and experimentation. We maintain a project plan timeline, status reports, and cache status page including information on upgrades, major configuration changes, and outages. More importantly, we are now in a position to move forward with architectural models of caching that are more compatible with commerically-provisioned commodity intrastructure, and in which ISPs themselves will have an incentive to participate. On 1 December 1997, we are deploying a prototype web cache service at MAE-West, specifically designed to demonstrate the viability of a commercial model for providing web caching service. purpose The principal purpose of this peering-point-colocated Squid cache is to provide an easily accessible (no-AUP, low hop-count, low latency) alternative to the current vBNS-hosted root caches. The secondary purpose of this cache is as a demonstration of the feasibility of introducing self-supporting caches into the main stream of the Internet's core. Having a web cache at popular Internet exchange point provides ISPs an opportunity to leverage their presence at this strategic position in the Internet topology. Because the exchange point is a likely component of the paths of many web pages travelling across the Internet, storing web pages on a web cache at this point offers ISPs a potentially significant savings in bandwidth and end user latency by allowing them to retrieve pages there rather than having to go on to the original source.

4 4

Re: The Year of the Backhoe Continues...
by Sean Donelan 03 Dec '97

03 Dec '97

>The relative severity has gone up though for two reasons. First, there >is more fiber than ever in the ground and that which is in the ground >is carrying more traffic than it used to. So a single cut can cause >lots of people problems. Also, because of the increase in internet >use, the visibility of such cuts has gone way up. Doesn't any one else get a chuckle when they hear a *single* cut can cause lots of people problems when referring to the Internet, given the mythological history of the Internet's design goals? Looking over logs for the last few years, the same causes why the application user has problems show up over and over again. Here they are in order.... 1. Congestion 2. Operator/Software error 3. Telcom facility outage (fiber/cable cut or telco 'virtual' service frame/atm/smds/etc failure) 4. Power failure 5. Hardware failure Its difficult to distinguish between operator errors and software errors, since most cases of operator/software failure often involve a failure by both. Also it is sometimes difficult to tell what the true cause of an outage was. It may be more convient to blame the usual suspects, than to admit your own mistakes. I've noticed some 'fiber cuts' have later turned out to be switch or DACS programming errors. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0