-----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-----