-----BEGIN PGP SIGNED MESSAGE----- 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.
"Gordon" == Gordon Cook <gcook@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. Now: 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 Bill> 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). 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 Gordon> 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. Gordon> Sprint's apparent boycott Gordon> of the concept and its service would seem to Gordon> 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? -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: PGP Public Key in ftp://ftp.sprintlink.net/engineer/smd/pgpkey iQCVAwUBMNOlUkSWYarrFs6xAQFOowP/VLELHPJxDGI7IhyZFgPT1qVExk/4ekTH lxvQcqhCSRzgUaqSDgv+/SOBb47Kui/gGEYxCLbwbucHdR3kt9vAlw4I0LyhbSKs OfGT0P89jnCIzK83teDo2W2zxBf3HyijeZbAIAEZ/ou47ourXASZnPkTe/w8yvU1 DhsS+nWdXhc= =JwWQ -----END PGP SIGNATURE-----