top posting: it's my fault for not stating clearly -- Since Amund's msg said that

- Surprisingly, as much as 40% of churn consists of duplicate announcements, which are unnecessary for correct protocol operation.

I was merely offering one explanation for the cause of the observed duplicates. The least to say is that this is not RRG's job (hence the presentation was to GROW), even if worth fixing.


On Mar 15, 2010, at 1:42 AM, Tony Li wrote:

[Off topic warning...]

we did a measurement study to understand the causes of such excessive
duplicate announcements, the results are reported in the following
"Investigating Occurrence of Duplicate Updates in BGP Announcements"
to be presented at PAM conference next month

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.


rrg mailing list

Reply via email to