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-rrc... 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-a... lysis/ 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-oppe... an/ 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 ----