draft-ietf-idr-custom-decision-06.txt		draft-ietf-idr-custom-decision-07.txt
	Inter-Domain Routing A. Retana		Inter-Domain Routing A. Retana
	Internet-Draft Cisco Systems, Inc.		Internet-Draft Cisco Systems, Inc.
	Intended status: Standards Track R. White		Intended status: Standards Track R. White
	Expires: October 22, 2015 Ericsson		Expires: May 4, 2016 Ericsson
	April 20, 2015		November 1, 2015
	BGP Custom Decision Process		BGP Custom Decision Process
	draft-ietf-idr-custom-decision-06		draft-ietf-idr-custom-decision-07
	Abstract		Abstract
	The BGP specification defines a Decision Process for installation of		The BGP specification describes a Decision Process for selecting the
	routes into the Loc-RIB. This process takes into account an		best route. This process uses a series of steps, made up of path
	extensive series of path attributes, which can be manipulated to		attributes and other values, to first determine the Degree of
	indicate preference for specific paths. It is cumbersome (if at all		Preference of a route and later as tie breakers. While existing
	possible) for the end user to define policies that will select, after		mechanisms may achieve some of the same results described in this
	partial comparison, a path based on subjective local (domain and/or		document, they can only do so through extensive configuration such as
	node) criteria.		matching communities to explicit policy and/or route preference
			configurations present on each BGP speaker within their
			administrative domain (autonomous system). Implementing some
			specific fine grained policies through such mechanisms is cumbersome,
			if even possible.
	This document defines a new Extended Community, called the Cost		This document defines a new Extended Community, called the Cost
	Community, which may be used in tie breaking during the best path		Community, which may be used as part of the Decision Process. The
	selection process. The end result is a local custom decision		end result is a local Custom Decision Process.
	process.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 http://datatracker.ietf.org/drafts/current/.		Drafts is at http://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 October 22, 2015.		This Internet-Draft will expire on May 4, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2015 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
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 21		skipping to change at page 2, line 26
	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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3		2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
	3. The BGP Cost Community . . . . . . . . . . . . . . . . . . . 3		3. The BGP Cost Community . . . . . . . . . . . . . . . . . . . 3
	4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 5		4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 5
	5. Deployment Considerations . . . . . . . . . . . . . . . . . . 5		5. Deployment Considerations . . . . . . . . . . . . . . . . . . 6
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 6		6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6		7.1. Cost Community Point of Insertion Registry . . . . . . . 7
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
	9.1. Normative References . . . . . . . . . . . . . . . . . . 6		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
	9.2. Informative References . . . . . . . . . . . . . . . . . 7		9.1. Normative References . . . . . . . . . . . . . . . . . . 8
	Appendix A. Cost Community Point of Insertion Registry . . . . . 7		9.2. Informative References . . . . . . . . . . . . . . . . . 9
	Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 8		Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 9
	B.1. Changes between the -00 and -01 versions. . . . . . . . . 8		A.1. Changes between the -00 and -01 versions. . . . . . . . . 9
	B.2. Changes between the -01 and -02 versions. . . . . . . . . 8		A.2. Changes between the -01 and -02 versions. . . . . . . . . 10
	B.3. Changes between the -02 and -03 versions. . . . . . . . . 8		A.3. Changes between the -02 and -03 versions. . . . . . . . . 10
	B.4. Changes between the -03 and -04 versions. . . . . . . . . 8		A.4. Changes between the -03 and -04 versions. . . . . . . . . 10
	B.5. Changes between the -04 and -05 versions. . . . . . . . . 9		A.5. Changes between the -04 and -05 versions. . . . . . . . . 10
	B.6. Changes between the -05 and -06 versions. . . . . . . . . 9		A.6. Changes between the -05 and -06 versions. . . . . . . . . 10
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9		A.7. Changes between the -06 and -07 versions . . . . . . . . 10
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
	1. Introduction		1. Introduction
	There are a number of metrics available within the BGP decision		The BGP specification defines a Decision Process [RFC4271] for
	process [RFC4271] which can be used to determine the exit point for		selecting the best route. This process uses a series of steps, made
	traffic, but there is no metric, or combination of metrics, which can		up of path attributes and other values, to first determine the Degree
	be used to break a tie among generally equal paths.		of Preference of a route and later as tie breakers. While existing
			mechanisms may achieve some of the same results described in this
	o LOCAL_PREF: The LOCAL_PREF is an absolute tie breaker near the		document, they can only do so through extensive configuration such as
	beginning of the decision process. There is no way to configure		matching communities to explicit policy and/or route preference
	the LOCAL_PREF such that the MED, IGP metric, and other metrics		configurations present on each BGP speaker within their
	are considered before breaking a tie.		administrative domain (autonomous system). Implementing some
			specific fine grained policies through such mechanisms is cumbersome,
			if even possible. For example:
	o MED: The MULTI_EXIT_DISC is an indicator of which local entrance		o Local Preference: The LOCAL_PREF is an attribute used to calculate
	point an AS would like a peering AS to use; MED isn't suitable to		the Degree of Preference in the Decision Process. There is no
	break the tie between two equal cost paths learned from two peer		secondary degree of preference indicator available that can be
	ASes. MED is also compared before the IGP metric; there is no way		considered after the MED, IGP metric, or other attributes.
	to set the MED so a path with a higher IGP metric is preferred
	over a path with a lower IGP metric.
	o IGP Metric: It is possible, using the IGP metric, to influence		o Multi-Exit Discriminator (MED): The MULTI_EXIT_DISC is an
	individual paths with otherwise equal cost metrics, but only by		indicator of which local entrance point an AS would like a peering
	changing the next hop towards each path, and configuring the IGP		AS to use. As the MED is compared before the IGP metric, there is
	costs of reaching each next hop. This method is cumbersome, and		no way to set the MED so a route with a higher IGP metric is
	prone to confusion and error.		preferred over one with a lower IGP metric.
	The BGP specification defines a Decision Process for installation of		o IGP Metric: It is possible, to influence individual routes, but
	routes into the Loc-RIB. This process takes into account an		only by changing the next hops, and configuring the IGP metric for
	extensive series of path attributes, which can be manipulated to		reaching them. This method is cumbersome and prone to confusion
	indicate preference for specific paths. It is cumbersome (if at all		and error.
	possible) for the end user to define policies that will select, after
	partial comparison, a path based on subjective local (domain and/or
	node) criteria.
	This document defines a new Extended Community, called the Cost		This document defines a new Extended Community [RFC4360], called the
	Community, which may be used in tie breaking during the best path		Cost Community, which may be used as part of the Decision Process.
	selection process. The end result is a custom decision process.		The end result is a local Custom Decision Process.
	2. Requirements Language		2. Requirements Language
	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].
	3. The BGP Cost Community		3. The BGP Cost Community
	The BGP Cost Community is an Opaque Extended Community [RFC4360]		The BGP Cost Community is an Opaque Extended Community [RFC4360]
	defined as follows:		defined as follows:
	Type Field:		Type Field:
	The value of the high-order octet of this Opaque Extended		The value of the high-order octet is determined by provisioning
	Community is 0x03 or 0x43. The value of the low-order octet of		[RFC4360]. IANA has assigned the codepoint value 0x01 to 'Cost
	the extended type field for this community is 0x01.		Community' in both the Transitive Opaque Extended Community Sub-
			Types registry and the Non-Transitive Opaque Extended Community
			Sub-Types registry.
	Value Field:		Value Field:
	The Value field contains three distinct sub-fields, described		The Value field contains three distinct sub-fields, described
	below:		below:
	+------------------------------+		+------------------------------+
	| Point of Insertion (1 octet) |		| Point of Insertion (1 octet) |
	+------------------------------+		+------------------------------+
	| Community-ID (1 octet) |		| Community-ID (1 octet) |
	+------------------------------+		+------------------------------+
	| Cost (4 octets) |		| Cost (4 octets) |
	+------------------------------+		+------------------------------+
	skipping to change at page 4, line 13		skipping to change at page 4, line 16
	below:		below:
	+------------------------------+		+------------------------------+
	| Point of Insertion (1 octet) |		| Point of Insertion (1 octet) |
	+------------------------------+		+------------------------------+
	| Community-ID (1 octet) |		| Community-ID (1 octet) |
	+------------------------------+		+------------------------------+
	| Cost (4 octets) |		| Cost (4 octets) |
	+------------------------------+		+------------------------------+
	The Point of Insertion sub-field contains the value of the path		The Point of Insertion (POI) sub-field indicates *after*, or
	attribute *after* which this community MUST be considered during		*instead of*, which step in the Decision Process the Cost
	the best path selection process.		Community MUST be considered.
	The BGP decision process includes some steps that do not		The value of the POI may reference a path attribute used in the
	correspond to any path attribute; the following values are		Decision Process. In this case the Cost Community is
	defined:		considered after, or instead of, the step where the path
			attribute is considered.
			The Decision Process includes some steps that do not correspond
			to any path attribute; the following values are defined:
	128 ABSOLUTE_VALUE - Indicates that the Cost Community MUST be		128 ABSOLUTE_VALUE - Indicates that the Cost Community MUST be
	considered as the first step in determining the Degree of		considered as the first step in determining the Degree of
	Preference of a path.		Preference of a route (Section 9.1.1 of [RFC4271]). If two
			routes have the same Cost, then the rest of the Calculation
			of Degree of Preference is to be followed.
	129 IGP_COST - Indicates that the Cost Community MUST be		129 IGP_COST - Indicates that the Cost Community MUST be
	considered after the interior (IGP) distance to the next-hop		considered after the interior (IGP) distance to the next-hop
	has been compared.		has been compared.
	130 EXTERNAL_INTERNAL - Indicates that the Cost Community MUST		130 EXTERNAL_INTERNAL - Indicates that the Cost Community MUST
	be considered after the paths advertised by BGP speakers in		be considered after Paragraph d of Section 9.1.2.2 of
	a neighboring autonomous system (if any) have been selected.		[RFC4271].
	131 BGP_ID - Indicates that the Cost Community MUST be		131 BGP_ID - Indicates that the Cost Community MUST be
	considered after the BGP Identifier (or ORIGINATOR_ID		considered after the BGP Identifier (or ORIGINATOR_ID
	[RFC4456]) has been compared.		[RFC4456]) has been compared.
			This document creates a new Cost Community Point of Insertion
			Registry (Section 7.1) that includes the relevant path
			attributes and these other values.
	The Community-ID sub-field contains an identifier to distinguish		The Community-ID sub-field contains an identifier to distinguish
	between multiple instances of the Cost Community. The high-order		between multiple instances of the Cost Community. The high-order
	bit is reserved to indicate that the Cost Community MUST replace		bit indicates that the Cost Community MUST replace the step
	the path attribute specified by the Point of Insertion during the		indicated by the POI in the Decision Process.
	best path selection process.
	The Cost sub-field contains a value assigned by the network		If the high-order bit is set, the Cost in the Cost Community
	administrator and that is significant to the local autonomous		may replace the value of a path attribute at a specific step in
	system. The lower cost MUST be preferred. The default value is		the Decision Process, but not the attribute itself. For
	0x7FFFFFFF (half the maximum value).		example, if the high-order bit is set with the AS_PATH POI, the
			AS_PATH attribute would still be used for loop prevention
			[RFC4271], but the Cost would replace its length in the
			Decision Process.
			The high-order bit MUST be ignored when used with the
			ABSOLUTE_VALUE POI.
			If the Accumulated IGP Metric Attribute (AIGP) [RFC7311] is
			used such that the "AIGP-enhanced interior cost" replaces the
			"interior cost" tie breaker in the Decision Process, and the
			high-order bit is set with the IGP_COST POI, then the Cost
			Community SHOULD be ignored in favor of the process described
			in Section 4.2 of [RFC7311].
			The Cost sub-field is a 32-bit unsigned integer. It contains a
			value assigned by the network administrator that is significant to
			their administrative domain. The default Cost is 0x7FFFFFFF (half
			the maximum).
			If the Cost Community is inserted after a step in the Decision
			Process, and is therefore only compared to other Cost
			Communities, the lower Cost MUST be preferred.
			If the Cost Community replaces a step in the Decision Process,
			it MUST be treated exactly as the value it is replacing would
			be treated. It is up to the network administrator to select
			the appropriate Cost to use when replacing a specific step; the
			method to do that is outside the scope of this document.
	4. Operation		4. Operation
	The network administrator may use the Cost Community to assign a		The network administrator may use the Cost Community to assign a Cost
	value to a path originated or learned from a peer in any part of the		to a route originated, or learned from a peer, in any part of their
	local domain. The Point of Insertion MUST also be specified using		administrative domain. The POI MUST also be specified.
	the values defined in Appendix A.
	If a BGP speaker receives a path that contains the Cost Community, it		If a BGP speaker receives a route that contains the Cost Community,
	SHOULD consider its value at the Point of Insertion specified, when		it MUST consider its Cost at the POI specified, during the Decision
	calculating the best path [RFC4271].		Process.
	If the Point of Insertion is not valid for the local best path		If the POI is not valid for the local Decision Process
	selection implementation, then the Cost Community SHOULD be silently		implementation, then the Cost Community SHOULD be silently ignored.
	ignored. Paths that do not contain the Cost Community (for a valid,
	particular Point of Insertion) MUST be considered to have the default
	value.
	Multiple Cost Communities may indicate the same Point of Insertion.		Multiple Cost Communities may indicate the same POI. All the Cost
	In this case, the Cost Community with the lowest Community-ID is		Communities for a specific POI MUST be considered starting with the
	considered first. In other words, all the Cost Communities for a		one(s) with the lowest Community-ID. If multiple Cost Communities,
	specific Point of Insertion MUST be considered, starting with the one		for the same POI, with the same Community-ID are received for the
	with the lowest Community-ID.		same route from the same peer, then all except the one with the
			lowest Cost MUST be silently ignored.
			Routes that do not contain the Cost Community (for a valid,
			particular POI), or a Community-ID present in a route from another
			peer, MUST be considered to have the default Cost.
	If a range of routes is to be aggregated and the resultant aggregate		If a range of routes is to be aggregated and the resultant aggregate
	path attributes do not carry the ATOMIC_AGGREGATE attribute, then the		path attributes do not carry the ATOMIC_AGGREGATE attribute, then the
	resulting aggregate SHOULD have an Extended Communities path		resulting aggregate SHOULD have an Extended Communities path
	attribute which contains the set union of all the Cost Communities		attribute which contains the set union of all the Cost Communities
	from all of the aggregated routes. If multiple Cost Communities for		from all of the aggregated routes. If multiple Cost Communities for
	the same Point of Insertion (and with the same Community-ID) exist,		the same POI (and with the same Community-ID) exist, then only the
	then only the ones with the highest Cost SHOULD be included.		ones with the highest Cost SHOULD be included.
	If the non-transitive version of a Cost Community is received across		If the non-transitive version of a Cost Community is received across
	an Autonomous System boundary, then the receiver MUST strip it off		an Autonomous System boundary, then the receiver MUST strip it off
	the BGP update, and ignore it when running the selection process.		the BGP update, and ignore it during the Decision Process.
	5. Deployment Considerations		5. Deployment Considerations
	The mechanisms described in this document may be used to modify the		The mechanisms described in this document may be used to modify the
	BGP path selection process arbitrarily. It is important that a		Decision Process arbitrarily. It is important that a consistent
	consistent path selection process be maintained across the local		Decision Process be maintained across the local Autonomous System to
	Autonomous System to avoid potential routing loops. In other words,		avoid potential routing loops. In other words, all the nodes in the
	if the Cost Community is used, all the nodes in the AS that may have		AS that may have to consider the Cost Community at any POI MUST
	to consider this new community at any Point of Insertion SHOULD be		support the mechanisms described in this document.
	aware of the mechanisms described in this document.
	6. Security Considerations
	This document introduces no new security concerns to BGP or other
	specifications referenced in this document.
	7. IANA Considerations
	IANA is asked to assign the type values indicated in Section 3 to the
	Cost Community in the BGP Opaque Extended Community registry
	[BGP_EXT].
	Section 3 also defines a series of values to be used to indicate
	steps in the best path selection process that do not map directly to
	a path attribute. IANA is expected to maintain a registry for the
	Cost Community Point of Insertion values. Values 1 through 127 are
	to be assigned using the "Standards Action" policy or the Early
	Allocation process [RFC7120]. Values 128 through 191 are to be
	assigned using the "IETF Consensus" policy. Values 192 through 254
	are to be assigned using the "First Come First Served" policy.
	Values 0 and 255 are reserved for future use and SHOULD NOT be used.
	All the policies mentioned are documented in [RFC5226].
	Some of the values in this new registry match the values assigned in		Any mechanism which allows the modification of the Decision Process
	the BGP Path Attributes registry [BGP_PAR]. It is RECOMMENDED that		is capable of forming persistent routing loops in the control plane.
	an effort be made to assign the same values in both tables when		Network administrators deploying the Cost Community MUST ensure that
	applicable. The table in Appendix A shows the initial allocations		each impacted router in the network supports them, including the POIs
	for the new Cost Community Point of Insertion registry.		deployed within their network. This is similar in scope to a network
			administrator who uses communities [RFC1997] combined with filters or
			other policies to modify the Decision Process of BGP speakers.
			Consistency must be enforced at an administrative level.
	8. Acknowledgements		6. Security Considerations
	There have been many people who have shown their support and provided		This document defines a new Extended Community, called the Cost
	valuable input, comments and implementations -- the authors would		Community, which may be used to customize the Decision Process. As
	like to thank all of them! We would like to also thank Dan Tappan		such, the considerations outlined in [RFC4360] and [RFC4271] do not
	for the Opaque Extended Community type.		change.
	9. References		To minimize the potential of creating routing loops (Section 5) or
			otherwise affecting the Decision Process in unintended ways, the
			propagation of Cost Communities MUST be disabled by default and MUST
			be explicitly enabled by the network administrator. Furthermore, all
			transitive Cost Communities received across an Autonomous System
			boundary without explicit configuration MUST be stripped off the BGP
			update, and ignored during the Decision Process.
	9.1. Normative References		An ill-designed policy deployment using the Cost Community (e.g. one
			where there is no consistent POI support throughout the AS) may
			result in persistent routing loops that could result in loss of
			traffic. The design and implementation of policies for best route
			selection are outside the scope of this document.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		7. IANA Considerations
	Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended		IANA has assigned the codepoint value 0x01 to 'Cost Community' in
	Communities Attribute", RFC 4360, February 2006.		both the Transitive Opaque Extended Community Sub-Types registry and
			the Non-Transitive Opaque Extended Community Sub-Types registry.
	[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an		Section 3 also defines a series of values to be used to indicate
	IANA Considerations Section in RFCs", BCP 26, RFC 5226,		steps in the Decision Process that do not map directly to a path
	May 2008.		attribute. IANA is expected to maintain a registry for the Cost
			Community POI values.
	[RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code		o Values 1 through 127 are to be assigned using the "Standards
	Points", BCP 100, RFC 7120, January 2014.		Action" policy or the Early Allocation process [RFC7120].
	9.2. Informative References		o Values 128 through 191 are to be assigned using the "IETF
			Consensus" policy.
	[BGP_EXT] Internet Assigned Numbers Authority, "BGP Extended		o Values 192 through 254 are to be assigned using the "First Come
	Communities", 2010, <http://www.iana.org/assignments/		First Served" policy.
	bgp-extended-communities>.
	[BGP_PAR] Internet Assigned Numbers Authority, "BGP Parameters",		o Values 0 and 255 are reserved.
	2010, <http://www.iana.org/assignments/bgp-parameters/>.
	[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway		All the policies mentioned are documented in [RFC5226].
	Protocol 4 (BGP-4)", RFC 4271, January 2006.
	[RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route		The table in Section 7.1 shows the initial allocations for the new
	Reflection: An Alternative to Full Mesh Internal BGP		Cost Community Point of Insertion registry.
	(IBGP)", RFC 4456, April 2006.
	Appendix A. Cost Community Point of Insertion Registry		7.1. Cost Community Point of Insertion Registry
	The tables below document the initial Cost Community Point of		The tables below document the initial Cost Community Point of
	Insertion Registry		Insertion Registry
	+---------+-------------------------+		+---------+-------------------------+
	| Range | Registration Procedure |		| Range | Registration Procedure |
	+---------+-------------------------+		+---------+-------------------------+
	| 0 | Reserved |		| 0 | Reserved |
	| 1-127 | Standards Action |		| 1-127 | Standards Action |
	| 128-191 | IETF Consensus |		| 128-191 | IETF Consensus |
	| 192-254 | First Come First Served |		| 192-254 | First Come First Served |
	| 255 | Reserved |		| 255 | Reserved |
	+---------+-------------------------+		+---------+-------------------------+
	skipping to change at page 8, line 14		skipping to change at page 8, line 25
	+--------+-------------------+--------------------------------+		+--------+-------------------+--------------------------------+
	| Value | Code | Reference |		| Value | Code | Reference |
	+--------+-------------------+--------------------------------+		+--------+-------------------+--------------------------------+
	| 1 | ORIGIN | RFC4271 |		| 1 | ORIGIN | RFC4271 |
	| 2 | AS_PATH | RFC4271 |		| 2 | AS_PATH | RFC4271 |
	| 3 | Unassigned | |		| 3 | Unassigned | |
	| 4 | MULTI_EXIT_DISC | RFC4271 |		| 4 | MULTI_EXIT_DISC | RFC4271 |
	| 5 | LOCAL_PREF | RFC4271 |		| 5 | LOCAL_PREF | RFC4271 |
	| 6-25 | Unassigned | |		| 6-25 | Unassigned | |
	| 26 | AIGP | draft-ietf-idr-aigp |		| 26 | AIGP | RFC7311 |
	| 27-127 | Unassigned | |		| 27-127 | Unassigned | |
	| 128 | ABSOLUTE_VALUE | draft-ietf-idr-custom-decision |		| 128 | ABSOLUTE_VALUE | draft-ietf-idr-custom-decision |
	| 129 | IGP_COST | draft-ietf-idr-custom-decision |		| 129 | IGP_COST | draft-ietf-idr-custom-decision |
	| 130 | EXTERNAL_INTERNAL | draft-ietf-idr-custom-decision |		| 130 | EXTERNAL_INTERNAL | draft-ietf-idr-custom-decision |
	| 131 | BGP_ID | draft-ietf-idr-custom-decision |		| 131 | BGP_ID | draft-ietf-idr-custom-decision |
	+--------+-------------------+--------------------------------+		+--------+-------------------+--------------------------------+
	Point of Insertion Codes		Point of Insertion
	Appendix B. Change Log		8. Acknowledgements
	B.1. Changes between the -00 and -01 versions.		There have been many people who have shown their support and provided
			valuable input, comments and implementations -- the authors would
			like to thank all of them! We would like to also thank Dan Tappan
			for the Opaque Extended Community type. Bruno Decraene and Eric
			Rosen thoroughly reviewed this document and helped improved its
			quality significantly.
			9. References
			9.1. Normative References
			[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
			Requirement Levels", BCP 14, RFC 2119,
			DOI 10.17487/RFC2119, March 1997,
			<http://www.rfc-editor.org/info/rfc2119>.
			[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
			Border Gateway Protocol 4 (BGP-4)", RFC 4271,
			DOI 10.17487/RFC4271, January 2006,
			<http://www.rfc-editor.org/info/rfc4271>.
			[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
			Communities Attribute", RFC 4360, DOI 10.17487/RFC4360,
			February 2006, <http://www.rfc-editor.org/info/rfc4360>.
			[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
			IANA Considerations Section in RFCs", BCP 26, RFC 5226,
			DOI 10.17487/RFC5226, May 2008,
			<http://www.rfc-editor.org/info/rfc5226>.
			[RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code
			Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January
			2014, <http://www.rfc-editor.org/info/rfc7120>.
			[RFC7311] Mohapatra, P., Fernando, R., Rosen, E., and J. Uttaro,
			"The Accumulated IGP Metric Attribute for BGP", RFC 7311,
			DOI 10.17487/RFC7311, August 2014,
			<http://www.rfc-editor.org/info/rfc7311>.
			9.2. Informative References
			[RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities
			Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996,
			<http://www.rfc-editor.org/info/rfc1997>.
			[RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route
			Reflection: An Alternative to Full Mesh Internal BGP
			(IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006,
			<http://www.rfc-editor.org/info/rfc4456>.
			Appendix A. Change Log
			This section is to be removed before publication.
			A.1. Changes between the -00 and -01 versions.
	o Updated authors' contact information.		o Updated authors' contact information.
	o Editorial changes in the "Operations" and "Acknowledgement"		o Editorial changes in the "Operations" and "Acknowledgement"
	sections.		sections.
	B.2. Changes between the -01 and -02 versions.		A.2. Changes between the -01 and -02 versions.
	o Updated authors' contact information.		o Updated authors' contact information.
	o Added text to replace a step in the selection process.		o Added text to replace a step in the selection process.
	o Minor edits.		o Minor edits.
	B.3. Changes between the -02 and -03 versions.		A.3. Changes between the -02 and -03 versions.
	o No changes; just a refresh.		o No changes; just a refresh.
	B.4. Changes between the -03 and -04 versions.		A.4. Changes between the -03 and -04 versions.
	o Updated authors' contact information.		o Updated authors' contact information.
	B.5. Changes between the -04 and -05 versions.		A.5. Changes between the -04 and -05 versions.
	o Updated authors' contact information.		o Updated authors' contact information.
	B.6. Changes between the -05 and -06 versions.		A.6. Changes between the -05 and -06 versions.
	o Updated RFC 7120 reference (from RFC 4020).		o Updated RFC 7120 reference (from RFC 4020).
			A.7. Changes between the -06 and -07 versions
			o The review from Bruno Decraene and Eric Rosen resulted in several
			important changes related to the clarity and consistency of the
			document.
			o Added considerations for co-existence with AIGP.
			o Security Considerations.
	Authors' Addresses		Authors' Addresses
	Alvaro Retana		Alvaro Retana
	Cisco Systems, Inc.		Cisco Systems, Inc.
	7025 Kit Creek Rd.		7025 Kit Creek Rd.
	Research Triangle Park, NC 27709		Research Triangle Park, NC 27709
	USA		USA
	Email: aretana@cisco.com		Email: aretana@cisco.com
	Russ White		Russ White
	Ericsson		Ericsson
			Apex, NC 27539
			USA
	Email: russw@riw.us		Email: russw@riw.us
End of changes. 56 change blocks.
	170 lines changed or deleted		264 lines changed or added
This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/