draft-ietf-idr-aigp-17.txt		draft-ietf-idr-aigp-18.txt
	Network Working Group Pradosh Mohapatra		Network Working Group Pradosh Mohapatra
	Internet Draft Cumulus Networks		Internet Draft Cumulus Networks
	Intended Status: Proposed Standard		Intended Status: Proposed Standard
	Expires: October 8, 2014 Rex Fernando		Expires: October 28, 2014 Rex Fernando
	Eric C. Rosen		Eric C. Rosen
	Cisco Systems, Inc.		Cisco Systems, Inc.
	James Uttaro		James Uttaro
	ATT		ATT
	April 8, 2014		April 28, 2014
	The Accumulated IGP Metric Attribute for BGP		The Accumulated IGP Metric Attribute for BGP
	draft-ietf-idr-aigp-17.txt		draft-ietf-idr-aigp-18.txt
	Abstract		Abstract
	Routing protocols that have been designed to run within a single		Routing protocols that have been designed to run within a single
	administrative domain ("IGPs") generally do so by assigning a metric		administrative domain ("IGPs") generally do so by assigning a metric
	to each link, and then choosing as the installed path between two		to each link, and then choosing as the installed path between two
	nodes the path for which the total distance (sum of the metric of		nodes the path for which the total distance (sum of the metric of
	each link along the path) is minimized. BGP, designed to provide		each link along the path) is minimized. BGP, designed to provide
	routing over a large number of independent administrative domains		routing over a large number of independent administrative domains
	("autonomous systems"), does not make its path selection decisions		("autonomous systems"), does not make its path selection decisions
	skipping to change at page 4, line 43		skipping to change at page 4, line 43
	each running BGP. There are several reasons why a single		each running BGP. There are several reasons why a single
	administrative domain may be broken into several ASes (which, in this		administrative domain may be broken into several ASes (which, in this
	case, are not really "autonomous".) It may be that the existing IGPs		case, are not really "autonomous".) It may be that the existing IGPs
	do not scale well in the particular environment; it may be that a		do not scale well in the particular environment; it may be that a
	more generalized topology is desired than could be obtained by use of		more generalized topology is desired than could be obtained by use of
	a single IGP domain; it may be that a more finely grained routing		a single IGP domain; it may be that a more finely grained routing
	policy is desired than can be supported by an IGP. In such		policy is desired than can be supported by an IGP. In such
	deployments, it can be useful to allow BGP to make its routing		deployments, it can be useful to allow BGP to make its routing
	decisions based on the IGP metric, so that BGP chooses the "shortest"		decisions based on the IGP metric, so that BGP chooses the "shortest"
	path between two nodes, even if the nodes are in two different ASes		path between two nodes, even if the nodes are in two different ASes
	within that same administrative domain. We will refer to the set of		within that same administrative domain.
	ASes in a common administrative domain as an "AIGP Administrative
	Domain".
	There are in fact some implementations that already do something like		There are in fact some implementations that already do something like
	this, using BGP's MULTI_EXIT_DISC (MED) attribute to carry a value		this, using BGP's MULTI_EXIT_DISC (MED) attribute to carry a value
	based on IGP metrics. However, that doesn't really provide IGP-like		based on IGP metrics. However, that doesn't really provide IGP-like
	"shortest path" routing, as the BGP decision process gives priority		"shortest path" routing, as the BGP decision process gives priority
	to other factors, such as the AS_PATH length. Also, the standard		to other factors, such as the AS_PATH length. Also, the standard
	procedures for use of the MED do not ensure that the IGP metric is		procedures for use of the MED do not ensure that the IGP metric is
	properly accumulated so that it covers all the links along the path.		properly accumulated so that it covers all the links along the path.
	In this document, we define a new optional, non-transitive BGP		In this document, we define a new optional, non-transitive BGP
	attribute, called the "Accumulated IGP Metric Attribute", or "AIGP		attribute, called the "Accumulated IGP Metric Attribute", or "AIGP
	attribute", and specify the procedures for using it.		attribute", and specify the procedures for using it.
	The specified procedures prevent the AIGP attribute from "leaking		The specified procedures prevent the AIGP attribute from "leaking
	out" past an AIGP administrative domain boundary into the Internet.		out" past an administrative domain boundary into the Internet. We
			will refer to the set of ASes in a common administrative domain as an
			"AIGP Administrative Domain".
	The specified procedures also ensure that the value in the AIGP		The specified procedures also ensure that the value in the AIGP
	attribute has been accumulated all along the path from the		attribute has been accumulated all along the path from the
	destination, i.e., that the AIGP attribute does not appear when there		destination, i.e., that the AIGP attribute does not appear when there
	are "gaps" along the path where the IGP metric is unknown.		are "gaps" along the path where the IGP metric is unknown.
	3. AIGP Attribute		3. AIGP Attribute
	The AIGP Attribute is an optional non-transitive BGP Path Attribute.		The AIGP Attribute is an optional non-transitive BGP Path Attribute.
	The attribute type code for the AIGP Attribute is 26.		The attribute type code for the AIGP Attribute is 26.
	skipping to change at page 6, line 16		skipping to change at page 6, line 16
	This document defines only a single such TLV, the "AIGP TLV". The		This document defines only a single such TLV, the "AIGP TLV". The
	AIGP TLV is encoded as follows:		AIGP TLV is encoded as follows:
	- Type: 1		- Type: 1
	- Length: 11		- Length: 11
	- Accumulated IGP Metric.		- Accumulated IGP Metric.
	The value field of the AIGP TLV is always 8 bytes long. IGP		The value field of the AIGP TLV is always 8 octets long, and its
	metrics are frequently expressed as 4-octet values, and this		value is interpreted as an unsigned 64-bit integer. IGP metrics
	ensures that the AIGP attribute can be used to hold the sum of an		are frequently expressed as 4-octet values. By using an 8-octet
	arbitrary number of 4-octet values.		field, we ensure that the AIGP attribute can be used to hold the
			sum of a arbitrary number of 4-octet values.
	When an AIGP attribute is created, it SHOULD contain no more than one		When an AIGP attribute is created, it SHOULD contain no more than one
	AIGP TLV. However, if it contains more than one AIGP TLV, only the		AIGP TLV. However, if it contains more than one AIGP TLV, only the
	first one is used as described in Section 3.4 and Section 4. In the		first one is used as described in Section 3.4 and Section 4. In the
	remainder of this document, we will use the term "value of the AIGP		remainder of this document, we will use the term "value of the AIGP
	TLV" to mean the value of the first AIGP TLV in the AIGP attribute.		TLV" to mean the value of the first AIGP TLV in the AIGP attribute.
	Any other AIGP TLVs in the AIGP attribute MUST be passed along		Any other AIGP TLVs in the AIGP attribute MUST be passed along
	unchanged if the AIGP attribute is passed along.		unchanged if the AIGP attribute is passed along.
	3.1. Applicability Restrictions and Cautions		3.1. Applicability Restrictions and Cautions
End of changes. 6 change blocks.
	11 lines changed or deleted		12 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/