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
__________________________________
[EMAIL PROTECTED] CCIE <>< Grace Alone
