1st draft minutes of Routing WG session at RIPE 26

 Here are the 1st draft minutes of the Routing WG session at RIPE 26.
 Thanks to Chris Fletcher for keeping track of the major points
 during the session! Maybe, some of the URLs need adaptation as the
 presentation become available on the RIPE FTP-Server.

 Comments, input, and improvements to the draft minutes are welcome
 (but please keep discussion of topics separate from the minutes
 themselves, thank you)

     Joachim

-----

     --      1.   D  R  A  F  T        --

             RIPE 26, Amsterdam
           Routing Working Group
     Report of Meeting, 20th January 1997

     --      1.   D  R  A  F  T        --

A. Administrative Issues

   Joachim Schmitz, Chairman, presided and welcomed people to the meeting.
   There were 95 attenders. Chris Fletcher took minutes.

   The draft agenda circulated in the previous week was agreed. A copy is
   displayed at the end of this summary. There were no additions or changes
   to the minutes of the RIPE 25 Routing WG session. A short overview of
   open actions was given.

   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
   is still open. It will be pursued after the current meeting.

   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
   According to the result of the investigation no official additions by
   the Routing WG are needed. Therefore, the WG agreed to close this action.
   However, it was felt that further distribution of knowledge about CIDR
   is needed and therefore a pointer to the CIDR FAQ location should be
   included on the Routing WG pages at the RIPE NCC weg server.

   New Action 26.R1 on the RIPE NCC
      To add a link on the RIPE web server from the Routing WG pages
      to the CIDR FAQ location

B. Hierarchical authorisation for route objects (J.Schmitz)

   One major topic of this session was the discussion on hierarchical
   authorisation for route objects. There was already some discussion on
   the mailing list regarding various issues involved. To continue with
   the discussion J.Schmitz compiled the current state in a presentation.
   The transparencies of the presentation are available at
   ftp://ftp.ripe.net/ripe/presentations/ripe-m26-jschmitz-haro.html
   Based upon this several of the open issues were discussed in the WG
   session.

   Last year improvements to authorisation during the interaction with
   the database were discussed. One of the elements is *hierarchical*
   authorisation and the first implementations of it were done for inetnum
   objects and domains. Up to now there is no hierarchical authorization
   scheme for route objects. Following the same reasoning as for inetnum
   objects - to protect the objects against unauthorized changes - there
   definitely is a need to apply hierarchical authorisation also to route 
   objects; route objects in the RIPE database are already used by some
   ISPs to build configuration elements for their routers. Obviously, this
   calls for stronger protection.

   The route objects do not stand alone. They do have relationships to
   other objects in the database

   * Relation to the autnum object
     AS numbers constitute routing entities defined in the autnum object.
     They are closely related to routing and from a logical point of view
     are hierarchically higher than route objects. However, they form a
     flat space of numbers and a hierarchy among themselves is difficult
     to apply. Moreover, autnum objects in the current version of the
     database do not point to route objects making it difficult to implement
     a top-to-down search mechanism from autnum objects to route objects.
     Therefore, some hierarchical authorisation scheme starting from the
     autnum objects seems to be unapplicable on first sight.
     Yet, route objects point to two other objects at the same time, both
     pointers being mandatory: first they point to corresponding autnum
     objects via the "origin" attribute, and in addition a maintainer must
     be specified. Interesting enough this maintainer needs not be the same
     as the maintainer specified in the autnum object allowing creation of
     route objects for some AS using a completely independent maintainer.
     Obviously, there should be a possibility to prevent it introducing
     a hierarchical scheme: the proposal is to allow "mnt-lower" attributes
     within autnum objects defining which maintainers may create route objects
     for the AS of the corresponding autnum object.

   * Relation to inetnum objects
     Several people are not happy about the fact that there is no reference
     to address allocation for route objects because address space and its
     routing are somehow related. There are proposals to make route objects
     dependent on inetnum objects. The big advantage of such a scheme is that
     there will be no routes without allocation of address space which is a
     very appealing approach! However, it is not at all applicable to pure
     routing registries. Therefore, a dependency of route objects on inetnum
     objects seems to make the overall handling too complicated. Establishing
     a mere combination of address space ownership and route objects might be
     more easy. This may be (and in most cases already is) done somehow by the
     maintainer object. However, it is again not applicable to pure routing
     registries. Moreover, ownership and routing often differ, and changes in
     routing may demand changes in inetnum objects. In general, there are also
     many more inetnum objects than route objects (because of CIDR) which
     makes the relation again more complicated. There also is the opinion that
     the philosophy of the database should be to mirror the real world. In the
     real world advertised routes are completely controlled by an AS making
     other authorisation irrelevant. No policy should be enforced which does
     not exist in the real world. Maybe, consistency can be achieved through
     notification to flag discrepencies.
     Obviously, the relationship is difficult and there was not yet any
     consensus on how to deal with it. The problems might be solved in a
     unified distributed global registry but there is no immediate solution.
     More discussion is needed.

   * A prefix based hierarchical scheme
     With inetnum objects in the database a prefix based hierarchical scheme
     is used making shorter prefixes hierarchically higher than longer ones,
     controlling longer prefixes below them. This scheme could also easily
     be applied to route objects. Its big advantage is that already a working
     mechanism exists. However, there are also several problems in it:
     o To make authorisation work some starting point in form of top level
       route objects must be created in each registry in order to prevent
       that anybody may gain control of the whole tree of route objects.
       These top level route objects are kind of artificial because they do
       not reflect any routing at all. Starting points are especially diffi-
       cult to apply to the swamp 192.x.
     o If a hierarchical authorisation based on prefix length is *enforced*
       only one route object per IP-range would be allowed. This is different
       from what can be found in usage of the database today. It will cause
       difficulties in several cases:
       - Multihoming today is expressed by several route objects of differing
         origin. If only one route object is allowed multihoming could not be
         expressed in the database. This again might be circumvented by intro-
         ducing multiple origins per route object which again raises the
         question of authorisation by maintainers.
       - Relatively often specific IP-subranges are routed by another AS than
         a given IP-range. If the maintainer of the IP-range allows handling
         of IP-subranges in general (by specifying a corresponding "mnt-lower"
         attribute), any IP-subrange may be captured by the maintainers given
         in the mnt-lower attribute. This may not be intended. A possible
         solution might be in extending the usage of the "hole" attribute
         being already an optional attribute of the route object: holes
         could be excluded from hierarchical authorisation down to the next
         longer prefix specified.
       - If a customer changes from one ISP to another the origin of the
         corresponding route object changes, too. To facilitate the change,
         currently for a few weeks both ISPs keep a route object of the same
         IP range with their AS as origin. This is especially important if
         they generate elements of their router configurations from route
         objects in the database. The problem is similar to multihoming
         however with the focus on transition of maintainers.
     o Even though route objects could be secured by hierarchical authorisation
       in one registry they are not necessarily protected in another registry
       because data in different registries do not depend on each other. As
       a consequence duplication not only of the data but also of the specific
       hierarchy is indispensable.
     Obviously, enforcement of a prefix based hierarchical authorisation causes
     troubles which can not be solved within a short time.

   * A temporary suggestion
     The prefix based scheme is very valuable and should be applied somehow.
     A temporary suggestion is to apply it but not to enforce it, just to
     notify. The advantages are that it is built upon a working mechanism
     and nothing much changes. A starting point in form of top level route
     objects is not needed and duplication in several routing registries has
     no consequences. Still several route objects of differing origin per IP
     range are allowed and conflicts with current practice in using the data-
     base do not occur. Yet, a simple notification does not solve conflicts.
     The "owner" can not remove conflicting records - but with conflicts two
     parties exist and both must resolve the problem together. The notification
     does not solve the problem in itself but it will flag it to exist and
     that a solution is needed.
     However, objects in one registry remain unsecure if hierarchical authori-
     sation is applied in another and in the end this is no real solution.
     Nonetheless, this is a slight improvement to the current situation which
     is upwards compatible because notification is also needed if authorisation
     is enforced in the future.
     There was a general consensus that pure notification as a temporary
     solution should be applied. Later, on the way to enforcing authorisation
     some kind of approval mechanism could be probably installed if errors
     occur which come from insufficient authorisation for the action requested.
     With notification several new questions arise:
     - To keep notification traffic low it might be useful to notify only if
       it is requested by an object hierarchically higher. Currently, in the
       database notification only occurs if requested. Because of the impor-
       tance of route objects one might choose to notify for overlapping routes
       in all cases.
     - It might be useful to trigger notification by route objects only. To
       take the importance of inetnum objects into account one might think
       of notifications in cases of inetnum objects of overlapping address
       space.
     - It might be useful to notify the creator of route objects of the other
       notifications for coordination purposes.
     - Up to now notification is done only for the creation of objects, not
       for changes or deletions. To prevent floods of mail this should be
       kept.

   In general, several issues could be clarified but there remains quite a
   lot to do. The items where consensus was found should be implemented soon
   and discussion on the other items (still the majority) must continue.

   New Action 26.R2 on Joachim Schmitz
      To trigger database implementation of first discussion results
      from hierarchical authorization for route objects
   New Action 26.R3 on Joachim Schmitz
      To finalize the hierarchical authorization for route objects
      together with the Routing WG

C. Report on route aggregation by the RIPE NCC (D.Karrenberg, RIPE NCC)

   The report on route aggregation could not be given because the statistics
   mechanism was offline for two months. Therefore, nothing new can be re-
   ported. DK was asked to fix it and to report again at the next RIPE meeting.

   Action 25.R1 on Daniel Karrenberg/RIPE NCC
      To report on the results from the route aggregation analysis on
      the next RIPE meeting

   There is other data available from SURFnet showing growth of the Internet:
   New Action 26.R4 on Eric-Jan Bos
      To circulate the URL of his analysis of routing table size on the
      mailing list
   This has already been done - the URL is
   ftp://ftp.surfnet.nl/surfnet/net-management/ip/nets.ps and it contains
   data on the growth of the global routing table since 1 January 1994.

D. New Developments of RATools (D.Kessens, ISI)

   The RATools as part of the Routing Arbiter Project of Merit and ISI are a
   valuable means to make use of registry data and to compare it to the real
   world. David Kessens (formerly RIPE NCC, now at ISI) gave an overview of
   new developments in version 3.4.x and 3.5.1 of the RAToolSet. There were
   noticable enhancements for RtConfig, a tool which allows automatic gene-
   ration of router configuration elements from registry data. Moreover, the
   aoe (autnum object editor) is now in production. The overview of the
   RAToolSet news is available as
   ftp://ftp.ripe.net/ripe/presentations/ripe-m26-davidk-ratools.ps.gz
   and contains information about where to find the software (WWW, ftp).

   In a second presentation David Kessens introduced the aoe (autnum object
   editor). With this new tool autnum objects can be automatically generated
   for registries. Data of neighbors and for the policies can be taken from
   existing databases, from real life BGP dumps, or entered manually inclu-
   ding heuristics. It has a user friendly interface including a GUI (based
   on X.11 Tcl/Tk), an "on-line" help, and it makes updates to IRRs easy.
   The functionality of aoe was explained by various examples and it turns
   out that aoe can make work with autnum objects much easier. In the future,
   RPSL will also be supported (up to now aoe generates RIPE-181++ syntax),
   cooperation with other tools will be implemented, and more and better
   heuristic methods will be included. The aoe shares the same requirements
   with the RAToolSet (which it is part of) being
   - gcc 2.7.2 or later
   - libg++ 2.7.2 or later
   - Tcl 7.5/Tk 4.1 or later
   in version 3.5.1 of the RAToolSet. The presentation of aoe is available as
   ftp://ftp.ripe.net/ripe/presentations/ripe-m26-davidk-aoe.ps.gz

   During the RIPE meeting a test installation of the RA ToolSet was
   accessible to the participants.

E. Report on routing stability (G.Winters, Merit)

   Since routing stability has become a major issue in the Internet it was
   very interesting to have a presentation of recent measurements done by
   Merit. Gerald Winters of Merit showed results from Craig Labovitz which
   he (Craig) had presented at the May '96 Nanog meeting supplemented by
   some newer studies. The presentation of Craig Labovitz is available as
   ftp://home.merit.edu/pub/users/labovit/talks/nanog-9605/instability.ps
   and further information may be found at http://nic.merit.edu/~ipma/

   The presentation was very interesting and caused a lot of discussion.
   Topics from the presentation and the discussion are comprised below:
   As it turns out there are peaks of close to 10 million BGP announcements
   and withdrawals in a given day with more than 100 BGP updates per second.
   Major providers are not major causes of instability while individual ISPs
   and end-sites can have a disproportionate effect on routing stability.
   It is interesting that BGP traffic is a function of weekday/weekend and
   even of the time of the day. A correlation to the amount of traffic is
   speculative, however there might be an indication of some correlation to
   maintenance work. Up to now there has been no analysis whether long holi-
   days show in the statistics as well.
   For real big instability incidents (abnormal events) Merit people called
   the originators of the instability to find out the reason. From a relatively
   low number of 36 incidents it turned out that
   - links are nearly no problem
   - hardware is rarely a problem (but approx 3 times as often as link
     problems)
   - software and configuration problems cause more than 50% of BGP updates
   However, this does not give much indication on the reasons for the general
   instability below major incidents.
   A graph showing the number of BGP announcements (normalized to the number
   of routes) seemed to indicate that the instability grows because a linear
   regression of the data showed an increase. However, in the discussion it
   was noted that there was a very large variance in the samples taken and a
   linear regression may not be justified and therefore misleading. Moreover,
   the growth in complexity of the Internet may introduce another effect:
   more routes are seen because of an increasing number of peerings. There-
   fore, a mere normalisation of the number of BGP announcements to the num-
   ber of routes may not be sufficient. In the end (because the increase was
   not very steep), there might be no indication for a growing instability
   at all.
   A more elaborated analysis of the BGP announcements shows that most of
   the BGP updates are redundant or unnecessary with a large percentage of
   duplicates. 99% of the BGP traffic is withdrawals. One reason for this
   might be that withdrawals are *always* sent to all peers and accepted
   there regardless of outgoing or incoming filters. It is suspected that
   this behaviour is actually wanted because especially if a new filter is
   set up, previously valid routes should be withdrawn anyway.
   Another interesting analysis showed the frequency of BGP updates for the
   same prefix and origin. There were pronounced peaks at 30sec intervals.
   A close relation to IGP updates is suspected. However, in the discussion
   it was also mentioned that with Cisco routers the default keepalive on
   lines is 10sec and the line protocols go down after three missed keep-
   alives which is 30sec. If immediate BGP update is configured (which is
   the default) then the corresponding routes are immediately withdrawn.
   Obviously, there are other sources for this specific frequency and a more
   detailed analysis should be performed.
   It was a bit disappointing to have no statistics on the instability
   depending on the prefix length. With all the data collected an analysis
   like this should be possible.
   Recommendations to improve routing stability were
   - to use BGP route flap dampening
   - to aggregate as much as possible using CIDR
   - to filter
   As already seen at previous RIPE meetings route flap dampening is an impor-
   tant topic which has been dealt with before. A BOF on this topic was
   announced (see below).

Y. General input from other WGs

   There was no current input from other WGs.

Z. AOB

   Christian Panigl announced that a BOF session on route flap dampening
   was planned. The minutes of this session are included here.

   <at this place the BOF minutes will be included>

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 25.R1 on Daniel Karrenberg/RIPE NCC
      To report on the results from the route aggregation analysis on
      the next RIPE meeting
   Action 26.R1 on the RIPE NCC
      To add a link on the RIPE web server from the Routing WG pages
      to the CIDR FAQ location
   Action 26.R2 on Joachim Schmitz
      To trigger database implementation of first discussion results
      from hierarchical authorization for route objects
   Action 26.R3 on Joachim Schmitz
      To finalize the hierarchical authorization for route objects
      together with the Routing WG
   Action 26.R4 on Eric-Jan Bos
      To circulate the URL of his analysis of routing table size on the
      mailing list
   Action 26.R5 on Christian Panigl
      To collect reasonable route flap dampening parameter values and
      to present them at the next RIPE meeting in the Routing WG


Agenda
------

- Routing Working Group Meeting -
           Agenda for
  RIPE-26, Jan 1997, Amsterdam

A. Administrative issues (J.Schmitz)
   - volunteering of the scribe
   - agenda bashing
   - minutes from last meeting
   - open actions

B. Hierarchical authorisation for route objects (J.Schmitz)
   - current state
   - discussion

C. Report on route aggregation by the RIPE NCC (D.Karrenberg, RIPE NCC)
   - in general
   - route aggregation

D. New Developments of RATools (D.Kessens, ISI)
   - new tools
   - aoe

E. Report on routing stability (G.Winters, Merit)
   - measurements by Merit
   - route flap dampening

Y. General input from other WGs

Z. AOB

----
_____________________________________________________________________________

 Dr. Joachim Schmitz                                   schmitz@localhost
 DFN Network Operation Center
 Rechenzentrum der Universitaet Stuttgart              ++ 711 685 5553 voice
 Allmandring 30                                        ++ 711 678 8363  FAX
 D-70550 Stuttgart                                     FRG (Germany)
_____________________________________________________________________________