- routing-wg - mailman.ripe.net

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

draft agenda routing wg ripe 27
by Schmitz＠RUS.Uni-Stuttgart.DE 15 May '97

15 May '97

Dear all, please find enclosed the draft agenda of the routing wg session at RIPE 27, Dublin. Additions, ideas, changes welcome! Regards Joachim ----------- 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 ------------

1 0

Hierarchical Authorisation in the RR
by Carol Orange 15 May '97

15 May '97

Hi again, Here is another brief proposal for your perusal. This time for an implementation of hierarchical authorization in the Routing Registry. The mechanism described below will implement a hierarchy in the RR for which I believe there is consensus. The ideas in the proposal below were sifted from discussions which took place on the <routing-wg(a)ripe.net> mailing list and in the Routing WG meetings at RIPE-25 and RIPE-26. Please review this if you have time. We are hoping to have a go ahead on this from the Routing and Database WG's at or shortly after RIPE-27. Greetings, Carol Orange RIPE NCC -------------------------------------------------------------------- Hierarchical Authorisation in the RR Proposal for an Implementation Carol Orange, May 1997 At the January meeting of the Routing WG in Amsterdam, various possible hierarchies for authorization in the Routing Registry (RR) were considered. Whereas extensive discussion took place on the extent to which authority can be established in the RR, there was clear agreement that the maintainer of an AS should have authority over what routes are announced with a given aut-num in the "origin:" attribute. In the following, we specify an implementation to support the authority of "aut-num:" maintainers to determine who can announce routes under their AS. The mechanism can be extended as the need arises and consensus on other forms of authorization is achieved. For more information on the discussions leading up to this proposal, see: http://www.ripe.net/wg/routing/haro-d.html. Implementation -------------- If you (or your organization) manages an AS, then you should have authority over the routes announced in your AS. This can be implemented if we: a) add a "mnt-lower:" attribute to the aut-num object b) allow routes to be announced with a given "origin:" by those given authority as defined in the mntner object specified in the "mnt-lower:" attribute of the aut-num object. Example ------- If we add a "mnt-lower:" attribute to the aut-num object of the RIPE NCC, then only those who know what peEw8Gb4xBNqI encrypts can add and remove routes originating in AS3333. ---- aut-num: AS3333 ... mnt-lower: AS3333-MNT ... ---- mntner: AS3333-MNT descr: RIPE-NCC Maintainer ... auth: CRYPT-PW peEw8Gb4xBNqI ... ---- route: 193.0.0.0/23 descr: RIPE-NCC origin: AS3333 ... Summary ------- Other forms of hierarchical authorization and notification can be implemented in the future if a well defined hierarchy can achieve consensus. To provide some initial functionality which may meet the needs of many RR users, we propose to implement the above in the short term.

2 2

X-Notification in the RR
by Carol Orange 15 May '97

15 May '97

Hi all, The following is a proposal for a cross notification mechanism in the Routing Registry. I post it for your perusal and hope to discuss it during the Routing WG meeting in Dublin. The initial suggestion was made by Daniel Karrenberg at the Routing WG meeting in January, and discussions with Joachim Schmitz and Wilfried Woeber have helped me work it into the following proposal. Such a mechanism was given a high priority by those who participated in the recent RIPE Database priority survey, so we are hoping to reach consensus on this at or shortly after RIPE-27. Greetings, Carol Orange RIPE NCC ---------------------------------------------------------------------- Cross Notification in the Routing Registry A Proposal Carol Orange, May 1997 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 enjoys strong support of both the Routing WG and the Database WG. 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 RR. Route Announcement Notifications in the RR ------------------------------------------ Suppose you announce a route in your address space covering some /24. It may be useful when you make the announcement, to know that the /24 has already been announced in another AS. Likewise, should the user of that address space later decide to become multi-homed, it may be interesting to know that as well. Moreover, overlapping routes are often unintentionally announced in a single AS. In all of these cases, it would be useful to get a notification from the 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] [ ] Suppose we add a new field called "x-notify:" (cross-notify) which a) can contain either + a NIC-handle pointing to a person or role object, the email address of which will get the notification; or + a mntner ID pointing to the maintainer who will be notified b) is optional The contact in "x-notify:" will receive an e-mail whenever + a route is announced with overlapping address space + the address range in the route being added (with the "x-notify:" attribute) overlaps any address space currently announced in the RR. Issues ------ Does this cross notification satisfy the needs of network operators? Due to the global nature of the RR, some effort will be involved to provide notifications in a timely manner. What is an acceptable upper bound for cross notifications to be sent out? Using a NIC-handle or mntner for notification is different than the traditional e-mail address. However, it simplifies data maintenance for users significantly.

1 0

list
by Ivan Lambov 16 Apr '97

16 Apr '97

list

1 0

(no subject)
by Dimitrios Chrysaidis 10 Apr '97

10 Apr '97

subscribe

1 0

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

04 Mar '97

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

2 1