summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2791.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2791.txt')
-rw-r--r--doc/rfc/rfc2791.txt1459
1 files changed, 1459 insertions, 0 deletions
diff --git a/doc/rfc/rfc2791.txt b/doc/rfc/rfc2791.txt
new file mode 100644
index 0000000..91c5240
--- /dev/null
+++ b/doc/rfc/rfc2791.txt
@@ -0,0 +1,1459 @@
+
+
+
+
+
+
+Network Working Group J. Yu
+Request for Comments: 2791 CoSine Communications
+Category: Informational July 2000
+
+
+ Scalable Routing Design Principles
+
+Status of this Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2000). All Rights Reserved.
+
+Abstract
+
+ Routing is essential to a network. Routing scalability is essential
+ to a large network. When routing does not scale, there is a direct
+ impact on the stability and performance of a network. Therefore,
+ routing scalability is an important issue, especially for a large
+ network. This document identifies major factors affecting routing
+ scalability as well as basic principles of designing scalable routing
+ for large networks.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu Informational [Page 1]
+
+RFC 2791 Scalable Routing Design Principles July 2000
+
+
+Table of Contents
+
+ 1 Introduction .................................. 2
+ 2 Common Routing Design Goals ................... 3
+ 3 Characteristics of Today's Large Networks ..... 3
+ 4 Routing Scaling Issues .......................... 3
+ 4.1 Router Resource Consumption ..................... 4
+ 4.2 Routing Complexity .............................. 5
+ 5 Routing Protocol Scalability ..................... 6
+ 5.1 IS-IS and OSPF .................................. 6
+ 5.2 BGP ............................................. 8
+ 6 Scalable Routing Design Principles .............. 9
+ 6.1 Building Hierarchy .............................. 10
+ 6.2 Compartmentalization ............................ 13
+ 6.3 Making Proper Trade-offs ........................ 13
+ 6.4 Reduce Burdens of Routing Information Process ... 14
+ 6.4.1 Routing Intelligence Placement .................. 14
+ 6.4.2 Reduce Routes and Routing Information ........... 15
+ 6.4.2.1 CIDR and Route Aggregation ...................... 15
+ 6.4.2.2 Utilize Default Routing where it's Possible ..... 15
+ 6.4.2.3 Reduce Alternative Paths ........................ 16
+ 6.4.3 Use Static Route at Edge ......................... 16
+ 6.4.4 Minimize the Impact of Route Flapping ............ 16
+ 6.5 Scalable Routing Policy and Scalable Implementation 17
+ 6.6 Out-of-band Process .............................. 19
+ 7 Conclusion and Discussion ........................ 19
+ 8 Security Considerations .......................... 20
+ 9 Acknowledgement .................................. 21
+ 10 References ....................................... 21
+ Author's Address .............................................. 22
+ Appendix A Out-of-Band Routing Processes .................... 23
+ Full Copyright Statement ..................................... 26
+
+1. Introduction
+
+ Routing is essential to a network. Without routing, packets cannot be
+ delivered to desired destinations and the network would be non-
+ functional. The challenge of designing the routing for a large
+ network, such as a large ISP backbone network, is not only to make it
+ work, but also to make it scale. Without a scalable routing system, a
+ network may suffer from severe performance penalties, as
+ unfortunately proven by disastrous events in large networks. This
+ document attempts to analyze routing scalability issues and define a
+ set of principles for designing scalable routing system for large
+ networks.
+
+ The organization of this document is as follows: Section 2 describes
+ routing functions and design goals. Sections 3 and 4 discuss the
+
+
+
+Yu Informational [Page 2]
+
+RFC 2791 Scalable Routing Design Principles July 2000
+
+
+ characteristics of today's large networks and the associated routing
+ scaling issues. Section 5 explores routing protocol scalability, and
+ Section 6 presents scalable routing design principles. Section 7
+ provides a conclusion to the document.
+
+2. Common Routing Design Goals
+
+ The basic goals a routing system should achieve are as follows:
+
+ o Stability
+ o Redundancy and robustness
+ o Reasonable convergency time
+ o Routing information integrity
+ o Sensible and manageable routing policy
+
+ The challenge of designing routing in a large network is not only to
+ achieve these basic goals but also to make the routing system scale.
+
+3. Characteristics of Today's Large Networks
+
+ Today's large networks typically possess the following features:
+
+ o They are composed of a large number of nodes (routers and/or
+ switches), typically in the hundreds. Some provider networks
+ include customer CPE routers within their administrative domain,
+ which increases the number of nodes to thousands.
+
+ o They have rich connectivity to meet redundancy and robustness
+ requirements, and they consequently have complex topologies.
+
+ o They are default-free; that is, they carry all the routes known
+ to the entire Internet. Currently, the total number is
+ approximately 70,000.
+
+ o The customer aggregation routers inside the large networks
+ connect sometimes hundreds of customer routers.
+
+ These characteristics impose a direct challenge to the routing
+ scalability of the network.
+
+4. Routing Scaling Issues
+
+ Today, the main issues surrounding routing scaling are: i) excessive
+ router resource consumption, which can potentially increase routing
+ convergency difficulties thus destabilize a network; and ii) routing
+ complexity, resulting in poor management of network, producing low
+ service quality.
+
+
+
+
+Yu Informational [Page 3]
+
+RFC 2791 Scalable Routing Design Principles July 2000
+
+
+4.1. Router Resource Consumption
+
+ The routing process puts bursty loads on routers, especially under
+ unstable network conditions. In the extreme case, the routing process
+ takes all available resources from the routers, which results in slow
+ routing convergence or no convergence. A network is paralyzed when it
+ cannot converge internal routing information.
+
+ It's worthy noting that routers with internal architectures that
+ tightly couple forwarding and routing processes tend to handle the
+ excessive routing load poorly. The emerging new generation of routers
+ with the architecture of separating resource used for forwarding and
+ routing could provide better routing scalability.
+
+ Today, a large network typically employs IS-IS [1,2] or OSPF [3] as
+ an Interior Routing Protocol(IGP) and BGP [4] as an Exterior Routing
+ Protocol(EGP), respectively. The IGP calculates paths across the
+ interior of the network. BGP facilitates routing exchange between
+ routing domains, or Autonomous Systems (AS). BGP also processes and
+ propagates external routing information within the network. The
+ presence of a large number of routers and adjacencies in a network,
+ coupled with frequent topology changes due to link instability, will
+ contribute to excessive resource consumption by the interior routing.
+ In the case of exterior routing, a large quantity of routers in a BGP
+ system plus frequent routing updates (route flapping) would put a
+ heavy burden on the routers. Section 5 describes scaling issues with
+ IS-IS, OSPF and BGP in detail.
+
+ In addition, having many destinations in a routing system, combined
+ with multiple paths associated with these routes, impose the
+ following scaling issues on BGP:
+
+ o A large number of routes combined with multiple paths for each
+ increases the cost of routing processing for route selection,
+ routing policy application and filtering.
+
+ o Too many routes combined with multiple paths requires large
+ amounts of memory on routers for storage. The demand is even
+ higher at InterExchange Points such as NAPs.
+
+ o The larger the number of routes, the greater the chance route
+ flapping will occur and the more BGP routing updates will happen
+ as a result. Based on statistics collected by [5], thousands of
+ BGP updates in a measured 15 minute interval can occur on a
+ typical default-free router at a NAP.
+
+
+
+
+
+
+Yu Informational [Page 4]
+
+RFC 2791 Scalable Routing Design Principles July 2000
+
+
+ Route flapping refers to frequent routing updates occurring due
+ to network instability, for example, when the state of a
+ physical link in the network is fluctuating, or when a BGP
+ session is torn down and re-established numerous time within a
+ short period of time.
+
+ To facilitate fast convergence, topology change information must
+ be propagated in a timely fashion. When a route becomes
+ unavailable and is withdrawn, the information is typically sent
+ immediately. If the affected routes have been announced to the
+ global Internet, the update information is likely to be
+ propagated to the entire Internet.
+
+ Route flapping has a profound impact on routers running BGP. The
+ routers have to process routing information frequently and this
+ consumes a tremendous amounts of the available resources. When a
+ local route or link is oscillating, interior routing is affected
+ as well by excessive topology information flooding and
+ subsequent shortest path calculations. However, OSPF (or IS-IS)
+ imposes rate limits on such activity to reduce the burden on the
+ routers. For example, OSPF specifies that an individual SLA can
+ be updated at most once every 5 seconds. This essentially
+ dampens the flapping.
+
+ Moreover, large numbers of E-BGP sessions processed by a single
+ router create another potential scaling issue. Large networks usually
+ have huge customer subscriptions and connections. To scale the
+ hardware and the number of nodes in the network, providers tend to
+ dedicate a group of customer aggregation routers, each connecting as
+ many customer CPE routers as possible. As a result, it's not uncommon
+ for a customer aggregation router to handle hundreds of E-BGP
+ sessions, which imposes potential problems, such as BGP session
+ processing and maintenance, route processing, filtering and route
+ storage.
+
+4.2. Routing Complexity
+
+ Routing complexity can lead to network management difficulties, which
+ will have an impact on trouble shooting and quick problem resolution.
+ It can result in a less than desirable service quality across the
+ network. Complicated routing policies and special cases or exceptions
+ in a routing design can contribute to routing complexity in a large
+ system.
+
+ Routing Policy refers to the administrative criteria for handling
+ routing information, commonly in the form of routing path selection
+ and route filtering. The way routing information is handled has a
+ direct impact on traffic flow within a network and across domains. As
+
+
+
+Yu Informational [Page 5]
+
+RFC 2791 Scalable Routing Design Principles July 2000
+
+
+ a result, it affects business agreements among different networks.
+ Therefore, the determination of routing policy is largely dominated
+ by non-technical concerns, such as business considerations. Routing
+ policy can be very complex, which would make management and
+ configuration an unscalable task.
+
+ The keys to reducing routing complexity are systematic as well as
+ consistent routing scheme and a routing policy that is simple but
+ meets the requirement of administrative polices.
+
+ Another factor contributing to the complexity of routing management
+ is prefix-based route filtering. As is well known, prefix-based
+ filtering is necessary in order to protect the integrity of the
+ routing system. This becomes a challenge when the number of routes
+ known to the Internet is as large as it is today.
+
+5. Routing Protocol Scalability
+
+ Today's commonly deployed routing protocols are IS-IS or OSPF for
+ Interior routing (aka IGP) and BGP for exterior routing (aka EGP). In
+ terms of scaling and other aspects, these protocols are already an
+ improvement over the previous generation of protocols, such as RIP
+ and EGP. However, scalability is still a major issue when a network
+ is large, when a routing design is insensitive to scaling issues, or
+ the protocol implementation is inefficient.
+
+5.1. IS-IS and OSPF
+
+ As described earlier in the document, IS-IS and OSPF are Link State
+ routing protocols. The basic components of a link state routing
+ protocol are i) generation and maintenance of a Link-State-DataBase
+ (LSDB) that describes the routing topology of a given routing area;
+ and ii) route calculation based on the topology information in the
+ database. Each node in a routing area is responsible for describing
+ its local routing topology in a Link State Advertisement or LSA (LSP
+ in the case of IS-IS.) Each individually generated LSA will be
+ distributed or flooded to all the routers in the area. Each router
+ receives LSAs from all the other routers, forming a link-state-
+ database that reflects the routing topology of the entire routing
+ area.
+
+ The main associated scaling issues are the complexity of the link
+ state flooding and routing calculation, plus the size of the LSDB
+ which contributes to the cost of routing calculation and router
+ memory consumption.
+
+
+
+
+
+
+Yu Informational [Page 6]
+
+RFC 2791 Scalable Routing Design Principles July 2000
+
+
+ Flooding is the process by which a router distributes its self-
+ originated LSA to the rest of the routers in the area in case of any
+ link state change. A router will send the LSA via all its interfaces.
+ When receiving an LSA update, a router validates the information and
+ updates its local LSDB before sending it out via all its own
+ interfaces, except the one from which it received the original LSA
+ update. Given the nature of IS-IS or OSPF flooding, a full-mesh
+ network with N routers would have O(N^2) of LSAs flooded in the
+ network when a single link failure occurs. A single router outage
+ would cause LSA in the order of O(N^3) to be flooded in the system.
+
+ In the case of OSPF, the protocol will refresh or flood every 30
+ minutes even under stable network conditions, which could increase
+ the problem for an already highly loaded router.
+
+ From the above discussion, one can easily observe that the more
+ routers and adjacencies in a Link State IGP routing area, the more
+ CPU burden there are for each router to bear. When a network is
+ unstable, the load will be amplified.
+
+ A link-state protocol typically uses Dijkstra's Shortest Path First
+ (SPF) algorithm for route calculation. The Dijkstra algorithm scales
+ to the order of O(N^2), where N is the number of nodes. The algorithm
+ could be improved to the order of O(l*logN) where l is the number of
+ links in the network and N is the number of destinations or routers
+ [6].
+
+ Consequently, link state routing protocols do not scale to a network
+ topology with many routers and excessive adjacencies in an area. When
+ the network topology is unstable, the computation, processing and
+ bandwidth costs are magnified, which causes excessive consumption of
+ router resources. When the instability prevents IS-IS or OSPF from
+ maintaining adjacencies, a network routing meltdown occurs.
+
+ Node adjacencies are discovered and maintained through the exchange
+ of HELLO messages sent periodically from each node. When a node fails
+ to receive HELLO messages from its neighbor within a certain period
+ of time (40 seconds for OSPF and less for IS-IS), it considers the
+ neighbor down. When heavy flooding, re-calculation and other
+ activities happen that make router CPU a scarce resource, a router
+ may not be able to allocate CPU time to send or process HELLO
+ packets. Routers in the network then lose adjacency, which magnifies
+ the instability. As a result, an isolated instability can escalate to
+ a routing failure across the entire network.
+
+ Link-state IGPs also do not scale well to carry a large number of
+ routes such as the 70,000 routes known to the Internet today. Since
+ external routes are included in the link-state-database and in LSA
+
+
+
+Yu Informational [Page 7]
+
+RFC 2791 Scalable Routing Design Principles July 2000
+
+
+ (LSP for IS-IS) updates, the link bandwidth and router memory
+ consumption will be tremendous. Moreover, due to the large size of
+ LSA updates, it would aggravate router resource consumption in the
+ process of LSA flooding, especially under unstable network condition.
+
+ To summarize, a scalable design should avoid inclusion of too many
+ routers in an IGP routing area, a large external routes carried by
+ IGP and, more important, excessive adjacencies in the area.
+
+5.2. BGP
+
+ BGP is an inter-domain routing protocol allowing the exchange of
+ routing or reachability information between different Autonomous-
+ System networks. Functionally, BGP is composed of External BGP(E-BGP)
+ and Internal BGP(I-BGP). E-BGP is used for exchanging external routes
+ while I-BGP is typically used for distributing externally learned
+ routes within an AS.
+
+ The general costs of BGP are as follows:
+
+ o CPU consumption in BGP session establishment, route selection,
+ routing information processing, and handling of routing updates
+
+ o Router memory to install routes and multiple paths associated
+ with the routes.
+
+ The major scaling issue associated with BGP lie in the full mesh I-
+ BGP connections. Since it does not scale for an IGP to carry
+ externally learned prefixes, as mentioned in the previous section,
+ I-BGP assumes this duty. In order to prevent routing loops, prefixes
+ learned via I-BGP are prohibited from being advertised to another I-
+ BGP speaker. As a result, a full mesh of I-BGP sessions among the
+ routers within an AS is required. In an AS with N routers, each
+ router will have to establish I-BGP sessions with N-1 routers, and
+ the system complexity is in the order of O(N^2). Therefore, BGP
+ scales poorly when the number of routers involved in I-BGP mesh is
+ large.
+
+ A large network normally learns all the routes known to the Internet,
+ which is approximately 70,000. I-BGP will need to carry all these
+ routes.
+
+ The large number of I-BGP sessions and routes consumes tremendous
+ resources from each router, especially during BGP session
+ establishment and during periods of heavy route flapping.
+
+
+
+
+
+
+Yu Informational [Page 8]
+
+RFC 2791 Scalable Routing Design Principles July 2000
+
+
+ Frequent routing updates are another potential scaling problem in
+ large networks. BGP uses incremental updates and sends out routing
+ information about unreachable routes quickly for fast convergence.
+ This is a great improvement from EGP, in which the whole routing
+ table is updated at a fixed time interval. However, when a network is
+ unstable the updates, especially those containing route withdrawals,
+ are sent immediately, causing global BGP updates. As a result,
+ network instability initiated anywhere in a network triggers updates
+ all over the Internet. This effect is magnified when large amounts of
+ routes are visible to the Internet, putting a heavy load on routers
+ that participate in BGP.
+
+ The introduction of a routing hierarchy in BGP, through I-BGP Route
+ Reflectors [7] and BGP Confederations [8], for example, will help
+ alleviate the scaling problem caused by the requirement of full mesh
+ I-BGP establishment.
+
+ Another potential solution is to avoid the requirement of full mesh
+ pairwise I-BGP connections. This will change the way that BGP
+ distributes routing information among the I-BGP peers. Mechanisms
+ worth considering are using multicast to distribute information or
+ adopting flooding mechanisms similar to those used in IS-IS or OSPF.
+ Further investigation of the implication of using such mechanism for
+ BGP route distribution is needed.
+
+ Route dampening [9] is one way to reduce excessive updates triggered
+ by route flapping. The trade-off between fast convergence and
+ stability of the network should be considered, as discussed in
+ section 6.3.
+
+6. Scalable Routing Design Principles
+
+ The routing design for a large-scale network should achieve the basic
+ goals of accuracy, stability, redundancy and convergence as described
+ in Section 2 and moreover should achieve it in a scalable fashion.
+
+ How routing scales is influenced by protocol design decisions,
+ protocol implementation decisions, and network design decisions. A
+ network engineer has direct control over network design decisions and
+ can have substantial influence over protocol design and
+ implementation. The focus of this document is network design
+ decisions.
+
+
+
+
+
+
+
+
+
+Yu Informational [Page 9]
+
+RFC 2791 Scalable Routing Design Principles July 2000
+
+
+ Following is a set of design principles for making a large network
+ routing system more scalable:
+
+ o Building hierarchy
+ o Compartmentalization
+ o Making proper trade-offs
+ o Reducing route processing burdens
+ o Defining scalable routing policies and implementation
+ o Utilizing out-of-band routing assistance
+
+6.1. Building Hierarchy
+
+ As discussed in Section 5.1, OSPF and IS-IS scale poorly when a
+ network has a large number of routers and in particular, a large
+ quantity of adjacencies. This has unfortunately been proven by
+ networks that deploy IP over ATM with full mesh adjacencies among the
+ routers. The full mesh overlay design combined with the inefficient
+ protocol implementation led to disastrous network outages. A lesson
+ learned from this is to avoid full mesh overlay topology in a large
+ network with a large, flat network routing structure.
+
+ Building hierarchical routing structures in the network is the key to
+ achieving routing scalability in a large network. As discussed
+ earlier in this document, large networks are usually composed of many
+ routers with a complex topology, which results in a large number of
+ adjacencies. As also discussed earlier, currently available routing
+ protocols scale poorly for handling a large number of routers in a
+ routing domain or many adjacencies among the routers. Therefore, it
+ is sensible to build a routing hierarchy to reduce the number of
+ routers as well as the number of adjacencies in a routing domain.
+
+ The current common practice is to build a two-tiered hierarchy in a
+ network with a center component (or transit core network) to which a
+ number of outskirt components (or access networks) attach. The
+ transit core network covers the entire geographical area the network
+ serves; each access network (aka regional network) covers one region.
+ There are usually no direct link connections among the regional
+ components. Traffic from one regional network to another traverses
+ the transit core. Customer networks connect only to access or
+ regional networks. There are a number of ways to build a routing
+ hierarchy in the above described hierarchical network topology.
+
+ 1) Completely Separate Routing Domains
+
+ This design treats the transit core network and each regional
+ network as completely independent ASs with respect to routing, and
+ each AS runs an independent IGP. Each regional network E-BGP with
+ the transit core for exchanging routing knowledge. Full I-BGP
+
+
+
+Yu Informational [Page 10]
+
+RFC 2791 Scalable Routing Design Principles July 2000
+
+
+ connections need to be established only within each component
+ network. With this design, the maximum number of routers in an IGP
+ domain is the total number of routers in each component. As a
+ result, the IGP processing load is reduced, and the number of
+ routers in an I-BGP mesh in the network routing system is
+ decreased dramatically.
+
+ Another advantage of this design is that it compartmentalizes the
+ routing system so that instability in one such component has less
+ impact on the entire system. See the discussion in section 6.2.
+
+ The main disadvantage of this scheme is that it inserts one extra
+ AS in the routing path when routes are advertised to the Internet
+ via BGP. This extra AS in the path may cause route selection
+ difficulties for other providers.
+
+ 2) One Domain with IGP and BGP Hierarchy
+
+ This method includes the transit core and each regional network
+ into one AS domain. The routing hierarchy is realized by utilizing
+ multi-level IS-IS or OSPF areas and either BGP Confederation or
+ I-BGP Reflector or a combination of the two.
+
+ This mechanism avoids the introduction of an extra AS in the
+ routing path, which is an advantage over the method described in
+ Point 1). However, multi-area hierarchical IGP is rarely used
+ now-a-days in large networks since most of them are using IS-IS
+ for internal routing, which does not have sufficient multi-level
+ support. Although IS-IS supports multi-area routing, it imposes a
+ strict hierarchy between backbone and sub-areas and allows only
+ the advertisement of a default route from the backbone area to the
+ sub-areas instead of specific prefixes. This restriction may be
+ suitable for a network with a simple sub-area topology. A sub-area
+ in a large network, typically a regional or access network, itself
+ has a complicated topology. Receiving highly abstract routing
+ information, such as a default route, would affect the sub-area's
+ ability to make route selections required for traffic engineering.
+ It would also limit the information passed to external ASs, for
+ example, IGP-derived BGP Multi-Exit-Discriminator (MED)
+ information.
+
+ Efforts are being made to modify the IS-IS protocol to allow the
+ distribution of specific route from backbone area to sub-areas. A
+ mechanism facilitates such distribution is specified in [15]. When
+ implementation of such mechanism become available, implementing
+ multi-level IGP will be an attractive option for building routing
+ hierarchy within a large network.
+
+
+
+
+Yu Informational [Page 11]
+
+RFC 2791 Scalable Routing Design Principles July 2000
+
+
+ 3) One IGP Area with BGP Hierarchy
+
+ In lieu of multi-area IS-IS, the routing hierarchy could be
+ achieved by defining one IGP domain for the entire network while
+ employing a BGP hierarchy. Fortunately, the hierarchical topology
+ of the network in this case helps reduce adjacencies in the
+ routing domain (recall there are no connections among the second-
+ level network components). In addition, improvements could be made
+ to further reduce the adjacency by carefully arranging the
+ adjacencies to keep them at a minimum but still achieve good
+ redundancy. However, this is less than ideal since the number of
+ routers remains unchanged, which increases the load on the SPF
+ calculation. Moreover, instability within any regional network
+ would still affect the entire network (that is, there would be no
+ fault isolation).
+
+ Even with one IGP domain, it is possible to build BGP hierarchy to
+ make I-BGP more scalable in the network. BGP Reflectors and BGP
+ Confederations are existing mechanisms to address the scaling
+ problem of full-mesh I-BGP.
+
+ Further, a BGP reflector provides the ability to build more than
+ two levels of hierarchy, as long as the interactions among the
+ different levels of the hierarchy are carefully arranged to avoid
+ the possibility of creating routing loops.
+
+ Questions worth asking are: "Are two levels of routing hierarchy
+ sufficient for handling scaling issues?" "Is there really a need for
+ more than two levels of hierarchy?"
+
+ When a second-tier sub-domain of a large network, such as a regional
+ network, grows too big for routing protocols to handle, either
+ another layer of hierarchy needs to be introduced or the sub-domain
+ needs to be split into multiple second-tiered sub-domains.
+
+ Keeping two levels of hierarchy and adding more sub-domains appears
+ to be more manageable than adding another level to the hierarchy.
+ However, one concern is to avoid adding more nodes to the top-level
+ or transit core network to make it less scalable. Connecting the
+ split sub-areas to the same core router would eliminate the need to
+ add more nodes in the core area than is recommended.
+
+ Having more than two levels of hierarchy would exceed the capability
+ of IGPs as they are defined today. In OSPF, for example, all the
+ areas must be connected via the backbone area, which eliminates the
+ possibility of having more than two levels of hierarchy. IS-IS has
+ the same limitation. Therefore, the protocols need to be redefined
+ should more than two hierarchical layers in IGP be desirable.
+
+
+
+Yu Informational [Page 12]
+
+RFC 2791 Scalable Routing Design Principles July 2000
+
+
+ The complexity of protocols and management will increase with the
+ number of levels added to the hierarchy. According to [6], most of
+ the OSPF protocol bugs found over the years are related to routing
+ area support. Because the interaction among the multiple levels
+ increases management and debugging complexity, it is desirable to
+ keep the levels within a hierarchy to a minimum.
+
+6.2. Compartmentalization
+
+ A scalable routing design of a large network should be able to
+ localize problems or failures, thus preventing them from spreading to
+ the entire network, consuming resources of network routers, and
+ causing network wide instability. This is compartmentalization.
+ Network compartmentalization makes fault isolation possible which
+ contributes the stability of a large network.
+
+ To achieve compartmentalization in routing design for a large
+ network, one needs to avoid a design where the whole large network is
+ one flat routing system or routing domain. This is the reason for the
+ architecture of dividing interior and exterior routing in the global
+ routing system. Within a network, it is best to divide the network
+ into multiple routing domains or multiple routing areas. For example,
+ in OSPF, only summary route SLAs, rather than individual area routes,
+ are flooded beyond the area. When an area border router aggregates
+ the routes in its sub-area, instability of any route included in the
+ summary route would not cause flooding of SLAs to other areas. As a
+ result, router resources in other areas would not be consumed for
+ handling flooding and the SPF recalculation. In other words,
+ instability within each individual area would be prevented from
+ spreading to the entire routing domain.
+
+ Since building a routing hierarchy essentially divides a big routing
+ area into smaller areas or domains, it help achieve the goal of
+ compartmentalization.
+
+6.3. Making Proper Trade-offs
+
+ When designing routing for a large network, the overall goal should
+ be set with considerations of routing scalability and stability. The
+ trade-offs between conflicting goals should be taken into account.
+ Examples of such trade-offs are redundancy vs. scalability and
+ convergence vs. stability.
+
+ Redundancy introduces complexity and increased adjacencies to the
+ network topology. Redundancy also imposes the need for as many
+ alternative paths as possible for each route, which increases route
+
+
+
+
+
+Yu Informational [Page 13]
+
+RFC 2791 Scalable Routing Design Principles July 2000
+
+
+ processing and storage burdens. Because of these problems, it may be
+ necessary to sacrifice absolute redundancy in favor of a reasonable
+ level that scales better for the routing system.
+
+ Fast convergence requires that changes in network topology be
+ propagated to the network as quickly as possible. Such action
+ increases routing updates and, consequently, the route processing
+ burden. The burden is aggravated when a network carries full Internet
+ routing information, as large networks usually do, and topology
+ changes happen frequently. Route dampening may be necessary to
+ achieve stability at the expense of absolute fast convergence.
+
+6.4. Reduce Burdens of Routing Information Processing
+
+ The tasks of reducing routing processing burdens includes: i)
+ strategically place the routing intelligence within the network, ii)
+ avoid carrying unnecessary routing information and iii) reduce the
+ impact of route flapping.
+
+6.4.1. Routing Intelligence Placement
+
+ A router that executes routing policies, performs route filtering and
+ dampening is said to posses routing intelligence. Routing
+ intelligence is needed for a network i) to enforce the business
+ agreement between network entities in the form of routing policies;
+ ii) to protect the integrity of the routing information within the
+ network and sometimes iii) to shield a network from instability
+ happening elsewhere in the Internet.
+
+ The more routing intelligence a router has, the more resources of the
+ router are needed to perform those tasks. It is logical, then, to
+ place as little routing intelligence as possible on routers that
+ already are heavily burdened with other tasks.
+
+ Usually, traffic is heavily concentrated in the core of the network.
+ Because traffic aggregates from the edge of the network toward the
+ core, traffic is less concentrated near the edge of the network.
+ Consequently, to build a scalable routing system, it is wise to place
+ routing intelligence at the edge of the network, especially in the
+ networks deployed with routers that do not sufficiently decouple
+ forwarding and routing. In addition, pushing routing intelligency as
+ close to the edge of the network as possible also serves the purpose
+ of distributing computational and configuration burdens across all
+ routers.
+
+ It is also desirable to move the heavy burden of processing routes to
+ out-of-band processors, freeing more resources in network routers for
+ packet forwarding and handling.
+
+
+
+Yu Informational [Page 14]
+
+RFC 2791 Scalable Routing Design Principles July 2000
+
+
+6.4.2. Reduce Routes and Routing Information
+
+ As discussed in Section 4.1, a large number of routes in the system
+ is one of the major culprits in route scaling problems. Therefore, it
+ is best to reduce the number of routes in the system without losing
+ necessary routing information.
+
+6.4.2.1. CIDR and Route Aggregation
+
+ CIDR as specified in [10] provides a mechanism to aggregate routes
+ for efficiently utilizing IP address space as well as reducing the
+ number of routes in the global routing table. CIDR offers a way to
+ summarize routing information, which is one of the keys for routing
+ scalability in today's Internet.
+
+ Route aggregation would not only help global Internet scalability but
+ would also contribute to scalability in local networks. The overall
+ goal is to keep the routes in the backbone to a minimum.
+
+ To achieve better aggregation within the network; that is, to reduce
+ the number of routes in the network, a block of consecutive IP
+ addresses should be allocated to each access or regional network so
+ that when a regional network announces its routes to the transit core
+ network, they can be aggregated. This way, the core and other
+ regional networks would not need to know the specific prefixes of any
+ particular access network. Although assignment of customer addresses
+ from a provider block would have to be planned to support
+ aggregation, the effort would be worthwhile.
+
+6.4.2.2. Utilize Default Routing When Possible
+
+ The use of a default route achieves ultimate route summarization,
+ which reduces routing information to minimum. Route summarization
+ also masks the instability associated with an individual route, for
+ example, in the case of route flapping. It's beneficial for a network
+ to utilize default routing when appropriate. For example, if a
+ second-tiered regional network is a stub and there is no connected
+ customer requesting full Internet routing information, the regional
+ network can simply point default to its connected core network.
+ However, over-summarization of routing information has the danger of
+ losing routing granularity and as a result, management of network
+ such as traffic engineering would be adversely affected. Therefore,
+ caution needs to be exercised when using default routing.
+
+
+
+
+
+
+
+
+Yu Informational [Page 15]
+
+RFC 2791 Scalable Routing Design Principles July 2000
+
+
+6.4.2.3. Reduce Alternative Paths
+
+ Due to the requirement of reliability, the connectivity in the
+ Internet is rich, resulting in many paths toward a particular
+ destination. In other words, there are many alternate paths in the
+ BGP routing table towards the same destination, which consumes router
+ memory and adds to the routing processing burden.
+
+ To make routing scale, it is desirable to reduce alternate paths
+ while preserving reasonable redundancy. For example, on a given
+ border router (such as a NAP router), one primary path plus an
+ alternate path should provide reasonable redundancy. In this case, a
+ third or a fourth alternate route could be discarded for the sake of
+ scaling. This is a trade-off decision every network administrator
+ needs to make based on the particular needs of her network.
+
+6.4.3. Use Static Route at Edges
+
+ As mentioned earlier, one of the scaling issues in large networks is
+ that a single router may fan out to hundreds of customer routers. As
+ a result, resource consumption will be very intensive if all the
+ customer routers communicate via BGP with the edge router. Is it
+ necessary for the edge router to BGP with all of its attached
+ customer routers?
+
+ At first glance, it seems necessary for a customer network in a
+ different Autonomous System(AS) to exchange routing information with
+ the provider network via BGP. However, this is not necessarily the
+ case. When a customer network is single-homed (that is, if the sole
+ network connection for a customer is via its provider network), BGP
+ is not necessary and static routing can work. Since the customer
+ network is single-homed, static routing will not have any negative
+ impact on services. The advantages are that the customer aggregation
+ router will have fewer E-BGP sessions to handle, and no route
+ flapping can result from the statically configured customer routes.
+
+ Configuration of the customer's static routes on the provider's
+ aggregation router may add management overhead, especially if a
+ customer advertises a large number of routes. On the other hand, the
+ set of routes a customer announces to the provider usually changes
+ infrequently; thus it requires low maintenance once it is configured.
+
+6.4.4. Minimize the Impact of Route Flapping
+
+ As discussed earlier, route flapping is largely caused by link
+ instability and/or BGP session instability that results in excessive
+ routing updates across the Internet. Route flapping can originate
+ anywhere in the global Internet and affect every network in the
+
+
+
+Yu Informational [Page 16]
+
+RFC 2791 Scalable Routing Design Principles July 2000
+
+
+ Internet routing mesh (BGP mesh). Given that there are over 70,000
+ routes known to the Internet and there is little isolation for route
+ flapping, handling route flapping could be overwhelming to routers in
+ any network.
+
+ One way to reduce the effect of route flapping is to turn on route
+ dampening as specified in [10]. Essentially, dampening suppresses an
+ unstable route until it becomes stable. The current practice is for
+ each ISP to enable route dampening on its border routers. This way,
+ excessive routing updates can be stopped at the border.
+
+ An ideal model is to suppress the announcement of a flapping route
+ right at the source. One way to implement this is to have a router
+ recognize instability associated with its directly connected links
+ and suppress the announcement of the route. So far, there is no such
+ implementation. This approach should be explored.
+
+ Route aggregation often masks route flapping since components of an
+ aggregated route (more specific routes) would not cause the
+ aggregated route to flap. Therefore using CIDR can also help to
+ alleviate route flapping.
+
+6.5. Scalable Routing Policy and Scalable Implementation
+
+ Routing policy involves routing decisions about acceptance and
+ advertisement of certain routes to or from other networks and about
+ routing preference when more than one route becomes available.
+ Routing policy enforces business agreements between network entities
+ and is largely governed by non-technical criteria. In essence,
+ routing policy involves defining criteria for route filtering and
+ route selection.
+
+ One aspect of route filtering has to do with traffic control between
+ routing domains or between different provider networks. Making policy
+ based on individual prefixes should be avoided in this case because,
+ with the large number of prefixes in the Internet, it does not scale.
+ Making policy based on ASs that administratively represent a set of
+ prefixes scales better.
+
+ Another purpose of route filtering is to protect the integrity of
+ routing information by preventing the acceptance of falsely
+ advertised routing information that would lead traffic to 'black
+ holes'. In this case, only prefix-based filtering will sufficiently
+ achieve the goal. Prefix-based filtering needs to occur at the
+ borders between a network and its direct customers or peer networks.
+ The filtering is harder to manage at the boundary of the peer
+ networks since a peer network usually advertises a large amount of
+ prefixes. As mentioned earlier, there are about 70,000 routes known
+
+
+
+Yu Informational [Page 17]
+
+RFC 2791 Scalable Routing Design Principles July 2000
+
+
+ to the Internet. This means a large default-free network would need
+ to filter on the order of hundred of thousands of prefixes or even
+ more since a route could be advertised by more than one sources. The
+ sheer amount of the prefixes to be filtered imposes challenges for
+ router configuration memory and configuration management. To make it
+ scale, one would need to rely on the help from an out-of-band process
+ to sort out which prefixes should be accepted or denied from which
+ source. IRR [11] and DNS [12] are among the current proposed
+ mechanisms for implementing prefix-based filtering.
+
+ Route selection policy determines which path should be used to send
+ traffic toward a certain destination. This is important, for example,
+ when a network has two connections to another network and learns
+ routes from both connections. The decision involves which path to
+ select to send traffic to the customers behind the other network. The
+ choices are typically:
+
+ o Directing traffic to the closest interconnection point for
+ traffic to exit the network. This policy is also known as Hot-
+ Potato-Routing
+
+ o Directing traffic to the optimal network exit point. The optimal
+ exit point is determined based on certain criteria by the
+ network administrator and is not necessary the closest exit
+ point
+
+ o Always preferring routes advertised by directly connected
+ customers
+
+ o Allowing other network or customer to determine the path
+
+ When a policy is defined, its implications for scalable
+ implementation need to be considered. For example, if the policy
+ allows customers to determine which paths traffic follows, customers,
+ not the provider, should be required to set routing parameters to
+ make the routing favor their preferred path. Customers can use the
+ BGP community or mechanisms such as MED to set routing preferences in
+ a much more scalable way. This avoids putting such routing management
+ burdens solely on the provider. Distributing the routing management
+ burden makes the policy implementation more scalable.
+
+ Another scaling measure is to avoid making complex policy. When
+ routing policy is complex, management, such as configuration of the
+ router and debugging, would be a problem. The ultimate goal is to
+ make the network manageable.
+
+ The following basic principles would help scale the routing policy
+ management.
+
+
+
+Yu Informational [Page 18]
+
+RFC 2791 Scalable Routing Design Principles July 2000
+
+
+ o Making policies as simple as possible but meet the requirements
+
+ o Automating as much as possible to avoid error-prone manual work
+
+ o Avoiding policy based on individual prefixes as much as possible
+ with the exception of prefix-based route filtering for
+ protecting routing integrity
+
+ o Avoiding making exceptions
+
+ o Using out-of-band routing policy processing where possible
+
+6.6. Out-of-Band Process
+
+ A typical router assumes both routing and forwarding functions.
+ However, conceptually, routing and forwarding are two separate
+ processes. A router's ultimate task is to forward packets based on
+ its forwarding table, which is derived from routing information. One
+ of the main causes of route scaling problems is that routers run out
+ of processing power because routing requires too much processing.
+ While a router has to forward packets, it does not necessarily have
+ to exchange and process routing information or execute routing
+ policy; these tasks can be performed elsewhere. Thus the question
+ should be: Would it be possible to remove the routing process from a
+ router to reduce its burden? Moving the routing process from the
+ routers to other systems is referred to as out-of-band route
+ processing.
+
+ Out-of-band route processes would, in short, perform the heavy-duty
+ routing tasks. They would build a forwarding table for the router,
+ select routes based on pre-defined policy, filter routes, and shield
+ the router from route flapping attacks.
+
+ The shortcomings of out-of-band route processing are the possible
+ introduction of delays in routing changes; the de-coupling of routing
+ and forwarding paths, which could introduce inaccurate routing
+ information; and the cost of extra equipment.
+
+ Appendix A presents a current example of out-of-band route
+ processing. It also suggests other possible solutions.
+
+7. Conclusion and Discussion
+
+ How routing scales has a direct impact on network stability and
+ performance. With the fast growth of the Internet and consequent
+ expansion of providers' networks, routing scaling become increasingly
+
+
+
+
+
+Yu Informational [Page 19]
+
+RFC 2791 Scalable Routing Design Principles July 2000
+
+
+ an important issue to address. This document identifies the major
+ factors that affect route scalability and establishes basic
+ principles for designing scalable routing in large networks.
+
+ The major routing scaling issues we are facing today are excessive
+ router resource consumption due to routing processing burdens causing
+ routing convergency difficulties thus introducing network
+ instability; and routing complexity resulting in difficulties of
+ management and trouble shooting causing degradation of service.
+
+ The outlined principles for designing a scalable routing system are
+ building routing hierarchy; introducing fault isolation; reducing
+ routing processing burden where possible; defining manageable routing
+ policies and using the assistance of available out-of-band routing
+ process.
+
+ The use of out-of-band resources to assist routing processing is a
+ concept only been used in the Internet Exchange Points (IXPs).
+ However, it could potentially be used to advantage within a network
+ to help addressing routing scaling issues. This is a topic worthy of
+ further exploration.
+
+ Routing protocols and/or their implementations can still be improved
+ or enhanced for better handling of the scaling issues. For example,
+ the IS-IS multiple level mechanism is needed in order to scale the
+ IGP in large network. Also, using multicast or a reliable flooding
+ mechanism for I-BGP updates instead of pairwise full mesh peering is
+ something worth investigating.
+
+ It is our belief that even with the deployment of new technologies
+ such as DWDM, MPLS and others in the future, the fundamental routing
+ scheme will remain the current IGP/BGP paradigm. Therefore, the
+ scalable routing design principles outlined in this document should
+ still apply with the deployment of new technologies.
+
+8. Security Considerations
+
+ This document deals with routing scaling issues and thus is unlikely
+ to have a direct impact on security.
+
+ However, certain routing scaling improvement mechanisms suggested in
+ the document, such as network compartmentalization, will possibly
+ alleviate network outages caused by denial-of-service attacks since
+ it would help prevent such outages from spreading to the entire
+ network.
+
+
+
+
+
+
+Yu Informational [Page 20]
+
+RFC 2791 Scalable Routing Design Principles July 2000
+
+
+ Although the mechanisms described in this document do not enhance or
+ weaken the security aspect of routing protocols, it is worth
+ indicating here that security enhancement of routing protocols or
+ routing mechanisms may impact routing scalability. Therefore, when
+ applying security enhancement in routing, one has to be aware of the
+ implications on scalability.
+
+ For example, TCP MD5 signature option is proposed to be a mechanism
+ to protect BGP sessions from being spoofed [13]. It is done on a
+ per-session basis and the overhead of MD-5 extensions are minimal
+ thus has no direct impact on scalability. There have been concerns
+ about doing per-prefix AS path verification as any one ISP along a
+ path could have forged or modified information (maliciously or not).
+ One extreme solution is to have a signature for each prefix which
+ gives very strong security but presents enormous scaling issues in
+ terms of processing, memory and administrative overhead.
+
+9. Acknowledgement
+
+ Special thanks to Curtis Villamizar and Dave Katz for the extensive
+ review of the document and many helpful comments. Many thanks to
+ Yakov Rekhter, Noel Chiappa and Rob Coltun for their insightful
+ comments. The author also like to thank Susan R. Harris for the much
+ needed polishing of English language in the document.
+
+ The author was made aware after the publication of this document that
+ there is a relevant and independent presentation made by Enke Chen on
+ the subject. The presentation is thus referenced in [14].
+
+10. References
+
+ [1] "Intermediate System to Intermediate System Intra-Domain
+ Routeing Exchange Protocol for use in Conjunction with the
+ Protocol for Providing the Connectionless-mode Network Service
+ (ISO 8473)", ISO DP 10589, February 1990.
+
+ [2] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and Dual
+ Environments", RFC 1195, December 1990.
+
+ [3] Moy, J., "OSPF Version 2", RFC 2328, April 1998.
+
+ [4] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)",
+ RFC 1771, March 1995.
+
+ [5] C. Labovitz, R. Malan, F. Jahanian, "Origins of Internet Routing
+ Instability," in the Proceedings of INFOCOM99, New York, NY,
+ June, 1999
+
+
+
+
+Yu Informational [Page 21]
+
+RFC 2791 Scalable Routing Design Principles July 2000
+
+
+ [6] J. Moy, "OSPF-Anatomy of an Internet Routing Protocol",
+ Addison-Wesley, January 1998.
+
+ [7] Bates, T., Chandra, R. and E. Chen, "BGP Route Reflection - An
+ alternative to full mesh IBGP", RFC 2796, April 2000.
+
+ [8] Traina, P., "Autonomous System Confederation Approach to Solving
+ the I-BGP Scaling Problem", RFC 1965, June 1996.
+
+ [9] Curtis, V., Chandra, R. and R. Govindan, "BGP Route Flap
+ Damping", RFC 2439, November 1998.
+
+ [10] Fuller, V., Li, T., Yu, J. and K. Varadhan "Classless Inter-
+ Domain Routing (CIDR): an Address Assignment and Aggregation
+ Strategy", RFC 1519, September 1993.
+
+ [11] Villamizar, C., Alaettinoglu, C., Govindan, R. and D. Meyer,
+ "Routing Policy System Replication", RFC 2769, 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", RFC 2385, 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
+
+
+
+
+
+
+
+
+
+
+
+
+Yu Informational [Page 22]
+
+RFC 2791 Scalable Routing Design Principles July 2000
+
+
+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
+
+
+
+
+Yu Informational [Page 23]
+
+RFC 2791 Scalable Routing Design Principles July 2000
+
+
+ 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
+
+
+
+
+Yu Informational [Page 24]
+
+RFC 2791 Scalable Routing Design Principles July 2000
+
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu Informational [Page 25]
+
+RFC 2791 Scalable Routing Design Principles July 2000
+
+
+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 RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu Informational [Page 26]
+