RIPE 41

R I P E 4 1 A M S T E R D A M
Routing Working Group Session
15/16-January-2002 Minutes

Chair: Joachim Schmitz - JS395-RIPE
Scribe: Matthew Williams-Bywater
Participants:


A. Preliminaries

Joachim welcomed us all to the meeting and declared it open. The
Participant's list was then handed out by the chair and Matthew
Williams
from RIPE-NCC volunteered to take the minutes.

The proposed agenda for this session and minutes from the previous
meeting
at RIPE40 were approved without hesitation by the attendees.

Action points from earlier meetings:

37.R2 on RIS team, Henk Uijterwaal
Implement route flap analysis from RIS data
-ongoing-

39.R1 on J.Schmitz, D.Kessens and F.Parent
Initiate IPv6 IRR task force
-done-

The item above was considered done by participants. Florent
Parent has already published an Internet draft proposal,
"RPSL extensions for IPv6 and Multicast Routing Policies",
which can be found at URL:


http://www.normos.org/ietf/draft/draft-parent-multiprotocol-rpsl-00.txt

40.R1 on Kurt Keyser, Joachim Schmitz and Philip Smith
Create "Multihoming Document" for LIRs
-ongoing-


First Session: 15-January-2002
- ------------------------------

B. Henk Uijterwaal: Routing Information Service, Status and Plans

Presentation available at URL:
http://www.ripe.net/ripencc/pub-services/np/Talks/0201_RIPE41/

Two Route Collectors will be added to the Routing Information Service:

one located at Netnod-IX in Stockholm and another at NSPIXP2 in Tokyo.

The latter has received a feed from APNIC since August last year, but
its announcement as a service was delayed until January 2002 due to
hardware issues. Next steps include finding one or two locations in
the United States and investigating the added value of more collectors
in Europe.

Currently, Route Collectors are present at:
* RIPE-NCC
* LINX, London
* SFINX, Paris
* AMS-IX, Amsterdam
* CIXP, Geneva
* VIX, Vienna
* NSPIXP2, Otemachi (Tokyo)
[Planned: Netnod-IX, Stockholm]

Total of 178 BGP sessions

As part of the continuous improvement of the RIS, a 700GB RAID was
installed at the RIPE NCC. It is estimated that the new hardware will
fulfil storage needs until the end of this year. Additional changes
and
improvements will be announced to the mailing list,
[email protected],
maintained by majordomo at RIPE NCC. Hopefully, the mailing-list will
also become the natural forum for discussions about RIS data.

Since the last meeting, manuals and FAQ's have been added to the web
site.
The manual pages contain typical examples on usage and interpretation
of
different RIS query options. More cases will be appended in the
future.

Due to the time-gap of one hour between data collection and insertion,
it was
decided to implement a Looking Glass on each of the Remote Route
Collectors.
It has most of the standard options found elsewhere on the Internet. A
new
query type has been created for users as an attempt to target flaps,
the
RIS TopN Utility. It produces lists of prefixes on demand, where high
withdrawal or announcement activity was registered over a specified
time
interval. High counts could indicate some kind of problem for certain
routes.
The RIS team will start running the queries regularly to produce
monthly
Top Ten reports over "active" prefixes and AS numbers.

The utility can be found at URL:
http://abcoude.ripe.net/ris/topten.cgi

Furthermore, Henk and his team will continue its work on finding
"route
flaps". In February 2002, a student will start devoting his time to an
experiment that involves announcing/withdrawing fake routes and
observing
when changes are registered by Remote Route Collectors. A
collaboration
of people from AT&T Research and RIPE NCC will analyze results from
the
experiments.

Another project, the RISreport, has had to be redesigned due to
scalability
issues when adding new plots. The switch to the re-implementation will

commence within the next few weeks.


Questions:

None


C. Engin Gunduz: Routing Registry Consistency Check Project

Slides available at URL:

http://www.ripe.net/ripe/meetings/archive/ripe-41/presentations/database-rrcc/

Engin held a short introductory presentation regarding the RRCC
project and
its future. The main objectives of the project are targeting
inconsistencies
between the RIPE Routing Registry, making the RIPE RR reflect de facto

Internet Routing Policies and, by making it more accurate, also more
useful
for Network Administrators. The RRCC will use RIS data, currently from
RRC00,
and compare it to information stored in the RIPE RR.

RIPE201, published in December 2001, provides an overview of the
project and
is intended to solicit input from interested parties. It can be found
at URL:
http://www.ripe.net/ripe/docs/rr-consistencycheck.html.

There is also a prototype available on the RRCC web site.
See URL: http://www.ripe.net/rrcc/

The prototype is updated daily using, as previously mentioned, RIS
data and
provides the following query types:
* unregistered, but advertised prefixes
* registered, but not advertised prefixes
* unregistered peerings

Future plans include making different subscription services available
to the
community and producing metrics that measure improvements in RR data
quality. Community feedback can be sent to: [email protected].


Questions:

None


D. Philip Smith: Internet Routing Table Analysis Update

Slides available at URL:
http://www.ripe.net/ripe/meetings/archive/ripe-41/presentations/routing-rt-analysis/

Philip Smith has added a number of new variables to the Internet
Routing Table
statistics, which are available at URL:
http://www.apnic.net/stats/bgp/

New variables include:
* "Count Unique Prefixes" - Eliminate all subnets of prefixes
appearing in the
routing table, e.g. 158.43.0.0/16 is announced, but all subnets are
dropped/
ignored. Represents the Internet Routing Table's smallest
theoretical size
without losing address space, but may lead to routing problem if
used.
* "Prefixes after Maximum Aggregation" - Eliminate all subnets of
prefixes.
appearing in the Internet Routing Table that appear originating from
the
same AS, e.g. 158.43.0.0/16 is announced from AS1849 and all subnets
from
the same AS are dropped/ignored. Represents the aggregation effort
from AS,
not taking traffic engineering into account, and the smallest
theoretical
size of the routing table without losing any detailed reachability
information.
* "IP Addresses in Use" - Previous error which over-counted address
space
fixed.
* "Origin-only ASes" - Counts ASes which only originate prefixes and
are not
seen in transit paths from Smith's BGP view.
* "Transit-only ASes" - Counts ASes which are NOT originating prefixes
and
only in transit paths from BGP view.

The Internet Routing Table had 107232 entries on the 11th of January
from
Smith's view. On the same day, counts for 'Unique Prefixes' and
'Prefixes
after Maximum Aggregation' were 52095 and 71370 respectively, where
the
latter gives us a theoretical estimate of the routing table's size if
optimal
aggregation were to be employed. Philip had also observed some
interesting
trend changes in the BGP table since early last year after the
"Dot-Com"
collapse. A previously non-linear growth of the amount of tables
entries has
practically stabilized itself at approximately 107k routes. Similar
trends
can also be seen in the amount of announced ASes on the Internet.
Several
other examples on how to interpret statistics, including comparative
observations between RIR regions, were presented at the meeting.


Questions:

None


E. Andre Oppermann: BGPDNS - "Using BGP Topology Information for DNS RR
Sorting
a Scalable Way of Multi-Homing"

Presentation available at URL:
http://www.ripe.net/ripe/meetings/archive/ripe-41/presentations/routing-opperman/

BGPDNS is both concept and protocol for achieving server multi-homing
without
needing your own AS and PI address space. Reasons for multi-homing
vital
servers to several ISPs include:
* Link Redundancy
* Load-Balancing
* Independency

However, this approach has drawbacks for the community as large:
* Fragmentation of IP address space
* Excessive memory and CPU requirements on Internet Core Routers
* Exhaustion of current AS number space

Considering that BGPDNS overcomes many disadvantages of traditional
multi-homing, it may someday become the viable alternative. The method
does
not require an unique AS number or PI address space, while still fully

maintaining aggregates. When a request is received by the authorative
DNS
at the site, it will interact with the BGPDNS server, via the protocol
with
the same name, to determine which of its 'A Records', all
corresponding to a
particular server, is the best reachable IP for the requester. This
can be
achieved by having the BGPDNS server establish its own listening-only
BGP
sessions with route servers at each upstream provider.

The mechanisms for determining which IP that should be listed first in
the
DNS response, i.e. used by the source, are relatively easy to
understand.
Firstly, the BGPDNS server performs a "show ip bgp" for the requesters
IP
to establish the best path back to the source and, secondly, another
"show
ip bgp regexp" for the left-most AS in order to determine the
aggregate
originating from there. The A record IP that belongs to that address
space
will be given priority over the others. When the DNS server sees the
priority,
it will list the corresponding IP first in the response packet sent
back to
the requester. The source will then use this destination IP to
establish a
session with the target server. More detailed information can be
attained by
reading the RFC draft.

RFC draft and patches are available at URL:
http://www.bgpdns.org/


Questions:

Q: Other solutions using NAT yet?
A: BGPDNS with NAT is in the pipeline.
Q: Does BGPDNS support IPv6?
A: Yes.


Y. AOB

none


Second Joint Session with the Database WG: 16-January-2002
- ----------------------------------------------------------

F. Marc Blanchet: IPv6 and Multicast routing policies using RPSL

Slides can be found at URL:
http://www.viagenie.qc.ca/en/ipv6/presentations/ripe41-rpsl.pdf

Currently, RPSL doesn't define IPv6 nor multicast routing policies.
At RIPE-40, a task force was initiated to document the usage of
above in current classes and then, if required, define modifications
to the present implementation of RPSL.

The current proposal aims at making the changes generic, i.e. not only

limited to IPv6 and multicasting, and also minimizing the number of
additional classes/attributes. These goals are based on ideas from
Florent Parent's initial draft and discussions on the mailing list
([email protected]) and at IETF52.

See URL for the latest draft proposal:

http://www.normos.org/ietf/draft/draft-parent-multiprotocol-rpsl-00.txt

Although the current RPSL database will remain intact, the suggestions
imply
that a new server will be required for both the present database and
multi-
protocol extensions. Obviously, clients and current tools, e.g.
IRRtoolset,
will also have to support these changes.

Next steps include porting the IRRtoolset to support the new
extensions,
moving the document forward at IETF and continuing the discussion on
the
mailing list. Members can subscribe to it by sending an email to:
[email protected].


Discussion - "The Inconsistent Syntax of Proposed Sub-Attributes
Afi/Safi":

João Luis Silva Damas (RIPE NCC) - a) Does not like afi/safi because
its
not easily read/written by humans, easily processed by machines
though.
Better to do classes. b) Prune things that are not used or required.
c) Describe transition IPv4 -> IPv6, in particular tunnels.

David Kessens (Nokia) - a) Wants to add minimal IPv6 support b) Does
not
want to prune nor simplify RPSL, maybe just exclude unused things c)
No new
classes, just add/modify attributes to get running more swiftly.
However,
requires many changes to all tools, not only IRRToolSet, but also
privately
developed tools.

Ping Lu (Cable & Wireless) - Supports new classes as well.

Andrei Robachevski (RIPE NCC) - a) Also supports new classes. Does not
want
to complicate RPSL just to make it appear more intelligent. b) Charter
so
far concerns only extensions of RPSL. We also need RPS auth.

David - Distinguish between new classes, new attributes and new
sub-attributes.
Ping - From an operational standpoint: We want to build an IPv4 route,
so we
want to look for an IPv4 route class. Same goes for IPv6. If the
database
offers two distinct classes, then the user will only have to use one
hash for
deriving route.

Larry Blunk (Merit Network) - New commands would have to be added to
the
server. Same would be required for IRRToolSet, IRRd, whois etc.

David - a) The difference between IPv4 and IPv6 can easily be found by
parser,
but does this include future address formats? Probably not, so please
don't
use implicit information. b) Another idea would be to identify topics
by
commencing work on a deployment plan.

Per Heldal (Private) - What about using a proxy as front-end to the
database
as a method for cloaking syntax or attribute changes from tools and
user?

Wilfried Woeber (UniVie/ACOnet) - Are the IPv4 and IPv6 players the
same? Are
the infrastructures the same? Do we have an issue at all?

Ping - Again: Please don't change the sub-attribute context. Much too
complicated and will require changes to existing modules that analyze
or
parse the present RPSL.

Gert Doering (SpaceNet) - Same AS numbers are used, meaning that IPv4
and IPv6
attributes must be in the same class.

Ping - Agrees, but more concerned about sub-attribute context

Joachim Schmitz (AOL) summarizes the discussion:
* We need to continue our debate regarding the charter: RPSL
(IPv6, multicast, transitional elements) and RPS Auth.
* There is currently no consensus on the future apparition of
RPSLng. We will have ask different groups to take on certain
tasks and then develop proposals.


Z. Input from other WGs

See discussion under item F.


Summary of Open Action Points from the Routing WG

37.R2 on RIS team, Henk Uijterwaal
Implement route flap analysis from RIS data
-ongoing-

40.R1 on Kurt Keyser, Joachim Schmitz and Philip Smith
Create "Multihoming Document" for LIRs
-ongoing-

41.R1 on Marc Blanchet, David Kessens, Florent Parent and Joachim
Schmitz
Continue work on "RPSL extensions for IPv6 and Multicast Routing
Policies"
-new-

41.R2 on Joao Damas, Engin Gunduz, Shane Kerr, Andrei Robachevsky and
Joachim Schmitz
Continue work on the Routing Registry Consistency Check project
-new-


- ------------------------------------------------------------------------
- ---
In memory of an important contributor to the RIPE Routing Working Group
and
a valued member of the Internet community - Abha Ahuja (1972-2001)
- -----------------------------------------------------------------------

Joachim Schmitz, Matthew Williams-Bywater, February 2002