I'll jump in here and say that if you do that you have an instant convert
here in me.
That's part #1.
Part #2 is a little more interesting. It involves people publicizing their
policies (BTW, I believe these must be PUBLIC -- if you're going to use a RA
then let's know what everyone's rules are.) and putting THOSE in the RA.
Here's a stab at how I believe today:
1) MCSNet will aggregate where possible and reasonably implementable
without causing service degredation.
2) MCSNet will accept and announce for customers specific routes at no
more specific than 24 bits, IF the customer coming onto MCSNet with
those number(s) can provide evidence that they were delegated to
them. A SWIP entry to the customer's name and contact info is
considered sufficient evidence. We will announce these as necessary
and we will aggregate, again, where possible.
3) MCSNet will *accept from others* routes which are no more specific
than 24 bits. MCSNet requires that those who peer with us make a
reasonable attempt to aggregate as (1) above.
4) Routes will be accepted without prejudice, except that MCSNet
reserves the right to weight incoming routes and paths as it deems
appropriate to load balance circuits and capacity according to
physical and business requirements.
5) In general, MCSNet does not redistribute routes learned from one
peer to another.
6) In general, MCSNet will send customers full routing tables
unmolested IF they are (1) multi homed, and (2) have or can
demonstrate competence in managing the route announcements sent
7) In general, routes which MCSNet distributes to customers under (6)
will be agreed not to be sent beyond the direct customer (except for
those generated internally at MCSNet under *8* below).
8) In general, routes which MCSNet originates (ie: connected customer
routes generated by MCSNet) may be redistributed unaltered
9) MCSNet expects the following from those who want a BGP session:
a) Complience with 3, 6, 7 and 8 where applicable.
b) Non-interferance with MCSNet announcements within these