draft-ietf-idr-aigp-03.txt		draft-ietf-idr-aigp-04.txt
	Network Working Group Pradosh Mohapatra		Network Working Group Pradosh Mohapatra
	Internet Draft Rex Fernando		Internet Draft Rex Fernando
	Intended Status: Proposed Standard Eric C. Rosen		Intended Status: Proposed Standard Eric C. Rosen
	Expires: October 16, 2010 Cisco Systems, Inc.		Expires: April 8, 2011 Cisco Systems, Inc.
	James Uttaro		James Uttaro
	ATT		ATT
	April 16, 2010		October 8, 2010
	The Accumulated IGP Metric Attribute for BGP		The Accumulated IGP Metric Attribute for BGP
	draft-ietf-idr-aigp-03.txt		draft-ietf-idr-aigp-04.txt
			Abstract
			Routing protocols that have been designed to run within a single
			administrative domain ("IGPs") generally do so by assigning a metric
			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
			each link along the path) is minimized. BGP, designed to provide
			routing over a large number of independent administrative domains
			("autonomous systems"), does not make its path selection decisions
			through the use of a metric. It is generally recognized that any
			attempt to do so would incur significant scalability problems, as
			well as inter-administration coordination problems. However, there
			are deployments in which a single administration runs several
			contiguous BGP networks. In such cases, it can be desirable, within
			that single administrative domain, for BGP to select paths based on a
			metric, just as an IGP would do. The purpose of this document is to
			provide a specification for doing so.
	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.		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), 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.
	skipping to change at page 2, line 9		skipping to change at page 3, line 5
	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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	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.
	Abstract
	Routing protocols that have been designed to run within a single
	administrative domain ("IGPs") generally do so by assigning a metric
	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
	each link along the path) is minimized. BGP, designed to provide
	routing over a large number of independent administrative domains
	("autonomous systems"), does not make its path selection decisions
	through the use of a metric. It is generally recognized that any
	attempt to do so would incur significant scalability problems, as
	well as inter-administration coordination problems. However, there
	are deployments in which a single administration runs several
	contiguous BGP networks. In such cases, it can be desirable, within
	that single administrative domain, for BGP to select paths based on a
	metric, just as an IGP would do. The purpose of this document is to
	provide a specification for doing so.
	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 Restrictions on Sending/Receiving ..................... 6
	3.3 Creating and Modifying the AIGP Attribute ............. 7		3.3 Creating and Modifying the AIGP Attribute ............. 7
	3.3.1 Originating the AIGP Attribute ........................ 7		3.3.1 Originating the AIGP Attribute ........................ 7
	3.3.2 Modifications by the Originator ....................... 7		3.3.2 Modifications by the Originator ....................... 8
	3.3.3 Modifications by a Non-Originator ..................... 8		3.3.3 Modifications by a Non-Originator ..................... 8
	4 Decision Process ...................................... 9		4 Decision Process ...................................... 10
	4.1 When a Route has an AIGP Attribute .................... 10		4.1 When a Route has an AIGP Attribute .................... 10
	4.2 When the Route to the Next Hop has an AIGP attribute .. 10		4.2 When the Route to the Next Hop has an AIGP attribute .. 11
	5 Deployment Considerations ............................. 11		5 Deployment Considerations ............................. 12
	6 IANA Considerations ................................... 11		6 IANA Considerations ................................... 12
	7 Security Considerations ............................... 11		7 Security Considerations ............................... 12
	8 Acknowledgments ....................................... 12		8 Acknowledgments ....................................... 12
	9 Authors' Addresses .................................... 12		9 Authors' Addresses .................................... 13
	10 Normative References .................................. 13		10 Normative References .................................. 13
	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 4, line 44		skipping to change at page 4, line 42
	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.		within that same administrative domain. We will refer to the set of
			ASes in a common administrative domain as an "AIGP Administrative
			Domain".
	There are in fact some implementations which already do something		There are in fact some implementations that already do something like
	like this, using the MULTI_EXIT_DISC (MED) attribute to carry the IGP		this, using BGP's MULTI_EXIT_DISC (MED) attribute to carry a value
	metric. However, that doesn't really provide IGP-like "shortest		based on IGP metrics. However, that doesn't really provide IGP-like
	path" routing, as the BGP decision process gives priority to other		"shortest path" routing, as the BGP decision process gives priority
	factors, such as LOCAL_PREF and 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 the administrative domain boundaries into the Internet.		out" past an AIGP administrative domain boundary into the Internet.
	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 to be assigned by		The attribute type code for the AIGP Attribute is to be assigned by
	skipping to change at page 7, line 9		skipping to change at page 7, line 9
	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.3. Creating and Modifying the AIGP Attribute
	3.3.1. Originating the AIGP Attribute		3.3.1. Originating the AIGP Attribute
			An implementation that supports the AIGP attribute MUST support a
			configuration item, AIGP_ORIGINATE, that enables or disables its
			creation and attachment to routes. The default value of
			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 AS to which the BGP speaker belongs. It may be		leads outside the "AIGP administrative domain" to which the BGP
	added only to routes that satisfy one of the following conditions:		speaker belongs. It may be added only to routes that satisfy one of
			the following conditions:
	- The route is a static route that is being redistributed into BGP		- The route is a static route that is being redistributed into BGP
	- The route is an IGP route that is being redistributed into BGP		- The route is an IGP route that is being redistributed into BGP
	- The route is an IBGP-learned route whose AS_PATH attribute is		- The route is an IBGP-learned route whose AS_PATH attribute is
	empty.		empty.
	An implementation that supports the AIGP attribute MUST support a		- The route is an EBGP-learned route whose AS_PATH contains only
	configuration item, AIGP_ORIGINATE, that enables or disables its		ASes that are in the same AIGP Administrative Domain as the BGP
	creation and attachment to routes. The default value of		speaker.
	AIGP_ORIGINATE MUST be "disabled".
			A BGP speaker MUST NOT add the AIGP attribute to any route for which
			it has 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").		particular IGP" might be "OSPF" or "ISIS"). Other policies
			determining when and whether to originate an AIGP attribute are also
			possible, depending on the needs of a particular deployment scenario.
	When a BGP speaker R learns a route to address prefix P from an IGP,		When originating an AIGP attribute for a BGP route to address prefix
	the IGP will have computed a "distance" from R to P. The value		P, the value of the attribute is set according to policy. There are
	assigned to the AIGP attribute is either the IGP-computed distance,		a number of useful policies, some of which are in the following list:
	or some other value determined by policy.
	In the case of a static route whose next hop matches a BGP route that		- When a BGP speaker is redistributing into BGP an IGP route to
	has an AIGP attribute, the static route MAY inherit the AIGP		address prefix P, the IGP will have computed a "distance" from R
	attribute value of that BGP route.		to P. This distance MAY be assigned as the value of AIGP
			attribute.
			- A BGP speaker may be redistributing into BGP a static route to
			address prefix P, for which a "distance" from R to P has been
			configured. This distance MAY be assigned as the value of AIGP
			attribute.
			- 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
			a static route to P, with next hop N. The "distance" from R to N
			MAY be assigned as the value of the AIGP attribute of the route
			to P.
			* If R has an IGP route to N, the IGP-computed distance from R
			to N MAY be used.
			* If R has a BGP route to N, and an AIGP attribute value has
			been computed for that route (see section 3.3.3), that value
			MAY be used as the AIGP attribute value of the route to P.
	3.3.2. Modifications by the Originator		3.3.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 a		and at some point the "distance" from R to P changes, R SHOULD issue
	new BGP update containing the new value of the AIGP attribute.		a new BGP update containing the new value of the AIGP attribute.
	However, if the difference between the new distance and the distance		(Here we use the term "distance" to refer to whatever value the
	advertised in the AIGP attribute is less than a configurable		originator assigns to the AIGP attribute, however it is computed; see
	threshold, the update MAY be suppressed.		section 3.3.1.) However, if the difference between the new distance
			and the distance advertised in the AIGP attribute is less than a
			configurable threshold, the update MAY be suppressed.
	3.3.3. Modifications by a Non-Originator		3.3.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.
	skipping to change at page 8, line 34		skipping to change at page 9, line 11
	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 metric 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 attribute value needs to
	be increased in several steps:		be increased in several steps, according to the following procedure.
			(Note that this procedure is ONLY used when recursive next hop
			resolution is needed.)
	1. Let Xattr be the new AIGP attribute 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. If D is above a		resolution, get the distance D from R1 to XNH. (Note that this
	configurable threshold, set the AIGP attribute value to		condition cannot be satisfied the first time through this
	Xattr+D. If D is below a configurable threshold, set the AIGP		procedure.) If D is above a configurable threshold, set the
	attribute value to Xattr. In either case, exit this procedure.		AIGP attribute value to Xattr+D. If D is below a configurable
			threshold, set the AIGP attribute value to Xattr. In either
			case, 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.
	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 attribute value of Y, then set Xattr=Xattr+Y, and set
	XNH to the next hop of this route. (The intention here is that		XNH to the next hop of this route. (The intention here is that
	Y is the AIGP value of the route as it was received by R1,		Y is the AIGP value of the route as it was received by R1,
	without having been modified by R1.)		without having been modified by R1.)
	skipping to change at page 9, line 25		skipping to change at page 9, line 51
	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 value of a given route depends on (a) the AIGP values of all
	the next hops that are recursively resolved during this procedure,		the next hops that are recursively resolved during this procedure,
	and (b) the IGP distance to any next hop that is not recursively		and (b) the IGP distance to any next hop that is not recursively
	resolved. Any change due to (a) in any of these values MUST trigger		resolved. Any change due to (a) in any of these values MUST trigger
	a new AIGP computation for that route. Whether a change due to (b)		a new AIGP computation for that route. Whether a change due to (b)
	triggers a new AIGP computation depends upon whether the change in		triggers a new AIGP computation depends upon whether the change in
	IGP distance exceeds a configurable threshold.		IGP distance exceeds a configurable threshold.
	Note that the overall shortest path may not be selected if the next
	hop has to be recursively resolved more than once.
	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
	of the current document.		of the current document.
	skipping to change at page 10, line 22		skipping to change at page 11, line 4
	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, remove from consideration all
	routes that do not have an AIGP attribute.		routes that do not have an AIGP attribute.
	If router R is considering route T, where T has an AIGP attribute,		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 attribute value and (b) the IGP distance from
	R to T's next hop.		R to 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 routes, neither of		Suppose that a given router R1 is comparing two BGP-learned routes,
	which has an AIGP attribute. The BGP decision process as specified		such that either:
	in [BGP] makes use, in its tie breaker procedures, of "interior
	cost", defined as follows:
	"interior cost of a route is determined by calculating the metric		- the two routes have equal AIGP attribute values, or else
	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		- neither of the two routes has an AIGP attribute. The BGP
	"interior cost" from node R to node N as follows:		decision process as specified in [BGP] makes use, in its tie
			breaker procedures, of "interior cost", defined as follows:
	- If the route to N has an AIGP attribute, set A to the AIGP value		"interior cost of a route is determined by calculating the
	of the route to N, computing the AIGP value of the route		metric to the NEXT_HOP for the route using the Routing
	according to the procedure of section 3.3.3. (This will have		Table."
	been computed at the time the route to N was installed.)
	- If the route to N does not have an AIGP value, set A to 0. (This		Suppose route T has a next hop of N. We modify the notion of the
	can only be the case if there is no route to N that does have an		"interior cost" from node R1 to node N as follows:
	AIGP value.)
	- Let R2 be the next hop of the route to N, after all recursive		- Let R2 be the 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
			AIGP value of the route to N, computing the AIGP value of the
			route according to the procedure of section 3.3.3.
			- If the installed route to N does not have an AIGP value, set A to
			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 [ADDPATH] be used in conjunction with the AIGP
	Attribute.		Attribute.
	skipping to change at page 13, line 18		skipping to change at page 14, line 13
	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.		[ADDPATH] "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-00.txt, September 2008.		fast-conn-restore-00.txt, September 2008.
	[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, draft-ietf-idr-best-		Marques, R. Fernando, E. Chen, P. Mohapatra, draft-ietf-idr-best-
	external-01.txt, February 2010.		external-02.txt, August 2010.
	[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. 30 change blocks.
	80 lines changed or deleted		115 lines changed or added
This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/