doc: Add RFC documents

1 files changed, 395 insertions, 0 deletions

diff --git a/doc/rfc/rfc1966.txt b/doc/rfc/rfc1966.txt
new file mode 100644
index 0000000..3c683d3
--- /dev/null
+++ b/doc/rfc/rfc1966.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group                                           T. Bates
+Request for Comments: 1966                                 cisco Systems
+Category: Experimental                                        R. Chandra
+                                                           cisco Systems
+                                                               June 1996
+
+
+                          BGP Route Reflection
+                    An alternative to full mesh IBGP
+
+Status of this Memo
+
+   This memo defines an Experimental Protocol for the Internet
+   community.  This memo does not specify an Internet standard of any
+   kind.  Discussion and suggestions for improvement are requested.
+   Distribution of this memo is unlimited.
+
+Abstract
+
+   The Border Gateway Protocol [1] is an inter-autonomous system routing
+   protocol designed for TCP/IP internets. BGP deployments are
+   configured such that that 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 AS. This represents a
+   serious scaling problem that has been well documented with several
+   alternatives proposed [2,3].
+
+   This document describes the use and design of a method known as
+   "Route Reflection" to alleviate the the need for "full mesh" IBGP.
+
+1.  Introduction
+
+   Currently in the Internet, BGP deployments are configured such that
+   that 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. This "full mesh" requirement clearly does not
+   scale when there are a large number of IBGP speakers as is common in
+   many of todays internet networks.
+
+   For n BGP speakers within an AS you must maintain n*(n-1)/2 unique
+   IBGP sessions. With finite resources in both bandwidth and router CPU
+   this clearly does not scale.
+
+   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". It represents a change in
+   the commonly understood concept of IBGP and the addition of two new
+
+
+
+Bates & Chandra               Experimental                      [Page 1]
+
+RFC 1966                  BGP Route Reflection                 June 1996
+
+
+   optional transitive BGP attributes.
+
+2.  Design Criteria
+
+   Route Reflection was designed to satisfy the following criteria.
+
+           o Simplicity
+
+             Any alternative must be both simple to configure as well
+             as understand.
+
+           o Easy Migration
+
+             It must be possible to migrate 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 non compliant IBGP peers
+             to continue 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.
+
+3.  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
+
+
+
+
+Bates & Chandra               Experimental                      [Page 2]
+
+RFC 1966                  BGP Route Reflection                 June 1996
+
+
+   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 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 reflect IBGP learned
+   routes, 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.
+
+4.  Terminology and Concepts
+
+   We use the term "Route Reflector" (RR) to represent an IBGP speaker
+   that participates in the reflection.  The internal peers of a RR are
+   divided into two groups:
+
+           1) Client Peers
+
+           2) Non-Client Peers
+
+   A RR reflects routes between these groups.  A 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. The Client peers
+   should not peer with internal speakers outside of their cluster.
+   Figure 3 depicts a simple example outlining the basic RR components
+   using the terminology noted above.
+
+
+
+
+Bates & Chandra               Experimental                      [Page 3]
+
+RFC 1966                  BGP Route Reflection                 June 1996
+
+
+                      / - - - - - - - - - - - - -  -\
+                      |           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
+
+5. Operation
+
+   When a route is received by a RR, 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 the peer it is receiving the
+   best path from:
+
+           1) A Route from a Non-Client peer
+
+              Reflect to all other Clients.
+
+           2) A Route from a Client peer
+
+              Reflect to all the Non-Client peers and also to the
+              Client peers other than the originator. (Hence the
+              Client peers are not required to be fully meshed).
+
+            3) Route from an EBGP peer
+
+               Send to all the Client and Non-Client Peers.
+
+
+
+
+
+Bates & Chandra               Experimental                      [Page 4]
+
+RFC 1966                  BGP Route Reflection                 June 1996
+
+
+   An Autonomous System could have many RRs. A RR treats other RRs just
+   like any other internal BGP speakers. A RR could be configured to
+   have other RRs in a Client group or Non-client group.
+
+   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 normal in a 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 co-exist. Conventional BGP speakers ould
+   be either members of 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.
+
+6.  Redundant RRs
+
+   Usually a cluster of clients will have a single RR. In that case, the
+   cluster will be identified by the ROUTER_ID 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 must be
+   configured with a 4-byte CLUSTER_ID so that an RR can discern routes
+   from other RRs in the same cluster.
+
+7.  Avoiding Routing Information Loops
+
+   As IBGP learned routes are reflected, it is possible through mis-
+   configuration 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 a
+   RR. This attribute will carry the ROUTER_ID 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 route reflector
+   must never send routing information back to the router specified in
+   ORIGINATOR_ID.
+
+
+
+
+Bates & Chandra               Experimental                      [Page 5]
+
+RFC 1966                  BGP Route Reflection                 June 1996
+
+
+   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. It is encoded as follows:
+
+
+              0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |  Attr. Flags  |Attr. Type Code|   Length      | value ...
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Where Length is the number of octets.
+
+   When a RR reflects a route from its Clients to a Non-Client peer, it
+   must append 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 is looped back to the
+   same cluster due to mis-configuration. If the local CLUSTER_ID is
+   found in the cluster-list, the advertisement will be ignored.
+
+8.  Implementation and Configuration 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. This could result is looping of routes.
+
+   In some implementations, modification of the BGP path attribute,
+   NEXT_HOP is possible. For example, there could be a need for a RR to
+   modify NEXT_HOP for EBGP learned routes sent to its internal peers.
+   However, it must not be possible for an RR to set on reflected IBGP
+   routes as this breaks the basic principle of Route Reflection and
+   will result in potential black holeing of traffic.
+
+   An RR should not modify any AS-PATH attributes (i.e. LOCAL_PREF, MED,
+   DPA)that could change consistent route selection. This could result
+   in potential loops.
+
+   The BGP protocol provides no way for a Client to identify itself
+   dynamically as a Client to an RR configured BGP speaker and the
+   simplest way to achieve this is by manual configuration.
+
+9.  Security Considerations
+
+   Security issues are not discussed in this memo.
+
+
+
+
+
+Bates & Chandra               Experimental                      [Page 6]
+
+RFC 1966                  BGP Route Reflection                 June 1996
+
+
+10. Acknowledgments
+
+   The authors would like to thank Dennis Ferguson, Enke Chen, 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.
+
+11. References
+
+   [1]  Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP-4)",
+        RFC 1771, March 1995.
+
+   [2]  Haskin, D., "A BGP/IDRP Route Server alternative to a full mesh
+        routing", RFC 1863, October 1995.
+
+   [3]  Traina, P., "Limited Autonomous System Confederations for BGP",
+        RFC 1965, June 1996.
+
+12. Authors' Addresses
+
+   Tony Bates
+   cisco Systems
+   170 West Tasman Drive
+   San Jose, CA 95134
+
+   Phone: +1 408 527 2470
+   EMail: tbates@cisco.com
+
+
+   Ravishanker Chandrasekeran
+   (Ravi Chandra)
+   cisco Systems
+   170 West Tasman Drive
+   San Jose, CA 95134
+
+   EMail: rchandra@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bates & Chandra               Experimental                      [Page 7]
+