Re: Open Source BGP Route Optimization?

[Per Gregers Bilse <bilse () networksignature com>]

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