routing-wg

Download

routing-wg@ripe.net

May 1996

2 participants
2 discussions

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