Mailing List Archive

In message <Pine.SUN.3.91.951226143523.1922H-100000@tigger.jvnc.net>, Gordon Co
ok writes:

Dear concerned netizen, :-)

> COOK: So when you say 20% of the routes have been removed, how does one
> judge what remains that is defunct and still remains to be removed???? Of
> the 80% does anyone have a clue as to whether 95% of the 80% are "good" or
> whether the real total of good routes might be on 50% of the 80%??

The US had the PRDB and Europe had the RIPE database and both were
good things. The RIPE database was a better format since the PRDB was
AS690 specific. The PRDB had accurate data but no origin AS and some
field mismatches with the RIPE-181 format, but served as a good seed.
For the most part, the 20% that was removed at CANET, ANS, RIPE, and
MCI request is now better validated and resides in these databases.
The remaining 80% is not neccisarily wrong. The only thing that need
to be right is the mapping of prefix to origin AS, since the origin AS
is primarily what people who generate prefix lists use as the basis
for routing. It would be nice if the contact information was right
too, but not essential.

The job of removing any inaccuracies due to remnants of the old PRDB
AS690 policy which became the AS690 advisories for a (too long)
interim period is squarely in the hands of ANS and we're working on it
but not by throwing up our hands and throwing it all out as some
suggest. We are going through it somewhat systematicly, verifying
policy toward origin AS and specific exceptions, with priority given
to any routing trouble tickets that arise. Doing this manually is not
a very promising approach, so we are hoping for better tools to help
identify obvious problems and building some ourselves.

The PRDB was used mostly to populate route objects. The stuff that
was originally populated from the PRDB, if unchanged would have a
"changed field" with nsfnet-admin@merit.edu in it. If that's gone,
then someone updated the information. If still there, either the
information wasn't updated or whoever updated didn't change the field
(it wasn't checked until recently). There are 23,175 such records
(with nsfnet-admin@merit.edu in the changed field) of 45,361 in the
RADB (local copy ftp'd yesterday). In the 5 IRR databases, there are
a total of 342,720 records (counting aut-nums, people, inetnums, route
objects, and everything else). The IRR is more than just the RADB and
the RADB data, though seeded from the PRDB and initially somewhat
questionable, is clearly being maintained. [.note: these counts are
based on some quick greps, but I think they are accurate.]

> Now Elise has questioned the propriety of using NANOG for questions about
> the routing arbiter. Fine. But as far as I can tell no one is running a
> routing arbiter mail list. Without such a list the only choice is to
> take things to one on one private mail with bill manning and/or elise.

I didn't save Elise's message but I think she was asking that the
public "feedback" on the quality of Sprint's service (and everyone
else mentioned) didn't fall under the umbrella of operational issues
requiring cooperation among providers (or whatever the wording was).

I don't think any new mailing list is needed.

Curtis

Curtis, that was very helpful -- thank you!

If I could ask a few further questions. You said:

"The RIPE database was a better format since the PRDB was AS690 specific."

May I ask: Is AS690 the Autonomus System number for ANS? I understand
indeed that the PRDB was ANS specific but how exactly did that make the
Ripe Database a better format? If it was a better format, it couldn't be
used because the PRDB had components that were not transferrable to
RIPE? Are you saying that to transfer the ANS database into RIPE format
would have taken a very sizable number of person months?

Just testing whether I understand you correctly. Glad to know that you
think nanog is appropriate for this discussion.

I am trying to understand where we are at this point and am not trying to
saddle any particular person or entity with any blame. You are being
helpful and I appreciate that.

*********************************************************************
Gordon Cook, Editor & Publisher Subscriptions: Individ-ascii $85
The COOK Report on Internet Individ. hard copy $150
431 Greenway Ave, Ewing, NJ 08618 USA Small Corp & Gov't $200
(609) 882-2572 Corporate $350
Internet: cook@cookreport.com Corporate Site Lic. $650
http://pobox.com/cook/ for new COOK Report Glossary of Internet terms
*********************************************************************

Gordan:

On Thursday 12/28 you enclosed with the text below:


>May I ask: Is AS690 the Autonomus System number for ANS? I understand
>indeed that the PRDB was ANS specific but how exactly did that make the
>Ripe Database a better format? If it was a better format, it couldn't be
>used because the PRDB had components that were not transferrable to
>RIPE? Are you saying that to transfer the ANS database into RIPE format
>would have taken a very sizable number of person months?

To help you understand the PRDB, I offer some historical
information from an engineer's perspective:

The concepts and the some of the code for the PRDB database system
predate even ANS's creation. The PRDB concepts come from
the early days of the NSFNET and trying to run that specific network.
The multiple ISP/NSP world has come upon the Internet to replace
the NSFNET. This change was requested by some people to provide
a fair marketplace in the Internet.

The routing registration shift from PRDB to RIPE/IRR
format reflects a shift in the Internet reality, not an
ANS database specific project. The effort to keep the NSFNET
service current was an engineering effort over years.
We moved from 1/3 T1 to T1 to T3. Our databases also migrated
implementations and service capabilities. The PRDB was the
third in a series of the databases. RIPE could be considered
the fourth.

I hope this has helped fill in some history around Curtis's comments.


Sue Hares
Merit

It even predates the T1/... NSFNET backbone. We already used something
like that for the 56kbps Fuzzball based NSFNET backbone. In a sense,
the RIPE db etc. are latecomers here. Susan is correct, the NSFNET
implemented and formalized the routing data base in evolutionary
stages. Often despite complaints from many sites that wanted free and
uncontrolled flow of routing information.

I am not arguing about whether the RIPE and the RA DB should or should
not be merged, just that there is a history to the steps taken, and
reconciling into a homogenious DB (format) would have to be a concious
effort by the parties seeing mutual benefit. Not that it should not
happen otherwise, it just won't, given project priorities.

>Gordan:
>
>On Thursday 12/28 you enclosed with the text below:
>
>
>>May I ask: Is AS690 the Autonomus System number for ANS? I understand
>>indeed that the PRDB was ANS specific but how exactly did that make the
>>Ripe Database a better format? If it was a better format, it couldn't be
>>used because the PRDB had components that were not transferrable to
>>RIPE? Are you saying that to transfer the ANS database into RIPE format
>>would have taken a very sizable number of person months?
>
>To help you understand the PRDB, I offer some historical
>information from an engineer's perspective:
>
> The concepts and the some of the code for the PRDB database system
> predate even ANS's creation. The PRDB concepts come from
> the early days of the NSFNET and trying to run that specific network.
> The multiple ISP/NSP world has come upon the Internet to replace
> the NSFNET. This change was requested by some people to provide
> a fair marketplace in the Internet.
>
> The routing registration shift from PRDB to RIPE/IRR
> format reflects a shift in the Internet reality, not an
> ANS database specific project. The effort to keep the NSFNET
> service current was an engineering effort over years.
> We moved from 1/3 T1 to T1 to T3. Our databases also migrated
> implementations and service capabilities. The PRDB was the
> third in a series of the databases. RIPE could be considered
> the fourth.
>
>I hope this has helped fill in some history around Curtis's comments.
>
>
>Sue Hares
>Merit
>

On Wed, 3 Jan 1996, Hans-Werner Braun wrote:

> It even predates the T1/... NSFNET backbone. We already used something
> like that for the 56kbps Fuzzball based NSFNET backbone. In a sense,
> the RIPE db etc. are latecomers here. Susan is correct, the NSFNET
> implemented and formalized the routing data base in evolutionary
> stages. Often despite complaints from many sites that wanted free and
> uncontrolled flow of routing information.

isn't this exactly what is achieved by providing radb? including the
individual's routing policies, so my system can find a nice compromize
between what the providers around me want, and what I need?

'in spite of': guess the job is done just for that.

For me, it is important to have access to routing info and policy
advertisements, so I know better what's going on around us here.

... and if someone wants to make it a secret: hint:

from ... accept any
to ... announce <mine>


with this, your routes are all represented, your AS is well defined, and
what your route maps do (in cisco lingo), or your netsentry, or your
filter, is your private issue. No reason not to participate, even with a
blank statement like the one above. BTW: mine is blank, because I do a
conservative approach: accept anything, announce clean. ;-)

Or tell anybody how you want it, guess what: bgp makes it happen as close
as possible.(with RS and some little wood shims, no effort no gain of course)

Database format: a fight about 'better' or 'worse' is , mho, just stupid:
better changes with time. New features bring new ideas and new needs for,
guess what: new features.

The evolutionary process is the best one, since
every worthy contribution will prevail, and good meant tries will vanish
silently.

The informal process existing is excellent too: no red tape for real good
improvements.

To me, the radb is worth a hell of a lot for all kinds of tasks, not only
routing (e.g. location, performance tests, yni).

I personally say here: this is a good thing, no matter from where it
comes. And if a provider with particularly bright and friendly people is
heavily envolved: the better for all the others, no?

Mike

>
> I am not arguing about whether the RIPE and the RA DB should or should
> not be merged, just that there is a history to the steps taken, and
> reconciling into a homogenious DB (format) would have to be a concious
> effort by the parties seeing mutual benefit. Not that it should not
> happen otherwise, it just won't, given project priorities.
>
> >Gordan:
> >
> >On Thursday 12/28 you enclosed with the text below:
> >
> >
> >>May I ask: Is AS690 the Autonomus System number for ANS? I understand
> >>indeed that the PRDB was ANS specific but how exactly did that make the
> >>Ripe Database a better format? If it was a better format, it couldn't be
> >>used because the PRDB had components that were not transferrable to
> >>RIPE? Are you saying that to transfer the ANS database into RIPE format
> >>would have taken a very sizable number of person months?
> >
> >To help you understand the PRDB, I offer some historical
> >information from an engineer's perspective:
> >
> > The concepts and the some of the code for the PRDB database system
> > predate even ANS's creation. The PRDB concepts come from
> > the early days of the NSFNET and trying to run that specific network.
> > The multiple ISP/NSP world has come upon the Internet to replace
> > the NSFNET. This change was requested by some people to provide
> > a fair marketplace in the Internet.
> >
> > The routing registration shift from PRDB to RIPE/IRR
> > format reflects a shift in the Internet reality, not an
> > ANS database specific project. The effort to keep the NSFNET
> > service current was an engineering effort over years.
> > We moved from 1/3 T1 to T1 to T3. Our databases also migrated
> > implementations and service capabilities. The PRDB was the
> > third in a series of the databases. RIPE could be considered
> > the fourth.
> >
> >I hope this has helped fill in some history around Curtis's comments.
> >
> >
> >Sue Hares
> >Merit
> >
>
>

*********************************************************************
* Unsolicited Commercial E-Mail will cost $500/message under USC 47 *
* which can be found online at http://www.law.cornell.edu/uscode/47/*
*********************************************************************
----------------------------------------------------------
IDT
Michael F. Nittmann ---------
Senior Network Architect \ /
(201) 928 1000 xt 500 -------
(201) 928 1888 FAX \ /
mn@ios.com ---
V
IOS

> hwb@upeksa.sdsc.edu (Hans-Werner Braun) writes:
> It even predates the T1/... NSFNET backbone. We already used something
> like that for the 56kbps Fuzzball based NSFNET backbone. In a sense,
> the RIPE db etc. are latecomers here. Susan is correct, the NSFNET
> implemented and formalized the routing data base in evolutionary
> stages.


Indeed there is an evoloution of routing policy databases/registries.

The early NSFnet one was done to configure a single backbone. Remember
that EGP was the state-of-the-art. NSFNet provided last resort routing
and everyone was happy. More complex registries were not needed to keep
track of this even when "back doors" appeared.

In Europe the situation was not like that at all. Despite great efforts
we were never blessed with a single pan-European backbone or even a
last-resort routing service. This is why RIPE developed a routing
registry that was capable of being useful in a general topology of
indepoendent ISPs. We weren't more clever or had more foresight, we
simply had the need earlier.

I think it has been a good decision by the RA team to use this
technology and to contribute to its development rather than inventing
something new right away. Given the resources I would hope for more
output in the way of tools etc. but I see it coming now.

> Often despite complaints from many sites that wanted free and
> uncontrolled flow of routing information.

This is a great misconception about routing registries which comes from
the time of the single backbone model. The routing registry and the
backbone were then operated by the same people and used to enforce The
Routing Policy. The situation is different now. Each ISP sets and
enforces their routing policy. The routing registry only supports them
in this.

Of course a good routing policy is to not propagate routes to address
space which is not assigned and to generally filter announcements from
customers. But there is no way to use the routing registry to force
ISPs to do reasonable things.

> I am not arguing about whether the RIPE and the RA DB should or should
> not be merged, just that there is a history to the steps taken, and
> reconciling into a homogenious DB (format) would have to be a concious
> effort by the parties seeing mutual benefit. Not that it should not
> happen otherwise, it just won't, given project priorities.

I am pessimistic at all. All routing registies use the same schema or
very very similar ones. They currently call come from the ripe-181
specifications which are based on input from the RA people. The RADB,
RIPE RR, MCI RR and all the others really form a global Internet RR
which is quite useful already and can be made more useful.

Two things are needed now:

1) Improve active maintenance by the registrars. This will by itself lead
to better alignment between registries and remove duplicate registrations.

2) Produce and *deploy* more useful tools.

If this is done well, ISPs will use those registries more and register in
them because it is useful and interest.

Daniel

>From list-admin@merit.edu Thu Jan 4 05:03:27 1996
>Message-Id: <9601040929.AA14593@ncc.ripe.net>
>To: hwb@upeksa.sdsc.edu (Hans-Werner Braun)
>Cc: nanog@merit.edu, RIPE Routing WG <routing-wg@ripe.net>
>Subject: Question on % of good routes and plea for an RA mail list was Re: Routing registry was Re: Sprint BGP filters in 207.x.x.x?
>In-Reply-To: Your message of Wed, 03 Jan 1996 15:21:50 PST.
> <199601032321.PAA24966@upeksa.sdsc.edu>
>References: <199601032321.PAA24966@upeksa.sdsc.edu>
>From: Daniel Karrenberg <Daniel.Karrenberg@ripe.net>
>Date: Thu, 04 Jan 1996 10:29:49 +0100
>Sender: Daniel.Karrenberg@ripe.net

>The early NSFnet one was done to configure a single backbone. Remember
>that EGP was the state-of-the-art. NSFNet provided last resort routing
>and everyone was happy. More complex registries were not needed to keep
>track of this even when "back doors" appeared.
>
>In Europe the situation was not like that at all. Despite great efforts
>we were never blessed with a single pan-European backbone or even a
>last-resort routing service. This is why RIPE developed a routing
>registry that was capable of being useful in a general topology of
>indepoendent ISPs.

FYI:

Lest anyone think that the PRDB was single-backbone-specific in
_design_ or capability (it pretty much was in terms of data), let
me note that, when Andy Adams and I rewrote the PRDB from a SPIRES
DB to a RDBMS (with help from Tom Libert and Sue Hares), we explicitly
designed in the ability to include data from other backbones.

This was initially done to support both the T1 and T3 backbones, but
it could easily have supported other backbones as well.

>Daniel


Steve Richardson/Merit

> "Steven J. Richardson" <sjr@merit.edu> writes:
>
> Lest anyone think that the PRDB was single-backbone-specific in
> _design_ or capability (it pretty much was in terms of data), let
> me note that, when Andy Adams and I rewrote the PRDB from a SPIRES
> DB to a RDBMS (with help from Tom Libert and Sue Hares), we explicitly
> designed in the ability to include data from other backbones.
>
> This was initially done to support both the T1 and T3 backbones, but
> it could easily have supported other backbones as well.

I know that, but if I recall things correctly the concept was one of
just extending the number of "backbones" (i.e. last-resort routing
services) and dit not support all implementable policies between autonomous
ASes in a basically arbitrary topology. Or am I wrong?

Daniel