Has PSI been assigned network 1?
Steven J. Richardson
sjr at merit.edu
Thu Apr 20 06:14:25 UTC 1995
Vadim:
> Date: Wed, 19 Apr 1995 18:49:39 -0400
> From: Vadim Antonov <avg at sprint.net>
> To: HANK at taunivm.tau.ac.il, avg at sprint.net, curtis at ans.net, guy at ghost.uu
net.ca,
jerry at fc.net
> CC: nanog at merit.edu, prs at isi.edu
> Hank Nussbacher <HANK at 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 at 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
More information about the NANOG
mailing list