draft-ietf-idr-route-reflect-v2-01.txt   draft-ietf-idr-route-reflect-v2-02.txt 
INTERNET-DRAFT Tony Bates INTERNET-DRAFT Tony Bates
<draft-ietf-idr-route-reflect-v2-01.txt> Ravi Chandra <draft-ietf-idr-route-reflect-v2-02.txt> Ravi Chandra
Enke Chen Enke Chen
Cisco Systems Cisco Systems
April 1999 September 1999
BGP Route Reflection BGP Route Reflection -
An alternative to full mesh IBGP An Alternative to Full Mesh IBGP
<draft-ietf-idr-route-reflect-v2-01.txt> <draft-ietf-idr-route-reflect-v2-02.txt>
Status of this Memo Status of this Memo
This document is an Internet Draft. Internet Drafts are working This document is an Internet-Draft and is in full conformance with
documents of the Internet Engineering Task Force (IETF), its Areas, all provisions of Section 10 of RFC2026. Internet-Drafts are working
and its Working Groups. Note that other groups may also distribute documents of the Internet Engineering Task Force (IETF), its areas,
working documents as Internet Drafts. 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 Internet-Drafts are draft documents valid for a maximum of six months
months. Internet Drafts may be updated, replaced, or obsoleted by and may be updated, replaced, or obsoleted by other documents at any
other documents at any time. It is not appropriate to use Internet time. It is inappropriate to use Internet-Drafts as reference
Drafts as reference material or to cite them other than as a "working material or to cite them other than as "work in progress."
draft" or "work in progress".
Please check the I-D abstract listing contained in each Internet The list of current Internet-Drafts can be accessed at
Draft directory to learn the current status of this or any other http://www.ietf.org/ietf/1id-abstracts.txt
Internet Draft.
The list of Internet-Draft Shadow Directories can be accessed at
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 25 skipping to change at page 2, line 25
This scaling problem has been well documented and a number of This scaling problem has been well documented and a number of
proposals have been made to alleviate this [2,3]. This document proposals have been made to alleviate this [2,3]. This document
represents another alternative in alleviating the need for a "full represents another alternative in alleviating the need for a "full
mesh" and is known as "Route Reflection". This approach allows a BGP mesh" and is known as "Route Reflection". This approach allows a BGP
speaker (known as "Route Reflector") to advertise IBGP learned routes speaker (known as "Route Reflector") to advertise IBGP learned routes
to certain IBGP peers. It represents a change in the commonly to certain IBGP peers. It represents a change in the commonly
understood concept of IBGP, and the addition of two new optional understood concept of IBGP, and the addition of two new optional
transitive BGP attributes to prevent loops in routing updates. transitive BGP attributes to prevent loops in routing updates.
This document is a revision of RFC1966 [4], and it includes editorial
changes, clarifications and corrections based on the deployment
experience with route reflection.
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 understand. as understand.
o Easy Transition o Easy Transition
skipping to change at page 3, line 4 skipping to change at page 3, line 7
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 part of the original AS or domain to continue be part of the original AS or domain
without any loss of BGP routing information. without any loss of BGP 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 |
skipping to change at page 3, line 36 skipping to change at page 4, line 5
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 |
skipping to change at page 6, line 20 skipping to change at page 6, line 47
defines the following attributes to detect and avoid routing defines the following attributes to detect and avoid routing
information loops: information loops:
ORIGINATOR_ID ORIGINATOR_ID
ORIGINATOR_ID is a new optional, non-transitive BGP attribute of Type 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 code 9. This attribute is 4 bytes long and it will be created by a RR
in reflecting a route. This attribute will carry the ROUTER_ID of in reflecting a route. This attribute will carry the ROUTER_ID of
the originator of the route in the local AS. A BGP speaker should not 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 create an ORIGINATOR_ID attribute if one already exists. A router
should ignore a route received with its ROUTER_ID as the which recognizes the ORIGINATOR_ID attribute should ignore a route
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 will be ignored. the advertisement received should be ignored.
8. Implementation Considerations 8. Implementation Considerations
Care should be taken to make sure that none of the BGP path Care should be taken to make sure that none of the BGP path
attributes defined above can be modified through configuration when attributes defined above can be modified through configuration when
exchanging internal routing information between RRs and Clients and exchanging internal routing information between RRs and Clients and
Non-Clients. Their modification could potential result in routing Non-Clients. Their modification could potential result in routing
loops. loops.
In addition, when a RR reflects a route, it should not modify the In addition, when a RR reflects a route, it should not modify the
skipping to change at page 8, line 18 skipping to change at page 8, line 46
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
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. 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. comments from Tony Li, Rohit Dube, and John Scudder on Section 9, and
from Bruce Cole.
12. References 12. References
[1] Rekhter, Y., and Li, T., "A Border Gateway Protocol 4 (BGP-4)", [1] Rekhter, Y., and Li, T., "A Border Gateway Protocol 4 (BGP-4)",
RFC1771, March 1995. RFC1771, 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", RFC1863, October 1995.
[3] Traina, P. "Limited Autonomous System Confederations for BGP", [3] Traina, P. "Limited Autonomous System Confederations for BGP",
RFC1965, June 1996. 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.
13. Author's Addresses 13. Author's Addresses
Tony Bates Tony Bates
Cisco Systems Cisco Systems
170 West Tasman Drive 170 West Tasman Drive
email: tbates@cisco.com email: tbates@cisco.com
Ravishanker Chandrasekeran Ravishanker Chandrasekeran
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/