|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Has PSI been assigned network 1?
Karl, I'll just point out what can be reflected in RIPE-181. In message <[email protected]>, "Karl Denninger, MCSNet" writes: > > 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. :-) 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 > guidelines. This too is beyond the scope of RIPE-181. > Discussion? 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. Curtis
|