- routing-wg - mailman.ripe.net

Proposed agenda for next meeting
by Willem van der Scheun 20 Sep '96

20 Sep '96

Dear collegues, Please find below the proposed agenda for the next meeting of the RIPE routing WG. I want to draw your attention to agenda point 3, change of chairman. If there are any objections against Joachim Schmitz taking over please let them know beforehand. Also if there are other candidates please make that known. 1. Opening & administrativa 2. Agenda bashing 3. Chairman of the Routing WG The present chairman will step down and proposes to appoint Joachim Schmitz of the DFN NOC as new chairman. 4. Report from the RIPE NCC 5. Presentation by Joachim Schmitz on working experience with ROE (route object editor). 6. Presentation by Tony Barber of Pipex on experience with Progressive BGP route dampening 7. Presentation by Cengiz Alaettinoglu of ISI on Routing Policy Analysis Tools: - RtConfig (router configuration generator) - roe (route object editor) - aoe (autonomous system object editor) - CIDRAdvisor - IRR visualisation - IRRRelayd - prpath/prtraceroute/prcheck 8. If time permits IRRRelayd - prpath/prtraceroute/prcheck 8. If time permits hands on experience with the ISI tools 9. Closing -- Willem

2 1

proposal for inet-rtr obj extensions, for multicast, etc.
by Wilfried Woeber, UniVie/ACOnet 18 Sep '96

18 Sep '96

Dear all, (to complete a long-standing RIPE action and to make progress) please find below a modified version of a document (originally by Erik-Jan Bos) which then was describing a multicast router in a routing registry. This version proposes a more generalized approach and tries to discuss some implications, benefits and compatibility issues. It is up for discussion in the relevant RIPE working groups - in particular Routing, Mbone, (IPv6??) and DataBase. Of course any input and suggestions welcome! I would like to have your comments before and at the RIPE 25 Meeting, as well as on the mailing lists. Apologies for any rough edges, inconsistencies, omissins and typos. I'm sure we're going to change and improve this text (if this is at all perceived as a useful exercise) and before it could eventually become a RIPE Document. Best 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 -------------------------------------------------------------------------- --- Start of document Generalized Description of Peering Relations in a Routing Registry Erik-Jan Bos, Wilfried Woeber Document ID: ripe-nnn September, 1996 [ adapted and extended from a previous proposal titled: ] [ ] [ 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 extension and generalization of concepts as documented in ripe-122 (Specifying an "Internet Router" in the Routing Registry) by which it becomes possible to define peering relations in a very general way. This approach should in particular be understood to support documentation and debugging of "overlay networks" and regular routing protocol peerings at the same time. Originally this work was started to acommodate the description of a multicast capable Internet router within a routing registry. Comments and suggestions received at RIPE DB-WG sessions and private input led to the proposal to generalize the functionality. In addition to the inet-rtr specific attributes we propose the inclusion of a url: attribute, which is already proposed as an extension to all defined objects. 1. Introduction With the growing of the Mbone worldwide, managing the Mbone becomes a complex task. The multicast-bone is already suffering from problems that used to be present in the unicast-bone several years ago, such as routing coordination (and the lack of scoping of announcements). While the Mbone is currently a focus of interest, activity, growth and coordination efforts, we expect the general concept of an overlay network that needs routing coordination to become a general issue (e.g. IPv6 tunnels). 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 in particular, and other "overlay networks" in general, 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 various different peering environments and/or overlay meshes. Furthermore, administrative details (such as contact person) and operational information (e.g. NOC info as described in role objects) are easily administered by well known procedures and become easily retrievable. Further discussion of the basic concepts led to the idea of generalizing this approach to cater for registering all sorts of peerings, with the dynamic exchange of routing information being a secondary issue. A long-term goal should be to provide the level of configuration and debugging support that is already available for maintaining external unicast routing to a broader range of routing domains. 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. A Router specification a multi-protocol router in the Internet Because an Internet Router - can perform different types of routing at the same time, e.g. . IP unicast routing . multicast routing using DVMRP tunnels or PIM . IPv4/IPv6 or "general purpose" tunnels - in many situations there are defined or potential interactions between the routing domains documentation of these facts should be possible in the routing registry. 3.1 A Simple Router Object, IPv4-only, Current Definiton 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 general purpose unicast router: inet-rtr: broodjeham.surfnet.nl localas: AS1103 ifaddr: 192.87.106.102 255.255.255.192 ifaddr: 192.87.4.99 255.255.255.0 peer: 161.53.2.1 AS2108 BGP4 admin-c: Erik-Jan Bos tech-c: Henk Steenman notify: netmaster(a)surfnet.nl changed: Erik-Jan.Bos(a)surfnet.nl 950505 source: RIPE Several pieces of important information are present in this object as described in ripe-122. First of all there is the FQDN of the router, acting as object name. The Home Autonomous System Number is shown, which (currently) is only meaningful in the context of external IP routing. Furthermore, the ifaddr:-lines show that this router has two interfaces, connected to two different networks, and the masks used on these networks. Finally the peer attribute records the IP (Version 4) address for an external BGP peering and lists peering specific information, eg. the localas: of the peer router (AS2108) and the type and version of the EGP used (BGP4). 3.2 A Router for IPv4 and DVMRP, extending the current structure For a moment, let us assume that this box is at the same time used as a multicast router and has a DVMRP tunnel configured. One of the approaches would be to define a dedicated attribute to describe this configuration, say mpeer: for multicast peering. The router object would then look like the following example: inet-rtr: broodjeham.surfnet.nl localas: AS1103 ifaddr: 192.87.106.102 255.255.255.192 ifaddr: 192.87.4.99 255.255.255.0 peer: 161.53.2.1 AS2108 BGP4 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 While all the previously defined and well-known attributes would remain unchanged, the newly invented mpeer: line would be used to describe a DVMRP peering and showing it's peer's IP address, the treshold and metric. Again, the format and interpretation of the entries beyond the IP (Version 4) address would be specific for that attribute. The advantage of that approach is that there is no need to change the definition of exiting attributes, which in turn preserves the functionality of any tools written to understand the specific information. However, there is a couple of major disadvantages when proceeding in that direction - the most important ones being that - the object's definition and schema has to be changed whenever a new attribute for a differnet kind of peering is proposed - frequent changes of the objects schema would lead to incompatible versions of the software - eventually having a sizeable number of different attributes for the various peerings leeds to congestion of the namespace for attribute tags and (probably) to confusion and errors on the human part of the system - and (maybe the most important thing) there is currently no way to describe peerings that do not use IPv4 addresses to identify the peer, e.g. IPv6 and some other protocols 3.3 The Generalization of the Peer Description Concept Because of these reasons given in 3.2 we propose to change the concept of the peering description to become more general and extensible by moving the peering protocol identifier into the first part on the line and deriving the format and meaning from that. Thus the example object used here would look like the following: inet-rtr: broodjeham.surfnet.nl localas: AS1103 ifaddr: 192.87.106.102 255.255.255.192 ifaddr: 192.87.4.99 255.255.255.0 g-peer: BGP4 161.53.2.1 AS2108 g-peer DVMRP 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 Changing the object's schema in that way raises the issue of backwards compatibility versus "cleanliness" (tools) and compatibility of possibly different versions of the software deploied at different registries. 3.4 Backwards Compatibility Discussion For the backwards compatibility we propose to define a new attribute g-peer, "generalized peering description", and eventually make the peer: attribute obsolete - as soon as the tools have been converted to understand the new format. The disadvantage is the coexistence and/or duplicate registration of BGP4 specific information in peer: and/or g-peer: lines. An alternate approach would be to stick with the peer: attribute for the BGP4 specific information and to specify all other types of peering in g-peer: attributes. While this may be an advantage in the short term, it might add complexity for the tools in the long run by requiring them to understand different attribute formats. For the different software version issue we propose to have the implementation treat any unknown peering type (and the rest of the line) as a remark. This situation should generate a warning at the time of registration or update, and there should probably a switch to instruct the software to suppress the warning or do more stringent tests. We specifically ask the maintainers of tools which are currently relying on the peer: attribute, and the RIPE- and Internet-Community in general, for guidance about these issues! All other attributes would remain as already defined for a routing registry [1]. See next chapter for the syntax definition and concepts for extension. 4. Multiprotocol Router Syntax Definition An object for a router capable of maintaining different routing protocol (or tunnel) peerings in parallel is defined here. Each of the possible attributes are shown, on a single line. The second column defines 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] peer: [obsolete] [multiple] g-peer: [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. [Note: For the time being this is specific for the IPv4 external routing domain. It might even be useful to move that information to a g-peer: BGP4 entry?!] ifaddr: An interface IPv4 address of the router. [Note: the current draft of this proposal does not deal with necessary or desirable changes for IPv6.] peer: obsolete, potentially useful until RR tools are changed! g-peer: A peering of the router with another router, indicating the protocol and any protocol-specific information. [Note: please refer to the next section for the protocols being proposed in this draft and the proposed mechanisms for extension] Format: <protocol-ID> <peer address> <additional information> Examples: g-peer: DVMRP 192.87.108.13 16 1 g-peer: BGP4 161.53.2.1 AS2108 g-peer: IPv6-TUN IPv6-Address IPv6-specific 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. 4.1 Discussion of Application Use of this approach has already been discussed for BGP4: g-peer: BGP4 <remote-peer address> <peer AS> example: BGP4 192.87.4.6 AS2122 localAS AS2121 or even g-peer: BGP4 <remote-peer address> <peer AS> [localAS <ASnumber>] DVMRP g-peer: DVMRP <remote-peer address> <metric> <thresh> example: DVMRP 192.87.4.6 192.87.108.13 16 1 IP-over-IP g-peer: IPv4-TUN <remote-peer address> example: IPv4-TUN 192.87.4.6 or g-peer: IPv6-TUN <remote-peer address> example: IPv6-TUN IPv6-Address 4.2 Extensions * t.b.s. * [ The gist of it should be that future extensions could be incorporated by simply editing a software configuratin file to define additional protocol types and supplying the syntax checking rules. To be discussed in more detail. ] 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 already done some reviewing of a previous version of this document and they receive credits as well. We are grateful for detailed suggestions received from David Kessens (ISI, then with the RIPE-NCC) and Steve Richardson (Merit). 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 --------------------------------------------------------------------------------

2 1

HELP! Seeking AS1800 maintainer
by FREEnet Hostmaster 26 Jul '96

26 Jul '96

Dear All! Could anybody help me to find email address of the person(s) who is responsible for routing policy of AS1800? I'm unable to find it out in databases I'm aware of, but I desperately need to discuss some routing problems with somebody who knows at least how icm-dc-1.icp.net is configured. I suspect this router is doing bogus aggregation for me. I'd be very obliged if you could help me! Thanks. Regards, --- Dimitri I. Sidelnikov FREEnet Hostmaster

3 2

Progressive BGP route dampening
by Tony Barber 16 Jul '96

16 Jul '96

This is a short note to the ripe community and our peers to let you know that we are now implementing a form a progressive route dampening based on BGP prefix length. Flapping routes with longer prefixes will be penalised/suppressed for longer than shorter ones. Hopefully more implementations of this ilk will prompt more Networks to CIDRise. Maximum ripe block allocations will receive the default cisco suppression. Any questions, just drop us a line. Regards --Tony

4 5

minutes of routing wg session RIPE24 (22-04-96)
by Schmitz＠rus.uni-stuttgart.de 15 May '96

15 May '96

Routing WG M I N U T E S Monday, 22-04-96 Start: 14:15 End: 15:45 Chairman: Willem van der Scheun Scribe: Joachim Schmitz, DFN-NOC Participants: 77 The agenda for this session was distributed on the mailing list on 19. April (* added during agenda bashing): 1. Opening This includes finding a minutetaker, so please prepare to volunteer! 2. Minutes of last meeting (RIPE22, October 1995) Action points from last meeting 3. Agenda bashing 4. Routing Registry Progress RIPE NCC, appr. 15 minutes 5. Routing table growth Daniel Karrenberg, appr. 45 minutes *5a.Exponential route flap dampening Peter Lothberg 6. Routing WG future activities, input to RIPE NCC appr. 15 minutes 7. AoB 1. Opening The prelimenaries were done within short time (passing participant list around, looking for a scribe) 2. Minutes of last meeting, Action points The minutes of the last meeting were accepted without changes. Then, the actions from earlier meetings were discussed. - Action 22-8 on RIPE NCC/Merit: To make the RADB publicly available on the the RIPE FTP server (if Merit concords) status: DONE - Action 22-9 on RIPE NCC/ANS: To find a final date when to give up advisory tags. status: DONE. Actually, the tags have been ignored by ANS since Nov 1995. - Action 22-10 on 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 status: OPEN (not yet started) Transfered to chairman Willem van der Scheun - Action 22-11 on 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 status: OPEN (depends on previous action) 3. Agenda Bashing Then the audience was asked for any changes on the agenda. Willi Huber asked how to deal with organisations which want to become multihomed. This topic was discussed under the AoB item of the agenda at the end of the meeting. A short presentation by Peter Lothberg was added on a suggestion for exponential route flap dampening after "5. Routing table growth". 4. Routing Registry Progress Daniel Karrenberg of the RIPE NCC reported on the progress of the routing registry. It is found to be in good shape, especially since - for the registration of new ASs, submission of a routing policy has become compulsory. This data is actually used (by ANS, BT, and possibly others) to generate filters ANS added on 14.May 1996 (Curtis Villamizar) that prior attemtps to automate generation of policies for new ASs failed. The reason is missing data in the registries (aut-nums, routing policies, insufficient as-macros). At this point ANS still relies on notification from adjacent providers. - the effort to reduce redundancies and remove old data is continuing. This is most notable on the route objects. Their overall number in the RIPE database declines. ANS added on 14.May 1996 (Curtis Villamizar) that they have code to clean up prefix based policy exceptions. However, the RIPE NCC is caught again by the growth of the Internet and its resources did not permit to handle all new items or reports on errors in the database software. Steven Bakker then asked about the current state of the extended as-in, as-out attributes. As it turned out these attributes have not proceeded beyond the draft state and are not yet implemented in the database software. Moreover, the current PRIDE-tools won`t work if the extensions are used in the database. Obviously, quite some effort must be put into it. However, to express certain routing policy elements the extension are indispensable. No workaround exists in the current implementation. The topic was transferred to the database working group. A presentation will be given there, showing the development of the database software in the last months as it was focused on authorization. The presentation will include future plans regarding further elements for the database. 5. Routing table growth The main presentation in this meeting of the routing working group was given by Daniel Karrenberg on the growth of the routing tables. It will be made available on the RIPE FTP-server as soon as DK has returned from vacation (planned as ftp://ftp.ripe.net/ripe/presentations/ripe-m24-dfk-Less-routes) Part of the data may also be found in the quarterly report Q1, 1996 (URL ftp://ftp.ripe.net/ripe/docs/ripe-135.txt or ripe-135.ps). As DK pointed out it has become a well known problem that ISPs which do full routing have run into severe problems regarding the size of routing tables and routing stability. This lead to ideas of quite repressive prefix filtering (e.g. by Sprint not accepting smaller prefixes than /19). However, Europe is in a good shape at least with respect to 193/8 and 194/8 because allocation of address space was done in aggregatable chunks from the start and there are many good netizens. To illustrate this DK showed some statistics he did for the combined 193/8 and 194/8 address space from the routing table of the RIPE border router. He finds that - the total address space increases (doing no DNS analysis but simply counting each /24 as if it contained 256 hosts, /23 as 512 hosts etc). This conforms with allocation - the total number of routes decreases. This is due to aggregation. - the number of redundant routes also decreases. Currently, there are only approximately 12% redundant routes (but roughly 25% a few months ago). RIPE NCC started posting information on redundant routes per AS a few months ago and the response from ISPs is good. Actually, aggregation requests from the NCC were often accepted. Data on redundant routes is available on the RIPE FTP-server (ftp://ftp.ripe.net/ripe/less-routes/*) Yet, the definition of when to treat a route as being redundant is not easy. Up to now a route has been defined as redundant if it was possible to build a less specific aggregate which contains this more specific route, based upon origin and AS-path information. However, there is a general feeling that many more redundant routes exist if origins or other information could be analysed more thoroughly. For the time being DK wants to - automate the analysis possibly allowing near real time analysis and use a dedicated machine from which to collect the data - educate and explain to more ISPs why this effort is valuable and needed, maybe even trying to give hints on router configuration - convince people possibly by peer pressure to really adopt the changes necessary on their side Future development should include refinement of the definition of equivalent or redundant routes, respectively, and probably extension of the analysis to the net outside Europe. These topics were vividly discussed by the audience. Willfried Woeber asked how "outside Europe" could be defined - whether geographically or by address space. DK answered that it was not yet specified, but by definition European routes are in 193/8, 194/8. WW also wants to have the effort extended to the 192/8 block, at least for the allocations done in Europe and asked whether this was a political of technical problem. DK did not see real problems but estimated that problems could arise because on the RIPE NCC border router not all US routes are seen which might make analysis beyond Europe more difficult. Blasco Bonito wanted to push the education element and asked whether a FAQ on this topic existed. Actually, Hank Nussbacher has already started the CIDR FAQ. Probably, some additions should be made. An action was put on the chair- man to investigate the status of the CIDR FAQ and see whether additions are needed, probably by triggering a discussion on the mailing list. Mike Norris pointed out that configuration examples for routers will be difficult to set up because it depends on the local situation of each ISP and router hardware or software used. Joachim Schmitz added that the current analysis should be extended by comparing the data of routing tables to the route objects actually registered at the database, maybe even testing conformity with the routing policy as it is found in the database. DK agrees and thinks that it is a very important step to be done in the future. Yet, according to DK's opinion the work done so far on discovering redundant routes could be used for this. Finally, DK asked how the routing working group could be involved. He asked for suggestions, especially on filtering of prefix lengths where he thinks that reducing redundancy is more worthwhile (even a /32 prefix could be meaningful if it points e.g. to a root nameserver). Ruediger Volk suggested to identify which ASs are of European origin to reduce the effort. Other valuable points are peer pressure and endorsement. 5a.Exponential route flap dampening After this talk Peter Lothberg presented a suggestion on exponential route flap dampening, another effort to reduce the pressure excerted by Internet growth. Given several interconnected ISPs with a flapping connection on one end, this may lead to complete loss of connectivity with respect to the other end across the intermediate ISPs. The reason is that propagation of routing information takes time. If the flapping frequency is higher than propagation across the net at least one ISP in between will not have a valid route for the corresponding connection at any given time. Besides computing new routing tables over and over again, dropping of packets is also costly for routers (if they do not have a default route). To circumvent this problem PL suggests that updates on the routing tables should be done ever more reluctant the greater the prefix of the route is. The premise is that small prefixes are most likely to be aggregates and should be updated as soon as possible while greater prefixes should either be aggregated (e.g. by forcing people to renumber when changing ISPs) or the connections made more stable (which is difficult with smaller organisations and ISPs as experience shows). As a first draftproposal, prefixes of /16 should be updated without delay, /17 with a tiny delay, /18 with small delay, etc, /24 maybe changed only once a day. Surprisingly, no protest was uttered from the audience. However, there is no implementation of this scheme yet while PL thought that it could be implemented pretty fast. In the following discussion MN felt that dampening delays must be globally the same and should be hardcoded to be efficient - but it would then be difficult to change them if need arises. A further clarifi- cation among DK and PL stated that dampening is applied to outbound updates only. ANS added on 14.May 1996 (Curtis Villamizar) that the implementation of route flap dampening is complicated business. It should only be applied to EBGP (probably inbound only) and delays must be handled carefully. If this is not done correctly, inconsistent data may arise, routing loops occur, or black holes are generated. Moreover, route withdrawl should be propagated faster than announcements. 6. Routing WG future activities, input to RIPE NCC This item from the agenda was skipped. Discussion will be done through the mailing list first. 7. AoB The final topic of the meeting was the discussion of multihomed organisations. WH asked whether anybody had collected pros and cons to give when requests occur. This did not seem to be the case but the general feeling was that multihoming should not be encouraged because - it leads to more routes in the Internet - if more specific routes are announced by one ISP involved, less specific ones by an other, then the ISP with the more specific announcement will attract the traffic which is not necessarily desired - moreover, it may become necessary that certain ISPs downstream should prefer routes at given exchange points to reach the multihomed organisation through certain ISPs rejecting routes through other ISPs. This is near to impossible. PL thinks that this problem is solved automatically as the Internet evolves by the bare needs of running the Internet. Since there was no other business the meeting was closed at 15:45. ACTIONS: - Action 22-8 on RIPE NCC/Merit: To make the RADB publicly available on the the RIPE FTP server (if Merit concords) status: DONE - Action 22-9 on RIPE NCC/ANS: To find a final date when to give up advisory tags. status: DONE. Actually, the tags have been ignored by ANS since Nov 1995. - Action 22-10 on Willem van der Scheun: 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 status: OPEN - Action 22-11 on 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 status: OPEN (depends on previous action) - New Action on Daniel Karrenberg: To put his presentation on routing table growth on the RIPE FTP-server as ftp://ftp.ripe.net/ripe/presentations/ripe-m24-dfk-Less-routes status: OPEN - New Action on Willem van der Scheun: To investigate the status of the CIDR FAQ and see whether additions are needed, probably by triggering a discussion on the mailing list. This is to educate netizens for better understanding of problems resulting from routing table growth status: OPEN ---- _____________________________________________________________________________ DFN Network Operation Center, Dr. Joachim Schmitz, (finger help(a)noc.dfn.de) >>>>>> mailto: noc(a)noc.dfn.de <<<<<< Rechenzentrum Universitaet Stuttgart, Allmandring 30, D-70550 Stuttgart Phone: 0711-685-5810, 0711-685-5576, FAX +711 6788363 (business hours) EMERGENCY phone +711 1319 139 with answering machine and pager _____________________________________________________________________________

1 0

draft minutes of routing wg session RIPE24 (22-04-96)
by Schmitz＠rus.uni-stuttgart.de 14 May '96

14 May '96

Routing WG M I N U T E S - D R A F T - Monday, 22-04-96 Start: 14:15 End: 15:45 Chairman: Willem van der Scheun Scribe: Joachim Schmitz, DFN-NOC Participants: 77 The agenda for this session was distributed on the mailing list on 19. April (* added during agenda bashing): 1. Opening This includes finding a minutetaker, so please prepare to volunteer! 2. Minutes of last meeting (RIPE22, October 1995) Action points from last meeting 3. Agenda bashing 4. Routing Registry Progress RIPE NCC, appr. 15 minutes 5. Routing table growth Daniel Karrenberg, appr. 45 minutes *5a.Exponential route flap dampening Peter Lothberg 6. Routing WG future activities, input to RIPE NCC appr. 15 minutes 7. AoB 1. Opening The prelimenaries were done within short time (passing participant list around, looking for a scribe) 2. Minutes of last meeting, Action points The minutes of the last meeting were accepted without changes. Then, the actions from earlier meetings were discussed. - Action 22-8 on RIPE NCC/Merit: To make the RADB publicly available on the the RIPE FTP server (if Merit concords) status: DONE - Action 22-9 on RIPE NCC/ANS: To find a final date when to give up advisory tags. status: DONE (more or less) - Action 22-10 on 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 status: OPEN (not yet started) Transfered to chairman Willem van der Scheun - Action 22-11 on 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 status: OPEN (depends on previous action) 3. Agenda Bashing Then the audience was asked for any changes on the agenda. Willi Huber asked how to deal with organisations which want to become multihomed. This topic was discussed under the AoB item of the agenda at the end of the meeting. A short presentation by Peter Lothberg was added on a suggestion for exponential route flap dampening after "5. Routing table growth". 4. Routing Registry Progress Daniel Karrenberg of the RIPE NCC reported on the progress of the routing registry. It is found to be in good shape, especially since - for the registration of new ASs, submission of a routing policy has become compulsory. This data is actually used (by ANS, BT, and possibly others) to generate filters - the effort to reduce redundancies and remove old data is continuing. This is most notable on the route objects. Their overall number in the RIPE database declines. However, the RIPE NCC is caught again by the growth of the Internet and its resources did not permit to handle all new items or reports on errors in the database software. Steven Bakker then asked about the current state of the extended as-in, as-out attributes. As it turned out these attributes have not proceeded beyond the draft state and are not yet implemented in the database software. Moreover, the current PRIDE-tools won`t work if the extensions are used in the database. Obviously, quite some effort must be put into it. However, to express certain routing policy elements the extension are indispensable. No workaround exists in the current implementation. The topic was transferred to the database working group. A presentation will be given there, showing the development of the database software in the last months as it was focused on authorization. The presentation will include future plans regarding further elements for the database. 5. Routing table growth The main presentation in this meeting of the routing working group was given by Daniel Karrenberg on the growth of the routing tables. It will be made available on the RIPE FTP-server as soon as DK has returned from vacation (planned as ftp://ftp.ripe.net/ripe/presentations/ripe-m24-dfk-Less-routes) Part of the data may also be found in the quarterly report Q1, 1996 (URL ftp://ftp.ripe.net/ripe/docs/ripe-135.txt or ripe-135.ps). As DK pointed out it has become a well known problem that ISPs which do full routing have run into severe problems regarding the size of routing tables and routing stability. This lead to ideas of quite repressive prefix filtering (e.g. by Sprint not accepting smaller prefixes than /19). However, Europe is in a good shape at least with respect to 193/8 and 194/8 because allocation of address space was done in aggregatable chunks from the start and there are many good netizens. To illustrate this DK showed some statistics he did for the combined 193/8 and 194/8 address space from the routing table of the RIPE border router. He finds that - the total address space increases (doing no DNS analysis but simply counting each /24 as if it contained 256 hosts, /23 as 512 hosts etc). This conforms with allocation - the total number of routes decreases. This is due to aggregation. - the number of redundant routes also decreases. Currently, there are only approximately 12% redundant routes (but roughly 25% a few months ago). RIPE NCC started posting information on redundant routes per AS a few months ago and the response from ISPs is good. Actually, aggregation requests from the NCC were often accepted. Data on redundant routes is available on the RIPE FTP-server (ftp://ftp.ripe.net/ripe/less-routes/*) Yet, the definition of when to treat a route as being redundant is not easy. Up to now a route has been defined as redundant if it was possible to build a less specific aggregate which contains this more specific route, based upon origin and AS-path information. However, there is a general feeling that many more redundant routes exist if origins or other information could be analysed more thoroughly. For the time being DK wants to - automate the analysis possibly allowing near real time analysis and use a dedicated machine from which to collect the data - educate and explain to more ISPs why this effort is valuable and needed, maybe even trying to give hints on router configuration - convince people possibly by peer pressure to really adopt the changes necessary on their side Future development should include refinement of the definition of equivalent or redundant routes, respectively, and probably extension of the analysis to the net outside Europe. These topics were vividly discussed by the audience. Willfried Woeber asked how "outside Europe" could be defined - whether geographically or by address space. DK answered that it was not yet specified, but by definition European routes are in 193/8, 194/8. WW also wants to have the effort extended to the 192/8 block, at least for the allocations done in Europe and asked whether this was a political of technical problem. DK did not see real problems but estimated that problems could arise because on the RIPE NCC border router not all US routes are seen which might make analysis beyond Europe more difficult. Blasco Bonito wanted to push the education element and asked whether a FAQ on this topic existed. Actually, Hank Nussbacher has already started the CIDR FAQ. Probably, some additions should be made. An action was put on the chair- man to investigate the status of the CIDR FAQ and see whether additions are needed, probably by triggering a discussion on the mailing list. Mike Norris pointed out that configuration examples for routers will be difficult to set up because it depends on the local situation of each ISP and router hardware or software used. Joachim Schmitz added that the current analysis should be extended by comparing the data of routing tables to the route objects actually registered at the database, maybe even testing conformity with the routing policy as it is found in the database. DK agrees and thinks that it is a very important step to be done in the future. Yet, according to DK's opinion the work done so far on discovering redundant routes could be used for this. Finally, DK asked how the routing working group could be involved. He asked for suggestions, especially on filtering of prefix lengths where he thinks that reducing redundancy is more worthwhile (even a /32 prefix could be meaningful if it points e.g. to a root nameserver). Ruediger Volk suggested to identify which ASs are of European origin to reduce the effort. Other valuable points are peer pressure and endorsement. 5a.Exponential route flap dampening After this talk Peter Lothberg presented a suggestion on exponential route flap dampening, another effort to reduce the pressure excerted by Internet growth. Given several interconnected ISPs with a flapping connection on one end, this may lead to complete loss of connectivity with respect to the other end across the intermediate ISPs. The reason is that propagation of routing information takes time. If the flapping frequency is higher than propagation across the net at least one ISP in between will not have a valid route for the corresponding connection at any given time. Besides computing new routing tables over and over again, dropping of packets is also costly for routers (if they do not have a default route). To circumvent this problem PL suggests that updates on the routing tables should be done ever more reluctant the greater the prefix of the route is. The premise is that small prefixes are most likely to be aggregates and should be updated as soon as possible while greater prefixes should either be aggregated (e.g. by forcing people to renumber when changing ISPs) or the connections made more stable (which is difficult with smaller organisations and ISPs as experience shows). As a first draftproposal, prefixes of /16 should be updated without delay, /17 with a tiny delay, /18 with small delay, etc, /24 maybe changed only once a day. Surprisingly, no protest was uttered from the audience. However, there is no implementation of this scheme yet while PL thought that it could be implemented pretty fast. In the following discussion MN felt that dampening delays must be globally the same and should be hardcoded to be efficient - but it would then be difficult to change them if need arises. A further clarifi- cation among DK and PL stated that dampening is applied to outbound updates only. 6. Routing WG future activities, input to RIPE NCC This item from the agenda was skipped. Discussion will be done through the mailing list first. 7. AoB The final topic of the meeting was the discussion of multihomed organisations. WH asked whether anybody had collected pros and cons to give when requests occur. This did not seem to be the case but the general feeling was that multihoming should not be encouraged because - it leads to more routes in the Internet - if more specific routes are announced by one ISP involved, less specific ones by an other, then the ISP with the more specific announcement will attract the traffic which is not necessarily desired - moreover, it may become necessary that certain ISPs downstream should prefer routes at given exchange points to reach the multihomed organisation through certain ISPs rejecting routes through other ISPs. This is near to impossible. PL thinks that this problem is solved automatically as the Internet evolves by the bare needs of running the Internet. Since there was no other business the meeting was closed at 15:45. ACTIONS: - Action 22-8 on RIPE NCC/Merit: To make the RADB publicly available on the the RIPE FTP server (if Merit concords) status: DONE - Action 22-9 on RIPE NCC/ANS: To find a final date when to give up advisory tags. status: DONE (more or less) - Action 22-10 on Willem van der Scheun: 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 status: OPEN - Action 22-11 on 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 status: OPEN (depends on previous action) - New Action on Daniel Karrenberg: To put his presentation on routing table growth on the RIPE FTP-server as ftp://ftp.ripe.net/ripe/presentations/ripe-m24-dfk-Less-routes status: OPEN - New Action on Willem van der Scheun: To investigate the status of the CIDR FAQ and see whether additions are needed, probably by triggering a discussion on the mailing list. This is to educate netizens for better understanding of problems resulting from routing table growth status: OPEN ---- _____________________________________________________________________________ DFN Network Operation Center, Dr. Joachim Schmitz, (finger help(a)noc.dfn.de) >>>>>> mailto: noc(a)noc.dfn.de <<<<<< Rechenzentrum Universitaet Stuttgart, Allmandring 30, D-70550 Stuttgart Phone: 0711-685-5810, 0711-685-5576, FAX +711 6788363 (business hours) EMERGENCY phone +711 1319 139 with answering machine and pager _____________________________________________________________________________

2 2

Proposed agenda routing-wg meeting April 22
by Willem van der Scheun 19 Apr '96

19 Apr '96

Dear collegues, Please find below the proposed agenda for the meeting of the routing WG at the coming RIPE meeting, April 22 at 14:00 hours. Thanks to Daniel for his input. 1. Opening This includes finding a minutetaker, so please prepare to volunteer! 2. Minutes of last meeting (RIPE22, October 1995) Action points from last meeting 3. Agenda bashing 4. Routing Registry Progress RIPE NCC, appr. 15 minutes 5. Routing table growth Daniel Karrenberg, appr. 45 minutes 6. Routing WG future activities, input to RIPE NCC appr. 15 minutes 7. AoB See you in Berlin. -- Willem

1 0

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