draft-ietf-idr-reserved-extended-communities-02.txt		draft-ietf-idr-reserved-extended-communities-03.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: June 7, 2012 IMDEA Networks		Expires: November 22, 2012 IMDEA Networks
	Dec 05, 2011		May 21, 2012
	Assigned BGP extended communities		Assigned BGP extended communities
	draft-ietf-idr-reserved-extended-communities-02		draft-ietf-idr-reserved-extended-communities-03
	Abstract		Abstract
	This document defines two IANA registries in order to assign		This document defines an IANA registry in order to assign non-
	transitive and non-transitive extended communities from. These are		transitive extended communities from. These are similar to the
	similar to the existing well-known BGP communities defined in RFC		existing well-known BGP communities defined in RFC 1997 but provide a
	1997 but provide an easier control of inter-AS community		control over inter-AS community advertisement as, per RFC RFC 4360,
	advertisement as a community could be chosen as transitive or non-		they are not transitive across Autonomous System boundaries.
	transitive across ASes.
	For that purpose, this document defines the use of the reserved AS		For that purpose, this document defines the use of the reserved
	number 0 for the transitive and non-transitive generic four-octet AS		Autonomous System number 0.65535 in the non-transitive generic four-
	specific extended community types.		octet AS specific extended community type.
	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
	skipping to change at page 1, line 46		skipping to change at page 1, line 45
	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 June 7, 2012.		This Internet-Draft will expire on November 22, 2012.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 IETF Trust and the persons identified as the
			Copyright (c) 2012 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.
	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 communities can be registered in the IANA "BGP		implementations. New communities can be registered in the IANA "BGP
	Well-known Communities" registry but it can't be assumed anymore that		Well-known Communities" registry but it can't be assumed anymore that
	they will be known by all BGP implementations. Implementations or		they will be known by all BGP implementations. Implementations or
	BGP policies which recognize them will behave as specified.		BGP policies which recognize them will behave as specified in the
	Implementations which do not recognize those new reserved communities		IANA registry. Implementations which do not recognize those new IANA
	will propagate them from BGP neighbor to BGP neighbor and from AS to		assigned communities will propagate them from BGP neighbor to BGP
	AS with an unlimited scope.		neighbor and from AS to AS with an unlimited scope.
	There is currently no agreed way to register a non transitive well-		There is currently no agreed way to register a non-transitive well-
	known community:		known community.
	On one hand, [RFC1997] defines BGP Well-known communities with no		On one hand, [RFC1997] defines BGP Well-known communities with no
	structure to set their transitiveness across ASes. Without		structure to set their transitiveness across ASes. Without
	structure, communities can only be filtered by explicitly enumerating		structure, communities can only be filtered by explicitly enumerating
	all community values that will be denied or allowed to BGP speakers		all community values that will be denied or allowed to BGP speakers
	in neighboring ASes. This is not satisfactory as this would require		in neighboring ASes. This is not satisfactory as this would require
	upgrading all border routers to understand this community before its		upgrading all border routers to understand this community before its
	first usage.		first usage.
	On the other hand, [RFC4360] defines the BGP extended community		On the other hand, [RFC4360] defines the BGP extended community
	attribute with a structure including a type and a transitive bit "T".		attribute with a structure including a type and a transitive bit "T".
	This transitive bit, when set, allows to restrict the scope of the		This transitive bit, when set, allows to restrict the scope of the
	community within an AS. But their is no IANA registry to allocate		community within an AS. But there is no IANA registry to allocate
	one well-known extended community. [RFC4360] defines IANA registries		one well-known extended community. [RFC4360] defines IANA registries
	to allocate BGP Extended Communities types. Each type is able to		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		encode 2^48 or 2^56 values depending on the type being extended or
	regular. Therefore, one needing to reserve a single non-transitive		regular. Therefore, one needing to reserve a single non-transitive
	extended community would need to reserve an extended subtype which		extended community would need to reserve an extended subtype which
	represents 2^48 communities, while a single value is used. This		represents 2^48 communities, while a single value is used. This
	would both waste the resources and disable the ability to define		would both waste the resources and disable the ability to define
	global policies on reserved communities, such as to accept them or to		global policies on reserved communities, such as to accept them or to
	filter them out.		filter them out. In addition, using a new community type typically
			requires a software upgrade on both the router setting the community
			and the router using it in a BGP policy. So this would not allow the
			networking community to quickly define and use a new community.
	To address this limitation, this document defines two IANA registries		To address this limitation, this document defines an IANA registry in
	in order to allow the registration of transitive and non-transitive		order to allow the registration of non-transitive extended
	extended communities. These are similar to the existing Well-known		communities. These are similar to the existing Well-known BGP
	BGP communities defined in [RFC1997] but provides a control on		communities defined in [RFC1997] but provides a control on inter-AS
	inter-AS community advertisement as a community could be chosen as		community advertisement. Indeed, as per [RFC4360] non-transitive
	transitive or non-transitive across ASes.		communities are removed from routes propagated to another AS.
	2. Assigned extended communities		2. Assigned non-transitive extended communities
	[I-D.ietf-idr-as4octet-extcomm-generic-subtype] defines a generic		[I-D.ietf-idr-as4octet-extcomm-generic-subtype] defines a generic
	sub-type for the four-octet AS specific extended community. The		sub-type for the four-octet AS specific extended community. The
	value of the four-octets Global Administrator sub-field contains a		value of the four-octets Global Administrator sub-field contains a
	four-octet Autonomous System number. The value of their two-octet		four-octet Autonomous System number. The value of their two-octet
	Local Administrator sub-field has semantics defined by the Autonomous		Local Administrator sub-field has semantics defined by the Autonomous
	System set in the Global Administrator sub-field.		System set in the Global Administrator sub-field.
	This document updates [I-D.ietf-idr-as4octet-extcomm-generic-subtype]		This document updates [I-D.ietf-idr-as4octet-extcomm-generic-subtype]
	and defines the use of the Local Administrator sub-field when the AS		and defines the use of the Local Administrator sub-field of the "non-
	number encoded in the Global Administrator sub-field has the reserved		transitive generic four-octet AS specific" extended community type
	value 0.		when the AS number has the reserved value 0.65535 (0x0000FFFF).
	When the AS number encoded in the Global Administrator sub-field has		When the AS number, encoded in the Global Administrator sub-field,
	the reserved value 0, the communities have global significance. The		has the reserved value 0.65535, the communities have global
	lists of those communities are maintained by the IANA in the		significance. The lists of those communities are maintained by the
	registries "Assigned transitive extended communities" for the		IANA in the registry "Assigned non-transitive extended communities".
	"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.
	Note that this use of the reserved AS number 0 in the AS field of the		Note that this use of the reserved AS number 0.65535 in the AS field
	communities is similar to the one defined by [RFC1997] for the BGP		of the communities is similar to the one defined by [RFC1997] for the
	Well-Known communities.		BGP Well-Known communities. In particular, [RFC1997] also uses the
			reserved AS number 65535.
	3. IANA Considerations		3. Assigned transitive extended communities
	The IANA is requested to create and maintain a registry entitled		As per [RFC4893], a 2-octet Autonomous System number can be converted
	"Assigned transitive extended communities" with the following		into a 4-octet Autonomous System number by setting the two high-order
	registration procedure:		octets of the 4-octet field to zero. This applies to the reserved
			2-octet Autonous System number 65535 which could use either a
			standard community or the 4-octet AS specific generic extended
			community. As noted in
			[I-D.ietf-idr-as4octet-extcomm-generic-subtype], this is undesirable
			as they would be treated as different communities, even if they had
			the same values.
	Registry Name: Assigned transitive extended communities		Therefore, this document does not define a non-transitive extended
			community registry and transitive communities are still to be
			assigned as per [RFC1997].
	Range Registration Procedures		4. IANA Considerations
	----------- -------------------------
	0x0000-8000 First Come First Served
	0x8001-FFFF Standards Action/Early IANA Allocation
	The IANA is requested to create and maintain a registry entitled		The IANA is requested to create and maintain a registry entitled
	"Assigned non-transitive extended communities" with the following		"Assigned non-transitive extended communities" with the following
	registration procedure:		registration procedure:
	Registry Name: Assigned non-transitive extended communities		Registry Name: Assigned non-transitive extended communities
			with Global Significance
	Range Registration Procedures		Range Registration Procedures
	----------- -------------------------		----------- -------------------------
	0x0000-8000 First Come First Served		0x0000-8000 First Come First Served
	0x8001-FFFF Standards Action/Early IANA Allocation		0x8001-FFFF Standards Action/Early IANA Allocation
	An application may need both a transitive and a non-transitive		An application may need both a transitive and a non-transitive
	community and 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 communities will still be		communities. Therefore, the IANA SHOULD try to accommodate such
	different as they will differ from their T bit). The IANA SHOULD try		request to get both a non-transitive community from the above
	to accommodate such request to get both a transitive and non-		"Assigned non transitive extended communities" and a transitive
	transitive assigned community with the same value for both.		community from [RFC1997] BGP Well-known Communities with the same
			(lower two-octets) value for both.
	4. Security Considerations		5. 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.
	5. Normative References		It allows the allocation of non-transitive global communities which
			are not propagated across Autonomous System boundaries. Compared to
			a transitive well-known community, a non-transitive community can
			provide some security benefit both for the sender and the receiver of
			the community.
			6. Acknowledgements
			We would like to acknowledge John Scudder and Jeffrey Haas for their
			contribution to this document.
			7. Normative References
	[I-D.ietf-idr-as4octet-extcomm-generic-subtype]		[I-D.ietf-idr-as4octet-extcomm-generic-subtype]
	Rao, D., Mohapatra, P., and J. Haas, "Generic Subtype for		Rao, D., Mohapatra, P., and J. Haas, "Generic Subtype for
	BGP Four-octet AS specific extended community",		BGP Four-octet AS specific extended community",
	draft-ietf-idr-as4octet-extcomm-generic-subtype-04 (work		draft-ietf-idr-as4octet-extcomm-generic-subtype-05 (work
	in progress), July 2011.		in progress), March 2012.
	[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.
			[RFC4893] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS
			Number Space", RFC 4893, May 2007.
	[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.
			Appendix A. Appendix A. Changes / Author Notes
			[RFC Editor: Please remove this section before publication ]
			Changes -01
			o Name changed from 'Reserved BGP extended communities' to 'Assigned
			BGP extended communities'
			o Addition of section 'Assigned extended communities'
			Changes -02: no change, refresh only.
			Changes -03
			o Use of AS number 0.65535 (0x0000FFFF) instead of AS 0. This is
			better aligned with RFC 1997 which also uses AS 65535.
			o Remove the transitive flavor of assigned extended communities.
			RFC 1997 well-known standard communities to be used instead.
	Authors' Addresses		Authors' Addresses
	Bruno Decraene		Bruno Decraene
	France Telecom - Orange		France Telecom - Orange
	38 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.com		Email: bruno.decraene@orange.com
End of changes. 26 change blocks.
	59 lines changed or deleted		102 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/