- routing-wg - mailman.ripe.net

RIPE24 WG meeting
by Willem van der Scheun 12 Apr '96

12 Apr '96

Dear Collegues, At the coming RIPE meeting I would like to have a meeting of the routing WG. Since I have been away for quite a while I have completely lost track of the subjects. So I'll completely rely on input from the WG. Could any of you who has subjects for the WG meeting, report them to me, through the mailing list. In this way I'm sure we'll get an interesting agenda. -- Willem

1 0

Less Routes in 193/8 and 194/8
by Daniel Karrenberg 13 Mar '96

13 Mar '96

Dear colleagues, we have run the robot that finds redundant routes for the first time. We have used only routing data from 193/8 and 194/8 at this point. Addresses in this range have been allocated/assigned by the RIPE NCC. This limited audience was chosen because we expect it to be relatively friendly. In total 713 prefixes appear redundant 133 are covered by less-specific ones and 580 are aggregateable with others. I have included the 'hitlists' below for your infomation. the higher you find your AS on this list the more important it is for you to reduce the number of prefixes. Ideally your AS should not appear in any of the lists. If you have any further questions, please do not hesitate to contact us. Regards Daniel Karrenberg RIPE NCC Manager ## Hitlist by origin: #routes Originating Autonomous Systems 55 = AS3258 48 = AS5389 46 = AS719 39 = AS3215 36 = AS790 31 = AS3301 AS3330 28 = AS1899 27 = AS1290 24 = AS1836 AS1257 19 = AS2819 17 = AS544 15 = AS5381 13 = AS3212 12 = AS3300 11 = AS1717 AS2856 AS786 10 = AS3316 AS5391 9 = AS1273 AS2614 8 = AS5401 AS1759 7 = AS2592 AS5392 6 = AS5490 AS1808 5 = AS2607 AS2118 AS5510 AS3252 AS3268 AS3225 4 = AS5427 AS1790 AS3255 AS3058 AS1234 AS2686 AS2529 AS2766 3 = AS3259 AS2860 AS5390 AS3262 AS517 AS3264 AS2111 AS1849 AS5433 2 = AS2561 AS3345 AS3249 AS3302 AS3267 AS1220 AS5415 AS2611 AS1103 1 = AS3563 AS1890 AS3248 AS1794 AS5467 AS2871 AS3323 AS1740 AS2602 AS5424 AS3240 AS2861 AS3228 AS1241 AS2136 AS5504 AS2610 AS3319 AS2109 AS1136 AS5483 AS5769 AS5387 ## Hitlist by 1st neighbor #routes Immediate 'transit' Autonomous Systems 172 = AS1755 113 = AS286 64 = AS701 61 = AS3300 48 = AS1901 47 = AS790 16 = AS2118 AS1759 13 = AS2871 AS5400 11 = AS1128 AS2855 9 = AS1273 7 = AS1849 AS1274 6 = AS1790 AS1800 5 = AS1239 AS3302 4 = AS1887 AS2685 AS2854 AS2848 AS1673 3 = AS3336 AS4000 AS3058 AS2611 2 = AS2578 AS2380 AS3343 AS226 1 = AS2853 AS1794 AS1801 AS5408 AS2895 AS1792 AS1955 AS1835 AS2683 AS1103 AS5402

1 1

Re: Help Please - Reducing Routes (fwd) just for info
by alex＠relcom.EU.net 11 Mar '96

11 Mar '96

> >From <@ncc.ripe.net:owner-routing-wg@ripe.net> Fri Mar 8 17:00:04 1996 > Message-Id: <9603081340.AA02991(a)ncc.ripe.net> > To: RIPE Routing WG <routing-wg(a)ripe.net>, > European ISP Forum <eof-list(a)ripe.net> > Subject: Help Please - Reducing Routes > Cc: RIPE NCC Staff <staff(a)ripe.net> > Yes, it's understandable. But I'd like to make a notes: 1) It's better to produce some information in Subject:, as (The_number_of_redundant_networks) 2) Subject is not understandable. 3) May be it's better to change message structure: I. Short reference: (For example): Below is the list of redundant networks anounced by you routers. See detail descriprion below (after ---END line). ---(BEGIN) ... ... ... ---(END) == Detail description ==. This is because usially all system administrators know good all this description (after they'll read it first). Some networks would be redundant always due to different reasons (technical and political), that means this messages would be received fast enougph. It's important this case to see news list of networks just in the message beginning; moreover, may be somebody would have some robot to execute this messages. That's why I prefere to have description in the end of the message, and to mark main part of this message by some special lines (---(BEGIN), ---(END) , for example). --- Aleksei Roudnev, Network Operational Centre, Relcom, Moscow (+7 095) 194-19-95 (Network Operational Centre Hot Line) (+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)

2 1

Help Please - Reducing Routes
by Daniel Karrenberg 11 Mar '96

11 Mar '96

Dear colleagues, I would like you all to help me a little with the text of an e-mail message I am about to program into a new robot. This robot detects redundant BGP routes and brings them to the attention of the contact persons of the ASes concerned. This is the direct result of the discussion we had at the last RIPE meeting about the need for reducing the number of routes and the consensus that we should mount a community effort to do something about it. I would like you to read the example message below and give me sugestions for improvements. It would also be useful to receive a short note saying "I could understand it, no suggestions", so that I can see how many actually tried to grok it. Note that this is not picking in any way on AS1273. I picked them because this message was the first one I saw that has all the optional elements in it. I also know that the ECRC crew is good humoured in general ;-). I hope to have the robot running sometime next week; but it is no good if people do not understand what they need to do. So please help! Daniel From: Less Routes <less-routes(a)ripe.net> To: "Dave F. Morton" <dave(a)ECRC.DE>, "Todd Ferguson" <todd(a)ECRC.DE>, "Kurt Kayser" <kurt(a)ecrc.de>, "Kurt Kayser" <kurt(a)ecrc.de>, "Waltraud Erber" <wer(a)ecrc.de>, Subject: Routes AS1273 can help eleminate Dear AS1273 contact persons, as you may know the Internet routing system is quite strained at the moment. The major cause of this is the number of routes in the system. This has already caused some service providers to restrict the number of routes they propagate. The RIPE NCC has analysed BGP routing tables and found that a significant number of routes (as many as 22% of the total) are apparently redundant. Your autonomous system is either originating some of those redundant routes or one of your immediate neighbors is doing so. We have found redundant routes by looking separately at each set of routes which we observe coming to us though a unique set of BGP paths. We believe that no routing information will be lost by eliminating redundant routes in in each set independently. We have included all information about the redundant routes your AS is directly involved with and included it in the message below. For each unique set of BGP paths observed in the routing table you will see a number of lines like - Paths: <as-path> [/ <as-path> ...] This is the set of AS paths observed in BGP routing. - Drop: <prefix> covered by <less-specific-prefix> These prefixes can be dropped from global routing because they are covered by a less specific (shorter) prefix observed via the same set of paths. - Aggregate: <prefix> from <more-specific-prefix> & <more-specific-prefix> The more specific prefixes can be aggregated (combined) into a less specific one. This works recursively, i.e. aggregates of aggregates may appear. This serves to show you how the aggregation was derived by us. - Announce: <prefix> The announce lines show you all non-redundant routes for this set of paths including those that could not be improved. This is what should be announced ideally. - Prefixes: <n> <n> is the number of prefixes observed via the set of paths. - Dropable: <n> <n> is the number of prefixes that can be dropped because they are covered by less specific prefixes (see above). - Agg-able: <n> <n> is the number of prefixes that can be dropped because they can be aggregated into less specific prefixes (see above). - Gainable: <n> <n> is the total number of prefixes that can be dropped without loosing information or routing functionality. We have compiled the information in two different sets: routes originated by your AS and routes originated by your AS's immediate neighbor ASes. We only consider neighbor ASes that appear to be 'downstream' from you from our point of view. If your AS originates routes, please consider reducing the announcements as indicated by dropping and/or aggregating routes. If you have multiple connections to (some of) your neighbors and you cannot aggregate or drop the announcements yourself because your immediate neighbor(s) need separate routes to choose the proper connection, please ask your neighbor(s) to do the aggregation for you. If you have a legitimate reason for announcing prefixes that our model considers redundant, we are *very* interested to hear from you, so that we can improve our model. Of course we are also interested in any feedback from you about the usefulness of this information to you and your willingnewss to use it. If the routes are originated by your neighbors, please contact them and bring this to their attention. We will be collecting this information regularly and make it available at ftp://ftp.ripe.net/ripe/less-routes/ in file names of the form AS<num> where <num> is the AS number. We will also regularly publish reports on the progress of this effort. Please act now. reducing the number of prefixes in the Internet routing system is absolutely required to make routing more stable for everyone. This affects you! Thank you The RIPE NCC Routing Team # BGP routes from amsterdam.ripe.net # at Thu Feb 1 07:54:35 1996 UTC # Possible improvementss for routes you originate: Paths: 1755 1273 Incomplete / 1128 1673 1239 1800 1755 1273 Incomplete Drop: 194.24.193/24 covered by 194.24.192/19 Aggregate: 194.24/23 from 194.24/24 & 194.24.1/24 Aggregate: 194.45.208/21 from 194.45.208/22 & 194.45.212/22 Aggregate: 194.115.102/23 from 194.115.102/24 & 194.115.103/24 Aggregate: 194.139.100/23 from 194.139.100/24 & 194.139.101/24 Aggregate: 194.139.102/23 from 194.139.102/24 & 194.139.103/24 Aggregate: 194.139.100/22 from 194.139.100/23 & 194.139.102/23 Announce: 193.22.160/22 Announce: 193.26.103/24 Announce: 193.29.189/24 Announce: 193.30.202/24 Announce: 193.96.229/24 Announce: 193.97.129/24 Announce: 193.97.140/24 Announce: 193.101.21/24 Announce: 193.102.110/24 Announce: 193.141.37/24 Announce: 193.141.94/24 Announce: 194.24/23 Announce: 194.24.4/24 Announce: 194.24.192/19 Announce: 194.31.6/23 Announce: 194.31.193/24 Announce: 194.45.160/22 Announce: 194.45.173/24 Announce: 194.45.186/24 Announce: 194.45.208/21 Announce: 194.55.32/24 Announce: 194.77.146/23 Announce: 194.99.111/24 Announce: 194.115.101/24 Announce: 194.115.102/23 Announce: 194.127.245/24 Announce: 194.139.100/22 Prefixes: 34 Dropable: 1 Agg-able: 6 Gainable: 7 # Possible improvements for routes originated # by your immediate neighbors. Paths: 1755 1273 2861 IGP / 1128 1673 1239 1800 1755 1273 2861 IGP Aggregate: 194.138.16/23 from 194.138.16/24 & 194.138.17/24 Announce: 194.138.16/23 Prefixes: 2 Dropable: 0 Agg-able: 1 Gainable: 1 Paths: 1755 1273 5401 IGP / 1128 1673 1239 1800 1755 1273 5401 IGP Aggregate: 194.77.60/23 from 194.77.60/24 & 194.77.61/24 Aggregate: 194.77.182/23 from 194.77.182/24 & 194.77.183/24 Aggregate: 194.77.196/23 from 194.77.196/24 & 194.77.197/24 Announce: 193.16.1/24 Announce: 193.96.105/24 Announce: 193.96.240/24 Announce: 193.100.124/23 Announce: 193.101.23/24 Announce: 193.101.68/24 Announce: 193.101.120/23 Announce: 193.101.166/24 Announce: 193.102.58/24 Announce: 193.102.128/22 Announce: 193.103.149/24 Announce: 194.15.215/24 Announce: 194.55.171/24 Announce: 194.77.46/23 Announce: 194.77.48/22 Announce: 194.77.52/23 Announce: 194.77.60/23 Announce: 194.77.65/24 Announce: 194.77.88/24 Announce: 194.77.111/24 Announce: 194.77.156/23 Announce: 194.77.160/24 Announce: 194.77.164/23 Announce: 194.77.166/24 Announce: 194.77.168/24 Announce: 194.77.176/24 Announce: 194.77.180/24 Announce: 194.77.182/23 Announce: 194.77.189/24 Announce: 194.77.196/23 Announce: 194.115.31/24 Announce: 194.127.100/24 Prefixes: 35 Dropable: 0 Agg-able: 3 Gainable: 3 Paths: 1755 1273 5401 IGP / 1128 1804 1800 1755 1273 5401 IGP Aggregate: 194.77.66/23 from 194.77.66/24 & 194.77.67/24 Announce: 193.16.3/24 Announce: 193.98.8/22 Announce: 193.98.92/23 Announce: 193.98.225/24 Announce: 193.100.96/24 Announce: 193.100.167/24 Announce: 193.101.2/24 Announce: 193.101.45/24 Announce: 193.101.62/23 Announce: 193.102.21/24 Announce: 193.102.83/24 Announce: 193.102.94/24 Announce: 193.103.134/24 Announce: 193.103.226/24 Announce: 194.64.169/24 Announce: 194.76.211/24 Announce: 194.77.56/22 Announce: 194.77.66/23 Announce: 194.77.94/24 Announce: 194.77.105/24 Announce: 194.77.110/24 Announce: 194.77.113/24 Announce: 194.77.138/24 Announce: 194.77.215/24 Prefixes: 25 Dropable: 0 Agg-able: 1 Gainable: 1

3 3

RIPE Action 21.9: Fwd: E-J B: Draft doc m.cast router in routing reg.
by Wilfried Woeber, UniVie/ACOnet 25 Jan '96

25 Jan '96

FYI, this is the original proposal as circulated by Erik-Jan Bos. -Wilfried. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Subject: Draft document multicast router in routing registry From: Erik-Jan Bos <erik-jan.bos(a)surfnet.nl> Date: Sun, 07 May 1995 11:49:46 +0200 Mbone-EU, please find below a first version of a document describing a multicast router in a routing registry. I would like to have your comments and we can discuss it at the next Mbone WG meeting. I realize some of you might not have a chance to read it before the meeting. Well... here it is, I'll try to bring copies to the meeting. See you in Rome. --- Start of document A Multicast Router in the Routing Registry Erik-Jan Bos Document ID: ripe-nnn May, 1995 **** DRAFT ** WORK IN PROGRESS ** DRAFT **** ABSTRACT This document describes an addition to ripe-122 (Specifying an "Internet Router" in the Routing Registry) in which it is possible to define a multicast capable Internet routing within a routing registry. 1. Introduction With the growing of the Mbone worldwide, managing the Mbone becomes a complex task. The multicast-bone is starting to suffer from problems that used to be present in the unicast-bone several years ago, such as routing coordination. Today, registries are available for administering policies and routes and routers [1]. Tools are availble [2,3] for checking and analyzing the real world against what is registered. The Mbone could and should benefit from these technologies coming from the unicast world. The features of the specification described in this document will be usable e.g. in the RIPE Data Base, after review by the RIPE Data Base WG. After implementation tools could be developed for mapping and analyzing the Mbone. Furthermore, administrative details (such as contact person) are easily administered by well known procedures and easily retrievable. 2. Multicast routers versus unicast routers An "Internet Router" or a "gateway" in the current version of IP (IPv4) can be defined as follows [4]: "Gateways in the Internet form a cooperative, interconnected structure. Datagrams pass from gateway to gateway until they reach a gateway that can deliver the datagram directly." This definition can be applied to both unicast and multicast routers. Since both a unicast and multicast router are fulfilling the "Internet Router" function for different natures of traffic, there is no need for a special routing registry data base object. Moreover, both functions could be present in the same box. 3. Multicast router specification Since an Internet Router can perform both types of routing, this fact should be registerable in the routing registry. Each router is uniquely defined by by its object name, also known as the fully qualified domain name. Below is an example of a internet router object, specifying a multicast router: inet-rtr: broodjeham.surfnet.nl localas: AS1103 ifaddr: 192.87.106.102 255.255.255.0 ifaddr: 192.87.4.99 255.255.255.0 mpeer: 192.87.108.13 16 1 admin-c: Erik-Jan Bos tech-c: Henk Steenman notify: netmaster(a)surfnet.nl remarks: SURFnet Multicast router changed: Erik-Jan.Bos(a)surfnet.nl 950505 source: RIPE Several pieces of important information are present in this object. First of all there is the FQDN of the router, acting as object name. The Home Autonomous System Number is shown, which for a multicast router is merely for identification purposes only. Furthermore, the ifaddr:-lines show that this router has two interfaces, in two different networks. Finally, the DVMRP peers are shown with IP address, treshold and metric. All other attributes are common to other objects already defined for a routing registry [1]. For exact syntax definition see next chapter. 4. Multicast router Syntax Definition The multicast capable router object is defined here. Each of the possible attributes are shown, on a single line. The second column defined whether the attribute must be present [mandatory] of could be present [optional]. The third column defines whether exactly one line is allowed [single] or that more than one line of the same attribute is allowed [multiple]. In case an attribute has more lines than one, the name of the attribute must be repeated on each line. inet-rtr: [mandatory] [single] localas: [mandatory] [single] ifaddr: [mandatory] [multiple] mpeer: [mandatory] [multiple] admin-c: [mandatory] [multiple] tech-c: [mandatory] [multiple] notify: [optional] [multiple] remarks: [optional] [multiple] changed: [mandatory] [multiple] source: [mandatory] [single] Each attribute has the following syntax: inet-rtr: The fully qualified domain name of the router. localas: The Autonomous System to which the router belongs. ifaddr: An interface IPv4 address of the router. mpeer: A multicast peering of the router. Format: <mpeer address> <mpeer treshold> <mpeer metric> Example: mpeer: 192.87.108.13 16 1 Status: mandatory, multiple instances allowed. admin-c: Full name or uniquely assigned NIC-handle of a contact person for administrative matters. tech-c: Full name or uniquely assigned NIC-handle of a contact person for technical matters. notify: An e-mail address to which notifications of changes to this object should be send. remarks: Remarks or comments, for clarification purposes only. changed: The e-mail address and date of a change. source: Source of the information. 5. Acknowledgements This specification, being an addition to ripe-122, leans on the specification done by the author of ripe-122. Credits go to Tony Bates. Furthermore, the RIPE Mbone WG has done reviewing of this document and they receive credits as well. 6. Security considerations Security is not considered in this document. 7. References [1] Bates, Tony, "Specifying an Internet Router in the Routing Registry", ripe-122, October 1994. On-line at URL: ftp://ftp.ripe.net/ripe/docs/ripe-122.txt [2] PRIDE Tools Release 1. On-line at URL: ftp://ftp.ripe.net/pride/tools/pride-tools-1.tar.Z [3] Merit Inc. RRDB Tools. On-line at URL: ftp://rrdb.merit.edu/pub/meritrr [4] Douglas Comer, "Internetworking with TCP/IP", Prentice-Hall, 1988. ISBN: 0-13-470188-7. --- End of document __ Erik-Jan. --------------------------------------------------------------------------------

1 0

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