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/