Re: Has PSI been assigned network 1?
Hank Nussbacher <HANK@taunivm.tau.ac.il> wrote:
The e-mail interface of NACRs is close to uselessness, and too big headache to deal with. Waiting time on processing is simply ridiculous.
I've been sending updates to auto-dbm@ripe.net for the past 2 years with no problem.
You don't have to keep a full-time engineer just to handle NACRs, do you?
There should be a host accepting telnet sessions for on-line updates (which have to be installed *immediately*, so whoever added a network can test connectivity and go ahead).
telent info.ripe.net to test it out.
RIPE database does not control the actual routing. I'm not sure the current RADB project has any mention of real-time updates of gated from the database. With dozens of updates we do every day it nearly as good as useless.
There should be well-defined and useful interface to service providers databases.
It should be secure.
I use a password on all AS updates to AS378.
You call *that* secure? We have way too many people who need to do changes for our AS-es. Check the contact list for AS1800.
Without that i do not see RADB being successful or useful beyond the point of filtering updates from particularly obnoxious peers.
It may not have everything we want today but it is an excellent starting platform.
If i can't implement my existing policy, i cannot use RADB, ok? (Well, we _will_ use it -- to talk to people whose announcements are loaded with garbadge). We simply cannot use it to talk to major service providers because policies in place cannot be represented in RIPE-81. --vadim
In message <199504192249.SAA20468@titan.sprintlink.net>, Vadim Antonov writes:
It may not have everything we want today but it is an excellent starting platform.
If i can't implement my existing policy, i cannot use RADB, ok?
(Well, we _will_ use it -- to talk to people whose announcements are loaded with garbadge). We simply cannot use it to talk to major service providers because policies in place cannot be represented in RIPE-81.
--vadim
Vadim, Mainly for the benefit of the RPS WG, could you describe the policies that you are unable to implement in RIPE-181. Curtis
Vadim:
Date: Wed, 19 Apr 1995 18:49:39 -0400 From: Vadim Antonov <avg@sprint.net> To: HANK@taunivm.tau.ac.il, avg@sprint.net, curtis@ans.net, guy@ghost.uu net.ca, jerry@fc.net CC: nanog@merit.edu, prs@isi.edu
Hank Nussbacher <HANK@taunivm.tau.ac.il> wrote:
The e-mail interface of NACRs is close to uselessness, and too big headache to deal with. Waiting time on processing is simply ridiculous.
I've been sending updates to auto-dbm@ripe.net for the past 2 years with no problem.
You don't have to keep a full-time engineer just to handle NACRs, do you?
Please be fair; most of this is a problem which Sprint brought on itself through poor follow-through with an allocation policy which you and I discussed on the phone a quite a while ago. To be clear about what is going on, let's review the history. I called you a long time ago (about a 1.5 years ago) and mentioned that it would be a lot easier on your NACR person (the pre-Lisa-Carlson person, as I remember) if you would: - decide on a consistent (net announcement ["aslist"] + AUP) for some large aggregates of IP address space, - register (NACR) those aggregates, - sit back and assign customers of like policy out of these pre-existing aggregates. Note that these customers would NOT require a NACR. You agreed and set up three /16 aggregates of what had been Class-C IP address space. From that time on, there has been a "drift" in policy away from the aggregate policy, which shows that the procedure for assigning nets from Sprint-controlled IP address aggregates was somehow ignoring what you set up. If your lead had been following by whatever internal procedures Sprint uses, then there would have been no need to NACR any customers who had policy which matched one of those aggregates. When new interconnection points were added, the aggregate's policies could have been updated, automagically updating the policy of all of the members of the aggregates. Currently, the state of Sprint policy is shown by the fact that, out of 118 "/16" aggregates, for instance, there are 2580 included prefixes which have policy which does NOT match that of the aggregates. Here's the profile: 188 "/16" Sprint aggregates have 26 different policies among themselves. These 188 aggregates include 2580 more-specific prefixes which have their own policies which differ from the /16 prefix of which they are a part. Of these 2580 prefixes, 2255 (87.4%) are completely due to Sprint (i.e., they are not caused by prefixes which have moved to have a primary AS which is not 1239, 1240, or 1800). These 2255 prefixes are contained within 65 of the "/16" aggregates (34.6% of the 188 total "/16" aggregates). Of these 65 large aggregates: 21 have 1 different policy 15 have 2 different policies 8 have 3 different policies 8 have 4 different policies 6 have 5 different policies 4 have 6 different policies 1 has 7 different policies 1 has 8 different policies 1 has 9 different policies If you sort all of these policies, you find that they can be summarized as follows: Number of: ----------------------------- more-specific "/16" aggs prefixes with in which they policy diffs are found Net announcement policy ----------------------------------------------------------------------------- 24 4 1:1239(144) 2:1239(147) 3:1239(218) 4:1800 253 20 1:1239(144) 2:1800 185 19 1:1239(144) 2:1800 3:1239(218) 2 1 1:1239(144) 2:1800 3:1239(218) 4:210 5:209 2 2 1:1239(144) 2:1800 3:1239(218) 4:3561(11) 5:3561(218) 6:685 7:73 8:101 1 1 1:1239(144) 2:1800 3:1239(218) 4:3561(218) 5:93 22 4 1:1239(147) 2:1239(144) 3:1239(218) 4:1800 3 1 1:1239(147) 2:1239(144) 3:1239(218) 4:1800 5:701 10 4 1:1239(147) 2:1239(218) 3:1239(144) 4:1800 5 4 1:1239(218) 2:1239(144) 3:1800 35 6 1:1239(218) 2:1239(147) 3:1239(144) 4:1800 149 18 1:1239(218) 2:1800 3:1239(144) 2 1 1:1239(218) 2:1800 3:1239(144) 4:3561(218) 4 2 1:1239(218) 2:1800 3:1239(144) 4:3830 3 1 1:1240 2:1800 3:1239 12 1 1:1800 130 6 1:1800 2:1133 3:1239(144) 1 1 1:1800 2:1133 3:1239(144) 4:1674 942 32 1:1800 2:1239(144) 20 1 1:1800 2:1239(144) 3:1133 16 4 1:1800 2:1239(144) 3:1133 4:1674 189 20 1:1800 2:1239(144) 3:1239(218) 1 1 1:1800 2:1239(144) 3:1239(218) 4:701(147) 5:701(134) 5 1 1:1800 2:1239(144) 3:1740(135) 1 1 1:1800 2:1239(144) 3:2149 4:174 122 15 1:1800 2:1239(218) 3:1239(144) 1 1 1:1800 2:1239(218) 3:1239(144) 4:1321 1 1 1:1800 2:1240 28 4 1:1800 2:1240 3:1133 4:1674 70 4 1:1800 2:1879 3:1133 4:1239(144) 3 1 1:1800 2:297(145) 3:297(144) 4:372 5:1133 6:1239(144) 6 1 1:1800 2:701(147) 3:701(134) 6 1 1:1800 2:701(147) 3:701(134) 4:1239(144) 5:1133 6:1674 1 1 2:1800 3:1239(218) ============================================================================= 2255 -- 34 different policies SO--by using 34 different policies, you could cover all of the more-specific; in fact, there are only 46 different Sprint-primary policies altogether (i.e., including the policies of the "/16" aggregates): 24 1:1239(144) 2:1239(147) 3:1239(218) 4:1800 253 1:1239(144) 2:1800 196 1:1239(144) 2:1800 3:1239(218) 4 1:1239(144) 2:1800 3:1239(218) 4:209 5:210 3 1:1239(144) 2:1800 3:1239(218) 4:210 5:209 1 1:1239(144) 2:1800 3:1239(218) 4:297(144) 2 1:1239(144) 2:1800 3:1239(218) 4:3561(11) 5:3561(218) 6:685 7:73 8:101 1 1:1239(144) 2:1800 3:1239(218) 4:3561(218) 5:93 23 1:1239(147) 2:1239(144) 3:1239(218) 4:1800 3 1:1239(147) 2:1239(144) 3:1239(218) 4:1800 5:701 11 1:1239(147) 2:1239(218) 3:1239(144) 4:1800 3 1:1239(147) 2:1239(218) 3:1239(144) 4:1800 5:1321 5 1:1239(218) 2:1239(144) 3:1800 35 1:1239(218) 2:1239(147) 3:1239(144) 4:1800 5 1:1239(218) 2:1239(147) 3:1239(144) 4:1800 5:3561(27) 6:3561(218) 7:93 170 1:1239(218) 2:1800 3:1239(144) 2 1:1239(218) 2:1800 3:1239(144) 4:3561(218) 4 1:1239(218) 2:1800 3:1239(144) 4:3830 3 1:1240 2:1800 3:1239 12 1:1800 138 1:1800 2:1133 3:1239(144) 1 1:1800 2:1133 3:1239(144) 4:1674 1 1:1800 2:1133 3:1239(144) 4:1849 5:3561(218) 6:3561(11) 1 1:1800 2:1133 3:1239(144) 4:3561(218) 5:3561(11) 1 1:1800 2:1133 3:1674 944 1:1800 2:1239(144) 23 1:1800 2:1239(144) 3:1133 25 1:1800 2:1239(144) 3:1133 4:1674 205 1:1800 2:1239(144) 3:1239(218) 1 1:1800 2:1239(144) 3:1239(218) 4:1325 11 1:1800 2:1239(144) 3:1239(218) 4:209 5:210 2 1:1800 2:1239(144) 3:1239(218) 4:210 5:209 2 1:1800 2:1239(144) 3:1239(218) 4:3354 1 1:1800 2:1239(144) 3:1239(218) 4:701(147) 5:701(134) 5 1:1800 2:1239(144) 3:1740(135) 1 1:1800 2:1239(144) 3:2149 4:174 1 1:1800 2:1239(144) 3:3354 124 1:1800 2:1239(218) 3:1239(144) 2 1:1800 2:1239(218) 3:1239(144) 4:1321 1 1:1800 2:1240 28 1:1800 2:1240 3:1133 4:1674 76 1:1800 2:1879 3:1133 4:1239(144) 3 1:1800 2:297(145) 3:297(144) 4:372 5:1133 6:1239(144) 6 1:1800 2:701(147) 3:701(134) 6 1:1800 2:701(147) 3:701(134) 4:1239(144) 5:1133 6:1674 1 2:1800 3:1239(218) Without analyzing the size of the IP address space consumed--which is important, to be sure--I will assume that the 118 /16s could easily hold all of the customers of each of the 46 policies. That means that Sprint has actually submitted *at least* 2255 *extra* NACRs (not including changes and deletes) which certainly is a bit of work if you do it by hand. Of course, there are some NSPs (such as BARRNet) which seem to have laid down such policies and kept to them; in fact, it seems to me that we seldom had NACR activity from BARRNet for the past year or so.
--vadim
Steve Richardson/Merit
There is a lot more on this thread so I appologise if this has already been addressed...
RIPE database does not control the actual routing.
Nor does any other registry today.
I'm not sure the current RADB project has any mention of real-time updates of gated from the database. With dozens of updates we do every day it nearly as good as useless.
The last customer request was for 5 minute intervals, which is well within the existing bounds for BGP convergance time, at least as reported by you for at least one Sprint box. Would you really want 20 peers "flapping" routes at you much faster than this? Would you like to do this to your peers? Following Dales comment, each provider may set its own parameters on generation of configurations, regardless of where it gets its data from. For those sites that choose to use the registry for generation of configurations, they have the ability to generate them in "real-time". This does not force other peers to accept these updates in "real-time", but does provide a consistent place for them to get the data when they do their own configuration runs.
If i can't implement my existing policy, i cannot use RADB, ok?
The RADB is an RPS database. The IRR is several RIPE-181 and RPS databases that are syncronized. The RPS database is a superset of RIPE-181. RIPE-181 is a superset of RIPE-81.
(Well, we _will_ use it -- to talk to people whose announcements are loaded with garbadge). We simply cannot use it to talk to major service providers because policies in place cannot be represented in RIPE-81.
--vadim
So, why not convince yourself to run an RPS database, participate in the RPS discussions, generate your own configs from your database in the timeframes you need, and make your database available to the IRR so the others have a consistent view of sprint policy? --bill
participants (4)
-
bmanning＠ISI.EDU -
Curtis Villamizar -
Steven J. Richardson -
Vadim Antonov