soBGP deployment

Tue May 24 03:06:23 UTC 2005

>> I suspect the right thing to do is to ask why soBGP and sBGP
>> have failed?
> Or maybe, jut maybe, because we've never had the tools to deploy
> it.

actually, we had a small workshop with sbgp tools at the last
eugene nanog.  perhaps it's time for another?  bill, can you host
at he next nanog, as it is on your turf?

but, of course, for real deployment, those tools, built for *bsd
and linux, would limit initial deployment to those running pc-based
routers.  to go futher, we would need support from juniper and
other vendors.

>    - sBGP allows the receiver to validate that the update indeed traversed 
> the path described in the AS Path Update as part of the local acceptance of 
> the update.
> 
>    - soBGP allows the receiver to determine that the AS Path describes a 
> plausible traversal across the network, but cannot validate that the update 
> itself traversed this path.

further, the latter, because it relies on a separate data set for
path validity, has serious and very kinky temporal sync problems.

i receive a bgp announcement from a new peer, but the announcement
was originated two weeks ago (shockers!  a stable route); was the
asserted path to my new peer valid when the announcement was
originated two weeks ago?  once your mind starts down such paranoid
paths, the void opens before one's eyes.

randy