- routing-wg - mailman.ripe.net

RIPE Action 21.9: proposal for an ext. of inet-rtr (Mbone R.)
by Wilfried Woeber, UniVie/ACOnet 25 Jan '96

25 Jan '96

There is a fairly old action on Eric-Jan and me to circulate a proposal on extending the definition for the RIPE Database router object inet-rtr: The original definition is documented in ripe-122. The background for the proposed extension is the discussion about documenting the routing of "overlay" networks, most prominently the Mbone. Quite a while ago Erik-Jan Bos circulated a proposal to extend inet-rtr: with an mpeer: attribute. This proposed mpeer: attribute is/was intended to specifically document Mbone DVMRP tunnels. [ I'm going to re-distribute this paper in a separate message for those of you who don't have a copy readily available ] Further discussion revealed that by rearranging and extending the definition of the *existing* peer: attribute there is a possibility to make the concept even more general and potentially covering IP over IP, STUN, whatever. At the same time we could avoid inventing just another attribute. The current use of the attribute is: peer: <Peer address> <Peer AS> <Routing Protocol> [localAS ASnumber] The generalisation would involve changing that definition to peer: <Peer address> <Peer protocol> <peer-proto-specific info> So for the good old BGP peering this might then look like: peer: 192.87.4.6 BGP4 AS2122 localAS AS2121 for an Mbone tunnel this might be peer: 192.87.4.6 DVMRP metric thresh and for an IP-over-IP even peer: 192.87.4.6 IP Unfortunately this approach would require a non-compatible change to the existing peer: attribute. How many tools would be affected? What's the expected effort to fix these tools? Your opinions and input wrt to the concept and the proposal to change the peer: definiton for BGP peerings is appreciated - before we spend too much effort on the details.... Regards 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

Re: Question on % of good routes and plea for an RA mail list was Re: Routing registry was Re: Sprint BGP filters in 207.x.x.x?
by Steven J. Richardson 05 Jan '96

05 Jan '96

>From list-admin(a)merit.edu Thu Jan 4 05:03:27 1996 >Message-Id: <9601040929.AA14593(a)ncc.ripe.net> >To: hwb(a)upeksa.sdsc.edu (Hans-Werner Braun) >Cc: nanog(a)merit.edu, RIPE Routing WG <routing-wg(a)ripe.net> >Subject: Question on % of good routes and plea for an RA mail list was Re: Routing registry was Re: Sprint BGP filters in 207.x.x.x? >In-Reply-To: Your message of Wed, 03 Jan 1996 15:21:50 PST. > <199601032321.PAA24966(a)upeksa.sdsc.edu> >References: <199601032321.PAA24966(a)upeksa.sdsc.edu> >From: Daniel Karrenberg <Daniel.Karrenberg(a)ripe.net> >Date: Thu, 04 Jan 1996 10:29:49 +0100 >Sender: Daniel.Karrenberg(a)ripe.net >The early NSFnet one was done to configure a single backbone. Remember >that EGP was the state-of-the-art. NSFNet provided last resort routing >and everyone was happy. More complex registries were not needed to keep >track of this even when "back doors" appeared. > >In Europe the situation was not like that at all. Despite great efforts >we were never blessed with a single pan-European backbone or even a >last-resort routing service. This is why RIPE developed a routing >registry that was capable of being useful in a general topology of >indepoendent ISPs. FYI: Lest anyone think that the PRDB was single-backbone-specific in _design_ or capability (it pretty much was in terms of data), let me note that, when Andy Adams and I rewrote the PRDB from a SPIRES DB to a RDBMS (with help from Tom Libert and Sue Hares), we explicitly designed in the ability to include data from other backbones. This was initially done to support both the T1 and T3 backbones, but it could easily have supported other backbones as well. >Daniel Steve Richardson/Merit

2 1

Question on % of good routes and plea for an RA mail list was Re: Routing registry was Re: Sprint BGP filters in 207.x.x.x?
by Daniel Karrenberg 04 Jan '96

04 Jan '96

> hwb(a)upeksa.sdsc.edu (Hans-Werner Braun) writes: > It even predates the T1/... NSFNET backbone. We already used something > like that for the 56kbps Fuzzball based NSFNET backbone. In a sense, > the RIPE db etc. are latecomers here. Susan is correct, the NSFNET > implemented and formalized the routing data base in evolutionary > stages. Indeed there is an evoloution of routing policy databases/registries. The early NSFnet one was done to configure a single backbone. Remember that EGP was the state-of-the-art. NSFNet provided last resort routing and everyone was happy. More complex registries were not needed to keep track of this even when "back doors" appeared. In Europe the situation was not like that at all. Despite great efforts we were never blessed with a single pan-European backbone or even a last-resort routing service. This is why RIPE developed a routing registry that was capable of being useful in a general topology of indepoendent ISPs. We weren't more clever or had more foresight, we simply had the need earlier. I think it has been a good decision by the RA team to use this technology and to contribute to its development rather than inventing something new right away. Given the resources I would hope for more output in the way of tools etc. but I see it coming now. > Often despite complaints from many sites that wanted free and > uncontrolled flow of routing information. This is a great misconception about routing registries which comes from the time of the single backbone model. The routing registry and the backbone were then operated by the same people and used to enforce The Routing Policy. The situation is different now. Each ISP sets and enforces their routing policy. The routing registry only supports them in this. Of course a good routing policy is to not propagate routes to address space which is not assigned and to generally filter announcements from customers. But there is no way to use the routing registry to force ISPs to do reasonable things. > I am not arguing about whether the RIPE and the RA DB should or should > not be merged, just that there is a history to the steps taken, and > reconciling into a homogenious DB (format) would have to be a concious > effort by the parties seeing mutual benefit. Not that it should not > happen otherwise, it just won't, given project priorities. I am pessimistic at all. All routing registies use the same schema or very very similar ones. They currently call come from the ripe-181 specifications which are based on input from the RA people. The RADB, RIPE RR, MCI RR and all the others really form a global Internet RR which is quite useful already and can be made more useful. Two things are needed now: 1) Improve active maintenance by the registrars. This will by itself lead to better alignment between registries and remove duplicate registrations. 2) Produce and *deploy* more useful tools. If this is done well, ISPs will use those registries more and register in them because it is useful and interest. Daniel

1 0

195/8
by Daniel Karrenberg 18 Dec '95

18 Dec '95

> Sean Doran <smd(a)chops.icp.net> writes: > > Peter and I would naturally love to see no subnets of > 195/8 at all, and see everyone using any of 195/8 and > talking to networks outside Europe be required to provide > transit to all of 195/8. I fully agree that that is a very desirable goal. However, given the transmission tariff situation and the marketing practises of US ISPs in Europe it is probably not realistic right now. > Failing that, I want to see an absolute maximum of > about 1000 prefixes in 195/8, period. The RIPE NCC allocates address space. We have no control over how ISPs will set their routing policy and design their exterior routing. Would you like to consider for a moment the allocation data for 19[34]/8? prefix #allocs #allocs length 193/8 194/8 PA 12 1 0 PA 13 2 1 PA 14 6 1 PA 15 25 7 PA 16 55 60 PA 17 2 10 PA 18 4 25 PA 19 2 93 PI 16 50 52 ---- ---- Total 147 249 ==== ==== Notes: 1) The table only shows the prefixes currently allocated. 2) The RIPE NCC does allocate in such a way that future allocations can often be aggregated with present allocations. This means that a number of allocations will 'ripple upwards' in the table. It is important to note that we do not make any guarantees about that to our customers but still try to do the right thing. 3) Little can be said at present about the possibility of aggregation in PI space. 4) The allocation information is available in the RIPE database. However due to some procedural problems not all of it is up-to-date at present. We will have this corrected early next year. As you can see the total number of allocations is not that high. The provider aggregateable addresses could be routed in less than 200 routes for each block. Now consider the actual number of routes vs the address space covered for the 'C-Space' /16 block hosts routes hosts addres- / sed route 192.0.0.0 4733440 6471 731 193.0.0.0 8934656 2001 4465 194.0.0.0 6462208 1622 3984 195.0.0.0 1024 4 256 196.0.0.0 708864 356 1991 197.0.0.0 256 1 256 198.0.0.0 7400960 3668 2017 199.0.0.0 7735552 3270 2365 200.0.0.0 4625152 589 7852 201.0.0.0 256 1 256 202.0.0.0 3855680 1362 2830 203.0.0.0 5662720 690 8206 204.0.0.0 10388224 3517 2953 205.0.0.0 5851648 1775 3296 206.0.0.0 10236928 1573 6507 207.0.0.0 32768 3 10922 208.0.0.0 1024 4 256 C Space 76631360 26907 2848 You will note that Europe's performance is far better than that of anyone else if you consider the time of allocation. *Personal Soapbox The RIPE NCC allocation policy has resulted in significant aggregation well before anyone else's! I consider it quite arrogant of Sean Doran (and Peter) to tell us how we should set our policies. *End Personal Soapbox For next year we are planning to continuously compare allocations with observed routes in various ways. The goal of this is advise IRs and ISPs about possible improvements in allocation/assignment and routing. We consider this the appropriate strategy to improve route aggregation. > If you will guarantee that here and on paper, then as > Dennis Ferguson and Geert-Jan de Groot have pointed out in > various ways, there should be no trouble whatsoever with > listening to /19s or even /24s in 195/8. I can easily guarantee you on paper that we will make every effort not to make more than 1000 allocations from 195/8 and that we will supply you (as everyone else) with the data on valid allocation including whether they are PA or PI. Hint: This makes it easy to verify which /19s ot of 195/8 you need to accept. > If you can't do that and mean it and enforce it, then > the only option I see is to impose a bitwise filter which > sets a hard ceiling of the number of prefixes we will hear > in 195/8. It should be clear that the RIPE NCC cannot enforce routing policies of any ISP. In order to be totally clear I add that we also do not desire to ever do this because it is a "Bad Thing" (tm). However unless there is consensus that indiscriminate prefix length filters are a "Good Thing" (tm) and the majority of providers use them, we cannot waste of address space by raising our minimum allocation size. > Daniel> SprintLink will be well advised to take > Daniel> this into account when defining their routing > Daniel> policy. > > We did. Maybe someting went wrong in the definition process then because your policy will likely prevent connectivity to some parts of 195/8. Of course I assume that one of your goals is the largest possible connectivity. Maybe I am wrong, certainly I am curious. > Right now there is nothing allocated under 195/8 right > now, and so anything you allocate under 195/8 which isn't > aggregated into a 18-bit-or-shorter prefix simply will > never work from day one. You should probably consider > making this clear to everyone you allocate your /19s to, > if you plan to keep allocating nonaggregatable /19s. It will not work *with/over Sprintlink*. We already advise everyone that - we publish our allocation policy in the appropriate fora so that ISPs can take note of it - we have no control over the routing policies of service providers. I am sure that you can achieve the desired result by setting your filter in 195/8 to /19. Should the number of routes accepted by this filter grow beyond acceptable limits we will certainly work with you as with everyone else to improve the situation. If you intend to keep the filter at /18, I invite you to get out the word yourself. A good start would be to present it at the upcoming RIPE meeting in January. Curiously your's Daniel

1 0

RE: Routing wars pending?
by Hank Nussbacher 16 Nov '95

16 Nov '95

On Wed, 15 Nov 1995 11:00:04 MET you said: > 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. Is that the general consensus in other countries? > > 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. We have had problems with this also. > > 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. Yes Europe is very organized - but what do you do about the USA? > > 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 > -------------------------------------------------------------------------- Hank

2 1

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