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. _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
