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.


rrg mailing list

Reply via email to