Are the Route Servers Viable Solutions That Are Being Held Hostage?

Gordon -

   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.

    > The Route Server achieves just
    > this goal: it processes routing information
    > for each ISP's router, thus enabling the ISP
    > 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.

Now:

    > Bill Manning's nanog post
    > talks with frustration about a large provider
    > that is NOT cooperating with the routing:

    > Many people do register in the IRR.
    > Those that don't, won't for a variety of
    > reasons. For some, there is an unwillingness
    > to trust a thirdparty operator coupled with no
    > desire to run a portion of the registry
    > in-house.

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'
aut-num: AS2885
as-name: NAP-FOUR
descr: NAP-FOUR
admin-c: Not available
tech-c: See MAINT-AS2885
mnt-by: MAINT-AS2885
changed: DB-admin@merit.edu 950201
source: RADB

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).

    > Is the answer that the router server concept
    > will necessarily fail if it does not get
    > complete cooperation from **ALL** the top tier
    > providers?

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.

    > Sprint's apparent boycott
    > of the concept and its service would seem to
    > be a great shame.

"Apparent".

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
  big-internet?

Sean,

I am trying learn and understand and if I was unnecessarily harsh on
sprint I apologize. Thank you for setting forth your point of view as
eloquently as you have. I hope that MERIT and ANS will address the
issues that you have raised. I see the routing arbiter as one a part of
the new architecture that I have so far not understood and I was/am
beginning to wonder whether it might hold some promise for solving some
of the backbone stress problems I wrote about in my last newsletter.
please remember that i have not officially published anything on this issue
yet. Nsf is spending $10 million a year on the 2 RA coop
agreements....right? seems like they should be getting something more
useful for the money than so far has been the case.

On Sunday the 17th of December Sean Doran stated pretty clearly why
Sprint wasn't using the Routing Arbiter database. I am very surprised
that neither Bill Manning or Elise Gerich or anyone else involved with
the project has so far come back and said no...Sean....your
interpretation was wrong. Here is what we did. And we did this
because........ Does the lack of response from the Routing arbiter to
Sean mean that it has no problems with Sean's description of what it did
and why it did it?

To refresh folk's minds, here is what Sean said:

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.