Re: [lisp] Thinking forward to Vancouver, important dates.

[Robert Raszuk <[e-mail]>]

Damien,

>> That is completely incorrect. BGP keeps (and may use locally) as
>> many paths as it receives from it's iBGP and eBGP peers.
>
> well, with vanilla BGP, at one given router you have only one exit
> per prefix.

No. EBGP multipath and IBGP multipath are clear examples where in 
vanilla BGP you install more then one BGP path to RIB.

> In the paper, we consider vanilla BGP, of course multipath BGP allows
> several exits per prefix, and you can use add path to iBGPed announce
> multiple routes internally

I am talking about vanilla BGP. No add-path is required for multipath.

>> Please note that there are commercial deployed products doing just
>> that for the last 10 years or so already.
>>
> sure, but as far as I know, they are black boxes and there is no
> standard method for them. is there?

They are not that black. They in fact work by influencing BGP best path 
decision.

>> Also multipath considers link-bw which results in non equal traffic
>> spread.
>
> you are right that the phrasing was not ideal. It is obviously
> possible to have no equal traffic spread when combined with TE, but
> it is not BGP itself that allow this.

Of course this is BGP itself. Nothing to do with TE. Please see:
http://tools.ietf.org/html/draft-ietf-idr-link-bandwidth-04

>> The tunneling to deflection point in the upstream can be done, but
>> it guarantees nothing. Till you have at least a minimal assurance
>> what is the view of the world of the peers of the upstream any
>> decision you make from stub AS point of view will be quite blind.
>
> Sorry, I am not sure I understand this sentence. With the tunnels, we
> can select the exit point exactly, however, of course, the selection
> of this exit point is based on partial information.

You select it exactly but only in your peer. The point is that it buys 
you very little as avrage AS distance today is 3.4 - You have completely 
no control what happens after the deflection point.


>> Assuming that LMDs are just a bit extended RRs normal EBGP with
>> add-paths could be used. I see no need for new protocol.
>
> I thought add path was limited to iBGP. If we can use add-path in
> eBGP and if we can use any selection mode we want, then yes it would
> make it.

Today it is limited to iBGP, but not that it can not be extended if you 
provide valid case for it.

Thx,
R.