< draft-nalawade-kapoor-tunnel-safi-04.txt		draft-nalawade-kapoor-tunnel-safi-05.txt >
	Network Working Group Gargi Nalawade		Network Working Group Gargi Nalawade
	Internet Draft Ruchi Kapoor		Internet Draft Ruchi Kapoor
	Expires: April 2006 Dan Tappan		Expires: December 2006 Dan Tappan
	Scott Wainner		Scott Wainner
			Simon Barber
			Chris Metz
	Cisco Systems		Cisco Systems
	Tunnel SAFI		BGP Tunnel SAFI
	draft-nalawade-kapoor-tunnel-safi-04.txt		draft-nalawade-kapoor-tunnel-safi-05.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	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
	skipping to change at page 1, line 39 ¶		skipping to change at page 1, line 41 ¶
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt		http://www.ietf.org/ietf/1id-abstracts.txt
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	Abstract		Abstract
	The architecture of an MPLS VPN solution relies on the establishment		There is a growing requirement for network operators to support
	of two layers of reachability information. The first is the		multi-address familiy routing and forwarding services across their
	association of a prefix, interface, or route table to a VPNv4 label		backbone networks. In general this is accomplished by constructing a
	that is used on the egress PE to delineate a Virtual Route Forwarding		mesh of tunnels between the backbbone provider edge routers and then
	table. The second is the association of the next-hop to reach the		advertising reachability to prefixes through specific tunnels. This
	egress PE. By default, the MPLS VPN establishes an LSP tunnel from		document defines a new subsequence address family identifier
	the ingress PE to the egress PE. A requirement exists to establish		associated with a tunnel end-point information. This enables a single
	an IP tunnel between the ingress and egress PE in lieu of an LSP.		egress provider edge router to use the border gateway protocol as a
	The egress PE's tunnel capability needs to be distributed to all the		scalable and efficient means to distribute its tunnel end-point
	potential ingress PE's as well as the attributes of the tunnel. The		information to many ingress provider edge routers. The result is that
	tunnel end-point discovery may occur within and across Autonomous		the mesh of tunnels is in place and packets can be forwarded through
	Systems. BGP is the logical protocol of choice that is widely		these tunnels based on advertised reachability.
	deployed for MPLS VPN solutions and can carry this information in a
	synchronized manner. This document defines how BGP speakers can
	convey Tunnel end-point reachability information.
	1. Introduction		1. Introduction
			There is a growing requirement for network operators to support
			multi-address familiy routing and forwarding services across their
			backbone networks. In the context of network-based IP VPN, this is
			accomplished today using the mechanisms defined in RFC4364. More
			recently the softwires effort has emerged as a generalized, network-
			based routing and forwarding solution supporting connectivity of
			address familiy islands (e.g. IPv4, IPv6, VPNv4, VPNv6) across a
			uniform IPv4 or IPv6 backbone network [SW-MESH-FMWK]. In both cases
			the establishment of tunnels (IP or MPLS) between ingress and egress
			provider edge (PE) routers must be in place before packets of one
			address famility can be tunneled across the backbone network.
	Two end-points of a tunnel need to agree upon the end-point		Two end-points of a tunnel need to agree upon the end-point
	information and its binding to a network address at the remote point.		information and its binding to a network address at the remote point.
	Normally, this information can be manually shared and statically		Normally, this information can be manually shared and statically
	configured when the number of tunnels to manage is relatively small.		configured when the number of tunnels to manage is relatively small.
	In the case of a network such as an MPLS VPN where there is a need		In the case of a network such as an MPLS VPN where there is a need
	for a tunnel between every ingress and egress PE, the number of		for a tunnel between every ingress and egress PE, the number of
	tunnel end-points that need to be exchanged and maintained grows		tunnel end-points that need to be exchanged and maintained grows
	dramatically as the network becomes large. The egress PE already		dramatically as the network becomes large. The egress PE already
	defines reachability information for the private routing information		defines reachability information for the private routing information
	as well as the NLRI of the PE itself. This information is		as well as the NLRI of the PE itself. This information is
	skipping to change at page 2, line 46 ¶		skipping to change at page 3, line 9 ¶
	PE and may or may not correlate with the capabilities of any other		PE and may or may not correlate with the capabilities of any other
	potential ingress PE. For this reason, the ingress PE may select the		potential ingress PE. For this reason, the ingress PE may select the
	most appropriate tunneling mechanism based on the compability of the		most appropriate tunneling mechanism based on the compability of the
	tunnel capabilities between the ingress and egress PE's and their		tunnel capabilities between the ingress and egress PE's and their
	preferences.		preferences.
	2. The Tunnel SAFI		2. The Tunnel SAFI
	This document defines a new BGP SAFI called the Tunnel SAFI. The		This document defines a new BGP SAFI called the Tunnel SAFI. The
	<AFI, SAFI> [IANA-AFI] [IANA-SAFI] value pair used to identify this		<AFI, SAFI> [IANA-AFI] [IANA-SAFI] value pair used to identify this
	SAFI are- AFI=1, SAFI=64, for the IPv4 Tunnel AFI; and AFI=2, SAFI=64		SAFI are: AFI=1, SAFI=64, for the IPv4 Tunnel address family; and
	for the IPv6 Tunnel AFI.		AFI=2, SAFI=64 for the IPv6 Tunnel address family.
	For BGP Speakers supporting [BGP-4], the tunnel end point address		For BGP Speakers supporting [BGP-4], the tunnel end point address
	will be carried as an NLRI in the MP_REACH attribute for the Tunnel		will be carried as an NLRI in the MP_REACH attribute for the Tunnel
	SAFI.		SAFI.
	The NLRI will be encoded as a 2-octet Identifier followed by the NLRI		The NLRI will be encoded as a 2-octet Identifier followed by the NLRI
	format as specified by the respective AFI. The Identifier will		format as specified by the respective AFI. The Identifier will
	identify the tunnel end point being advertised. This Identifier		identify the tunnel end point being advertised. This Identifier
	enables multiple tunnel end-points to share the same network address,		enables multiple tunnels to share the same network address, thus
	thus conserving the number of addresses needed to be configured by		conserving the number of addresses needed to be configured by the
	the operator on each of the Tunnel-endpoints.		operator on each of the Tunnel-endpoints. The network address
			contained in the Tunnel SAFI NLRI is the network address of the
			tunnel end point.
	3. BGP Attribute		The network address contained in the BGP Tunnel SAFI NLRI SHOULD be
			the same as the network address carried in the 'Network Address of
			Next Hop' field of the BGP Softwire Nexthop Attribute [BGP-SW-NEXT-
			HOP]. The BGP Softwire Nexthop Attribute will be carried separately
			in BGP advertisements, as described in [BGP-SW-NEXT-HOP].
	The BGP Tunnel Encapsulation Attribute [BGP-TUN] will be used to		3. BGP Encapsulation Attributes
	carry The Tunnel end-point information. The egress PE may support one
	or more tunnel methods. The egress PE MUST advertise all tunnel
	types for which it will support tunnel termination. The egress PE
	MAY advertise one or more tunnel types.
	If a BGP SPeaker supports the BGP Tunnel SAFI then it MUST understand		The BGP Tunnel SAFI will carry the tunnel end-point information
			inside a BGP encapsulation attribute. The encapsulation attribute
			used can be either the BGP Tunnel Encapsulation Attribute [BGP-TUN]
			or the BGP Softwire Mesh encapsulation attribute [BGP-SW-ENCAP]. The
			egress PE may support one or more tunnel methods. The egress PE MUST
			advertise all tunnel types for which it will support tunnel
			termination. The egress PE MAY advertise one or more tunnel types.
			If a BGP Speaker supports the BGP Tunnel SAFI then it MUST understand
	the Tunnel Encapsulation attribute [BGP-TUN]. A BGP update for the		the Tunnel Encapsulation attribute [BGP-TUN]. A BGP update for the
	Tunnel SAFI MUST never be sent without the BGP Tunnel Encapsulation		Tunnel SAFI MUST contain either the BGP Tunnel Encapsulation
	Attribute.		Attribute [BGP-TUN] or the BGP Softwire Mesh encapsulation attribute
			[BGP-SW-ENCAP]. A BGP update for the Tunnel SAFI MUST NOT contain
			both the BGP Tunnel Encapsulation Attribute [BGP-TUN] and the BGP
			Softwire Mesh encapsulation attribute [BGP-SW-ENCAP] in the same
			update message. If such an update message is received by a BGP
			speaker, the message should be ignored.
			The details of the contents of the BGP Tunnel Encapsulation Attribute
			[BGP-TUN] are described in the section below.
			3.1 Contents of BGP Tunnel Encapsulation Attrubite.
	As defined in [BGP-TUN], the first bit of the TYPE field in the BGP		As defined in [BGP-TUN], the first bit of the TYPE field in the BGP
	Tunnel Encapsulation Attribute is the 'transitive bit'. If the bit		Tunnel Encapsulation Attribute is the 'transitive bit'. If the bit
	value is 1, implies that this tunnel is transitive. If the bit value		value is 1, implies that this tunnel is transitive. If the bit value
	is 0, it implies this specific tunnel is not transitive.		is 0, it implies this specific tunnel is not transitive.
	The Value Field of the BGP Tunnel Encapsulation Attribute, MUST		The Value Field of the BGP Tunnel Encapsulation Attribute, MUST
	contain at least one of the following valid Type codes for this SAFI.		contain at least one of the following valid Type codes for this SAFI.
	It MAY contain one or more TLVs with these Type codes.		It MAY contain one or more TLVs with these Type codes.
	skipping to change at page 3, line 46 ¶		skipping to change at page 4, line 30 ¶
	Type 2: mGRE Tunnel information		Type 2: mGRE Tunnel information
	Type 3: IPSec Tunnel information		Type 3: IPSec Tunnel information
	Type 4: MPLS Tunnel information		Type 4: MPLS Tunnel information
	Type 5: L2TPv3 in IPSEC Tunnel information		Type 5: L2TPv3 in IPSEC Tunnel information
	Type 6: mGRE in IPSEC Tunnel information		Type 6: mGRE in IPSEC Tunnel information
	3.1. L2TPv3 Tunnel information TLV		3.1.1 L2TPv3 Tunnel information TLV
	The L2TPv3 Tunnel Information TLV has a type value of 1. The value		The L2TPv3 Tunnel Information TLV has a type value of 1. The value
	part of the L2TPv3 Tunnel Information Type contains the following :		part of the L2TPv3 Tunnel Information Type contains the following :
	- Preference (2 Octets)		- Preference (2 Octets)
	- Flags (1 Octet)		- Flags (1 Octet)
	- Cookie Length (1 Octet)		- Cookie Length (1 Octet)
	- Session ID (4 Octets)		- Session ID (4 Octets)
	- Cookie (Variable)		- Cookie (Variable)
	skipping to change at page 5, line 37 ¶		skipping to change at page 6, line 19 ¶
	the egress PE, the associated Cookie MAY be generated such that		the egress PE, the associated Cookie MAY be generated such that
	packets received by the egress PE from an ingress PE can be quickly		packets received by the egress PE from an ingress PE can be quickly
	validated for proper service context.		validated for proper service context.
	The default value of the Length Field for the L2TPv3 Tunnel		The default value of the Length Field for the L2TPv3 Tunnel
	information TLV is between 8 and 16 bytes, depending on the length of		information TLV is between 8 and 16 bytes, depending on the length of
	the Cookie field specified in Cookie length. If the length of the TLV		the Cookie field specified in Cookie length. If the length of the TLV
	is greater than that value, the subsequent portion of the Value field		is greater than that value, the subsequent portion of the Value field
	contains one or more sub-TLVs as defined in [BGP-TUN].		contains one or more sub-TLVs as defined in [BGP-TUN].
	3.2. mGRE Tunnel Information TLV		3.1.2 mGRE Tunnel Information TLV
	The mGRE Tunnel Information Type has a Type 2. The value part of the		The mGRE Tunnel Information Type has a Type 2. The value part of the
	mGRE Tunnel Information Type contains the following :		mGRE Tunnel Information Type contains the following :
	- Preference (2 Octets)		- Preference (2 Octets)
	- Flags (1 Octet)		- Flags (1 Octet)
	- mGRE Key (0 or 4 Octets)		- mGRE Key (0 or 4 Octets)
	The mGRE Tunnel Information TLV looks as follows :		The mGRE Tunnel Information TLV looks as follows :
	skipping to change at page 6, line 45 ¶		skipping to change at page 7, line 29 ¶
	PE to any potential ingress PE. In this case, the key value has		PE to any potential ingress PE. In this case, the key value has
	unidirectional relevance from all viable ingress PE's to the egress		unidirectional relevance from all viable ingress PE's to the egress
	PE. Alternatively, the key value may be statically configured such		PE. Alternatively, the key value may be statically configured such
	that all ingress and egress PE's use the same key value.		that all ingress and egress PE's use the same key value.
	If the Length field of the TLV contains a value greater than 3 Octets		If the Length field of the TLV contains a value greater than 3 Octets
	plus the value specified in the Key Length, the subsequent portion of		plus the value specified in the Key Length, the subsequent portion of
	the Value field contains one or more sub-TLVs as defined by [BGP-		the Value field contains one or more sub-TLVs as defined by [BGP-
	TUN].		TUN].
	3.3. IPSec Tunnel Information TLV		3.1.3 IPSec Tunnel Information TLV
	The IPSec Tunnel Information Type has a Type 3. The value part of		The IPSec Tunnel Information Type has a Type 3. The value part of
	the IPSec Tunnel Information Type contains the following :		the IPSec Tunnel Information Type contains the following :
	- Preference (2 Octets)		- Preference (2 Octets)
	- Flags (1 Octet)		- Flags (1 Octet)
	- IKE ID Type (1 Octets)		- IKE ID Type (1 Octets)
	- IKE ID Length (2 Octets)		- IKE ID Length (2 Octets)
	- IKE Identifier (Variable)		- IKE Identifier (Variable)
	skipping to change at page 8, line 10 ¶		skipping to change at page 8, line 38 ¶
	Identifier.		Identifier.
	IKE Identifier - A variable length field containing an IKE Identifier		IKE Identifier - A variable length field containing an IKE Identifier
	of the egress PE.		of the egress PE.
	If the Length field of the TLV contains a value greater than 11		If the Length field of the TLV contains a value greater than 11
	Octets plus the value specified in the Key Length, the subsequent		Octets plus the value specified in the Key Length, the subsequent
	portion of the Value field contains one or more sub-TLVs as defined		portion of the Value field contains one or more sub-TLVs as defined
	by [BGP-TUN].		by [BGP-TUN].
	3.4. MPLS TLV		3.1.4 MPLS TLV
	The MPLS TLV has a Type 4. The value part of the MPLS TLV contains		The MPLS TLV has a Type 4. The value part of the MPLS TLV contains
	the following :		the following :
	- Preference (2 Octets)		- Preference (2 Octets)
	- Flags (1 Octet)		- Flags (1 Octet)
	The MPLS Tunnel Information TLV looks as follows :		The MPLS Tunnel Information TLV looks as follows :
	0 1		0 1
	skipping to change at page 8, line 44 ¶		skipping to change at page 9, line 29 ¶
	Preference A 2 Octet field containing a Preference associated with		Preference A 2 Octet field containing a Preference associated with
	the TLV. The Preference value indicates a preferred ordering of		the TLV. The Preference value indicates a preferred ordering of
	tunneling encapsulations according to the sender. The recipient of		tunneling encapsulations according to the sender. The recipient of
	the information SHOULD take the sender's preference into account in		the information SHOULD take the sender's preference into account in
	selecting which encapsulation it will use. A higher value indicates a		selecting which encapsulation it will use. A higher value indicates a
	higher preference.		higher preference.
	Flags - A 1 Octet field containing flag-bits.		Flags - A 1 Octet field containing flag-bits.
	3.5. L2TPv3 in IPSEC TLV		3.1.5 L2TPv3 in IPSEC TLV
	When the value in the Type field is 5, the Value portion of the		When the value in the Type field is 5, the Value portion of the
	SAFI-Specific Attribute TLV will carry an IPSec TLV followed by an		SAFI-Specific Attribute TLV will carry an IPSec TLV followed by an
	L2TPv3 TLV.		L2TPv3 TLV.
	3.5. mGRE in IPSEC TLV		3.1.6 mGRE in IPSEC TLV
	When the value in the Type field is 6, the Value portion of the		When the value in the Type field is 6, the Value portion of the
	SAFI-Specific Attribute TLV will carry an IPSec TLV followed by an		SAFI-Specific Attribute TLV will carry an IPSec TLV followed by an
	mGRE TLV.		mGRE TLV.
	4. Capability Advertisement		4. Capability Advertisement
	A BGP speaker MAY participate in the distribution of the IPv4-Tunnel		A BGP speaker MAY participate in the distribution of the IPv4 Tunnel
	SAFI or IPv6-Tunnel SAFI information. A BGP speaker that wishes to		address family or IPv6 Tunnel address family information. A BGP
	exchange the IPv4-Tunnel SAFI or the IPv6 Tunnel SAFI, MUST use the		speaker that wishes to exchange the IPv4 Tunnel address family or the
	MP_EXT Capability Code as defined in [BGP-MP], to advertise the		IPv6 Tunnel address family, MUST use the MP_EXT Capability Code as
	corresponding (AFI, SAFI) pair.		defined in [BGP-MP], to advertise the corresponding (AFI, SAFI) pair.
	5. Operation		5. Operation
			A BGP Speaker that receives the Capability for the IPv4 Tunnel
	A BGP Speaker that receives the Capability for the IPv4-Tunnel SAFI		address family or the IPv6 Tunnel address family, MAY advertise the
	or the IPv6-Tunnel SAFI, MAY advertise the IPv4-Tunnel SAFI or IPv6-		IPv4 Tunnel address family or IPv6 Tunnel address family prefixes to
	Tunnel SAFI prefixes to that peer.		that peer.
	The BGP Tunnel Encapsulation attribute is defined only to be used in		The BGP Tunnel Encapsulation attribute is defined only to be used in
	UPDATE messages for the IPv4 tunnel SAFI or the IPv6 Tunnel SAFI. If		UPDATE messages for the IPv4 tunnel address family or the IPv6 Tunnel
	the BGP Tunnel Encapsulation Attribute is received in an UPDATE		address family. If the BGP Tunnel Encapsulation Attribute is received
	message for any other AFI/SAFI, it MUST be ignored.		in an UPDATE message for any other AFI/SAFI, it MUST be ignored.
	If a BGP Speaker receives an unrecognized Transitive Tunnel		If a BGP Speaker receives an unrecognized Transitive Tunnel
	Encapsulation TLV as part of the BGP Tunnel Encapsulation Attribute,		Encapsulation TLV as part of the BGP Tunnel Encapsulation Attribute,
	it MUST accept it and propagate it to other peers.		it MUST accept it and propagate it to other peers.
	6. Deployment Considerations		6. Deployment Considerations
	In order for the Tunnels to come up between two end-points, the BGP		In order for the Tunnels to come up between two end-points, the BGP
	Speakers advertising the Tunnel end-points using the IPv4/IPv6 Tunnel		Speakers advertising the Tunnel end-points using the IPv4/IPv6 Tunnel
	SAFI, MUST exchange at least one common encapsulation option.		SAFI, MUST exchange at least one common encapsulation option.
	skipping to change at page 11, line 18 ¶		skipping to change at page 12, line 4 ¶
	infrastructure to distribute tunnel endpoint information. The Tunnel		infrastructure to distribute tunnel endpoint information. The Tunnel
	SAFI UPDATE message is used to signal tunnel attribute and endpoint		SAFI UPDATE message is used to signal tunnel attribute and endpoint
	information amongst PEs. And thus tunnel endpoint discovery is		information amongst PEs. And thus tunnel endpoint discovery is
	accomplished using MP-BGP updates.		accomplished using MP-BGP updates.
	8. Security Considerations		8. Security Considerations
	This extension to BGP does not change the underlying security issues.		This extension to BGP does not change the underlying security issues.
	9. Acknowledgements		9. Acknowledgements
			The authors would like to thank Jim Guichard, Francois LeFaucher and
	We would like to thank Jim Guichard, Francois LeFaucher for their		David Ward for their contribution. We would like to thank Arjun
	contribution. We would like to thank Arjun Sreekantiah, Shyam Suri,		Sreekantiah, Shyam Suri, Chandrashekhar Appanna, John Scudder and
	Chandrashekhar Appanna, John Scudder and Mark Townsley for their		Mark Townsley for their comments and suggestions.
	comments and suggestions.
	10. References		10. References
	[IANA-AFI] http://www.iana.org/assignments/address-family-numbers		[IANA-AFI] http://www.iana.org/assignments/address-family-numbers
	[IANA-SAFI] http://www.iana.org/assignments/safi-namespace		[IANA-SAFI] http://www.iana.org/assignments/safi-namespace
	[BGP-4] Rekhter, Y. and T. Li (editors), "A Border Gateway Protocol		[BGP-4] Rekhter, Y. and T. Li (editors), "A Border Gateway Protocol
	4 (BGP-4)", Internet Draft draft-ietf-idr-bgp4-26.txt, April 2005.		4 (BGP-4)", Internet Draft draft-ietf-idr-bgp4-26.txt, April 2005.
	[BGP-CAP] Chandra, R., Scudder, J., "Capabilities Advertisement with		[BGP-CAP] Chandra, R., Scudder, J., "Capabilities Advertisement with
	BGP-4", draft-ietf-idr-rfc2842bis-02.txt, April 2002.		BGP-4", draft-ietf-idr-rfc2842bis-02.txt, April 2002.
	[BGP-TUN] Kapoor R., Nalawade G., "BGPv4 Tunnel Encapsulation		[BGP-TUN] Kapoor R., Nalawade G., "BGPv4 Tunnel Encapsulation
	Attribute", draft-nalawade-kapoor-idr-bgp-ssa-02.txt, work in		Attribute", draft-nalawade-kapoor-idr-bgp-ssa-03.txt, work in
	progress.		progress.
	[MULTI-BGP] Bates et al, "Multiprotocol Extensions for BGP-4", draft-		[MULTI-BGP] Bates et al, "Multiprotocol Extensions for BGP-4", draft-
	ietf-idr-rfc2858bis-02.txt, work in progress.		ietf-idr-rfc2858bis-02.txt, work in progress.
			[SW-MESH-FMWK] Metz, C. et al, "A Framework for Softwire Mesh
			Signaling, Routing and Encapsulation across IPv4 and IPv6 Backbone
			Networks", draft-wu-softwire-mesh-framework-00, June 2006.
			[BGP-SW-NEXT-HOP] Nalawade G. et al, "BGP Softwire Nexthop
			Attribute", draft-nalawade-sw-nhop-00.txt, June 2006.
			[BGP-SW-ENCAP] Nalawade G., Barber S., Ward D., Kapoor R., Metz C.,
			"BGPv4 Softwire Mesh Encapsulation Attribute", draft-softwire-mesh-
			encap-attribute-00.txt, June 2006.
	11. Authors' Addresses		11. Authors' Addresses
	Gargi Nalawade		Gargi Nalawade
	Cisco Systems, Inc		Cisco Systems, Inc
	170 West Tasman Drive		170 West Tasman Drive
	San Jose, CA 95134		San Jose, CA 95134
	mailto:gargi@cisco.com		mailto:gargi@cisco.com
	Ruchi Kapoor		Ruchi Kapoor
	Cisco Systems, Inc		Cisco Systems, Inc
	skipping to change at page 12, line 21 ¶		skipping to change at page 13, line 18 ¶
	170 West Tasman Drive		170 West Tasman Drive
	San Jose, CA 95134		San Jose, CA 95134
	mailto:tappan@cisco.com		mailto:tappan@cisco.com
	Scott Wainner		Scott Wainner
	Cisco Systems, Inc		Cisco Systems, Inc
	13600 Dulles Technology Drive		13600 Dulles Technology Drive
	Herndon, VA 20171		Herndon, VA 20171
	mailto:swainner@cisco.com		mailto:swainner@cisco.com
			Simon Barber
			Cisco Systems, Inc
			mailto:sbarber@cisco.com
			Chris Metz
			Cisco Systems, Inc
			170 West Tasman Drive
			San Jose, CA 95134
			mailto:chmetz@cisco.com
	12. Intellectual Property Statement		12. Intellectual Property Statement
	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 Rights or other rights that might be claimed to		Intellectual Property Rights 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; nor does it represent that it has		might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information		made any independent effort to identify any such rights. Information
	on the procedures with respect to rights in RFC documents can be		on the procedures with respect to rights in RFC documents can be
	found in BCP 78 and BCP 79.		found in BCP 78 and BCP 79.
	skipping to change at page 13, line 7 ¶		skipping to change at page 14, line 14 ¶
	Director.		Director.
	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 that may cover technology that may be required to implement		rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at ietf-		this standard. Please address the information to the IETF at ietf-
	ipr@ietf.org.		ipr@ietf.org.
	13. Full Copyright Statement		13. Full Copyright Statement
	Copyright (C) The Internet Society (2005). This document is subject		Copyright (C) The Internet Society (2006). All Rights Reserved.
	to the rights, licenses and restrictions contained in BCP 78, and
	except as set forth therein, the authors retain all their rights."
	"This document and the information contained herein are provided on		This document is subject to the rights, licenses and restrictions
	an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE		contained in BCP 78, and except as set forth therein, the authors
	REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE		retain all their rights.
	INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
	IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF		This document and the information contained herein are provided on an
	THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
			OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
			ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
			INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
			INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	14. Expiration Date		14. Expiration Date
	This memo is filed as <draft-nalawade-kapoor-tunnel-safi-04.txt>, and		This memo is filed as <draft-nalawade-kapoor-tunnel-safi-05.txt>, and
	expires April, 2006.		expires December, 2006.
End of changes. 28 change blocks.
	67 lines changed or deleted		121 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/