[81032] in North American Network Operators' Group
Re: soBGP deployment
daemon@ATHENA.MIT.EDU (Russ White)
Mon May 23 21:49:59 2005
Date: Mon, 23 May 2005 21:47:31 -0400 (Eastern Daylight Time)
From: Russ White <ruwhite@cisco.com>
Reply-To: Russ White <riw@cisco.com>
To: Randy Bush <randy@psg.com>
Cc: "Larry J. Blunk" <ljb@merit.edu>, nanog@merit.edu
In-Reply-To: <17041.63797.265940.720976@roam.psg.com>
Errors-To: owner-nanog@merit.edu
> o with sbgp, the assertion of the validity of asn A announcing
> prefix P to asn B is congruent with the bgp signaling itself,
> A merely signs the assertion in the bgp announcement.
>
> o with sobgp, the assertion is in an external database with
> issues such as
> - data correctness & completeness
The database is built just like BGP routing information databases are built
today. Each AS originates their piece, and every other AS puts the pieces
together to form the whole. There is no centralized registry.
> - data consistency
> - update frequency
These two are up to the originating AS'. If you update your certificates
in real time, the same way you do your routes (and I can easily argue you
don't actually update your routes in real time, actually), then you will
get congruent, up to date information. Those AS' who do not update their
certificates in real time will not have real time data in the database,
just like BGP is today.
> - granularity (bgp is per-prefix, and this is used by real
> folk to do traffic eng etc). consider the mess of keeping
> this up to date and correct in a super irr.
There is no "super irr." There is no centralized database in soBGP. Period.
:-)
Russ
__________________________________
riw@cisco.com CCIE <>< Grace Alone