- Test - lists.nanog.org

Transition & RA material via WWW
by B. Regan Knapp 20 Apr '95

20 Apr '95

Hi Everyone, I have been working over the last several weeks on reorganizing and updating Merit's Web material relating to its national networking activities. Today some of this work has been made available from the Merit top-level web home page. Information regarding the Routing Arbiter Project and the NSFNET Transition is now available from the top-level Merit home page at URL http://www.merit.edu. This information is newer and more up-to-date than the information at http://www.ra.net, or http://www.ra.net/home.html. (In the future, the http://www.ra.net address will be an alias for http://www.merit.edu) I would like to add the caveat that this information is still under construction. I have tried to concentrate on the Routing Arbiter and NSFNET Transition information, but there are a few pointers out to information on other aspects of Merit's national networking activities. The information not directly related to NSFNET Transition or RA Project is a bit more sketchy, and will be improving in the near future. If you have gotten a different address from a previous mailing from me regarding a test site, please stop using the test URL and use the one referenced in this message. This is Merit's official site. If you would like to access the NSFNET Transition or Routing Arbiter information directly, without going through the Merit top-level home page, you can use these URLs: http://www.merit.edu/routing.arbiter/NSFNET/NSF.transition.html OR http://www.merit.edu/routing.arbiter/RA/index.html respectively. Regan Knapp -- Regan Knapp Vox: (313) 936-2035 Merit Network, Inc. Fax: (313) 747-3185 4251 Plymouth Rd. Suite C email: regan(a)merit.edu Ann Arbor, MI 48105-2785 http://www.umich.edu/~brk/

1 0

Re: Has PSI been assigned network 1?
by Dale S. Johnson 20 Apr '95

20 Apr '95

Vadim, > >Following Dales comment, each provider may set its own parameters > >on generation of configurations, regardless of where it gets > >its data from. > > Sorry, the only available technology today is heavily taxed > even w/o doing massive filtering. Hey, have I got a deal for you!! Exhausted from peering with 10 or more ASs at an exchange point? Like to spend more of your time switching packets? Think the load is only going to get worse in the future? Get your routes from a Route Server! One Peer; No Fuss. Call 1-800-Routing-Arbiter. No Credit Cards needed. --Dale (PS: None of the Routing Registry, the Route Servers, or the Router Configuration Generation Tools are tied to net-based filtering. You can register your policy in RIPE-181/RPSL, and tell the generation tools (both for your routers and for the Route Server) to implement your policy with AS-path expressions rather than with net lists. Your mileage may vary.)

1 0

Re: Has PSI been assigned network 1?
by cengiz＠ISI.EDU 20 Apr '95

20 Apr '95

It seems to me that everyone has some sort of an internal policy database. Perhaps some providers actually get a call from their customers and login to their routers and update the config files to reflect that new policy. But my impression is most providers have a database (in ASCII file format, ripe-181, NACRs, mainframes, etc) and generate config files from this. The way I look at a routing registry is that a routing registry is a way of accessing each other's internal database or bringing them together in a common place accessible by everyone. For it to be useful it must have a common format, currently Ripe-181. Ripe-181 lacks certain features which are often used by US providers to describe their policies. Hence we are developing a new language, called RPSL (Routing Policy Specification Language). Please contribute to its development so that this common format is adequate for all of us. Your internal format may still be different (ANS uses a superset of Ripe-181) as long as it is converted to the common format before making it public. Now that we have common place, a repository, is this information useful? As long as there are lots of tools to access this information in useful ways, I think it is. Currently, one can configure its routers from this registry (RtConfig tool), or do diagnosis (prtraceroute) or do policy analysis (prpath, prcheck). More tools are coming. Why trust the registry, as opposed to your internal database? This is a very good point. Hence, we are also in the process of defining a hierarchical registry organization for IRR (Internet Routing Registry). Some providers (like MCI) may maintain a part of this global registry, and some may prefer to have their internal database and convert it to the common format and make it available somewhere else (say RADB or Ripe). If you wish to join rps wg and contribute or at least provide feedback, please send mail to rps-request(a)isi.edu. Cengiz -- Cengiz Alaettinoglu Information Sciences Institute (310) 822-1511 University of Southern California http://www.isi.edu/div7/people/cengiz.home

1 0

Re: Has PSI been assigned network 1?
by Vadim Antonov 20 Apr '95

20 Apr '95

Dale, thanks for the informative response (much better than our regularly scheduled flames). Few remarks: > 1) The availability of useful tools (such as prtraceroute) that will > only work correctly across you network if your data is registered > correctly. (Even if you don't use these tools, your neighbor ISPs > may start sending you prtraceroutes across your network that show your > routing or your policy description is wrong). Long time ago i asked our friends at cisco to do the neat thing which in many cases does what prtraceroute would do (note AS tags). Granted, it does not check correspondence with registry data :) SL-DC-1>trace sovcom.kiae.su Translating "SOVCOM.KIAE.SU"...domain server (192.94.207.66) [OK] Type escape sequence to abort. Tracing the route to SOVCOM.KIAE.SU (144.206.136.1) 1 SL-DC-8-F0/0.SPRINTLINK.NET (144.228.20.8) 4 msec 0 msec 4 msec 2 SL-MAE-E-H2/0-T3.SPRINTLINK.NET (144.228.10.42) 8 msec 0 msec 4 msec 3 VIENNA1.VA.ALTER.NET (192.41.177.249) [AS 701] 12 msec 4 msec 4 msec 4 VIENNA3.VA.ALTER.NET (137.39.11.4) [AS 701] 4 msec 96 msec 4 msec 5 AMSTERDAM2.NL.EU.NET (134.222.35.1) [AS 286] 88 msec 204 msec 220 msec 6 AMSTERDAM6.NL.EU.NET (134.222.32.2) [AS 286] 108 msec 104 msec 104 msec 7 HELSINKI1.FI.EU.NET (134.222.27.2) [AS 286] 200 msec 172 msec 128 msec 8 STPETERSBURG.RU.EU.NET (134.222.23.2) [AS 286] 188 msec 196 msec * 9 MOSCOW-M9-2.RELCOM.EU.NET (193.124.254.34) [AS 2118] 204 msec 188 msec 260 msec 10 MOSCOW-KIAE-3.RELCOM.EU.NET (193.124.254.38) [AS 2118] 256 msec 388 msec 424 msec 11 SOVCOM.KIAE.SU (144.206.136.1) [AS 2118] 240 msec 248 msec 188 msec SL-DC-1> > 2) The registry is the method by which you specify your policy for > the Route Servers (if you use them). Yes. That's the point -- RSes aren't immediately useful (at least with our particular setup), and registry will not have accurate data if that data is not used to actually do routing. > 3) Some other major ISPs will not route nets that are not registered. My private communications with engineering people of several major ISPs indicate that they're essentially in the same position re. RS as we are. >The email interface to the RADB and IRR is one that has been running at >RIPE for a couple of years (also an email/template interface). e-mail is fine when you file one change a week. When you have to keep a full-time person just to process NACRs (as we are) things are different. >RIPE's user community lists improving the user interface as a rather low >priority. Yeah -- but that is exactly what can kill IRR in US. >Nonetheless, the code is structured in such a way that >telnet, web, or other interfaces would be extremely easy to integrate >(once authentication was established). What kind of interface would >you like to see? telnet & web. Also, some formalized interface for direct database interaction is necessary. We configure routers automatically when implementation people create appropriate recodrs in our internal database. We'd like to do that with entering routing data as well. E-mail is not sufficient because you have to parse replies. I would prefer SMTP-style interface, so when our database program is used to configure routing it can automatically connect the IRR and update it. There should be two different IRR machines for AS owners only (the one which allows updates) and the one which responds on queries from the general public, so we can get reasonable responsiveness, w/o "please try again"s. >How often >ISPs choose to regenerate their config files is a separate question. >(I think everyone is planning updates more frequently than twice per >week now). This is inacceptable. It should be done immediately; or people will simply ignore the whole thing (why should we wait when we simply can establish BGP peering, so it will work immediately?) >If you want to add a net to the IRR and then have that change immediately >reflected in the configuration files of all ISPs who do full net-based >filtering, you may have to have some discussions with them. (But the >data will be there and waiting in the registry). No, there should be some protocol for dynamic updating ISP's copies of the database. > There should be well-defined and useful interface to service > providers databases. >I'm not sure what you mean by this. If you issue the command: "whois >-h whois.ra.net <net>" It is retrieval. It is not interactive modification. (And it is slow. I would like to be able to establish a connection and do a thousand of queries. Some my nasty scripts call whois several thousand times.) It also lacks query functions (what are all networks i'm supposed to hear from peer X?, which networks Lollypop Inc. owns?) For example, one menu of Sprint's internal database: Please enter customer ID [type Return if not known]: You may try to find the customer by: 1) Organization name 2) City name 3) Name of a person 4) Telephone/fax number 5) E-mail address 6) IP network address 7) Dial-in phone number Your choice? >> It should be secure. >This has lots of aspects. We have implemented PGP for the interface >(not yet released), and are working with the CERT to establish that >other security concerns are addressed. More specific discussion is >welcome on a smaller list. It should be _very_ secure. It would be very attractive target for hackers. PGP is fine; what about security for on-line interfaces; and who guarantees security of RS machines? A multimillion corporation cannot put its business at risk of being dependent on a machine controlled by somebody else, w/o contractual obligations on adequate security. [I understand that i want too much, but then...] >Yes, we were listening in Boulder. Some enhancements (to support >AS-path expressions) have all ready been coded, and Cengiz Alaettinoglu >and Daniel Karrenberg have all ready set up an IETF working group with >an aggressive schedule for implementing for an enhanced language. >(An early version of the implementation is started, I believe). Glad to hear that :) --vadim

4 3

Re: Has PSI been assigned network 1?
by Vadim Antonov 20 Apr '95

20 Apr '95

Hank Nussbacher <HANK(a)taunivm.tau.ac.il> wrote: >The e-mail interface >of NACRs is close to uselessness, and too big headache to deal with. >Waiting time on processing is simply ridiculous. >I've been sending updates to auto-dbm(a)ripe.net for the past 2 years >with no problem. You don't have to keep a full-time engineer just to handle NACRs, do you? >There should be a host accepting telnet sessions for on-line >updates (which have to be installed *immediately*, so whoever >added a network can test connectivity and go ahead). >telent info.ripe.net to test it out. RIPE database does not control the actual routing. I'm not sure the current RADB project has any mention of real-time updates of gated from the database. With dozens of updates we do every day it nearly as good as useless. >There should be well-defined and useful interface to service >providers databases. > >It should be secure. >I use a password on all AS updates to AS378. You call *that* secure? We have way too many people who need to do changes for our AS-es. Check the contact list for AS1800. > Without that i do not see RADB being successful or useful beyond the > point of filtering updates from particularly obnoxious peers. >It may not have everything we want today but it is an excellent starting >platform. If i can't implement my existing policy, i cannot use RADB, ok? (Well, we _will_ use it -- to talk to people whose announcements are loaded with garbadge). We simply cannot use it to talk to major service providers because policies in place cannot be represented in RIPE-81. --vadim

4 3

Re: Has PSI been assigned network 1?
by Sean Donelan 20 Apr '95

20 Apr '95

> > If pizzahut wants to reach a wider community, they can ask their > > provider to register their route in the RADB. From a routing > > standpoint all it needs is the prefix, prefix length, and the home-AS. >Right! Case in point that there is some benefit you may get from >registereing in the routing registry. Another benefit would be more >meaningful output from tools like prtraceroute: Of course I notice the lack of PRDB/RADB/IRR registration didn't effect your reaching the network. It seems to be a very reachable site regardless of one or two network provider's policies. Yes, network providers can stamp their feet and say they won't accept a network announcement unless it is in the IRR, or is not properly CIDRized, or is not an even number. But there will be other network providers who will get your traffic there anyway. So you have a choice, use one network provider who only routes "registered" networks and not reach certain sites. Or choose a different network provider who isn't as dogmatic and reach more networks. I use www.pizzahut.com as an example because it is memorable. You may not be able to justify it as R&E. But it makes for an easy to demostrate, concrete example of the effects of policy on Internet routing for the layperson. There are several hundred similar networks in the "Greater Internet." Somehow life goes on even though one or two network providers deny their customers access to these networks. Maybe we should change the slogan to "The Internet treats dogmatic policy as damage and bypasses it." Welcome to the competive market. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

Re: Has PSI been assigned network 1?
by Vadim Antonov 20 Apr '95

20 Apr '95

jgs(a)aads.net (John G. Scudder) wrote: >What AS690 does is not just bureaucratic silliness. It's also enlightened >self-interest (as Curtis keeps saying). If enough people have the sense to >want to protect themselves, the Routing Registry will fly. I agree with the idea of Routing Registry (although i'm more than sceptical about RADB in its present form, replacing distributed computation with a cental box not controlled by the service providers). However, my point is that it should be easy to use and should be on-line; the NACR-style configuration nightmare is not going to fly. --vadim

6 6

Re: Has PSI been assigned network 1?
by Hank Nussbacher 20 Apr '95

20 Apr '95

On Wed, 19 Apr 1995 13:50:52 -0400 you said: >Well, there is a big _if_: if things will work w/o RADB (and they >will, for no sane provider will use RADB as the sole source of >exterior information at peering points, not for at least before >it became the proven and stable service) -- people will forget >to update things, cut the corners, etc. The Ebone access I get via CERN is controlled strictly via the prototype RADB at ripe.net. It works flawlessly. >RADB got to be easy to use to become real. The e-mail interface >of NACRs is close to uselessness, and too big headache to deal with. >Waiting time on processing is simply ridiculous. I've been sending updates to auto-dbm(a)ripe.net for the past 2 years with no problem. >There should be a host accepting telnet sessions for on-line >updates (which have to be installed *immediately*, so whoever >added a network can test connectivity and go ahead). telent info.ripe.net to test it out. >There should be well-defined and useful interface to service >providers databases. > >It should be secure. I use a password on all AS updates to AS378. >RADB should be able to implement _existing_ routing policies, >not the subset which can be defined in RIPE-81 (it currently >can't, there are places which use a lot of _very_ hairy stuff). > >Without that i do not see RADB being successful or useful beyond the >point of filtering updates from particularly obnoxious peers. It may not have everything we want today but it is an excellent starting platform. >--vadim Hank

2 1

Re: Has PSI been assigned network 1?
by Sean Donelan 20 Apr '95

20 Apr '95

>We don't trust our peers. We only accept routes which they are >registered as providing transit for in the PRDB. When the RADB is in >use, unless PSI has a route object for 1.0.0.0/8 in the RADB, we still >won't trust them when they try to pass us 1/8. Then you're back to the www.pizzahut.com(192.112.170.243) example. Reachable from most places as long as you don't touch NSFNET/ANSNET and the PRDB. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

3 2

Re: Has PSI been assigned network 1?
by Vadim Antonov 20 Apr '95

20 Apr '95

>Is PGP secure enough for you? Secure _telnet_. >RIPE-181; it's different. Not that much. I used RIPE-81 as a generic name. In general case routing policies which can be implemented by border routers _cannot_ be implemented in a central box interfacing those border boxes -- simply because those boxes may have (and do have) exterior peering sessions on other links/LANs. A large part of routing policies (particularly between US and Europe) is implemented as intricate interior weighting systems between announcements from different sides. Whoever wants to play with it can have our ICM-DC-1 configuration, just to try to represent what it does in RIPE-181 format. >Without that i do not see RADB being successful or useful beyond the >point of filtering updates from particularly obnoxious peers. Which is already a big win, seeing as how there are a good number of particularly obnoxious peers out there, some of them quite large. >I have to ask if you have actually looked at the RADB and surrounding >pieces at all. I've read papers abour RADB. They're not very clear on many issues. In any case, my point is that RADB has to be provider-friendly to be successful. --vadim

2 1