draft-ietf-idr-route-reflect-v2-03.txt   rfc2796.txt 
INTERNET-DRAFT Tony Bates
Cisco Systems
<draft-ietf-idr-route-reflect-v2-03.txt> Ravi Chandra
Enke Chen
Siara Systems
December 1999
BGP Route Reflection - Network Working Group T. Bates
An Alternative to Full Mesh IBGP Request for Comments: 2796 Cisco Systems
<draft-ietf-idr-route-reflect-v2-03.txt> Updates: 1966 R. Chandra
Category: Standards Track E. Chen
Redback Networks
April 2000
Status of this Memo BGP Route Reflection -
An Alternative to Full Mesh IBGP
This document is an Internet-Draft and is in full conformance with Status of this Memo
all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months This document specifies an Internet standards track protocol for the
and may be updated, replaced, or obsoleted by other documents at any Internet community, and requests discussion and suggestions for
time. It is inappropriate to use Internet-Drafts as reference improvements. Please refer to the current edition of the "Internet
material or to cite them other than as "work in progress." Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
The list of current Internet-Drafts can be accessed at Copyright Notice
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at Copyright (C) The Internet Society (2000). All Rights Reserved.
http://www.ietf.org/shadow.html.
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. Currently in the Internet BGP protocol designed for TCP/IP internets. Currently in the Internet BGP
deployments are configured such that that all BGP speakers within a deployments are configured such that that all BGP speakers within a
single AS must be fully meshed so that any external routing single AS must be fully meshed so that any external routing
information must be re-distributed to all other routers within that information must be re-distributed to all other routers within that
AS. This represents a serious scaling problem that has been well AS. This represents a serious scaling problem that has been well
documented with several alternatives proposed [2,3]. documented with several alternatives proposed [2,3].
skipping to change at page 2, line 34 skipping to change at page 2, line 23
This document is a revision of RFC1966 [4], and it includes editorial This document is a revision of RFC1966 [4], and it includes editorial
changes, clarifications and corrections based on the deployment changes, clarifications and corrections based on the deployment
experience with route reflection. These revisions are summarized in experience with route reflection. These revisions are summarized in
the Appendix. the Appendix.
2. Design Criteria 2. Design Criteria
Route Reflection was designed to satisfy the following criteria. Route Reflection was designed to satisfy the following criteria.
o Simplicity o Simplicity
Any alternative must be both simple to configure as well Any alternative must be both simple to configure as well as
as understand. understand.
o Easy Transition o Easy Transition
It must be possible to transition from a full mesh It must be possible to transition from a full mesh
configuration without the need to change either topology configuration without the need to change either topology or AS.
or AS. This is an unfortunate management overhead of the This is an unfortunate management overhead of the technique
technique proposed in [3]. proposed in [3].
o Compatibility o Compatibility
It must be possible for non compliant IBGP peers It must be possible for non compliant IBGP peers to continue be
to continue be part of the original AS or domain part of the original AS or domain without any loss of BGP
without any loss of BGP routing information. routing information.
These criteria were motivated by operational experiences of a very These criteria were motivated by operational experiences of a very
large and topology rich network with many external connections. large and topology rich network with many external connections.
3. Route Reflection 3. Route Reflection
The basic idea of Route Reflection is very simple. Let us consider The basic idea of Route Reflection is very simple. Let us consider
the simple example depicted in Figure 1 below. the simple example depicted in Figure 1 below.
+-------+ +-------+ +-------+ +-------+
| | IBGP | | | | IBGP | |
| RTR-A |--------| RTR-B | | RTR-A |--------| RTR-B |
| | | | | | | |
+-------+ +-------+ +-------+ +-------+
\ / \ /
IBGP \ ASX / IBGP IBGP \ ASX / IBGP
\ / \ /
+-------+ +-------+
| | | |
| RTR-C | | RTR-C |
| | | |
+-------+ +-------+
Figure 1: Full Mesh IBGP Figure 1: Full Mesh IBGP
In ASX there are three IBGP speakers (routers RTR-A, RTR-B and RTR- 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 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 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) 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 will not re-advertise these IBGP learned routes to other IBGP
speakers. speakers.
If this rule is relaxed and RTR-C is allowed to advertise IBGP 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) 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 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 would eliminate the need for the IBGP session between RTR-A and RTR-B
as shown in Figure 2 below. as shown in Figure 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.
4. Terminology and Concepts 4. Terminology and Concepts
We use the term "Route Reflection" to describe the operation of a BGP We use the term "Route Reflection" to describe the operation of a BGP
speaker advertising an IBGP learned route to another IBGP peer. Such 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 a BGP speaker is said to be a "Route Reflector" (RR), and such a
route is said to be a reflected route. route is said to be a reflected route.
skipping to change at page 5, line 5 skipping to change at page 4, line 24
1) Client Peers 1) Client Peers
2) Non-Client Peers 2) Non-Client Peers
A RR reflects routes between these groups, and may reflect routes A RR reflects routes between these groups, and may reflect routes
among client peers. A RR along with its client peers form a Cluster. among client peers. A RR along with its client peers form a Cluster.
The Non-Client peer must be fully meshed but the Client peers need 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 not be fully meshed. Figure 3 depicts a simple example outlining the
basic RR components using the terminology noted above. basic RR components using the terminology noted above.
/ - - - - - - - - - - - - - - / - - - - - - - - - - - - - -
| Cluster | | Cluster |
+-------+ +-------+ +-------+ +-------+
| | | | | | | | | | | |
| RTR-A | | RTR-B | | RTR-A | | RTR-B |
| |Client | |Client | | | |Client | |Client | |
+-------+ +-------+ +-------+ +-------+
| \ / | | \ / |
IBGP \ / IBGP IBGP \ / IBGP
| \ / | | \ / |
+-------+ +-------+
| | | | | | | |
| RTR-C | | RTR-C |
| | RR | | | | RR | |
+-------+ +-------+
| / \ | | / \ |
- - - - - /- - -\- - - - - - / - - - - - /- - -\- - - - - - /
IBGP / \ IBGP IBGP / \ IBGP
+-------+ +-------+ +-------+ +-------+
| RTR-D | IBGP | RTR-E | | RTR-D | IBGP | RTR-E |
| Non- |---------| Non- | | Non- |---------| Non- |
|Client | |Client | |Client | |Client |
+-------+ +-------+ +-------+ +-------+
Figure 3: RR Components Figure 3: RR Components
5. Operation 5. Operation
When a RR receives a route from an IBGP peer, it selects the best When a RR receives a route from an IBGP peer, it selects the best
path based on its path selection rule. After the best path is 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 selected, it must do the following depending on the type of the peer
it is receiving the best path from: it is receiving the best path from:
1) A Route from a Non-Client IBGP peer 1) A Route from a Non-Client IBGP peer
Reflect to all the Clients. Reflect to all the Clients.
2) A Route from a Client peer 2) A Route from a Client peer
Reflect to all the Non-Client peers and also to the Reflect to all the Non-Client peers and also to the Client
Client peers. (Hence the Client peers are not required peers. (Hence the Client peers are not required to be fully
to be fully meshed.) meshed.)
An Autonomous System could have many RRs. A RR treats other RRs just 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 like any other internal BGP speakers. A RR could be configured to
have other RRs in a Client group or Non-client group. have other RRs in a Client group or Non-client group.
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
skipping to change at page 7, line 11 skipping to change at page 6, line 28
create an ORIGINATOR_ID attribute if one already exists. A router create an ORIGINATOR_ID attribute if one already exists. A router
which recognizes the ORIGINATOR_ID attribute should ignore a route which recognizes the ORIGINATOR_ID attribute should ignore a route
received with its ROUTER_ID as the ORIGINATOR_ID. received with its ROUTER_ID as the ORIGINATOR_ID.
CLUSTER_LIST CLUSTER_LIST
Cluster-list is a new optional, non-transitive BGP attribute of Type Cluster-list is a new optional, non-transitive BGP attribute of Type
code 10. It is a sequence of CLUSTER_ID values representing the code 10. It is a sequence of CLUSTER_ID values representing the
reflection path that the route has passed. It is encoded as follows: 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 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 ... | Attr. Flags |Attr. Type Code| Length | value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where Length is the number of octets. Where Length is the number of octets.
When a RR reflects a route, it must prepend the local CLUSTER_ID to When a 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 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 one. Using this attribute an RR can identify if the routing
information is looped back to the same cluster due to mis- information is looped back to the same cluster due to mis-
configuration. If the local CLUSTER_ID is found in the cluster-list, configuration. If the local CLUSTER_ID is found in the cluster-list,
the advertisement received should be ignored. the advertisement received should be ignored.
skipping to change at page 8, line 15 skipping to change at page 7, line 28
reflection approach may not yield the same route selection result as reflection approach may not yield the same route selection result as
that of the full IBGP mesh approach. A way to make route selection 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 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 sure that route reflectors are never forced to perform the BGP route
selection based on IGP metrics which are significantly different from selection based on IGP metrics which are significantly different from
the IGP metrics of their clients, or based on incomparable MEDs. The the IGP metrics of their clients, or based on incomparable MEDs. The
former can be achieved by configuring the intra-cluster IGP metrics former can be achieved by configuring the intra-cluster IGP metrics
to be better than the inter-cluster IGP metrics, and maintaining full to be better than the inter-cluster IGP metrics, and maintaining full
mesh within the cluster. The latter can be achieved by: mesh within the cluster. The latter can be achieved by:
o setting the local preference of a route at the border router o setting the local preference of a route at the border router to
to reflect the MED values. reflect the MED values.
o or by making sure the AS-path lengths from different ASs are o or by making sure the AS-path lengths from different ASs are
different when the AS-path length is used as a route different when the AS-path length is used as a route selection
selection criteria. criteria.
o or by configuring community based policies using which the o or by configuring community based policies using which the
reflector can decide on the best route. reflector can decide on the best route.
One could argue though that the latter requirement is overly One could argue though that the latter requirement is overly
restrictive, and perhaps impractical in some cases. One could restrictive, and perhaps impractical in some cases. One could
further argue that as long as there are no routing loops, there are further argue that as long as there are no routing loops, there are
no compelling reasons to force route selection with route reflectors 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 be the same as it would be with the full IBGP mesh approach.
To prevent routing loops and maintain consistent routing view, it is To prevent routing loops and maintain consistent routing view, it is
essential that the network topology be carefully considered in essential that the network topology be carefully considered in
designing a route reflection topology. In general, the route designing a route reflection topology. In general, the route
reflection topology should congruent with the network topology when reflection topology should congruent with the network topology when
there exist multiple paths for a prefix. One commonly used approach there exist multiple paths for a prefix. One commonly used approach
is the POP-based reflection, in which each POP maintains its own is the POP-based reflection, in which each POP maintains its own
route reflectors serving clients in the POP, and all route reflectors route reflectors serving clients in the POP, and all route reflectors
are fully meshed. In addition, clients of the reflectors in each POP are fully meshed. In addition, clients of the reflectors in each POP
are often fully meshed for the purpose of optimal intra-POP routing, 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 and the intra-POP IGP metrics are configured to be better than the
inter-POP IGP metrics. inter-POP IGP metrics.
10. Security 10. Security Considerations
This extension to BGP does not change the underlying security issues This extension to BGP does not change the underlying security issues
inherent in the existing IBGP [5]. inherent in the existing IBGP [5].
11. Acknowledgments 11. Acknowledgments
The authors would like to thank Dennis Ferguson, John Scudder, Paul The authors would like to thank Dennis Ferguson, John Scudder, Paul
Traina and Tony Li for the many discussions resulting in this work. Traina and Tony Li for the many discussions resulting in this work.
This idea was developed from an earlier discussion between Tony Li This idea was developed from an earlier discussion between Tony Li
and Dimitri Haskin. and Dimitri Haskin.
In addition, the authors would like to acknowledge valuable review In addition, the authors would like to acknowledge valuable review
and suggestions from Yakov Rekhter on this document, and helpful and suggestions from Yakov Rekhter on this document, and helpful
comments from Tony Li, Rohit Dube, and John Scudder on Section 9, and comments from Tony Li, Rohit Dube, and John Scudder on Section 9, and
from Bruce Cole. from Bruce Cole.
skipping to change at page 9, line 14 skipping to change at page 8, line 25
The authors would like to thank Dennis Ferguson, John Scudder, Paul The authors would like to thank Dennis Ferguson, John Scudder, Paul
Traina and Tony Li for the many discussions resulting in this work. Traina and Tony Li for the many discussions resulting in this work.
This idea was developed from an earlier discussion between Tony Li This idea was developed from an earlier discussion between Tony Li
and Dimitri Haskin. and Dimitri Haskin.
In addition, the authors would like to acknowledge valuable review In addition, the authors would like to acknowledge valuable review
and suggestions from Yakov Rekhter on this document, and helpful and suggestions from Yakov Rekhter on this document, and helpful
comments from Tony Li, Rohit Dube, and John Scudder on Section 9, and comments from Tony Li, Rohit Dube, and John Scudder on Section 9, and
from Bruce Cole. from Bruce Cole.
12. Appendix Comparison with RFC 1966 13. 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.
[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.
14. Authors' Addresses
Tony Bates
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
EMail: tbates@cisco.com
Ravi Chandra
Redback Networks Inc.
350 Holger Way.
San Jose, CA 95134
EMail: rchandra@redback.com
Enke Chen
Redback Networks Inc.
350 Holger Way.
San Jose, CA 95134
EMail: enke@redback.com
Appendix Comparison with RFC 1966
Several terminologies related to route reflection are clarified, and Several terminologies related to route reflection are clarified, and
the reference to EBGP routes/peers are removed. the reference to EBGP routes/peers are removed.
The handling of a routing information loop (due to route reflection) The handling of a routing information loop (due to route reflection)
by a receiver is clarified and made more consistent. by a receiver is clarified and made more consistent.
The addition of a CLUSTER_ID to the CLUSTER_LIST has been changed The addition of a CLUSTER_ID to the CLUSTER_LIST has been changed
from "append" to "prepend" to reflect the deployed code. from "append" to "prepend" to reflect the deployed code.
The section on "Configuration and Deployment Considerations" has been The section on "Configuration and Deployment Considerations" has been
expanded to address several operational issues. expanded to address several operational issues.
13. References Full Copyright Statement
[1] Rekhter, Y., and Li, T., "A Border Gateway Protocol 4 (BGP-4)",
RFC1771, March 1995.
[2] Haskin, D., "A BGP/IDRP Route Server alternative to a full mesh
routing", RFC1863, October 1995.
[3] Traina, P. "Limited Autonomous System Confederations for BGP",
RFC1965, June 1996.
[4] Bates, T., and Chandra, R., "BGP Route Reflection An alternative
to full mesh IBGP", RFC1966, June 1996.
[5] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Sig-
nature Option", RFC2385, August 1998.
14. Author's Addresses
Tony Bates Copyright (C) The Internet Society (2000). All Rights Reserved.
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
email: tbates@cisco.com 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.
Ravi Chandra The limited permissions granted above are perpetual and will not be
Siara Systems, Inc. revoked by the Internet Society or its successors or assigns.
1195 Borregas Ave.
Sunnyvale, CA 94089
email: rchandra@siara.com 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.
Enke Chen Acknowledgement
Siara Systems, Inc.
1195 Borregas Ave.
Sunnyvale, CA 94089
email: enke@siara.com Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 37 change blocks. 
138 lines changed or deleted 164 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/