Iljitsch,
On Mar 26, 2009, at 4:24 PM, Iljitsch van Beijnum wrote:
On 26 mrt 2009, at 12:38, Danny McPherson wrote:
Recognizing the originator ID can happen very early when expensive
actions such as applying prefix lists and route maps and inserting
in the RIB haven't happened yet, so the impact of doing this could
be fairly negligible.
Could be. Then again, there's NO way that it can me more
efficient then having not received the updates - from a system
state perspective. Further, those updates are multiplied by
the number of RRs and handled in the same processing path as
ALL other updates, so operators should be concerned about this.
Then again, this is only an issue for the prefixes the router itself
sends to the RRs and then are reflected back. You mentioned some
really large numbers in your talk which seem atypical to me: in a
network large enough to have RRs I would assume that most routers
are only responsible for a relatively small number of best prefixes
in the global table. Yes, this multiplies by the number of RRs but
then again so do all the prefixes that the router isn't considered
best for, which require significant more resources.
I think it's important to point out that the concern is /routes/,
i.e.: /paths/ + prefixes, not just prefixes alone that are the concern
here. In addition, your comment seems to be from the viewpoint of a
"snapshot in time"; however, BGP (particularly on Edge routers) is
very dynamic, because it's constantly receiving eBGP updates from
peers and/or customers, performing path selection and when it arrives
at a new best path forwarding it to RR's and then receiving it back.
The larger point here is paths are much more dynamic than just
prefixes, resulting in a more offered load on the overall system ...
In the case where a router would indeed get back 100k if its own
prefixes from RRs it would make more sense to make that router a non
client peer of the RRs and make the problem go away in that way.
However, that would increase the size of the iBGP mesh, which was the
point of putting RR's in in the first place. Admittedly, you don't
have to revert to a complete iBGP full-mesh, but administratively it's
harder to plan & deploy what boxes will be part of the full-mesh (non-
rr-clients) vs. rr-clients and then changing configs around when
circuits toward peers or customers are groomed from box-to-box as well.
Considering all of the above and the fact that avoiding
backreflection means breaking groupwise processing on the RRs which
means extra processing for ALL prefixes times ALL clients for each
RR I'd say that we shouldn't make changes here, but limit ourselves
to documenting the issue so that vendors and operators can make sure
the additional processing for backreflection is reduced.
Re: your comment on "breaking groupwise processing" ... don't RR's
already have to account for not sending updates to a specific peer
(or, set of peers) based on various ORF types they've received from
that peer (assuming ORF's are enabled)? Why can't that same code/
logic apply here (i.e.: it's already written, why can't we re-use it
here)?
-shane
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow
