Also, that method has the same "knowing the routes" problem as netflow. Whereever you are getting your list of ASN's route ASN.*"'s routes, there is pretty much no way they are accurate (for an ASN of ANY size).
The vast majority of the routes will be an intersection of routes announced by the AS to other AS (including looking glasses).
Assume you are provider A, and you are considering peering with provider B. Assume Provider B has customer Z, who buys transit from Provider B and Provider C. Assume you already peer with provider C.
You have no way to know if customer Z will be part of your routes to Provider B, or if you will prefer them over provider C, without having the route list.
This is a standard problem resolved in the set theory. Pick your set. Measure. Pick your set again, measure. Repeat N times. Decide which set of results you accept as more likely. Use them. Alex
This is a very common situation if you have any decent amount of peering, and/or if you are considering peering with a provider who has any reasonable number of multihomed customers. As we've already proved in previous nanog emails, the top 20 route-announcing providers added together have enough routes to cover the internet around 8 times over. Even looking glasses may not contain all the paths available.
Projecting actual IP traffic onto actual IP routes is the only way to do it.
--