May 1997 - routing-wg - mailman.ripe.net

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