[81032] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

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

home help back first fref pref prev next nref lref last post