- routing-wg - mailman.ripe.net

RE: Routing wars pending?
by Wilfried Woeber, UniVie/ACOnet 15 Nov '95

15 Nov '95

Hi Hank! I don't know to what extent you have been following the discussions recently within RIPE wrt Registries of Last Resort... My first answer to the story below would be "stop the Registry of Last Resort business asap". Just to avoid making the mess even bigger... >ILAN acts as registry of last resort in Israel. It owns and assigns >IP addresses in the 192.114-118.0.0 address range. These 5 blocks >are owned by ILAN (AS378). Over the years, many IP addresses have >been assigned - in the past to individual companies and more lately >CIDR blocks to local ISPs. ILAN takes a $50 one time fee to register >the IP address for the requestor. Just a matter of terminology, I'm worried by your mixing of the LRL function and phrases like "owns and assigns" in the same sentence with "owned by ILAN (AS378)". If you were really sending these signals to your peers then there is a good chance of mis-understandings. With regard to the rest of your message - here is what we do, both as a Service Provider Registry and a as backbone provider which has to deal with routing: We strictly refuse requests to assign address space for further sub-assignement. Adresses are *directly* assigned to the eventual user. If a service provider wants to act as a Local-IR, then the proper way of doing it is to get in touch with the RIPE-NCC and establish a registry of it's own. Just to make sure that everybody understands the rules, we explicitely point out that the assignement is only valid for the purpose of connecting (directly or through an intermediate step) to our backbone. We explicitely reserve the right to reclaim the address space if these conditions are not (or no longer) met. I know that RLR are slightly different, of course. With regard to routing, the answer is both collaboration by all service providers (which is working rather well, I think) *and* filtering based on the route objects in the RIPE database (which appears to gain popularity). If somebody tries to play games, and most of the backbones would have filters, then there is a good chance that the hickup is confined to a small part of the Internet - which eventually makes the "highjacked" addresses more or less useless. And the multiple database issue should be sorted out anyway, because the problem of inconsistency *is* there, even without malicious intent on any side. Wilfried. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at Computer Center - ACOnet : Vienna University : Tel: +43 1 4065822 355 Universitaetsstrasse 7 : Fax: +43 1 4065822 170 A-1010 Vienna, Austria, Europe : NIC: WW144 --------------------------------------------------------------------------

1 0

New Document available: ripe-131
by RIPE NCC Document Annoucement Service 23 Oct '95

23 Oct '95

New/Revised RIPE Document Announcement -------------------------------------- A revised/new document is available from the RIPE document store. Ref: ripe-131 Title: The Advisory Attribute Author: David Kessens, RIPE NCC Date: 23 October 1995 Format: Obsoletes: ripe-130 Obsoleted by: Updates: ripe-181 Updated by: Old: Short content description ------------------------- Adds 'advisory' attributes to 'aut-num' objects. Use with care. FTP Access ---------- All RIPE documents and Internet RFC`s are available via anonymous FTP from host ftp.ripe.net. Type "ftp ftp.ripe.net". Login with username "anonymous" supplying your email address as the password. After logging in, type "cd ripe/docs/" followed by the command "get filename". The relevant filenames for this document are: ripe-131.txt for the ASCII version ripe-131.ps for the PostScript version Electronic Mail Retrieval of Documents -------------------------------------- Documents can also be retrieved from the RIPE document store using a mail server program. For more information on how to use the program, send email to: mail-server(a)ripe.net with "send HELP" in the body text. RIPE NCC Interactive Information Server --------------------------------------- Type "telnet info.ripe.net". This is a menu driven service allows the document store to be browsed. After reading documents you are prompted as to whether you would like to receive an email copy of the document you have just read. If you would, you simply enter your email address and the document will be mailed to you. Below are details of alternative methods of access. Gopher Access ------------- The same documents are available via a "gopher" server at "gopher gopher.ripe.net". WAIS Access ----------- There is also a "WAIS" server at wais.ripe.net, where there is a WAIS index for RIPE documents "ripe-docs.src" WWW Access ---------- For those who wish to add this home page at the RIPE NCC to their own customized home pages, it can be accessed as: http://www.ripe.net MIME Mail Reader ---------------- Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the RIPE document by FTP or mail server. SEND ripe/docs/ripe-131.txt

1 0

New RA Tools Announcement
by Brian Renaud 18 Oct '95

18 Oct '95

Here is some additional location information for a number of the tools I discussed at the last meeting. -Brian ------- Forwarded Message Date: Wed, 18 Oct 1995 13:34:21 -0400 From: labovit(a)merit.edu To: nanog(a)merit.edu Subject: New RA Tools Announcement New Routing Arbiter Tools Announce ---------------------------------- The Routing Arbiter welcomes comments, bug-reports and suggestions for new tools. Please direct email to ra-team(a)ra.net. Please feel free to redistribute this announcement. A web version of this page lives at http://www.ra.net/~ra/tools ------------------------ Online Tools and Reports ------------------------ IRRWeb This graphical interface into the Internet Routing Registry makes it possible to use the Web to query the IRR and update RADB AS objects, Route objects, and Maintainer objects. Users can enter any value that can be submitted through a whois query, such as an AS number, network IP address, or maintainer. IRRWeb then displays the corresponding AS objects, Route objects, or Maintainer objects from the various registries in the IRR. Authorized maintainers can edit the objects directly; IRRWeb performs a cursory pre-check and mails the revised object to auto-dbm(a)ra.net. The user then receives e-mail from auto-dbm confirming and displaying the revised object, or explaining why the object was rejected. See http://www.ra.net/cgi-bin/ra/query-radb.pl Source code is available at ftp://ftp.ra.net/routing.arbiter/tools/irrweb.tar.gz Daily NAP Route Flap Reports</A> This new tool set generates daily reports of route flaps (link failures at regular and short intervals) throughout the Internet. Modeled after the reports originally produced by Curtis Villamizar of ANS, the new reports are generated using tools packaged with Merit's Multi-Threaded Routing Toolkit. The data is obtained from peering sessions with Route Servers at the interconnection points. The reports note the last state of the route (up or down), the length of time that a route existed (or did not exist) for that prefix, and the number of times a route for the prefix transitioned from down to up, up to down, or was replaced by a new route with changed attribute information. AS-path-specific information is also provided for every path announced for the prefix. See http://www.ra.net/~ra/tools/flap.html Route History Server The Route History Server provides a mechanism for tracking the announce/withdraw history of a given prefix for the last 24 hours. The History Server peers with the route servers at each NAP and records all BGP updates in History Server/Route Server peering session. See http://www.ra.net/cgi-bin/ra/rshist.pl ----------------------- Tools Available for FTP ----------------------- RSd The Route Server daemon (RSd) is an enhanced version of the GateD routing software that provides multiples views of routing information. The software provides a mechanism for network service provides to off-load the computational complexity of routing policy calculations from their routers. RSd supports configuration and transparent passing of BGP MEDs. The software also supports BGP route flap dampening. Available at ftp://ftp.ra.net/routing.arbiter/tools/rsd.tar.gz Peval A policy evaluator that inputs a RIPE-181 policy expression, performs essential background calculations such as symbolic evaluations and expansions, and outputs another RIPE-181 policy expression that is used by other tools, such as RTConfig. Available as part of the RAToolSet at ftp://ftp.ra.net/routing.arbiter/tools/RAToolSet RTConfig A router configuration tool that can be used by providers to generate router configs directly from the RADB or other IRR registries. Currently in production use for the RA Route Servers, ANSNET, and CA*net, RTConfig is a front-end tool that uses peval and radbserver transparently to users. Available as part of the RAToolSet at ftp://ftp.ra.net/routing.arbiter/tools/RAToolSet rrc2r/rrmerge This Cisco-to-RIPE-181 conversion package makes it possible for users to convert Cisco router configuration files to RIPE-181 objects that can be submitted to the Internet Routing Registry (IRR). The Cisco access-list can be converted into an explicit set of nets embedded in an AS object or represented as a community. The RADBserver is queried for any missing or previously registered information. Available at ftp://ftp.ra.net/routing.arbiter/tools/RAToolSet/rrc2r-0.2.tar.gz CiscoBGP IRR users have long recognized the need for tools that check the IRR against routes actually propagated in the Internet. CiscoBGP obtains and analyzes routing information from production Ciscos, and compares the data with routes in the IRR. The software also flags prefixes that are reserved by RFC 1597, Address Allocation for Private Internets. Available as part of the MRT software distribution at http://www.merit.edu/~mrt BGPCheck BGPCheck obtains and analyzes routing information from BGP4 peering sessions, and compares the data with routes in the IRR. The software also flags prefixes that are reserved by RFC 1597, <em>Address Allocation for Private Internets</em>. Available as part of the MRT software distribution at http://www.merit.edu/~mrt PRtraceroute The 'prtraceroute' tool is a powerful form of traceroute that displays the Autonomous Systems that a packet traverses. PRtraceroute was developed by the Pride project. A version of prtraceroute that queries the RADB is available at ftp://ftp.ra.net/routing.arbiter/pride/prtraceroute-2.0beta2.shar.gz ------------------ Tool Announcements ------------------ PGP-Based Radb Authentication Follow these steps to take advantage of the new RADB support for PGP-based digital signatures: 1. Register your public key with the Routing Arbiter Service. 2. Modify your Maintainer object to reflect your use of digital signatures. 3. Use PGP to sign your RADB transactions. For detailed instructions, see: http://www.ra.net/routing.arbiter/RA/RADB.tools.docs/pgp.html -- Craig Labovitz labovit(a)merit.edu Merit Network, Inc. 4251 Plymouth Road, Suite C. (313) 764-0252 (office) Ann Arbor, MI 48105 (313) 747-3745 (fax) ------- End of Forwarded Message

1 0

Re: Minutes of the Routing WG session (first draft)
by Brian Renaud 17 Oct '95

17 Oct '95

> A C T I O N on Brian Renaud: Making the transparencies of his presentation > of the RA Project publicly available (both on the Merit and the RIPE FTP/ > WWW servers) The postscript is now available at: ftp://ftp.ra.net/routing.arbiter/radb/presentations/RIPE-22_renaud_routing.… the compressed version is at: ftp://ftp.ra.net/routing.arbiter/radb/presentations/RIPE-22_renaud_routing.… z -Brian

1 0

Server updates for WWWhois
by Paolo Bevilacqua 16 Oct '95

16 Oct '95

Hello, As requested at the last WG meeting, i'm going to complete the list of the whois servers supported by the Web interface that is available at: http://black.uni.net/cgi-bin/whois After this step you're welcome to install this script at your site. Please mail me about the known servers and the associated email address for updates.

1 0

Minutes of the Routing WG session (first draft)
by Schmitz＠RUS.Uni-Stuttgart.DE 16 Oct '95

16 Oct '95

Routing WG M I N U T E S Thursday, 12-10-95, 9:00 - D R A F T - (additions/corrections welcome) Chairman Jan Willem Scheun was ill. Rob Blockzijl volunteered as temporary chairman for this specific session. There was no draft agenda. It was set up on the fly with three topics 1. The RA Project a presentation by Brian Renaud (Merit) 2. The RIPE Routing Registry an overview by Daniel Karrenberg (RIPE NCC) 3. RIPE Routing Registry, R & D overview by Daniel Karrenberg (RIPE NCC) There were no additions from the audience. 1. The Routing Arbiter Project presentation by Brian Renaud (Merit) After filling in the historical background an overview was given of the transition from the old NSFNET PRDB to the new RADB and a description of the current situation including Route Servers and some current data from the present RADB. Then the current initiatives were presented, e.g. continued clean-up of the database, generation of usage and analytical reports, support for RSPL extensions, and support for PGP authentication (with a trial setup running at the moment). Afterwards, Brian Renaud gave a review of the tools recently developed at the RA Project. There are several tools which handle, e.g. configuration from the database policy generator from configuration monitoring of running networks These tools are now not only developed for the Router Servers (which are Sun Workstations) but also for Cisco Routers. There are also various tools under development which among other things feature a GUI for selected tasks. Brian Renaud wants input on the tools from anybody who wants to use them or has contributions/suggestions. Mail addresses are on the transparencies which will be made available soon. A C T I O N on Brian Renaud: Making the transparencies of his presentation of the RA Project publicly available (both on the Merit and the RIPE FTP/ WWW servers) 2. The RIPE Routing Registry Daniel Karrenberg only had a few remarks - The RIPE database is cleaned up from obsolete data. In most cases the responsible persons are directly contacted - The data in the registry are compared to the real world - Tools for the router configuration from the database are most valuable. The NCC wants to make the Merit tools better known in Europe and wants to participate in their development (see below) and immediately opened the discussion. The topis were: - How to handle changes with large numbers of objects (both RADB, RIPE)? They may be done using the automatical machine interface or by submission to the human interface by personal mail (especially for global changes). - Is the RADB publicly available like the RIPE database? It may be fetched via FTP from the Merit server. However, it may be made available on the RIPE server. They mirror it anyway. A C T I O N on the RIPE NCC and Merit: making the RADB publicly available on the the RIPE FTP server (if Merit concords) - What is the status of the advisory tag? The advisory is not yet obsolete. ANS still needs it for operation. For European ISPs advisories are only necessary in the RIPE database. There is no encouragement to register in more than one registry because of the planned GRR which is under construction. A C T I O N on the RIPE NCC: find a FINAL date together with ANS when to give up advisory tags. This was especially stressed by Daniel Karrenberg. - Do ISPs register in the RIPE database? They do not only register but surprisingly many also maintain their data. This is enforced by the RIPE NCC a bit which makes registration of a routing policy mandatory when registering a new AS. There is a general feeling that many more will register and maintain data if proper tools exist to make it easier. Data on the database population will be made available again (as it was done in the PRIDE project). The quality of the data will be checked by RIPE NCC (whether data are updated, consistent, correct...) - There was some discussion on authentication, PGP, and cryptography, mostly related to the RADB as first implementation and future ideas for the RIPE database. PGP authentication by signature is formally a simple new value of the "auth"-tag in the maintainer object (RADB test suite). However, the PGP keys must be savely stored at the database site. There was some discussion on how to do this (in or out of the database). From the experience of both RIPE NCC and Merit there were only very few attempts to willingly change objects of other parties when not being allowed to. They were all detected through the notification facility (which is the same for RADB and RIPE database because the same database manager code is used). Therefore, it does not seem to be necessary to have strong authentication (or even cryptography). However, some organisations like PTTs have stronger security demands and ask for it. They would not register without. 3. RIPE Routing Registry, R & D Rob Blockzijl points out that the RIPE NCC wants to enforce R & D again. Daniel Karrenberg states that the RA people do more for the progress than the RIPE NCC. The RIPE NCC and the Routing WG should/want to do more. A focus should be found to make information in the routing databases significantly more useful. A first step had been taken by development of diagnostic tools in the PRIDE project. This effort should be extended not only on diagnose but also on tools for configuration and real time analysis and monitoring. There are other fields which should be considered but these are the most important. More useful architectural work should be done and one area should be chosen to join the efforts of the RA project group. The following discussion in the audience did not lead to a final conclusion on which area to chose. Therefore, two actions are placed on the RIPE NCC: A C T I O N on the RIPE NCC (Daniel Karrenberg): to trigger the discussion on the mailing list of the Routing WG, which focus to choose for a future tool development project and to come to concensus on it. A C T I O N on the RIPE NCC (Daniel Karrenberg): based upon the focus found in the Routing WG to prepare a draft paper for the new project and to present it at the next RIPE meeting in January. Scribe: Joachim Schmitz, DFN-NOC ---------- If I forgot anything or did not record something correctly just send me your additions/corrections. Thank You! Regards Joachim Schmitz _______________________________________________________________________________ Dr. Joachim Schmitz schmitz(a)rus.uni-stuttgart.de DFN Network Operation Center Rechenzentrum der Universitaet Stuttgart ++ 711 685 5576 voice Allmandring 30 ++ 711 678 7626 FAX D-70550 Stuttgart FRG (Germany) _______________________________________________________________________________

1 0

PGP authentication for the RADB (fwd)
by Elise Gerich 07 Sep '95

07 Sep '95

several folks have asked me to forward information from the routing arbiter project that would be of broader interest. thought you all might like to know about our pgp key plans (i think that jean-michel asked about this at the last ripe meeting.) --elise >Brian Renaud writes: > From nanog-request(a)MERIT.EDU Thu Sep 7 11:52:50 1995 > Resent-Date: Thu, 7 Sep 1995 11:52:39 -0400 > Message-Id: <199509071552.LAA21225(a)home.merit.edu> > From: Brian Renaud <renaud(a)MERIT.EDU> > To: nanog(a)MERIT.EDU > Subject: PGP authentication for the RADB > Reply-To: renaud(a)MERIT.EDU > Date: Thu, 07 Sep 1995 11:52:31 -0400 > Sender: renaud(a)MERIT.EDU > Resent-Message-ID: <"obcC1.0.5z.2LnJm"@merit.edu> > Resent-From: nanog(a)MERIT.EDU > X-Mailing-List: <nanog(a)MERIT.EDU> archive/latest/24 > X-Loop: nanog(a)MERIT.EDU > Precedence: list > Resent-Sender: nanog-request(a)MERIT.EDU > > > The RADB now supports authentication using PGP-based digital signatures. > If you want to use this feature, there are three things you must do: > > * Register your public key with the RA. > > * Modify your maintainer object to reflect your use of digital > signatures > > * Sign (via PGP) your RADB transactions. > > > 1. Registering your public key with the RA. > > You must send your public key to the RA for inclusion onto our PGP > keyring. Use the "pgp -kxa" command to generate a copy of your public > key suitable for mailing, then mail the resultant file to > db-admin(a)ra.net. > > For example: > > % pgp -kxa smith(a)ra.net pubkey > ... > % mail -s 'please register my public key' db-admin(a)ra.net < pubkey.asc > > > > You may use one of two methods of verification: > > * Fax a copy of a photographic identification (passport or drivers license) > to: > > RADB public key verification > +1 313 747 3185 > > please write your PGP fingerprint and email address on the fax > > * Attend an RA sponsored key signing session at NANOG or IETF. You > will need to bring a copy of your public key with a PGP fingerprint > and photo identification. (This will be verification via the > identification you bring, rather than having two other people agree > that you are who you say you are.) > > We will be holding a key signing at NANOG on Monday, September 11 at > 5:00. If that time is not convenient, you can also accost RA team > members at random and present them with with the appropriate > information. > > > 2. Modifications to the maintainer object > > There is a new authentication option for the maintainer object. The > syntax for it is: > > auth: PGP-FROM {PGP User Id} > > For example, > > auth: PGP-FROM John Smith <smith(a)ra.net> > > > 3. Signing your RADB transactions > > You will need to PGP-sign each transaction you send to > auto-dbm(a)ra.net. Use the "pgp -sta" command to do this. > > For example: > > % pgp -sta -u smith(a)ra.net routes > ... > % mail -s 'route updates' auto-dbm(a)ra.net < routes.asc > >

1 0

RA Service at Sprint Nap
by Elise Gerich 18 Aug '95

18 Aug '95

The Routing Arbiter Service is pleased to announce it is fully in production at the Sprint NAP. Two route servers are installed at the Sprint Nap to provide redundancy, and the route servers are configured daily. The route server configurations are based on the routing policy information stored in the Internet Routing Registry. The IRR contains the full set of data from five databases: Routing Arbiter Database, RIPE Database, internetMCI Database, CA*net Database, and ANSnet Database. For more information about the RA Service check http://www.ra.net or to use the RA Service at the Sprint Nap, send mail to ra-peer(a)ra.net --Elise

1 0

routing minutes - draft - ripe21
by Willem van der Scheun 31 May '95

31 May '95

Here are the draft minutes of the routing WG held at the 21th RIPE meeting in Rome. Please give your comments, if any, before June 9. DRAFT -- DRAFT -- DRAFT -- DRAFT -- DRAFT -- DRAFT -- DRAFT -- DRAFT -- Routing Working Group Minutes RIPE 21 Rome, May 8, 1995 Chairman: Willem v.d. Scheun ---------------------------- 1. Opening and agenda bashing Willem v.d. Scheun opened the session and welcomed everyone to the meeting. The agenda was agreed with some scheduling changes which will be reflected in the minutes. 2. Minutetaker Anne Lord volunteered to take the minutes. 3. Status of the Route Arbiter project, Elise Gerich, Merit 3.1 PRDB -> RADB transition. There was much discussion during and following Elise's presentation. The main points are: - May 8th (day of WG meeting) is the last day that NACR's will be accepted by Merit. After this date, old style NACR's will automatically be translated into ripe-181 compliant route objects. Objects should be sent to : <auto-dbm(a)ra.net> - If you have registrations in the PRDB your data will automatically be converted. - If you require connectivity to AS690 you will need to register your route in the RADB using the "advisory" tag. As AS690 config files are currently generated from the RADB only. - The "advisory" tag replaces the old-style NACRS but will be short term only The end of May was mentioned as the "short-term". - Global IRR schema means that registering in one RR should be sufficient. However, registering in more than one database will be allowed but not encouraged. Problem of determining priority when there are conflicts in RR data is still not solved. Question was asked concerning how to remove duplicates once priority issue was resolved? There was some discussion, but the problem has yet to be resolved. 3.2 RA Project Project began on July 1st, 1994 as collaboration between Merit, ISI (and IBM). ISI and IBM are responsible for the software development of the Route Server and advanced protocol development. Merit is responsible for development and maintenance of the RADB, network management and routing engineering. Current status: - 6 route servers (RS) are deployed: o 2 Mae East o Sprint NAP o Ameritech o PacBell o Mae West (not fully operational) - Main interconnection-point effort is focussed on Mae East. o 15 ISP's present o 11 peering with primary RS and backup o 6 import and exporting routes from RS. o none is yet fully dependant on RS. o only problems reported have been from Sprint. Elise reported that for the last 10 months RSes have been operational, although the fact has not been communicated since more network management tools were needed and the NOC does not yet have out of band access to the RSes. - Network Management Area development o deployed bi-lingual SNMP agent v.2 o Discovery Rover code - reports on state and topology of net. - NOC formerly ANS, now Merit, University of Michigan. - RADB is implementation of ripe-181. Some extensions to the syntax were necessary. Specifically there are now attributes: o extended-interas-in o entended-interas-out - PGP v.2.6 email authentication added. Development work done by Laurent Joncheray. Description of the mechanism can be found at: o http://www.ra.net o ftp://ftp.ra.net/routing-arbiter/tools/RAToolSet - Software development by Cengiz Alaettinoglu on tools that generate config files for ripe-181 policy expressions. Tools are (available from above URL's): o rtconfig o toolkit There was a question concering duration of project and available resources. The RA project is a 5 year project which will terminate in 1999. 14 people are working on the project. All the software is public domain. 4. Report on the population and usage of the routing registry - RIPE NCC - Maintainence of the RR is a RIPE NCC core activity. - Little time for actual work to date - current resources are 1 hour per day from Mirjam Kuehne and Anne Lord. - 3 stage workplan developed based on BGP dump of amsterdam.ripe.net o chase non-registrations of ripe-181 policy of EU ASes -> nag. o extract AS path and compare with registered policy -> nag. o develop tools to do above work auto-magically Comments: - Question concerning the consistency of route objects and the home AS. Is this part of the RR activity? Answer was yes, but focus of effort prioritised to above. - Registering in the RIPE RR is vital. When "advisory" tag goes away, some EU networks not registered may lose some connectivity. - Ideal end state is to register in one RR only. This should be sufficient for full connectivity. - Should be free (but not encouraged) to make multiple registrations. Currently some RR's require this (MCI & RADB). Seen as short-term (+/- 2 weeks). Advice for now is to make multiple registrations. - Currently RR's mirror each others databases. RIPE NCC will monitor dual registrations. 5. Routing Policy System (RPS) - Importance of ripe-181 acknowledged as document has become rfcxxxx standards track document. - IETF working group formed o rps - Charter o to develop a routing policy description language based on ripe-181. o co-ordinate efforts of various RR's - Co-chaired o Cengiz Alaettinoglu o Daniel Karrenberg. - Mailing list establised. To subscribe send mail to o <rps(a)isi.edu> o <rps-request(a)isi.edu> 6. CIDRD wg report (Danvers IETF) - ALE wg merged with CIDRD - ALE is now 2018 +/- 8 years - Analysis of address space utilisation was presented. Stats were taken from amsterdam1.dante.net. Figures showed that in 193/194 blocks there was an average of 4,000 hosts per route. CIDR works! - Routing table growth slowing down. Chief problems now seen to be route update processing and flapping. - Yakov Rekter presented paper which will soon become Internet Draft o "Address Ownership Considered Fatal" Paper discusses problems arising from portable address space. All ISP's encouraged to assign only "provider aggregatable" address space. "Provider independant" address space assigned by Regional Registries will offer no guarantee of routability. (will be determined by ISP's - some of whom claim to be filtering on longer prefixes.) Trade off between renumbering to ISP block when you move provider or paying for ISP to route your prefix. Uncertain how this will develop. Daniel Karrenberg asked for European input to document, which is vitally important. - rfc1597 stands and is on standards track. Comments in rfc1627 will be incorporated. 7. AOB Nothing was reported under AOB so the session was formally closed.

4 3

AS690 advisories
by Daniel Karrenberg 29 May '95

29 May '95

We have met with both the RA team and ANS last Tuesday. The message below is the result of these discussions. The upshot is: If you want your routes imported by ANS (AS690) you need to now: make sure you have route objects with correct advisory attruibutes in the RADB. Put those advisories in the RIPE RR. after Friday: European route objects can be removed from the RADB. AS690 advisories in the RIPE RR are sufficient to talk to ANS. July: advisory attributes will no longer be needed. This is a little easier as we expected at the RIPE meeting, so I hope everyone is happy. Daniel ------- Forwarded Message Date: Fri, 26 May 1995 16:44:47 -0400 From: Steve Heimlich <heimlich(a)ans.net> To: nanog(a)merit.edu Subject: AS690 use of multiple routing registries Folks, This note outlines changes to the ANS AS690 use of various registries which comprise the Internet Routing Registry (IRR). [RIPE gang, please forward to your mailing lists as appropriate]. Currently, the IRR consists of the following four well-known registries: the RADB, the CA*Net registry, the MCI registry, and the RIPE registry. AS690, to date, has relied exclusively on the RADB for generation of its configurations. As a result, those organizations which would naturally register in the MCI, CA*Net, or RIPE registries have been making redundant registrations in the RADB to ensure connectivity with ANS. This redundant registration has been inconvenient for many, and leads to multiple copies of route objects with inconsistent attributes. As of next week, ANS will begin to use route objects from the CA*Net, MCI, and RIPE routing registries. In order to do this, we will first create an ANS registry (containing customers of ANS) with "source: ANS" as its distinguishing attribute. Beginning with next Wednesday's AS690 config run (changed from Tuesday due to the U.S. Memorial Day holiday), we will prefer routes with AS690 advisories from these registries in the following order: ANS, CA*Net, MCI, and the RADB. Once we verify that this has succeeded, we will include the RIPE registry ahead of the RADB on next Friday's config run (i.e., ANS, CA*Net, MCI, RIPE, RADB). This method for config generation will eliminate the need for multiple registrations of singly-homed routes. Toward the end of June, we expect to have software running which will eliminate the use of AS690 advisories. This software generates an initial policy first by using registered advisories (a one-time operation). Currently, this results in a 16,000 line aut-num object for AS690. As this is somewhat unreasonable, we will be reducing the number of per-network exceptions in favor of one policy per home AS. As we approach the deployment of this capability, we will be working with peer providers on arranging mutually acceptable policies with AS690. Steve ------- End of Forwarded Message

1 0