Dear Hank, On Wed, 10 Sep 2003, Hank Nussbacher wrote:
Can the RIPE NCC TTM group explain why such a service is needed when there are other packages available that do similar things?
From your previous postings, I have understood that you do not like the current model where every WG can ask the RIPE NCC for specific actions. However, this was the procedure at the time. Even with the advent of the NCC-services WG it appears to us as the correct procedure for something
Short summary. ============== Ip2asn is built as an internal tool in response to requirements raised inside the TTM WG. It is used to put ASN information into TTM products. Making this mapping function available externally is not much work at all. We know of no similar service that meets this particular need. Long version: ============= For starters, I disagree with the statement that this is a new service that was not approved by anybody beforehand. The TT-WG was set up for various reasons. One of them was to provide a forum where (paying) customers of the TTM service can learn about the development plans for the project and provide feedback. The issue of IP-AS mappings has been discussed several times in the last years, our plans have been presented at previous meetings, and the presentation that you are referring to, was in fact the outcome of a specific question raised in the WG. For those who haven't followed the TT-WG, let me briefly summarize what happened in the past: Since the start of the service, TTM has provided the IP-level path that a packet takes when traveling from source to destination based on traceroute-like probes. One frequently see changes in these paths. These changes can be caused by many things, but amongst the most common are: 1. Traffic is routed through different routers of the same upstream provider. (For example, when load balancing schemes are in use). 2. Traffic is routed through a different upstream provider. In order to quickly distinguish between #1 and #2, one can look at which AS the IP-addresses in the path belong to. This requires a mapping of IP-addresses to AS-numbers, at the time that the IP-trace was taken (as IP blocks may move from one AS to another over time). Sometime in 2002, we therefor added a column in the output showing the AS that every IP address belonged to. This mapping was based on whois queries. When this was presented to the TT-WG, the (valid) question was raised how accurate this mapping was and if it wouldn't be better to use a routing-table based approach. As we, nor anybody in the audience, knew the answer, we (the RIPE NCC TTM-group) agreed with the TT-WG to study this. The talk you are referring to is the direct result of this question. like this, because it is germane to the TT-WG and does not involve a significant amount of resources. Anyway, the conclusion from this study was that the IRR only produces the correct mapping in about 80%, switching to an approach based on routing tables (i.e. the RIS) increases that percentage to about 99%. Obviously, the more accurate the results, the more useful the output, and the conclusion looked simple: the TTM service should switch to a routing table based approach for IP to AS mappings. Implementation ============== Besides being accurate, the implementation also has to be fast, as we have to process 4000 to 5000 different IP addresses in a relatively short time. We also believe that we should use routing tables that we are already collecting for the RIS, this in order to ensure that data from one RIPE NCC service (TTM) is consistent with another. This will also give a performance boost, as all data resides on 1 local network. The best way to accomplish this, appears to be a daemon that loads all information into memory. serves queries and refreshes itself at regular intervals. Other tools =========== We were fully aware that other tools existed to do this job, but we believe that none of them meets our requirements. For the ones that you list: 0) Both NANOG traceroute and lft have a -A switch but get the prefix data from a routing registry (whois.ra.net) which has been shown to be incomplete, out of date, not maintained 1) http://www.cymru.com/Tools/getorgasn2.pl Relies on access to a router. comments: one router does not necessarily see all prefixes and origins one needs to combine data collected from various vantage points (RIS collectors, route-view peers) performance: each lookup is done with a 'sh ip bgp $prefix' command on the router, won't scale to thousands of lookups (or hurt router performance) 2) Net::Patricia Create ASCII prefix/AS table from a source of routing information (route-views quoted), use Net::Patricia to lookup. Comments: the idea is good, but the ASCII data and perl make it too slow. An ip2asn server at RIPE NCC could parse the data from RIS, keep everything in memory and refresh info daily. 3) "Routeviews project now has a test/static asn zone up that you can try" % dig @archive.routeviews.org 13.142.223.128.asn.routeviews.org txt comments: interesting idea but at the time it was still under development. strange replies on non-matched IPs, e.g. try host -t txt 7.227.290.195.asn.routeviews.org This could be a solution for traceroute, but in TTM we skip time consuming dns lookups on the testboxes and do offline processing; performing thousands of dns lookups for ip2as there will likely take too long too. 4) ip2asn scripts from Stephen Gill - starting from BGP table dump - contacting route server comments: BGP table dump covered above (good start, but not complete and ASCII is slow), route server is slow, won't scale to thousands of queries Why make this a service? ======================== Mapping IP to AS can be used in many tools, both that are published in the public domain as in tools used inside LIR's only. All these tools will benefit from more accurate data. To use a routing based IP-AS mapping for TTM, we need to develop and maintain some amount of code. Adding an interface to access the same data from the outside, requires very little additional work. In fact, I think that we'd be doing the community a dis-service if we would not make this tool available to everybody. Henk (with the help of Rene, Daniel and the rest of the TTM group) ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal@ripe.net RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ That problem that we weren't having yesterday, is it better? (Big ISP NOC)