[routing-wg] bgp bestpath conquer

hi,
we run a network with 3 route reflectors. the third one is for own and
customer prefixes. it has 2k routes, the other two rrs have full table.
the pes advertise bestexternal, so rrs have full visibility. our policy
dictates that all the routes have locpref set to express active/backup.
it's observed multiple times that the small rr sends out the updates much
faster than full table rrs. when a customer changes from active to backup,
the active pe sends the withdraw to the rrs, the rrs select the new 
bestpath,
and floods it. but in this case, the locpref changes from high to low, 
and any
pe that wants to forward for this prefix, have to get the update from 
all the
rrs, because until one high locpref exists, that will be selected locally.
the idea is that what if i change the small rr to do the following:
when it detectes a nexthop change during bestpath calculation, take the
old bestpath's locpref, increment it by 1, and send out the new bestpath
with this incremented locpref. if another nexthop change detected for this
prefix, increment the locpref again. so every time it computes the bestpath
for this prefix, it'll send out the result with an increasing locpref, 
forcing pes
to instantly start using the new path.
optionally, a minute timer could  expire the prefix, then it'll send out 
the prefix
with the received locpref, because for that time, other rrs completed their
normal flooding process, but it would double bgp traffic.
it would speed up convergence in the active->backup case because we don't
have to wait for all the rrs to finish it's work. only drawbacks i see 
now are the
following:
-it requres local hot potato routing at backup pe to work.
-maximum one conqueror rr must be used within a single cluster.
-when active route flaps, the locpref will count to 2^31.
-it disrupts igp metric usage in case of scattered rrs or addpath.
the question is, that do you see something else? any feedback welcomed!

sorry for the timing, but preiously i tried to discuss it on
ietf routing board, but they haven't answered to me...
now i'm sure that i'll attend at ripe71, hopefully
i'll have oppurinity to discuss it with someone....

thanks,
csaba mate
niif/as1955

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/routing-wg/attachments/20151116/e750dfb8/attachment.html>