On 26 mrt 2009, at 12:38, Danny McPherson wrote:
Recognizing the originator ID can happen very early when expensive actions such as applying prefix lists and route maps and inserting in the RIB haven't happened yet, so the impact of doing this could be fairly negligible.
Could be. Then again, there's NO way that it can me more efficient then having not received the updates - from a system state perspective. Further, those updates are multiplied by the number of RRs and handled in the same processing path as ALL other updates, so operators should be concerned about this.
Then again, this is only an issue for the prefixes the router itself sends to the RRs and then are reflected back. You mentioned some really large numbers in your talk which seem atypical to me: in a network large enough to have RRs I would assume that most routers are only responsible for a relatively small number of best prefixes in the global table. Yes, this multiplies by the number of RRs but then again so do all the prefixes that the router isn't considered best for, which require significant more resources.
In the case where a router would indeed get back 100k if its own prefixes from RRs it would make more sense to make that router a non client peer of the RRs and make the problem go away in that way.
Considering all of the above and the fact that avoiding backreflection means breaking groupwise processing on the RRs which means extra processing for ALL prefixes times ALL clients for each RR I'd say that we shouldn't make changes here, but limit ourselves to documenting the issue so that vendors and operators can make sure the additional processing for backreflection is reduced.
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
