Dear colleagues,

the Routing-WG minutes of our sessions at RIPE-41 had already been published on the web in February (http://www.ripe.net/ripe/wg/routing/r41-minutes.html). For those who have not yet seen them, I redistribute them with some very slight editorial changes and one URL correction.

Thanks again to Matthew Williams-Bywater for compiling this!
   Joachim

--- JS395-RIPE -- standard disclaimer ---

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
Scribes: Matthew Williams-Bywater
Participants: 150 (1st session) / 78 (2nd session)


A. Preliminaries

  Joachim welcomed us all to the meeting and declared it open. The
  participants' 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
     and work in the task force is running now.

  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, ris-users@ripe.net,
  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
  TopTen 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 scalabity
  issues when adding new plots. The switch to the re-implementation will
  commence within the next few weeks.

  There were no questions on this presentation.


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
  to 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 RRCC@ripe.net.

  There were also no questions on this presentation.


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 loosing 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.

  There were no additional questions to that presentation.


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

  # Editorial note: Compared to the discussion this summary comes delayed.
  # In the meantime, there was some more discussion on the mailing list,
  # a new proposal from the RIPE NCC, and a meeting of interested people
  # during the IETF and a new draft by the RIPE NCC to be presented at
  # RIPE42. Nonetheless, the summary is provided again for completeness.

  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
  (rpslng@ripe.net) and at IETF52.
 
  See URL for the latest draft proposal during RIPE41:
  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:
  rpslng-request@ripe.net.


  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: If we want to configure an IPv4 route,
  so we are looking for an IPv4 route class. Same goes for IPv6. If the
  database offers two distinct classes, then the user will only need 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?
  Is 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&April 2002
----