idnits 2.17.1 draft-decraene-idr-reserved-extended-communities-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 17, 2010) is 4933 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC5226' is defined on line 168, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Decraene 3 Internet-Draft France Telecom - Orange 4 Intended status: Standards Track P. Francois 5 Expires: April 20, 2011 UCL 6 October 17, 2010 8 Reserved BGP extended communities 9 draft-decraene-idr-reserved-extended-communities-00 11 Abstract 13 This document assigns two BGP extended community types, one 14 transitive and one non-transitive. It also defines two IANA 15 registries in order to allow the allocation of reserved transitive 16 and non-transitive extended communities. These are similar to the 17 existing reserved (formerly Well-known) BGP communities defined in 18 RFC 1997 but provides an easier control of inter-AS community 19 advertissement as a community could be chosen as transitive or non- 20 transitive across ASes. 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 26 document are to be interpreted as described in RFC 2119 [RFC2119]. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on April 20, 2011. 45 Copyright Notice 47 Copyright (c) 2010 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 1. Introduction 62 RFC1997 [RFC1997] defines the BGP community attribute and some BGP 63 Well known communities whose meaning SHALL be understood by all 64 implementations compliant with RFC1997 [RFC1997]). New reserved 65 communities can be registred in the IANA "BGP Well-known Communities" 66 registry but can't anymore be considered as well known. 67 Implementations which do not reconize those new reserved communities 68 will propagate them from BGP neigbour to BGP neigbour and from AS to 69 AS with an unlimited scope. 71 RFC 4360[RFC4360] defines the BGP extended community attribute with a 72 structure including a type and a transitive bit "T". The transitive 73 bit, when set, allows to restrict the scope of the community within 74 an AS. Without structure, this can only be accomplished by 75 explicitly enumerating all community values that will be denied or 76 allowed and passed to BGP speakers in neighboring ASes. RFC 77 4360[RFC4360] defines IANA registries to allocate BGP Extended 78 Communities types. Each type is able to encode 2^48 or 2^56 values 79 depending on the type being extended or regular. It does not define 80 an IANA registry to allocate single reserved communities. Therefore, 81 one needing to reserve a single non-transitive extended community 82 would need to reserve an extended subtype which represents 2^48 83 communities. This would both waste the ressources and disable the 84 ability to define global policies on reserved communities, such as to 85 filter them out. 87 This document assigns two BGP extended community types, one 88 transitive and one non-transitive. It also defines two IANA 89 registries in order to allow the allocation of reserved transitive 90 and non-transitive extended communities. These are similar to the 91 existing reserved ("Well-known") BGP communities defined in RFC 1997 92 but provides an easier control of inter-AS community advertissement 93 as a community could be chosen as transitive or non-transitive across 94 ASes. 96 2. IANA Considerations 98 IANA is requested to assign, from the registry "BGP Extended 99 Communities Type - extended, transitive type", a type value TBD for 100 "BGP Reserved transitive extended communities": 102 Registry Name: BGP Extended Communities Type - extended, transitive 104 Name Type Value 105 ---- ---------- 106 BGP Reserved transitive extended communities TBD (e.g. 0x9000) 108 IANA is requested to assign, from the registry "BGP Extended 109 Communities Type - extended, non-transitive", a type value TBD for 110 "BGP Reserved non-transitive extended communities": 112 Registry Name: BGP Extended Communities Type - extended, non-transitive 114 Name Type Value 115 ---- ---------- 116 BGP Reserved non-transitive extended communities TBD (e.g. 0xd000) 118 Note to the IANA: suggested value for the two reserved BGP Extended 119 Communities extended type are 0x9000 and 0xd000. Otherwise, both 120 values should be identical, except for their T - Transitive bit (bit 121 1 as defined in RFC 4360 [RFC4360]). 123 The IANA is requested to create and maintain a registry entitled "BGP 124 Reserved transitive extended communities". 126 Registry Name: BGP Reserved transitive extended communities 128 Range Registration Procedures 129 --------------------------- ------------------------- 130 0x000000000000-FFFFFFFEFFFF Reserved 131 0xFFFFFFFF0000-00FFFFFF8000 First Come First Served 132 0x00FFFFFF8001-FFFFFFFFFFFF Standards Action/Early IANA Allocation 134 The IANA is requested to create and maintain a registry entitled "BGP 135 Reserved non-transitive extended communities". 137 Registry Name: BGP Reserved non-transitive extended communities 139 Range Registration Procedures 140 --------------------------- ------------------------- 141 0x000000000000-FFFFFFFEFFFF Reserved 142 0xFFFFFFFF0000-00FFFFFF8000 First Come First Served 143 0x00FFFFFF8001-FFFFFFFFFFFF Standards Action/Early IANA Allocation 145 An application may need both a transitive and non-transitive reserved 146 community. It may be beneficial to have the same value for both 147 communities. (Note that both extended community will still be 148 different as they will differ from their T bit). IThe IANA SHOULD 149 try to accomodate such request to have both a transitive and non- 150 transitive reserved community with the same value for both. 152 3. Security Considerations 154 This document defines IANA actions. In itself, it has no impact on 155 the security of the BGP protocol. 157 4. Normative References 159 [RFC1997] Chandrasekeran, R., Traina, P., and T. Li, "BGP 160 Communities Attribute", RFC 1997, August 1996. 162 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 163 Requirement Levels", BCP 14, RFC 2119, March 1997. 165 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 166 Communities Attribute", RFC 4360, February 2006. 168 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 169 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 170 May 2008. 172 Authors' Addresses 174 Bruno Decraene 175 France Telecom - Orange 176 38-40 rue du General Leclerc 177 Issy Moulineaux cedex 9 92794 178 France 180 Email: bruno.decraene@orange-ftgroup.com 182 Pierre Francois 183 UCL 184 Place Ste Barbe, 2 185 Louvain-la-Neuve 1348 186 BE 188 Email: francois@info.ucl.ac.be