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