--- 1/draft-ietf-idr-reserved-extended-communities-00.txt 2011-05-23 18:15:17.000000000 +0200 +++ 2/draft-ietf-idr-reserved-extended-communities-01.txt 2011-05-23 18:15:17.000000000 +0200 @@ -1,31 +1,33 @@ Network Working Group B. Decraene Internet-Draft France Telecom - Orange Intended status: Standards Track P. Francois -Expires: August 11, 2011 UCL - February 07, 2011 +Expires: November 24, 2011 Universite catholique de Louvain + May 23, 2011 - Reserved BGP extended communities - draft-ietf-idr-reserved-extended-communities-00 + Assigned BGP extended communities + draft-ietf-idr-reserved-extended-communities-01 Abstract - 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 reserved (formerly Well-known) BGP communities defined in - RFC 1997 but provides an easier control of inter-AS community + This document defines two IANA registries in order to assign + transitive and non-transitive extended communities from. These are + similar to the existing well-known BGP communities defined in RFC + 1997 but provide an easier control of inter-AS community advertisement as a community could be chosen as transitive or non- 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 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. @@ -33,24 +35,23 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of @@ -52,147 +53,152 @@ (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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 - implementations. New reserved communities can be registered in the - IANA "BGP Well-known Communities" registry but it can't be assumed - anymore that they will be known by all BGP implementations. - Implementations or BGP policies which recognize them will behave as - specified. Implementation which do not recognize those new reserved - communities will propagate them from BGP neighbor to BGP neighbor and - from AS to AS with an unlimited scope. + implementations. New communities can be registered in the IANA "BGP + Well-known Communities" registry but it can't be assumed anymore that + they will be known by all BGP implementations. Implementations or + BGP policies which recognize them will behave as specified. + Implementations which do not recognize those new reserved communities + will propagate them from BGP neighbor to BGP neighbor and from AS to + 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: - o [RFC1997] defines BGP Well-known communities with no structure to - set their transitiveness across ASes. Without structure, non - transitive communities can only be filtered by explicitly - enumerating all community values that will be denied or allowed to - BGP speakers in neighboring ASes. This is not satisfactory as - this would require upgrading all border routers to understand this - community before its first usage. + On one hand, [RFC1997] defines BGP Well-known communities with no + structure to set their transitiveness across ASes. Without + structure, communities can only be filtered by explicitly enumerating + all community values that will be denied or allowed to BGP speakers + in neighboring ASes. This is not satisfactory as this would require + upgrading all border routers to understand this community before its + 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 + 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 - 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 + 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 - Communities Type - extended, transitive type", a type value TBD for - "BGP Reserved transitive extended communities": + To address this limitation, this document defines two IANA registries + in order to allow the registration of transitive and non-transitive + 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 - ---- ---------- - BGP Reserved transitive extended communities TBD (e.g. 0x9000) + [I-D.ietf-idr-as4octet-extcomm-generic-subtype] defines a generic + sub-type for the four-octet AS specific extended community. The + 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 - Communities Type - extended, non-transitive", a type value TBD for - "BGP Reserved non-transitive extended communities": + This document updates [I-D.ietf-idr-as4octet-extcomm-generic-subtype] + and defines the use of the Local Administrator sub-field when the AS + 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 - ---- ---------- - BGP Reserved non-transitive extended communities TBD (e.g. 0xd000) + 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 + Well-Known communities. - Note to the IANA: suggested value for the two reserved BGP Extended - 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]). +3. IANA Considerations - The IANA is requested to create and maintain a registry entitled "BGP - Reserved transitive extended communities": + The IANA is requested to create and maintain a registry entitled + "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 - --------------------------- ------------------------- - 0x000000000000-FFFFFFFEFFFF Reserved - 0xFFFFFFFF0000-00FFFFFF8000 First Come First Served - 0x00FFFFFF8001-FFFFFFFFFFFF Standards Action/Early IANA Allocation + ----------- ------------------------- + 0x0000-8000 First Come First Served + 0x8001-FFFF Standards Action/Early IANA Allocation - The IANA is requested to create and maintain a registry entitled "BGP - Reserved non-transitive extended communities": + The IANA is requested to create and maintain a registry entitled + "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 - --------------------------- ------------------------- - 0x000000000000-FFFFFFFEFFFF Reserved - 0xFFFFFFFF0000-00FFFFFF8000 First Come First Served - 0x00FFFFFF8001-FFFFFFFFFFFF Standards Action/Early IANA Allocation + ----------- ------------------------- + 0x0000-8000 First Come First Served + 0x8001-FFFF Standards Action/Early IANA Allocation - An application may need both a transitive and non-transitive reserved - community. It may be beneficial to have the same value for both - communities. (Note that both extended community will still be + An application may need both a transitive and a non-transitive + community and it may be beneficial to have the same value for both + communities. (Note that both extended communities will still be different as they will differ from their T bit). The IANA SHOULD try - to accommodate such request to have both a transitive and non- - transitive reserved community with the same value for both. + to accommodate such request to get both a transitive and non- + 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 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 Communities Attribute", RFC 1997, August 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, February 2006. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. Authors' Addresses Bruno Decraene France Telecom - Orange - 38-40 rue du General Leclerc + 38 rue du General Leclerc Issy Moulineaux cedex 9 92794 France Email: bruno.decraene@orange-ftgroup.com Pierre Francois - UCL + Universite catholique de Louvain Place Ste Barbe, 2 Louvain-la-Neuve 1348 BE Email: francois@info.ucl.ac.be