Routing WG Minutes

Minutes from the Routing Working Group at RIPE 24

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 preliminaries 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
consensus on it
status: OPEN (not yet started)
Transferred 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 attempts 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. Wilfried 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 exerted 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 draft proposal, 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 withdrawal 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
consensus 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