nanog mailing list archives
Re: Open Source BGP Route Optimization?
From: Per Gregers Bilse <bilse () networksignature com>
Date: Fri, 28 May 2004 21:27:14 +0100
Hi bep, good to see you're still kicking.-) On May 28, 12:25pm, Bruce Pinsky <bep () whack org> wrote:
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".
'Learn' as in how? Either you need protocol (extension) and/or hooks and out-of-band (ie, some other protocol), or you have to probe and synthesize (which I would be reluctant to trust). There's no other way.
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.
But that wasn't really the point. If I telnet to all border routers and do 'sh ip b' I can get all tables too; likewise if I have a starting point and do a lot of LS traceroutes; and maybe even via SNMP (haven't checked what various MIBs support). The point was that an optimizer can't simply be an internal BGP peer, as there is no guarantee that it will in fact get any alternative paths. And the secondary point/issue is that it may be unwise to have two loosely connected protocols in charge of routing: one the regular BGP, and one some out-of-band add-on trying to manipulate the first. I think I would want these things to be tightly integrated in only one protocol. On May 28, 12:35pm, Bruce Pinsky <bep () whack org> wrote:
| It has been discussed and been on wish lists, but: And as I said in my other post, there were two drafts submitted that never went anywhere.
And as I said it had been discussed and been on wish lists; same thing, if a little more floral in tone.-) There's nothing scientific that prevents implementation of selective withdrawal and/or any other addition to BGP, but they're not implemented, so it's a moot point.
But the "optimizing" device is in need of receiving all potential paths from the border routers. Essentially, it needs a complete picture of all viable paths, not just the best that each border has. It would not be
Yes, that's precisely what we're saying: it can't just be an internal BGP peer in a normal setup.
The point is not to tell other borders about paths it will not use, but for the "optimizing" device to select the desired path from all available paths and cause that path to become "best path" for all border routers. And
And again, yes, the other way around, this is what we're saying: The borders need to tell the optimizer about all paths. Coffee machine dead? :-) Best, -- Per
Current thread:
- RE: Open Source BGP Route Optimization?, (continued)
- RE: Open Source BGP Route Optimization? Drew Weaver (May 25)
- RE: Open Source BGP Route Optimization? Matthew Kaufman (May 25)
- Re: Open Source BGP Route Optimization? Tony Li (May 25)
- Re: Open Source BGP Route Optimization? Christian Malo (May 25)
- Re: Open Source BGP Route Optimization? Tony Li (May 25)
- Re: Open Source BGP Route Optimization? Curtis Maurand (May 25)
- RE: Open Source BGP Route Optimization? Matthew Kaufman (May 25)
- RE: Open Source BGP Route Optimization? Drew Weaver (May 25)
- Re: Open Source BGP Route Optimization? Jonathan M. Slivko (May 25)
- Re: Open Source BGP Route Optimization? Bruce Pinsky (May 28)
- Re: Open Source BGP Route Optimization? Per Gregers Bilse (May 28)
- Re: Open Source BGP Route Optimization? Andrew - Supernews (May 28)
- Re: Open Source BGP Route Optimization? Sam Stickland (May 29)
- Re: Open Source BGP Route Optimization? Olivier Bonaventure (May 29)
- Re: Open Source BGP Route Optimization? Alexei Roudnev (May 29)
- Re: Open Source BGP Route Optimization? Per Gregers Bilse (May 28)
- Re: Open Source BGP Route Optimization? Arnold Nipper (May 28)
- Re: Open Source BGP Route Optimization? Per Gregers Bilse (May 28)