December 1995 - Test - lists.nanog.org

Re: Service Problems
by Vadim Antonov 21 Dec '95

21 Dec '95

Now, that i'm not in the ISP business -- *all* large ISPs have the same "small" problem, namely the complete lack of understanding of the current workforce market by the management. There are only few people in the world who really know how the global routing works, and some of them already worth more than average Joe Banana telco tech will make for his entire life. Needless to say that they don't work for telcos, so those who still do have something to think about. In my practice, leaving a large ISP by members of engineering or operational staff causes rather steep increases in their income. On the other hand, engineers having compensation bigger than their managers is something unheard of in the telco corporate culture, and so is trusting engineers to do planning, without the "benefit" of last-year-plus-five-percent beancounting. Those who stay are either young enough to work just for fun, or have other reasons (immigration status, etc) to stay. Of course, incompetents tend to stay till pensions. --vadim PS Although i post from a Sprint accound i do not work or speak Sprint. >From list-admin(a)merit.edu Wed Dec 20 02:53:59 1995 Received: from merit.edu (merit.edu [35.1.1.42]) by titan.sprintlink.net (8.6.9/8.6.9) with ESMTP id CAA27552 for <avg(a)titan.sprintlink.net>; Wed, 20 Dec 1995 02:53:58 -0500 Received: from pike.ixa.net (nikm(a)pike.ixa.net [199.242.19.1]) by merit.edu (8.6.12/merit-2.0) with ESMTP id CAA22222 for <nanog(a)merit.edu>; Wed, 20 Dec 1995 02:19:40 -0500 Received: (from nikm@localhost) by pike.ixa.net (8.7.3/8.6.11) id XAA13404; Tue, 19 Dec 1995 23:15:57 -0800 (PST) Date: Tue, 19 Dec 1995 23:15:57 -0800 (PST) From: Nikos Mouat <nikm(a)ixa.net> To: William Allen Simpson <bsimpson(a)morningstar.com> cc: nanog(a)merit.edu Subject: Re: Service Problems In-Reply-To: <4648.bsimpson(a)morningstar.com> Message-ID: <Pine.SUN.3.91.951219230848.13375B-100000(a)pike.ixa.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: R > On the other hand, I have been very pleased with MCI NOC. Yes, MCI has > some problems too, but they even CALLED BACK to let me know when > _another_ provider (PSI) had fixed the problem that I reported, rather > than me trying again every 10 minutes to see if it was fixed yet. That > kind service overwhelmed me with joy and brought tears to my eyes! If it makes you feel better, I put in a trouble ticket with MCI approx 29hours ago. it was not a complete outage, but the problem i was trying to talk to a tech about had an hour or so prior caused a serious outage on my mci connection - I would prioritize it as important, not urgent. the person who took the trouble ticket asked me if it would be "ok to take the circuit down for testing" - the problem i was trying to get resolved was related to peering.. go figure.. I still haven't heard back from MCI.. UUNET on the other hand I managed to get a call through to a tech there immediately... I've given up on trying to get through to MCI.. I've had nothing but good experience with them on the physical circuit level.. and the routing guys installing the circuit were great.. but trying to get a [routing] tech on the phone for trouble issues just sucks.

2 1

Re: Sprint Service Problems
by Hank Nussbacher 21 Dec '95

21 Dec '95

On Wed, 20 Dec 1995 01:11:30 -0700 (MST) you said: >Time for me to jump on the bandwagon. > >We're a Sprint Customer. Right now we have a 256K fractional T1 line to >the net. We're tied to Stockton-7. "Our End" of the line is in Helena >Montana. > >For months now, I've been asking them why our ping times look like: >Sending 100, 32-byte ICMP Echos to 144.228.47.21, timeout is 1 >seconds: >!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! >!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! >Success rate is 100 percent (100/100), round-trip min/avg/max = >100/104/204 ms > >Note the 100 ms. I have NEVER seen it below 100 ms EVER. No matter what >the traffic, time of day, etc. Well, maybe I've seen it at 98 or 99 once >or twice. > >In theory, a round trip time should be two times the single direction >distance, which should be composed of the following two items: > >1) 256K maximum bitrate (amount of time to clock the bits out) - > 32 bytes * 8 bit bytes = 256 bit times > 256 bit times * (1/256,000) (one bit time) ~= 1 ms >2) Speed of Light Limit (The Rest) > In vacuum, light can travel 186 miles per millisecond. > Not sure how much it differs in fibre, but I figure that > even if you assume that its 150 miles per millisecond, > you can travel roughly 7000 miles in the remaining time (59ish ms). > >So, that puts my link 7000 miles away. Now I'm curious as to how they >have my line routed over 7000 miles. So I call up their INSC and ask who >I can talk to about this. I end up opening a trouble ticket, and >eventually the engineer I talk to say's that it is in the acceptable >limits for the distance of circuit, which they tell me goes from Helena >to Seattle and then to Stockton California in more or less of a straight >line between the points. According to my calculation there's about 1200 >miles of fiber there. Still 5800 miles short. > >I backed off after reading some papers on ping times versus maxumum >flow. That is until I had an outage last week caused by a Fiber Cut in >Texas. Now I'm mad. I supposedly have a line from Helena to Seattle >to California which somehow goes through Texas. After finally yelling loud >enough about either this cut not being my problem or my line isn't routed >where I was told it was, I finally got a manager or VP who was kind >enough to tell me that my line is routed through Arizona, and Texas, and >a couple of other places in what I call the "mideast", and then to the >Dakotas, through montana to the spokane (eastern washington) area, and >then back to Montana. Adding up the miles, I get about 4-5,000 miles. >I can believe that, with some switch latency. Here are some tests I have done at 256kb: Line From-to Medium 8000 octet 1000 octet 32 octet speed ping ping ping in seconds in seconds in seconds ----- ------------- ---------- ---------- ---------- ---------- 256kb Israel-Israel fiber .524 .068 .008 256kb Israel-Israel FR, CIR=0 .628 .144 .016 256kb Israel-USA satellite 1.096 .640 .572 256kb Israel-Europe fiber .576 .116 .052 For 32 octets and 100ms - that is twice the rate we get with a fiber link from Tel-Aviv to Geneva - a few thousand miles. Hank

1 0

Wayward Cables
by Jeff.Ogden＠um.cc.umich.edu 20 Dec '95

20 Dec '95

Bill Simpson does not have his facts on the fiber cut to the old NSFNET NOC in Ann Arbor quite right. There was a cut and the NOC was cut off which wasn't good, but it was not the case that separate links were purchased to avoid that completely. We knew that there was some risk depending on where cuts took place. As I remmeber this happened twice in the 7+ years of the NSFNET agreement (two times to Michigan). -Jeff Ogden Merit

1 0

subscribe
by Benham Malcom 20 Dec '95

20 Dec '95

1 0

Wayward Cables
by William Allen Simpson 20 Dec '95

20 Dec '95

> From: "Forrest W. Christian" <forrestc(a)imach.com> > That is until I had an outage last week caused by a Fiber Cut in > Texas. Now I'm mad. I supposedly have a line from Helena to Seattle > to California which somehow goes through Texas. Reminds me of when the entire NSFnet went down because both the primary and backup links (purchased deliberately to be separate) coming to the NSF NOC were cut -- far to the north, on supposedly southeast and southwest bound links! Needless to say, the two links weren't supposed to go over the same fiber (by definition), and going by way of Midland was a long way out of the way! (Not as far as Texas, though.) Maybe every contract needs a clear picture of where the links are actually located! What can NANOG, as a group, do about this problem? Do we need to form yet another consortium to coordinate link purchases for NA? Might save some money, too.... Bill.Simpson(a)um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2

1 0

Service Problems
by William Allen Simpson 20 Dec '95

20 Dec '95

Gosh, and I thought that it was PSI that had these characteristics. No, I don't subscribe to PSI, but some of my clients/contacts do. Not long ago, their Detroit switch had been down for 4.5 hours (and thereby a big chunk of the midwest, since they refuse to peer at NAPs), and they hadn't even noticed! I had to _tell_ them to ping it, and the address to ping. (They did know how to ping.) On the other hand, I have been very pleased with MCI NOC. Yes, MCI has some problems too, but they even CALLED BACK to let me know when _another_ provider (PSI) had fixed the problem that I reported, rather than me trying again every 10 minutes to see if it was fixed yet. That kind service overwhelmed me with joy and brought tears to my eyes! Bill.Simpson(a)um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2

3 2

Re: Are the Route Servers Viable Solutions That Are Being Held Hostage?
by Dave Curado 20 Dec '95

20 Dec '95

>> In short, I think the chief failing of the RADB is not the >> toolset, the concept, or the long-term plan, all of which >> make some to alot of sense. Instead, what seems to have >> killed it dead is that the RA was too busy to commit the >> *serious* effort it would have taken to populate the RADB >> with information from reality in the first place. > This paragraph begs the question: Can the patient be saved? That is, > if the concept, toolset and long-term plan make some to alot of sense, > do we move forward by fixing the existing problems or starting over? My feeling is that patient can and should be saved; it is worth the effort to clean up the RADB where it is needed. The tools and concepts work. There is a solid group of people behind the design. As a small provider, we have seen nothing but Good Things since embracing these services. davec

1 0

objectives of nanog
by Elise Gerich 20 Dec '95

20 Dec '95

Colleagues, The goals of NANOG, as written in the charter, include establishing a forum for the exchange of technical information and the discussion of specific implementation issues which require cooperation and coordination between service providers. Some of the current discussions are more appropriate to a "soapbox" or "flamesRus" mailing list. Please refrain from continuing to hijack this list for non-technical issues. Thank you. --Elise

1 0

Re: Are the Route Servers Viable Solutions That Are Being Held Hostage?
by sob＠academ.com 20 Dec '95

20 Dec '95

>From Gordon Cook: > To refresh folk's minds, here is what Sean said: > > The principal problem is that the RSes and the whole IRR > are only as good as the databases are, and the bulk of the > RADB was populated from the wrong source. Rather than > doing what I would consider the correct thing -- that is, > watching peerings between the RSes and the providers > participating in the various RS tests and tracking down > all the information from the IRR based on what was seen > there, verifying routing policies with end sites -- they > started with the PRDB and hoped that fate would cause the > RADB to become more correct. I think that is a bit strong to say that the RA was hoping that fate would cause the RADB to become more correct. I think the RA was hoping that the community would work with the RA to correct errors in the data originally loaded into the RA. Certainly, that has been my intent as I have worked with the data for the various ASes which I watch over. My understanding of RADB and the IRR concept in general is that it should serve as a source of information, not as a reflection of observed behavior. So filling the RADB with observed data from the RSes would not be appropriate. However, having some resource that does compare observed data to the information in the RADB would be useful. This has previously been discussed at NANOG and I recall the RA team taking some interest in exploring the possible creation of such a resource. > To be brief and blunt, the RA team started with > information explicitly designed to PREVENT connectivity > between "bad" (evil, greedy, commercial) networks and > "good" networks which would be AUP compliant. I'd think > common sense would indicate doing some extra (and well > paid) work to instead start off with something approaching > a model of the reality of interconnectivity. I agree that using the PRDB as the original source may have caused more harm than good. In my opinion, the only other approach would have been to start with an empty database and have the various providers fill it with their data from scratch. Would we now have a more accurate RADB? Maybe. Since that was the path not taken, we'll never know for sure. I believe that the more folks participate with data in the IRR, the likelyhood that errors in the data can be identified increases. > Moreover, another disappointment is that one could easily > assert that a strong reason for using the PRDB as the > source of information from day #1 was that MERIT was > already spending its resources maintaining that database > and toolset in a deal with ANS to keep ANS's network > routing working much the same way during the many months > while they figured out how to move on from the end of the > NSFNET backbone service. I am sure that the transition of ANS from the NSFNET days to the current situation involved a number of operational adjustments. I believe that anything done to help this transition go smoothly was good for everyone and not just ANS. Perhaps I am not enough of an "evil greedy bastard" (though I am an "sob" :-) to believe that ANS having problems resulting the transition is a good thing for everyone else. > In short, I think the chief failing of the RADB is not the > toolset, the concept, or the long-term plan, all of which > make some to alot of sense. Instead, what seems to have > killed it dead is that the RA was too busy to commit the > *serious* effort it would have taken to populate the RADB > with information from reality in the first place. This paragraph begs the question: Can the patient be saved? That is, if the concept, toolset and long-term plan make some to alot of sense, do we move forward by fixing the existing problems or starting over? -- 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

My Bad
by Justin Newton 20 Dec '95

20 Dec '95

Apologies for opening up the flame throwers a little too wide here on NANOG, a similar discussion was going on on another list I was on and I just kind of got carried away. I'll be quiet again now :)

1 0