draft-ietf-idr-large-community-06.txt		draft-ietf-idr-large-community-07.txt
	IDR J. Heitz, Ed.		IDR J. Heitz, Ed.
	Internet-Draft Cisco		Internet-Draft Cisco
	Intended status: Standards Track J. Snijders, Ed.		Intended status: Standards Track J. Snijders, Ed.
	Expires: May 2, 2017 NTT		Expires: May 8, 2017 NTT
	K. Patel		K. Patel
	Arrcus		Arrcus
	I. Bagdonas		I. Bagdonas
	Equinix		Equinix
	A. Simpson
	Nokia
	N. Hilliard		N. Hilliard
	INEX		INEX
	October 29, 2016		November 4, 2016
	Large BGP Communities		BGP Large Communities
	draft-ietf-idr-large-community-06		draft-ietf-idr-large-community-07
	Abstract		Abstract
	This document describes the Large BGP Communities attribute, an		This document describes the BGP Large Communities attribute, an
	extension to BGP-4. This attribute provides a mechanism to signal		extension to BGP-4. This attribute provides a mechanism to signal
	opaque information within separate namespaces to aid in routing		opaque information within separate namespaces to aid in routing
	management. The attribute is suitable for use with four-octet ASNs.		management. The attribute is suitable for use with four-octet
			Autonomous System Numbers.
	Requirements Language		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].
	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
	skipping to change at page 1, line 48		skipping to change at page 1, line 47
	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 May 2, 2017.		This Internet-Draft will expire on May 8, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2016 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
	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.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Large BGP Communities Attribute . . . . . . . . . . . . . . . 3		2. BGP Large Communities Attribute . . . . . . . . . . . . . . . 3
	3. Aggregation . . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Aggregation . . . . . . . . . . . . . . . . . . . . . . . . . 4
	4. Canonical Representation . . . . . . . . . . . . . . . . . . 4		4. Canonical Representation . . . . . . . . . . . . . . . . . . 4
	5. Reserved Large BGP Community values . . . . . . . . . . . . . 4		5. Reserved BGP Large Community values . . . . . . . . . . . . . 4
	6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 4		6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 5
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 5		7. Security Considerations . . . . . . . . . . . . . . . . . . . 5
	8. Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION 5		8. Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION 5
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
	10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 6		10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 6
	11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6		11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . 7		12. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
	12.1. Normative References . . . . . . . . . . . . . . . . . . 7		12.1. Normative References . . . . . . . . . . . . . . . . . . 7
	12.2. Informative References . . . . . . . . . . . . . . . . . 7		12.2. Informative References . . . . . . . . . . . . . . . . . 7
	12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 8		12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
	1. Introduction		1. Introduction
	BGP implementations typically support a routing policy language to		BGP implementations typically support a routing policy language to
	control the distribution of routing information. Network operators		control the distribution of routing information. Network operators
	attach BGP communities to routes to identify intrinsic properties of		attach BGP communities to routes to associate particular properties
	these routes. These properties may include information such as the		with these routes. These properties may include information such as
	route origin location, or specification of a routing policy action to		the route origin location, or specification of a routing policy
	be taken, or one that has been taken, and may apply to an individual		action to be taken, or one that has been taken, and is applied to all
	route or to a group of routes. Because BGP communities are optional		routes contained in a BGP Update Message where the Communities
			Attribute is included. Because BGP communities are optional
	transitive BGP attributes, BGP communities may be acted upon or		transitive BGP attributes, BGP communities may be acted upon or
	otherwise used by routing policies in other Autonomous Systems (ASes)		otherwise used by routing policies in other Autonomous Systems (ASes)
	on the Internet.		on the Internet.
	[RFC1997] BGP Communities attributes are four-octet values split into		BGP Communities attributes are a variable length attribute consisting
	two two-octet words. The most significant word is interpreted as an		of a set of one or more four-octet values, each of which specify a
	Autonomous System Number (ASN) and the least significant word is a		community [RFC1997]. Common use of the individual values of this
	locally defined value whose meaning is assigned by the operator of		attribute type split this single 32-bit value into two 16-bit values.
	the Autonomous System in the most significant word.		The most significant word is interpreted as an Autonomous System
			Number (ASN) and the least significant word is a locally defined
			value whose meaning is assigned by the operator of the Autonomous
			System in the most significant word.
	Since the adoption of four-octet ASNs [RFC6793], the BGP Communities		Since the adoption of four-octet ASNs [RFC6793], the BGP Communities
	attribute can no longer accommodate the above encoding, as a two-		attribute can no longer accommodate the above encoding, as a two-
	octet word cannot fit a four-octet ASN. The BGP Extended Communities		octet word cannot fit a four-octet ASN. The BGP Extended Communities
	attribute [RFC4360] is also unsuitable, as the protocol limit of six		attribute [RFC4360] is also unsuitable. The six-octet length of the
	octets cannot accommodate both a four-octet Global Administrator		Extended Community value precludes the common operational practise of
	value and a four-octet Local Administrator value, which precludes the		encoding four-octet ASNs in both the Global Administrator and the
	common operational practice of encoding a target ASN in the Local		Local Administrator sub-fields.
	Administrator field.
	To address these shortcomings, this document defines a Large BGP		To address these shortcomings, this document defines a BGP Large
	Communities attribute encoded as one or more twelve-octet values,		Communities attribute encoded as an unordered set of one or more
	each consisting of a four-octet Global Administrator field and two		twelve-octet values, each consisting of a four-octet Global
	four-octet operator-defined fields, each of which can be used to		Administrator field and two four-octet operator-defined fields, each
	denote properties or actions significant to the operator of the		of which can be used to denote properties or actions significant to
	Autonomous System assigning the values.		the operator of the Autonomous System assigning the values.
	2. Large BGP Communities Attribute		2. BGP Large Communities Attribute
	This document creates the Large BGP Communities attribute as an		This document creates the BGP Large Communities attribute as an
	optional transitive path attribute of variable length. All routes		optional transitive path attribute of variable length. All routes
	with the Large BGP Communities attribute belong to the community		with the BGP Large Communities attribute belong to the communities
	specified in the attribute.		specified in the attribute.
	The attribute consists of one or more twelve-octet values. Each		Each BGP Large Community value is encoded as a 12-octet quantity, as
	twelve-octet Large BGP Communities value represents three four-octet		follows:
	values, as follows:
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Global Administrator |		| Global Administrator |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Local Data Part 1 |		| Local Data Part 1 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Local Data Part 2 |		| Local Data Part 2 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Global Administrator: A four-octet namespace identifier. This		Global Administrator: A four-octet namespace identifier.
	SHOULD be an Autonomous System Number.
	Local Data Part 1: A four-octet operator-defined value.		Local Data Part 1: A four-octet operator-defined value.
	Local Data Part 2: A four-octet operator-defined value.		Local Data Part 2: A four-octet operator-defined value.
	The Global Administrator field is intended to allow different		The Global Administrator field is intended to allow different
	Autonomous Systems to define Large BGP Communities without collision.		Autonomous Systems to define BGP Large Communities without collision.
	Implementations MUST allow the operator to specify any value for the		This field SHOULD be either one of the reserved values as defined
	Global Administrator field.		below, or an Autonomous System Number (ASN). If it is a reserved
			value, then the Local Data Parts are as defined by the reserved
			value. If it is an ASN then the Local Data Parts are to be
			interpreted as defined by the owner of the ASN.
	There is no significance to the order in which Large BGP Communities		There is no significance to the order in which twelve-octet Large
	are encoded in the BGP path attribute payload. A BGP speaker can		Community values are encoded in a Large Communities attribute, nor in
	transmit them in any order.		the order of the BGP Large Communities attributes if two or more such
			attributes are encoded in the BGP path attribute payload of a single
			BGP Update message. A BGP speaker can transmit them in any order.
	Duplicate Large BGP Communities SHOULD NOT be transmitted. A		Duplicate BGP Large Community values SHOULD NOT be transmitted. A
	receiving speaker SHOULD silently remove duplicate Large BGP		receiving speaker SHOULD silently remove duplicate BGP Large
	Communities from a BGP UPDATE message.		Community values from a BGP UPDATE message.
	3. Aggregation		3. Aggregation
	If a range of routes is aggregated, then the resulting aggregate		If a range of routes is aggregated, then the resulting aggregate
	should have a Large BGP Communities attribute which contains all of		should have a BGP Large Communities attribute which contains all of
	the Large BGP Communities attributes from all of the aggregated		the BGP Large Communities attributes from all of the aggregated
	routes.		routes.
	4. Canonical Representation		4. Canonical Representation
	Large BGP Communities MUST be represented as three separate unsigned		The canonical representation of BGP Large Communities is three
	integers in decimal notation in the following order: Global		separate unsigned integers in decimal notation in the following
	Administrator, Local Data 1, Local Data 2. Numbers MUST NOT contain		order: Global Administrator, Local Data 1, Local Data 2. Numbers
	leading zeros; a zero value MUST be represented with a single zero.		MUST NOT contain leading zeros; a zero value MUST be represented with
	For example: 64496:4294967295:2, 64496:0:0, or (64496, 111, 222).		a single zero. Each number is separated from the next by a single
			colon. For example: 64496:4294967295:2, 64496:0:0.
	5. Reserved Large BGP Community values		BGP Large Communities SHOULD be represented in the canonical
			representation.
	The following Global Administrator values are reserved: 0 (the first		5. Reserved BGP Large Community values
	ASN) [RFC7607], 65535 (UINT16_MAX) and 4294967295 (the last ASN)
	[RFC7300]. Operators SHOULD NOT use these Global Administrator		The following Global Administrator values are reserved: 0, 65535, and
			4294967295. Operators SHOULD NOT use these Global Administrator
	values.		values.
	Although this document does not define any Special-Use Large BGP		Although this document does not define any Special-Use BGP Large
	Communities, the Global Administrator values specified above could be		Communities, the Global Administrator values specified above could be
	used if there is a future need for them.		used if there is a future need for them.
	6. Error Handling		6. Error Handling
	The error handling of Large BGP Communities is as follows:		The error handling of BGP Large Communities is as follows:
	o A Large BGP Communities attribute SHALL be considered malformed if		o A BGP Large Communities attribute SHALL be considered malformed if
	its length is not a non-zero multiple of 12.		the length of the BGP Large Communities value, expressed in
			octets, is not a non-zero multiple of 12.
	o A BGP UPDATE message with a malformed Large BGP Communities		o A BGP UPDATE message with a malformed BGP Large Communities
	attribute SHALL be handled using the approach of "treat-as-		attribute SHALL be handled using the approach of "treat-as-
	withdraw" as described in section 2 [RFC7606].		withdraw" as described in section 2 [RFC7606].
	The Large BGP Communities Global Administrator field may contain any		The BGP Large Communities Global Administrator field MAY contain any
	value, and a Large BGP Communities attribute MUST NOT be considered		value, and a BGP Large Communities attribute MUST NOT be considered
	malformed if the Global Administrator field contains an unallocated,		malformed if the Global Administrator field contains an unallocated,
	unassigned or reserved ASN or is set to one of the reserved Large BGP		unassigned or reserved ASN or is set to one of the reserved BGP Large
	Community values defined in Section 5.		Community values defined in Section 5.
	7. Security Considerations		7. Security Considerations
	This extension to BGP has similar security implications as BGP		This extension to BGP has similar security implications as BGP
	Communities [RFC1997].		Communities [RFC1997].
	This document does not change any underlying security issues		This document does not change any underlying security issues
	associated with any other BGP Communities mechanism. Specifically,		associated with any other BGP Communities mechanism. Specifically,
	an AS relying on the Large BGP Communities attribute carried in BGP		an AS relying on the BGP Large Communities attribute carried in BGP
	must have trust in every other AS in the path, as any intermediate		must have trust in every other AS in the path, as any intermediate
	Autonomous System in the path may have added, deleted, or altered the		Autonomous System in the path may have added, deleted, or altered the
	Large BGP Communities attribute. Specifying the mechanism to provide		BGP Large Communities attribute. Specifying the mechanism to provide
	such trust is beyond the scope of this document.		such trust is beyond the scope of this document.
			BGP Large Communities do not protect the integrity of each community
			value. Operators should be aware that it is possible for a BGP
			speaker to alter BGP Large Community values in a BGP Update Message.
			Protecting the integrity of the transitive handling of BGP Large
			Community attributes in a manner consistent with the intent of
			expressed BGP routing policies falls within the broader scope of
			securing BGP, and is not specifically addressed here.
	Network administrators should note the recommendations in Section 11		Network administrators should note the recommendations in Section 11
	of BGP Operations and Security [RFC7454].		of BGP Operations and Security [RFC7454].
	8. Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION		8. Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION
	This section records the status of known implementations of the		This section records the status of known implementations of the
	protocol defined by this specification at the time of posting of this		protocol defined by this specification at the time of posting of this
	Internet-Draft, and is based on a proposal described in [RFC7942].		Internet-Draft, and is based on a proposal described in [RFC7942].
	The description of implementations in this section is intended to		The description of implementations in this section is intended to
	assist the IETF in its decision processes in progressing drafts to		assist the IETF in its decision processes in progressing drafts to
	RFCs. Please note that the listing of any individual implementation		RFCs. Please note that the listing of any individual implementation
	here does not imply endorsement by the IETF. Furthermore, no effort		here does not imply endorsement by the IETF. Furthermore, no effort
	has been spent to verify the information presented here that was		has been spent to verify the information presented here that was
	supplied by IETF contributors. This is not intended as, and must not		supplied by IETF contributors. This is not intended as, and must not
	be construed to be, a catalog of available implementations or their		be construed to be, a catalog of available implementations or their
	features. Readers are advised to note that other implementations may		features. Readers are advised to note that other implementations may
	exist.		exist.
	As of today these vendors have produced an implementation of Large		As of today these vendors have produced an implementation of BGP
	BGP Communities:		Large Communities:
	o Cisco IOS XR		o Cisco IOS XR
	o ExaBGP		o ExaBGP
	o GoBGP		o GoBGP
	o BIRD		o BIRD
	o OpenBGPD		o OpenBGPD
	o pmacct		o pmacct
	o Quagga		o Quagga
	skipping to change at page 6, line 31		skipping to change at page 6, line 47
	Protocol (BGP) Parameters" group and is now asked to make that		Protocol (BGP) Parameters" group and is now asked to make that
	Permanent.		Permanent.
	10. Contributors		10. Contributors
	The following people contributed significantly to the content of the		The following people contributed significantly to the content of the
	document:		document:
	John Heasley		John Heasley
	NTT Communications		NTT Communications
	Email: heas@shrubbery.net		Email: heas@shrubbery.net
			Adam Simpson
			Nokia
			Email: adam.1.simpson@nokia.com
	11. Acknowledgments		11. Acknowledgments
	The authors would like to thank Ruediger Volk, Russ White, Acee		The authors would like to thank Ruediger Volk, Russ White, Acee
	Lindem, Shyam Sethuram, Jared Mauch, Joel M. Halpern, Jeffrey Haas,		Lindem, Shyam Sethuram, Jared Mauch, Joel M. Halpern, Jeffrey Haas,
	Gunter van de Velde, Marco Marzetti, Eduardo Ascenco Reis, Mark		Gunter van de Velde, Marco Marzetti, Eduardo Ascenco Reis, Mark
	Schouten, Paul Hoogsteder, Martijn Schmidt, Greg Hankins, Bertrand		Schouten, Paul Hoogsteder, Martijn Schmidt, Greg Hankins, Bertrand
	Duvivier, Barry O'Donovan, Grzegorz Janoszka, Linda Dunbar, Marco		Duvivier, Barry O'Donovan, Grzegorz Janoszka, Linda Dunbar, Marco
	Davids, Gaurab Raj Upadhaya, Jeff Tantsura, Teun Vink, Adam		Davids, Gaurab Raj Upadhaya, Jeff Tantsura, Teun Vink, Adam
	Davenport, Theodore Baschak, Pier Carlo Chiodi, Nabeel Cocker, Ian		Davenport, Theodore Baschak, Pier Carlo Chiodi, Nabeel Cocker, Ian
	Dickinson, Jan Baggen, Duncan Lockwood, David Farmer, Randy Bush, Wim		Dickinson, Jan Baggen, Duncan Lockwood, David Farmer, Randy Bush, Wim
	Henderickx, Stefan Plug, Kay Rechthien, Rob Shakir, Warren Kumari,		Henderickx, Stefan Plug, Kay Rechthien, Rob Shakir, Warren Kumari,
	Gert Doering, Thomas King, Mikael Abrahamsson, Wesley Steehouwer,		Gert Doering, Thomas King, Mikael Abrahamsson, Wesley Steehouwer,
	Sander Steffann, Brad Dreisbach, Martin Millnert, Christopher Morrow,		Sander Steffann, Brad Dreisbach, Martin Millnert, Christopher Morrow,
	Jay Borkenhagen, Arnold Nipper, Joe Provo, Niels Bakker, Bill Fenner,		Jay Borkenhagen, Arnold Nipper, Joe Provo, Niels Bakker, Bill Fenner,
	Tom Daly, Ben Maddison, Alexander Azimov, Brian Dickson, Peter van		Tom Daly, Ben Maddison, Alexander Azimov, Brian Dickson, Peter van
	Dijk, Julian Seifert, Tom Petch, Tom Scholl, Arjen Zonneveld, Remco		Dijk, Julian Seifert, Tom Petch, Tom Scholl, Arjen Zonneveld, Remco
	van Mook, Adam Chappell, Jussi Peltola, Kristian Larsson, Markus		van Mook, Adam Chappell, Jussi Peltola, Kristian Larsson, Markus
	Hauschild, Richard Steenbergen, David Freedman, Richard Hartmann for		Hauschild, Richard Steenbergen, David Freedman, Richard Hartmann and
	their support, insightful review and comments.		Geoff Huston for their support, insightful review and comments.
	12. References		12. References
	12.1. Normative References		12.1. Normative References
	[RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities		[RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities
	Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996,		Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996,
	<http://www.rfc-editor.org/info/rfc1997>.		<http://www.rfc-editor.org/info/rfc1997>.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	skipping to change at page 7, line 36		skipping to change at page 8, line 5
	Patel, "Revised Error Handling for BGP UPDATE Messages",		Patel, "Revised Error Handling for BGP UPDATE Messages",
	RFC 7606, DOI 10.17487/RFC7606, August 2015,		RFC 7606, DOI 10.17487/RFC7606, August 2015,
	<http://www.rfc-editor.org/info/rfc7606>.		<http://www.rfc-editor.org/info/rfc7606>.
	12.2. Informative References		12.2. Informative References
	[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended		[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
	Communities Attribute", RFC 4360, DOI 10.17487/RFC4360,		Communities Attribute", RFC 4360, DOI 10.17487/RFC4360,
	February 2006, <http://www.rfc-editor.org/info/rfc4360>.		February 2006, <http://www.rfc-editor.org/info/rfc4360>.
	[RFC7300] Haas, J. and J. Mitchell, "Reservation of Last Autonomous
	System (AS) Numbers", BCP 6, RFC 7300,
	DOI 10.17487/RFC7300, July 2014,
	<http://www.rfc-editor.org/info/rfc7300>.
	[RFC7454] Durand, J., Pepelnjak, I., and G. Doering, "BGP Operations		[RFC7454] Durand, J., Pepelnjak, I., and G. Doering, "BGP Operations
	and Security", BCP 194, RFC 7454, DOI 10.17487/RFC7454,		and Security", BCP 194, RFC 7454, DOI 10.17487/RFC7454,
	February 2015, <http://www.rfc-editor.org/info/rfc7454>.		February 2015, <http://www.rfc-editor.org/info/rfc7454>.
	[RFC7607] Kumari, W., Bush, R., Schiller, H., and K. Patel,
	"Codification of AS 0 Processing", RFC 7607,
	DOI 10.17487/RFC7607, August 2015,
	<http://www.rfc-editor.org/info/rfc7607>.
	[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running		[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
	Code: The Implementation Status Section", BCP 205,		Code: The Implementation Status Section", BCP 205,
	RFC 7942, DOI 10.17487/RFC7942, July 2016,		RFC 7942, DOI 10.17487/RFC7942, July 2016,
	<http://www.rfc-editor.org/info/rfc7942>.		<http://www.rfc-editor.org/info/rfc7942>.
	12.3. URIs		12.3. URIs
	[1] http://largebgpcommunities.net		[1] http://largebgpcommunities.net
	Authors' Addresses		Authors' Addresses
	skipping to change at page 9, line 4		skipping to change at page 9, line 4
	Arrcus, Inc		Arrcus, Inc
	Email: keyur@arrcus.com		Email: keyur@arrcus.com
	Ignas Bagdonas		Ignas Bagdonas
	Equinix		Equinix
	London		London
	UK		UK
	Email: ibagdona.ietf@gmail.com		Email: ibagdona.ietf@gmail.com
	Adam Simpson
	Nokia
	600 March Road
	Ottawa Ontario K2K 2E6
	Canada
	Email: adam.1.simpson@nokia.com
	Nick Hilliard		Nick Hilliard
	INEX		INEX
	4027 Kingswood Road		4027 Kingswood Road
	Dublin 24		Dublin 24
	IE		IE
	Email: nick@inex.ie		Email: nick@inex.ie
End of changes. 43 change blocks.
	95 lines changed or deleted		98 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/