--- 1/draft-ietf-idr-route-reflect-v2-02.txt 2006-02-04 23:31:52.000000000 +0100 +++ 2/draft-ietf-idr-route-reflect-v2-03.txt 2006-02-04 23:31:52.000000000 +0100 @@ -1,19 +1,20 @@ INTERNET-DRAFT Tony Bates - Ravi Chandra - Enke Chen Cisco Systems - September 1999 + Ravi Chandra + Enke Chen + Siara Systems + December 1999 BGP Route Reflection - An Alternative to Full Mesh IBGP - + Status of this Memo This document is an Internet-Draft and is in full conformance with 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 @@ -55,21 +56,22 @@ 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". This approach allows a BGP speaker (known as "Route Reflector") to advertise IBGP learned routes to certain IBGP peers. It represents a change in the commonly understood concept of IBGP, and the addition of two new optional 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. + experience with route reflection. These revisions are summarized in + the Appendix. 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. @@ -343,49 +345,63 @@ The authors would like to thank Dennis Ferguson, 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. In addition, the authors would like to acknowledge valuable review and suggestions from Yakov Rekhter on this document, and helpful comments from Tony Li, Rohit Dube, and John Scudder on Section 9, and 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)", 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. -13. Author's Addresses +14. Author's Addresses Tony Bates - Cisco Systems + Cisco Systems, Inc. 170 West Tasman Drive + San Jose, CA 95134 email: tbates@cisco.com - Ravishanker Chandrasekeran - (Ravi Chandra) - Cisco Systems - 170 West Tasman Drive - San Jose, CA 95134 + Ravi Chandra + Siara Systems, Inc. + 1195 Borregas Ave. + Sunnyvale, CA 94089 - email: rchandra@cisco.com + email: rchandra@siara.com Enke Chen - Cisco Systems - 170 West Tasman Drive - San Jose, CA 95134 + Siara Systems, Inc. + 1195 Borregas Ave. + Sunnyvale, CA 94089 - email: enkechen@cisco.com + email: enke@siara.com