Toni, you are raising an interesting issue. However, if the sending routers
do not check whether an update is duplicate, and if the receiving
routers do not check whether an update is duplicate, don't we create
a positive feedback loop? I mean, if a router X sends a duplicate
update to N other peers, then each of those other routers can also
generate duplicate updates sent to their own peers, creating a
multiplicative effect. Of course there are several factors that
would act to limit the dissemination of such updates, such as
policy, but in principle the positive feedback is still there, right?

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.



Constantine Dovrolis | 3346 KACB | 404-385-4205
Associate Professor  | Networking and Telecommunications Group
College of Computing | Georgia Institute of Technology

rrg mailing list

Reply via email to