Hello,
Personally, I believe that the route reflector can be more conservative on CPU resources overall, as the number of BGP adjacencies with route reflectors is the minimum possible. The main difference is, however, in the way these two approaches tackle the problem of simplifying the full mesh of BGP neighbors, and the resulting features you are given as a consequence.
With confederations, you split your AS into sub-ASes. BGP speakers inside a sub-AS have still to be fully meshed (or use an internal route reflector). With confederations, you are given a crude form of traffic engineering within your own AS, as you can determine the path between internal sub-ASes using ordinary BGP attributes, just like you can do it between normal ASes.
The route reflector relaxes the requirement on disseminating information between iBGP peers. However, in order to prevent routing loops, each route reflector adds two new BGP attributes to each reflected prefix (the ORIGINATOR_ID and CLUSTER_LIST). With route reflectors, the logical topology between BGP speakers in an AS reduces itself to hub and spoke (it may get more complicated, though, if redundant route reflectors are used).
The confederations and route reflectors can be combined together. However, according to what I have heard, the confederations have not been very popular. I am sure other friends here can share their own experiences.
Best regards,
Peter
