good to see you're still kicking.-)
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.
> 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
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?