In message <199504191812.OAA19123@titan.sprintlink.net>, Vadim Antonov writes:
jgs@aads.net (John G. Scudder) wrote:
What AS690 does is not just bureaucratic silliness. It's also enlightened self-interest (as Curtis keeps saying). If enough people have the sense to want to protect themselves, the Routing Registry will fly.
I agree with the idea of Routing Registry (although i'm more than sceptical about RADB in its present form, replacing distributed computation with a cental box not controlled by the service providers).
However, my point is that it should be easy to use and should be on-line; the NACR-style configuration nightmare is not going to fly.
--vadim
Vadim,
How about if we put an HTTP front end on it in place of the e-mail interface and you can use your favorite forms capable web browser? Would that be easy enough to use?
If so, can you live with an e-mail interface for a few months?
Curtis
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 to MCSNet. 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 (including attributes). 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. Discussion? -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity Modem: [+1 312 248-0900] | (shell, PPP, SLIP, leased) in Chicagoland Voice: [+1 312 248-8649] | 7 POPs online through Chicago, all 28.8 Fax: [+1 312 248-9865] | Email to "info@mcs.net" for more information ISDN: Surf at Smokin' Speed | WWW: http://www.mcs.net, gopher: gopher.mcs.net