draft-ietf-idr-route-reflect-v2-02.txt   draft-ietf-idr-route-reflect-v2-03.txt 
INTERNET-DRAFT Tony Bates INTERNET-DRAFT Tony Bates
<draft-ietf-idr-route-reflect-v2-02.txt> Ravi Chandra
Enke Chen
Cisco Systems Cisco Systems
September 1999 <draft-ietf-idr-route-reflect-v2-03.txt> Ravi Chandra
Enke Chen
Siara Systems
December 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-02.txt> <draft-ietf-idr-route-reflect-v2-03.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
skipping to change at page 2, line 27 skipping to change at page 2, line 27
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 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. experience with route reflection. These revisions are summarized in
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 understand. as understand.
skipping to change at page 9, line 14 skipping to change at page 9, line 14
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. References 12. Appendix Comparison with RFC 1966
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.
13. 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 [4] Bates, T., and Chandra, R., "BGP Route Reflection An alternative
to full mesh IBGP", RFC1966, June 1996. to full mesh IBGP", RFC1966, June 1996.
[5] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Sig- [5] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Sig-
nature Option", RFC2385, August 1998. nature Option", RFC2385, August 1998.
13. Author's Addresses 14. Author's Addresses
Tony Bates Tony Bates
Cisco Systems Cisco Systems, Inc.
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134
email: tbates@cisco.com email: tbates@cisco.com
Ravishanker Chandrasekeran Ravi Chandra
(Ravi Chandra) Siara Systems, Inc.
Cisco Systems 1195 Borregas Ave.
170 West Tasman Drive Sunnyvale, CA 94089
San Jose, CA 95134
email: rchandra@cisco.com email: rchandra@siara.com
Enke Chen Enke Chen
Cisco Systems Siara Systems, Inc.
170 West Tasman Drive 1195 Borregas Ave.
San Jose, CA 95134 Sunnyvale, CA 94089
email: enkechen@cisco.com email: enke@siara.com
 End of changes. 

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