Here are the 1st draft minutes of the Routing WG session at RIPE 26. Thanks to Chris Fletcher for keeping track of the major points during the session! Maybe, some of the URLs need adaptation as the presentation become available on the RIPE FTP-Server. Comments, input, and improvements to the draft minutes are welcome (but please keep discussion of topics separate from the minutes themselves, thank you) Joachim ----- -- 1. D R A F T -- RIPE 26, Amsterdam Routing Working Group Report of Meeting, 20th January 1997 -- 1. D R A F T -- A. Administrative Issues Joachim Schmitz, Chairman, presided and welcomed people to the meeting. There were 95 attenders. Chris Fletcher took minutes. The draft agenda circulated in the previous week was agreed. A copy is displayed at the end of this summary. There were no additions or changes to the minutes of the RIPE 25 Routing WG session. A short overview of open actions was given. Action 22.10 on Joachim Schmitz 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 consensus on it is still open. It will be pursued after the current meeting. Action 24.4 on Joachim Schmitz To investigate the status of the CIDR FAQ and see whether additions are needed, probably by triggering a discussion on the mailing list According to the result of the investigation no official additions by the Routing WG are needed. Therefore, the WG agreed to close this action. However, it was felt that further distribution of knowledge about CIDR is needed and therefore a pointer to the CIDR FAQ location should be included on the Routing WG pages at the RIPE NCC weg server. New Action 26.R1 on the RIPE NCC To add a link on the RIPE web server from the Routing WG pages to the CIDR FAQ location B. Hierarchical authorisation for route objects (J.Schmitz) One major topic of this session was the discussion on hierarchical authorisation for route objects. There was already some discussion on the mailing list regarding various issues involved. To continue with the discussion J.Schmitz compiled the current state in a presentation. The transparencies of the presentation are available at ftp://ftp.ripe.net/ripe/presentations/ripe-m26-jschmitz-haro.html Based upon this several of the open issues were discussed in the WG session. Last year improvements to authorisation during the interaction with the database were discussed. One of the elements is *hierarchical* authorisation and the first implementations of it were done for inetnum objects and domains. Up to now there is no hierarchical authorization scheme for route objects. Following the same reasoning as for inetnum objects - to protect the objects against unauthorized changes - there definitely is a need to apply hierarchical authorisation also to route objects; route objects in the RIPE database are already used by some ISPs to build configuration elements for their routers. Obviously, this calls for stronger protection. The route objects do not stand alone. They do have relationships to other objects in the database * Relation to the autnum object AS numbers constitute routing entities defined in the autnum object. They are closely related to routing and from a logical point of view are hierarchically higher than route objects. However, they form a flat space of numbers and a hierarchy among themselves is difficult to apply. Moreover, autnum objects in the current version of the database do not point to route objects making it difficult to implement a top-to-down search mechanism from autnum objects to route objects. Therefore, some hierarchical authorisation scheme starting from the autnum objects seems to be unapplicable on first sight. Yet, route objects point to two other objects at the same time, both pointers being mandatory: first they point to corresponding autnum objects via the "origin" attribute, and in addition a maintainer must be specified. Interesting enough this maintainer needs not be the same as the maintainer specified in the autnum object allowing creation of route objects for some AS using a completely independent maintainer. Obviously, there should be a possibility to prevent it introducing a hierarchical scheme: the proposal is to allow "mnt-lower" attributes within autnum objects defining which maintainers may create route objects for the AS of the corresponding autnum object. * Relation to inetnum objects Several people are not happy about the fact that there is no reference to address allocation for route objects because address space and its routing are somehow related. There are proposals to make route objects dependent on inetnum objects. The big advantage of such a scheme is that there will be no routes without allocation of address space which is a very appealing approach! However, it is not at all applicable to pure routing registries. Therefore, a dependency of route objects on inetnum objects seems to make the overall handling too complicated. Establishing a mere combination of address space ownership and route objects might be more easy. This may be (and in most cases already is) done somehow by the maintainer object. However, it is again not applicable to pure routing registries. Moreover, ownership and routing often differ, and changes in routing may demand changes in inetnum objects. In general, there are also many more inetnum objects than route objects (because of CIDR) which makes the relation again more complicated. There also is the opinion that the philosophy of the database should be to mirror the real world. In the real world advertised routes are completely controlled by an AS making other authorisation irrelevant. No policy should be enforced which does not exist in the real world. Maybe, consistency can be achieved through notification to flag discrepencies. Obviously, the relationship is difficult and there was not yet any consensus on how to deal with it. The problems might be solved in a unified distributed global registry but there is no immediate solution. More discussion is needed. * A prefix based hierarchical scheme With inetnum objects in the database a prefix based hierarchical scheme is used making shorter prefixes hierarchically higher than longer ones, controlling longer prefixes below them. This scheme could also easily be applied to route objects. Its big advantage is that already a working mechanism exists. However, there are also several problems in it: o To make authorisation work some starting point in form of top level route objects must be created in each registry in order to prevent that anybody may gain control of the whole tree of route objects. These top level route objects are kind of artificial because they do not reflect any routing at all. Starting points are especially diffi- cult to apply to the swamp 192.x. o If a hierarchical authorisation based on prefix length is *enforced* only one route object per IP-range would be allowed. This is different from what can be found in usage of the database today. It will cause difficulties in several cases: - Multihoming today is expressed by several route objects of differing origin. If only one route object is allowed multihoming could not be expressed in the database. This again might be circumvented by intro- ducing multiple origins per route object which again raises the question of authorisation by maintainers. - Relatively often specific IP-subranges are routed by another AS than a given IP-range. If the maintainer of the IP-range allows handling of IP-subranges in general (by specifying a corresponding "mnt-lower" attribute), any IP-subrange may be captured by the maintainers given in the mnt-lower attribute. This may not be intended. A possible solution might be in extending the usage of the "hole" attribute being already an optional attribute of the route object: holes could be excluded from hierarchical authorisation down to the next longer prefix specified. - If a customer changes from one ISP to another the origin of the corresponding route object changes, too. To facilitate the change, currently for a few weeks both ISPs keep a route object of the same IP range with their AS as origin. This is especially important if they generate elements of their router configurations from route objects in the database. The problem is similar to multihoming however with the focus on transition of maintainers. o Even though route objects could be secured by hierarchical authorisation in one registry they are not necessarily protected in another registry because data in different registries do not depend on each other. As a consequence duplication not only of the data but also of the specific hierarchy is indispensable. Obviously, enforcement of a prefix based hierarchical authorisation causes troubles which can not be solved within a short time. * A temporary suggestion The prefix based scheme is very valuable and should be applied somehow. A temporary suggestion is to apply it but not to enforce it, just to notify. The advantages are that it is built upon a working mechanism and nothing much changes. A starting point in form of top level route objects is not needed and duplication in several routing registries has no consequences. Still several route objects of differing origin per IP range are allowed and conflicts with current practice in using the data- base do not occur. Yet, a simple notification does not solve conflicts. The "owner" can not remove conflicting records - but with conflicts two parties exist and both must resolve the problem together. The notification does not solve the problem in itself but it will flag it to exist and that a solution is needed. However, objects in one registry remain unsecure if hierarchical authori- sation is applied in another and in the end this is no real solution. Nonetheless, this is a slight improvement to the current situation which is upwards compatible because notification is also needed if authorisation is enforced in the future. There was a general consensus that pure notification as a temporary solution should be applied. Later, on the way to enforcing authorisation some kind of approval mechanism could be probably installed if errors occur which come from insufficient authorisation for the action requested. With notification several new questions arise: - To keep notification traffic low it might be useful to notify only if it is requested by an object hierarchically higher. Currently, in the database notification only occurs if requested. Because of the impor- tance of route objects one might choose to notify for overlapping routes in all cases. - It might be useful to trigger notification by route objects only. To take the importance of inetnum objects into account one might think of notifications in cases of inetnum objects of overlapping address space. - It might be useful to notify the creator of route objects of the other notifications for coordination purposes. - Up to now notification is done only for the creation of objects, not for changes or deletions. To prevent floods of mail this should be kept. In general, several issues could be clarified but there remains quite a lot to do. The items where consensus was found should be implemented soon and discussion on the other items (still the majority) must continue. New Action 26.R2 on Joachim Schmitz To trigger database implementation of first discussion results from hierarchical authorization for route objects New Action 26.R3 on Joachim Schmitz To finalize the hierarchical authorization for route objects together with the Routing WG C. Report on route aggregation by the RIPE NCC (D.Karrenberg, RIPE NCC) The report on route aggregation could not be given because the statistics mechanism was offline for two months. Therefore, nothing new can be re- ported. DK was asked to fix it and to report again at the next RIPE meeting. Action 25.R1 on Daniel Karrenberg/RIPE NCC To report on the results from the route aggregation analysis on the next RIPE meeting There is other data available from SURFnet showing growth of the Internet: New Action 26.R4 on Eric-Jan Bos To circulate the URL of his analysis of routing table size on the mailing list This has already been done - the URL is ftp://ftp.surfnet.nl/surfnet/net-management/ip/nets.ps and it contains data on the growth of the global routing table since 1 January 1994. D. New Developments of RATools (D.Kessens, ISI) The RATools as part of the Routing Arbiter Project of Merit and ISI are a valuable means to make use of registry data and to compare it to the real world. David Kessens (formerly RIPE NCC, now at ISI) gave an overview of new developments in version 3.4.x and 3.5.1 of the RAToolSet. There were noticable enhancements for RtConfig, a tool which allows automatic gene- ration of router configuration elements from registry data. Moreover, the aoe (autnum object editor) is now in production. The overview of the RAToolSet news is available as ftp://ftp.ripe.net/ripe/presentations/ripe-m26-davidk-ratools.ps.gz and contains information about where to find the software (WWW, ftp). In a second presentation David Kessens introduced the aoe (autnum object editor). With this new tool autnum objects can be automatically generated for registries. Data of neighbors and for the policies can be taken from existing databases, from real life BGP dumps, or entered manually inclu- ding heuristics. It has a user friendly interface including a GUI (based on X.11 Tcl/Tk), an "on-line" help, and it makes updates to IRRs easy. The functionality of aoe was explained by various examples and it turns out that aoe can make work with autnum objects much easier. In the future, RPSL will also be supported (up to now aoe generates RIPE-181++ syntax), cooperation with other tools will be implemented, and more and better heuristic methods will be included. The aoe shares the same requirements with the RAToolSet (which it is part of) being - gcc 2.7.2 or later - libg++ 2.7.2 or later - Tcl 7.5/Tk 4.1 or later in version 3.5.1 of the RAToolSet. The presentation of aoe is available as ftp://ftp.ripe.net/ripe/presentations/ripe-m26-davidk-aoe.ps.gz During the RIPE meeting a test installation of the RA ToolSet was accessible to the participants. E. Report on routing stability (G.Winters, Merit) Since routing stability has become a major issue in the Internet it was very interesting to have a presentation of recent measurements done by Merit. Gerald Winters of Merit showed results from Craig Labovitz which he (Craig) had presented at the May '96 Nanog meeting supplemented by some newer studies. The presentation of Craig Labovitz is available as ftp://home.merit.edu/pub/users/labovit/talks/nanog-9605/instability.ps and further information may be found at http://nic.merit.edu/~ipma/ The presentation was very interesting and caused a lot of discussion. Topics from the presentation and the discussion are comprised below: As it turns out there are peaks of close to 10 million BGP announcements and withdrawals in a given day with more than 100 BGP updates per second. Major providers are not major causes of instability while individual ISPs and end-sites can have a disproportionate effect on routing stability. It is interesting that BGP traffic is a function of weekday/weekend and even of the time of the day. A correlation to the amount of traffic is speculative, however there might be an indication of some correlation to maintenance work. Up to now there has been no analysis whether long holi- days show in the statistics as well. For real big instability incidents (abnormal events) Merit people called the originators of the instability to find out the reason. From a relatively low number of 36 incidents it turned out that - links are nearly no problem - hardware is rarely a problem (but approx 3 times as often as link problems) - software and configuration problems cause more than 50% of BGP updates However, this does not give much indication on the reasons for the general instability below major incidents. A graph showing the number of BGP announcements (normalized to the number of routes) seemed to indicate that the instability grows because a linear regression of the data showed an increase. However, in the discussion it was noted that there was a very large variance in the samples taken and a linear regression may not be justified and therefore misleading. Moreover, the growth in complexity of the Internet may introduce another effect: more routes are seen because of an increasing number of peerings. There- fore, a mere normalisation of the number of BGP announcements to the num- ber of routes may not be sufficient. In the end (because the increase was not very steep), there might be no indication for a growing instability at all. A more elaborated analysis of the BGP announcements shows that most of the BGP updates are redundant or unnecessary with a large percentage of duplicates. 99% of the BGP traffic is withdrawals. One reason for this might be that withdrawals are *always* sent to all peers and accepted there regardless of outgoing or incoming filters. It is suspected that this behaviour is actually wanted because especially if a new filter is set up, previously valid routes should be withdrawn anyway. Another interesting analysis showed the frequency of BGP updates for the same prefix and origin. There were pronounced peaks at 30sec intervals. A close relation to IGP updates is suspected. However, in the discussion it was also mentioned that with Cisco routers the default keepalive on lines is 10sec and the line protocols go down after three missed keep- alives which is 30sec. If immediate BGP update is configured (which is the default) then the corresponding routes are immediately withdrawn. Obviously, there are other sources for this specific frequency and a more detailed analysis should be performed. It was a bit disappointing to have no statistics on the instability depending on the prefix length. With all the data collected an analysis like this should be possible. Recommendations to improve routing stability were - to use BGP route flap dampening - to aggregate as much as possible using CIDR - to filter As already seen at previous RIPE meetings route flap dampening is an impor- tant topic which has been dealt with before. A BOF on this topic was announced (see below). Y. General input from other WGs There was no current input from other WGs. Z. AOB Christian Panigl announced that a BOF session on route flap dampening was planned. The minutes of this session are included here. <at this place the BOF minutes will be included> Summary of Actions ------------------ Action 22.10 on Joachim Schmitz 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 consensus on it Action 25.R1 on Daniel Karrenberg/RIPE NCC To report on the results from the route aggregation analysis on the next RIPE meeting Action 26.R1 on the RIPE NCC To add a link on the RIPE web server from the Routing WG pages to the CIDR FAQ location Action 26.R2 on Joachim Schmitz To trigger database implementation of first discussion results from hierarchical authorization for route objects Action 26.R3 on Joachim Schmitz To finalize the hierarchical authorization for route objects together with the Routing WG Action 26.R4 on Eric-Jan Bos To circulate the URL of his analysis of routing table size on the mailing list Action 26.R5 on Christian Panigl To collect reasonable route flap dampening parameter values and to present them at the next RIPE meeting in the Routing WG Agenda ------ - Routing Working Group Meeting - Agenda for RIPE-26, Jan 1997, Amsterdam A. Administrative issues (J.Schmitz) - volunteering of the scribe - agenda bashing - minutes from last meeting - open actions B. Hierarchical authorisation for route objects (J.Schmitz) - current state - discussion C. Report on route aggregation by the RIPE NCC (D.Karrenberg, RIPE NCC) - in general - route aggregation D. New Developments of RATools (D.Kessens, ISI) - new tools - aoe E. Report on routing stability (G.Winters, Merit) - measurements by Merit - route flap dampening Y. General input from other WGs Z. AOB ---- _____________________________________________________________________________ Dr. Joachim Schmitz schmitz@noc.dfn.de DFN Network Operation Center Rechenzentrum der Universitaet Stuttgart ++ 711 685 5553 voice Allmandring 30 ++ 711 678 8363 FAX D-70550 Stuttgart FRG (Germany) _____________________________________________________________________________