Sriram, Kotikalapudi (Fed) writes:

...

When we (as7018) were preparing to begin dropping invalid routes received from peers earlier this year, that is exactly the kind of analysis we did. In our case we rolled our own with a two-pass process: we first found all the traffic to/from invalid routes by a bgp community we gave them, then outside of our flow analysis tool we further filtered the traffic for invalid routes which were covered by less-specific not-invalid routes. What remained was the traffic we would lose once invalid routes were dropped. Had the pmacct capability existed at that time, we would have used it.

We (NIST) did a detailed analysis of Invalid routes (with Routeviews data) that was presented at IETF 101: [foo] See slides 10-13. We tried to drill down on Invalid routes which were covered by less-specific not-invalid routes. We examined questions like: how often does the less-specific route have the same origin AS (OAS) as the Invalid, and, if not, then how frequently is the OAS of the less specific route a transit provider of the OAS of the Invalid route? We plan to update the results periodically.

Sriram, Please note that this thread is about "Analysing traffic", not routes. Prior to dropping invalid routes, had we seen that we were exchanging any significant amount of traffic with destinations covered only by invalid routes, we would have tried to do something about it. First we would have attempted to contact the holder of the resources in question. If we were not able to resolve the issue that way, then we would have at least considered deploying a temporary whitelist entry, while continuing attempts to fix things the right way. Fortunately it did not come to that. The volume of the invalid-only traffic we were carrying then was insignificant. Of course, traffic volume is not the only thing one should consider prior to dropping invalid routes, but it should be one piece of one's due diligence. Jay B.