Re: Has PSI been assigned network 1?
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
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).
This is an excellent point, and raises a path that CA*net has tried to implement. I believe that the IRR has to follow "paths of administrative trust" model, and not a central registration model, since it is an administrative overlay on the routing protocol. What I mean is this: ISPs should run (or contract to run) their own routing registry (think of CA*net and RIPE as contracted database providers to member service providers in this model). This routing registry *database* gets signed using PGP and exchanged *in bulk* with its immediate peer neighbors and a central repository. ISPs then generate their configurations on this database. The IRR is the union of all ISP databases. Each ISP is responsible for the consistency and validity of its own database. The important point is that as databases are moved, they are signed, and this leaves a clear and specific audit trail of who certifies the validity of the registered prefixes. The central repository (the RA) acts in two roles: registry of last resort (although this will not scale for the entire Internet) and as a contracted central depository to assist the NAP routing for NSF. This central depository provides the opportunity for interesting reporting on configuration/topology/policy problems and issues. Their are many religious objections to RIPE-181. However, my view is that the facility it provides (a standard policy language and software to implement it) is so important, just the fact that it exists now is enough for me. When Nirvana arrives, I will deploy it. Until then, I will use RIPE software, and thank them and the RA (Merit/ISI/IBM) profusely for the work they have done. Eric Carroll University of Toronto Network & Operations Services External Networking Facilities Management CA*net Network Engineering
my opinion: the nacr style is good, because it requires really getting the thing right and thought out. Anyways, such a db should be used infrequently. aggregation should make frequent entries unnecessary. (...) ripe's telnet is good too, but a real telnet online type access would invite sloppyness, and/or repalce route flap by nultiple daily policy flap. Mike On Wed, 19 Apr 1995, Vadim Antonov wrote:
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
-------------------------------------------------------------------------------- Michael F. Nittmann nittmann@wis.com Network Architect nittmann@b3.com B3 Corporation, Marshfield, WI (CIX Member) (715) 387 1700 xt. 158 US Cyber (SM), Washington DC (715) 573 2448 (715) 831 7922 --------------------------------------------------------------------------------
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
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
Karl, I'll just point out what can be reflected in RIPE-181. In message <m0s1lHM-000IDOC@venus.mcs.com>, "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
Vadim Antonov <avg@sprint.net> writes:
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).
A (set of) central box(es) is the best we can get deployed quickly. As a matter of fact it is deployed already in Europe. Once can always improve that but it boils down to solving highly distributed database problems. There is no intention of "replacing distributed computation" with this. Do not confuse the Routing Registry with Route Servers. Although the registry "box is not controlled by the service providers", the content is! So the only thing you need is a dependable and neutral entity to run the registry.
However, my point is that it should be easy to use and should be on-line;
Of course! Daniel
participants (6)
-
Curtis Villamizar -
Daniel Karrenberg -
Eric M. Carroll -
Karl Denninger, MCSNet -
Michael F. Nittmann -
Vadim Antonov