rfc2791.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,460 行 · 第 1/5 页

   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)",