- routing-wg - mailman.ripe.net

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

subscribe
by kkinsell＠telecom.ie 28 Feb '97

28 Feb '97

subscribe

1 0

route obj & notifications
by Schmitz＠RUS.Uni-Stuttgart.DE 14 Feb '97

14 Feb '97

Dear colleagues, yes, it is me again ;-) asking for comments on another element of hierarchical authorisation for route objects: The idea is to use a prefix based hierarchical scheme just as it is used for inetnum objects. However, it turned out that there are several difficulties in it. So, to get started the consensus at the wg session was: *not* to enforce a prefix based hierarchical scheme until these difficulties are solved, but instead generate notifications only. There are several proposals out there for notifications - to notify only if it is requested (by adding "notify" attributes to objects) - to leave inetnum objects out for the time being until their relation to route objects is clearly defined - notifications should only be done for creation of route objects not for changes or deletions (to prevent mail floods) - probably, the creator of route objects should also be notified of notifications for coordination purposes What are your feelings about this? Yes, no, maybe, missing items? Your comments are welcome! For further reference read/attack/tear apart/abuse the compilation at http://www.ripe.net/wg/routing/haro-d.html Regards Joachim _____________________________________________________________________________ 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

route & aut-num objects
by Schmitz＠RUS.Uni-Stuttgart.DE 14 Feb '97

14 Feb '97

Dear colleagues, let's start with a very easy thing near to solution with hierarchical authorisation for route objects: the relation to aut-num objects. A route object references several other objects. Important to us are the references to the maintainer and the aut-num object (both are mandatory attributes of the route object): route: [mandatory] [single] descr: [mandatory] [multiple] origin: [mandatory] [single] ----> points to aut-num object ... mnt-by: [mandatory] [multiple] ----> points to mntner object changed: [mandatory] [multiple] source: [mandatory] [single] The aut-num object also contains a mandatory reference to a maintainer object. Up to now, the maintainers referenced in route object and aut-num object of same origin need not be the same. For hierarchical authorisation it would be nice to introduce a "mnt-lower" attribute in the aut-num object defining which maintainers may create route objects for the AS of the corresponding aut-num object. This allows control of one AS which parties may generate route objects with its origin. We already had consensus in the wg session that this is needed but did not yet decide precisely how to do it. The idea of using a "mnt-lower" attribute came up and I think it is easiest to implement. If there are no objections I will hand on the above proposal for imple- mentation in the database software in two weeks. For further reference read/attack/tear apart/abuse the compilation at http://www.ripe.net/wg/routing/haro-d.html Regards Joachim _____________________________________________________________________________ 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