nanog mailing list archives
Re: Peering Policies and Route Servers
From: Elise Gerich <epg () merit edu>
Date: Tue, 30 Apr 1996 15:20:53 -0400 (EDT)
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 --EliseI, 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
Current thread:
- Re: Peering Policies and Route Servers, (continued)
- Re: Peering Policies and Route Servers Nathan Stratton (Apr 29)
- Re: Peering Policies and Route Servers Jeff Young (Apr 30)
- Re: Peering Policies and Route Servers Matt Zimmerman (Apr 30)
- Re: Peering Policies and Route Servers Michael Dillon (Apr 29)
- Re: Peering Policies and Route Servers Nathan Stratton (Apr 29)
- Re: Peering Policies and Route Servers Matt Zimmerman (Apr 30)
- Re: Peering Policies and Route Servers Enke Chen (Apr 30)
- Re: Peering Policies and Route Servers Randy Bush (Apr 30)
- Re: Peering Policies and Route Servers Elise Gerich (Apr 30)
- Re: Peering Policies and Route Servers Paul A Vixie (Apr 30)
- Re: Peering Policies and Route Servers Elise Gerich (Apr 30)
- Re: Peering Policies and Route Servers Paul A Vixie (Apr 30)
- Re: Peering Policies and Route Servers Paul Ferguson (Apr 29)
- Re: Peering Policies and Route Servers Curtis Villamizar (Apr 30)
- Re: Peering Policies and Route Servers Cengiz Alaettinoglu (Apr 30)
- Re: Peering Policies and Route Servers Steve Heimlich (Apr 29)
- Re: Peering Policies and Route Servers Vadim Antonov (Apr 30)
- Re: Peering Policies and Route Servers Peter Lothberg (Apr 30)
- Re: Peering Policies and Route Servers bmanning (Apr 30)
- Re: Peering Policies and Route Servers Tim Salo (Apr 30)
- Re: Peering Policies and Route Servers Randy Bush (Apr 30)
- Re: Peering Policies and Route Servers Matt Zimmerman (Apr 30)
- Re: Peering Policies and Route Servers Randy Bush (Apr 30)