alternative to full mesh IBGP", RFC2796, April 2000.
[8] Traina, P., "Autonomous System Confederation Approach to Solving
the I-BGP Scaling Problem", RFC1965, June 1996.
[9] Curtis, V., Chandra, R. and R. Govindan, "BGP Route Flap
Damping", RFC2439, November 1998.
[10] Fuller, V., Li, T., Yu, J. and K. Varadhan "Classless Inter-
Domain Routing (CIDR): an Address Assignment and Aggregation
Strategy", RFC1519, September 1993.
[11] Villamizar, C., Alaettinoglu, C., Govindan, R. and D. Meyer,
"Routing Policy System Replication", RFC2769, February 2000.
[12] Bates, T., Bush, R., Li, T. and Y. Rekhter, "DNS-based NLRI
origin AS verification in BGP", Work in Progress.
[13] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Signature Option", RFC2385, August 1998.
[14] E. Chen, "Routing Scalability in Backbone Networks." Nanog
Presentation: http://www.nanog.org/mtg-9901/ppt/enke/index.htm
[15] T. Li, T. Przygienda, H. Smit, "Domain-wide Prefix Distribution
with Two-Level IS-IS", Work in Progress.
Author's Address
Jieyun (Jessica) Yu
CoSine Communications
1200 Bridge Parkway
Redwood City, CA 94065
EMail: jyy@cosinecom.com
Appendix A. Out-of-Band Routing Processes
The use of a Route Server(RS) at NAPs is an example of achieving
routing scalability through an out-of-band routing process. A NAP is
a public inter-connection point where ISP networks exchange traffic.
ISP routers at a NAP establish BGP peer sessions with each other. The
result is full mesh E-BGP peering with a complexity of O(N^2) system
wide. When the RS is in place, each router peers only with the RS
(and its backup) to obtain necessary routing information (or more
precisely, the necessary forwarding information). In addition, the RS
also filters routes and executes policy for each provider's router,
which further reduces the burden on all routers involved.
The concept of the Route Server can also be used to help address
routing scalability in a large network.
1) RS Assisted Peering between Customer Aggregation Router and
Customer Routers
Currently, in a typical large provider network, it's not unusual that
a customer aggregation router connects up to hundreds of customer
routers. That means the router has to handle hundreds of E-BGP
sessions and filter a large number of prefixes. These tasks impose a
heavy burden on the aggregation router. Reducing the number of
customer routers per aggregation router is not an optimal option,
since this would introduce more routers in the routing system of the
whole network, which is neither scalable for backbone routing, nor
cost efficient. Using an RS between customers and the providers'
customer aggregation router become an attractive option to reduce the
burden on the router.
Figure 1 shows one way of incorporating an RS router between a
provider's customer aggregation router and customer routers.
--------------------------- LAN Media in a POP
| |
----- -----
|CR | |RS |
----- -----
/ | \
/ | \
C1 C2..Cn
Figure 1: RS serving customer aggregation router connecting
customer routers
In a scenario without an RS, the customer aggregation router(CR) has
to peer with customer routers C1, C2 ... Cn (where n could be in the
hundreds). When an RS router is introduced, CR, C1, C2 ... Cn peer
with the RS router instead, and the RS passes the processed routing
information (or forwarding information) to all of them, according to
policy and filters.
The advantages are obvious:
o The customer aggregation router peers only with the RS router
instead of with hundreds of customer routers.
o The customer aggregation router does not need to filter prefixes
or process routing policies, which frees resources for packet
forwarding and handling.
One general concern with the use of an RS router is the possibility
of a mismatch of routing connectivity and the physical connectivity.
For example, if the link between the CR and C1 is down and if the RS
router is not aware of the outage, it will continue to pass routes
from C1 to the CR, and the traffic following these routes will be
black holed. However, this is not a problem in the specific
application described here. This is because the RS router has to go
through the CR to peer with C1, C2 ... Cn. When the link is down, C1
is inaccessible from the RS router, and no routing information can be
exchanged between the two. Consequently, the RS will announce no
routes related to C1.
Another concern is the creation of single point of failure. If the RS
router is down, no routing information can be exchanged between the
customer aggregation router and C1, C2 ... Cn, and no traffic will
flow between them. This problem could be addressed by adding a second
RS router as a backup.
In this scenario, since RS peers with C1 ... Cn via CR, it requires
that when the RS router passes routing information to C1...Cn, it
designates the IP address of the CR as the next hop. Likewise, when
the RS router passes routes from each customer router to the customer
aggregation router, it needs to place the correct next hop on the
route. Modifications need to be made to the RS code to include this
function.
2) Private RS Router at InterExchange Point
A large provider network often has many BGP peers at the
Interexchange Point, NAP or private interconnection. This means a
border router has to handle many E-BGP sessions. Since an
Interconnect points is usually the administrative boundary between
ISPs, policy and route filtering are very demanding. This imposes a
scaling problem on the border router.
Deploying many routers to distribute the load among them is an
expensive solution: extra hardware and extra ports cost money.
Shifting the routing burden to an RS router is a promising
alternative solution. In the case of using RS for multiple peers at a
private interexchange point, the scenario is similar to RS used
between customer aggregation router and customer routers as described
in 1) above. In the case of such peering at a NAP, the private RS
could be placed either on the same NAP media or a private media
between the ISP's NAP router and the RS.
3) RS Routers at Each POP in a Large Network
Even in a network with a hierarchical routing structure, a sub-area
may become too large, and I-BGP full meshing may impose a scaling
problem. One way to address this would be to split the sub-area or
add yet another tier of I-BGP reflector structure. Another possible
solution would be to use an RS router as an I-BGP Server. Depending
on the topology of a POP, this solution may or may not be suitable.
The use of RS routers at network POPs need to be investigated
further.
Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFCEditor function is currently provided by the
Internet Society.