Q1: To obtain the data, you use the IRR. However, I would not trust a topology that is based on IRR regardless of the filtering, because there is too much old stuff in there and the filters suggested in the past do not work well. A1: We agree that IRR is noisy, however at the same time we think IRR is very helpful if used correctly. In fact IRR greatly reduces the number of traceroutes we have to perform. Please note that the released topology has been verified by BGP tables or traceroute, link by link. Q2: I noticed that some AS edges that appear in RouteViews in May 2005 do not appear in your topology. Do you have an explanation why this happens? A2: We do not include every edge that could have appeared in May 2005. You can always combine all routing tables in May 2005, day by day, hour by hour. A more general way of doing this is to include all BGP updates. We can easily get many more AS edges than what appear in a snapshot by this way. However it's very hard to distinguish transient or erronous route information. We discuss this senario in our NSDI'07 paper in the section of "Background::Data Sources and Their Limitation::BGP updates." Knowing this, we pay more attendtion to a *snapshot* of Internet topology. Most of the snapshot was taken on May 12, 2005, just after midnight Greenwich time. However for the traceroute part, the experiments lasted about a week in May 2005. Q3: How about the ASes? Do you pay attention to missing ASes? A3: Like the AS routes, ASes could be transient in BGP tables as well. For example, if a stub AS withdraw all of its prefixes, the AS number will disappear in the routing tables. There are also new AS numbers put into use and injected into routing table, every month if not everyday. In general, missing ASes are not as interesting as missing edges. One can always ask the authorities (e.g. ARIN) who assign the AS numbers to check if an AS is real. On the other hand, AS edges are totally arranged among ASes themselves, and not controlled by any central authority. It's inheritedly harder to know if an AS edge exist or not. Q4: I've noticed that some nodes have a link in connectivity file but have no specified relationship in relationships file. This is somewhat suprising if those two files were obtained from the same data source? A4: In the AS relationship algorithm we used, there are a small number of links whose types can not be inferred, because the algorithm "thinks" they are erroneous/transient links (maybe due to misconfiguration etc). Therefore, we did not include these edges into the relationship file. Q5: I've noticed that some prefixes do not propagate globally when I infer routes using No Valley Prefer Customer (NVPC) approach. I've tracked this down to the following reason - some ASes will have one neighbor but will have peer relationship with this neighbor. Do you have a strong reason why single-homed ASes will peer with their neighbor instead of having a provider which would be more logical to me? A5: We believe the reason is that there are some errors in the inferred relationships. As mentioned in the paper, the accuracy about relationship inferring is not 100%. In addition to the scenario you have identified, you could also have "isolated islands", where a group of ASes connect the rest of the Internet only by a customer edge (a.k.a., valley routing). Fortunately, the number and size of these isolated islands are very small, so you can either delete them or flip the direction of an edge, then everything will be connected by NVPC. Q6: Are you planning to release a newer topology than the one from May 2005? We have looked at your data and we found that many ASes that appear now in routeviews that don't appear in your graph from May 2005. A6: New ASes and links do come up everyday. Our data collection was done a while back, it is probably time to do a new massive synthesis of source. We will release our data once we get it. To monitor Internet we definitely need continuous effort and resources and to leaverage other efforts such as NetDimes and iPlane.