- Test - lists.nanog.org

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

Re: Pacific Bell NAP Upgrade
by Warren K. Williams 19 Dec '95

19 Dec '95

Pushpendra: > >Do you plan to connect the SF and the S. California NAP together or will the >S. California NAP be a standalone exchange point ? > >How do you plan to work with the MAE-LA , deployment for which is already >underway, or will this be another MAE-West/SF NAP like situation ? > We are exploring all our alternatives at this point. Kind regards, Warren ------------------------------------------------------------------------------ Warren K. Williams, Director - Network Access Point Pacific Bell Business Communications Services Email: wkwilli(a)pacbell.com Phone: 510.867.9065 ------------------------------------------------------------------------------

1 0

NANOG input to Renumbering (PIER) WG
by wel＠faline.bellcore.com 19 Dec '95

19 Dec '95

The experience and advice of the NANOG community is requested: A new working group (Procedures for Internet/Enterprise Renumbering) is being created in the IETF to support the immediate need for renumbering networks and organizations. Our focus is on what needs to be done with the existing real world, and what's available now to help with the task. Towards this end, we are asking for case studies: actual experience with renumbering networks. tools: information on what tools helped and how they were used. application problems: information on applications that required special attention, and what solutions you may have come up with. We want to get our documents out by this summer at the latest, so we're asking for as much as possible in the way of input by the start of February (so we can put some preliminary work together for the March IETF, and shape our further efforts based on your advice), with all input by May 15. Please send your information to the PIER discussion list, pier(a)isi.edu You may also send it to the editors of the documents directly, without its appearing on the public discussion list, at pier-solicit(a)bellcore.com An Internet Draft, draft-ietf-pier-solicitation-00.txt, describes our request in more detail. Besides the standard I-D servers, it is also available at ftp://ftp.bellcore.com/pub/wel/PIER/solicit.txt With appreciation for your help, Will Leland wel(a)bellcore.com

1 0

Re: Not to beat a dead horse
by William Allen Simpson 19 Dec '95

19 Dec '95

> From: Avi Freedman <freedman(a)netaxs.com> > But I still see 4 /24s advertised in 208/8: > > Now, besides the fact that 208.0.4.0 & 208.0.5.0 could be 208.0.4.0/23 > (grin), what IS the appropriate way to deal with an ongoing situation > where un-NIC-allocated IP space is advertised on the Internet? > My solution would be to filter the routes based on AS. Someday, those routes will be announced from a valid provider, and you will need to know the valid AS from which they should be announced to ignore the bogons. > We have no plans to implement incoming route filters on 208/8 - who > knows when the NIC will start allocating out of it. > The RA knows? Maybe this is a valid use of the RADB? Cannot the NIC update the RA with both prefix and AS? 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