rfc2791.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

        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: [e-mail]












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]