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

[Damien Saucez <[e-mail]>]

On 06 Jul 2012, at 17:03, Robert Raszuk wrote:

> 
>>> 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.
> 
> http://tools.ietf.org/html/draft-ietf-idr-bgp-issues-06
> Section 2.11.3
> 
> It does not require protocol extension so this is a BGP implementation thing. IETF RFCs are not to describe implementations, but protocol.
> 
> And of course multipaths are installed both in RIB and FIB.
> 
ok with the SHOULD i the proposal, that solves the issue

>>> 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.
> 
> True.
> 
>> Do you know if someone is using this community to adapt the load
> > balancing according to the link load?
> 
> I do not know if this would be a good idea in the first place.

agree, this is a pandora box but maybe it could help reducing
the impact of some DDoS. For example, with our technique, if
the operator sees that there is too much load from a part of the
network, it can change the weight associated to the locators that
it announces to this part of the network such that a proportion
of the traffic from there is diverted to other parts that are less
loaded. This can be done with the community as well (but you
also need a "scoped advertisement" but this is not elegant as
the value is supposed to give the capacity (called bandwidth
in the draft) in bytes, which hasn't change... An alternative 
would be to have a community that can be scoped and that
only gives a weight to the route. Maybe this already exist.

Damien Saucez

> 
> R.