nearly too late: minutes of Routing WG RIPE 39(!)

Dear colleagues, please find below the minutes of our last session during the previous RIPE meeting. Delay in delivering is solely up to myself - I had receive more than enough input from the two scribes Bill Woodcock and Shane Kerr already shortly after the meeting - thanks a lot again to both! Thanks Joachim ----- R I P E 3 9 B O L O G N A Routing Working Group Session 2-May-2001 Draft Minutes Chair: Joachim Schmitz (JS395-RIPE) Scribe: Bill Woodcock, Shane Kerr -- thank you!!! Participants: 111 Prior to the Routing WG two tutorials were given which have a relationship to Routing Monday, 30-Apr, 9:00: Clarence Filsfils, John Evans (Cisco) Full day tutorial on MPLS Tuesday, 1-May, 9:00: Cengiz Allaettinoglu (Packetdesign) Half day tutorial on the RAToolSet The Routing WG session itself was held on Wednesday, 2-May, 14:00. A. Preliminaries (Joachim Schmitz) The chair man welcomed the participants, and distributed the participants' list to sign in. Bill Woodcock volunteered to take the minutes, Shane Kerr also provided them in parallel. Regarding the WG agenda Bernard Tuy asked about the status of the the IPv6 routing registry and whether some presentation would be given. Joachim explained that no action had been taken yet, because the first step is development of RPSLv6. However, this is part of the NCC activity plan. Joachim suggested to initiate a corresponding task force to assist the NCC in that work -> action 39.R1 on Joachim: initiate RPSLv6 task force Following that the WG agenda was accepted without changes. The minutes of the previous meeting at RIPE38 were accepted by the participants, and are thus declared final. Actions from earlier meetings 36.R1 on RIPE NCC RADB coordination for RPSL transition This has been done as part of the RPSL transition at RIPE *close* 37.R1 on C.Panigl, P.Smith, D.Karrenberg, J.Schmitz Updates to RIPE-210 *ongoing* 37.R2 on RIS team, Henk Uijterwall Route flap analysis from RIS data *ongoing* 38.R1 on J.Schmitz, W.Woeber Organize RaToolSet tutorial at RIPE 39 The tutorial has been held this meeting as part of the RPSL transition *close* 38.R2 on J.Schmitz, W.Woeber Collect final community input on database migration dates This had happened according to schedule and recognized for the transition *close* B. Cengiz Allaettinoglu: Observations on IGP Convergence http://www.packetdesign.com/Docs/draft-alaettinoglu-ISIS-convergence-00.ps Towards sub-second IGP convergence: Today, we are typically in the area of tens of seconds or up to several minutes which comes from the process of 1. detect (link up/down or peer reachability) 2. distribute info (flooding) with LSP packets (link state packets) 3. determine new path: shortest path first (SPF) computation Experiments were conducted to analyze this in more detail. Looking closer at the individual steps: 1. Detect Hello packets are sent at a fixed interval of 10secs, with a timeout of 30secs (default value) where the timeout gives a lower bound for cenvergence. In priniple, the hello interval can be reduced. Bandwidth consumption is not necessarily an issue today anymore, and analysis shows that up to 10% of traffic may consist of hello packets if they are treated preferred to data packets. Essentially, allowing sub-second intervals leads to sub-second detection. However, this is hard for "run-to-complete" router OSs which could be mended by employing real time OSs. Still, the hello interval is limited due to physical constraints (bandwidth, error spectrum, propagation delay). Moreover, there are stability issues, if routing follows rapid link transients which would call for some damping mechanism and treating "bad news" differently from "good news". 2. LSP propagation In theory, propagation should not matter (essentially at the speed of light, plus store&forward time per hop) but practice shows difference. In particular, the SPF computation is done before forwarding LSPs, and normally a delay of 5secs is usually set by default, adding to propagation delays. If set to zero, still the SPF computation is done before. 3. SPF calculation Each node must calculate the new SPF topology. For a given number of n nodes and a change in topology the time was measured which is required to calculate SPF. Depending on router vendor, the effort grows by n^2 or n*log(n). For larger network, even on high end routers, the calculation then lasts for seconds. However, new dynamic algorithms exist which scale like log(n) which for large networks improves performance easily 10k times. This is now newly implemented in vendor's codes. Topologies up to 90k edges were tested and no instability was found. There were a few questions on that presentation Q: What happens if an incremental update is lost A: LSPs are already split-horizon Q: What kind of topology had been simulated A: A flat one Q: What if nodes fail which drastically change the shape of the graph A: those have been included, and results are an average of all different kinds of failures Q: Has this been shown and discussed anywhere else A: Yes, at IETF working groups, where the only objection against rapid hello packets was on run-to-completion architectures Q: Topologies can be envisioned where this does not work A: In theory yes, but for practice these would be pathological cases C. Philip Smith: Revision to RIPE-210 (Route Flap Damping) - update Philip first dealt with the question why RIPE-210 should be revised. This is due to several drawbacks: . parameters for /24 damping are virtually unfeasible . "golden networks" are changing . remaining open issues are long solved . restructuring and updating is necessary and discussed these items Parameters for /24 damping specified would never lead to damping as shown by simple discussion of the values. Instead the correct values bgp dampening 30 820 3000 60 with a maximum possible penalty of 3280 leads to suppression of prefixes and the original design intentions are achieved. The "golden networks" according to definition should not be dampened, however the list given in RIPE-210 was outdated, and contrary to the original intention to only list root nameservers, consisted partly of those (incomplete) and some gTLD servers. In the revision "golden networks" are defined to be those which an operator does not want to dampen for whatever reason. It is suggested to move a template list into an appendix, also to reduce the effect that the list is just included unchanged in router configurations by cut&paste. The question is considered solved that updates from a router arrive at a peer at different times through different paths which could be understood as multiple flaps. This has been included in OS codes now. In addition, route refresh is now RFC2918, a proposed standard. Regarding restructuring the following items were changed . moved data to appendices . changed document from Cisco only to general doc (allowing other router vendor implementations), so far received exmaples for Juniper's JunOS Philip also asks for others like gated, Foundry, Redback, Extreme... . show what is not recommended . appendix of study of flap damping operation intended to help for port configs The new draft has been posted to several mailing lists at NANOG, APOPS, AfNOG, and received some input which will be included in a refined version. Joachim thanked Philip for his contribution to the document and the work he put into it. Daniel suggested that the golden networks are excluded from the document itself for the simple reason that they are likely to change more rapidly than the document itself. To have a reference, he suggests to put a reference in which points to a web page on the RIPE NCC web server. This was accepted by the audience. -> action 39.R2 on Daniel Karrenberg: Provide "Golden Network" web page D. Henk Uijterwaal: RIS - Status and Plans There are a few changes to the team, with two people leaving and two new ones joining. In addition, they are looking for a student intern for the 2001-2002 term. Expected total FTE for 2001 is 2.1 FTE with 0.3...0.7 student. Currently, route collectors exist at - RIPE-NCC - LINX and new ones to come up or in the process of being deployed - SFINX - AMS-IX - CIXP If you would want to provide feeds to the route collectors, write e-mail to ris-peerings@ripe.net Beyond that additional route collectors are suggested for - JP/Asian region - US - DE, SE in discussion However, before those are considered more closely, investigate what we can do with existing RRCs first, and determine added value of installing more RRCs. The data of all of these can be handled. Already we have results and displays which for the most part come from Thomas Franchetti's thesis: fully automated setup to produce daily updated plots of the RIS data. This is fully documented and currently generates 4 different plots; current plots are - BGP updates/minute - Prefix distribution - BGP distribution of types (announcements, withdrawals) - BGP unique announcements More plots and stats can be easily added, and will be added. Beyond these generic plots, those parties with a peering session can get a personalized view. Before putting this to true production, two more tasks must be done - security review of cgi-code - apply NCC layout Plans for the next months include - transitioning with new people - RIS reports will go online - move to regular service From the audience the question was posed about data volume. This is 14 MB per peer per day, and 4 GB raw data per month. Due to a scaling problem with the database, active data in the database is currently limited to 3 months worth of data. Older data is kept gzipped. [break] After the break, a joint session with the Database WG was held, to wrap up on the transition to the RPSL database. E. Andrei Robachevsky: New Version of the RIPE Database http://www.ripe.net/rpsl The database has migrated and is now running RPSL. There is no other production database anymore, in particular no test or RIPE-181 databases. About one week after the migration (happened on 23-April), already 56k objects have been processed. The query rate with an average of 8.7 queries/sec is the same, and so far 17M objects have been downloaded. Currently, there are 6 active mirrors (there had been 12 before). The new RIPE database software code had been completely rewritten to improve performance and managability. It now supports RPSL, extended syntax and objects (RFC2622), RPSS (RFC2725), and the RAToolSet (v.4.7.0, ftp:/ftp.isi.edu/ra/RAToolSet). There are plans to move development and maintenance of the RAToolSet over to the RIPE NCC. In addition, a new whois client has been developed (ftp://ftp.ripe.net/ripe/dbase/reimp/whoisRIP-1.0.tar.gz). Andrei then gave an overview of features of the new database software with regard to RPSL, in particular - modified objects: mntnr, route, aut-num, inetnum, as-set (was as-macro), route-set (was community), inet-rtr. Non-affected objects: person, role, domain, limerick. - new objects: as-block, rtr-set, peering-set, filter-set - new attributes: member-of, mbrs-by-ref, mnt-routes, referral-by, auth-override - new query flags: -l <ip-range>, -x <ip-range>, -K, -d, -q sources, -q version - new version of the mirroring protocol The team involved in development and transition of the new database software is Daniele Arena Marek Bukowy Joao Damas Engin Gunduz Roman Karpiuk Shane Kerr Ambrose Magee Chris Ottrey Filippo Portera Andrei Robachevsky reachable at dbrip@ripe.net. Many thanks go to this team and anybody who has helped to make it happen! This was very much supported by the audience! Prior to the transition (on the test database) and right after, a few issues had been discovered and resolved - PGP updates failed at <auto-rpsl@ripe.net> o solved 24 April o use ONLY RPSL path for PGP signed updates - Conversion problems of updates at <auto-dbm@ripe.net> o incorrect or misleading replies o solved 26 April o please use RPSL path <auto-rpsl@ripe.net> - Acknowledgement problems o sometimes were not sent or were misleading o solved 26 April - Acknowledgement problems(2) o authentication does not give proper responses - Some filaed updates were not processed o might have happened 23-27 April o please re-send them if you didn't receive a reply from DB and the objects are not updated - Indentation difference o will be solved ASAP - DB accepts mirror's requests with protocol #1 o "compatability" mode o deadline: [15.10 | until sorted out with RADB/iRRd] - Routing Policy System Security (RFC2725) o authorisation rules for route creation need mntner authorization for inetnum, (parent) route, aut-num, a route itself problem with MAIL-FROM, because can only have 1 mail-from! problem with CRYPT-PW because you have to share password o need to duplicate objects in the RIPE DB origin or address from non-RIPE space currently have inetnum with NONE auth for mnt-routes as-blocks for RIPE space with NONE auth for mnt-lower o possible better solution perform checks on mirrored sources - which sources contain authoritative data for an IP/ASN space? implement some of RFC2769 (rps-dist) features - integrity attribute? requires good coordination and understanding between RIR's, IRR's To finalize the transition, the mail addresses to send updates to will be changed over time as announced: - 1st (current) <auto-dbm@ripe.net> -> <auto-181@ripe.net> 23rd April - 2nd (next) <auto-dbm@ripe.net> -> <auto-rpsl@ripe.net> 14th May - 3rd no <auto-181@ripe.net> There was a set of questions on the transition and the presentation Q: the keyword "password" must be written all in lowercase in contrast to RPSL definition? A: this has been fixed Q: after migration import/export attributes often extended over several lines, while one liners with updates were correctly returned which caused problems with scripts processing data A: line continuation is a feature of RPSL and described in the standard; accordingly scripts must be capable of handling them; for the auto conversion during migration it was not the rule to break single lines into multiples, but could also not be excluded Q: when querying an encompassing AS block you get "?" as ARIN number, and ARIN1-RIPE with a wrong address A: this will be fixed Q: a provider asked that they have C&W as upstream which reads their AS-macros and was wondering whether C&W was ready to read AS-sets A: C&W participated explicitely in the transition process, and a representative of C&W confirmed that they have already made the conversion G. Rob Evans: Operational Experience with RtConfig <rhe@noc.ten-155.net> <rhe@nosc.ja.net> Rob introduced himself as working for the University of London Computer Centre, running JANET (UK education and research network) and TEN-155 (pan-European counterpart). While JANET applies fairly loose filtering, TEN-155 generates filters based on policies in IRR (RIPE). Therefore, all networks routing on TEN-155 must have a corresponding entry in the RIPE Database. They are using RtConfig, a program from the RAToolSet to generate parts of their router configurations, because people make mistakes. Using RtConfig limits their impact. Rob then showed several examples of common user mistakes like - redistributing IGP routes into BGP - unintentionally announcing full routing tables - ordering a filter wrongly - typing errors in filters and continued on how they are employing RtConfig - to generate filters - interprets policies - generates BGP configs - in formats for all our favorite routers accompanied by an example on how to generate filter lists. Gotchas To use RtConfig a few things should be considered - adds latency between a customer being allocated addresses and the route being accepted which can be reduced to a minium if updates are run regularly - filters can be very large (by route), which can be circumvented by just filter on AS path (which unfortunately does not protect against redistribution of IGP) - which db to query? for us in the European, RIPE will usually do Rob also thinks that they have room for improvements, because so far they do not use use many features of RPSL and RtConfig - peering sessions are still configured manually - many options that can be expressed in RPSL are still configured manually (eg route preferences) All of this can be done by a combination of RPSL database entries and RtConfig. F. Cengiz Allaettinoglu: Overview of the RAToolSet This was essentially a small recap from the RAToolSet tutorial from the beginning of the RIPE meeting covering RtConfig router configuration tool peval policy calculator/evaluator roe route object editor prtraceroute traceroute with policy no assumptions - only concerns YOUR part of IRRd CIDRAdvisor safe aggregations (for your routes) prpath paths to different location these two tools assumed that many people would register in IRR this assumption has not been true aoe aut-num editor (no longer available, not RPSL capable) Pointers to this are o http://www.isi.edu/ra/rps/training o http:/www.isis.edu/ra/RAToolSet Mailing lists o <rps@isi.edu> o <ratoolset@isi.edu> Cengiz Alaettinoglu <cengiz@packetdesign.com> Just prior to the RIPE40 meeting, it was announced that maintenance and development of the RAToolSet has moved to the RIPE NCC. As a part of this move, RAToolSet will be called IRRToolSet. A new web page http://www.ripe.net/ripencc/pub-services/db/irrtoolset/index.html and a mailing list irrtoolset@ripe.net have been established. Y. Input from other WGs Combining the 2nd slot with the Database WG covered the transition of the RIPE database to RPSL. In addition, reference was made to the IPv6 RR which needs to be taken up for further development. Z. AOB none Summary of Open Action Points from the Routing WG 37.R1 on C.Panigl, P.Smith, D.Karrenberg, J.Schmitz Provide updates to RIPE-210 - ongoing - 37.R2 on RIS team, Henk Uijterwaal Implement route flap analysis from RIS data - ongoing - 39.R1 on J.Schmitz, D.Kessens Initiate IPv6 IRR taskforce - new - 39.R2 on D.Karrenberg Provide "Golden Network" web page - new - Bill Woodcock, Shane Kerr, May 2001 Joachim Schmitz, September 2001 -----