About the BGP peering sessions.

> 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