draft-ietf-idr-route-reflect-02.txt   rfc1966.txt 
INTERNET-DRAFT Tony Bates Network Working Group T. Bates
<draft-ietf-idr-route-reflect-02.txt> MCI Request for Comments: 1966 cisco Systems
Ravi Chandra Category: Experimental R. Chandra
cisco Systems cisco Systems
April 1996 June 1996
BGP Route Reflection BGP Route Reflection
An alternative to full mesh IBGP An alternative to full mesh IBGP
<draft-ietf-idr-route-reflect-02.txt>
Status of this Memo Status of this Memo
This document is an Internet Draft. Internet Drafts are working This memo defines an Experimental Protocol for the Internet
documents of the Internet Engineering Task Force (IETF), its Areas, community. This memo does not specify an Internet standard of any
and its Working Groups. Note that other groups may also distribute kind. Discussion and suggestions for improvement are requested.
working documents as Internet Drafts. Distribution of this memo is unlimited.
Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a "working
draft" or "work in progress".
Please check the I-D abstract listing contained in each Internet
Draft directory to learn the current status of this or any other
Internet Draft.
Abstract Abstract
The Border Gateway Protocol [1] is an inter-autonomous system routing The Border Gateway Protocol [1] is an inter-autonomous system routing
protocol designed for TCP/IP internets. BGP deployments are protocol designed for TCP/IP internets. BGP deployments are
configured such that that all BGP speakers within a single AS must be configured such that that all BGP speakers within a single AS must be
fully meshed so that any external routing information must be re- fully meshed so that any external routing information must be re-
distributed to all other routers within that AS. This represents a distributed to all other routers within that AS. This represents a
serious scaling problem that has been well documented with several serious scaling problem that has been well documented with several
alternatives proposed [2,3]. alternatives proposed [2,3].
This document describes the use and design of a method known as This document describes the use and design of a method known as
"Route Reflection" to alleviate the the need for "full mesh" IBGP. "Route Reflection" to alleviate the the need for "full mesh" IBGP.
1. Introduction 1. Introduction
Currently in the Internet, BGP deployments are configured such that Currently in the Internet, BGP deployments are configured such that
that all BGP speakers within a single AS must be fully meshed and any that all BGP speakers within a single AS must be fully meshed and any
external routing information must be re-distributed to all other external routing information must be re-distributed to all other
skipping to change at page 3, line 44 skipping to change at page 3, line 23
routes, then it could re-advertise (or reflect) the IBGP routes 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 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 need for the IBGP session between RTR-A and RTR-B as shown in Figure
2 below. 2 below.
+------ + +-------+ +------ + +-------+
| | | | | | | |
| RTR-A | | RTR-B | | RTR-A | | RTR-B |
| | | | | | | |
+-------+ +-------+ +-------+ +-------+
\ / \ /
IBGP \ ASX / IBGP IBGP \ ASX / IBGP
\ / \ /
+-------+ +-------+
| | | |
| RTR-C | | RTR-C |
| | | |
+-------+ +-------+
Figure 2: Route Reflection IBGP Figure 2: Route Reflection IBGP
The Route Reflection scheme is based upon this basic principle. The Route Reflection scheme is based upon this basic principle.
skipping to change at page 5, line 40 skipping to change at page 5, line 19
In a simple configuration the backbone could be divided into many In a simple configuration the backbone could be divided into many
clusters. Each RR would be configured with other RRs as Non-Client 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 peers (thus all the RRs will be fully meshed.). The Clients will be
configured to maintain IBGP session only with the RR in their configured to maintain IBGP session only with the RR in their
cluster. Due to route reflection, all the IBGP speakers will receive cluster. Due to route reflection, all the IBGP speakers will receive
reflected routing information. reflected routing information.
It is normal in a Autonomous System to have BGP speakers that do not It is normal in a Autonomous System to have BGP speakers that do not
understand the concept of Route-Reflectors (let us call them understand the concept of Route-Reflectors (let us call them
conventional BGP speakers). The Route-Reflector Scheme allows such conventional BGP speakers). The Route-Reflector Scheme allows such
conventional BGP speakers to co-exist. Conventional BGP speakers conventional BGP speakers to co-exist. Conventional BGP speakers ould
could be either members of a Non-Client group or a Client group. This 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 allows for an easy and gradual migration from the current IBGP model
to the Route Reflection model. One could start creating clusters by to the Route Reflection model. One could start creating clusters by
configuring a single router as the designated RR and configuring configuring a single router as the designated RR and configuring
other RRs and their clients as normal IBGP peers. Additional clusters other RRs and their clients as normal IBGP peers. Additional clusters
can be created gradually. can be created gradually.
6. Redundant RRs 6. Redundant RRs
Usually a cluster of clients will have a single RR. In that case, the 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 cluster will be identified by the ROUTER_ID of the RR. However, this
skipping to change at page 7, line 27 skipping to change at page 6, line 47
will result in potential black holeing of traffic. will result in potential black holeing of traffic.
An RR should not modify any AS-PATH attributes (i.e. LOCAL_PREF, MED, An RR should not modify any AS-PATH attributes (i.e. LOCAL_PREF, MED,
DPA)that could change consistent route selection. This could result DPA)that could change consistent route selection. This could result
in potential loops. in potential loops.
The BGP protocol provides no way for a Client to identify itself The BGP protocol provides no way for a Client to identify itself
dynamically as a Client to an RR configured BGP speaker and the dynamically as a Client to an RR configured BGP speaker and the
simplest way to achieve this is by manual configuration. simplest way to achieve this is by manual configuration.
9. Security 9. Security Considerations
Security considerations are not discussed in this memo. Security issues are not discussed in this memo.
10. Acknowledgments 10. Acknowledgments
The authors would like to thank Dennis Ferguson, Enke Chen, John The authors would like to thank Dennis Ferguson, Enke Chen, John
Scudder, Paul Traina and Tony Li for the many discussions resulting Scudder, Paul Traina and Tony Li for the many discussions resulting
in this work. This idea was developed from an earlier discussion in this work. This idea was developed from an earlier discussion
between Tony Li and Dimitri Haskin. between Tony Li and Dimitri Haskin.
11. References 11. References
[1] Rekhter, Y., and Li, T., "A Border Gateway Protocol 4 (BGP-4)", [1] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP-4)",
RFC1771, March 1995. RFC 1771, March 1995.
[2] Haskin, D., "A BGP/IDRP Route Server alternative to a full mesh [2] Haskin, D., "A BGP/IDRP Route Server alternative to a full mesh
routing", RFC1863, October 1995. routing", RFC 1863, October 1995.
[3] Traina, P. "Limited Autonomous System Confederations for BGP", [3] Traina, P., "Limited Autonomous System Confederations for BGP",
INTERNET-DRAFT, <draft-traina-bgp-confed-00.txt>, April 1995. RFC 1965, June 1996.
12. Author's Addresses 12. Authors' Addresses
Tony Bates Tony Bates
MCI cisco Systems
2100 Reston Parkway 170 West Tasman Drive
Reston, VA 22091 San Jose, CA 95134
phone: +1 703 715 7521 Phone: +1 408 527 2470
email: Tony.Bates@mci.net EMail: tbates@cisco.com
Ravishanker Chandrasekeran Ravishanker Chandrasekeran
(Ravi Chandra) (Ravi Chandra)
cisco Systems cisco Systems
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
email: rchandra@cisco.com EMail: rchandra@cisco.com
 End of changes. 17 change blocks. 
46 lines changed or deleted 35 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/