[81004] in North American Network Operators' Group
Re: soBGP deployment
daemon@ATHENA.MIT.EDU (Russ White)
Sat May 21 22:00:26 2005
Date: Sat, 21 May 2005 21:59:46 -0400 (Eastern Daylight Time)
From: Russ White <ruwhite@cisco.com>
Reply-To: Russ White <riw@cisco.com>
To: Randy Bush <randy@psg.com>
Cc: Pekka Savola <pekkas@netcore.fi>, nanog@merit.edu
In-Reply-To: <17039.40442.337318.65482@roam.psg.com>
Errors-To: owner-nanog@merit.edu
>> 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
