In the paper, we specifically mentioned that we used RRC00's data and all the BGP sessions at RRC00 used multi-hop peering. So what we concluded is that data from multi-hop peerings should be carefully sanitized to remove those BGP updates associated with the instability of the monitoring session (in this case, it was the session instability caused by the worm attack).
almost. the session resets were exacerbated by what turn out to be mild effects worm attack. but the root cause seemed to be multi-hop ebgp sessions running on a partiuCular vendor's fragile tcp stack designed for point-to-point bgp peering, not trans- and inter-continental. so if you looked at a session cross-eyed, it reset. the upshot of this was that route-views and ris got the message and deployed physically at many critical peering venues, so they could peer directly as opposed to multi-hop. this has much improved the data. thanks route-views and ris. randy