North American Network Operators Group|
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical
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: firstname.lastname@example.org Corporate Site Lic. $650 Web: http://pobox.com/cook/ Newly expanded COOK Report Web Pages ********************************************************************