[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[RRG] BGP issues
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 rrg-request@psg.com 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