draft-ietf-idr-link-bandwidth-00.txt		draft-ietf-idr-link-bandwidth-01.txt
	Network Working Group P. Mohapatra		Network Working Group P. Mohapatra
	Internet-Draft Cisco Systems		Internet-Draft R. Fernando
	Intended status: Standards Track R. Fernando		Intended status: Standards Track Cisco Systems
	Expires: October 23, 2009 Juniper Networks		Expires: August 28, 2010 February 24, 2010
	April 21, 2009
	BGP Link Bandwidth Extended Community		BGP Link Bandwidth Extended Community
	draft-ietf-idr-link-bandwidth-00.txt		draft-ietf-idr-link-bandwidth-01.txt
			Abstract
			This document describes an application of BGP extended communities
			that allows a router to perform unequal cost load balancing.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF in full conformance with the
	provisions of BCP 78 and BCP 79. This document may contain material		provisions of BCP 78 and BCP 79.
	from IETF Documents or IETF Contributions published or made publicly
	available before November 10, 2008. The person(s) controlling the
	copyright in some of this material may not have granted the IETF
	Trust the right to allow modifications of such material outside the
	IETF Standards Process. Without obtaining an adequate license from
	the person(s) controlling the copyright in such materials, this
	document may not be modified outside the IETF Standards Process, and
	derivative works of it may not be created outside the IETF Standards
	Process, except to format it for publication as an RFC or to
	translate it into languages other than English.
	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.
	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."
	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.
	This Internet-Draft will expire on October 23, 2009.		This Internet-Draft will expire on August 28, 2010.
	Copyright Notice		Copyright Notice
	Copyright (c) 2009 IETF Trust and the persons identified as the		Copyright (c) 2010 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 in effect on the date of		Provisions Relating to IETF Documents
	publication of this document (http://trustee.ietf.org/license-info).		(http://trustee.ietf.org/license-info) in effect on the date of
	Please review these documents carefully, as they describe your rights		publication of this document. Please review these documents
	and restrictions with respect to this document.		carefully, as they describe your rights and restrictions with respect
			to this document. Code Components extracted from this document must
	Abstract		include Simplified BSD License text as described in Section 4.e of
			the Trust Legal Provisions and are provided without warranty as
			described in the BSD License.
	This document describes an application of BGP extended communities		This document may contain material from IETF Documents or IETF
	that allows a router to perform unequal cost load balancing.		Contributions published or made publicly available before November
			10, 2008. The person(s) controlling the copyright in some of this
			material may not have granted the IETF Trust the right to allow
			modifications of such material outside the IETF Standards Process.
			Without obtaining an adequate license from the person(s) controlling
			the copyright in such materials, this document may not be modified
			outside the IETF Standards Process, and derivative works of it may
			not be created outside the IETF Standards Process, except to format
			it for publication as an RFC or to translate it into languages other
			than English.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3		1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3
	2. Link Bandwidth Extended Community . . . . . . . . . . . . . . . 3		2. Link Bandwidth Extended Community . . . . . . . . . . . . . . . 3
	3. Deployment Considerations . . . . . . . . . . . . . . . . . . . 4		3. Deployment Considerations . . . . . . . . . . . . . . . . . . . 3
	4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 4		4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 4
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
	6. Security Considerations . . . . . . . . . . . . . . . . . . . . 4		6. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
	7. Normative References . . . . . . . . . . . . . . . . . . . . . 4		7. Normative References . . . . . . . . . . . . . . . . . . . . . 4
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 4
	1. Introduction		1. Introduction
	When a BGP speaker receives multiple paths from its internal peers,		When a BGP speaker receives multiple paths from its internal peers,
	it could select more than one path to send traffic to. In doing so,		it could select more than one path to send traffic to. In doing so,
	it might be useful to provide the speaker with information that would		it might be useful to provide the speaker with information that would
	help it distribute the traffic unequally based on the cost of the		help it distribute the traffic unequally based on the cost of the
	external (DMZ) link. This document suggests that the external link		external (DMZ) link. This document suggests that the external link
	bandwidth be carried in the network using a new extended community		bandwidth be carried in the network using a new extended community
	[RFC4360] - the link bandwidth extended community.		[RFC4360] - the link bandwidth extended community.
	skipping to change at page 3, line 31		skipping to change at page 3, line 31
	2. Link Bandwidth Extended Community		2. Link Bandwidth Extended Community
	When a BGP speaker receives a route from a directly connected		When a BGP speaker receives a route from a directly connected
	external neighbor (the external neighbor that is one IP hop away) and		external neighbor (the external neighbor that is one IP hop away) and
	advertises this route (via IBGP) to internal neighbors, as part of		advertises this route (via IBGP) to internal neighbors, as part of
	this advertisement the router may carry the bandwidth of the link		this advertisement the router may carry the bandwidth of the link
	that connects the router with the external neighbor. The bandwidth		that connects the router with the external neighbor. The bandwidth
	of such a link is carried in the Link Bandwidth Community. The		of such a link is carried in the Link Bandwidth Community. The
	community is optional non-transitive. A border router MUST strip the		community is optional non-transitive. A border router MUST strip the
	link bandwidth community from a route when it advertises the route to		link bandwidth community from a route when it advertises the route to
	an external neighbor.		an external neighbor. The value of the high-order octet of the
			extended Type Field is 0x40. The value of the low-order octet of the
	It is noteworthy that the bandwidth carried in the Link Bandwidth		extended type field for this community is 0x04. The value of the
	extended community is the configured bandwidth of the EBGP link. It		Global Administrator subfield in the Value Field SHOULD represent the
	does not depend on the amount of traffic transiting that link.		Autonomous System of the router that attaches the Link Bandwidth
			Community. If four octet AS numbering scheme is used [RFC4893],
	The value of the high-order octet of the extended Type Field is 0x40.		AS_TRANS should be used in the Global Administrator subfield. The
	The value of the low-order octet of the extended type field for this		bandwidth of the link is expressed as 4 octets in IEEE floating point
	community is 0x04.		format, units being bytes per second. It is carried in the Local
			Administrator subfield of the Value Field.
	The value of the Global Administrator subfield in the Value Field
	SHOULD represent the Autonomous System of the router that attaches
	the Link Bandwidth Community. If four octet AS numbering scheme is
	used [RFC4893], AS_TRANS should be used in the Global Administrator
	subfield.
	The bandwidth of the link is expressed as 4 octets in IEEE floating
	point format, units being bytes per second. It is carried in the
	Local Administrator subfield of the Value Field.
	3. Deployment Considerations		3. Deployment Considerations
	This document proposes to use the Link Bandwidth extended community		The usage of this community is restricted to the cases where BGP
	for the purpose of load balancing in the following two scenarios.		multipath can be safely deployed. In other words, the IGP distance
	The first scenario is when the candidate paths are identical until		between the load balancing router and the exit points should be the
	and including the IGP distance step in the BGP decision process. The		same. Alternatively, the path between the load sharing router and
	second scenario is when the traffic goes via a tunneled network, in		the exit points could be label switched. If there are multiple paths
	which case the candidate paths are identical for all steps before the		to reach a destination and if only some of them have link bandwidth
	IGP distance step in the BGP decision process. Use of this community		community, the receiver should not perform unequal cost load
	for other scenarios is outside the scope of this document.		balancing based on link bandwidths.
	If there are multiple paths to reach a destination and if only some
	of them have link bandwidth community, the receiver should not
	perform unequal cost load balancing based on link bandwidths.
	4. Acknowledgments		4. Acknowledgments
	The authors would like to thank Yakov Rekhter, Srihari Sangli and Dan		The authors would like to thank Yakov Rekhter, Srihari Sangli and Dan
	Tappan for proposing unequal cost load balancing as one possible		Tappan for proposing unequal cost load balancing as one possible
	application of the extended community attribute.		application of the extended community attribute.
	5. IANA Considerations		5. IANA Considerations
	This document defines a specific application of the two-octet AS		This document defines a specific application of the two-octet AS
	skipping to change at page 5, line 20		skipping to change at page 5, line 17
	Pradosh Mohapatra		Pradosh Mohapatra
	Cisco Systems		Cisco Systems
	170 W. Tasman Drive		170 W. Tasman Drive
	San Jose, CA 95134		San Jose, CA 95134
	USA		USA
	Phone:		Phone:
	Email: pmohapat@cisco.com		Email: pmohapat@cisco.com
	Rex Fernando		Rex Fernando
	Juniper Networks		Cisco Systems
	1194 N. Mathilda Ave		170 W. Tasman Drive
	Sunnyvale, CA 94089		San Jose, CA 95134
	USA		USA
	Phone:		Phone:
	Email: rex@juniper.net		Email: rex@cisco.com
End of changes. 13 change blocks.
	62 lines changed or deleted		54 lines changed or added
This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/