Are the Route Servers Viable Solutions That Are Being Held Hostage?
I am confused - hope I am not the only one. A well respected member of the IETF wrote privately to me: Gordon, what do you think the RR is for? it is a database - why would it have any impact on *if* and under what conditions provider A would want to talk to provider B at a NAP? the NAP rules are *specifically* that peer-to-peer agreements are required, that is one of the reasons the NAPs are level 2 system ----------------------------------- OK - fair enough - I turned next to the routing arbiter web pages listed by bill manning. There I found the following under advantages of using the route servers of the routing arbiter: Quote: Scalable Routing As noted earlier, an ISP's routers on a NAP would need to establish full-mesh BGP peer sessions among themselves in order to exchange routing information without the presence of the RS. That is, if there were N ISPs present at a NAP, each would have N-1 peering sessions. When N is a large number, a sizable load could be placed on each router in order to maintain the required peering sessions and process the needed routing information. With the RS, each ISP only needs to peer with one RS--or two for backup purposes--instead of maintaining N-1 peer sessions. Separation of Routing and Forwarding If a NAP did not have a Route Server, each ISP router would need to perform two major functions at all times: routing processing and packet forwarding. A heavy traffic load could put a substantial extra burden on the routers, which would also need to process routing information. The load would be particularly heavy if the number of peering sessions was not small, the number of destination routes was large, and the policy was complicated. It would be ideal to have the routers concentrate on forwarding packets, and have another system handle routing. 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. Simplify Routing Configuration Management on ISP's Routers The Route Server processes routing information based on the routing policy defined by each ISP. This includes route filtering, e.g., setting up routing firewalls, selecting the desired path towards all destinations the ISP will be reaching, and other tasks that would normally be configured and implemented on the ISP routers. The RS thus greatly reduces the routing processing, filtering and configuration management load on the ISP routers at the NAPs. Note that RS can facilitate both complex and simple routing policies. For example, a policy could be as simple as to accept all the routes advertised by another ISP at a NAP. Enforce Good Routing Engineering [The text describes how the route server can be used to dampen routing flaps.] End quote. Now it sounds to me like my private corrrespondent was saying that the routing registry was only a data base. That is a source where some could go to ascertain information about someone else's routing. Period. End of discussion. Routing would be done on the basis of bilateral peering agreements between individual providers connected to the NAPs. However, the text I have quoted from the R. ARBITOR'S pages seems to say something quite different - namely that ISP's at a NAP could have a single peering session with the route server there instead of having an individual peering session for every other attached router. If true it seems like this would indeed end most of the strains and stresses on the backbone routers of service providers discussed here several weeks ago under the links on the blink thread. Yet the route server answer won't work if everyone doesn't cooperate with it and provide their routes to it. 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. When these two conditions are found in a large-scale provider, the concept and implementation of the Internet RR are frustrated to the extent that the non-participating provider becomes increasingly unreachable/understandable. They are relegated to peridoc public postings to mailing lists for definitions of their routing policies. The large scale provider he is talking about, it seems quite clear is Sprint. Question are MCI, PSI, UUNET and ANS in complete cooperation with the Routing Arbiter? Could one effectively run complete peering sessions with each of them and with smaller ISPs by a single connection to a route server?? If the answer is yes and this is not happening what is preventing it? Route Server users could run separate sessions with sprint presumably. Now Bill points out that isps would have to obtain peering agreements with others and that this process would be separate and apart from the operation of the route server which just reflects the individual peering agreements. (So in this sense the private assertion of the IETF figure is also correct.) Is the answer that the router server concept will necessarily fail if it does not get complete cooperation from **ALL** the top tier providers? If so, and IF it could really solve the resource constraints talked about in links on the blink, Sprint's apparent boycott of the concept and its service would seem to be a great shame. ******************************************************************** Gordon Cook, Editor & Publisher Subscriptions: Individ-ascii $85 The COOK Report on Internet Individ. hard copy $150 431 Greenway Ave, Ewing, NJ 08618 Small Corp & Gov't $200 (609) 882-2572 Corporate $350 Internet: cook@cookreport.com Corporate Site Lic. $650 Web: http://pobox.com/cook/ Newly expanded COOK Report Web Pages ********************************************************************
-----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-----
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. ******************************************************************** Gordon Cook, Editor & Publisher Subscriptions: Individ-ascii $85 The COOK Report on Internet Individ. hard copy $150 431 Greenway Ave, Ewing, NJ 08618 Small Corp & Gov't $200 (609) 882-2572 Corporate $350 Internet: cook@cookreport.com Corporate Site Lic. $650 Web: http://pobox.com/cook/ Newly expanded COOK Report Web Pages ********************************************************************
-----BEGIN PGP SIGNED MESSAGE-----
"Gordon" == Gordon Cook <gcook@tigger.jvnc.net> writes:
Gordon> Sean, I am trying learn and understand and if Gordon> I was unnecessarily harsh on sprint I Gordon> apologize. Ok, no big deal. Like everyone else, we have our share of whoppingly bad mistakes, but it's nicer to get beaten up for those than for imaginary things. (Well, actually, it's nicer to get people to repeat all the wonderful things about us, but then we call such people PR agents and pay them lots of money :-) ) The NSF's new architecture as I understand it was principally designed as a way for the NSF to get out of the business of supplying production networking services itself by dumping the funded regional networks onto commercial providers without having to worry that those networks would end up on multiple providers who didn't talk to each other. Parts of the NSF93-52 scheme have worked quite well, other parts not so well, and other parts have so completely surpassed all predictions for success as to be somewhat frightening on engineering and planning fronts. I imagine that the NSF is already thinking "What Next" and could well be planning a further devolution of funding to the level of Universities (or perhaps even to funded projects). The problem with the NSF thinking "What Next" is typically that the Internet moves faster than it does, so by the time a programme is underway, it is in danger of being obsolete or wrong-headed. One could argue that some of NSF 93-52 is already in one or both of those boats. Planning for X being experimental and then seeing at the time the plan is approved that X is about to be rolled into production and X**2 is being designed for because of anticipated production need probably gives people ulcers. On the opposite side of the coin, planning for X, later needing X, but getting something considerably less than X gives the Internet ulcers, as we have seen from time to time with parts of the NSF's new design thingie. I think both types of flaw should be more easily correctable than they appear to be right now, but then sometimes I think the same about telcos... Sean. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: PGP Public Key in ftp://ftp.sprintlink.net/engineer/smd/pgpkey iQCVAwUBMNO1RESWYarrFs6xAQEZvAP+NVSIouUlX3ep3fdqe/4dIivL8lJLkpE4 qpCCQJdQfgZoz0D2T5iC9M8Q+crb+1ebwFu+y3lIbuphQs0pbrKSdoRve7FZcSc9 tmEu+zV0sOPXrhJuYE5lIll455KGBli0OA8TAUb20biMdhkdKQIQ7zHawZY8R+6p nNdwhYmCWhc= =iUPS -----END PGP SIGNATURE-----
Gordon, ] 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. Yesterday I wandered into Radio Shack in my festive holiday wanderings, and happened upon a small man wearing a name tag that said "Bud". I asked Bud, "Bud, will your I/R to RF transcievers send data at greater than 2.4kps?". "No", replied Bud. "And will your I/R to RF transcievers send data bidirectionally?" I asked Bud. "No", replied Bud. And while no money changed hands, I would gladly have paid to learn that this was technology I could not use. -alan
On Mon, 18 Dec 1995, Alan Hannan wrote:
Yesterday I wandered into Radio Shack in my festive holiday wanderings, and happened upon a small man wearing a name tag that said "Bud".
I asked Bud, "Bud, will your I/R to RF transcievers send data at greater than 2.4kps?".
"No", replied Bud.
"And will your I/R to RF transcievers send data bidirectionally?" I asked Bud.
"No", replied Bud.
And while no money changed hands, I would gladly have paid to learn that this was technology I could not use.
Yes, but I think that is just the Radio Shack answer. I ask "Do you have a 7404 hex inverter" Radio Shack guy "No", well "well what is this then" I say when I show him a stack of 7404's he has on his shelf. Radio (oh we don't have that, well why is it on your shelf) Shack. :-) Nathan Stratton CEO, NetRail, Inc. Your Gateway to the World! --------------------------------------------------------------------------- Phone (703)524-4800 NetRail, Inc. Fax (703)534-5033 2007 N. 15 St. Suite 5 Email sales@netrail.net Arlington, Va. 22201 WWW http://www.netrail.net/ Access: (703) 524-4802 guest ---------------------------------------------------------------------------
In the 1970's, few seemed to care about the environmental problems caused by population growth. However, some insightful folks anticipated the problems and began to work on solutions for the impending doom. These folks created and operated a recycling outfit and made it easy for the population to do the right thing: recycle. Still, some folks were downright insistent that *they* weren't going to recycle, and that they were going to throw newspaper in the trash and old oil down the sewer. Eventually, these folks were not allow to dump their waste in the community landfill and were force to sit in their own stink. Appropo of nothing. Just a story I remember hearing as a kid. Bill ------------------------------------------------------------------------- William B. Norton Merit Network Inc. e-mail: wbn@merit.edu phone: (313) 936-2656 WWW: http://home.merit.edu/~wbn
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. ******************************************************************** Gordon Cook, Editor & Publisher Subscriptions: Individ-ascii $85 The COOK Report on Internet Individ. hard copy $150 431 Greenway Ave, Ewing, NJ 08618 Small Corp & Gov't $200 (609) 882-2572 Corporate $350 Internet: cook@cookreport.com Corporate Site Lic. $650 Web: http://pobox.com/cook/ Newly expanded COOK Report Web Pages ********************************************************************
In message <Pine.SUN.3.91.951220005149.13779L-100000@tigger.jvnc.net>, Gordon C ook writes: 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? I offer the theory that the lack of response was due primarily to people who have real work to do. 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. The information taken from the PRDB was the prefix itself, contact information, and the AS690 advisory fields. The origin AS was not in the PRDB. This was instead populated by asking people to register the correct origin AS or by observed AS paths where there was no response. The origin AS fields are largely incorrect due to truncated AS paths which results from using the exact technique that Sean prescribes, looking at the routing table for a source of information. The AS690 advisories were also largely incorrect due to the topology changes that occurred during NSFNET transition not being reflected. This was also largely due to the AS690 advisory method of configuration becoming increasingly unwieldy as the network has grown. The AS690 advisories are now gone. ANS policy is now entirely expressed in the AS690 aut-num (the authoritative aut-num is in the database named "anstest" on configs.ans.net). The move to clean up ANS policy (greatly reducing inconsistencies and simplifying the policy) is underway and making good progress (for example, in the last 7 days the size of the AS690 aut-num object was reduced by about 4,000 lines due to simplifications of policy and increased use of BGP4 MED). 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. This is pure flamage. The only thing the AUP reflected in the RADB was whether the comm-list for a route contained the community COMM_NSFNET was set. Since no one uses that community for anything (that I'm, aware of), it has no effect. A lot of the route objects were picked up simply from route dumps at the CIX, when ANS policy was to automatically register in the PRDB any route found at the CIX as a commercial only route with CIX connectivity only. That was hardly designed to prevent connectivity. 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. ANS did and still does want to maintain the most reliable routing possible toward anyone willing to register accurate information in the IRR. The only choices for starting the database was to start empty or start with the best information available at the time. 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. I don't see how Sean expects the RA to populate contact information, origin AS, maintainance authorization and notification fields, AS connectivity, based on seeing an BGP route in a routing table. I also don't think Sean is entirely representing Sprint, since others at Sprint are populating information so their customers get connectivity. The RA is working on a lot of analysis tools. Among them are verification tools to determine whether what is observed in BGP updates is feasible based on what is present in the IRR. The attempt is being made to make entering information as easy as possible for those who do not wish to fully participate. When a new AS appears, an aut-num object should be entered so people have a basis for determining backup paths in addition to a primary path. If new prefixes appear, all that needs to be registered to get routing right is the prefix and origin AS. Correct contact information is a nice idea too, be we can route without it if we have to. There are many parties contributing toward improving the accuracy of the IRR, whether by developing better tools or by adding information or correcting information for which they are authoritative. The tools right now are primarily coming out of the RA. There are also those who are not contributing to improving the accuracy of the IRR or even worse persistantly whining about it or flaming others who are. Those people doing real work are trying hard to just ignore those who are whining and flaming. ******************************************************************** Gordon Cook, Editor & Publisher Subscriptions: Individ-ascii $85 The COOK Report on Internet Individ. hard copy $150 431 Greenway Ave, Ewing, NJ 08618 Small Corp & Gov't $200 (609) 882-2572 Corporate $350 Internet: cook@cookreport.com Corporate Site Lic. $650 Web: http://pobox.com/cook/ Newly expanded COOK Report Web Pages ******************************************************************** Curtis
participants (6)
-
Alan Hannan -
Curtis Villamizar -
Gordon Cook -
Nathan Stratton -
Sean Doran -
William B. Norton