draft-ietf-idr-reserved-extended-communities-00.txt		draft-ietf-idr-reserved-extended-communities-01.txt
	Network Working Group B. Decraene		Network Working Group B. Decraene
	Internet-Draft France Telecom - Orange		Internet-Draft France Telecom - Orange
	Intended status: Standards Track P. Francois		Intended status: Standards Track P. Francois
	Expires: August 11, 2011 UCL		Expires: November 24, 2011 Universite catholique de Louvain
	February 07, 2011		May 23, 2011
	Reserved BGP extended communities		Assigned BGP extended communities
	draft-ietf-idr-reserved-extended-communities-00		draft-ietf-idr-reserved-extended-communities-01
	Abstract		Abstract
	This document assigns two BGP extended community types, one		This document defines two IANA registries in order to assign
	transitive and one non-transitive. It also defines two IANA		transitive and non-transitive extended communities from. These are
	registries in order to allow the allocation of reserved transitive		similar to the existing well-known BGP communities defined in RFC
	and non-transitive extended communities. These are similar to the		1997 but provide an easier control of inter-AS community
	existing reserved (formerly Well-known) BGP communities defined in
	RFC 1997 but provides an easier control of inter-AS community
	advertisement as a community could be chosen as transitive or non-		advertisement as a community could be chosen as transitive or non-
	transitive across ASes.		transitive across ASes.
			For that purpose, this document defines the use of the reserved AS
			number 0 for the transitive and non-transitive generic four-octet AS
			specific extended community types.
	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 RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [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
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	skipping to change at page 1, line 44		skipping to change at page 1, line 46
	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 August 11, 2011.		This Internet-Draft will expire on November 24, 2011.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 IETF Trust and the persons identified as the		Copyright (c) 2011 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
	skipping to change at page 2, line 17		skipping to change at page 2, line 19
	(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.
	1. Introduction		1. Introduction
	[RFC1997] defines the BGP community attribute and some BGP Well known		[RFC1997] defines the BGP community attribute and some BGP well-known
	communities whose meaning SHALL be understood by all compliant		communities whose meaning SHALL be understood by all compliant
	implementations. New reserved communities can be registered in the		implementations. New communities can be registered in the IANA "BGP
	IANA "BGP Well-known Communities" registry but it can't be assumed		Well-known Communities" registry but it can't be assumed anymore that
	anymore that they will be known by all BGP implementations.		they will be known by all BGP implementations. Implementations or
	Implementations or BGP policies which recognize them will behave as		BGP policies which recognize them will behave as specified.
	specified. Implementation which do not recognize those new reserved		Implementations which do not recognize those new reserved communities
	communities will propagate them from BGP neighbor to BGP neighbor and		will propagate them from BGP neighbor to BGP neighbor and from AS to
	from AS to AS with an unlimited scope.		AS with an unlimited scope.
	There is currently no agreed way to reserve a non transitive well		There is currently no agreed way to register a non transitive well-
	known community:		known community:
	o [RFC1997] defines BGP Well-known communities with no structure to		On one hand, [RFC1997] defines BGP Well-known communities with no
	set their transitiveness across ASes. Without structure, non		structure to set their transitiveness across ASes. Without
	transitive communities can only be filtered by explicitly		structure, communities can only be filtered by explicitly enumerating
	enumerating all community values that will be denied or allowed to		all community values that will be denied or allowed to BGP speakers
	BGP speakers in neighboring ASes. This is not satisfactory as		in neighboring ASes. This is not satisfactory as this would require
	this would require upgrading all border routers to understand this		upgrading all border routers to understand this community before its
	community before its first usage.		first usage.
	o [RFC4360] defines the BGP extended community attribute with a
	structure including a type and a transitive bit "T". The
	transitive bit, when set, allows to restrict the scope of the
	community within an AS. But their is no IANA registry to allocate
	a (single) well known extended community. RFC 4360 [RFC4360]
	defines IANA registries to allocate BGP Extended Communities
	types. Each type is able to encode 2^48 or 2^56 values depending
	on the type being extended or regular. Therefore, one needing to
	reserve a single non-transitive extended community would need to
	reserve an extended subtype which represents 2^48 communities,
	while a single value is used. This would both waste the resources
	and disable the ability to define global policies on reserved
	communities, such as to filter them out.
	To address this limitation, this document assigns two BGP extended
	community types, one transitive and one non-transitive. It also
	defines two IANA registries in order to allow the allocation of
	reserved transitive and non-transitive extended communities. These
	are similar to the existing Well-known BGP communities defined in RFC
	1997 but provides a control on inter-AS community advertisement as a
	community could be chosen as transitive or non-transitive across
	ASes.
	2. IANA Considerations		On the other hand, [RFC4360] defines the BGP extended community
			attribute with a structure including a type and a transitive bit "T".
			This transitive bit, when set, allows to restrict the scope of the
			community within an AS. But their is no IANA registry to allocate
			one well-known extended community. [RFC4360] defines IANA registries
			to allocate BGP Extended Communities types. Each type is able to
			encode 2^48 or 2^56 values depending on the type being extended or
			regular. Therefore, one needing to reserve a single non-transitive
			extended community would need to reserve an extended subtype which
			represents 2^48 communities, while a single value is used. This
			would both waste the resources and disable the ability to define
			global policies on reserved communities, such as to accept them or to
			filter them out.
	IANA is requested to assign, from the registry "BGP Extended		To address this limitation, this document defines two IANA registries
	Communities Type - extended, transitive type", a type value TBD for		in order to allow the registration of transitive and non-transitive
	"BGP Reserved transitive extended communities":		extended communities. These are similar to the existing Well-known
			BGP communities defined in [RFC1997] but provides a control on
			inter-AS community advertisement as a community could be chosen as
			transitive or non-transitive across ASes.
	Registry Name: BGP Extended Communities Type - extended, transitive		2. Assigned extended communities
	Name Type Value		[I-D.ietf-idr-as4octet-extcomm-generic-subtype] defines a generic
	---- ----------		sub-type for the four-octet AS specific extended community. The
	BGP Reserved transitive extended communities TBD (e.g. 0x9000)		value of the four-octets Global Administrator sub-field contains a
			four-octet Autonomous System number. The value of their two-octet
			Local Administrator sub-field has semantics defined by the Autonomous
			System set in the Global Administrator sub-field.
	IANA is requested to assign, from the registry "BGP Extended		This document updates [I-D.ietf-idr-as4octet-extcomm-generic-subtype]
	Communities Type - extended, non-transitive", a type value TBD for		and defines the use of the Local Administrator sub-field when the AS
	"BGP Reserved non-transitive extended communities":		number encoded in the Global Administrator sub-field has the reserved
			value 0.
	Registry Name: BGP Extended Communities Type - extended, non-transitive		When the AS number encoded in the Global Administrator sub-field has
			the reserved value 0, the communities have global significance. The
			lists of those communities are maintained by the IANA in the
			registries "Assigned transitive extended communities" for the
			"transitive generic four-octet AS specific" extended community type
			and "Assigned non-transitive extended communities" for the "non-
			transitive generic four-octet AS specific" extended community type.
	Name Type Value		Note that this use of the reserved AS number 0 in the AS field of the
	---- ----------		communities is similar to the one defined by [RFC1997] for the BGP
	BGP Reserved non-transitive extended communities TBD (e.g. 0xd000)		Well-Known communities.
	Note to the IANA: suggested value for the two reserved BGP Extended		3. IANA Considerations
	Communities extended type are 0x9000 and 0xd000. Otherwise, both
	values should be identical, except for their T - Transitive bit (bit
	1 as defined in [RFC4360]).
	The IANA is requested to create and maintain a registry entitled "BGP		The IANA is requested to create and maintain a registry entitled
	Reserved transitive extended communities":		"Assigned transitive extended communities" with the following
			registration procedure:
	Registry Name: BGP Reserved transitive extended communities		Registry Name: Assigned transitive extended communities
	Range Registration Procedures		Range Registration Procedures
	--------------------------- -------------------------		----------- -------------------------
	0x000000000000-FFFFFFFEFFFF Reserved		0x0000-8000 First Come First Served
	0xFFFFFFFF0000-00FFFFFF8000 First Come First Served		0x8001-FFFF Standards Action/Early IANA Allocation
	0x00FFFFFF8001-FFFFFFFFFFFF Standards Action/Early IANA Allocation
	The IANA is requested to create and maintain a registry entitled "BGP		The IANA is requested to create and maintain a registry entitled
	Reserved non-transitive extended communities":		"Assigned non-transitive extended communities" with the following
			registration procedure:
	Registry Name: BGP Reserved non-transitive extended communities		Registry Name: Assigned non-transitive extended communities
	Range Registration Procedures		Range Registration Procedures
	--------------------------- -------------------------		----------- -------------------------
	0x000000000000-FFFFFFFEFFFF Reserved		0x0000-8000 First Come First Served
	0xFFFFFFFF0000-00FFFFFF8000 First Come First Served		0x8001-FFFF Standards Action/Early IANA Allocation
	0x00FFFFFF8001-FFFFFFFFFFFF Standards Action/Early IANA Allocation
	An application may need both a transitive and non-transitive reserved		An application may need both a transitive and a non-transitive
	community. It may be beneficial to have the same value for both		community and it may be beneficial to have the same value for both
	communities. (Note that both extended community will still be		communities. (Note that both extended communities will still be
	different as they will differ from their T bit). The IANA SHOULD try		different as they will differ from their T bit). The IANA SHOULD try
	to accommodate such request to have both a transitive and non-		to accommodate such request to get both a transitive and non-
	transitive reserved community with the same value for both.		transitive assigned community with the same value for both.
	3. Security Considerations		4. Security Considerations
	This document defines IANA actions. In itself, it has no impact on		This document defines IANA actions. In itself, it has no impact on
	the security of the BGP protocol.		the security of the BGP protocol.
	4. Normative References		5. Normative References
			[I-D.ietf-idr-as4octet-extcomm-generic-subtype]
			Rao, D., Mohapatra, P., and J. Haas, "Generic Subtype for
			BGP Four-octet AS specific extended community",
			draft-ietf-idr-as4octet-extcomm-generic-subtype-03 (work
			in progress), October 2010.
	[RFC1997] Chandrasekeran, R., Traina, P., and T. Li, "BGP		[RFC1997] Chandrasekeran, R., Traina, P., and T. Li, "BGP
	Communities Attribute", RFC 1997, August 1996.		Communities Attribute", RFC 1997, August 1996.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended		[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
	Communities Attribute", RFC 4360, February 2006.		Communities Attribute", RFC 4360, February 2006.
	[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an		[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
	IANA Considerations Section in RFCs", BCP 26, RFC 5226,		IANA Considerations Section in RFCs", BCP 26, RFC 5226,
	May 2008.		May 2008.
	Authors' Addresses		Authors' Addresses
	Bruno Decraene		Bruno Decraene
	France Telecom - Orange		France Telecom - Orange
	38-40 rue du General Leclerc		38 rue du General Leclerc
	Issy Moulineaux cedex 9 92794		Issy Moulineaux cedex 9 92794
	France		France
	Email: bruno.decraene@orange-ftgroup.com		Email: bruno.decraene@orange-ftgroup.com
	Pierre Francois		Pierre Francois
	UCL		Universite catholique de Louvain
	Place Ste Barbe, 2		Place Ste Barbe, 2
	Louvain-la-Neuve 1348		Louvain-la-Neuve 1348
	BE		BE
	Email: francois@info.ucl.ac.be		Email: francois@info.ucl.ac.be
End of changes. 30 change blocks.
	95 lines changed or deleted		101 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/