Are the Route Servers Viable Solutions That Are Being Held Hostage?
smd at chops.icp.net
Sun Dec 17 05:06:41 UTC 1995
-----BEGIN PGP SIGNED MESSAGE-----
Ordinarily your witchhunting on Sprint wouldn't
interest me very much, however as both SprintLink's
hesitance to bet the farm on the IRR and to commit scarce
resources towards something that is both not mission
critical nor particularly operationally useful comes out
me and my colleague Peter Lothberg and my former colleague
Vadim Antonov, I thought I might have a look.
>>>>> "Gordon" == Gordon Cook <gcook at tigger.jvnc.net> writes:
Gordon> The Route Server achieves just
Gordon> this goal: it processes routing information
Gordon> for each ISP's router, thus enabling the ISP
Gordon> routers to concentrate on packet switching.
Why not ask the interesting question: how many providers
in the community of interest served by the NSF's RA award
are there who use the RSes exclusively or the RADB
exclusively to configure their routing system?
You might even be more lenient and ask how many providers
currently have abandoned any direct peerings in favour of
a peering with the RS, and ask who they are. This sounds
like a FOIA opportunity.
The principal problem is that the RSes and the whole IRR
are only as good as the databases are, and the bulk of the
RADB was populated from the wrong source. Rather than
doing what I would consider the correct thing -- that is,
watching peerings between the RSes and the providers
participating in the various RS tests and tracking down
all the information from the IRR based on what was seen
there, verifying routing policies with end sites -- they
started with the PRDB and hoped that fate would cause the
RADB to become more correct.
To be brief and blunt, the RA team started with
information explicitly designed to PREVENT connectivity
between "bad" (evil, greedy, commercial) networks and
"good" networks which would be AUP compliant. I'd think
common sense would indicate doing some extra (and well
paid) work to instead start off with something approaching
a model of the reality of interconnectivity.
Moreover, another disappointment is that one could easily
assert that a strong reason for using the PRDB as the
source of information from day #1 was that MERIT was
already spending its resources maintaining that database
and toolset in a deal with ANS to keep ANS's network
routing working much the same way during the many months
while they figured out how to move on from the end of the
NSFNET backbone service.
In short, I think the chief failing of the RADB is not the
toolset, the concept, or the long-term plan, all of which
make some to alot of sense. Instead, what seems to have
killed it dead is that the RA was too busy to commit the
*serious* effort it would have taken to populate the RADB
with information from reality in the first place.
Even more short: overcomitted awardee, ugly shortcut, nearly useless mess.
Big people-intensive effort on fix needed.
Gordon> Bill Manning's nanog post
Gordon> talks with frustration about a large provider
Gordon> that is NOT cooperating with the routing:
Bill> Many people do register in the IRR.
Bill> Those that don't, won't for a variety of
Bill> reasons. For some, there is an unwillingness
Bill> to trust a thirdparty operator coupled with no
Bill> desire to run a portion of the registry
Funny, I see Bill using plurals there.
Of course, it's Sprint that's The Evil One (tm),
and it's not journalistically useful to print a
story about anybody else who has raised concerns
about the RADB, or who uses the IRR for strictly
limited purposes, or who participates in the IRR
as a side-effect of tools used in-house for dealing
with customer-side routing issues.
Hm, perhaps you might want to ask Bill to describe
his own routing policy, as I find:
: isis.sprintlink.net ; mwhois 'AS2885'
admin-c: Not available
tech-c: See MAINT-AS2885
changed: DB-admin at merit.edu 950201
a bit short on details.
But then, a story about the hypocrisy of some of the
players in the recurring arguments about the IRR probably
also isn't as interesting as Evil Sprint Messes Up Again (tm).
Gordon> Is the answer that the router server concept
Gordon> will necessarily fail if it does not get
Gordon> complete cooperation from **ALL** the top tier
No; the degenerate case is that a route server
talks to one and only one peer; any number of peers
beyond that increases its general utility, but does
not alter the concept.
That is, if Foo and Bar were to want to use the RA's RSes
to talk to each other rather than peer directly, that
would work despite the fact that Car, a provider Foo and
Bar both talk to directly, doesn't talk to the RSes.
Gordon> Sprint's apparent boycott
Gordon> of the concept and its service would seem to
Gordon> be a great shame.
In reality we have boycotted neither concept nor service.
What we do not do is give much credibility to any system
using the information currently in the RADB, simply
because of how utterly and obviously *wrong* so much of it
is. We also reject the frequent assertions by the RA
and its defenders that the onus is upon us to fix up their
initial database mess.
Vomit should be cleaned up by the barfer not by the barfed-upon.
Sean. (who has spent much time with mops and sponges)
P.S.: There are a number of other issues that Peter
Lothberg, a person closely associated with
RIPE-81 btw, has raised with respect to route servers.
Many of these have concerned synchronization of
multiple RSes, being able to map an entire picture
of the Internet routing system's forwarding
decisions for any given prefix, and other
complicated potential show-stoppers.
Seeing some of these dealt with would be pretty
cool. Perhaps the appropriate forum would be
-----BEGIN PGP SIGNATURE-----
Comment: PGP Public Key in ftp://ftp.sprintlink.net/engineer/smd/pgpkey
-----END PGP SIGNATURE-----
More information about the NANOG