draft-ietf-grow-rift-00.txt		draft-ietf-grow-rift-01.txt
	INTERNET-DRAFT D. Meyer (Editor)		INTERNET-DRAFT D. Meyer (Editor)
			draft-ietf-grow-rift-01.txt
	Category Informational		Category Informational
	Expires: July 2004 January 2004		Expires: August 2004 February 2004
	Operational Concerns and Considerations for Routing Protocol		Operational Concerns and Considerations for Routing Protocol
	Design -- Risk, Interference, and Fit (RIFT)		Design -- Risk, Interference, and Fit (RIFT)
	<draft-ietf-grow-rift-00.txt>		<draft-ietf-grow-rift-01.txt>
	Status of this Document		Status of this Document
	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.		all provisions of Section 10 of RFC2026.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	skipping to change at page 3, line 17		skipping to change at page 3, line 17
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
	2. Scope of this Work . . . . . . . . . . . . . . . . . . . . . . 5		2. Scope of this Work . . . . . . . . . . . . . . . . . . . . . . 5
	3. Problem Statement. . . . . . . . . . . . . . . . . . . . . . . 6		3. Problem Statement. . . . . . . . . . . . . . . . . . . . . . . 6
	3.1. Risk, Interference, and Application Fit (RIFT) . . . . . . 6		3.1. Risk, Interference, and Application Fit (RIFT) . . . . . . 6
	3.1.1. Risk: Software Engineering . . . . . . . . . . . . . . . 7		3.1.1. Risk: Software Engineering . . . . . . . . . . . . . . . 7
	3.1.2. Interference: Protocol Specification/Dynamic Behavior . 7		3.1.2. Interference: Protocol Specification/Dynamic Behavior . 7
	3.1.3. Application Fit: Distribution Topology . . . . . . . . . 7		3.1.3. Application Fit: Distribution Topology . . . . . . . . . 7
	4. Definitions. . . . . . . . . . . . . . . . . . . . . . . . . . 8		4. Definitions. . . . . . . . . . . . . . . . . . . . . . . . . . 8
	4.1. Reachability Information. . . . . . . . . . . . . . . . . . 8		4.1. Reachability Information. . . . . . . . . . . . . . . . . . 8
	4.2. Layer 3 Routing Information . . . . . . . . . . . . . . . . 8		4.2. Layer 3 Routing Information . . . . . . . . . . . . . . . . 8
			4.2.1. Standard Routing Information . . . . . . . . . . . . . . 9
	4.3. Auxiliary (non-routing) Information . . . . . . . . . . . . 9		4.3. Auxiliary (non-routing) Information . . . . . . . . . . . . 9
	4.4. Address Family Identifier (AFI) . . . . . . . . . . . . . . 9		4.4. Address Family Identifier (AFI) . . . . . . . . . . . . . . 9
	4.5. Subsequent Address Family Identifier (SAFI) . . . . . . . . 9		4.5. Subsequent Address Family Identifier (SAFI) . . . . . . . . 10
	4.6. Network Layer Reachability. . . . . . . . . . . . . . . . . 9		4.6. Network Layer Reachability. . . . . . . . . . . . . . . . . 10
	4.7. Application . . . . . . . . . . . . . . . . . . . . . . . . 10		4.7. Application . . . . . . . . . . . . . . . . . . . . . . . . 10
	4.8. Routing Protocol. . . . . . . . . . . . . . . . . . . . . . 10		4.8. Routing Protocol. . . . . . . . . . . . . . . . . . . . . . 10
	4.9. Fate Sharing. . . . . . . . . . . . . . . . . . . . . . . . 10		4.9. Fate Sharing. . . . . . . . . . . . . . . . . . . . . . . . 11
	5. Architectural Models . . . . . . . . . . . . . . . . . . . . . 11		5. Architectural Models . . . . . . . . . . . . . . . . . . . . . 11
	5.1. General Purpose Transport Infrastructure (GPT) Model. . . . 11		5.1. General Purpose Transport Infrastructure (GPT) Model. . . . 12
	5.2. Special Purpose Transport Infrastructure (SPT) Model. . . . 12		5.2. Special Purpose Transport Infrastructure (SPT) Model. . . . 12
	6. Analyzing Risk and Interference. . . . . . . . . . . . . . . . 12		6. Analyzing Risk and Interference. . . . . . . . . . . . . . . . 13
	6.1. Risk: Code Impact, and Resource Sharing . . . . . . . . . . 13		6.1. Risk: Code Impact, and Resource Sharing . . . . . . . . . . 13
	6.1.1. Code Impact. . . . . . . . . . . . . . . . . . . . . . . 13		6.1.1. Code Impact. . . . . . . . . . . . . . . . . . . . . . . 13
	6.1.2. Resource Sharing . . . . . . . . . . . . . . . . . . . . 13		6.1.2. Resource Sharing . . . . . . . . . . . . . . . . . . . . 14
	6.1.2.1. Resource Sharing and Operating System Level Issues . 14		6.1.2.1. Resource Sharing and Operating System Level Issues . 14
	6.2. Interference. . . . . . . . . . . . . . . . . . . . . . . . 14		6.2. Interference. . . . . . . . . . . . . . . . . . . . . . . . 15
	7. GTP and SPT Models: Risk and Interference. . . . . . . . . . . 15		7. GTP and SPT Models: Risk and Interference. . . . . . . . . . . 15
	7.1. Risk. . . . . . . . . . . . . . . . . . . . . . . . . . . . 15		7.1. Risk. . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
	7.1.1. Code Impact. . . . . . . . . . . . . . . . . . . . . . . 15		7.1.1. Code Impact. . . . . . . . . . . . . . . . . . . . . . . 16
	7.1.2. Resource Sharing . . . . . . . . . . . . . . . . . . . . 16		7.1.2. Resource Sharing . . . . . . . . . . . . . . . . . . . . 17
	7.1.3. Multisession BGP . . . . . . . . . . . . . . . . . . . . 17		7.1.3. Multisession BGP . . . . . . . . . . . . . . . . . . . . 17
	7.2. Interference. . . . . . . . . . . . . . . . . . . . . . . . 18		7.2. Interference. . . . . . . . . . . . . . . . . . . . . . . . 19
	7.2.1. Multisession BGP . . . . . . . . . . . . . . . . . . . . 19		7.2.1. Multisession BGP . . . . . . . . . . . . . . . . . . . . 19
	8. Application Fit. . . . . . . . . . . . . . . . . . . . . . . . 19		8. Application Fit. . . . . . . . . . . . . . . . . . . . . . . . 19
	8.1. RFC 2547 Style VPNs . . . . . . . . . . . . . . . . . . . . 19		8.1. RFC 2547 Style VPNs . . . . . . . . . . . . . . . . . . . . 20
	8.2. VPWS. . . . . . . . . . . . . . . . . . . . . . . . . . . . 20		8.1.1. RFC 2547 and Label Distribution. . . . . . . . . . . . . 21
	8.3. VPLS. . . . . . . . . . . . . . . . . . . . . . . . . . . . 21		8.2. VPWS. . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
	9. Operational Implications . . . . . . . . . . . . . . . . . . . 22		8.2.1. Assertion #1 . . . . . . . . . . . . . . . . . . . . . . 22
	10. Other Models. . . . . . . . . . . . . . . . . . . . . . . . . 22		8.2.2. Counter-Assertion #1 . . . . . . . . . . . . . . . . . . 22
	11. Conclusions and Recommendations . . . . . . . . . . . . . . . 22		8.2.3. Assertion #2 . . . . . . . . . . . . . . . . . . . . . . 23
	12. Intellectual Property . . . . . . . . . . . . . . . . . . . . 22		8.2.4. Counter-Assertion #2 . . . . . . . . . . . . . . . . . . 23
	13. Design Team . . . . . . . . . . . . . . . . . . . . . . . . . 22		8.2.4.1. Assertion #2a . . . . . . . . . . . . . . . . . . . . 23
	14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23		8.2.4.2. Counter-Assertion #2a . . . . . . . . . . . . . . . . 23
	15. Security Considerations . . . . . . . . . . . . . . . . . . . 24		8.2.5. Assertion #3 . . . . . . . . . . . . . . . . . . . . . . 24
	16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24		8.2.6. Counter-Assertion #3 . . . . . . . . . . . . . . . . . . 25
	17. References. . . . . . . . . . . . . . . . . . . . . . . . . . 25		8.3. VPWS and Per-Wire Attributes. . . . . . . . . . . . . . . . 27
	17.1. Normative References . . . . . . . . . . . . . . . . . . . 25		8.3.1. Assertion #4 . . . . . . . . . . . . . . . . . . . . . . 27
	17.2. Informative References . . . . . . . . . . . . . . . . . . 27		8.3.2. Counter-Assertion #4:. . . . . . . . . . . . . . . . . . 27
	18. Editor's Address. . . . . . . . . . . . . . . . . . . . . . . 29		8.3.3. Assertion #5 . . . . . . . . . . . . . . . . . . . . . . 27
	19. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 29		8.3.4. Counter-Assertion #5 . . . . . . . . . . . . . . . . . . 27
			8.3.5. Assertion #6 . . . . . . . . . . . . . . . . . . . . . . 28
			8.3.6. Counter-Assertion #6 . . . . . . . . . . . . . . . . . . 28
			8.3.7. Assertion #7:. . . . . . . . . . . . . . . . . . . . . . 28
			8.3.8. Counter-Assertion #7:. . . . . . . . . . . . . . . . . . 29
			8.4. VPLS. . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
			8.4.1. Assertion #8 . . . . . . . . . . . . . . . . . . . . . . 29
			8.4.2. Counter-Assertion #8 . . . . . . . . . . . . . . . . . . 29
			8.4.3. Assertion #9 . . . . . . . . . . . . . . . . . . . . . . 30
			8.4.4. Counter-Assertion #9 . . . . . . . . . . . . . . . . . . 30
			9. Operational Implications . . . . . . . . . . . . . . . . . . . 30
			9.1. OAM Functionality . . . . . . . . . . . . . . . . . . . . . 30
			9.1.1. Assertion #10: . . . . . . . . . . . . . . . . . . . . . 30
			9.1.2. Counter-Assertion #10: . . . . . . . . . . . . . . . . . 31
			9.2. Full-Mesh Issues. . . . . . . . . . . . . . . . . . . . . . 31
			10. Conclusions and Recommendations . . . . . . . . . . . . . . . 31
			11. Intellectual Property . . . . . . . . . . . . . . . . . . . . 31
			12. Design Team . . . . . . . . . . . . . . . . . . . . . . . . . 31
			13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32
			14. Security Considerations . . . . . . . . . . . . . . . . . . . 33
			15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
			16. References. . . . . . . . . . . . . . . . . . . . . . . . . . 34
			16.1. Normative References . . . . . . . . . . . . . . . . . . . 34
			16.2. Informative References . . . . . . . . . . . . . . . . . . 37
			17. Editor's Address. . . . . . . . . . . . . . . . . . . . . . . 38
			18. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 38
	1. Introduction		1. Introduction
	The stability of the global Internet routing system has been the		The stability of the global Internet routing system has been the
	subject of much research (see e.g., [RVBIB]) and discussion on		subject of much research (see e.g., [RVBIB]) and discussion on
	various IETF mailing lists [IETFOL]. Much of the research into the		various IETF mailing lists [IETFOL]. Much of the research into the
	routing system has centered around the analysis of the dynamics and		routing system has centered around the analysis of the dynamics and
	stability of the Border Gateway Protocol Version 4 [BGP] (hereafter		stability of the Border Gateway Protocol Version 4 [BGP] (hereafter
	referred to as BGP).		referred to as BGP).
	skipping to change at page 9, line 5		skipping to change at page 9, line 5
	Finally, if one defines routing information as "information used to		Finally, if one defines routing information as "information used to
	forward packets", combined with the above definition of reachability		forward packets", combined with the above definition of reachability
	information, then we can consider information such as described in		information, then we can consider information such as described in
	[FLOW] (for example) to be routing information (since it is		[FLOW] (for example) to be routing information (since it is
	attempting to add a level of granularity to how an 'aggregate' is		attempting to add a level of granularity to how an 'aggregate' is
	defined). That is, [FLOW] intends to complement to the existing		defined). That is, [FLOW] intends to complement to the existing
	routing information, and the flow information is dependent on IP4		routing information, and the flow information is dependent on IP4
	unicast reachability advertised by the same neighbor.		unicast reachability advertised by the same neighbor.
			4.2.1. Standard Routing Information
			In the most general terms, then, a routing protocol distributes data
			to accomplish the following three functionalities:
			(i). To govern the routing decision process (e.g., the
			standard BGP decision process)
			(ii). To constrain the flow of information (for example, with
			BGP communities)
			(iii). To tell the recipient how to get packets to the next hop
			We will refer to information that falls into this class as "standard
			routing information".
	4.3. Auxiliary (non-routing) Information		4.3. Auxiliary (non-routing) Information
	Auxiliary Information is any information that is exchanged by routers		Auxiliary Information is any information that is exchanged by routers
	which is neither Layer 3 routing information, nor reachability		which is neither Layer 3 routing information, nor reachability
	information. IS-IS hostname TLVs are an example of Axillary		information. IS-IS hostname TLVs are an example of auxiliary
	information [RFC1142].		information [RFC1142].
	4.4. Address Family Identifier (AFI)		4.4. Address Family Identifier (AFI)
	An Address Family contains addresses that share common structure and		An Address Family contains addresses that share common structure and
	semantics. An Address Family Identifier (AFI) uniquely identifies		semantics. An Address Family Identifier (AFI) uniquely identifies
	each address family. Several routing protocol messages contain a		each address family. Several routing protocol messages contain a
	field that represents the AFI. The AFI identifies the address type		field that represents the AFI. The AFI identifies the address type
	used by another data item contained in that message. The Routing		used by another data item contained in that message. The Routing
	Information Protocol (RIP) [RFC2453], Distance Vector Multicast		Information Protocol (RIP) [RFC2453], Distance Vector Multicast
	skipping to change at page 18, line 27		skipping to change at page 18, line 44
	When formulated in this way, one can see that one objective of		When formulated in this way, one can see that one objective of
	multisession BGP is to find a value, call it g, such that		multisession BGP is to find a value, call it g, such that
	f(GPT, g) ~ f(SPT,k), for small values of k (i.e., k close to 1)		f(GPT, g) ~ f(SPT,k), for small values of k (i.e., k close to 1)
	where		where
	A(n) ~ B(k) ==> A(n) = B(k) + h(n), h(n) >= 0		A(n) ~ B(k) ==> A(n) = B(k) + h(n), h(n) >= 0
	That is, A(n) is approaches B(k)		That is, A(n) is approximately equal to B(k)
	In this case, g is the size of the multisession AFI/SAFI grouping,		In this case, g is the size of the multisession AFI/SAFI grouping,
	and for small values of g, multisession BGP can have a risk profile		and for small values of g, multisession BGP can have a risk profile
	that looks very much like the SPT risk profile. In particular, for g		that looks very much like the SPT risk profile. In particular, for g
	= 1, both models would have similar risk profiles. Of course, there		= 1, both models would have similar risk profiles. Of course, there
	are many other components of risk that that are not considered by		are many other components of risk that that are not considered by
	this analysis, such as collateral issues resulting from the existence		this analysis, such as collateral issues resulting from the existence
	of faulty shared code, operating system process and memory structure,		of faulty shared code, operating system process and memory structure,
	etc.		etc.
	skipping to change at page 19, line 18		skipping to change at page 19, line 29
	GPT model by eliminating one potential source of interference,		GPT model by eliminating one potential source of interference,
	namely, the potential interference due to presence of multiple		namely, the potential interference due to presence of multiple
	AFI/SAFIs in a single BGP session. Following the analysis presented		AFI/SAFIs in a single BGP session. Following the analysis presented
	in section 7.1.3, we can see that for small groupings (described as		in section 7.1.3, we can see that for small groupings (described as
	small values of g in section 7.1.3), the interference profiles of		small values of g in section 7.1.3), the interference profiles of
	both models converge.		both models converge.
	8. Application Fit		8. Application Fit
	In the following sub-sections, application fit is examined from the		In the following sub-sections, application fit is examined from the
	perspective of analyzing the data distribution needs of three		perspective of analyzing the signaling and data distribution needs of
	representative classes of application, namely:		three representative applications, namely:
	RFC 2547 Style VPNs		RFC 2547 Style VPNs
	VPWS		VPWS
	VPLS		VPLS
	8.1. RFC 2547 Style VPNs		However, before investigating how the BGP data distribution mechanism
			(and its extensions) fit the requirements of these applications, it
			is useful to briefly review the gross characteristics of the BGP data
			distribution infrastructure. In particular, we examine which
			distribution topologies can be naturally built using internal BGP (or
			iBGP).
	First, it is useful to review the distribution mechanisms available		iBGP has been described loosely as a broadcast mechanism since an
	in BGP, in particular, in i-BGP. i-BGP has been described loosely as		iBGP speaker sends information to all its peers. This is typically
	a broadcast mechanism since an i-BGP speaker sends information to all		achieved by means of one or more route reflectors (or RRs); a more
	its peers. This is typically achieved by means of one or more route		direct but less scalable means is for each iBGP speaker to have a BGP
	reflectors; a more direct but less scalable means is for each i-BGP		session with each iBGP peer. It may, however, be more accurate to
	speaker to have a BGP session with each i-BGP peer.		characterize iBGP as a constrained broadcast mechanism. This is
			because the use of communities in conjunction with import and export
			policies allows an iBGP speaker to effectively limit its
			communication to a subset of the full set of iBGP peers; the
			efficiency of constrained broadcast can be improved by techniques
			such as described in [ORF] and [RTCONST].
	However, it is more accurate to characterize i-BGP as a constrained		8.1. RFC 2547 Style VPNs
	broadcast mechanism. This is because the use of communities in
	conjunction with import and export policies allows an i-BGP speaker
	to effectively limit its communication to a subset of the full set of
	i-BGP peers; the efficiency of constrained broadcast can be improved
	by techniques such as described in [ORF] and [RTCONST].
	There are five classes of information that need to be distributed for		There are five classes of information that need to be distributed for
	RFC 2547 style VPNs:		RFC 2547 style VPNs:
	(a). Membership (auto-discovery)		(a). Membership (auto-discovery)
	(b). Prefixes		(b). Prefixes
	(c). Labels		(c). Labels
	(d). BGP nexthop, and		(d). BGP nexthop, and
	(e). Path selection attributes		(e). Path selection attributes
	The first of these, membership or auto-discovery, must be sent to all		The first of these, membership or auto-discovery, must be sent to all
	peers, as a BGP speaker does not know a priori which of its peers are		peers, as a BGP speaker does not know a priori which of its peers are
	members of a given VPN. Membership of a given VPN is recognized by		members of a given VPN. Membership of a given VPN is recognized by
	the use of certain extended communities called Route Targets. BGP is		the use of extended communities called Route Targets. BGP is well-
	clearly eminently well-suited for this mode of distribution.		suited for this mode of distribution.
	The next three of these constitute the reachability information.		The next three of these constitute the reachability information.
	They say what part of a given VPN (b) is reachable, and how it is to		They say what part of a given VPN (b) is reachable, and how it is to
	be reached (c and d). The final piece of information is used for		be reached (c and d). The final piece of information is used for
	selection if there are multiple paths to a given prefix of a VPN, as		selection if there are multiple paths to a given prefix of a VPN, as
	in the case of multi-homing. All of these pieces of information need		in the case of multi-homing. All of these pieces of information need
	only be distributed to members of the VPN, i.e., they require a		only be distributed to members of the VPN, i.e., they require a
	constrained broadcast mechanism. BGP is reasonably well-suited for		constrained broadcast mechanism. BGP is reasonably well-suited for
	this mode of distribution using import and export NLRI filtering.		this mode of distribution using import and export NLRI filtering.
	The addition of the mechanism in [RTCONST] makes BGP even better		The addition of the mechanism in [RTCONST] makes BGP even better
	suited to this.		suited to this.
	The encoding of this information as defined in [RFC2547BIS] puts all		The encoding of this information as defined in [RFC2547BIS] puts all
	of this information in a single NLRI. This seems to imply that a		of this information in a single NLRI. This seems to imply that a
	broadcast mechanism has to be used for the distribution of RFC 2547		broadcast mechanism has to be used for the distribution of RFC 2547
	VPN information. However, the combination of [RTCONST] and [RFC2918]		VPN information. However, the combination of [RTCONST] and [RFC2918]
	allow BGP to distribute this information correctly yet efficiently.		allow BGP to distribute this information correctly yet efficiently.
	Finally, it is useful to observe that standard BGP path selection		In summary, there seems to be little argument that the RFC 2547
	mechanisms (local pref, MED, AS path length, etc.) can be applied to		application is a routing application. This is because the information
	the information in (e).		that gets sent via BGP in RFC 2547 is generally considered to be
			"routing information". That is, the protocol distributes address
			prefixes, along with their next hops (and of course, some additional
			attributes). Finally (and perhaps most importantly), there seems to
			be little argument that the information distributed by the RFC 2547
			application is standard routing information.
	The conclusion is that BGP is quite well-suited to this application,		8.1.1. RFC 2547 and Label Distribution
	and, with the addition of mechanisms such as [RTCONST] and [RFC2918],
	the fit is even closer.		One issue that is frequently raised with respect to whether or not
			the RFC 2547 VPN application is a routing application surrounds the
			fact that, in the 2547 application, BGP distributes MPLS labels along
			with the routes. The contention then, is that the RFC 2547
			application represents more than just a routing application. However,
			in this case the MPLS label is just a shorthand way of representing
			one or more address prefixes. That is, the assertion is that in this
			case, the label represents "standard routing information".
	8.2. VPWS		8.2. VPWS
	A VPN based on a Virtual Private Wire Service [VPWS] connects a		The question of whether VPWS is a "good fit" for the BGP transport
	number of sites by virtual wires (or pseudo-wires). The information		infrastructure is the source of much discussion (and controversy). In
	needed to create such a VPN comprises:		this section, we will review both positions and their supporting
			arguments as a series of assertions and counter-assertions (we will
			use this format throughout the rest of this section).
	(a). Membership (auto-discovery)		The key debate with respect to VPWS centers around what set of
	(b). VPN site identification		services are being defined, and how they are to be signaled. One way
	(c). Labels		to analyze the VPWS application, then is in terms of two of its more
	(d). BGP nexthop		contentious functionalities, namely:
	(e). Path selection attributes, and
	(f). Per-wire information
	The analysis of the first five items is exactly as for RFC 2547 VPNs,		(a). Auto-discovery
	with the slight change that the definition of a 'part of a VPN' is no
	longer an IP prefix, but is a VPN site identifier, which can be
	viewed as the VPWS prefix. The distribution requirements and the fit
	with BGP distribution mechanisms is identical to RFC 2547.
	The one major change is the potential for 'per-wire' attributes, such		Auto-discovery refers to discovery of the set of nodes
	as bandwidth for a given site-to-site connection. This information		that belong in a common L2VPN, and
	should be distributed on a point-to-point basis. BGP mechanisms are
	not efficient for point-to-point distribution. However, it is an
	open question whether such 'per-wire' attributes really need to be
	exchanged, as evidenced by the fact that LDP signaling for pseudo-
	wires [MARTINI] has not defined any such attributes. If per-wire
	information is indeed not necessary, BGP distribution mechanisms are
	as well-suited for VPWS VPNs as for RFC 2547 VPNs.
	Note that existing BGP path selection mechanisms can be used as is		(b). Signaling
	for VPWS, and can prove useful for multi-homed sites.
	8.3. VPLS		Signaling refers to the setup and maintenance of the
			point-to-point pseudo-wires that carry the traffic of
			the L2VPN.
	A VPLS connects a number of sites by an emulated LAN segment. The		The next sections examine the various assertions and counter-
	information needed to create a VPLS consists of:		assertions around auto-discovery and signaling for VPLS.
	(a). Membership (auto-discovery)		8.2.1. Assertion #1
	(b). VPLS site identification
	(c). Labels
	(d). BGP nexthop, and
	(e). Path selection attributes
	The notion of 'VPLS site identification' is analogous to a VPN site		Assertion #1 states VPWS is not a routing application. Those
	identifier for VPWS. The analysis of the distribution needs of these		supporting this assertion argue that in the case of VPWS, we are not
	five items is exactly as for RFC 2547 VPNs, and the conclusion is		distributing address prefixes, and (importantly) unlike the case of
	that BGP is reasonably well-suited for this application, and with the		RFC 2547 style VPNs, the BGP decision process is not used (or at
	addition of [RTCONST] and [REFRESH], the fit is even better.		least it is not used in the same way). Further, proponents argue that
			what we are distributing is state information that corresponds to
			point-to-point entities, i.e., pseudo-wires, and thus argues that
			that the VPWS application is completely different.
	Note that existing BGP path selection mechanisms can be used as is		8.2.2. Counter-Assertion #1
	for VPLS, and can prove useful for multi-homed sites.
			Counter-Assertion #1 states that VPWS is a routing application. More
			specifically, this position is outlined in [VPLS] (section 3.4),
			namely:
			"It is often desired to multi-home a VPLS site, i.e., to connect
			it to multiple PEs, perhaps even in different ASes. In such a
			case, the PEs connected to the same site can either be
			configured with the same VE ID or with different VE IDs. In the
			latter case, it is mandatory to run STP on the CE device, and
			possibly on the PEs, to construct a loop-free VPLS topology.
			In the case where the PEs connected to the same site are
			assigned the same VE ID, a loop-free topology is constructed by
			routing mechanisms, in particular, by BGP path selection. When a
			BGP speaker receives two equivalent NLRIs (see below for the
			definition), it applies standard path selection criteria such as
			Local Preference and AS Path Length to determine which NLRI to
			choose; it MUST pick only one.
			If the chosen NLRI is subsequently withdrawn, the BGP speaker
			applies path selection to the remaining equivalent VPLS NLRIs to
			pick another; if none remain, the forwarding information
			associated with that NLRI is removed."
			8.2.3. Assertion #2
			Assertion #2 states that auto-discovery for VPWS requires some form
			of constrained broadcast. There doesn't seem to be much controversy
			that auto-discovery does require some sort of constrained broadcast
			mechanism (which we don't want to be limited to a single AS), and we
			may want to be able to optimize it by using a RP (rendezvous point)
			like mechanism. BGP route reflectors (RR) provide a convenient and
			ubiquitously deployed candidate RP. In this case (RR as RP), the fit
			is good since auto-discovery, like routing, requires an n-party
			protocol where each party has no a priori knowledge of the existence
			or identity of the other n-1 parties.
			8.2.4. Counter-Assertion #2
			There is no real counter-position to Assertion #2, as it simply
			states that VPWS auto-discovery requires some form of constrained
			broadcast (about which there is some controversy; see Assertion #2a
			below).
			8.2.4.1. Assertion #2a
			Assertion #2a states that auto-discovery is not needed for VPWS.
			Further, the Assertion #2a states that there is not a validated need
			for VPWS auto-discovery, since auto-discovery is useful only when
			creating full mesh layer 2 topologies, which are undesirable due to
			their (well-understood) poor scaling properties; hence auto-discovery
			for VPWS is not useful.
			8.2.4.2. Counter-Assertion #2a
			<what is the counter-assertion here? auto-discovery is useful for
			partial mesh? cite?>
			In summary, with the exception of Assertion #2a, the major
			controversy surrounding VPWS is in signaling piece of the
			application. The "VPWS is not a routing application" camp argues that
			the VPWS signaling requirements do not fit the BGP distribution
			infrastructure, while the "VPWS is a routing application" camp
			believes that BGP is a good fit. The next sections examine these
			assertions.
			8.2.5. Assertion #3
			Assertion #3 states that VPWS applications are not a good fit for
			BGP. This argument is based on the assertion that BGP is poorly
			suited to the VPWS signaling requirements because pseudo-wires are
			inherently point-to-point (see, for example [L2VPNSIG]). Further, the
			assertion is that VPWS signaling is qualitatively different than in
			routing or auto-discovery, in which each piece of information must be
			distributed to the n participants. The conclusion here is that BGP's
			distribution mechanisms are a poor match for VPWS signaling. Another
			way to think about this is that BGP generally works from a single
			database, and then applies some filtering on a per-connection basis;
			this only makes sense if most of the information is going to go to a
			lot of places.
			For example, suppose that a RR is used for VPWS signaling, and there
			is the need to set up n pseudo-wires. In this case, instead of
			sending n setup messages, one sends one large "meta-setup" message
			with all the info that would have been in the n setup messages. That
			is, let
			n = number of pseudo-wires
			l = the size of the per-wire label information
			k = the size of the per-wire information
			In this case, the meta-setup message will be of size O((l + k) * n).
			After receiving the setup message, the RR then must send the n
			messages that could have been sent by the endpoint (note that this is
			almost true; the endpoint would have to send n messages of size (l +
			k), but the RR will have to send n copies of the larger setup
			message).
			8.2.6. Counter-Assertion #3
			Counter-Assertion #3 states that the VPWS application is a good fit
			for BGP (see, for example [L2VPNT]). In particular, this camp
			suggests that a RR really only needs to distribute the label-range
			[LABELRANGE], so the setup message isn't really n times as large, but
			rather is analyzed as follows:
			Let n = number of pseudo-wires
			m = the size of the label-range data
			k = the size of the per-wire information
			Then the messages will be of size O(m + (k * n)), and most
			importantly for the label-range argument:
			O(m + (k * n)) < O((l + k) * n)
			That is, the label-range concept reduces the size of the
			messages that need to be sent to and by the RR.
			However, some will argue that the label-range concept is efficient if
			and only if:
			(a). A large enough label range is preallocated to accommodate
			all the systems you might ever want to add to the
			VPLS/VPWS (assuming that service interruption is not
			acceptable), and
			(b). There is no per-wire information other than labels that
			needs to distributed
			In these cases, the label range approach can reduce the size of the
			setup messages as analyzed above. However, the counter argument is
			that any such reduction will become a second-order effect as soon as
			some other piece of per-wire status or configuration (e.g., MTU)
			information must be distributed. In addition, the idea of pre-
			allocating a large enough label range to accommodate future
			expansion, while saving bits in the setup messages, has other costs
			which may be large. In particular:
			(a). Until the future expansion takes place (if it ever does),
			one may be wasting quite a lot of labels (noting that
			that each label you distribute requires you to allocate a
			piece of high-speed memory in your forwarding engine;
			putting some of it aside for possible later use seems
			very costly. Each one you put aside is, e.g., one less
			RFC2547 route you can support).
			However, if you don't preallocate enough contiguous label
			space for future expansion, then if the expansion occurs
			you must start adding additional labels or label ranges,
			and your setup messages start getting longer anyway (in
			theory, you could just carve a new set of label ranges,
			instead of adding new ones; counter-position: if you did
			that, you'd have to bring down your whole VPWS (and
			possibly VPLS) every time you add a new endpoint).
			(b). Fragmentation of the label space, which can result from
			this preallocation, has real impact on label switching
			implementations (as the MPLS architecture explicitly
			leaves it to the implementation to develop its own label
			assignment strategies). So if, for example, a hardware
			designer thinks s/he can improve performance by using,
			say, prime numbered labels first, s/he should have the
			ability to design her/his system in this way. If an
			application is going to come along and demand that labels
			be assigned in contiguous groups, implementations which
			are perfectly conformant to the architecture may not be
			able to support that application.
			(c). For diagnosis of network problems, the label-range
			approach may have the additional issue that the operator
			may not know (a priori) which label(s) were assigned to
			which endpoint(s).
			(d). Finally, one may argue that label-range allocation is
			sub-optimal for non-full mesh topologies, since all peers
			of the VPN must hear about the a label-range withdraw, and
			(in a non-full mesh topology), not all peers need to know
			about it.
			In any event, one may argue that the scaling benefits of using a RR
			in routing is that the RR pre-digests all the received info; it runs
			the (BGP) decision process, and only forwards the results of the
			decision process, rather than forwarding all the raw data. In the
			case of VPWS (and possibly VPLS), the argument is that this advantage
			is absent (i.e., we don't run BGP path selection), and as a result,
			the RR doesn't help with scaling in the same way it does with
			routing. Of course, the counter position is that some form of BGP
			path selection is used; see discussion above). Finally, one may argue
			that using the RR will introduce some latency into the label withdraw
			procedure.
			8.3. VPWS and Per-Wire Attributes
			While several per-wire attributes have been defined (see [L2TPV3],
			for example), the need for per-wire attributes for VPWS remains
			controversial. The following sections examine those controversies.
			8.3.1. Assertion #4
			Assertion #4 is that VPWS requires various per-wire parameters. These
			may include (but are not limited to) MTU, whether to use sequencing
			capabilities, bandwidth capabilities, and QoS. In addition, during
			the lifetime of a pseudo-wire, there are per-wire status indications
			that may need to be passed to the other endpoint.
			8.3.2. Counter-Assertion #4:
			Counter-Assertion #4 states that it has not been demonstrated that
			VPWS needs per-wire attributes as few (per-wire attributes) have as
			yet been defined (see, e.g., [MARTINI]).
			8.3.3. Assertion #5
			Assertion #5 states that passing per-wire attributes through an RR
			will likely be inefficient. The argument here is that in the event
			that per-wire attributes are required, passing these (per-wire)
			attributes through a RR will be sub-optimal as the RR will forward
			the status to all the VPWS members, not just to the one endpoint that
			is interested in it. For attributes like sequence numbers, it may
			even more difficult as one has to make sure the sequence numbers
			resynchronize properly when the pseudo-wire flaps. This seems
			somewhat difficult to achieve through a BGP RR.
			8.3.4. Counter-Assertion #5
			The counter assertion here is that, since few (or no) per-wire
			attributes have been defined (counter-assertion #4), the fact that it
			is inefficient to use a RR for distribution is irrelevant.
			8.3.5. Assertion #6
			Assertion #6 states that, while still an open issue, pseudo-wire
			congestion control may require regular point-to-point control message
			exchanges, something which BGP would seem ill-equipped to handle.
			8.3.6. Counter-Assertion #6
			In this case, the counter assertion is that since few (or no) per-
			wire attributes have been defined (see counter-assertion #4), and
			further, since congestion control for pseudo-wires is still an open
			issue, arguing fit is premature.
			8.3.7. Assertion #7:
			Assertion #7 states that the primary motivation for VPWS is to
			deliver existing service models (i.e., Frame Relay and ATM) over a
			packet infrastructure (this is as opposed to some new service). In
			this case, common deployments involve partial mesh topologies (more
			specifically multiple hub and spoke connections, with some hub to hub
			connectivity that makes sense for the enterprise traffic profile). In
			addition, some of the connections in such deployments require per-
			wire characteristics (e.g., guaranteed throughput for voice, etc).
			In other words, the argument here is that a VPWS service designed to
			support so-called legacy services (Frame Relay and ATM) will require
			point-to-point signaling due to existing topologies and the need for
			per-wire attributes. Further, for new VPWS services that require
			full-mesh auto-provisioning, the "Colored Pools PW Provisioning
			Model" [L2VPN] suggests a method to support such provisioning while
			retaining the point-to-point signaling required to support per-wire
			attributes.
			8.3.8. Counter-Assertion #7:
			<what is the counter-assertion here?>
			8.4. VPLS
			A VPLS service connects a number of sites by an emulated LAN segment.
			In the next sections, we examine whether VPLS maybe be considered to
			be a routing application, and hence whether BGP is a good fit for its
			distribution requirements.
			8.4.1. Assertion #8
			Assertion #8 states that VPLS is a routing application, since the
			notion of "VPLS site identification" is analogous to a VPN site
			identifier for VPWS (which this camp also views as a routing
			application). As a result, the analysis of the distribution needs of
			these five items is exactly as for RFC 2547 VPNs, and the conclusion
			is that BGP is reasonably well-suited for this application, and with
			the addition of [RTCONST] and [REFRESH], the fit is even better.
			Finally, note that existing BGP path selection mechanisms can be used
			as is for VPLS, and can prove useful for multi-homed sites.
			8.4.2. Counter-Assertion #8
			Counter-Assertion #8 states that VPLS is not a routing application.
			In particular, the contention here is that while the VPLS NLRI are
			used to identify that a particular PE belongs to a particular VPLS
			instance (as described in Assertion #8),the path which data traffic
			follows will depend on the route to that PE, and that route is
			determined by the ordinary IP routing. As a result, it is not
			relevant which neighbor a VPLS NLRI was received from, and hence is
			not routing.
			8.4.3. Assertion #9
			Assertion #9 is that constrained or true broadcast is not valuable
			for VPLS, since the same label can not be used by all peers. In
			particular, the same label can not be used by all peers since MAC
			address learning is performed in the data plane.
			8.4.4. Counter-Assertion #9
			<what is the counter-assertion here? label ranges?>
	9. Operational Implications		9. Operational Implications
	10. Other Models		In this section we examine the operational implications of the
			various choices in the design spaces described in this document.
	11. Conclusions and Recommendations		9.1. OAM Functionality
	12. Intellectual Property		A service provider (SP) may want to know exactly where a particular
			pseudo-wire leaves its domain, and in addition may want to keep
			various counts and bits of status at that point. Further, the SP may
			want to be able to do data path testing to that point. That is, a SP
			may want point-to-point pseudo-wire state to be maintained at its
			border routers.
			9.1.1. Assertion #10:
			Assertion #10 states that it may be difficult for service providers
			to maintain point-to-point pseudo-wire state at their border routers
			with the proposed BGP signaling mechanisms. This is because those
			mechanisms provide no way to ensure that a pseudo-wire data path will
			leave the network at a node which has state information for that
			pseudo-wire.
			9.1.2. Counter-Assertion #10:
			<counter assertion?>
			9.2. Full-Mesh Issues
			10. Conclusions and Recommendations
			11. Intellectual Property
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	intellectual property or other rights that might be claimed to		intellectual property or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		this document or the extent to which any license under such rights
	might or might not be available; neither does it represent that it		might or might not be available; neither does it represent that it
	has made any effort to identify any such rights. Information on the		has made any effort to identify any such rights. Information on the
	IETF's procedures with respect to rights in standards-track and		IETF's procedures with respect to rights in standards-track and
	standards-related documentation can be found in BCP-11 [RFC2028].		standards-related documentation can be found in BCP-11 [RFC2028].
	Copies of claims of rights made available for publication and any		Copies of claims of rights made available for publication and any
	skipping to change at page 22, line 33		skipping to change at page 31, line 35
	attempt made to obtain a general license or permission for the use of		attempt made to obtain a general license or permission for the use of
	such proprietary rights by implementors or users of this		such proprietary rights by implementors or users of this
	specification can be obtained from the IETF Secretariat.		specification can be obtained from the IETF Secretariat.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights which may cover technology that may be required to practice		rights which may cover technology that may be required to practice
	this standard. Please address the information to the IETF Executive		this standard. Please address the information to the IETF Executive
	Director.		Director.
	13. Design Team		12. Design Team
	The design team that produced this document consisted of Daniel		The design team that produced this document consisted of Daniel
	Awduche (awduche@awduche.com), Ron Bonica (Ronald.P.Bonica@mci.com),		Awduche (awduche@awduche.com), Ron Bonica (Ronald.P.Bonica@mci.com),
	Hank Kilmer (hank@rem.com), Kireeti Kompella (kireeti@juniper.net),		Hank Kilmer (hank@rem.com), Kireeti Kompella (kireeti@juniper.net),
	Chris Lewis (chrlewis@cisco.com), Danny McPherson (danny@tcb.net),		Chris Lewis (chrlewis@cisco.com), Danny McPherson (danny@tcb.net),
	David Meyer (dmm@1-4-5.net) and Peter Whiting		David Meyer (dmm@1-4-5.net) and Peter Whiting
	(pwhiting@vericenter.com).		(pwhiting@vericenter.com).
	14. Acknowledgments		13. Acknowledgments
	David Ball, Peter Gutierrez, Susan Harris, Pedro Marques, Eric Rosen,		David Ball, Peter Gutierrez, Susan Harris, Pedro Marques, Eric Rosen,
	Pekka Savola, and Mark Townsley have all made many insightful		Pekka Savola, and Mark Townsley have all made many insightful
	comments on earlier versions of this document.		comments on earlier versions of this document.
	15. Security Considerations		14. Security Considerations
	This document specifies neither a protocol nor an operational		This document specifies neither a protocol nor an operational
	practice, and as such, it creates no new security considerations.		practice, and as such, it creates no new security considerations.
	16. IANA Considerations		15. IANA Considerations
	This document creates a no new requirements on IANA namespaces		This document creates a no new requirements on IANA namespaces
	[RFC2434].		[RFC2434].
	17. References		16. References
	17.1. Normative References		16.1. Normative References
	[AFI] http://www.iana.org/assignments/address-family-numbers		[AFI] http://www.iana.org/assignments/address-family-numbers
	[BGP] Rekhter, Y, T.Li, and S. Hares, "A Border Gateway		[BGP] Rekhter, Y, T.Li, and S. Hares, "A Border Gateway
	Protocol 4 (BGP-4)", draft-ietf-idr-bgp4-23.txt.		Protocol 4 (BGP-4)", draft-ietf-idr-bgp4-23.txt.
	Work in progress.		Work in progress.
	[BGPVPN] Ould-Brahim, H., E. Rosen, and Y. Rekhter, "Using		[BGPVPN] Ould-Brahim, H., E. Rosen, and Y. Rekhter, "Using
	BGP as an Auto-Discovery Mechanism for		BGP as an Auto-Discovery Mechanism for
	Provider-provisioned VPNs",		Provider-provisioned VPNs",
	skipping to change at page 25, line 35		skipping to change at page 34, line 35
	[EXTCOMM] Sangali, S., D. Tappan, and Y. Rekhter, "BGP		[EXTCOMM] Sangali, S., D. Tappan, and Y. Rekhter, "BGP
	Extended Communities Attribute",		Extended Communities Attribute",
	draft-ietf-idr-bgp-ext-communities-06.txt. Work		draft-ietf-idr-bgp-ext-communities-06.txt. Work
	in progress.		in progress.
	[FLOW] Marques, P, et. al., "Dissemination of flow		[FLOW] Marques, P, et. al., "Dissemination of flow
	specification rules",		specification rules",
	draft-marques-idr-flow-spec-00.txt. Work in		draft-marques-idr-flow-spec-00.txt. Work in
	progress.		progress.
			[LABELRANGE] What is the cite here?
			[L2VPN] Andersson, L. and E. Rosen, "L2VPN Framework",
			draft-ietf-l2vpn-l2-framework-03.txt. Work in
			Progress.
			[L2VPNSIG] Rosen, E. and V. Rodoaca, "Provisioning Models
			and Endpoint Identifiers in L2VPN Signaling",
			draft-ietf-l2vpn-signaling-00.txt. Work in
			Progress.
			[L2VPNT] Kompella, K. (Editor), "Layer 2 VPNs Over
			Tunnels", draft-kompella-l2vpn-l2vpn-00.txt.
			Work in Progress.
	[L2TPv3] Lau, J., M. Townsley and I. Goyret (Editors),		[L2TPv3] Lau, J., M. Townsley and I. Goyret (Editors),
	"Layer Two Tunneling Protocol (Version		"Layer Two Tunneling Protocol (Version
	3)", draft-ietf-l2tpext-l2tp-base-11.txt. Work in		3)", draft-ietf-l2tpext-l2tp-base-11.txt. Work in
	progress.		Progress.
	[MARTINI] Martini, L., E.Rosen, and T. Smith, "Pseudowire		[MARTINI] Martini, L., E.Rosen, and T. Smith, "Pseudowire
	Setup and Maintenance using LDP",		Setup and Maintenance using LDP",
	draft-ietf-pwe3-control-protocol-05.txt. Work in		draft-ietf-pwe3-control-protocol-05.txt. Work in
	progress.		progress.
	[MULLER1999] Muller, R. et. al., "Control System Reliability		[MULLER1999] Muller, R. et. al., "Control System Reliability
	Requires Careful Software Installation		Requires Careful Software Installation
	Procedures", International Conference on		Procedures", International Conference on
	Accelerator and Largeand Large Experimental		Accelerator and Largeand Large Experimental
	skipping to change at page 27, line 24		skipping to change at page 36, line 42
	[RFC3036] Anderson, L., et. al., "LDP Specification", RFC		[RFC3036] Anderson, L., et. al., "LDP Specification", RFC
	3036, January 2001.		3036, January 2001.
	[RFC3439] Bush, R. and D. Meyer, "Some Internet		[RFC3439] Bush, R. and D. Meyer, "Some Internet
	Architectural Guidelines and Philosophy", RFC		Architectural Guidelines and Philosophy", RFC
	3439, December, 2002.		3439, December, 2002.
	[SAFI] http://www.iana.org/assignments/safi-namespace		[SAFI] http://www.iana.org/assignments/safi-namespace
	[VLPS] Kompella, K., et. al. "Virtual Private LAN		[VPLS] Kompella, K., et. al. "Virtual Private LAN
	Service", draft-ietf-l2vpn-vpls-bgp-02.txt.		Service", draft-ietf-l2vpn-vpls-bgp-01.txt.
	Work in progress.		Work in progress.
	[VPWS] Kompella, K. et.al. "Layer 2 VPNs Over Tunnels",		[VPWS] Kompella, K. et.al. "Layer 2 VPNs Over Tunnels",
	draft-kompella-ppvpn-l2vpn-04.txt. Work in		draft-kompella-ppvpn-l2vpn-04.txt. Work in
	progress.		progress.
	17.2. Informative References		16.2. Informative References
	[IETFOL] https://www1.ietf.org/mailman/listinfo/routing-discussion		[IETFOL] https://www1.ietf.org/mailman/listinfo/routing-discussion
	[RFC2119] Bradner, S., "Key words for use in RFCs to		[RFC2119] Bradner, S., "Key words for use in RFCs to
	Indicate Requirement Levels", RFC 2119, March,		Indicate Requirement Levels", RFC 2119, March,
	1997.		1997.
	[RFC2026] Bradner, S., "The Internet Standards Process --		[RFC2026] Bradner, S., "The Internet Standards Process --
	Revision 3", RFC 2026/BCP 9, October, 1996.		Revision 3", RFC 2026/BCP 9, October, 1996.
	skipping to change at page 29, line 5		skipping to change at page 38, line 5
	[RFC2434] Narten, T., and H. Alvestrand, "Guidelines for		[RFC2434] Narten, T., and H. Alvestrand, "Guidelines for
	Writing an IANA Considerations Section in RFCs",		Writing an IANA Considerations Section in RFCs",
	RFC 2434/BCP 26, October 1998.		RFC 2434/BCP 26, October 1998.
	[RVBIB] http://www.routeviews.org/papers		[RVBIB] http://www.routeviews.org/papers
	[WILLINGER2002] Willinger, W., and J. Doyle, "Robustness and the		[WILLINGER2002] Willinger, W., and J. Doyle, "Robustness and the
	Internet: Design and evolution", 2002.		Internet: Design and evolution", 2002.
	18. Editor's Address		17. Editor's Address
	David Meyer		David Meyer
	Email: dmm@1-4-5.net		Email: dmm@1-4-5.net
	19. Full Copyright Statement		18. Full Copyright Statement
	Copyright (C) The Internet Society (2004). All Rights Reserved.		Copyright (C) The Internet Society (2004). All Rights Reserved.
	This document and translations of it may be copied and furnished to		This document and translations of it may be copied and furnished to
	others, and derivative works that comment on or otherwise explain it		others, and derivative works that comment on or otherwise explain it
	or assist in its implementation may be prepared, copied, published		or assist in its implementation may be prepared, copied, published
	and distributed, in whole or in part, without restriction of any		and distributed, in whole or in part, without restriction of any
	kind, provided that the above copyright notice and this paragraph are		kind, provided that the above copyright notice and this paragraph are
	included on all such copies and derivative works. However, this		included on all such copies and derivative works. However, this
	document itself may not be modified in any way, such as by removing		document itself may not be modified in any way, such as by removing
	skipping to change at line 1033		skipping to change at line 1431
	The limited permissions granted above are perpetual and will not be		The limited permissions granted above are perpetual and will not be
	revoked by the Internet Society or its successors or assigns.		revoked by the Internet Society or its successors or assigns.
	This document and the information contained herein is provided on an		This document and the information contained herein is provided on an
	"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING		"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
	TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING		TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
	BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION		BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
	HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF		HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
	MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Meyer, et. al.
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/