Note that the original soBGP didn't require any updates when the peering relationships changed; based on a quick look, a later extension has probably changed this.
one of the 29 hacks to sobgp to try to fix this and that (kinda like w's social security program). this one was to address the attested as-path problem, which s-bgp solves so elegantly.
*sigh* There were no "hacks" to "solve" this "problem." The certificates can be issued as the originating AS wants to. If they believe losing all connectivity to a peering AS (all possible peering points) is worth issuing a certificate for, they can. There's no requirement to do, since it depends on local policy (this might be a short outage, and the security risk of leaving the connection in place in the certificates might be very low--it's a situation by situation thing). There is no concept of a "peering point" within soBGP, just the whether or not two AS' are actually connected. There's no way to tell, from soBGP, how many times, or in how many places, two AS' are connected (unlike S-BGP). IMHO, there aren't going to be many cases where Sprint, for instance, loses every possible peering point with UUNET. I could be wrong, but it seems just beyond this side of improbable, to me. :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone