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.
Lixia
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
paper:
"Investigating Occurrence of Duplicate Updates in BGP Announcements"
http://www.cs.ucla.edu/~jpark/dupbgp.pdf
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.
Tony
_______________________________________________
rrg mailing list
rrg@irtf.org
http://www.irtf.org/mailman/listinfo/rrg
