draft-ietf-idr-aigp-15.txt		draft-ietf-idr-aigp-16.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: July 31, 2014 Rex Fernando		Expires: September 25, 2014 Rex Fernando
	Eric C. Rosen		Eric C. Rosen
	Cisco Systems, Inc.		Cisco Systems, Inc.
	James Uttaro		James Uttaro
	ATT		ATT
	January 31, 2014		March 25, 2014
	The Accumulated IGP Metric Attribute for BGP		The Accumulated IGP Metric Attribute for BGP
	draft-ietf-idr-aigp-15.txt		draft-ietf-idr-aigp-16.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 21		skipping to change at page 3, line 21
	3.2 Handling a Malformed AIGP Attribute ................... 6		3.2 Handling a Malformed AIGP Attribute ................... 6
	3.3 Restrictions on Sending/Receiving ..................... 7		3.3 Restrictions on Sending/Receiving ..................... 7
	3.4 Creating and Modifying the AIGP Attribute ............. 7		3.4 Creating and Modifying the AIGP Attribute ............. 7
	3.4.1 Originating the AIGP Attribute ........................ 7		3.4.1 Originating the AIGP Attribute ........................ 7
	3.4.2 Modifications by the Originator ....................... 9		3.4.2 Modifications by the Originator ....................... 9
	3.4.3 Modifications by a Non-Originator ..................... 9		3.4.3 Modifications by a Non-Originator ..................... 9
	4 Decision Process ...................................... 11		4 Decision Process ...................................... 11
	4.1 When a Route 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		4.2 When the Route to the Next Hop has an AIGP attribute .. 12
	5 Deployment Considerations ............................. 13		5 Deployment Considerations ............................. 13
	6 IANA Considerations ................................... 13		6 IANA Considerations ................................... 14
	7 Security Considerations ............................... 13		7 Security Considerations ............................... 14
	8 Acknowledgments ....................................... 14		8 Acknowledgments ....................................... 14
	9 Authors' Addresses .................................... 14		9 Authors' Addresses .................................... 14
	10 Normative References .................................. 15		10 Normative References .................................. 15
	11 Informative References ................................ 15		11 Informative References ................................ 15
	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].
	skipping to change at page 6, line 33		skipping to change at page 6, line 33
	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
	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 other
	that do not use tunneling is outside the scope of this document.		scenarios 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. Handling a Malformed AIGP Attribute		3.2. Handling a Malformed AIGP Attribute
	When receiving a BGP Update message containing a malformed AIGP		When receiving a BGP Update message containing a malformed AIGP
	attribute, the attribute MUST be treated exactly as if it were an		attribute, the attribute MUST be treated exactly as if it were an
	unrecognized non-transitive attribute. That is, "it MUST be quietly		unrecognized non-transitive attribute. That is, "it MUST be quietly
	skipping to change at page 13, line 8		skipping to change at page 13, line 8
	an AIGP TLV, set A to 0.		an AIGP TLV, set A to 0.
	- The "AIGP-enhanced interior cost" of route T is the quantity A+m.		- The "AIGP-enhanced interior cost" of route T is the quantity A+m.
	The "interior cost" tie breaker of [BGP] is then applied, but using		The "interior cost" tie breaker of [BGP] is then applied, but using
	the "AIGP-enhanced interior cost" instead of the "interior cost" as		the "AIGP-enhanced interior cost" instead of the "interior cost" as
	defined in [BGP].		defined in [BGP].
	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
	more effective if each BGP speaker can use it to choose from among		be more effective if each BGP speaker can use it to choose from
	multiple routes. Thus is it highly recommended that the procedures of		among multiple routes. Thus is it highly recommended that the
	[BESTEXT] and [ADD-PATH] be used in conjunction with the AIGP		procedures of [BESTEXT] and [ADD-PATH] be used in conjunction
	Attribute.		with the AIGP 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
	will tend to pass the paths for which the IGP distance from the Route		it will tend to pass the paths for which the IGP distance from
	Reflector itself to the next hop is smallest. This may result in a		the Route Reflector itself to the next hop is smallest. This may
	non-optimal choice by the clients.		result in a non-optimal choice by the clients.
			- When the procedures of this document are deployed, it must be
			understood that frequent changes of the IGP distance towards a
			certain prefix may result in equally frequent transmission of BGP
			updates about that prefix.
			- In an IGP deployment, there are certain situations in which a
			network link may be temporarily assigned a metric whose value is
			the maximum metric value (or close to the maximum) for that IGP.
			This is known as "costing out" the link. A link may be "costed
			out" to deflect traffic from the link before the link is actually
			brought down, or to discourage traffic from using a link until
			all the necessary state for that link has been set up (e.g.,
			[LDP-IGP-SYNC]). This assumes of course that a path containing a
			"costed out" link will have a total distance that is larger than
			any alternate path within the same IGP area; in that case the
			normal IGP decision process will choose the path that does not
			contain the costed out link.
			Costing out a link will have the same effect on BGP routes that
			carry the AIGP attribute. The value of the AIGP TLV will be
			larger for a route (to a given prefix) that contains a "costed
			out" link than for a route (to the same prefix) that does not.
			It must be understood though that a route that carries an AIGP
			attribute will be preferred to a route that does not, no matter
			what the value of the AIGP TLV is. This is similar to the
			behavior in, e.g., an OSPF area, where an intra-area route is
			preferred to an inter-area or external route, even if the intra-
			area route's distance is large.
	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"
	registry to the AIGP attribute.		registry to the AIGP attribute.
	IANA shall create a registry for "BGP AIGP Attribute Types". The		IANA shall create a registry for "BGP AIGP Attribute Types". The
	type field consists of a single octet, with possible values from 1 to		type field consists of a single octet, with possible values from 1 to
	255. (The value 0 is "reserved".) The allocation policy for this		255. (The value 0 is "reserved".) The allocation policy for this
	field is to be "Standards Action". Type 1 should be defined as		field is to be "Standards Action". Type 1 should be defined as
	skipping to change at page 14, line 7		skipping to change at page 14, 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, Ron Bonica,		The authors would like to thank Waqas Alam, Rajiv Asati, Alia Atlas,
	Bruno Decraene, Brian Dickson, Clarence Filsfils, Anoop Kapoor,		Ron Bonica, Bruno Decraene, Brian Dickson, Clarence Filsfils, Anoop
	Pratima Kini, Sue Hares, Thomas Mangin, Robert Raszuk, Yakov Rekhter,		Kapoor, Pratima Kini, Sue Hares, Thomas Mangin, Robert Raszuk, Yakov
	Eric Rosenberg, Samir Saad, John Scudder, Shyam Sethuram, and Ilya		Rekhter, Eric Rosenberg, Samir Saad, John Scudder, Shyam Sethuram,
	Varlashkin for their input.		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 15, line 22		skipping to change at page 15, line 33
	[ADD-PATH] "Advertisement of Multiple Paths in BGP", D. Walton, A.		[ADD-PATH] "Advertisement of Multiple Paths in BGP", D. Walton, A.
	Retana, E. Chen, J. Scudder, draft-ietf-idr-add-paths-09.txt, October		Retana, E. Chen, J. Scudder, draft-ietf-idr-add-paths-09.txt, October
	2013.		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.		[BGP-ERROR] "Revised Error Handling for BGP UPDATE Messages", J.
	Scudder, E. Chen, P. Mohapatra, K. Patel, draft-ietf-idr-error-		Scudder, E. Chen, P. Mohapatra, K. Patel, draft-ietf-idr-error-
	handling-04.txt, June 2013.		handling-06.txt, February 2014.
			[LDP-IGP-SYNC] "LDP IGP Synchronization", M. Jork, A. Atlas, L. Fang,
			RFC 5443, March 2009.
	[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. 9 change blocks.
	22 lines changed or deleted		54 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/