Has PSI been assigned network 1?


I'll just point out what can be reflected in RIPE-181.

1) MCSNet will aggregate where possible and reasonably implementable
  without causing service degredation.

Register a route object with the aggregates. List any known holes.
There is actually no way to specify that you will block outbound
announcement of components other than to list the components on as-out
lines. Gated has the "xx.yy.xx masklen mm refines restrict" syntax
that might be nice for RIPE-181 to pick up.

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.

No way to specify "we chop off anything more specific that /24". This
would also be good to add "... AND {masklen <= 24}".

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.

Politics is not expressed in RIPE-181. Not even good politics. :slight_smile:

Costs and prefs are expressible.

5) In general, MCSNet does not redistribute routes learned from one
  peer to another.

This is expressed in the as-out lines.

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
  to MCSNet.

You express this in as-out as well by onl;y putting you home AS and
the home AS of you customers in the as-out line.

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).

No place to describe limitations imposed by contracts, other than in a
remark. You could stop a contract violation in someone else's as-out,
to which they may respond "oh, we didn't know we weren't supposed to
be doing that".

8) In general, routes which MCSNet originates (ie: connected customer
  routes generated by MCSNet) may be redistributed unaltered
  (including attributes).

Might be handy if you have a dual home customer that punches a hole in
your block to have someone upstream selectively block announcement of
the hole if from then on the hole and aggregate will be routed the
same way. I don't think that would violate your expectation here.

If you refused to do reasonable aggregation, then expect that your
announcements might be altered (proxy aggregated). I don't think you
have intentions of being anti-social in this way.

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

This too is beyond the scope of RIPE-181.


Nice set of policies. I guess you still may still have to fight it
out with each provider (and their lawyers) separately on some minor
points and maybe expectations of their. Please don't drag this
mailing list through such a discussion.