minutes of routing wg session RIPE24 (22-04-96)

                         Routing WG  M I N U T E S

 Monday, 22-04-96
 Start:    14:15
 End:      15:45
 Chairman: Willem van der Scheun
 Scribe:   Joachim Schmitz, DFN-NOC
 Participants: 77

 The agenda for this session was distributed on the mailing list on 19. April
 (* added during agenda bashing):

    1. Opening
       This includes finding a minutetaker, so please prepare
       to volunteer!
    2. Minutes of last meeting (RIPE22, October 1995)
       Action points from last meeting
    3. Agenda bashing
    4. Routing Registry Progress
            RIPE NCC, appr. 15 minutes
    5. Routing table growth
            Daniel Karrenberg, appr. 45 minutes
   *5a.Exponential route flap dampening
            Peter Lothberg
    6. Routing WG future activities, input to RIPE NCC
            appr. 15 minutes
    7. AoB

 1. Opening

 The prelimenaries were done within short time (passing participant list
 around, looking for a scribe)

 2. Minutes of last meeting, Action points

 The minutes of the last meeting were accepted without changes. Then, the
 actions from earlier meetings were discussed.
 - Action 22-8 on RIPE NCC/Merit:
      To make the RADB publicly available on the the RIPE FTP server (if Merit
      concords)
   status: DONE
 - Action 22-9 on RIPE NCC/ANS:
      To find a final date when to give up advisory tags.
   status: DONE. Actually, the tags have been ignored by ANS since Nov 1995.
 - Action 22-10 on Daniel Karrenberg:
      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
      concensus on it
   status: OPEN (not yet started)
      Transfered to chairman Willem van der Scheun
 - Action 22-11 on Daniel Karrenberg:
      Based upon the focus found in the Routing WG, to prepare a draft paper
      for the new project and to present it at the next RIPE meeting in January
   status: OPEN (depends on previous action)

 3. Agenda Bashing

 Then the audience was asked for any changes on the agenda. Willi Huber asked
 how to deal with organisations which want to become multihomed. This topic was
 discussed under the AoB item of the agenda at the end of the meeting. A short
 presentation by Peter Lothberg was added on a suggestion for exponential route
 flap dampening after "5. Routing table growth".

 4. Routing Registry Progress

 Daniel Karrenberg of the RIPE NCC reported on the progress of the routing
 registry. It is found to be in good shape, especially since
 - for the registration of new ASs, submission of a routing policy has become
   compulsory. This data is actually used (by ANS, BT, and possibly others)
   to generate filters
   ANS added on 14.May 1996 (Curtis Villamizar) that prior attemtps to automate
   generation of policies for new ASs failed. The reason is missing data in the
   registries (aut-nums, routing policies, insufficient as-macros). At this
   point ANS still relies on notification from adjacent providers.
 - the effort to reduce redundancies and remove old data is continuing. This
   is most notable on the route objects. Their overall number in the RIPE
   database declines.
   ANS added on 14.May 1996 (Curtis Villamizar) that they have code to clean
   up prefix based policy exceptions.
 However, the RIPE NCC is caught again by the growth of the Internet and its
 resources did not permit to handle all new items or reports on errors in the
 database software.

 Steven Bakker then asked about the current state of the extended as-in, as-out
 attributes. As it turned out these attributes have not proceeded beyond the
 draft state and are not yet implemented in the database software. Moreover,
 the current PRIDE-tools won`t work if the extensions are used in the database.
 Obviously, quite some effort must be put into it. However, to express certain
 routing policy elements the extension are indispensable. No workaround exists
 in the current implementation.
 The topic was transferred to the database working group. A presentation will
 be given there, showing the development of the database software in the last
 months as it was focused on authorization. The presentation will include
 future plans regarding further elements for the database.

 5. Routing table growth

 The main presentation in this meeting of the routing working group was
 given by Daniel Karrenberg on the growth of the routing tables. It will be
 made available on the RIPE FTP-server as soon as DK has returned from vacation
 (planned as ftp://ftp.ripe.net/ripe/presentations/ripe-m24-dfk-Less-routes).
 Part of the data may also be found in the quarterly report Q1, 1996 (URL
 ftp://ftp.ripe.net/ripe/docs/ripe-135.txt or ripe-135.ps).

 As DK pointed out it has become a well known problem that ISPs which do full
 routing have run into severe problems regarding the size of routing tables and
 routing stability. This lead to ideas of quite repressive prefix filtering
 (e.g. by Sprint not accepting smaller prefixes than /19). However, Europe is
 in a good shape at least with respect to 193/8 and 194/8 because allocation of
 address space was done in aggregatable chunks from the start and there are
 many good netizens. To illustrate this DK showed some statistics he did for
 the combined 193/8 and 194/8 address space from the routing table of the RIPE
 border router. He finds that
 - the total address space increases (doing no DNS analysis but simply counting
   each /24 as if it contained 256 hosts, /23 as 512 hosts etc). This conforms
   with allocation
 - the total number of routes decreases. This is due to aggregation.
 - the number of redundant routes also decreases. Currently, there are only
   approximately 12% redundant routes (but roughly 25% a few months ago). RIPE
   NCC started posting information on redundant routes per AS a few months ago
   and the response from ISPs is good. Actually, aggregation requests from the
   NCC were often accepted. Data on redundant routes is available on the RIPE
   FTP-server (ftp://ftp.ripe.net/ripe/less-routes/*).
 Yet, the definition of when to treat a route as being redundant is not easy.
 Up to now a route has been defined as redundant if it was possible to build
 a less specific aggregate which contains this more specific route, based upon
 origin and AS-path information. However, there is a general feeling that many
 more redundant routes exist if origins or other information could be analysed
 more thoroughly.
 For the time being DK wants to
 - automate the analysis possibly allowing near real time analysis and use a
   dedicated machine from which to collect the data
 - educate and explain to more ISPs why this effort is valuable and needed,
   maybe even trying to give hints on router configuration
 - convince people possibly by peer pressure to really adopt the changes
   necessary on their side
 Future development should include refinement of the definition of equivalent
 or redundant routes, respectively, and probably extension of the analysis
 to the net outside Europe.

 These topics were vividly discussed by the audience. Willfried Woeber asked
 how "outside Europe" could be defined - whether geographically or by address
 space. DK answered that it was not yet specified, but by definition European
 routes are in 193/8, 194/8. WW also wants to have the effort extended to the
 192/8 block, at least for the allocations done in Europe and asked whether
 this was a political of technical problem. DK did not see real problems but
 estimated that problems could arise because on the RIPE NCC border router not
 all US routes are seen which might make analysis beyond Europe more difficult.

 Blasco Bonito wanted to push the education element and asked whether a FAQ on
 this topic existed. Actually, Hank Nussbacher has already started the CIDR
 FAQ. Probably, some additions should be made. An action was put on the chair-
 man to investigate the status of the CIDR FAQ and see whether additions are
 needed, probably by triggering a discussion on the mailing list.

 Mike Norris pointed out that configuration examples for routers will be
 difficult to set up because it depends on the local situation of each ISP
 and router hardware or software used.

 Joachim Schmitz added that the current analysis should be extended by comparing
 the data of routing tables to the route objects actually registered at the
 database, maybe even testing conformity with the routing policy as it is
 found in the database. DK agrees and thinks that it is a very important step
 to be done in the future. Yet, according to DK's opinion the work done so far
 on discovering redundant routes could be used for this.

 Finally, DK asked how the routing working group could be involved. He asked
 for suggestions, especially on filtering of prefix lengths where he thinks
 that reducing redundancy is more worthwhile (even a /32 prefix could be
 meaningful if it points e.g. to a root nameserver). Ruediger Volk suggested to
 identify which ASs are of European origin to reduce the effort. Other valuable
 points are peer pressure and endorsement.

 5a.Exponential route flap dampening

 After this talk Peter Lothberg presented a suggestion on exponential route
 flap dampening, another effort to reduce the pressure excerted by Internet
 growth. Given several interconnected ISPs with a flapping connection on one
 end, this may lead to complete loss of connectivity with respect to the other
 end across the intermediate ISPs. The reason is that propagation of routing
 information takes time. If the flapping frequency is higher than propagation
 across the net at least one ISP in between will not have a valid route for
 the corresponding connection at any given time. Besides computing new routing
 tables over and over again, dropping of packets is also costly for routers
 (if they do not have a default route). To circumvent this problem PL suggests
 that updates on the routing tables should be done ever more reluctant the
 greater the prefix of the route is. The premise is that small prefixes are
 most likely to be aggregates and should be updated as soon as possible while
 greater prefixes should either be aggregated (e.g. by forcing people to
 renumber when changing ISPs) or the connections made more stable (which is
 difficult with smaller organisations and ISPs as experience shows). As a
 first draftproposal, prefixes of /16 should be updated without delay, /17 with
 a tiny delay, /18 with small delay, etc, /24 maybe changed only once a day.
 Surprisingly, no protest was uttered from the audience. However, there is
 no implementation of this scheme yet while PL thought that it could be
 implemented pretty fast. In the following discussion MN felt that dampening
 delays must be globally the same and should be hardcoded to be efficient - but
 it would then be difficult to change them if need arises. A further clarifi-
 cation among DK and PL stated that dampening is applied to outbound updates
 only.
 ANS added on 14.May 1996 (Curtis Villamizar) that the implementation of
 route flap dampening is complicated business. It should only be applied to
 EBGP (probably inbound only) and delays must be handled carefully. If this
 is not done correctly, inconsistent data may arise, routing loops occur, or
 black holes are generated. Moreover, route withdrawl should be propagated
 faster than announcements.

 6. Routing WG future activities, input to RIPE NCC

 This item from the agenda was skipped. Discussion will be done through the
 mailing list first.

 7. AoB

 The final topic of the meeting was the discussion of multihomed organisations.
 WH asked whether anybody had collected pros and cons to give when requests
 occur. This did not seem to be the case but the general feeling was that
 multihoming should not be encouraged because
 - it leads to more routes in the Internet
 - if more specific routes are announced by one ISP involved, less specific
   ones by an other, then the ISP with the more specific announcement will
   attract the traffic which is not necessarily desired
 - moreover, it may become necessary that certain ISPs downstream should prefer
   routes at given exchange points to reach the multihomed organisation through
   certain ISPs rejecting routes through other ISPs. This is near to impossible.
 PL thinks that this problem is solved automatically as the Internet evolves by
 the bare needs of running the Internet.

 Since there was no other business the meeting was closed at 15:45.

 ACTIONS:

 - Action 22-8 on RIPE NCC/Merit:
      To make the RADB publicly available on the the RIPE FTP server (if Merit
      concords)
   status: DONE
 - Action 22-9 on RIPE NCC/ANS:
      To find a final date when to give up advisory tags.
   status: DONE. Actually, the tags have been ignored by ANS since Nov 1995.
 - Action 22-10 on Willem van der Scheun:
      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
      concensus on it
   status: OPEN
 - Action 22-11 on Daniel Karrenberg:
      Based upon the focus found in the Routing WG, to prepare a draft paper
      for the new project and to present it at the next RIPE meeting in January
   status: OPEN (depends on previous action)
 - New Action on Daniel Karrenberg:
      To put his presentation on routing table growth on the RIPE FTP-server as
      ftp://ftp.ripe.net/ripe/presentations/ripe-m24-dfk-Less-routes
   status: OPEN
 - New Action on Willem van der Scheun:
      To investigate the status of the CIDR FAQ and see whether additions are
      needed, probably by triggering a discussion on the mailing list. This is
      to educate netizens for better understanding of problems resulting from
      routing table growth
   status: OPEN

----
_____________________________________________________________________________

 DFN Network Operation Center, Dr. Joachim Schmitz, (finger help@localhost)
                     >>>>>> mailto:  noc@localhost   <<<<<<
   Rechenzentrum Universitaet Stuttgart, Allmandring 30, D-70550 Stuttgart
   Phone: 0711-685-5810, 0711-685-5576, FAX +711 6788363 (business hours)
       EMERGENCY phone +711 1319 139 with answering machine and pager
_____________________________________________________________________________