On 3/15/10 2:42 AM, Tony Li wrote: > Interestingly, I'm not sure that this is worth fixing. Most BGP > implementations store a copy of all of the best paths that they've received > from neighbors. They then compute the 'best path' amongst this set and > advertise it appropriately. Truly fixing this problem would require that an > implementation retain state on a per-neighbor basis about which attributes > were advertised (and in some cases, what changes to what attributes were > performed). Further, the implementation would still have to effectively > compute the update because output policy could have a substantial impact on > the result. Thus, the question really becomes whether transmitting the > update and receiving it is more expensive than additional filtering in the > sender. Given that bandwidth is 'free', the tradeoff is now between the > sender with additional state and processing, or the processing in the > receiver. Note that the receivers task is to parse the update, realize that > there is, in fact, no change, and not do anything. > Indeed, you're trading systemic state for implementation optimizations, in lots of places where issues such as this are amplified. > 40% duplicates in a system today ma not be a problem, however, if prefix, origin, and path validation techniques are employed down the road in a secure routing protocol built on the current model, and every one of those updates have to be processed, I suspect at some point senders will be a bit more conservative in what they send.
-danny _______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg
