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

Gordon Cook gcook at
Thu Dec 14 00:06:51 UTC 1995

I am confused - hope I am not the only one.

A well respected member of the IETF wrote privately to me:

        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 

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 

        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 

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 at              Corporate Site Lic.  $650
Web:    Newly expanded COOK Report Web Pages 

More information about the NANOG mailing list