All,
Paul A Vixie writes:
The organizations that export/import routes via the route servers may find:
1) the routers have fewer configured peers therefore resulting in less load on the routers 2) the route servers have route flap dampening implemented thereby insulating the peer from a high number of routing updates 3) the route servers do the routing computations which results in freeing significant amounts of processing time on the peer routers 4) a reduction in the time and energy (people resources) needed to establish new peering relationships
--Elise
I, as an example of an "organization" as described above, have found these things to be true. The startup transient is high -- all those this-objects and that-objects. But once it's up and running, adding route relationships is much easier using the route server than by adding BGP sessions.
Of course, I don't do anything complicated. I understand that Sean and others have found that they need to do things with their route import and export rules that the route servers don't have a way of expressing. Perhaps if I were running a net as large as Sean's I would have his troubles.
Some providers have indicated that the route servers would better serve their needs if: 1) the RSs implemented only a subset of the policy expressed in the IRR and 2) the RSs could do proxy aggregation. The configurations of the RSs support both of those requirements now. The policy language does not yet support this in a "standard" fashion, but that is being addressed in the RPS working group. The RA has implemented requirements that providers have when a provider communicates what is needed. I can't find any messages from Sean indicating what he would like to express but can't. The RA team is always willing to work with providers to meet their needs. --Elise