- Test - lists.nanog.org

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

Re: Sprint Service Problems
by sgoldste＠nsf.gov 20 Dec '95

20 Dec '95

First, if you are getting SPAMmed with <furlough> messages from NSF, sorry. The server does it automagically. I am still reading my mail from home, though now in an UNOFFICIAL capacity, as I am forbidden from performing gummint service... Next, please realize that the operational and implementor folks at Sprint are held hostage to the big bureaucrazy problem: they have to wait each year for the next budget cycle to play catch-up with their performance needs. So, do your best to help them by sending constructive comments to them for them that they might show to their top-level management that is still living in the days of voice telephony with 25-year depreciation cycles on central office gear. Don't stop complaining, but try to give the clueful guys within Sprint something to help them win the good fights internally. This, obviously goes for other service providers, too. --SG (Furloughed Fed) ____________________________________________ Steve Goldstein, National Science Foundation +1(703)306-1949 Ext. 1119 "Let's not procrastinate until tomorrow!"

5 5

Re: Sprint Service Problems
by Melise 20 Dec '95

20 Dec '95

Mr. Lewis, If you are a Sprint customer and are not calling these service lapses to their Network Management Center's attention, you are not giving them the opporturnity to serve you properly. Escalate the problem. respectfully, Melise Jones Sustaining Engineer BBN Systems and Technologies

3 2

Sprint Service Problems
by dlewis＠Teir.COM 19 Dec '95

19 Dec '95

Its days like this when I just love sprint: 8 sl-dc-8-F0/0.sprintlink.net (144.228.20.8) 12 msec 16 msec 12 msec 9 sl-dc-6-F0/0.sprintlink.net (144.228.20.6) 16 msec 20 msec 16 msec 10 sl-dc-8-F0/0.sprintlink.net (144.228.20.8) 24 msec 16 msec 12 msec 11 sl-dc-6-F0/0.sprintlink.net (144.228.20.6) 16 msec 16 msec 16 msec 12 sl-dc-8-F0/0.sprintlink.net (144.228.20.8) 12 msec 20 msec 12 msec 13 sl-dc-6-F0/0.sprintlink.net (144.228.20.6) 12 msec 16 msec 16 msec 14 sl-dc-8-F0/0.sprintlink.net (144.228.20.8) 20 msec 24 msec 16 msec 15 sl-dc-6-F0/0.sprintlink.net (144.228.20.6) 16 msec 16 msec 20 msec 16 sl-dc-8-F0/0.sprintlink.net (144.228.20.8) 16 msec 20 msec 16 msec 17 sl-dc-6-F0/0.sprintlink.net (144.228.20.6) 16 msec 20 msec 16 msec 18 sl-dc-8-F0/0.sprintlink.net (144.228.20.8) 16 msec 16 msec 16 msec 19 sl-dc-6-F0/0.sprintlink.net (144.228.20.6) 16 msec 12 msec 16 msec 20 sl-dc-8-F0/0.sprintlink.net (144.228.20.8) 16 msec 20 msec 16 msec 21 sl-dc-6-F0/0.sprintlink.net (144.228.20.6) 20 msec 16 msec 16 msec 22 sl-dc-8-F0/0.sprintlink.net (144.228.20.8) 16 msec 16 msec 12 msec 23 sl-dc-6-F0/0.sprintlink.net (144.228.20.6) 20 msec 16 msec 16 msec 24 sl-dc-8-F0/0.sprintlink.net (144.228.20.8) 20 msec 28 msec 20 msec 25 sl-dc-6-F0/0.sprintlink.net (144.228.20.6) 16 msec 16 msec 16 msec 26 sl-dc-8-F0/0.sprintlink.net (144.228.20.8) 12 msec 12 msec 16 msec 27 sl-dc-6-F0/0.sprintlink.net (144.228.20.6) 20 msec 16 msec 16 msec 28 sl-dc-8-F0/0.sprintlink.net (144.228.20.8) 24 msec 16 msec 12 msec 29 sl-dc-6-F0/0.sprintlink.net (144.228.20.6) 16 msec 16 msec 16 msec 30 sl-dc-8-F0/0.sprintlink.net (144.228.20.8) 16 msec 20 msec 24 msec Sadly this is all too common of an occurrence. What is sprint doing to help keep problems like this from becoming chronic? Is it just me or is Sprint particularly bad about this? I guess the reason that I'm bringing this up here is I wonder if these types of problems are the result of any particular choices Sprint made in their design.... If so I would like to know how to avoid them. :) I know that hardware fails and things break, but Sprint has had (in my opinion) more than it's share of problems. -D Darrel Lewis Network Engineer Thomson Electronic Information Resources dlewis(a)teir.com

3 2