draft-ietf-idr-route-reflect-v2-00.txt		draft-ietf-idr-route-reflect-v2-01.txt
	INTERNET-DRAFT Tony Bates		INTERNET-DRAFT Tony Bates
	<draft-ietf-idr-route-reflect-v2-00.txt> Ravi Chandra		<draft-ietf-idr-route-reflect-v2-01.txt> Ravi Chandra
	Enke Chen		Enke Chen
	Cisco Systems		Cisco Systems
	November 1998		April 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-00.txt>		<draft-ietf-idr-route-reflect-v2-01.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. 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		Internet Drafts are draft documents valid for a maximum of six
	months. Internet Drafts may be updated, replaced, or obsoleted by		months. Internet Drafts may be updated, replaced, or obsoleted by
	skipping to change at page 1, line 41		skipping to change at page 1, line 41
	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].
	This document describes the use and design of a method known as		This document describes the use and design of a method known as
	'Route Reflection' to alleviate the the need for 'full mesh' IBGP.		"Route Reflection" to alleviate the the need for "full mesh" IBGP.
	1. Introduction		1. Introduction
	Currently in the Internet, BGP deployments are configured such that		Currently in the Internet, BGP deployments are configured such that
	that all BGP speakers within a single AS must be fully meshed and any		that all BGP speakers within a single AS must be fully meshed and any
	external routing information must be re-distributed to all other		external routing information must be re-distributed to all other
	routers within that AS. For n BGP speakers within an AS that		routers within that AS. For n BGP speakers within an AS that
	requires to maintain n*(n-1)/2 unique IBGP sessions. This "full		requires to maintain n*(n-1)/2 unique IBGP sessions. This "full
	mesh" requirement clearly does not scale when there are a large		mesh" requirement clearly does not scale when there are a large
	number of IBGP speakers each exchanging a large volume of routing		number of IBGP speakers each exchanging a large volume of routing
	skipping to change at page 6, line 36		skipping to change at page 6, line 36
	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 append 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 will 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
	skipping to change at page 8, line 17		skipping to change at page 8, line 17
	there exist multiple paths for a prefix. One commonly used approach		there exist multiple paths for a prefix. One commonly used approach
	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
	Security considerations are not discussed in this memo.		This extension to BGP does not change the underlying security issues
			inherent in the existing IBGP.
	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
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/