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