Re: [rrg] Geoff Huston's BGP/DFZ research - 300k DFZ prefixes are the tip of the iceberg

[Lixia Zhang <[e-mail]>]

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
>
>