soBGP deployment

Sun May 22 01:59:46 UTC 2005

>> 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 at cisco.com CCIE <>< Grace Alone