|
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: [email protected] Corporate Site Lic. $650
Web: http://pobox.com/cook/ Newly expanded COOK Report Web Pages
********************************************************************
|