draft-ietf-idr-aigp-10.txt		draft-ietf-idr-aigp-11.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: November 23, 2013 Rex Fernando		Expires: May 21, 2014 Rex Fernando
	Eric C. Rosen		Eric C. Rosen
	Cisco Systems, Inc.		Cisco Systems, Inc.
	James Uttaro		James Uttaro
	ATT		ATT
	May 23, 2013		November 21, 2013
	The Accumulated IGP Metric Attribute for BGP		The Accumulated IGP Metric Attribute for BGP
	draft-ietf-idr-aigp-10.txt		draft-ietf-idr-aigp-11.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 3, line 11		skipping to change at page 3, line 11
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1 Specification of requirements ......................... 3		1 Specification of requirements ......................... 3
	2 Introduction .......................................... 3		2 Introduction .......................................... 3
	3 AIGP Attribute ........................................ 5		3 AIGP Attribute ........................................ 5
	3.1 Applicability Restrictions and Cautions ............... 6		3.1 Applicability Restrictions and Cautions ............... 6
	3.2 Restrictions on Sending/Receiving ..................... 6		3.2 Handling a Malformed AIGP Attribute ................... 6
	3.3 Creating and Modifying the AIGP Attribute ............. 7		3.3 Restrictions on Sending/Receiving ..................... 7
	3.3.1 Originating the AIGP Attribute ........................ 7		3.4 Creating and Modifying the AIGP Attribute ............. 7
	3.3.2 Modifications by the Originator ....................... 8		3.4.1 Originating the AIGP Attribute ........................ 7
	3.3.3 Modifications by a Non-Originator ..................... 8		3.4.2 Modifications by the Originator ....................... 9
	4 Decision Process ...................................... 10		3.4.3 Modifications by a Non-Originator ..................... 9
	4.1 When a Route has an AIGP Attribute .................... 10		4 Decision Process ...................................... 11
	4.2 When the Route to the Next Hop has an AIGP attribute .. 11		4.1 When a Route has an AIGP Attribute .................... 11
			4.2 When the Route to the Next Hop has an AIGP attribute .. 12
	5 Deployment Considerations ............................. 12		5 Deployment Considerations ............................. 12
	6 IANA Considerations ................................... 12		6 IANA Considerations ................................... 13
	7 Security Considerations ............................... 12		7 Security Considerations ............................... 13
	8 Acknowledgments ....................................... 12		8 Acknowledgments ....................................... 13
	9 Authors' Addresses .................................... 13		9 Authors' Addresses .................................... 13
	10 Normative References .................................. 13		10 Normative References .................................. 14
	11 Informative References ................................ 13		11 Informative References ................................ 14
	1. Specification of requirements		1. Specification of requirements
	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 [RFC2119].		document are to be interpreted as described in [RFC2119].
	2. Introduction		2. Introduction
	There are many routing protocols that have been designed to run		There are many routing protocols that have been designed to run
	skipping to change at page 5, line 40		skipping to change at page 5, line 41
	| Type | Length | |		| Type | Length | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
	~ ~		~ ~
	| Value |		| Value |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+..........................		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+..........................
	AIGP TLV		AIGP TLV
	Figure 1		Figure 1
	- Type: A single octet encoding the TLV Type. Only type 1, "AIGP		- Type: A single octet encoding the TLV Type. Only type 1, "AIGP
	TLV", is defined in this document.		TLV", is defined in this document. Use of other TLV types is
			outside the scope of this document.
	- Length: Two octets encoding the length in octets of the TLV,		- Length: Two octets encoding the length in octets of the TLV,
	including the type and length fields. The length is encoded as an		including the type and length fields. The length is encoded as an
	unsigned binary integer. (Note that the minimum length is 3,		unsigned binary integer. (Note that the minimum length is 3,
	indicating that no value field is present.)		indicating that no value field is present.)
	- A value field containing zero or more octets.		- A value field containing zero or more octets.
	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:
	skipping to change at page 6, line 21		skipping to change at page 6, line 21
	- 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 bytes long. IGP
	metrics are frequently expressed as 4-octet values, and this		metrics are frequently expressed as 4-octet values, and this
	ensures that the AIGP attribute can be used to hold the sum of an		ensures that the AIGP attribute can be used to hold the sum of an
	arbitrary number of 4-octet values.		arbitrary number of 4-octet values.
			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
			first one is 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 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 unchanged if the AIGP attribute is passed along.
	3.1. Applicability Restrictions and Cautions		3.1. Applicability Restrictions and Cautions
	This document only considers the use of the AIGP attribute in		This document only considers the use of the AIGP attribute in
	networks where each router uses tunneling of some sort to deliver a		networks where each router uses tunneling of some sort to deliver a
	packet to its BGP next hop. Use of the AIGP attribute in networks		packet to its BGP next hop. Use of the AIGP attribute in networks
	that do not use tunneling is outside the scope of this document.		that do not use tunneling is outside the scope of this document.
	If a Route Reflector supports the AIGP attribute, but some of its		If a Route Reflector supports the AIGP attribute, but some of its
	clients do not, then the routing choices that result may not all		clients do not, then the routing choices that result may not all
	reflect the intended routing policy.		reflect the intended routing policy.
	3.2. Restrictions on Sending/Receiving		3.2. Handling a Malformed AIGP Attribute
			When receiving a BGP Update message containing a malformed AIGP
			attribute, the attribute MUST be treated exactly as if it were an
			unrecognized non-transitive attribute. That is, "it MUST be quietly
			ignored and not passed along to other BGP peers". This is equivalent
			to the "attribute discard" action specified in [BGP-ERROR].
			Note that an AIGP attribute MUST NOT be considered to be malformed
			because it contains more than one TLV of a given type, or because it
			contains TLVs of unknown types.
			If a BGP Path Attribute is received that has the AIGP attribute
			codepoint, but also has the transitive bit set, the attribute MUST be
			considered to be a malformed AIGP attribute, and MUST be discarded as
			specified in this section.
			If an AIGP attribute is received, and its first AIGP TLV contains the
			maximum value 0xffffffffffffffff, the attribute SHOULD be considered
			to be malformed, and discarded as specified in this section. (Since
			the TLV value cannot be increased any further, it is not useful for
			metric-based path selection.)
			3.3. Restrictions on Sending/Receiving
	An implementation that supports the AIGP attribute MUST support a		An implementation that supports the AIGP attribute MUST support a
	per-session configuration item, AIGP_SESSION, that indicates whether		per-session configuration item, AIGP_SESSION, that indicates whether
	the attribute is enabled or disabled for use on that session.		the attribute is enabled or disabled for use on that session.
	- The default value of AIGP_SESSION, for EBGP sessions, MUST be		- The default value of AIGP_SESSION, for EBGP sessions, MUST be
	"disabled".		"disabled".
	- The default value of AIGP_SESSION, for IBGP and confederation-		- The default value of AIGP_SESSION, for IBGP and confederation-
	EBGP sessions, MUST be "enabled."		EBGP sessions, SHOULD be "enabled."
	The AIGP attribute MUST NOT be sent on any BGP session for which		The AIGP attribute MUST NOT be sent on any BGP session for which
	AIGP_SESSION is disabled.		AIGP_SESSION is disabled.
	If an AIGP attribute is received on a BGP session for which		If an AIGP attribute is received on a BGP session for which
	AIGP_SESSION is disabled, the attribute MUST be treated exactly as if		AIGP_SESSION is disabled, the attribute MUST be treated exactly as if
	it were an unrecognized non-transitive attribute. That is, "it MUST		it were an unrecognized non-transitive attribute. That is, "it MUST
	be quietly ignored and not passed along to other BGP peers" (see		be quietly ignored and not passed along to other BGP peers" (see
	[BGP], section 5).		[BGP], section 5).
	3.3. Creating and Modifying the AIGP Attribute		3.4. Creating and Modifying the AIGP Attribute
	3.3.1. Originating the AIGP Attribute		3.4.1. Originating the AIGP Attribute
	An implementation that supports the AIGP attribute MUST support a		An implementation that supports the AIGP attribute MUST support a
	configuration item, AIGP_ORIGINATE, that enables or disables its		configuration item, AIGP_ORIGINATE, that enables or disables its
	creation and attachment to routes. The default value of		creation and attachment to routes. The default value of
	AIGP_ORIGINATE MUST be "disabled".		AIGP_ORIGINATE MUST be "disabled".
	A BGP speaker MUST NOT add the AIGP attribute to any route whose path		A BGP speaker MUST NOT add the AIGP attribute to any route whose path
	leads outside the "AIGP administrative domain" to which the BGP		leads outside the "AIGP administrative domain" to which the BGP
	speaker belongs. It may be added only to routes that satisfy one of		speaker belongs. It may be added only to routes that satisfy one of
	the following conditions:		the following conditions:
	skipping to change at page 7, line 42		skipping to change at page 8, line 27
	A BGP speaker R MUST NOT add the AIGP attribute to any route for		A BGP speaker R MUST NOT add the AIGP attribute to any route for
	which R does not set itself as the next hop.		which R does not set itself as the next hop.
	It SHOULD be possible to set AIGP_ORIGINATE to "enabled for the		It SHOULD be possible to set AIGP_ORIGINATE to "enabled for the
	routes of a particular IGP that are redistributed into BGP" (where "a		routes of a particular IGP that are redistributed into BGP" (where "a
	particular IGP" might be "OSPF" or "ISIS"). Other policies		particular IGP" might be "OSPF" or "ISIS"). Other policies
	determining when and whether to originate an AIGP attribute are also		determining when and whether to originate an AIGP attribute are also
	possible, depending on the needs of a particular deployment scenario.		possible, depending on the needs of a particular deployment scenario.
	When originating an AIGP attribute for a BGP route to address prefix		When originating an AIGP attribute for a BGP route to address prefix
	P, the value of the attribute is set according to policy. There are		P, the value of the AIGP TLV is set according to policy. There are a
	a number of useful policies, some of which are in the following list:		number of useful policies, some of which are in the following list:
	- When a BGP speaker R is redistributing into BGP an IGP route to		- When a BGP speaker R is redistributing into BGP an IGP route to
	address prefix P, the IGP will have computed a "distance" from R		address prefix P, the IGP will have computed a "distance" from R
	to P. This distance MAY be assigned as the value of AIGP		to P. This distance MAY be assigned as the value of the AIGP
	attribute.		TLV.
	- A BGP speaker R may be redistributing into BGP a static route to		- A BGP speaker R may be redistributing into BGP a static route to
	address prefix P, for which a "distance" from R to P has been		address prefix P, for which a "distance" from R to P has been
	configured. This distance MAY be assigned as the value of AIGP		configured. This distance MAY be assigned as the value of the
	attribute.		AIGP TLV.
	- A BGP speaker R may have received and installed a BGP-learned		- A BGP speaker R may have received and installed a BGP-learned
	route to prefix P, with next hop N. Or it may be redistributing		route to prefix P, with next hop N. Or it may be redistributing
	a static route to P, with next hop N. Then:		a static route to P, with next hop N. Then:
	* If R has an IGP route to N, the IGP-computed distance from R		* If R has an IGP route to N, the IGP-computed distance from R
	to N MAY be used as the AIGP attribute value of the route to		to N MAY be used as the value of the AIGP TLV of the route to
	P.		P.
	* If R has a BGP route to N, and an AIGP attribute value has		* If R has a BGP route to N, and an AIGP TLV attribute value
	been computed for that route (see section 3.3.3), that value		has been computed for that route (see section 3.4.3), that
	MAY be used as the AIGP attribute value of the route to P.		value MAY be used as the AIGP TLV value of the route to P.
	3.3.2. Modifications by the Originator		3.4.2. Modifications by the Originator
	If BGP speaker R is the originator of the AIGP attribute of prefix P,		If BGP speaker R is the originator of the AIGP attribute of prefix P,
	and at some point the "distance" from R to P changes, R SHOULD issue		and at some point the "distance" from R to P changes, R SHOULD issue
	a new BGP update containing the new value of the AIGP attribute.		a new BGP update containing the new value of the AIGP TLV of the AIGP
	(Here we use the term "distance" to refer to whatever value the		attribute. (Here we use the term "distance" to refer to whatever
	originator assigns to the AIGP attribute, however it is computed; see		value the originator assigns to the AIGP TLV, however it is computed;
	section 3.3.1.) However, if the difference between the new distance		see section 3.4.1.) However, if the difference between the new
	and the distance advertised in the AIGP attribute is less than a		distance and the distance advertised in the AIGP TLV is less than a
	configurable threshold, the update MAY be suppressed.		configurable threshold, the update MAY be suppressed.
	3.3.3. Modifications by a Non-Originator		3.4.3. Modifications by a Non-Originator
	Suppose a BGP speaker R1 receives a route with an AIGP attribute		Suppose a BGP speaker R1 receives a route with an AIGP attribute
	whose value is A, and a Next Hop whose value is R2. Suppose also		whose value is A, and a Next Hop whose value is R2. Suppose also
	that R1 is about to redistribute that route on a BGP session that is		that R1 is about to redistribute that route on a BGP session that is
	enabled for sending/receiving the attribute.		enabled for sending/receiving the attribute.
	If R1 does not change the Next Hop of the route, then R1 MUST NOT		If R1 does not change the Next Hop of the route, then R1 MUST NOT
	change the AIGP attribute value of the route.		change the AIGP attribute value of the route.
			In all the computations discussed in this section, the AIGP value
			MUST be capped at its maximum unsigned value 0xffffffffffffffff.
			Increasing the AIGP value MUST NOT cause the value to wrap around.
	If R1 changes the Next Hop of the route from R2 to R1, and if R1's		If R1 changes the Next Hop of the route from R2 to R1, and if R1's
	route to R2 is an IGP-learned route, or a static route that does not		route to R2 is an IGP-learned route, or a static route that does not
	require recursive next hop resolution, then R1 must increase the		require recursive next hop resolution, then R1 MUST increase the
	value of the AIGP attribute by adding to A the distance from R1 to		value of the AIGP TLV by adding to A the distance from R1 to R2.
	R2. This distance is either the IGP-computed distance from R1 to R2,		This distance is either the IGP-computed distance from R1 to R2, or
	or some value determined by policy. However, A MUST be increased by		some value determined by policy. However, A MUST be increased by a
	a non-zero amount.		non-zero amount.
	Note that if R1 and R2 above are EBGP neighbors, and there is a		Note that if R1 and R2 above are EBGP neighbors, and there is a
	direct link between them on which no IGP is running, then when R1		direct link between them on which no IGP is running, then when R1
	changes the next hop of a route from R2 to R1, the AIGP metric value		changes the next hop of a route from R2 to R1, the AIGP TLV value
	MUST be increased by a non-zero amount. The amount of the increase		MUST be increased by a non-zero amount. The amount of the increase
	SHOULD be such that it is properly comparable to the IGP metrics.		SHOULD be such that it is properly comparable to the IGP metrics.
	E.g., if the IGP metric is a function of latency, then the amount of		E.g., if the IGP metric is a function of latency, then the amount of
	the increase should be a function of the latency from R1 to R2.		the increase should be a function of the latency from R1 to R2.
	If R1 changes the Next Hop of the route from R2 to R1, and if R1's		If R1 changes the Next Hop of the route from R2 to R1, and if R1's
	route to R2 is a BGP-learned route, or a static route that requires		route to R2 is a BGP-learned route, or a static route that requires
	recursive next hop resolution, then the AIGP attribute value needs to		recursive next hop resolution, then the AIGP TLV value needs to be
	be increased in several steps, according to the following procedure.		increased in several steps, according to the following procedure.
	(Note that this procedure is ONLY used when recursive next hop		(Note that this procedure is ONLY used when recursive next hop
	resolution is needed.)		resolution is needed.)
			1. Let Xattr be the new AIGP TLV value.
	1. Let Xattr be the new AIGP attribute value.
	2. Initialize Xattr to A.		2. Initialize Xattr to A.
	3. Set the XNH to R2.		3. Set the XNH to R2.
	4. Find the route to XNH.		4. Find the route to XNH.
	5. If the route to XNH does not require recursive next hop		5. If the route to XNH does not require recursive next hop
	resolution, get the distance D from R1 to XNH. (Note that this		resolution, get the distance D from R1 to XNH. (Note that this
	condition cannot be satisfied the first time through this		condition cannot be satisfied the first time through this
	procedure.) If D is above a configurable threshold, set the		procedure.) If D is above a configurable threshold, set the
	AIGP attribute value to Xattr+D. If D is below a configurable		AIGP TLV value to Xattr+D. If D is below a configurable
	threshold, set the AIGP attribute value to Xattr. In either		threshold, set the AIGP TLV value to Xattr. In either case,
	case, exit this procedure.		exit this procedure.
	6. If the route to XNH is a BGP-learned route, and the route does		6. If the route to XNH is a BGP-learned route, and the route does
	NOT have an AIGP attribute, then exit this procedure and do not		NOT have an AIGP attribute, then exit this procedure and do not
	pass on any AIGP attribute.		pass on any AIGP attribute. If the route has an AIGP attribute
			without an AIGP TLV, then the AIGP attribute MAY be passed
			along unchanged.
	7. If the route to XNH is a BGP-learned route, and the route has		7. If the route to XNH is a BGP-learned route, and the route has
	an AIGP attribute value of Y, then set Xattr=Xattr+Y, and set		an AIGP TLV value of Y, then set Xattr=Xattr+Y, and set XNH to
	XNH to the next hop of this route. (The intention here is that		the next hop of this route. (The intention here is that Y is
	Y is the AIGP value of the route as it was received by R1,		the AIGP TLV value of the route as it was received by R1,
	without having been modified by R1.)		without having been modified by R1.)
	8. Go to step 4.		8. Go to step 4.
	The AIGP value of a given route depends on (a) the AIGP values of all		The AIGP TLV value of a given route depends on (a) the AIGP TLV
	the next hops that are recursively resolved during this procedure,		values of all the next hops that are recursively resolved during this
	and (b) the IGP distance to any next hop that is not recursively		procedure, and (b) the IGP distance to any next hop that is not
	resolved. Any change due to (a) in any of these values MUST trigger		recursively resolved. Any change due to (a) in any of these values
	a new AIGP computation for that route. Whether a change due to (b)		MUST trigger a new AIGP computation for that route. Whether a change
	triggers a new AIGP computation depends upon whether the change in		due to (b) triggers a new AIGP computation depends upon whether the
	IGP distance exceeds a configurable threshold.		change in IGP distance exceeds a configurable threshold.
	If the AIGP attribute is carried across several ASes, each with its		If the AIGP attribute is carried across several ASes, each with its
	own IGP domain, it is clear that these procedures are unlikely to		own IGP domain, it is clear that these procedures are unlikely to
	give a sensible result if the IGPs are different (e.g., some OSPF and		give a sensible result if the IGPs are different (e.g., some OSPF and
	some IS-IS), or if the meaning of the metrics is different in the		some IS-IS), or if the meaning of the metrics is different in the
	different IGPs (e.g., if the metric represents bandwidth in some IGP		different IGPs (e.g., if the metric represents bandwidth in some IGP
	domains but represents latency in others). These procedures also are		domains but represents latency in others). These procedures also are
	unlikely to give a sensible result if the metric assigned to inter-AS		unlikely to give a sensible result if the metric assigned to inter-AS
	BGP links (on which no IGP is running) or to static routes is not		BGP links (on which no IGP is running) or to static routes is not
	comparable to the IGP metrics. All such cases are outside the scope		comparable to the IGP metrics. All such cases are outside the scope
	skipping to change at page 10, line 44		skipping to change at page 11, line 31
	cases, the AIGP attributes of the eliminated routes are not		cases, the AIGP attributes of the eliminated routes are not
	considered.		considered.
	4.1. When a Route has an AIGP Attribute		4.1. When a Route has an AIGP Attribute
	Assuming that the BGP decision process invokes the tie breaking		Assuming that the BGP decision process invokes the tie breaking
	procedures, the procedures in this section MUST be executed BEFORE		procedures, the procedures in this section MUST be executed BEFORE
	any of the tie breaking procedures described in [BGP] section 9.1.2.2		any of the tie breaking procedures described in [BGP] section 9.1.2.2
	are executed.		are executed.
	If any routes have an AIGP attribute, remove from consideration all		If any routes have an AIGP attribute containing an AIGP TLV, remove
	routes that do not have an AIGP attribute.		from consideration all routes that do not have an AIGP attribute
			containing an AIGP TLV.
			If router R is considering route T, where T has an AIGP attribute
			with an AIGP TLV,
	If router R is considering route T, where T has an AIGP attribute,
	- then R must compute the value A, defined as follows: set A to the		- then R must compute the value A, defined as follows: set A to the
	sum of (a) T's AIGP attribute value and (b) the IGP distance from		sum of (a) T's AIGP TLV value and (b) the IGP distance from R to
	R to T's next hop.		T's next hop.
	- remove from consideration all routes that are not tied for the		- remove from consideration all routes that are not tied for the
	lowest value of A.		lowest value of A.
	4.2. When the Route to the Next Hop has an AIGP attribute		4.2. When the Route to the Next Hop has an AIGP attribute
	Suppose that a given router R1 is comparing two BGP-learned routes,		Suppose that a given router R1 is comparing two BGP-learned routes,
	such that either:		such that either:
	- the two routes have equal AIGP attribute values, or else		- the two routes have equal AIGP TLV values, or else
	- neither of the two routes has an AIGP attribute.		- neither of the two routes has an AIGP attribute containing an
			AIGP TLV.
	The BGP decision process as specified in [BGP] makes use, in its tie		The BGP decision process as specified in [BGP] makes use, in its tie
	breaker procedures, of "interior cost", defined as follows:		breaker procedures, of "interior cost", defined as follows:
	"interior cost of a route is determined by calculating the metric		"interior cost of a route is determined by calculating the metric
	to the NEXT_HOP for the route using the Routing Table."		to the NEXT_HOP for the route using the Routing Table."
	Suppose route T has a next hop of N. We modify the notion of the		Suppose route T has a next hop of N. We modify the notion of the
	"interior cost" from node R1 to node N as follows:		"interior cost" from node R1 to node N as follows:
	- Let R2 be the BGP next hop of the route to N, after all recursive		- Let R2 be the BGP next hop of the route to N, after all recursive
	resolution of the next hop is done. Let m be the IGP distance		resolution of the next hop is done. Let m be the IGP distance
	(or in the case of a static route, the configured distance) from		(or in the case of a static route, the configured distance) from
	R1 to R2.		R1 to R2.
	- If the installed route to N has an AIGP attribute, set A to the		- If the installed route to N has an AIGP attribute with an AIGP
	AIGP value of the route to N, computing the AIGP value of the		TLV, set A to the AIGP value of the route to N, computing the
	route according to the procedure of section 3.3.3.		AIGP value of the route according to the procedure of section
			3.4.3.
	- If the installed route to N does not have an AIGP value, set A to		- If the installed route to N does not have an AIGP value, set A to
	0.		0.
	- The "interior cost" of route T is the quantity A+m.		- The "interior cost" of route T is the quantity A+m.
	5. Deployment Considerations		5. Deployment Considerations
	Using the AIGP attribute to achieve a desired routing policy will be		Using the AIGP attribute to achieve a desired routing policy will be
	more effective if each BGP speaker can use it to choose from among		more effective if each BGP speaker can use it to choose from among
	multiple routes. Thus is it highly recommended that the procedures of		multiple routes. Thus is it highly recommended that the procedures of
	[BESTEXT] and [ADDPATH] be used in conjunction with the AIGP		[BESTEXT] and [CONN-REST] be used in conjunction with the AIGP
	Attribute.		Attribute.
	If a Route Reflector does not pass all paths to its clients, then it		If a Route Reflector does not pass all paths to its clients, then it
	will tend to pass the paths for which the IGP distance from the Route		will tend to pass the paths for which the IGP distance from the Route
	Reflector itself to the next hop is smallest. This may result in a		Reflector itself to the next hop is smallest. This may result in a
	non-optimal choice by the clients.		non-optimal choice by the clients.
	6. IANA Considerations		6. IANA Considerations
	IANA has assigned the codepoint 26 in the "BGP Path Attributes"		IANA has assigned the codepoint 26 in the "BGP Path Attributes"
	skipping to change at page 12, line 41		skipping to change at page 13, line 28
	The spurious introduction, though error or malfeasance, of an AIGP		The spurious introduction, though error or malfeasance, of an AIGP
	attribute, could result in the selection of paths other than those		attribute, could result in the selection of paths other than those
	desired.		desired.
	Improper configuration on both ends of an EBGP connection could		Improper configuration on both ends of an EBGP connection could
	result in an AIGP attribute being passed from one service provider to		result in an AIGP attribute being passed from one service provider to
	another. This would likely result in an unsound selection of paths.		another. This would likely result in an unsound selection of paths.
	8. Acknowledgments		8. Acknowledgments
	The authors would like to thank Waqas Alam, Rajiv Asati, Clarence		The authors would like to thank Waqas Alam, Rajiv Asati, Brian
	Filsfils, Robert Raszuk, Yakov Rekhter, Eric Rosenberg, Samir Saad,		Dickson, Clarence Filsfils, Pratima Kini, Thomas Mangin, Robert
	John Scudder, and Shyam Sethuram for their input.		Raszuk, Yakov Rekhter, Eric Rosenberg, Samir Saad, John Scudder,
			Shyam Sethuram, and Ilya Varlashkin for their input.
	9. Authors' Addresses		9. Authors' Addresses
	Rex Fernando		Rex Fernando
	Cisco Systems, Inc.		Cisco Systems, Inc.
	170 Tasman Drive		170 Tasman Drive
	San Jose, CA 95134		San Jose, CA 95134
	Email: rex@cisco.com		Email: rex@cisco.com
	Pradosh Mohapatra		Pradosh Mohapatra
	skipping to change at page 13, line 36		skipping to change at page 14, line 23
	Middletown, NJ 07748		Middletown, NJ 07748
	Email: uttaro@att.com		Email: uttaro@att.com
	10. Normative References		10. Normative References
	[BGP], "A Border Gateway Protocol 4 (BGP-4)", Y. Rekhter, T. Li, S.		[BGP], "A Border Gateway Protocol 4 (BGP-4)", Y. Rekhter, T. Li, S.
	Hares, RFC 4271, January 2006.		Hares, RFC 4271, January 2006.
	11. Informative References		11. Informative References
	[ADDPATH] "Fast Connectivity Restoration Using BGP Add-Path", P.		[CONN-REST] "Fast Connectivity Restoration Using BGP Add-Path", P.
	Mohapatra, R. Fernando, C. Filsfils, R. Raszuk, draft-pmohapat-idr-		Mohapatra, R. Fernando, C. Filsfils, R. Raszuk, draft-pmohapat-idr-
	fast-conn-restore-03.txt, January 2013.		fast-conn-restore-03.txt, January 2013.
	[BESTEXT], "Advertisement of the Best External Route in BGP", P.		[BESTEXT], "Advertisement of the Best External Route in BGP", P.
	Marques, R. Fernando, E. Chen, P. Mohapatra, H. Gredler, draft-ietf-		Marques, R. Fernando, E. Chen, P. Mohapatra, H. Gredler, draft-ietf-
	idr-best-external-05.txt, January 2012.		idr-best-external-05.txt, January 2012.
			[BGP-ERROR] "Revised Error Handling for BGP UPDATE Messages", J.
			Scudder, E. Chen, P. Mohapatra, K. Patel, draft-ietf-idr-error-
			handling-04.txt, June 2013.
	[RFC2119] "Key words for use in RFCs to Indicate Requirement		[RFC2119] "Key words for use in RFCs to Indicate Requirement
	Levels.", S. Bradner, March 1997.		Levels.", S. Bradner, March 1997.
End of changes. 40 change blocks.
	78 lines changed or deleted		125 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/