- routing-wg - mailman.ripe.net

Progressive BGP route flap dampening
by Christian Panigl, ACOnet/UniVie +43 1 4065822-383 02 Jan '97

02 Jan '97

Dear Routing WG members, sorry for not having had the opportunity to participate in the last few meetings. I'm trying hard for the January meeting ! In the meantime let me initiate an e-mail discussion wrt route flap dampening (I'm appending the relevant part of the minutes of the Sept. meeting, where further discussion was requested). Recently, following a scheduled router-maintenance on an Ebone backbone router, I had problems to communicate with NORDUnet (haven't explicitely tried PIPEX ;-) from /24 networks for about 2 hours ! This reminded me of the "progressive route flap dampening" discussion, and increased my motivation for throwing my 0.02 EUROs into the routing-wg list: - I can't beleive that it's really necessary and reasonable to kill a network (regardless of prefix-length) for two hours if it's flapping twice maybe within half an hour but not more frequently within a month ! - Imagine you're SW-upgrading a router and (very unlikely, as we all know ;-} detect that you have to step back ... BINGO, it's perfectly and innocently electrocuted :-( - I'd suggest that dampening (regardless of prefix length) shouldn't start before AT LEAST three flaps are happening in a row (let's say within half an hour). - Dampening should lockout real network instabilities not make worse even scheduled maintenance ! - Besides, I know applications where it might be perfectly reasonable to announce a single *providerindependent* /24 and where it's contraproductive and politically incorrect to include it into an ISP aggregate ! A solution could be to ask Internic/RIPE to define "PI" address-ranges which can and should be excluded from the /24 hostility acts. Kind regards Christian ===== Following quoted from = = RIPE 25, Amsterdam = Routing Working Group = Report of Meeting, 23rd September 1996 = = [...] = =6. Progressive BGP route flap dampening = ftp://ftp.ripe.net/ripe/presentations/ripe-m25-tbarber-bgp-damp.html = = Tony Barber gave a presentation on the strategies used by = UUnet-Pipex to reduce the effects of route flapping and to = try to prevent router table overflow. These were: = = - route dampening = - prefix filtering = - more router memory = = They had encountered many instabilities from peers and found = that many ISPs had not deployed CIDR; this gave rise to more = flapping as more routes, and particularly more specific ones, = were advertised. = = Tony explained the parameters used for route dampening on a = Cisco router. He had arrived at the following re-use times = for various route sizes: = = /24 and greater ~160 minutes = /23 and /22 ~60 minutes = /21 and less ~30 minutes = = He recommended filtering out all prefixes more specific than /24. = = While route dampening consumed router memory, this was more or = less balanced by a reduction in routing CPU cycles. = = He recommended that if route dampening was to be widely = deployed in Europe, consistency was important. In this sense, = the Routing WG should agree on guidelines for parameters to = be used. = = In discussion, the following points were made: = = - aggregation works in reducing router load and route = flapping. = = - route flapping is often a feature of certain autonomous = systems rather than a function of prefix length. = = - much instability was due to configuration changes and = errors as distinct from link failures. = = - making dampening dependent on prefix length could = penalise many stable /24s. = = - it might be useful to discriminate against /24s in the = 192.0.0.0/8 block (the swamp). = = - the focus should be on keeping noise out of the system = rather than trying to mitigate against it once in the = system. = = In summary, it was agreed that route dampening was an = important topic and that more discussion was needed. = ===== End quote

2 1

RAToolSet version 3.5.0 is now released
by Cengiz Alaettinoglu 17 Dec '96

17 Dec '96

RAToolSet version 3.5.0 is now available from: http://www.isi.edu/ra/RAToolSet ftp://ftp.isi.edu/ra/RAToolSet This version contains the beta release of aoe, Autonomous System Object Editor: aoe simplifies the creation of aut-num objects by employing some heuristics to add and modify as-in and as-out attributes. For example, given a BGP dump from a router inside your AS, aoe parses the AS_PATH attributes in the BGP dump, and determines the peer ASes, and the import policies for each peer AS. A template based mechanism is provided for users to create their own heuristics to augment the heuristics that we provide. aoe can register the aut-num object in the IRR after editing is done. aoe is implemented by WeeSan Lee. RtConfig has couple of new features: -supress_martian option -@RtConfig networks commands -@RtConfig default commands There are also some minor bug fixes. Please refer to the man pages for the details. We will be presenting the new features during the upcoming ietf. Precompiled binary versions for selected OSes will be made available after the IETF. As usual, bug reports, suggestions for improvements and particularly patches are welcome. Cengiz -- Cengiz Alaettinoglu Information Sciences Institute (310) 822-1511 University of Southern California http://www.isi.edu/~cengiz

2 1

RAToolSet 3.5.0 has in/out bug with export policy
by David M. Meyer 07 Dec '96

07 Dec '96

It looks like RtConfig 3.5.0 confuses "in" and "out" when a distribute-list command (instead of a route-map) is generated from an export command. In this case, the export policy is NOT ANY. To see this, consider the following RtConfig code: @RtConfig set cisco_map_name = "AS2914-EXPORT" @RtConfig export AS7396 198.32.162.100/32 AS2914 205.238.48.3/32 @RtConfig set cisco_map_name = "AS2914-IMPORT" @RtConfig import AS7396 198.32.162.100/32 AS2914 205.238.48.3/32 and consider this aut-num for AS7396: aut-num: AS7396 as-name: OREGON-IX descr: Oregon Exchange Route views (route-views.oregon-ix.net) as-in: from AS2914 100 accept ANY AND NOT {0.0.0.0/0} as-in: from AS3333 100 accept ANY AND NOT {0.0.0.0/0} as-in: from AS2497 100 accept ANY AND NOT {0.0.0.0/0} as-out: to AS2914 announce NOT ANY as-out: to AS3333 announce NOT ANY as-out: to AS2497 announce NOT ANY guardian: meyer(a)ns.uoregon.edu admin-c: DMM65 tech-c: DMM65 notify: nethelp(a)ns.uoregon.edu mnt-by: MAINT-AS3582 changed: meyer(a)ns.uoregon.edu 961206 source: RADB ` Then RtConfig 3.5.0 generates no access-list 1 access-list 1 deny ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 ! router bgp 7396 neighbor 205.238.48.3 distribute-list 1 in no access-list 2 access-list 2 deny ip 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 access-list 2 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 ! ! no route-map AS2914-IMPORT route-map AS2914-IMPORT permit 1 match ip address 2 ! router bgp 7396 neighbor 205.238.48.3 route-map AS2914-IMPORT in neighbor 205.238.48.3 distribute-list 2 in Note that router bgp 7396 neighbor 205.238.48.3 distribute-list 1 in should be router bgp 7396 neighbor 205.238.48.3 distribute-list 1 out ^^^ At least this is what I would have expected. Dave

2 1

hierarchical auth with route objects
by Schmitz＠RUS.Uni-Stuttgart.DE 05 Dec '96

05 Dec '96

Dear colleagues, hierarchical authorization in the RIPE-db as a new feature presented at the last RIPE meeting is not limited to inetnum objects or the domain name space. It is also applicable to route objects. However, it has not yet been implemented for route objects because no consensus was found on how to do it. With this mail I want to start the discussion again. Please note, that this is only the draft of a draft - nothing final. So drop your comments here! In my opinion, route objects are not much different from inetnum objects regarding hierarchical authorization. Both span a certain range of IP addresses and in both cases hierarchical authorization controls definition of IP subranges. Following this reasoning it seems to be simple to implement within the IP prefix tree. However, route objects are not standing alone but are logically linked to AS objects via the origin tag. Applying hierarchical authorization within the IP prefix tree *alone* does allow uncontrolled creation of route objects of differing origin. Therefore, AS objects which match the origin AS of a route object may be considered as parent objects of route objects. I think this is a very useful approach (even though it links different types of objects in one authorization hierarchy). There have been ideas that route objects should only be created if proper address allocation occured. However, it has also been pointed out that it is not a good idea to mix address allocation and routing for several rea- sons, e.g. some registries are pure routing registries and all registries should have the same structure. Moreover, changes in routing might make changes in address registration necessary (and vice versa). There have been some good comments on this topic on the database wg mailing list. Never- theless, if no route objects exist for allocated address space, any AS owner may generate route objects uncontrolled in this registry (creation of objects in one registry which are protected by hierarchical authorization in another is also not covered but this is an entirely different problem). Obviously, there are still some loose ends. But I think that the approach of AS objects as parents of route objects from corresponding origin com- bined with hierarchical authorization within the IP prefix tree is very useful and may be applied here. Shall we go for this? Regards Joachim Schmitz _____________________________________________________________________________ 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) _____________________________________________________________________________

3 2

final minutes of the routing WG session at RIPE 25
by Schmitz＠RUS.Uni-Stuttgart.DE 02 Nov '96

02 Nov '96

Dear Routing WG members, since there have been no additional comments on the minutes of our session at RIPE 25 I conclude that the minutes are accepted as is. I updated some URLs but there is no other change. The final version of the minutes is appended below. Thanks again to Mike Norris who took them. Regards Joachim -------- RIPE 25, Amsterdam Routing Working Group Report of Meeting, 23rd September 1996 1. Opening and Administrivia Willem van der Scheun, Chairman, presided and welcomed people to the meeting. There were 89 attenders. Mike Norris took minutes. 2. Agenda bashing A draft agenda of business, circulated by the Chairman in the previous week, was agreed. 3. Chairman of the Routing WG Willem announced that his day job prevented him from devoting the time necessary to chairmanship of the WG and that he was standing down. He was pleased to say that Joachim Schmitz would accept his proposal to be Chairman, and this proposal was endorsed by the meeting. Members thanked Willem for his work as Chairman and guidance of the WG. Joachim chaired the remainder of the meeting. 4. Report from the RIPE NCC Daniel Karrenberg said that the RIPE NCC planned to resume its studies of route aggregation. An exercise he had conducted earlier in 1996 and reported to RIPE 24 had revealed plenty of room for improvement. Individual reports to those responsible for over-specific routing had resulted in significant improvements. Since then, however, the aggregation situation had disimproved. Daniel's impression was that some ISPs didn't care or wouldn't take the trouble to correct matters. Further remedial action was needed and the Contributors' Committee supported the NCC in this work. Skilled staff would soon be appointed and they would help ISPs in promoting route aggregation. While neither RIPE nor the NCC could take action against any offenders, the use of peer pressure among the ISPs could be used in a positive manner to improve the position. The meeting encouraged ISPs to supply BGP data to the NCC on request for the purpose of analysing route aggregation. New Action: the NCC would report on route aggregation at RIPE 26. 5. Working Experience with Route Object Editor (ROE) ftp://ftp.ripe.net/ripe/presentations/ripe-m25-jschmitz-work-exp-roe.html Joachim Schmitz reported on his experience with ROE. This was part of the RA Toolset and had been written by Cengiz Alaettinoglu. Its purpose was to view and manipulate route objects and to compare them with operational routes. It worked on routes as objects from Internet routing registries (IRRs) and as determined from routers (by means of input BGP tables). Compiled with C++ in a Tcl/Tk environment, ROE was easy to install. With its GUI it was easy to use. As not all IRRs were aligned in the way they worked, ROE displayed separate route registrations where appropriate. Joachim found it slow in operation, although Cengiz later indicated that this was probably due to network and server performance and not to the ROE program execution. It was also not clear to Joachim whether live or mirrored IRR data was used. He suggested that the program could be improved by allowing more configuration options and greater clarity in some of the messages. This and other feedback should be directed to Cengiz. Overall, he recommended ROE for operational use, particularly for complex routing tasks. 6. Progressive BGP route flap dampening ftp://ftp.ripe.net/ripe/presentations/ripe-m25-tbarber-bgp-damp.html Tony Barber gave a presentation on the strategies used by UUnet-Pipex to reduce the effects of route flapping and to try to prevent router table overflow. These were: - route dampening - prefix filtering - more router memory They had encountered many instabilities from peers and found that many ISPs had not deployed CIDR; this gave rise to more flapping as more routes, and particularly more specific ones, were advertised. Tony explained the parameters used for route dampening on a Cisco router. He had arrived at the following re-use times for various route sizes: /24 and greater ~160 minutes /23 and /22 ~60 minutes /21 and less ~30 minutes He recommended filtering out all prefixes more specific than /24. While route dampening consumed router memory, this was more or less balanced by a reduction in routing CPU cycles. He recommended that if route dampening was to be widely deployed in Europe, consistency was important. In this sense, the Routing WG should agree on guidelines for parameters to be used. In discussion, the following points were made: - aggregation works in reducing router load and route flapping. - route flapping is often a feature of certain autonomous systems rather than a function of prefix length. - much instability was due to configuration changes and errors as distinct from link failures. - making dampening dependent on prefix length could penalise many stable /24s. - it might be useful to discriminate against /24s in the 192.0.0.0/8 block (the swamp). - the focus should be on keeping noise out of the system rather than trying to mitigate against it once in the system. In summary, it was agreed that route dampening was an important topic and that more discussion was needed. 7. Routing Policy analysis tools http://www.isi.edu/ra/Presentations Cengiz Alaettinoglu of ISI presented a review of recent developments and updates in the RA toolset, now at version 3.4.0. The set of front-end tools used a number of back-end libraries, which made program development easier. It required RAWhoisd v3.0 and had been ported to several operating systems. Cengiz gave details of availability (URL = http://www.isi.edu/ra/RAToolSet as official reference or copies also available from ftp://ftp.isi.edu/ra/RAToolSet/RAToolSet-3.4.1.tar.gz or ftp://ftp.ra.net/routing.arbiter/tools/RAToolSet/RAToolSet-3.4.1.tar.gz ) and of the mailing list (ratoolset(a)isi.edu, subscription via robot majordomo(a)isi.edu) The toolset was made available for demonstration purposes to attenders of RIPE 25. RtConfig generated the BGP access list part ofrouter configuration from route objects. It was now used in production by some major network operators. ROE was again shown, with reference to review options before submitting a changed route object. The AS object editor (AOE) was not implemented, though it was on demo at RIPE 25. CIDRAdvisor identifies 'safe' aggregates by route originators as well as aggregates for proxies. Cengiz showed the effects of using various radius values for the distance that aggregation should hold. 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 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 New action 25.R1 on Daniel Karrenberg/RIPE NCC To report on the results from the route aggregation analysis on the 26th RIPE meeting New action 25.R2 on Joachim Schmitz To coordinate making the presentations at the Routing WG available. This action is already done. Mike Norris 23/9/96 _____________________________________________________________________________ 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

RAToolSet 3.4.1 is available for anonymous ftp
by Cengiz Alaettinoglu 16 Oct '96

16 Oct '96

RAToolSet 3.4.1 (contains RtConfig and Route Object Editor in addition to other tools) is now available at http://www.isi.edu/ra/RAToolSet ftp://ftp.isi.edu/ra/RAToolSet The ftp directory also contains binaries for selected architectures. We can make binaries for other systems available upon request. RAToolSet 3.4.1 compiles out of the box for the following systems: SunOS, Solaris, OSF/1, BSDI, FreeBSD, linux, and probably on other systems as well. There is also a mailing list, ratoolset(a)isi.edu. To join, please send a message to majordomo(a)isi.edu with body containing subscribe ratoolset In the upcoming Nanog, there will be demos of these tool. Bug reports, fixes and suggestions for improvements are welcome and appreciated. Cengiz -- Cengiz Alaettinoglu Information Sciences Institute (310) 822-1511 University of Southern California http://www.isi.edu/~cengiz

1 0

draft minutes of the WG session at RIPE 25
by Schmitz＠RUS.Uni-Stuttgart.DE 08 Oct '96

08 Oct '96

Here are the draft minutes of the WG session at RIPE 25. Thanks to Mike Norris for taking them. Comments to the draft minutes are welcome, the final version will be circulated next week. Joachim ------ RIPE 25, Amsterdam Routing Working Group Report of Meeting, 23rd September 1996 1. Opening and Administrivia Willem van der Scheun, Chairman, presided and welcomed people to the meeting. There were 89 attenders. Mike Norris took minutes. 2. Agenda bashing A draft agenda of business, circulated by the Chairman in the previous week, was agreed. 3. Chairman of the Routing WG Willem announced that his day job prevented him from devoting the time necessary to chairmanship of the WG and that he was standing down. He was pleased to say that Joachim Schmitz would accept his proposal to be Chairman, and this proposal was endorsed by the meeting. Members thanked Willem for his work as Chairman and guidance of the WG. Joachim chaired the remainder of the meeting. 4. Report from the RIPE NCC Daniel Karrenberg said that the RIPE NCC planned to resume its studies of route aggregation. An exercise he had conducted earlier in 1996 and reported to RIPE 24 had revealed plenty of room for improvement. Individual reports to those responsible for over-specific routing had resulted in significant improvements. Since then, however, the aggregation situation had disimproved. Daniel's impression was that some ISPs didn't care or wouldn't take the trouble to correct matters. Further remedial action was needed and the Contributors' Committee supported the NCC in this work. Skilled staff would soon be appointed and they would help ISPs in promoting route aggregation. While neither RIPE nor the NCC could take action against any offenders, the use of peer pressure among the ISPs could be used in a positive manner to improve the position. The meeting encouraged ISPs to supply BGP data to the NCC on request for the purpose of analysing route aggregation. New Action: the NCC would report on route aggregation at RIPE 26. 5. Working Experience with Route Object Editor (ROE) ftp://ftp.ripe.net/ripe/presentations/ripe-m25-jschmitz-work-exp-roe.html Joachim Schmitz reported on his experience with ROE. This was part of the RA Toolset and had been written by Cengiz Alaettinoglu. Its purpose was to view and manipulate route objects and to compare them with operational routes. It worked on routes as objects from Internet routing registries (IRRs) and as determined from routers (by means of input BGP tables). Compiled with C++ in a Tcl/Tk environment, ROE was easy to instal. With its GUI it was easy to use. As not all IRRs were aligned in the way they worked, ROE displayed separate route registrations where appropriate. Joachim found it slow in operation, although Cengiz later indicated that this was probably due to network and server performance and not to the ROE program execution. It was also not clear to Joachim whether live or mirrored IRR data was used. He suggested that the program could be improved by allowing more configuration options and greater clarity in some of the messages. This and other feedback should be directed to Cengiz. Overall, he recommended ROE for operational use, particularly for complex routing tasks. 6. Progressive BGP route flap dampening ftp://ftp.ripe.net/ripe/presentations/ripe-m25-tbarber-bgp-damp.html Tony Barber gave a presentation on the strategies used by UUnet-Pipex to reduce the effects of route flapping and to try to prevent router table overflow. These were: - route dampening - prefix filtering - more router memory They had encountered many instabilities from peers and found that many ISPs had not deployed CIDR; this gave rise to more flapping as more routes, and particularly more specific ones, were advertised. Tony explained the parameters used for route dampening on a Cisco router. He had arrived at the following re-use times for various route sizes: /24 and greater ~160 minutes /23 and /22 ~60 minutes /21 and less ~30 minutes He recommended filtering out all prefixes more specific than /24. While route dampening consumed router memory, this was more or less balanced by a reduction in routing CPU cycles. He recommended that if route dampening was to be widely deployed in Europe, consistency was important. In this sense, the Routing WG should agree on guidelines for parameters to be used. In discussion, the following points were made: - aggregation works in reducing router load and route flapping. - route flapping is often a feature of certain autonomous systems rather than a function of prefix length. - much instability was due to configuration changes and errors as distinct from link failures. - making dampening dependent on prefix length could penalise many stable /24s. - it might be useful to discriminate against /24s in the 192.0.0.0/8 block (the swamp). - the focus should be on keeping noise out of the system rather than trying to mitigate against it once in the system. In summary, it was agreed that route dampening was an important topic and that more discussion was needed. 7. Routing Policy analysis tools http://www.isi.edu/ra/Presentations Cengiz Alaettinoglu of ISI presented a review of recent developments and updates in the RA toolset, now at version 3.4.0. The set of front-end tools used a number of back-end libraries, which made program development easier. It required RAWhoisd v3.0 and had been ported to several operating systems. Cengiz gave details of availability (URL = http://www.isi.edu/ra/RAToolSet as official reference or copies also available from ftp://ftp.isi.edu/pub/cengiz/RAToolSet-3.4.0.tar.gz or ftp://ftp.ra.net/routing.arbiter/tools/RAToolSet/RAToolSet-3.4.0.tar.gz ) and of the mailing list (ratoolset(a)isi.edu) The toolset was made available for demonstration purposes to attenders of RIPE 25. RtConfig generated the BGP access list part ofrouter configuration from route objects. It was now used in production by some major network operators. ROE was again shown, with reference to review options before submitting a changed route object. The AS object editor (AOE) was not implemented, though it was on demo at RIPE 25. CIDRAdvisor identifies 'safe' aggregates by route originators as well as aggregates for proxies. Cengiz showed the effects of using various radius values for the distance that aggregation should hold. 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 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 New action on Daniel Karrenberg/RIPE NCC To report on the results from the route aggregation analysis on the 26th RIPE meeting New action on Joachim Schmitz To coordinate making the presentations at the Routing WG available Mike Norris 23/9/96 _____________________________________________________________________________ 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

Short summary of WG session at RIPE25
by Schmitz＠RUS.Uni-Stuttgart.DE 08 Oct '96

08 Oct '96

The following short summary of the WG session at RIPE25 has already been submitted to the RIPE NCC last week. The draft minutes will be circulated this week. Joachim ----- RIPE 25 Short minutes from the Routing WG Meeting 23.9.96 16:00-18:10 89 participants Chairmen: Willem van der Scheun, Joachim Schmitz Scribe: Mike Norris * New chairman Joachim Schmitz (JS395-RIPE), schmitz(a)noc.dfn.de * Presentations Joachim Schmitz, DFN-NOC: Working Experience with ROE Tony Barber, Pipex: Experience with Progressive BGP Route Flap Dampening Cengiz Alaettinoglu, ISI: The RA ToolSet During the RIPE meeting a test installation of the RA ToolSet was accessible to the participants * 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 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 New action on Daniel Karrenberg/RIPE NCC To report on the results from the route aggregation analysis on the 26th RIPE meeting New action on Joachim Schmitz To coordinate making the presentations at the Routing WG available _____________________________________________________________________________ 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

Fwd: Re: mnt-lower attribute not allowed?
by Wilfried Woeber, UniVie/ACOnet 04 Oct '96

04 Oct '96

Dear routing folks ! Just wanted to let you know that we've just started a discussion on how to properly maintain route: objects on the DB-WG list. You're more than welcome to join in on db-wg(a)ripe.net (or we could move the discussion to the routing-wg list :-)! Wilfried. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Subj: Re: mnt-lower attribute not allowed? Hi Steven et.al. ! => => The AS object that matches the origin AS of a route object could be the => parent object of the route object, but then people are still able to put => route objects in with another origin AS which might not be desired by the => owner of the non-portable CIDR address space. Furthermore, a second => hierarchy exists: the IP prefix tree. => => You might want to try to formulate a proposal that is not too => complicated and also addresses the concerns of most people ... = =How about making the inetnum object the parent of the route object? =I think it would make sense to allow the "owner" of the inetnum to create =the route objects.. I'm not convinced that this is the way to go. For two major reasons: - in many environments the routing is handled differently from the address allocation. In particular, where filters or other things are (semi-)automatically derived from objects in the DB, it's certainly not feasable to have the customers ("owner" of the address space) change things without coordination. If they do, it might not reflect reality at all or it might interfere with local logistics. And there's the issue of porting PA address space for a limited amount of time to a different ISP. - I think we should come up with a concept that works as well outside the RIPE-coordinated address space and the central registry concept. I think we should . come up with a solution that works for routing-registries that do not include an address registry in the same DB, . find a solution that works uniformly across all parts of the address space (A, B, C-19[3-5], TWD, et.al.) = You can also keep the owner in the "notify:" field of =the route object, so once you delegate maintenance of the route object to =someone else, you can still keep track of what's happening with it. = =Or does this sound ludicrous? No, it made me think, thus it was a very useful approach :-) I'd favour an approach that is (conceptually) similar to the handling of domain objects - something like an upstream search based on the AS #. Although I haven't a clear picture of how it could work in reality, because the "tree" is certainly less well-defined than in the DNS namespace. Another idea would be to have a registry-pointer in the inetnum objects that identifies a articular regsitry object. This in turn could be used to describe the desired maintainance. We might want to have that linkage anyway? I'm not sure whether that meets David's criteria of "not too complicated and also addresses the concerns of most people" :-) Cheers, Wilfried. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at Computer Center - ACOnet : Vienna University : Tel: +43 1 4065822 355 Universitaetsstrasse 7 : Fax: +43 1 4065822 170 A-1010 Vienna, Austria, Europe : NIC: WW144 --------------------------------------------------------------------------

1 0

BGP route dampening details
by Tony Barber 03 Oct '96

03 Oct '96

I have put the text of the presentation at the last ripe routing wg at : http://www.pipex.net/people/tonyb/bgp-damp.html fot anyone who is interested. Regards --Tony

1 0