< draft-lapukhov-bgp-ecmp-considerations-02.txt		draft-lapukhov-bgp-ecmp-considerations-03.txt >
	Network Working Group P. Lapukhov		IDR Working Group P. Lapukhov
	Internet-Draft Facebook		Internet-Draft Facebook
	Intended status: Informational J. Tantsura		Intended status: Informational J. Tantsura
	Expires: January 2, 2020 Apstra, Inc.		Expires: May 6, 2020 Apstra, Inc.
	July 1, 2019		November 3, 2019
	Equal-Cost Multipath Considerations for BGP		Equal-Cost Multipath Considerations for BGP
	draft-lapukhov-bgp-ecmp-considerations-02		draft-lapukhov-bgp-ecmp-considerations-03
	Abstract		Abstract
	BGP (Border Gateway Protocol) [RFC4271] employs tie-breaking logic to		BGP (Border Gateway Protocol) [RFC4271] employs tie-breaking logic to
	select a single best path among multiple paths available, known as		select a single best path among multiple paths available, known as
	BGP best path selection. At the same time, it is a common practice		BGP best path selection. At the same time, it has become a common
	to allow for "equal-cost multipath" (ECMP) selection and programming		practice to allow for "equal-cost multipath" (ECMP) selection and
	of multiple next-hops in routing tables. This document summarizes		programming of multiple next-hops in routing tables. This document
	some common considerations for the ECMP logic when BGP is used as the		summarizes some common considerations for the ECMP logic when BGP is
	routing protocol, with the intent of providing common reference for		used as the routing protocol, with the intent of providing common
	otherwise unstandardized set of features.		reference for otherwise unstandardized set of features.
	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 https://datatracker.ietf.org/drafts/current/.		Drafts is at https://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 January 2, 2020.		This Internet-Draft will expire on May 6, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 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
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://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 20 ¶		skipping to change at page 2, line 20 ¶
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. AS-PATH attribute comparison . . . . . . . . . . . . . . . . 2		2. AS-PATH attribute comparison . . . . . . . . . . . . . . . . 2
	3. Multipath among eBGP-learned paths . . . . . . . . . . . . . 3		3. Multipath among eBGP-learned paths . . . . . . . . . . . . . 3
	4. Multipath among iBGP learned paths . . . . . . . . . . . . . 3		4. Multipath among iBGP learned paths . . . . . . . . . . . . . 3
	5. Multipath among eBGP and iBGP paths . . . . . . . . . . . . . 4		5. Multipath among eBGP and iBGP paths . . . . . . . . . . . . . 4
	6. Multipath with AIGP . . . . . . . . . . . . . . . . . . . . . 5		6. Multipath with AIGP . . . . . . . . . . . . . . . . . . . . . 5
	7. Best path advertisement . . . . . . . . . . . . . . . . . . . 5		7. Best path advertisement . . . . . . . . . . . . . . . . . . . 5
	8. Multipath and non-deterministic tie-breaking . . . . . . . . 5		8. Multipath and non-deterministic tie-breaking . . . . . . . . 5
	9. Weighted equal-cost multipath . . . . . . . . . . . . . . . . 5		9. Weighted equal-cost multipath . . . . . . . . . . . . . . . . 5
	10. Informative References . . . . . . . . . . . . . . . . . . . 5		10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6		11. Informative References . . . . . . . . . . . . . . . . . . . 6
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
	1. Introduction		1. Introduction
	Section 9.1.2.2 of [RFC4271] defines step-by-step tie-breaking		Section 9.1.2.2 of [RFC4271] defines step-by-step tie-breaking
	procedure for selecting a single "best-path" among multiple		procedure for selecting a single "best-path" among multiple
	alternatives available for the same route. In order to improve		alternatives available for the same route. In order to improve
	efficiency in densely meshed symmetric network topologies it is		efficiency, in densely meshed symmetric network topologies is has
	common to allow the selection of multiple "equal cost" paths for the		become a common practice to allow selection of multiple "equal" paths
	same route. Typical approach is to abort the tie-breaking process		for the same route. Most commonly used approach is to abort the tie-
	after comparing IGP cost for the NEXT_HOP attribute and select either		breaking process after comparing IGP cost for the NEXT_HOP attribute
	all eBGP or all iBGP paths that remained "equal" under the tie-		and selecting either all eBGP or all iBGP paths that remained "equal"
	breaking rules. See [BGPMP] for a vendor document explaining the		under the tie-breaking rules (see [BGPMP] for a vendor document
	logic. In a nutshell, the steps that compare the BGP identifiers and		explaining the logic). Basically, the steps that compare the BGP
	BGP peer IP addresses (steps (f) and (g) in [RFC4271]) are ignored		identifiers and BGP peer IP addresses (steps (f) and (g) in
	for the purpose of multipath routing. BGP implementations commonly		[RFC4271]) are ignored for the purpose of multipath routing. BGP
	have a configuration knob that specifies the maximum number of equal		implementations commonly have a configuration knob that specifies the
	paths that are allowed be programmed in the routing table. Commonly,		maximum number of equal paths that are allowed be programmed in the
	there's also a knob to enable multipath separately for iBGP-learned		routing table. Commonnly, there's also a knob to enable multipath
	or eBGP-learned paths.		separately for iBGP-learned or eBGP-learned paths.
	2. AS-PATH attribute comparison		2. AS-PATH attribute comparison
	The mandatory requirement for all paths that are considered as the		The mandatory requirement for all paths that are considered as the
	candidates for ECMP selection is to have the same AS_PATH length,		candidates for ECMP selection is to have the same AS_PATH length,
	computed using the logic defined in [RFC4271] and [RFC5065], i.e.		computed using the logic defined in [RFC4271] and [RFC5065], i.e.
	ignoring the AS_SET, AS_CONFED_SEQUENCE, and AS_CONFED_SET segment		ignoring the AS_SET, AS_CONFED_SEQUENCE, and AS_CONFED_SET segment
	lengths. The content of the latter attributes is used purely for		lengths. The content of the latter attributes is used purely for
	routing loop prevention. Assuming that AS_PATHs length computed in		loop detection and prevention. Assuming that AS_PATHs length
	this fashion are the same, many implementations require that the		computed in this fashion are the same, many implementations require
	content of AS_SEQUENCE segment MUST be the same among all the paths		that the content of AS_SEQUENCE segment MUST be the same among all
	considered. Two common configuration knobs to alter this behaviour		the paths considered. Two common configuration knobs to alter this
	are usually provided: First one, to relax the otherwise mandatory		behaviour are usually provided: One, to relax otherwise mandatory
	AS_SEQUENCE comparison rule, enforcing only the AS_PATH length rule,		AS_SEQUENCE comparison rule, enforcing only the AS_PATH length rule,
	while ignoring the content of AS_SEQUENCE. Another one requiring		while ignoring the content of AS_SEQUENCE. And another requiring
	that the first AS numbers in the first AS_SEQUENCE segment found in		that the first AS numbers in first AS_SEQUENCE segment found in
	AS_PATH (often referred to as "peer AS" number) be the same as the		AS_PATH (often referred to as "peer AS" number) be the same as the
	one found in best path (as determined by running the full tie-		one found in best path (determined by running the full tie-breaking
	breaking procedure). This document refers to those two as "multipath		procedure). This document refers to those two as "multipath as-path
	as-path relaxed" and "multipath same peer-as" correspondingly.		relaxed" and "multipath same peer-as".
	3. Multipath among eBGP-learned paths		3. Multipath among eBGP-learned paths
	Step (d) in Section 9.1.2.2 of [RFC4271] mandates, in presence of an		Step (d) in Section 9.1.2.2 of [RFC4271] mandates, in presence of an
	eBGP path, to remove all iBGP paths from the the ECMP candidates set.		eBGP path to remove all iBGP paths from the the ECMP candidates set.
	This leaves the BGP tie-breaking procedure with just eBGP paths. At		This leaves the BGP tie-breaking procedure with just eBGP paths. At
	this point, the mandatory BGP NEXT_HOP attribute value most commonly		this point, the mandatory BGP NEXT_HOP attribute value most commonly
	belongs to the IP subnet that the BGP speaker shares with the		belongs to the IP subnet that the BGP speaker shares with the
	advertising neighbor. In this case, it is common for implementations		advertising neighbor. In this case, it is common for implementations
	to treat all NEXT_HOP values as having the same "internal cost" to		to treat all NEXT_HOP values as having the same "internal cost" to
	reach them per the guidance of step (e) of Section 9.1.2.2. In some		reach them per the guidance of step (e) of Section 9.1.2.2. In some
	cases, either static routing or an IGP routing protocol could be used		cases, either static routing or an IGP routing protocol could be
	between the BGP speakers peering using an eBGP session. An		running between the BGP speakers peering over eBGP session. An
	implementation may use the next-hop metric discovered from the above		implementation may use the metric discovered from the above sources
	sources to perform tie-breaking even for eBGP paths.		to perform tie-breaking even for eBGP paths.
	If the MED attribute is present in some paths, the set of multipath		Notice that in case when, in some paths MED attribute is present, the
	routes allowed will most likely be reduced to the ones coming from		set of multipath routes allowed will most likely be reduced to the
	the same peer AS, per step (c) of Section 9.1.2.2. This is unless an		ones coming from the same peer AS, per step (c) of Section 9.1.2.2.
	implementation provides a configuration knob to always compare MED		This is unless an implementation provides a configuration knob to
	attributes across all paths, as recommended by [RFC4451]. In the		always compare MED attributes across all paths, as recommended by
	latter case, the presence of the MED attribute does not automatically		[RFC4451]. In the latter case, the presence of MED attribute does
	reduce the candidate path set to the same peer AS only.		not automatically reduce the candidate path set to the same peer AS
			only.
	4. Multipath among iBGP learned paths		4. Multipath among iBGP learned paths
	In most cases iBGP is used along with an underlying IGP. Thus, when		When all paths for a prefix are learned via iBGP, since in most cases
	all paths for a prefix are learned via iBGP, the tie-breaking		iBGP is used along with an underlying IGP, the tie-breaking commonly
	commonly occurs based on IGP metric of the NEXT_HOP attribute. In		occurs based on IGP metric of the NEXT_HOP attribute. In some
	some implementations, it is possible to ignore the IGP cost as well,		implementations, it is however possible to ignore the IGP cost as
	if all of the paths are reachable via some kind of tunneling		well, if all of the paths are reachable via some kind of tunneling
	mechanism, such as MPLS [RFC3031]. This is enabled via a knob		mechanism, such as MPLS [RFC3031]. This is enabled via a knob
	referred in this document as "skip igp check" . Notice that there is		referred in this document as "skip igp check" . Notice that there is
	no standard way for a BGP speaker to detect presence of such		no standard way for a BGP speaker to detect presence of such
	tunneling techniques other than relying on the configuration		tunneling techniques other than relying on the configuration
	settings.		settings.
	When iBGP is deployed with BGP route-reflectors per [RFC4456], the		When iBGP is deployed with BGP route-reflectors per [RFC4456] the
	path attribute list may include the CLUSTER_LIST attribute. Many		path attribute list may include the CLUSTER_LIST attribute. Most
	implementations ignore it for the purpose of ECMP route selection,		implementations commonly ignore it for the purpose of ECMP route
	assuming that IGP cost along should be sufficient for loop		selection, assuming that IGP cost along should be sufficient for loop
	prevention. This assumption may not hold when IGP is not deployed,		prevention. This assumption may not hold when IGP is not deployed,
	and instead iBGP session are configured to reset the NEXT_HOP		and instead iBGP session are configured to reset the NEXT_HOP
	attribute to "self" on every node. This also assumes the use of		attribute to self on every node (this also assumes the use of
	directly connected link addresses for session formation. In this		directly connected link addresses for session formation). In this
	case, ignoring CLUSTER_LIST length might lead to routing loops. It		case, ignoring CLUSTER_LIST length might lead to routing loops. It
	is therefore recommended for implementations to have a knob that		is therefore recommended for implementations to have a knob that
	enables accounting for CLUSTER_LIST length when performing multipath		enables accounting for CLUSTER_LIST length when performing multipath
	route selection. Effectively, the CLUSTER_LIST attribute length		route selection. In this case, CLUSTER_LIST attribute length should
	should be as an IGP metric.		be effectively used to replace the IGP metric.
	Similarly to the route-reflector scenario, the use of BGP		Similarly to the route-reflector scenario, the use of BGP
	confederations in multipath scenarios assumes presence of an IGP for		confederations in multipath scenarios assumes presence of an IGP for
	proper loop prevention and use the IGP metric as the final tie-		proper loop prevention and use the IGP metric as the final tie-
	breaker for multipath routing. In addition to that, and similar to		breaker for multipath routing. In addition to that, and similar to
	eBGP case, implementations often require that in order to be		eBGP case, implementations often require that in order to be
	considered equal, the paths must belong to the same peer member AS as		considered equal, paths under consideration must belong to the same
	the best-path. It is useful to have the following two configuration		peer member AS as the best-path. It is useful to have the following
	knobs. First one enabling "multipath same confederation member peer-		two configuration knobs, one enabling "multipath same confederation
	as", and another enabling less restrictive "confed as-path multipath		member peer-as" and another enabling less restrictive "confed as-path
	relaxed" rule, that allow selecting multipath routes reachable via		multipath relaxed" rule, that allow selecting multipath routes
	any confederation member peer AS. As mentioned above, the		reachable via any confederation member peer AS. As mentioned above,
	AS_CONFED_SEQUENCE value length is usually ignored for the purpose of		the AS_CONFED_SEQUENCE value length is usually ignored for the
	AS_PATH length comparison, relying instead on the IGP cost for loop		purpose of AS_PATH length comparison, for the loop prevention relying
	prevention.		instead on the IGP cost .
	In cases when IGP is not present with BGP confederation deployment,		In cases, when IGP is not present with BGP confederation deployment,
	and similar to route-reflection case, it may be nessesary to consider		and similar to route-reflection case, it may be nessesary to consider
	AS_CONFED_SEQUENCE length when selecting the equivalent routes,		AS_CONFED_SEQUENCE length when selecting the equivalent routes,
	effectively using it as a substitution for an IGP metric. A separate		effectively using it as a substitution for an IGP metric. A separate
	configuration knob is needed to allow this behavior.		configuration knob is needed to allow this behavior.
	Per [RFC5065] paths learned over BGP intra-confederation peering		Per [RFC5065] paths learned over BGP intra-confederation peering
	sessions are treated as iBGP. There is no specification or		sessions are treated as iBGP. There is no specification or
	operational document that defines how a mixed iBGP route-reflector		operational document that defines how a mixed iBGP route-reflector
	and confederation based deplyments would work together. Therefore,		and confederation based deplyments would work together. Therefore,
	this document does not make recommendations for the above case.		this document does not make recommendations for the above case.
	5. Multipath among eBGP and iBGP paths		5. Multipath among eBGP and iBGP paths
	The best-path selection algorithm explicitly prefers eBGP paths over		The best-path selection algorithm explicitly prefers eBGP paths over
	iBGP or learned from a BGP confederation member AS, which is, as per		iBGP (or learned from BGP confederation member AS, which is, as per
	[RFC5065] treated the same as iBGP from perspective of best-path		[RFC5065] treated the same as iBGP from perspective of best-path
	selection. In some cases however, it might be beneficial to allow		selection). In some cases however, it might be beneficial to allow
	multipath routing between eBGP and iBGP learned paths. This is only		multipath routing between eBGP and iBGP learned paths. This is only
	possible if some sort of tunneling technique is used to reach both		possible if some sort of tunneling technique is used to reach both
	the eBGP and iBGP paths. If this feature is enabled, the equal		the eBGP and iBGP paths. If this feature is enabled, the equal
	routes are selected prior to the MED comparison step (c) in		routes are selected prior to the MED comparison step (c) in
	Section 9.1.2.2 [RFC4271].		Section 9.1.2.2 [RFC4271].
	6. Multipath with AIGP		6. Multipath with AIGP
	AIGP attribute defined in [RFC7311] must be used for best-path		AIGP attribute defined in [RFC7311] must be used for best-path
	selection prior to running any logic of Section 9.1.2.2 [RFC4271].		selection prior to running any logic of Section 9.1.2.2 [RFC4271].
	Only the paths with minimal value of AIGP metric are eligible for		Only the paths with minimal value of AIGP metric are eligible for
	further consideration of tie-breaking rules. The rest of multipath		further consideration of tie-breaking rules. The rest of multipath
	selection logic remains the same.		selection logic remains the same.
	7. Best path advertisement		7. Best path advertisement
	Unless BGP "Add-Path" feature described in [RFC7911] is enabled and		Unless BGP "Add-Path" feature as described in [RFC7911] is enabled
	even though multiple equal paths may be selected for programming into		and even though multiple equal paths may be selected for programming
	the routing table, a BGP speaker announces single best-path only to		into the routing table, a BGP speaker announces to its peers single
	its peers. The unique best-path is elected among the multi-path set		best-path only. The unique best-path is elected among the multi-path
	using the standard tie-breaking rules.		set using the standard tie-breaking rules.
	8. Multipath and non-deterministic tie-breaking		8. Multipath and non-deterministic tie-breaking
	Some implementations may implement non-standard tie-breaking logic,		Some implementations may implement non-standard tie-breaking logic,
	for example using the oldest path rule(reference). This is generally		for example using the oldest path rule, IETF reference - [RFC5004], a
	not recommended, and may interact with multi-path route selection on		vendor implementaion example [BGPMP]. This is generally not
			recommended, and may interact with multi-path route selection on
	downstream BGP speakers. That is, after a route flap that affects		downstream BGP speakers. That is, after a route flap that affects
	the best-path upstream, the original best path would not be		the best-path upstream, the original best path would not be
	recovered, and the older path would still be advertised, possibly		recovered, and the older path would still be advertised, possibly
	affecting the tie-breaking rules on down-stream device if for		affecting the tie-breaking rules on down-stream device if for
	example, the AS_PATH contents are different from previous.		example, the AS_PATH contents are different from previous. Another
			side effect of using non-standard tie-breaking could be increased
			number of BGP Next-Hop sets for Prefixes learned from eBGP neighbors
			and advertised downstream towards iBGP Neighbors. This could
			potentially cause ECMP group/entry tables to overrun (depending on a
			platform) as the prefixes will be less coalesced.
	9. Weighted equal-cost multipath		9. Weighted equal-cost multipath
	The proposal in [I-D.ietf-idr-link-bandwidth] defines conditions		The proposal in [I-D.ietf-idr-link-bandwidth] defines conditions
	where iBGP multipath feature might inform the routing table of		where iBGP multipath feature might inform the routing table of
	"weights" associated with the multiple external paths.		"weights" associated with the multiple external paths.
	[I-D.ietf-idr-link-bandwidth] defines the weight extended community		[I-D.ietf-idr-link-bandwidth] defines the weight extended community
	attribute as non-transitive, considers the applicability in iBGP case		attribute as non-transitive, considers the applicability for iBGP
	only, though there are implementations that apply it to eBGP as well.		only, though there are implementations that apply it to eBGP as well.
	The proposal does not change the equal-cost multipath selection		The proposal does not change the equal-cost multipath selection
	logic, but associates additional load-sharing attributes with		logic, only associates additional load-sharing attributes with
	equivalent paths.		equivalent paths.
	10. Informative References		10. Acknowledgements
			We like to thank Diptanshu Singh for their reviews and valuable
			comments.
			11. Informative References
	[BGPMP] "BGP Best Path Selection Algorithm",		[BGPMP] "BGP Best Path Selection Algorithm",
	<http://www.cisco.com/c/en/us/support/docs/ip/		<http://www.cisco.com/c/en/us/support/docs/ip/border-
	border-gateway-protocol-bgp/13753-25.html>.		gateway-protocol-bgp/13753-25.html>.
	[I-D.ietf-idr-link-bandwidth]		[I-D.ietf-idr-link-bandwidth]
	Mohapatra, P. and R. Fernando, "BGP Link Bandwidth		Mohapatra, P. and R. Fernando, "BGP Link Bandwidth
	Extended Community", draft-ietf-idr-link-bandwidth-07		Extended Community", draft-ietf-idr-link-bandwidth-07
	(work in progress), March 2018.		(work in progress), March 2018.
	[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol		[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
	Label Switching Architecture", RFC 3031,		Label Switching Architecture", RFC 3031,
	DOI 10.17487/RFC3031, January 2001,		DOI 10.17487/RFC3031, January 2001,
	<https://www.rfc-editor.org/info/rfc3031>.		<https://www.rfc-editor.org/info/rfc3031>.
	skipping to change at page 6, line 29 ¶		skipping to change at page 6, line 42 ¶
	[RFC4451] McPherson, D. and V. Gill, "BGP MULTI_EXIT_DISC (MED)		[RFC4451] McPherson, D. and V. Gill, "BGP MULTI_EXIT_DISC (MED)
	Considerations", RFC 4451, DOI 10.17487/RFC4451, March		Considerations", RFC 4451, DOI 10.17487/RFC4451, March
	2006, <https://www.rfc-editor.org/info/rfc4451>.		2006, <https://www.rfc-editor.org/info/rfc4451>.
	[RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route		[RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route
	Reflection: An Alternative to Full Mesh Internal BGP		Reflection: An Alternative to Full Mesh Internal BGP
	(IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006,		(IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006,
	<https://www.rfc-editor.org/info/rfc4456>.		<https://www.rfc-editor.org/info/rfc4456>.
			[RFC5004] Chen, E. and S. Sangli, "Avoid BGP Best Path Transitions
			from One External to Another", RFC 5004,
			DOI 10.17487/RFC5004, September 2007,
			<https://www.rfc-editor.org/info/rfc5004>.
	[RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous		[RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous
	System Confederations for BGP", RFC 5065,		System Confederations for BGP", RFC 5065,
	DOI 10.17487/RFC5065, August 2007,		DOI 10.17487/RFC5065, August 2007,
	<https://www.rfc-editor.org/info/rfc5065>.		<https://www.rfc-editor.org/info/rfc5065>.
	[RFC7311] Mohapatra, P., Fernando, R., Rosen, E., and J. Uttaro,		[RFC7311] Mohapatra, P., Fernando, R., Rosen, E., and J. Uttaro,
	"The Accumulated IGP Metric Attribute for BGP", RFC 7311,		"The Accumulated IGP Metric Attribute for BGP", RFC 7311,
	DOI 10.17487/RFC7311, August 2014,		DOI 10.17487/RFC7311, August 2014,
	<https://www.rfc-editor.org/info/rfc7311>.		<https://www.rfc-editor.org/info/rfc7311>.
	skipping to change at page 7, line 4 ¶		skipping to change at page 7, line 24 ¶
	Authors' Addresses		Authors' Addresses
	Petr Lapukhov		Petr Lapukhov
	Facebook		Facebook
	1 Hacker Way		1 Hacker Way
	Menlo Park, CA 94025		Menlo Park, CA 94025
	US		US
	Email: petr@fb.com		Email: petr@fb.com
	Jeff Tantsura		Jeff Tantsura
	Apstra, Inc.		Apstra, Inc.
			333 Middlefield Rd #200
	Menlo Park, CA 94025		Menlo Park, CA 94025
	US		US
	Email: jefftant.ietf@gmail.com		Email: jefftant.ietf@gmail.com
End of changes. 31 change blocks.
	86 lines changed or deleted		106 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/