- routing-wg - mailman.ripe.net

Power Tool For Webmasters
by powertools＠cybertools.net 29 Jul '97

29 Jul '97

With over 30 million documents on the Web today, and thousands more being added almost hourly, it is now harder than ever for potential customers to find your place on the Net. Which is why we've developed the Web Promotion Spider for Windows 95 / NT . This amazing new software automatically submits your site to over 250 (the list grows daily) major search engines, directories, and Usenet newsgroups! Not only that, The Web Promotion Spider has the ability to dynamically optimize your website, ensuring maximum visibility on the Internet - at the same time recording all registration data in a built in database. Originally engineered for use by the professional advertising industry, this program is easy and intuitive to use. Beginners will be amazed at how simple it is to take complete control over their search engine and index marketing efforts. But don't be fooled by its simplicity! The Web Promotion Spider is an industrial strength marketing tool and an extremely valuable part of any on-line publicity campaign. With this kind of power, it should come as no surprise that many of our customers have built profitable on-line promotional businesses with this product and their existing Internet connection! But don't just take our word for it. The Web Promotion Spider is available now for FREE immediate download on a limited trial basis (shareware). Visit http://www.cybertools.net/spider /////////////////////////////////////////////////////////////////////////////// If you wish to be removed from future mailings, please reply with the subject "Remove" and this software will automatically block you from future mailings. ////////////////////////////////////////////////////////////////////////////////

1 0

Re: Routing WG Minutes - RIPE 27, Dublin
by SchmitzJo＠aol.com 14 Jul '97

14 Jul '97

Dear Carol, you wrote: > >> RIPE 27 : Routing WG Draft Minutes > >> Chair : Joachim Schmitz (JS395-RIPE) > >> Scribe : Anne Lord (AL12-RIPE) > >> Attenders : 57 > >> [...] > >> 2. Hierarchical Authorisation / Cross Notification of Route Objects > >> in the IRR (Carol Orange) > >> > >> 2.1 Cross Notification [...] > >> After a fairly lengthy and interesting discussion, it was agreed to go > >> ahead with implementing the draft proposal given the following > >> modifications which were agreed: > >> > >> - the submitter of the route will always be notified as to whether the > >> object submitted was successful. Notification of overlaps can be built > >> into the acceptance/feedback message returned to the submitter. > >> > >> - for deleting a conflicting object, it was agreed to notify the > >> submitter of the conflicting object that there was no longer a > >> conflict in the database > >> > >> - notifications on overlap - either for newly submitted route objects, > >> or for deletions - will only be done for *existing* route objects if > >> explicitly requested by the "x-notify" attribute > > I've reworded the above adjustments as I understood them, and have > incorporated them in the newest version (to be submitted on the list). > You can keep whichever version you find clearer. They say the same > thing. > > - Whenever a route object is submitted in the RR, a notification > should be generated to the submitter if the address space overlaps > with any other route object in the RR. This is regardless of whether > the new attribute for cross notification is used. I agree with this one. However, I suggest to keep the note that the notifi- cation to the submitter is included in the acceptance/feedback message on the submission mail - this keeps mail traffic low. > > - If the address space covered in the route object matched the > address space in another route object, be sure this is clear in the > notification message. Agreed. > > - Notifications should be sent to the appropriate contact not only if > an overlap is introduced, but also when an overlap is eliminated. Again agreed. However, in your proposal I am missing a bit the distinction between the two parties involved: (a) the submitter, and (b) the owner of a route object which already exists in the RR and the new submission is in conflict with it. I try to think a bit more about the text and probably rewrite it taking your suggestions into account. [...] > >> > >> 2.2 Hierarchical authorisation in the RR (Carole Orange) > >> (or "aut-num authorisation for route objects in the RR") > >> > >> The proposal is documented in a draft document which was previously > >> circulated to the Database WG and Routing WG mailing lists. Agreement > >> on this proposal is now sought so that it can be implemented. > >> > >> The goal of the proposal is to allow network operators who announce a > >> route in their AS to delegate this authority to others. > > No, the goal is to allow network operators who maintain an aut-num > object to determine who can submit a route object with their AS number > as origin. Yes. We must change this in the minutes. > > >> There has been > >> much discussion on the mailing lists and a specific "non-goal" of the > >> proposal is to produce an optimal hierarchical authorisation scheme > >> for the RR. This proposal is not CIDR based; hence the change of name > >> for the draft to avoid any confusion about CIDR based hierarchy in the > >> proposal to "Aut-num authorisation for route objects in the RR". > >> > >> The proposal works briefly by the following mechanism: > >> > >> A "mnt-route" attribute (in former drafts called "mnt-lower") is added > >> to the aut-num object. Currently the "mntner" object referenced > >> determines who can add/update/delete an object associated with that > >> aut-num (for more details see the draft which can be found at the > >> reference above in the archives of the mailing list, or look at the > >> Working Documents section of the Routing WG at the RIPE web server). > > No, this is not the case. There are currently no restrictions on who > can add/update/delete a route object specifying a given aut-num in the > origin. The proposal is intended address this authorization gap, by > allowing network operators to specify these restrictions, and as you > state above, by also allowing them to delegate this authority if they > so desire. You are again right. Sorry, this slipped. [...] > >> > >> 5. Route Flap Dampening Parameters (Christian Panigl) [...] > What I miss in this summary is that there seemed to be consensus at > the meeting that "it is beneficial if everyone adopts the same > parameters, because it allows problems to be detected and addressed on > the home front." (but perhaps that was obvious, and I'm being picky.) No, you are not picky. I consider this an important point and will add it to the minutes. Thank you very much for your comments! Regards Joachim

1 0

Cross Notification in the Routing Registry
by Carol Orange 11 Jul '97

11 Jul '97

Dear all, The following describes a mechanism for "Cross Notification in the Routing Registry" to be implemented shortly at the RIPE NCC. The mechanism has been modified to incorporate the feedback received during RIPE 27. Appended is a short history explaining how the proposal reached its current form. If this mechanism is of interest to you, please review the document and send any comments or questions you may have to myself. Unless we hear show stoppers, we will start the implementation in the week of July 21, 1997. Greetings, Carol Orange, RIPE NCC -------------------------------------------------------------------- Cross Notification in the Routing Registry Carol Orange, July 1997 Suppose you register the announcement of a route covering some /24. When you make the announcement, it may be useful to know that the /24 has already been registered as being announced in another AS. Alternatively, if a user of a /24 which is announced by you decides to become multi-homed, it may be of interest to you. Overlapping routes are often unintentionally announced in a single AS, and a mechanism for detecting such errors would certainly be handy. In the following, we propose a simple cross notification mechanism which will allow routing registry users to be notified of overlapping route announcements in the Routing Registry (RR). Consider the route object: route: [mandatory] [single] [primary/look-up key] descr: [mandatory] [multiple] [ ] origin: [mandatory] [single] [primary key] hole: [optional] [multiple] [ ] withdrawn: [optional] [single] [ ] comm-list: [optional] [multiple] [ ] advisory: [optional] [multiple] [ ] remarks: [optional] [multiple] [ ] notify: [optional] [multiple] [inverse key] mnt-by: [mandatory] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] To address the considerations above, we propose the following notification mechanism be implemented in the Routing Registry: 1. Whenever a route object is added to the routing registry, a check is done to see if the address space overlaps with that in any other route object in the RR. If so, a notification will be sent to the submitter of the route object. This will always happen and is not dependent on any notification attributes described below. 2. A new field called "cross-nfy:" will be added to the route and aut-num objects. This field: a) contains a contact reference, specified as either + a NIC-handle pointing to a person or role object, the email address of which will get the notification; or + a mntner ID referencing the maintainer to be notified; b) is optional; and c) is multiple (so that more than one contact can be notified). This attribute is used to request notifications of the addition or removal of route objects which overlap the address space of the already registered route objects in which this attribute is specified. If the "cross-nfy:" attribute is used in: + a route object, then a notification will be sent for any overlaps with the address space specified in the route object; + an aut-num object, then a notification will be sent for overlaps with the address space specified in each route object in which the given AS number is specified in the "origin:" attribute. The contact in "cross-nfy:" will receive an e-mail whenever: + a route is registered which overlaps this address space; or + a route is removed which overlapped this address space. If all is well, the former will indicate the introduction of multi-homing, and the latter will indicate the cancellation of the multi-homing. It is expected, however, that the former will often indicate an error, and the latter its removal. Either way, it will be useful to know about the registration and elimination of overlapping announcements. Some Important Notes -------------------- 1. At the time of implementation, the notification may take up to 24 hours, due to the current mirroring scheme employed in the RR. This time will be reduced when the mirroring scheme is improved. 2. Exact address space matches will be distinguished from non-exact overlaps in the notification messages. 3. After the implementation of RPSL, it will be useful to allow one or more route-sets to be specified in the "cross-nfy:" attribute in addition to the contact reference. For example, using: cross-nfy: <ContactA> <route-set1> <route-set3> cross-nfy: <ContactB> <route-set2> in an aut-num object would allow ContactA to be notified upon registration and deletion of routes overlapping the address space covered in <route-set1> and <route-set3> and ContactB to be notified with regards to route registrations with address space overlapping that covered in <route-set2>. In this way, a more selective notification scheme can be specified without adding "cross-nfy:" to every route object. Acknowledgements ---------------- Thanks to the RIPE Routing and Database working groups for lively discussions resulting in constructive input on this notification mechanism. Daniel Karrenberg was the first to mention the need for a notification mechanism in the RR. Chris Fletcher, Joachim Schmitz and Wilfried Woeber have all made essential contributions. ------------- ------------- ------------- ------------ ------------- Appendix - Some History At the January meeting of the Routing WG in Amsterdam, various possible hierarchies for authorization in the Routing Registry (RR) were considered. During the discussion, a suggestion was made that "hierarchical notification" would be useful even in cases where authority is not well defined. This suggestion enjoyed strong support of both the Routing WG and the Database WG. At the start of May 1997, a proposal was submitted to the mailing lists of the RIPE Routing and Database WG's describing a notification mechanism designed to meet the stated requirements. During the RIPE meeting in Dublin, it was agreed to that the notification mechanism should be implemented, with the following modifications: 1. Whenever a route object is submitted in the RR, a notification should be generated to the submitter if the address space overlaps with any other route object in the RR. [RIPE27 - Routing WG meeting] 2. The attribute should be named "cross-nfy:" rather than "x-notify:" to avoid any misunderstandings with respect to other conventions. In particular, mailers often interpret "X-field:" to mean "ignore this field". [private discussion Chris Fletcher] 3. If the address space covered in the route object matched the address space in another route object, be sure this is clear in the notification message. [RIPE27 - Routing WG meeting] 4. - Notifications should be sent to the appropriate contact not only if an overlap is introduce, but also when an overlap is eliminated. [RIPE27 - Routing WG meeting] 5. The "cross-nfy:" field should be available for the "aut-num:" object as well as for the routing object. If "cross-nfy:" is in the "aut-num:" object, it applies to all routes with that aut-num as origin. [RIPE27 - Database WG meeting] It has since been suggested that it would be useful if the mechanism would be extensible for the "route-set:" objects defined in RPSL (see draft-ietf-rps-rpsl-02). To make use of the route grouping functionality supplied by the "route-set:" object, we suggest the following extension be considered: 6. In the "aut-num:" object, allow "cross-nfy:" to be a multiple attribute, and in addition to specifying who should be notified, specify for which route-sets. If no route-sets are specified, then the notification will take place for all route objects with the given "aut-num:" as origin. [private discussion Joachim Schmitz]

1 0

unsubscribe
by Marko Miinalainen 10 Jul '97

10 Jul '97

unsubscribe

1 0

Routing WG Minutes - RIPE 27, Dublin
by Anne Lord 09 Jul '97

09 Jul '97

Dear All, Below are the draft minutes for the Routing WG Meeting in Dublin as compiled and agreed by Joachim and myself. Any comments, questins etc are gratefully recieved and should be sent to the list. Many thanks, Anne -- RIPE 27 : Routing WG Draft Minutes Chair : Joachim Schmitz (JS395-RIPE) Scribe : Anne Lord (AL12-RIPE) Attenders : 57 1. Preliminaries Joachim Schmitz opened the working group and asked for a volunteer scribe. Anne Lord volunteered as scribe. Review of RIPE 26 minutes The minutes of the last working group had been previously circulated to the mailing list. These minutes were agreed as final and closed. Review of actions RIPE 26 Action 22.10 : J. Schmitz Future tool development project - closed. (was discussed during the working group meeting itself) Action 25.R1 : D.Karrenberg Route aggregation analysis - open. Due to lack of time this has not been progressed. Volunteers to run scripts or do further development were asked for - they should contact Daniel Karrenberg. The present tool does slightly more than Tony Bates' aggregation report which looks at announcements being made. Daniel's tool actually emails originators with a "how to fix" mail. Action 26.R1 : RIPE NCC Add link to CIDR FAQ on RIPE web server - done. Action 26.R2 : J. Schmitz Trigger implementation of first elements of hierarchical authorisation for route objects - done. Action 26.R3 : J. Schmitz Finalise hierarchical authorisation for route objects - ongoing. Action 26.R4 : E.J. Bos Circulate URL of his analysis of routing table size - done. (ftp://ftp.surfnet.nl/surfnet/net-management/ip/nets.ps) Action 26.R5 : C. Panigl Collect reasonable route flap dampening parameter values - done. (was discussed during the working group meeting itself) Current developments Joachim reported briefly 2 working groups within the IETF that are relevant to the work of the Routing WG. * RPS - Routing Policy Systems Chairs are : Daniel Karrenberg and Cengiz Alaettinoglu http://www.ietf.org/html.charters/rps-charter.html The RPS working group wants to develop and propagate tools and methods to analyse and describe routing policies. One major project is RPSL "routing policy specification language". This is relevant for the Routing WG because they plan to switch from ripe-181 format for the routing registry to RPSL this year. The second version of an Internet draft on RPSL is already available. * RIDE - Registry Information Data Exchange Chairs are : David Kessens and Dhaval Shah This group is looking at ways of exchanging information between registries of all sorts in a unified "language". See URL for more information: http://www.isi.edu/~davidk/ride 2. Hierarchical Authorisation / Cross Notification of Route Objects in the IRR (Carol Orange) 2.1 Cross Notification A draft proposal was sent to the Database and Routing WG mailing lists in May. The proposal is essentially to make network operators aware of overlapping route announcements in the IRR. Implementation is by a new attribute in the route object called "x-notify". Using this attribute you will get notified if you submit a route object which overlaps an existing route object in the IRR or if another route object is submitted which overlaps your route object. Note - this will be an *optional* attribute. The exact syntax is documented in the draft sent to the mailing list and can be found in the mailing list archives at: ftp://ftp.ripe.net/ripe/archives/routing-wg/current. There were also some additions from the Database WG. An overview of the current state is given in the Working Documents section of the Routing WG on the RIPE web server: http://www.ripe.net/wg/routing/rwg-docs.html Discussion It was envisaged that given the way that the current IRR is mirrored (once every 24 hours), there will be delay in notification. Real time mirroring would be ideal and the software exists. However this has not yet been fully implemented as this still requires input from other RR's. Gerald Winters from Merit (representing the RADB) commented that the current mirroring has been changed to mirror more frequently. It was asked if there was a way to differentiate between exact matches and overlaps? It was commented that this could be built in to the software notification. A question was then raised as to the exact notification that takes place when an overlap/exact match occurs and as to the timing of the possibilites for notifcation and to whom. Do you for example, also notify the originator of the overlap? Should the software return a warning to the originator of overlap even without the "x-notify" attribute ? After a fairly lengthy and interesting discussion, it was agreed to go ahead with implementing the draft proposal given the following modifications which were agreed: - the submitter of the route will always be notified as to whether the object submitted was successful. Notification of overlaps can be built into the acceptance/feedback message returned to the submitter. - for deleting a conflicting object, it was agreed to notify the submitter of the conflicting object that there was no longer a conflict in the database - notifications on overlap - either for newly submitted route objects, or for deletions - will only be done for *existing* route objects if explicitly requested by the "x-notify" attribute Action 27.R1: Carol Orange, RIPE NCC To implement cross notification in the RR with modifications as agreed at the meeting of the 27th RIPE Routing WG. 2.2 Hierarchical authorisation in the RR (Carole Orange) (or "aut-num authorisation for route objects in the RR") The proposal is documented in a draft document which was previously circulated to the Database WG and Routing WG mailing lists. Agreement on this proposal is now sought so that it can be implemented. The goal of the proposal is to allow network operators who announce a route in their AS to delegate this authority to others. There has been much discussion on the mailing lists and a specific "non-goal" of the proposal is to produce an optimal hierarchical authorisation scheme for the RR. This proposal is not CIDR based; hence the change of name for the draft to avoid any confusion about CIDR based hierarchy in the proposal to "Aut-num authorisation for route objects in the RR". The proposal works briefly by the following mechanism: A "mnt-route" attribute (in former drafts called "mnt-lower") is added to the aut-num object. Currently the "mntner" object referenced determines who can add/update/delete an object associated with that aut-num (for more details see the draft which can be found at the reference above in the archives of the mailing list, or look at the Working Documents section of the Routing WG at the RIPE web server). The "mnt-route" attribute is optional and can be multiple per aut-num object. Each mnt-route attribute references it's own "mntner" object. This allows different people to maintain own routes announced. Action 27.R2: Carole Orange, RIPE NCC To implement aut-num authorisation in the RR There was some discussion over the notification mechanisms when customers change their announcements in their AS - so as to enable notification to their upstream provider. This is actually a different issue and the discussion was deferred to the mailing list due to time constraints. 3. A future tool development project (Joachim Schmitz) ftp://ftp.ripe.net/ripe/presentations/ripe-m27-jschmitz-ftdp.html Joachim briefly described some of the existing tool sets in place to help network operators with their network operations and asked whether there was a need for such a new development effort in this area to be carried out under the auspices of RIPE and if so, where would it fit into the RIPE activity plan. Possibly, such a project could fit into the slot for "new activities" taken from the 1997 expenditures budget. As background to this Joachim gave a description of the history (ish) and the functioning of the existing tools as well as the interaction with the relevant entities. ie. routers.. ISPs, IRR.... etc. Some of the tools he made mention of were the PRIDE tools eg. prtraceroute, prcheck, or the RATools eg. roe, aoe, peval, CIDR advisor.. The question was then asked: Is a new tool or software project needed ? What gaps exist in the existing toolsets? It was felt generally by the audience that the orientation should be more towards actual integrity of the data in the RIPE database, quality and consistency of the DB rather than towards new tools. Therefore, this action could be closed. 4. Report from the RIPE NCC Time contraints prevented NCC from doing CIDR report and route aggregation analysis that had previously been started. However new technical projects are ongoing and they are going to hire more people to do technical projects. The RIPE NCC welcomes any volunteers who wish to take over the production of the route aggregation analysis reports. Currently the reports are rather manually produced - mostly so in the generation of the "how to fix" emails which go out to the originators of "problems". Daniel repeated that he was quite willing to hand over the scripts if anyone wished to work on this since there are currently no spare human resources at the NCC at this point in time. There were no volunteers immediately. It was agreed however that these reports were very useful and perhaps it would be possible to at least publish a summarised report and not send the "how to fix" emails. Reports will be sent out to the RIPE working group mailing list. Since Tony Bates' report on route aggregation also contains information on European ASs it was agreed to ask him whether a copy of his report is also distributed to the general RIPE mailing list. Action 27.R3: RIPE NCC To ask Tony Bates to send a copy of his regular CIDR report to the general RIPE mailing list as well. 5. Route Flap Dampening Parameters (Christian Panigl) C. Panigl started with a summary of the BOF at the last RIPE meeting. Consensus was that we needed route flap dampening, but there was no consensus on dampening parameters: 2 camps had previously emerged: - Those in favour of "progressive" dampening with the exclusion of "golden" networks ie. root name servers.. - or "flat and gentle" where all prefixes are treated equally a la Cisco default dampening. As an action from the previous Routing WG meeting, Christian Panigl presented information he had collected about dampening parameters. As a basis for his studies, he took information about dampening parameters from the following sources: - discussions by Randy Bush a la SPRINT/ICM parameters - Tony Barbers presentation on progressive route flap dampening at UUNET UK. Christian reported on the work by Sean Donelan <sean(a)sdg.dia.com> who made investigations.. comparing /24 prefixes and /16 prefixes: /24: 65% of Routing Table accounts for 65% of all route flaps /16: 12% of Routing Table accounts for 10% of all route flaps Both groups tend to flap ~2% of the routes within the group. What is the goal of flap dampening: stable routes or shorter prefixes? It was suggested that softer "punishment" of shorter prefixes might lead to future waste of address space. Some router cpu offload has happened with progressive dampening. Excessive BGP withdrawal problem seems to be fixed in IOS 11.1(8) for Cisco routers. The assumption that the /24 is more unstable is not necessarily true given the following situation: example: reload after s/w uprade - 1x flap new s/w crashes - 1x flap reload with old s/w - 1x flap = 3x flaps within 10 minutes Then according to Randy's parameters /24 prefixes were blocked for 3.5 hours.., /22 45 minutes, /19 45 minutes, /16 less than 30 minutes. According to Tony's paramters /24 prefixes were blocked for 2hrs 45mins, /22 55 minutes, /19 55 minutes /16 less than 30 minutes. It was suggested that suppression should not start until the 4th flap in a row which corresponds to parameter value suppress = 3000 and that the maximum suppression should not last longer than 1hour (max supress <60). It was agreed that a recommendation from RIPE would be desirable. Given that the current allocation policies are expected to hold for the foreseeable future, it was suggested that all /19's or shorter prefixes are not penalised outside of the Cisco default dampening. Action 27.R4: Task Force (Tony Barber, Sean Doran, Daniel Karrenberg and Christian Panigl). To write proposal document and circulate to the RIPE rounting working group mailing list for discussion as soon as possible. 6. Reports from other WGs There was no current input from other WGs. 7. AOB Since there was no AOB the meeting was closed. Agenda ------ R I P E 2 7 D U B L I N Routing Working Group Session 21-May-97 Draft Agenda A. Preliminaries - introduction - participants' list - volunteering of scribe - agenda bashing - RIPE 26 minutes - actions from earlier meetings - current developments B. Hierarchical Authorisation/Notification of Route Objects - first implementation issues (Carol Orange) - further developments (Joachim Schmitz) - discussion C. A Future Tool Development Project (Joachim Schmitz) - an overview - discussion D. Report from the RIPE NCC (Daniel Karrenberg) E. Route Flap Dampening Parameters (Christian Panigl) - overview - suggested parameters Y. General Input from Other WGs Z. AOB Summary of Actions: ------------------- Action 25.R1: D.Karrenberg To report on the results from the route aggregation analysis on the next RIPE meeting Action 26.R3: J. Schmitz To finalize the hierarchical authorization for route objects together with the Routing WG Action 27.R1: Carol Orange, RIPE NCC To implement cross notification in the RR with modifications as agreed at the meeting of the 27th RIPE Routing WG. Action 27.R2: Carole Orange, RIPE NCC To implement aut-num authorisation in the RR Action 27.R3: RIPE NCC To ask Tony Bates to send a copy of his regular CIDR report to the general RIPE mailing list as well. Action 27.R4: Task Force (Tony Barber, Sean Doran, Daniel Karrenberg and Christian Panigl). To write proposal document and circulate to the RIPE Routing WG mailing list for discussion as soon as possible. Anne Lord, Joachim Schmitz, 6 June 1997.

2 1

None
by Remy Longueve 20 Jun '97

20 Jun '97

help

1 0

RIPE-158, the test traffic project design note is ready.
by Henk Uijterwaal (RIPE-NCC) 03 Jun '97

03 Jun '97

Dear All, The final version of the design note for the RIPE-NCC test traffic project is ready and can be found on the test-traffic home page: http://www.ripe.net/test-traffic This page also has copies of the slides shown at the Dublin RIPE meeting. Links to the note in the usual places as well as a copy on the ftp will appear later today. If you have any questions about the note or the project, please do not hesitate to contact us. Kind regards, Henk Uijterwaal ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(a)ripe.net RIPE-NCC WWW: http://www.ripe.net/home/henk Kruislaan 409 Phone: +31.20.5925022 NL 1098 SJ Amsterdam Fax: +31.20.5925090 The Netherlands Home: +31.20.6651962 ------------------------------------------------------------------------------ %DCL-E-NOCFFE, unable to locate coffee - keyboard input suspended.

1 0

BGP dampening
by Tony Barber 29 May '97

29 May '97

Subsequent to the last routing wg seminar I have just been looking at out parameters for bgp dampening. To summarise What we (1849) currently have : 1- don't dampen any routes we use for special purposes 2- don't dampen any root nameserver routes 3- Heavy dampening on /24 and greater (>24 filtered anyway) 4- not so heavy dampening on /22 and /23 5- All else using default for standard protection. I am seriously think of adding 192.* into 3 above. People should be renumbering !!! Parameters to go with above are : ! Savage dampening of all networks which have a mask of ! /24 and above. These are supressed into a datastructure ! with a half life of 45 minutes, only re-use when reaches 250 ! Max outage of 255 minutes. no route-map expo-flap-dampen permit 10 route-map expo-flap-dampen permit 10 match ip address 181 set dampening 45 250 2000 255 ! dampen /23 /22 ! half life is now 25 minutes and reuse at 650 no route-map expo-flap-dampen permit 20 route-map expo-flap-dampen permit 20 match ip address 182 set dampening 25 650 2000 60 We should redress these figures in light of discussions last week. Personally I think that the concept is about right as we have it, we just need to agree the figures/times. It means that all major aggregated space is not really affected any more than it was before. In fact we could improve it as per below. Should we try 3000 as the suppress at figure so that minimum of 4 flaps is required? The max-suprress time needs to be changed to 60 max as we said. Hence new figures would be :::: ! /24 and above. set dampening 30 750 3000 60 ! dampen /23 /22 set dampening 20 1000 3000 45 all else default which is set dampening 15 750 2000 30 but change the minimium count to 3000 and reuse at to 1000 --Tony

2 1

The Cidr Report (fwd)
by Tony Barber 29 May '97

29 May '97

5 6

Re: The Cidr Report (fwd)
by zsako＠banknet.net 27 May '97

27 May '97

> From owner-routing-wg(a)ripe.net Tue May 27 11:52:28 1997 > From: Tony Barber <tonyb(a)pipex.net> Tony, I have checked at random the network below: > > 148.212.1.0/24 | AS1292 | ITESM Campus -- Monterr | Universidad Autonoma de > > 148.212.2.0/24 | AS1292 | ITESM Campus -- Monterr | Universidad Autonoma de > > 148.212.3.0/24 | AS1292 | ITESM Campus -- Monterr | Universidad Autonoma de > > 148.212.4.0/24 | AS1292 | ITESM Campus -- Monterr | Universidad Autonoma de > > 148.212.5.0/24 | AS1292 | ITESM Campus -- Monterr | Universidad Autonoma de > > 148.212.6.0/24 | AS1292 | ITESM Campus -- Monterr | Universidad Autonoma de > > 148.212.7.0/24 | AS1292 | ITESM Campus -- Monterr | Universidad Autonoma de > > 148.212.8.0/24 | AS1292 | ITESM Campus -- Monterr | Universidad Autonoma de > > 148.212.9.0/24 | AS1292 | ITESM Campus -- Monterr | Universidad Autonoma de > > 148.212.10.0/24 | AS1292 | ITESM Campus -- Monterr | Universidad Autonoma de > > 148.212.11.0/24 | AS1292 | ITESM Campus -- Monterr | Universidad Autonoma de > > 148.212.12.0/24 | AS1292 | ITESM Campus -- Monterr | Universidad Autonoma de > > 148.212.13.0/24 | AS1292 | ITESM Campus -- Monterr | Universidad Autonoma de > > 148.212.14.0/24 | AS1292 | ITESM Campus -- Monterr | Universidad Autonoma de > > 148.212.15.0/24 | AS1292 | ITESM Campus -- Monterr | Universidad Autonoma de > > 148.212.16.0/20 | AS1292 | ITESM Campus -- Monterr | Universidad Autonoma de > > 148.212.32.0/20 | AS1292 | ITESM Campus -- Monterr | Universidad Autonoma de > > This kind of non-aggregation is what is really hammering the routers on > the Internet. > > Maybe we at RIPE need to give some serious thought about pan european > filtering on address space ? > > i.e nothing > /24 > Only natural 'old class B's' > ?? > > --Tony > zsako/banknet $ whois -h whois.ra.net 148.212.1 route: 148.212.0.0/16 descr: Universidad Autonoma de descr: Coahuila descr: Jose Cardenas e Hiidalgo s/n descr: Col. Republica Ote. descr: C.P. 2500 descr: Saltillo descr: Coahuila descr: MEXICO origin: AS1292 comm-list: COMM_NSFNET advisory: AS690 1:1800 2:1239(144) 3:1239(218) mnt-by: MAINT-AS1292 changed: nsfnet-admin(a)merit.edu 950506 source: RADB route: 148.212.0.0/16 descr: UADEC origin: AS1292 advisory: AS690 1:1800 2:1239(144) 3:1239(218) notify: hostmaster(a)sesqui.net mnt-by: SESQUINET-MAINT-MCI changed: sob(a)sesqui.net 950426 source: MCI > This kind of non-aggregation is what is really hammering the routers on > the Internet. In this particular instance there is no doubt you are right. The RRs also show a difference between what is announced and what is registered. > Maybe we at RIPE need to give some serious thought about pan european > filtering on address space ? > > i.e nothing > /24 > Only natural 'old class B's' > ?? I may agree with the first part (nothing longer than /24), however I feel it would not be wise to filter based on "natural" size of networks. This would prevent us from using the "Class B" address space in the same manner as any other public address space. The same approach caused the problems with 39/8, as far as remember... I think the RIPE NCC may want to allocate sometime in the future from the "Class B" address space, just as we now have allocations from 62/8. Filtering on "natural" size would make this impossible in the case of small registries. A better aproach would be in my view to filter based on RR information (like ANS). I must admit this latter approach is much more difficult to implement and at the same time it does not solve the problem of people also registering crazy routes (not only advertising them). :( Regards, Janos

1 0