On 8 jan 2008, at 23:09, Robert Raszuk wrote:
But I would like to also see the real list of what are the issue in BGP we are trying to address ... Is this point-to-point model, is this TCP transport, is this update format ... No one yet stated what is broken. And when we do not know what is broken .. or which link of BGP chain is fragile it is quite a challenge to design new thing around the unknown.
In addition to the fact that it's possible to configure iBGP such that you can have routing loops?
This is from a draft I once wrote: Today, the BGP4 protocol is used for inter-domain routing. There are several problems with BGP. By design, it is a "path vector" protocol: basically a distance vector protocol with path information added. As such, it suffers from some of the problems inherent to distance vector routing, such as slow convergence and the count to infinity problem (although the AS path in BGP helps a lot here). Another problem area for BGP is the fact that all processing happens on a per-prefix basis: there is no way to communicate reachability or policy changes except to update all impacted prefixes. BGP is extremely agnostic as to the underlying path selection algorithm in order to accommodate as much policy control as possible. Unfortunately, this makes it very hard to predict BGP's behavior and the default behavior (especially with today's rather flat AS hierarchy) is more often than not suboptimal. BGP allows harmful policies that keep the protocol from converging to a stable state. Lack of workable aggregation mechanisms means that once an address block is deaggregated, it's almost impossible to get rid of the resulting long prefixes, leading to excessive growth of the internet's global routing table. Coarseness of the only available end-to-end metric (the AS path) pushes operators to deaggregation for traffic engineering purposes. The way BGP operates within a single AS requires an additional intra-domain routing protocol and suboptimal engineering tradeoffs by requiring having a full mesh between all BGP routers within the AS or having route reflectors or a confederation. There is no validation of routing information beyond the next hop. A BGP speaker only communicates its best path (if any) to a neighbor, with no way to tie additional information to the nonexistence of a path and no way to accomplish type of service routing or install backup paths. Paths must be explicitly revoked, which in practice requires a BGP speaker to keep track of which paths were communicated to which peer. BGP requires fairly extensive configuration (setting up filters) before it's useful. -- to unsubscribe send a message to [EMAIL PROTECTED] with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
