<html> <head> <meta http-equiv="content-type" content="text/html; charset=utf-8"> </head> <body bgcolor="#FFFFFF" text="#000000"> <div class="moz-text-html" lang="x-unicode"> <div class="moz-text-flowed" style="font-family: -moz-fixed; font-size: 12px;" lang="x-western">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 </div> </div> </body> </html>