doc: Add RFC documents

1 files changed, 675 insertions, 0 deletions

diff --git a/doc/rfc/rfc4456.txt b/doc/rfc/rfc4456.txt
new file mode 100644
index 0000000..df894ef
--- /dev/null
+++ b/doc/rfc/rfc4456.txt
@@ -0,0 +1,675 @@
+
+
+
+
+
+
+Network Working Group                                           T. Bates
+Request for Comments: 4456                                       E. Chen
+Obsoletes: 2796, 1966                                      Cisco Systems
+Category: Standards Track                                     R. Chandra
+                                                           Sonoa Systems
+                                                              April 2006
+
+
+                         BGP Route Reflection:
+            An Alternative to Full Mesh Internal BGP (IBGP)
+
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   The Border Gateway Protocol (BGP) is an inter-autonomous system
+   routing protocol designed for TCP/IP internets.  Typically, all BGP
+   speakers within a single AS must be fully meshed so that any external
+   routing information must be re-distributed to all other routers
+   within that Autonomous System (AS).  This represents a serious
+   scaling problem that has been well documented with several
+   alternatives proposed.
+
+   This document describes the use and design of a method known as
+   "route reflection" to alleviate the need for "full mesh" Internal BGP
+   (IBGP).
+
+   This document obsoletes RFC 2796 and RFC 1966.
+
+
+
+
+
+
+
+
+
+
+
+
+Bates, et al.               Standards Track                     [Page 1]
+
+RFC 4456                  BGP Route Reflection                April 2006
+
+
+Table of Contents
+
+   1. Introduction ....................................................2
+   2. Specification of Requirements ...................................2
+   3. Design Criteria .................................................3
+   4. Route Reflection ................................................3
+   5. Terminology and Concepts ........................................4
+   6. Operation .......................................................5
+   7. Redundant RRs ...................................................6
+   8. Avoiding Routing Information Loops ..............................6
+   9. Impact on Route Selection .......................................7
+   10. Implementation Considerations ..................................7
+   11. Configuration and Deployment Considerations ....................7
+   12. Security Considerations ........................................8
+   13. Acknowledgements ...............................................9
+   14. References .....................................................9
+      14.1. Normative References ......................................9
+      14.2. Informative References ....................................9
+   Appendix A: Comparison with RFC 2796 ..............................10
+   Appendix B: Comparison with RFC 1966 ..............................10
+
+1.  Introduction
+
+   Typically, all BGP speakers within a single AS must be fully meshed
+   and any external routing information must be re-distributed to all
+   other routers within that AS.  For n BGP speakers within an AS that
+   requires to maintain n*(n-1)/2 unique Internal BGP (IBGP) sessions.
+   This "full mesh" requirement clearly does not scale when there are a
+   large number of IBGP speakers each exchanging a large volume of
+   routing information, as is common in many of today's networks.
+
+   This scaling problem has been well documented, and a number of
+   proposals have been made to alleviate this [2,3].  This document
+   represents another alternative in alleviating the need for a "full
+   mesh" and is known as "route reflection".  This approach allows a BGP
+   speaker (known as a "route reflector") to advertise IBGP learned
+   routes to certain IBGP peers.  It represents a change in the commonly
+   understood concept of IBGP, and the addition of two new optional
+   non-transitive BGP attributes to prevent loops in routing updates.
+
+   This document obsoletes RFC 2796 [6] and RFC 1966 [4].
+
+2.  Specification of Requirements
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [7].
+
+
+
+
+Bates, et al.               Standards Track                     [Page 2]
+
+RFC 4456                  BGP Route Reflection                April 2006
+
+
+3.  Design Criteria
+
+   Route reflection was designed to satisfy the following criteria.
+
+      o  Simplicity
+
+         Any alternative must be simple to configure and easy to
+         understand.
+
+      o  Easy Transition
+
+         It must be possible to transition from a full-mesh
+         configuration without the need to change either topology or AS.
+         This is an unfortunate management overhead of the technique
+         proposed in [3].
+
+      o  Compatibility
+
+         It must be possible for noncompliant IBGP peers to continue to
+         be part of the original AS or domain without any loss of BGP
+         routing information.
+
+   These criteria were motivated by operational experiences of a very
+   large and topology-rich network with many external connections.
+
+4.  Route Reflection
+
+   The basic idea of route reflection is very simple.  Let us consider
+   the simple example depicted in Figure 1 below.
+
+                   +-------+        +-------+
+                   |       |  IBGP  |       |
+                   | RTR-A |--------| RTR-B |
+                   |       |        |       |
+                   +-------+        +-------+
+                         \            /
+                     IBGP \   ASX    / IBGP
+                           \        /
+                            +-------+
+                            |       |
+                            | RTR-C |
+                            |       |
+                            +-------+
+
+                    Figure 1: Full-Mesh IBGP
+
+   In ASX, there are three IBGP speakers (routers RTR-A, RTR-B, and
+   RTR-C).  With the existing BGP model, if RTR-A receives an external
+
+
+
+Bates, et al.               Standards Track                     [Page 3]
+
+RFC 4456                  BGP Route Reflection                April 2006
+
+
+   route and it is selected as the best path it must advertise the
+   external route to both RTR-B and RTR-C.  RTR-B and RTR-C (as IBGP
+   speakers) will not re-advertise these IBGP learned routes to other
+   IBGP speakers.
+
+   If this rule is relaxed and RTR-C is allowed to advertise IBGP
+   learned routes to IBGP peers, then it could re-advertise (or reflect)
+   the IBGP routes learned from RTR-A to RTR-B and vice versa.  This
+   would eliminate the need for the IBGP session between RTR-A and RTR-B
+   as shown in Figure 2 below.
+
+                  +-------+        +-------+
+                  |       |        |       |
+                  | RTR-A |        | RTR-B |
+                  |       |        |       |
+                  +-------+        +-------+
+                        \            /
+                    IBGP \   ASX    / IBGP
+                          \        /
+                           +-------+
+                           |       |
+                           | RTR-C |
+                           |       |
+                           +-------+
+
+                Figure 2: Route Reflection IBGP
+
+   The route reflection scheme is based upon this basic principle.
+
+5.  Terminology and Concepts
+
+   We use the term "route reflection" to describe the operation of a BGP
+   speaker advertising an IBGP learned route to another IBGP peer.  Such
+   a BGP speaker is said to be a "route reflector" (RR), and such a
+   route is said to be a reflected route.
+
+   The internal peers of an RR are divided into two groups:
+
+      1) Client peers
+
+      2) Non-Client peers
+
+   An RR reflects routes between these groups, and may reflect routes
+   among client peers.  An RR along with its client peers form a
+   cluster.  The Non-Client peer must be fully meshed but the Client
+   peers need not be fully meshed.  Figure 3 depicts a simple example
+   outlining the basic RR components using the terminology noted above.
+
+
+
+
+Bates, et al.               Standards Track                     [Page 4]
+
+RFC 4456                  BGP Route Reflection                April 2006
+
+
+                 / - - - - - - - - - - - - -  -
+                 |           Cluster           |
+                   +-------+        +-------+
+                 | |       |        |       |  |
+                   | RTR-A |        | RTR-B |
+                 | |Client |        |Client |  |
+                   +-------+        +-------+
+                 |       \           /         |
+                    IBGP  \         / IBGP
+                 |         \       /           |
+                           +-------+
+                 |         |       |           |
+                           | RTR-C |
+                 |         |  RR   |           |
+                           +-------+
+                 |           /   \             |
+                  - - - - - /- - -\- - - - - - /
+                     IBGP  /       \ IBGP
+                  +-------+         +-------+
+                  | RTR-D |  IBGP   | RTR-E |
+                  |  Non- |---------|  Non- |
+                  |Client |         |Client |
+                  +-------+         +-------+
+
+                     Figure 3: RR Components
+
+6.  Operation
+
+   When an RR receives a route from an IBGP peer, it selects the best
+   path based on its path selection rule.  After the best path is
+   selected, it must do the following depending on the type of peer it
+   is receiving the best path from
+
+      1) A route from a Non-Client IBGP peer:
+
+         Reflect to all the Clients.
+
+      2) A route from a Client peer:
+
+         Reflect to all the Non-Client peers and also to the Client
+         peers.  (Hence the Client peers are not required to be fully
+         meshed.)
+
+   An Autonomous System could have many RRs.  An RR treats other RRs
+   just like any other internal BGP speakers.  An RR could be configured
+   to have other RRs in a Client group or Non-client group.
+
+
+
+
+
+Bates, et al.               Standards Track                     [Page 5]
+
+RFC 4456                  BGP Route Reflection                April 2006
+
+
+   In a simple configuration, the backbone could be divided into many
+   clusters.  Each RR would be configured with other RRs as Non-Client
+   peers (thus all the RRs will be fully meshed).  The Clients will be
+   configured to maintain IBGP session only with the RR in their
+   cluster.  Due to route reflection, all the IBGP speakers will receive
+   reflected routing information.
+
+   It is possible in an Autonomous System to have BGP speakers that do
+   not understand the concept of route reflectors (let us call them
+   conventional BGP speakers).  The route reflector scheme allows such
+   conventional BGP speakers to coexist.  Conventional BGP speakers
+   could be members of either a Non-Client group or a Client group.
+   This allows for an easy and gradual migration from the current IBGP
+   model to the route reflection model.  One could start creating
+   clusters by configuring a single router as the designated RR and
+   configuring other RRs and their clients as normal IBGP peers.
+   Additional clusters can be created gradually.
+
+7.  Redundant RRs
+
+   Usually, a cluster of clients will have a single RR.  In that case,
+   the cluster will be identified by the BGP Identifier of the RR.
+   However, this represents a single point of failure so to make it
+   possible to have multiple RRs in the same cluster, all RRs in the
+   same cluster can be configured with a 4-byte CLUSTER_ID so that an RR
+   can discard routes from other RRs in the same cluster.
+
+8.  Avoiding Routing Information Loops
+
+   When a route is reflected, it is possible through misconfiguration to
+   form route re-distribution loops.  The route reflection method
+   defines the following attributes to detect and avoid routing
+   information loops:
+
+   ORIGINATOR_ID
+
+   ORIGINATOR_ID is a new optional, non-transitive BGP attribute of Type
+   code 9.  This attribute is 4 bytes long and it will be created by an
+   RR in reflecting a route.  This attribute will carry the BGP
+   Identifier of the originator of the route in the local AS.  A BGP
+   speaker SHOULD NOT create an ORIGINATOR_ID attribute if one already
+   exists.  A router that recognizes the ORIGINATOR_ID attribute SHOULD
+   ignore a route received with its BGP Identifier as the ORIGINATOR_ID.
+
+
+
+
+
+
+
+
+Bates, et al.               Standards Track                     [Page 6]
+
+RFC 4456                  BGP Route Reflection                April 2006
+
+
+   CLUSTER_LIST
+
+   CLUSTER_LIST is a new, optional, non-transitive BGP attribute of Type
+   code 10.  It is a sequence of CLUSTER_ID values representing the
+   reflection path that the route has passed.
+
+   When an RR reflects a route, it MUST prepend the local CLUSTER_ID to
+   the CLUSTER_LIST.  If the CLUSTER_LIST is empty, it MUST create a new
+   one.  Using this attribute an RR can identify if the routing
+   information has looped back to the same cluster due to
+   misconfiguration.  If the local CLUSTER_ID is found in the
+   CLUSTER_LIST, the advertisement received SHOULD be ignored.
+
+9.  Impact on Route Selection
+
+   The BGP Decision Process Tie Breaking rules (Sect.  9.1.2.2, [1]) are
+   modified as follows:
+
+      If a route carries the ORIGINATOR_ID attribute, then in Step f)
+      the ORIGINATOR_ID SHOULD be treated as the BGP Identifier of the
+      BGP speaker that has advertised the route.
+
+      In addition, the following rule SHOULD be inserted between Steps
+      f) and g): a BGP Speaker SHOULD prefer a route with the shorter
+      CLUSTER_LIST length.  The CLUSTER_LIST length is zero if a route
+      does not carry the CLUSTER_LIST attribute.
+
+10.  Implementation Considerations
+
+   Care should be taken to make sure that none of the BGP path
+   attributes defined above can be modified through configuration when
+   exchanging internal routing information between RRs and Clients and
+   Non-Clients.  Their modification could potentially result in routing
+   loops.
+
+   In addition, when a RR reflects a route, it SHOULD NOT modify the
+   following path attributes: NEXT_HOP, AS_PATH, LOCAL_PREF, and MED.
+   Their modification could potentially result in routing loops.
+
+11.  Configuration and Deployment Considerations
+
+   The BGP protocol provides no way for a Client to identify itself
+   dynamically as a Client of an RR.  The simplest way to achieve this
+   is by manual configuration.
+
+   One of the key component of the route reflection approach in
+   addressing the scaling issue is that the RR summarizes routing
+   information and only reflects its best path.
+
+
+
+Bates, et al.               Standards Track                     [Page 7]
+
+RFC 4456                  BGP Route Reflection                April 2006
+
+
+   Both Multi-Exit Discriminators (MEDs) and Interior Gateway Protocol
+   (IGP) metrics may impact the BGP route selection.  Because MEDs are
+   not always comparable and the IGP metric may differ for each router,
+   with certain route reflection topologies the route reflection
+   approach may not yield the same route selection result as that of the
+   full IBGP mesh approach.  A way to make route selection the same as
+   it would be with the full IBGP mesh approach is to make sure that
+   route reflectors are never forced to perform the BGP route selection
+   based on IGP metrics that are significantly different from the IGP
+   metrics of their clients, or based on incomparable MEDs.  The former
+   can be achieved by configuring the intra-cluster IGP metrics to be
+   better than the inter-cluster IGP metrics, and maintaining full mesh
+   within the cluster.  The latter can be achieved by
+
+      o  setting the local preference of a route at the border router to
+         reflect the MED values, or
+
+      o  making sure the AS-path lengths from different ASes are
+         different when the AS-path length is used as a route selection
+         criteria, or
+
+      o  configuring community-based policies to influence the route
+         selection.
+
+   One could argue though that the latter requirement is overly
+   restrictive, and perhaps impractical in some cases.  One could
+   further argue that as long as there are no routing loops, there are
+   no compelling reasons to force route selection with route reflectors
+   to be the same as it would be with the full IBGP mesh approach.
+
+   To prevent routing loops and maintain consistent routing view, it is
+   essential that the network topology be carefully considered in
+   designing a route reflection topology.  In general, the route
+   reflection topology should be congruent with the network topology
+   when there exist multiple paths for a prefix.  One commonly used
+   approach is the reflection based on Point of Presence (POP), in which
+   each POP maintains its own route reflectors serving clients in the
+   POP, and all route reflectors are fully meshed.  In addition, clients
+   of the reflectors in each POP are often fully meshed for the purpose
+   of optimal intra-POP routing, and the intra-POP IGP metrics are
+   configured to be better than the inter-POP IGP metrics.
+
+12.  Security Considerations
+
+   This extension to BGP does not change the underlying security issues
+   inherent in the existing IBGP [1, 5].
+
+
+
+
+
+Bates, et al.               Standards Track                     [Page 8]
+
+RFC 4456                  BGP Route Reflection                April 2006
+
+
+13.  Acknowledgements
+
+   The authors would like to thank Dennis Ferguson, John Scudder, Paul
+   Traina, and Tony Li for the many discussions resulting in this work.
+   This idea was developed from an earlier discussion between Tony Li
+   and Dimitri Haskin.
+
+   In addition, the authors would like to acknowledge valuable review
+   and suggestions from Yakov Rekhter on this document, and helpful
+   comments from Tony Li, Rohit Dube, John Scudder, and Bruce Cole.
+
+14.  References
+
+14.1.  Normative References
+
+   [1]  Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4
+        (BGP-4)", RFC 4271, January 2006.
+
+14.2.  Informative References
+
+   [2]  Savola, P., "Reclassification of RFC 1863 to Historic", RFC
+        4223, October 2005.
+
+   [3]  Traina, P., McPherson, D., and J. Scudder, "Autonomous System
+        Confederations for BGP", RFC 3065, February 2001.
+
+   [4]  Bates, T. and R. Chandra, "BGP Route Reflection An alternative
+        to full mesh IBGP", RFC 1966, June 1996.
+
+   [5]  Heffernan, A., "Protection of BGP Sessions via the TCP MD5
+        Signature Option", RFC 2385, August 1998.
+
+   [6]  Bates, T., Chandra, R., and E. Chen, "BGP Route Reflection - An
+        Alternative to Full Mesh IBGP", RFC 2796, April 2000.
+
+   [7]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bates, et al.               Standards Track                     [Page 9]
+
+RFC 4456                  BGP Route Reflection                April 2006
+
+
+Appendix A: Comparison with RFC 2796
+
+   The impact on route selection is added.
+
+   The pictorial description of the encoding of the CLUSTER_LIST
+   attribute is removed as the description is redundant to the BGP
+   specification, and the attribute length field is inadvertently
+   described as one octet.
+
+Appendix B: Comparison with RFC 1966
+
+   All the changes listed in Appendix A, plus the following.
+
+   Several terminologies related to route reflection are clarified, and
+   the reference to EBGP routes/peers are removed.
+
+   The handling of a routing information loop (due to route reflection)
+   by a receiver is clarified and made more consistent.
+
+   The addition of a CLUSTER_ID to the CLUSTER_LIST has been changed
+   from "append" to "prepend" to reflect the deployed code.
+
+   The section on "Configuration and Deployment Considerations" has been
+   expanded to address several operational issues.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bates, et al.               Standards Track                    [Page 10]
+
+RFC 4456                  BGP Route Reflection                April 2006
+
+
+Authors' Addresses
+
+   Tony Bates
+   Cisco Systems, Inc.
+   170 West Tasman Drive
+   San Jose, CA 95134
+
+   EMail: tbates@cisco.com
+
+
+   Ravi Chandra
+   Sonoa Systems, Inc.
+   3255-7 Scott Blvd.
+   Santa Clara, CA 95054
+
+   EMail: rchandra@sonoasystems.com
+
+
+   Enke Chen
+   Cisco Systems, Inc.
+   170 West Tasman Drive
+   San Jose, CA 95134
+
+   EMail: enkechen@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bates, et al.               Standards Track                    [Page 11]
+
+RFC 4456                  BGP Route Reflection                April 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Bates, et al.               Standards Track                    [Page 12]
+