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

[Damien Saucez <[e-mail]>]

Hello,

On 06 Jul 2012, at 16:39, Robert Raszuk wrote:

> 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 which RFC is this defined? I looked for but not found it. I am not looking
for multiple routes in the RIB but in the FIB. If you can point me to the 
correct RFC, I am interested.

>> 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

Well, I had the impression that this extended community was used
to announce the link capacity more than its usage. Do you know
if someone is using this community to adapt the load balancing 
according to the link load?

> 
>>> 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.
> 

Ok, yes you are right. However what we have seen (but these
results are not public right now) that the major benefit if you can
select the exit of your ISP with our technique is that you can use
the most disjoint path (ASPaths sharing the least number of ASNs)
which means that in case of failure, you reduce the risk of using
a path that is actually not yet seen as dead  (because of path
exploration). So I believe that resiliency is a good use case (and
also with any other techniques allowing one to select several
routes by its own)


> 
>>> 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.

Would resiliency (and protection against path exploration) be a
valid case for it?

Damien Saucez

> 
> Thx,
> R.
>