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
>
> >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: