draft-ietf-grow-as-path-prepending-04.txt		draft-ietf-grow-as-path-prepending-05.txt
	Network Working Group M. McBride		Network Working Group M. McBride
	Internet-Draft Futurewei		Internet-Draft Futurewei
	Updates: 7454, 8195 (if approved) D. Madory		Updates: 7454, 8195 (if approved) D. Madory
	Intended status: Best Current Practice Kentik		Intended status: Best Current Practice Kentik
	Expires: January 9, 2022 J. Tantsura		Expires: 8 July 2022 J. Tantsura
	Microsoft		Microsoft
	R. Raszuk		R. Raszuk
	NTT Network Innovations		NTT Network Innovations
	H. Li		H. Li
	HPE		HPE
	J. Heitz		J. Heitz
	Cisco		Cisco
	G. Mishra		G. Mishra
	Verizon Inc.		Verizon Inc.
	July 8, 2021		4 January 2022
	AS Path Prepending		AS Path Prepending
	draft-ietf-grow-as-path-prepending-04		draft-ietf-grow-as-path-prepending-05
	Abstract		Abstract
	AS Path Prepending provides a tool to manipulate the BGP AS_Path		AS Path Prepending provides a tool to manipulate the BGP AS_Path
	attribute through prepending multiple entries of an AS. AS Path		attribute through prepending multiple entries of an AS. AS Path
	Prepending is used to deprioritize a route or alternate path. By		Prepending is used to deprioritize a route or alternate path. By
	prepending the local ASN multiple times, ASs can make advertised AS		prepending the local ASN multiple times, ASs can make advertised AS
	paths appear artificially longer. Excessive AS Path Prepending has		paths appear artificially longer. Excessive AS Path Prepending has
	caused routing issues in the internet. This document provides		caused routing issues in the internet. This document provides
	guidance with the use of AS Path Prepending, including alternative		guidance with the use of AS Path Prepending, including alternative
	skipping to change at page 1, line 48 ¶		skipping to change at page 1, line 48 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on January 9, 2022.		This Internet-Draft will expire on 8 July 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2022 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	(https://trustee.ietf.org/license-info) in effect on the date of		license-info) in effect on the date of publication of this document.
	publication of this document. Please review these documents		Please review these documents carefully, as they describe your rights
	carefully, as they describe your rights and restrictions with respect		and restrictions with respect to this document. Code Components
	to this document. Code Components extracted from this document must		extracted from this document must include Revised BSD License text as
	include Simplified BSD License text as described in Section 4.e of		described in Section 4.e of the Trust Legal Provisions and are
	the Trust Legal Provisions and are provided without warranty as		provided without warranty as described in the Revised BSD License.
	described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3		1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
	2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Problems . . . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Problems . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3.1. Cascading and ripple affect of prepending across the		3.1. Cascading and ripple affect of prepending across the
	internet . . . . . . . . . . . . . . . . . . . . . . . . 4		internet . . . . . . . . . . . . . . . . . . . . . . . . 4
	3.2. Excessive Prepending . . . . . . . . . . . . . . . . . . 5		3.2. Excessive Prepending . . . . . . . . . . . . . . . . . . 5
	3.3. Prepending during a routing leak . . . . . . . . . . . . 6		3.3. Prepending during a routing leak . . . . . . . . . . . . 6
	3.4. Prepending to All . . . . . . . . . . . . . . . . . . . . 7		3.4. Prepending to All . . . . . . . . . . . . . . . . . . . . 7
	3.5. Memory . . . . . . . . . . . . . . . . . . . . . . . . . 7		3.5. Memory . . . . . . . . . . . . . . . . . . . . . . . . . 7
	3.6. Errant announcement . . . . . . . . . . . . . . . . . . . 7		3.6. Errant announcement . . . . . . . . . . . . . . . . . . . 8
	4. Alternatives to AS Path Prepend . . . . . . . . . . . . . . . 8		4. Alternatives to AS Path Prepend . . . . . . . . . . . . . . . 8
	5. Best Practices . . . . . . . . . . . . . . . . . . . . . . . 9		5. Best Practices . . . . . . . . . . . . . . . . . . . . . . . 9
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 10		7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
	8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 11		8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 11
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11		9. Normative References . . . . . . . . . . . . . . . . . . . . 11
	9.1. Normative References . . . . . . . . . . . . . . . . . . 11		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
	9.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 11
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
	1. Introduction		1. Introduction
	The Border Gateway Protocol (BGP) [RFC4271] specifies the AS_PATH		The Border Gateway Protocol (BGP) [RFC4271] specifies the AS_PATH
	attribute which enumerates ASs a route update has traversed. If the		attribute which enumerates ASs a route update has traversed. If the
	UPDATE message is propagated over an external link, then the local AS		UPDATE message is propagated over an external link, then the local AS
	number is prepended to the AS_PATH attribute, and the NEXT_HOP		number is prepended to the AS_PATH attribute, and the NEXT_HOP
	attribute is updated with an IP address of the router that should be		attribute is updated with an IP address of the router that should be
	used as a next hop to the network. If the UPDATE message is		used as a next hop to the network. If the UPDATE message is
	propagated over an internal link, then the AS_PATH attribute and the		propagated over an internal link, then the AS_PATH attribute and the
	skipping to change at page 3, line 28 ¶		skipping to change at page 3, line 28 ¶
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	2. Use Cases		2. Use Cases
	There are various reasons that AS Path Prepending is in use today		There are various reasons that AS Path Prepending is in use today
	including:		including:
	o Preferring one ISP over another ISP on the same ASBR or across		* Preferring one ISP over another ISP on the same ASBR or across
	different ASBRs.		different ASBRs.
	o Preferring one ASBR over another ASBR in the same site or between		* Preferring one ASBR over another ASBR in the same site or between
	sister sites.		sister sites.
	o Utilize one path exclusively and another path solely as a backup.		* Utilize one path exclusively and another path solely as a backup.
	o Signal to indicate that one path may have a different amount of		* Signal to indicate that one path may have a different amount of
	capacity than another where the lower capacity link still takes		capacity than another where the lower capacity link still takes
	traffic.		traffic.
	o Conditionally prefer one ASBR over another at the same site or		* Conditionally prefer one ASBR over another at the same site or
	between sites for lowest latency path based on geographic		between sites for lowest latency path based on geographic
	location.		location.
	o An ISP doesn't accept traffic engineering using BGP communities.		* An ISP doesn't accept traffic engineering using BGP communities.
	Prepending is the only option.		Prepending is the only option.
	The following illustration, from Geoff Hustons Path Prepending in BGP		The following illustration, from Geoff Hustons Path Prepending in BGP
	[1], shows how AS Prepending is typically used:		(https://labs.apnic.net/?p=1264), shows how AS Prepending is
			typically used:
	+---+ +---+		+---+ +---+
	+---| D |----| F |		+---| D |----| F |
	| +---+ +---+		| +---+ +---+
	+---+ +---+ |		+---+ +---+ |
	| A |---| B | |		| A |---| B | |
	+---+ +---+ 2x<- |		+---+ +---+ 2x<- |
	| +---+ +---+		| +---+ +---+
	+---| C |----| E |		+---| C |----| E |
	+---+ +---+		+---+ +---+
	skipping to change at page 7, line 7 ¶		skipping to change at page 7, line 7 ¶
	prepending-to-all going on right now and during leaks, it doesn't go		prepending-to-all going on right now and during leaks, it doesn't go
	well for those who make this mistake. While one can debate the		well for those who make this mistake. While one can debate the
	merits of prepending to a subset of multiple transit providers, it is		merits of prepending to a subset of multiple transit providers, it is
	difficult to see the utility in prepending to every provider. In		difficult to see the utility in prepending to every provider. In
	this configuration, the prepending is no longer shaping route		this configuration, the prepending is no longer shaping route
	propagation. It is simply incentivizing ASs to choose another origin		propagation. It is simply incentivizing ASs to choose another origin
	if one were to suddenly appear whether by mistake or otherwise.		if one were to suddenly appear whether by mistake or otherwise.
	3.4. Prepending to All		3.4. Prepending to All
	Based on analysis done in 2019, Excessive AS Path Prepending [2], out		Based on analysis done in 2019, Excessive AS Path Prepending
	of approximately 750,000 routes in the IPv4 global routing table,		(https://blogs.oracle.com/internetintelligence/excessive-as-path-
	nearly 60,000 BGP routes are prepended to 95% or more of hundreds of		prepending-is-a-self-inflicted-vulnerability), out of approximately
	BGP sources. About 8% of the global routing table, or 1 out of every		750,000 routes in the IPv4 global routing table, nearly 60,000 BGP
	12 BGP routes, is configured with prepends to virtually the entire		routes are prepended to 95% or more of hundreds of BGP sources.
	internet. The 60,000 routes include entities of every stripe:		About 8% of the global routing table, or 1 out of every 12 BGP
	governments, financial institutions, even important parts of internet		routes, is configured with prepends to virtually the entire internet.
			The 60,000 routes include entities of every stripe: governments,
			financial institutions, even important parts of internet
	infrastructure.		infrastructure.
	Much of the worst propagation of leaked routes during big leak events		Much of the worst propagation of leaked routes during big leak events
	have been due to routes being prepended-to-all. AS64505 leak of		have been due to routes being prepended-to-all. AS64505 leak of
	April 2014 (>320,000 prefixes) was prepended-to-all. And the AS64506		April 2014 (>320,000 prefixes) was prepended-to-all. And the AS64506
	leak of June 2015 (>260,000 prefixes) was also prepended-to-all.		leak of June 2015 (>260,000 prefixes) was also prepended-to-all.
	Prepended-to-all prefixes are those seen as prepended by all (or		Prepended-to-all prefixes are those seen as prepended by all (or
	nearly all) of the ASs of the internet. In this configuration,		nearly all) of the ASs of the internet. In this configuration,
	prepending is no longer shaping route propagation but is simply		prepending is no longer shaping route propagation but is simply
	incentivizing ASs to choose another origin if one were to suddenly		incentivizing ASs to choose another origin if one were to suddenly
	skipping to change at page 8, line 10 ¶		skipping to change at page 8, line 18 ¶
	announcement. In this incident, AS64496 announced its one prefix		announcement. In this incident, AS64496 announced its one prefix
	with an extremely long AS path. Someone entered their ASN instead of		with an extremely long AS path. Someone entered their ASN instead of
	the prepend count 64496 modulo 256 = 252 prepends and when a path		the prepend count 64496 modulo 256 = 252 prepends and when a path
	lengths exceeded 255, routers crashed		lengths exceeded 255, routers crashed
	4. Alternatives to AS Path Prepend		4. Alternatives to AS Path Prepend
	Various options, to provide path preference without needing to use AS		Various options, to provide path preference without needing to use AS
	Path Prepend, include:		Path Prepend, include:
	o Use predefined communities that are mapped to a particular		* Use predefined communities that are mapped to a particular
	behavior when propagated.		behavior when propagated.
	o Announce more specific routes on the preferred path.		* Announce more specific routes on the preferred path.
	o The BGP Origin Code is an attribute that is used for path		* The BGP Origin Code is an attribute that is used for path
	selection and can be used as a high order tie-breaker. The three		selection and can be used as a high order tie-breaker. The three
	origin codes are IGP, EGP and INCOMPLETE. When AS Paths are of		origin codes are IGP, EGP and INCOMPLETE. When AS Paths are of
	equivalent length, users could advertise paths, with IGP or EGP		equivalent length, users could advertise paths, with IGP or EGP
	origin, over the preferred path while the other ASBRs (which would		origin, over the preferred path while the other ASBRs (which would
	otherwise need to prepend N times) advertises with an INCOMPLETE		otherwise need to prepend N times) advertises with an INCOMPLETE
	origin code.		origin code.
	o The Multi Exit Discriminator (MED) is an optional non-transitive		* The Multi Exit Discriminator (MED) is an optional non-transitive
	attribute that can be used to influence path preference instead of		attribute that can be used to influence path preference instead of
	using as-path. MED is non transitive so it cannot influence an AS		using as-path. MED is non transitive so it cannot influence an AS
	more then 1 AS hop away.		more then 1 AS hop away.
	o Local-preference optional non-transitive attribute, above as-path		* Local-preference optional non-transitive attribute, above as-path
	in bgp path selection, can be used to influence route preference		in bgp path selection, can be used to influence route preference
	within the local operators AS administrative domain. Local-		within the local operators AS administrative domain. Local-
	preference can shield the operator domain from traffic shifts off		preference can shield the operator domain from traffic shifts off
	the preferred path to a de-preferred path caused by excess		the preferred path to a de-preferred path caused by excess
	prepending done by service providers across the internet. If all		prepending done by service providers across the internet. If all
	service providers across the internet set local-preference inbound		service providers across the internet set local-preference inbound
	conditionally with Large Community set on preferred paths,		conditionally with Large Community set on preferred paths,
	essentially the impacts of route leaks as well as other routing		essentially the impacts of route leaks as well as other routing
	issues resulting from excess prepending can be mitigated.		issues resulting from excess prepending can be mitigated.
	skipping to change at page 9, line 33 ¶		skipping to change at page 9, line 44 ¶
	ingressing B, will be shunted to D via local-preference and the route		ingressing B, will be shunted to D via local-preference and the route
	leak is now mitigated for all downstream AS to the left of B that		leak is now mitigated for all downstream AS to the left of B that
	prefer the path through B.		prefer the path through B.
	5. Best Practices		5. Best Practices
	Many of the best practices, or lack thereof, can be illustrated from		Many of the best practices, or lack thereof, can be illustrated from
	the preceeding examples. Here's a summary of the best current		the preceeding examples. Here's a summary of the best current
	practices when using AS Path Prepending:		practices when using AS Path Prepending:
	o Network operators should ensure prepending is absolutely necessary		* Network operators should ensure prepending is absolutely necessary
	as many networks have excessive prepending. It is best to		as many networks have excessive prepending. It is best to
	innumerate what the routing policies are intended to achieve		innumerate what the routing policies are intended to achieve
	before concluding that prepending is a solution		before concluding that prepending is a solution
	o The neighbor you are prepending may have an unconditional		* The neighbor you are prepending may have an unconditional
	preference for customer routes and prepending doesn't work. It's		preference for customer routes and prepending doesn't work. It's
	helpful to check with neighbors to see if they will honor the		helpful to check with neighbors to see if they will honor the
	prepend to avoid wasting effort and potentially causing further		prepend to avoid wasting effort and potentially causing further
	vulnerabilities.		vulnerabilities.
	o Use of local-preference inbound on preferred paths between service		* Use of local-preference inbound on preferred paths between service
	providers to help mitigate the adverse affects of prepending		providers to help mitigate the adverse affects of prepending
	o There is no need to prepend more than 5 ASs. The following		* There is no need to prepend more than 5 ASs. The following
	diagram, from the previously referenced AS Path Prepending		diagram, from the previously referenced AS Path Prepending
	analysis from 2019, shows that 90% of AS path lengths are 5 ASNs		analysis from 2019, shows that 90% of AS path lengths are 5 ASNs
	or fewer in length.		or fewer in length.
	+------------------------------------+		+------------------------------------+
	90| |		90| |
	| X |		| X |
	80| X X |		80| X X |
	| X X |		| X X |
	70| X X |		70| X X |
	skipping to change at page 10, line 30 ¶		skipping to change at page 10, line 44 ¶
	20| X XX |		20| X XX |
	| XX XX |		| XX XX |
	10| XX XXXX |		10| XX XXXX |
	|XX XXXXXXXXXXXXXXXXX|		|XX XXXXXXXXXXXXXXXXX|
	+------------------------------------+		+------------------------------------+
	5 10 15		5 10 15
	AS Path Length in IPv4		AS Path Length in IPv4
	X Axis = unique AS Paths in millions		X Axis = unique AS Paths in millions
	o Don't prepend ASNs that you don't own.		* Don't prepend ASNs that you don't own.
	o Prepending-to-all is a self-inflicted and needless risk that		* Prepending-to-all is a self-inflicted and needless risk that
	serves little purpose. Those excessively prepending their routes		serves little purpose. Those excessively prepending their routes
	should consider this risk and adjust their routing configuration.		should consider this risk and adjust their routing configuration.
	o The Internet is typically around 5 ASs deep with the largest		* The Internet is typically around 5 ASs deep with the largest
	AS_PATH being 16-20 ASNs. Some have added 100 or more AS Path		AS_PATH being 16-20 ASNs. Some have added 100 or more AS Path
	Prepends and operators should therefore consider limiting the		Prepends and operators should therefore consider limiting the
	maximum AS-path length being accepted through aggressive filter		maximum AS-path length being accepted through aggressive filter
	policies.		policies.
	6. IANA Considerations		6. IANA Considerations
	7. Security Considerations		7. Security Considerations
	Long prepending may make a network more vulernable to route hijacking		Long prepending may make a network more vulernable to route hijacking
	which will exist whenever there is a well connected peer that is		which will exist whenever there is a well connected peer that is
	willing to forge their AS_PATH or allows announcements with a		willing to forge their AS_PATH or allows announcements with a
	fabricated AS path.		fabricated AS path.
	8. Acknowledgement		8. Acknowledgement
	The authors would like to thank Greg Skinner, Randy Bush, Dave		The authors would like to thank Greg Skinner, Randy Bush, Dave
	Farmer, Nick Hilliard, Martijn Schmidt, Michael Still, Geoff Huston		Farmer, Nick Hilliard, Martijn Schmidt, Michael Still, Geoff Huston
	and Jeffrey Haas for contributing to this document.		and Jeffrey Haas for contributing to this document.
	9. References		9. Normative References
	9.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A		[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
	Border Gateway Protocol 4 (BGP-4)", RFC 4271,		Border Gateway Protocol 4 (BGP-4)", RFC 4271,
	DOI 10.17487/RFC4271, January 2006,		DOI 10.17487/RFC4271, January 2006,
	<https://www.rfc-editor.org/info/rfc4271>.		<https://www.rfc-editor.org/info/rfc4271>.
	skipping to change at page 11, line 38 ¶		skipping to change at page 12, line 5 ¶
	[RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks		[RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks
	Reserved for Documentation", RFC 5737,		Reserved for Documentation", RFC 5737,
	DOI 10.17487/RFC5737, January 2010,		DOI 10.17487/RFC5737, January 2010,
	<https://www.rfc-editor.org/info/rfc5737>.		<https://www.rfc-editor.org/info/rfc5737>.
	[RFC8195] Snijders, J., Heasley, J., and M. Schmidt, "Use of BGP		[RFC8195] Snijders, J., Heasley, J., and M. Schmidt, "Use of BGP
	Large Communities", RFC 8195, DOI 10.17487/RFC8195, June		Large Communities", RFC 8195, DOI 10.17487/RFC8195, June
	2017, <https://www.rfc-editor.org/info/rfc8195>.		2017, <https://www.rfc-editor.org/info/rfc8195>.
	9.2. URIs
	[1] https://labs.apnic.net/?p=1264
	[2] https://blogs.oracle.com/internetintelligence/excessive-as-path-
	prepending-is-a-self-inflicted-vulnerability
	Authors' Addresses		Authors' Addresses
	Mike McBride		Mike McBride
	Futurewei		Futurewei
	Email: michael.mcbride@futurewei.com		Email: michael.mcbride@futurewei.com
	Doug Madory		Doug Madory
	Kentik		Kentik
	Email: dmadory@kentik.com		Email: dmadory@kentik.com
	Jeff Tantsura		Jeff Tantsura
	Microsoft		Microsoft
	Email: jefftant.ietf@gmail.com		Email: jefftant.ietf@gmail.com
	skipping to change at page 12, line 17 ¶		skipping to change at page 12, line 25 ¶
	Email: dmadory@kentik.com		Email: dmadory@kentik.com
	Jeff Tantsura		Jeff Tantsura
	Microsoft		Microsoft
	Email: jefftant.ietf@gmail.com		Email: jefftant.ietf@gmail.com
	Robert Raszuk		Robert Raszuk
	NTT Network Innovations		NTT Network Innovations
	940 Stewart Dr		940 Stewart Dr
	Sunnyvale, CA 94085		Sunnyvale, CA 94085
	USA		United States of America
	Email: robert@raszuk.net		Email: robert@raszuk.net
	Hongwei Li		Hongwei Li
	HPE		HPE
	Email: flycoolman@gmail.com		Email: flycoolman@gmail.com
	Jakob Heitz		Jakob Heitz
	Cisco		Cisco
	170 West Tasman Drive		170 West Tasman Drive
	San Jose, CA 95134		San Jose, CA 95134
	USA		United States of America
	Email: jheitz@cisco.com		Email: jheitz@cisco.com
	Gyan Mishra		Gyan Mishra
	Verizon Inc.		Verizon Inc.
	Email: gyan.s.mishra@verizon.com		Email: gyan.s.mishra@verizon.com
End of changes. 34 change blocks.
	60 lines changed or deleted		52 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/