- routing-wg - mailman.ripe.net

list
by Ivan Lambov 16 Apr '97

16 Apr '97

list

1 0

(no subject)
by Dimitrios Chrysaidis 10 Apr '97

10 Apr '97

subscribe

1 0

Draft minutes of the "Route Flap Dampening BOF" @ RIPE26
by Christian Panigl, ACOnet/UniVie 04 Mar '97

04 Mar '97

Dear Routing WG, thanks to Joachim who took notes and provided me with very elaborated draft minutes of our "Route Flap Dampening BOF" ! I did some additions and I'm now asking all participants to come back with comments. And I'd like to remind you to send me your pointers to similar discussions and related recommendations (IETF, NANOG, ...) since I wasn't able to attend other forums than RIPE yet. Regards Christian --- Christian Panigl : Vienna University Computer Center - ACOnet --- --- VUCC - ACOnet : -------------------------------------------- --- --- Universitaetsstrasse 7 : Mail: Panigl(a)CC.UniVie.ac.at (CP8-RIPE) --- --- A-1010 Vienna / Austria : Tel: +43 1 4065822-383 (Fax: -170) --- =================================================== Route Flap Dampening BOF, RIPE 26, 22.1.97, 14:00 Chairman: Christian Panigl (CP) Scribe: Joachim Schmitz (JS) Attendees: approx 30 In the Routing WG session Christian Panigl asked whether people are interested to participate in a BOF on route flap dampening. The BOF session was held after the plenary session of the RIPE meeting on Wednesday. CP experienced quite severe reachability problems of customer networks because route flap dampening became active at various AS borders following scheduled maintenance actions on a core router. If the default dampening parameters were used everywhere, it wouldn't have hurt that much, since dampening would have lasted for ~20-30 minutes only for all prefixes. Some backbone ISPs, however, have started to implement "progressive route flap dampening" typically using different parameters. The common effect is that longer prefixes are dampened more aggressively than shorter prefixes. In the observed case all /24 customer networks were cut off from parts of the Internet for more than 2 hours and were no longer able to reach for instance the root nameservers. By the way, many, even top- and second-level nameservers are sitting in /24 (192/TWD) prefixes themselves and could easily be "victims" of such a progressive dampening policy ! CP wasn't branding route flap dampening itself, but the aggressiveness of some of the implemented "progressive" parameters and was questioning the real usefulness of progressive dampening at all. Following CP's introduction a vivid discussion on route flap dampening came off: * Does flapping really depend on the prefix length? - To the knowledge of people attending the BOF session no measurements exist. Although several items were already measured by Merit on the stability of routes (as seen in the presentation by G.Winters in the Routing WG) they did not include a stability analysis with regard to the prefix length. If flapping does not necessarily depend on the prefix length longer prefixes should not be punished by more aggressive dampening. - However, the number of longer prefixes in the routing tables is much bigger than the number of shorter ones. As a consequence, if the percentage of flapping routes is the same for all prefix lengths the absolute number of flaps will be definitely higher for longer prefixes. As each flap consumes the same performance on the router (regardless of the prefix length) and to get the the best CPU saving factor, longer prefixes should be dampened more aggressively. - Further justification for the latter was primarily based on the assumption that longer prefixes are serving less users, which of course didn't stay uncontradicted (think of important servers sitting in a /24). * Which networks or prefixes are "important"? - Stating that shorter prefixes are more important because they cover more users doesn't hold in general. On the one hand this may be valuable and motivate ISPs to CIDRize and customers to renumber, on the other hand it may lead to the situation that organisations try to get (or keep, think of Class A/B recycling) as short a prefix as possible, wasting address space without having to care for stability. In this case instability would be moved to shorter prefixes which is far from desirable. - Long prefixes need not be instable. There are discussions to use long prefix routes ("golden networks") for root nameservers or for other Internet structure servers (even for application servers as news, etc). It can be well assumed that these routes are more stable than others and they must not be dampened too aggressively in order not to tackle the functionality of the Internet itself. During all the discussion the general consensus was clear: for routers with large BGP tables (notably with full routing) the CPU load would kill any existing router. To survive instabilities route flap dampening should be applied by *everybody*. However, it was obvious that dampening parameters need to be coordinated throughout the Internet in order to - allow efficient dampening and easy clearing after repair - dampen flaps at their source by keeping them from spreading in the network This will significantly increase the overall stability and the manageability. The broader (soft and default) dampening is deployed allover the Internet, the less the need for aggressive paramaters will be. The group was forming into two major camps with regard to how dampening should be done: - progressive dampening: needs to be accompanied by means to explicitely exclude "golden networks" from "hostility acts" - flat (default) dampening: because it's very hard to make a distinction between less and more "important", not to say "golden" networks, all prefixes should be treated equally. Efforts should be focussed on the propagation of dampening throughout the Internet. The default values for dampening parameters as they are found in Cisco routers are based upon some experiments approx one year ago. These experiments lead to recommendations by the IETF last year. Nevertheless, many ISPs have moved away from the default values and are using their own parameters. Because of the urgent need of coordination of these values CP will try to collect related recommendations and the outcome of similar discussions. This is an activity of the RIPE Routing WG, therefore everybody who is aware of related efforts (IETF, NANOG, ...) should come back to the Routing WG list with hints and pointers ! New Action 26.R4 on Chrisian Panigl To collect reasonable route flap dampening parameter values and to present them at the next RIPE meeting in the Routing WG. Further reading: ftp://ftp.ripe.net/ripe/minutes/ripe-m-24.ps ftp://ftp.ripe.net/ripe/minutes/ripe-m-25.ps http://www.ripe.net/wg/routing/r25-routing.html ftp://ftp.ripe.net/ripe/presentations/ripe-m25-tbarber-bgp-damp.html

2 1

subscribe
by kkinsell＠telecom.ie 28 Feb '97

28 Feb '97

subscribe

1 0

route obj & notifications
by Schmitz＠RUS.Uni-Stuttgart.DE 14 Feb '97

14 Feb '97

Dear colleagues, yes, it is me again ;-) asking for comments on another element of hierarchical authorisation for route objects: The idea is to use a prefix based hierarchical scheme just as it is used for inetnum objects. However, it turned out that there are several difficulties in it. So, to get started the consensus at the wg session was: *not* to enforce a prefix based hierarchical scheme until these difficulties are solved, but instead generate notifications only. There are several proposals out there for notifications - to notify only if it is requested (by adding "notify" attributes to objects) - to leave inetnum objects out for the time being until their relation to route objects is clearly defined - notifications should only be done for creation of route objects not for changes or deletions (to prevent mail floods) - probably, the creator of route objects should also be notified of notifications for coordination purposes What are your feelings about this? Yes, no, maybe, missing items? Your comments are welcome! For further reference read/attack/tear apart/abuse the compilation at http://www.ripe.net/wg/routing/haro-d.html Regards Joachim _____________________________________________________________________________ Dr. Joachim Schmitz schmitz(a)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) _____________________________________________________________________________

1 0

route & aut-num objects
by Schmitz＠RUS.Uni-Stuttgart.DE 14 Feb '97

14 Feb '97

Dear colleagues, let's start with a very easy thing near to solution with hierarchical authorisation for route objects: the relation to aut-num objects. A route object references several other objects. Important to us are the references to the maintainer and the aut-num object (both are mandatory attributes of the route object): route: [mandatory] [single] descr: [mandatory] [multiple] origin: [mandatory] [single] ----> points to aut-num object ... mnt-by: [mandatory] [multiple] ----> points to mntner object changed: [mandatory] [multiple] source: [mandatory] [single] The aut-num object also contains a mandatory reference to a maintainer object. Up to now, the maintainers referenced in route object and aut-num object of same origin need not be the same. For hierarchical authorisation it would be nice to introduce a "mnt-lower" attribute in the aut-num object defining which maintainers may create route objects for the AS of the corresponding aut-num object. This allows control of one AS which parties may generate route objects with its origin. We already had consensus in the wg session that this is needed but did not yet decide precisely how to do it. The idea of using a "mnt-lower" attribute came up and I think it is easiest to implement. If there are no objections I will hand on the above proposal for imple- mentation in the database software in two weeks. For further reference read/attack/tear apart/abuse the compilation at http://www.ripe.net/wg/routing/haro-d.html Regards Joachim _____________________________________________________________________________ Dr. Joachim Schmitz schmitz(a)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) _____________________________________________________________________________

1 0

proposed way to proceed...
by Schmitz＠RUS.Uni-Stuttgart.DE 14 Feb '97

14 Feb '97

Dear colleagues, there is work to do and I would appreciate your input very much. We have several actions open from our last wg session at Amsterdam and I would like to continue on them. This week I circulated the 1st draft minutes of our session on the mailing list. For reference, it is now also available on the RIPE NCC webserver. Moreover, I have prepared several new pages for our wg and they are also now available on the RIPE NCC webserver (start out at http://www.ripe.net/wg/routing/index.html) I would like to focus the discussion on two topics: * hierarchical authorisation for route objects - we should first find some consensus on immediate solutions possible as they became apparent from our last wg session; I will send an additional mail immediately following this one - then there are lots of nice problems to solve in general and we need more input on them - for reference read/attack/tear apart/abuse the compilation at http://www.ripe.net/wg/routing/haro-d.html - this thing is completely draft and comments are a *must* - Wilfried Woeber as chair of the database wg asked that contributions should not only be sent to the routing wg mailing list but please be copied to the database wg mailing list as well (because there are also lots of issues regarding the implementation in the database) * future tool development project - this action is open too long for my feeling (and partly due to me because I did not pursue it, sorry). I will prepare some call for ideas and present it on the mailing list in the near future. So, let's continue (and for those who are not yet with us: let's get going ;-) Regards Joachim _____________________________________________________________________________ Dr. Joachim Schmitz schmitz(a)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) _____________________________________________________________________________

1 0

1st draft minutes of Routing WG session at RIPE 26
by Schmitz＠RUS.Uni-Stuttgart.DE 11 Feb '97

11 Feb '97

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(a)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) _____________________________________________________________________________

1 0

Global routing table size graph
by Erik-Jan Bos 23 Jan '97

23 Jan '97

Routing WG, during the Routing WG meeting I promissed to e-mail you the URL of the graph that shows the global routing table size since 1 January 1994. Measurements are done every hour on the hour, by a script I run on my workstation. This graph is updated automatically, every hour. The URL is: ftp://ftp.surfnet.nl/surfnet/net-management/ip/nets.ps The first real dip in the graph was after the Houston (?) IETF, where during the CIDRD working group meeting almost all ISPs present decided to start using CIDR. __ Erik-Jan.

1 0

Re: hierarchical route objects, part 1
by Schmitz＠RUS.Uni-Stuttgart.DE 16 Jan '97

16 Jan '97

Dear Curtis, you wrote: > > > Here is an example. The registries approve of the top level blocks, > > > that is the aggregates (or blocks that should be announced as > > > aggregates). Whoever the aggregate is allocated to creates the top > > > level route object and can delegate below that. For example, ANS has > > > 207.24/14. There were two route objects needed to handle multihomed > > > (a /22 and a /24) prefixes. The usual way a provider would delegate > > > would be to reference more than one maintainer in the route object > > > (the provider and the customer, and probably the other provider if the > > > route object had a unique origin AS). > > > > > This scheme sounds reasonable but it raises the question of coordination > > among different registries... > > I would not expect to see the same address space allocated by more > than one registry. All registries would have a top level 0/0 route > object which prevents registry of bogons. RIPE would have a hierarchy > under 0/0 and the RA would have a hierarchy tracking InterNIC assigned > addresses. I would not expect the two to overlap, therefore there is > no real coordination problem beyond initial setup or new blocks > allocated to a registry. > This is more difficult than it looks from the beginning. As an example we ourselves register all our objects (inetnum, routes, persons...) in RIPE database (because we are in Europe). However, among others we peer with MCI and MCI insists on having route objects in their registry in order to allow routing. If the route objects are secured by hierarchical authorisation in the RIPE database we would also like to have them secured in the MCI registry. Following the scheme above MCI would have to include inetnums (while it is a pure routing registry) *and* would have to generate top level route objects allowing specific access by us to our route objects (this is a very tiring job especially regarding "the swamp" 192.x). Of course, they could copy from RIPE database... (ask them why they don't...) I guess, this problem may only be resolved by the GRR (which is yet to come) From the ongoing disussion I conclude for myself (at the current state of the discussion) that we can not impose a strict security mechanism at the time being without breaking too many things. Maybe, I am too dumb to see a simple solution which might be just at hand... I will summarise the things said here on the mailing list for the routing wg session next week and try to think some more about it (I guess, Daniel was right from the start when he said that we should begin with a bare notification mechanism...) Regards Joachim _____________________________________________________________________________ Dr. Joachim Schmitz schmitz(a)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) _____________________________________________________________________________

2 1