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/