Re: Has PSI been assigned network 1?
FYI -- Sprint never submitted NACRs on behalf of customers, for purely legal reasons. As common carrier Sprint is legally prohibited from enforcing anything related to contents of communications, hence it couldn't enter legal agreements on AUP-compliance in regard to customer traffic. So, we HAVE to pass thru all NACRs (and don't forget that 1800 has most of Europe to care about). --vadim
From sjr@merit.edu Thu Apr 20 02:14:32 1995 Received: from tiny.sprintlink.net (tiny.sprintlink.net [199.0.55.90]) by titan.sprintlink.net (8.6.9/8.6.9) with ESMTP id CAA22156 for <avg@titan.sprintlink.net>; Thu, 20 Apr 1995 02:14:31 -0400 Received: from home.merit.edu (home.merit.edu [198.108.60.42]) by tiny.sprintlink.net (8.6.9/8.6.9) with ESMTP id CAA22402 for <avg@sprint.net>; Thu, 20 Apr 1995 02:14:29 -0400 Received: from localhost (sjr@localhost) by home.merit.edu (8.6.12/merit-2.0) with SMTP id CAA21817; Thu, 20 Apr 1995 02:14:26 -0400 Message-Id: <199504200614.CAA21817@home.merit.edu> To: Vadim Antonov <avg@sprint.net> cc: HANK@taunivm.tau.ac.il, curtis@ans.net, guy@ghost.uunet.ca, jerry@fc.net, nanog@merit.edu, prs@isi.edu Subject: Re: Has PSI been assigned network 1? In-reply-to: Your message of Wed, 19 Apr 1995 18:49:39 EDT. <199504192249.SAA20468@titan.sprintlink.net> Date: Thu, 20 Apr 1995 02:14:25 -0400 From: "Steven J. Richardson" <sjr@merit.edu> Status: R
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
Vadim: Even given your need to:
So, we HAVE to pass thru all NACRs (and don't forget that 1800 has most of Europe to care about). [ for legal reasons]
We've talked to most of your "pass-thru" clients, to help them. Through my interactions with these clients in the last months I've had the repeated joy of learning how to give CIDR tutorials over the phone. These clients have also lacked a knowledge base about CIDR or NACRs. If your network implementation staff received more training, perhaps they could train your "pass-thru" clients and relieve some stress for your clients. Again, I hope that your management will allow you the time it takes to train others. Best wishes, Sue Hares
So, we HAVE to pass thru all NACRs (and don't forget that 1800 has most of Europe to care about). [ for legal reasons]
We've talked to most of your "pass-thru" clients, to help them. Through my interactions with these clients in the last months I've had the repeated joy of learning how to give CIDR tutorials over the phone.
These clients have also lacked a knowledge base about CIDR or NACRs. If your network implementation staff received more training, perhaps they could train your "pass-thru" clients and relieve some stress for your clients.
Again, I hope that your management will allow you the time it takes to train others.
So are all the routing engineers hanging out at merit, then? If you know of people, be sure and let me know. In the mean time, I have to take people with only Unix basics, and teach them IP networking basics just to make them useful in some capacity. If better people were available, we'd have them. It puts a big load on our core of talented staff to deal with all the problems that come up, and not much time for training. My guess is that Sprint is in a very similar situation. It's hard to find good people, and even more difficult to step away from demanding customers to invest in your future, as important as it may be. Dave -- Dave Siegel, Director of Engineering Network (99) Operations Center (800)638-9947 (602)249-1190 after hours dsiegel@net99.net
Dave: It's pleasure to hear from you. Network Operation have always been a challenge balancing immediate HAVE-To-Do's with training. Training takes time, and I've trained several folks at MERIT in routing - so I've help build the "Internet pool". ;-) The original query from Vadim was "why did NACR processing take so long". My response was his people were taking a great deal more time than needed since they did not understand CIDR or aggregation. Sprint's policy - as Steve Richardson noted - has some very interesting twists due to the requirements and their network's routing design. The note about lack of training was not a comment on Sprint or Vadim - it was simply to denote that it takes more time to perform a function if you don't understand it. Many people do not learn well under a crunch time period. You may be gifted to learn in that environment. NANOG has held sessions on the NACRs, RADB and many other things. We also have a web page at MERIT describing these things. The templates at MERIT and memos tried to help the NACR system. One thing I found was that several of the new ISPs were coming on-line with out the basis of knowledge that established networks. So.. as I talked to you and others we tried to rapid fire catch up and on the phone training to short cut proces of NACR training. We did this instead of point you to endless documents. It probably left you and I unsatisfied - but most compromises do. Next time would you have me point you to a list of documents in your crunch period? I really would appreciate an honest answer because it sounds you were not fully satisfied with NACRs. Sue Hares
participants (3)
-
net99＠net99.net -
Susan Hares -
Vadim Antonov