Open Source BGP Route Optimization?

Fri May 28 19:25:07 UTC 2004

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Per Gregers Bilse wrote:

| At first I wasn't sure what a "route optimizer" was supposed to do --
| the term is rather generic and could have a lot of different
| interpretations.
|
| A multi-path traffic balancing solution in the style of Cisco's OER has
| to be tightly integrated with the routing infrastructure.  Specifically,
| it needs first hand BGP peer data in order to work reliably.  There will
| be a number of cases where an add-on solution might be able to improve on
| certain things, but there is one major hurdle: a BGP speaker only forwards
| its own best paths, so an add-on analyzer might well never learn about
| alternative paths.  The only way for any implementation to reliably learn
| (all) alternative paths and otherwise maintain routing integrity is by
| receiving BGP data first hand, ie directly peer with transit providers
| and other peers.
|

Having helped design and implement one such a system, I can tell you that
there are alternatives to peering directly with transit providers.  We were
able to learn alternate paths directly from the border routers of the
entity whose exit paths our product was "optimizing".

I am also aware of other implementations that did not rely on BGP NLRI data
for determining if an exit path was valid for any given destination or
prefix.  In those implemenations, BGP was used merely as a mechanism to
influence the outbound routing decision.

Additionally, there were two RFC drafts published regarding the capability
to negotiate for receiving both the active and inactive paths.

draft-fletcher-bgp-inactive-path
draft-walton-bgp-add-paths

Given the failure of this market segment to mature, I suspect both of those
are expired by now.

- --
=========
bep

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (MingW32)

iD8DBQFAt5ITE1XcgMgrtyYRAn14AJ4ruf+9zpTxjwwlHqDnCRaClhWq5gCgmArk
jXgwS/2xiwqQlfUFqfpWg/Y=
=qKz1
-----END PGP SIGNATURE-----