Re: Peering Policies and Route Servers

[Elise Gerich <epg () merit edu>]

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