R I P E 4 0 P R A G U E Routing Working Group Session 3-October-2001 Minutes Chair: Joao Luis Silva Damas (i p o Joachim Schmitz - JS395-RIPE) Scribe: Matthew Williams Participants: 88 A. Preliminaries Joao introduced himself, welcomed us all to the meeting, and explained he was charing this meeting on behalf of Joachim Schmitz who could not attened this time. Joao handed out the participants' list. Matthew Williams from the RIPE-NCC volunteered to take the minutes. The agenda for this session and minutes from the previous meeting at RIPE39 were approved without further ado. Action points from earlier meetings: 37.R1 on C.Panigl, P. Smith, D. Karrenberg, J. Schmitz Updates to RIPE-210 -done- The final draft document (v2.0) has been sent to the Routing-WG mailing list. 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 task force -ongoing- 39.R2 on RIPE NCC Provide 'Golden Network' web page -done- The web page can be found at URL: http://www.golden-networks.net/ B. Henk Uijterwaal: Routing Information Service, Status and Plans Presentation available at URL: http://www.ripe.net/ripencc/pub-services/np/Talks/0110_RIPE40 There have been some changes to the team. Three new staff members have joined and one has left. Next year in February, a student focusing on route flaps and/or black holes will also join the team. One of the new functions, the Customer Liaison Engineer, will be responsible for encouraging more interaction between New Projects and users of its services. Two mailing lists, ris-ix@ripe.net and ris-users@ripe.net, have been created for this purpose. Ris-ix will be used specifically for correspondence between RIPE-NCC and hosts of Route Collectors, while ris-users will be open to anyone who uses RIS or RIS' raw data. Some links to research based on the RIS' data have been added to the web site: - Thomas Franchetti's Thesis, 'Internet Routing Analysis Provided by the RIS Report', provides the most current technical description of the RIS and RIS Report. It also includes some interesting practical examples on RIS usage. (URL: http://www.ripe.net/ris/analysis.html) - Various plots and tables from RIPE-NCC and MAE-East data by Olaf Mannel at the University of Saarbrucken. (URL: http://www.net.uni-sb.de/~olafm) - Dartmouth College/Renesys Inc's 'Global Routing Instabilities during Code Red II and Nimda Worm Propagation' (URL: http://www.renesys.com/projects/bgp_instability) Currently, route collectors are present at: - RIPE-NCC - LINX, London - SFINX, Paris - AMS-IX, Amsterdam - CIXP, Geneva - VIX, Vienna - NSPIXP2, Otemachi (Tokyo) Total of 162 BGP sessions The route collector in Tokyo, which has been deployed in collaboration with APNIC, will provide the RIS with a view from a completely different angle. There are further plans to install one or two more route collectors in the US for the same reason as mentioned above. The additional value of adding more boxes can be judged by studying the differences in BGP routing information between different collectors. There have been some improvements to the RIS since the last meeting. It is now possible to make queries either by AS or Prefix, which should be clearer for the user. The Zebra logs can now be downloaded from the web site and NTP problems with raw data are fixed. Two other services, ASInuse and the RIS report have been brought online. Immediate plans include improving the response time of queries and providing more FAQs and general documentation. In 2002, the RIS team plan to deploy additional route collectors, develop user training and implement a graphical presentation of AS maps. The main research projects comprise of studying route flapping, investing dark address space and reconstructing the Internet routing table from RIS' raw data. C. Philip Smith: BGP Flaps Slides available at URL: http://www.ripe.net/ripe/meetings/archive/ripe-40/presentations/ routing-bgpflaps/ Philip Smith presented some interesting observations regarding BGP flaps based on Geoff Huston's data at URL: http://www.telstra.net/ops/bgp/ bgp-upd-entries.html. The main focus of this study was the behaviour of different prefix sizes in today's Internet with regard to the dampening values chosen in 1997 (RIPE-210). Main observations when analyzing BGP updates of the last 14 days: - Forwarding Information Base (FIB): 110k prefixes - Average updates per hour: 713 - Average prefix size of updates: 23.05 BGP Updates per hour, sorted: /24 - 449 updates /23 - 51 updates /22 - 45 updates /19 - 41 updates /20 - 39 updates /16 - 35 updates /21 - 29 updates This means that 60% of all updates were caused by /24s. However, the route dampening values after three flaps have remained unchanged in the update to RIPE-210: - /24s and longer prefixes, suppressed for 60 minutes - /22s and /23s, suppressed for 45 minutes - The rest are suppressed for 30 minutes Philip's preliminary conclusions were that /24s maybe should be dampened more aggressively and that values for /22s and /23s should be extended to include /16s and then the entire range from /19s to /23s. Dampening values for the rest seem to be working satisfactory. Geoff Huston has been only been collecting data for the last couple of months,i.e. more research needs to be done. There will be another presentation at the next RIPE meeting. Q: Why are /24s flapping so much? Q: Where are the /8 flaps coming from? A: Currently, questions like where and who cannot be answered. More research needs to be done before the next meeting. D. Philip Smith: Multi-homing Document Presentation available at URL: http://www.ripe.net/ripe/meetings/archive/ripe-40/presentations/ routing-multihoming/ Kurt Keyser, Abha Ahuja, Joachim Schmitz and Philip Smith intend on authoring a document for LIRs on multihoming with some advise regarding common situations. Progress is slow at the moment. An update will be presented at the next RIPE meeting. Q: Is there a draft available for scrutiny? A: Not yet, but feedback from the WG is very welcome. E. Florent Parent: IPv6 Routing Policies using RPSL Presentation available at URL: http://www.ripe.net/ripe/meetings/archive/ripe-40/presentations/ ipv6-routing-rpsl-ripe40.pdf Florent Parent gave us an update on RPSL and IPv6. At this time, the specification for RPSL (RFC2622) does not cover IPv6 usage for routing policies. However, there is support for the new version of IP in RPSL. Immediate tasks will be documenting IPv6 usage in current classes and defining new attributes where required. The current classes used in the 6Bone whois database are ipv6-site and inet6num. They are both defined in an IETF draft, which can be downloaded from: http://whois.6bone.net/~david/6bone/draft-ietf-ngtrans- 6bone-registry-xx.txt. Florent went on to discuss the implications of IPv6 routing policies when using current RPSL classes. There is much work to be done. The next steps will be to form a task force focusing on IPv6 RPSL, sending the current IETF draft to the mailing list for scrutiny and adding support in RAtoolset for the new IP version. Those interested in participating in the task force should contact Florent (email:Florent.Parent@viagenie.qc.ca). Q: What is the name of the mailing list? A: The chair mentioned that it is hosted by RIPE-NCC as rpslng@ripe.net (majordomo). F. Roger Gottsponer: How to secure your job: Implement MPLS VPNs Presentation available at URL: http://www.ripe.net/ripe/meetings/archive/ripe-40/presentations/mpls-routing-rpe40/ Mr Gottsponer from Nextra in Switzerland shared with us lessons they had learnt when implementing and running a real life MPLS/VPN network. This presentation was instigated by the MPLS tutorial at RIPE39 and the fact that Nextra has been running a national MPLS-VPN network for 2.5 years. The international network has been in place since one year back. Their experiences are that MPLS provides one with lots of interesting features, such as new customer services (VPNs) and money-saving opportunities through traffic engineering, but it does also make operations more problematic. Another downside is the fact that some features may not be 'VPN-aware', i. e. NAT, firewalls. However, most problems are not related to technology. Mr Gottsponer went on to talk about general concepts and the actual deployment of MPLS/VPNs. He did mention some interesting observations regarding using traceroute on a MPLS network and considerations when securing your Provider Edge (PE) routers. The problem with traceroute is that it will send an ICMP packet with a TTL of 0 to the second router in the Label Switch Path (LSP) between the two PE routers. Because the second router only looks at the layer 2 header, the packet will be sent all the way to the PE router at the other end of the LSP before the ICMP TIME_EXCEEDED response is sent back to the transmitting station. One will therefore see observe strange latencies when using a non-mpls-aware traceroute utility. The second issue dealt with securing PE routers against unsolicited telnet requests. Mr Gottsponer's main recommendations were: - Only use host routes for network management stations - Point host routes to null interfaces in each of the customers' Virtual Routing Forwarding Tables (VRFs) - Filter routing updates from customers. Do not accept all internal address ranges. - Use loopback addresses and IP extended access-lists on PE routers There were no questions after the presentation. Y. Input from other WGs IPv6 WG: As mentioned previously, interested parties are welcome to join the IPv6 RPSL task force by sending an email to: Florent.Parent@viagenie.qc.ca Z. AOB none Summary of Open Action Points from the Routing WG 37.R2 on RIS team, Henk Uijterwaal Implement route flap analysis from RIS data -ongoing- 39.R1 on J.Schmitz, D.Kessens, F.Parent Initiate IPv6 IRR task force -ongoing- 40.R1 on Kurt Keyser, Abha Ahuja, Joachim Schmitz and Philip Smith Creating a 'Multihoming Document' for LIRs -new- Joao Luis Silva Damas, Joachim Schmitz, Matthew Williams, October 2001