idnits 2.17.1 draft-ietf-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 (February 07, 2011) is 4820 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 178, 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: August 11, 2011 UCL 6 February 07, 2011 8 Reserved BGP extended communities 9 draft-ietf-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 advertisement 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 August 11, 2011. 45 Copyright Notice 47 Copyright (c) 2011 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] defines the BGP community attribute and some BGP Well known 63 communities whose meaning SHALL be understood by all compliant 64 implementations. New reserved communities can be registered in the 65 IANA "BGP Well-known Communities" registry but it can't be assumed 66 anymore that they will be known by all BGP implementations. 67 Implementations or BGP policies which recognize them will behave as 68 specified. Implementation which do not recognize those new reserved 69 communities will propagate them from BGP neighbor to BGP neighbor and 70 from AS to AS with an unlimited scope. 72 There is currently no agreed way to reserve a non transitive well 73 known community: 75 o [RFC1997] defines BGP Well-known communities with no structure to 76 set their transitiveness across ASes. Without structure, non 77 transitive communities can only be filtered by explicitly 78 enumerating all community values that will be denied or allowed to 79 BGP speakers in neighboring ASes. This is not satisfactory as 80 this would require upgrading all border routers to understand this 81 community before its first usage. 83 o [RFC4360] defines the BGP extended community attribute with a 84 structure including a type and a transitive bit "T". The 85 transitive bit, when set, allows to restrict the scope of the 86 community within an AS. But their is no IANA registry to allocate 87 a (single) well known extended community. RFC 4360 [RFC4360] 88 defines IANA registries to allocate BGP Extended Communities 89 types. Each type is able to encode 2^48 or 2^56 values depending 90 on the type being extended or regular. Therefore, one needing to 91 reserve a single non-transitive extended community would need to 92 reserve an extended subtype which represents 2^48 communities, 93 while a single value is used. This would both waste the resources 94 and disable the ability to define global policies on reserved 95 communities, such as to filter them out. 97 To address this limitation, this document assigns two BGP extended 98 community types, one transitive and one non-transitive. It also 99 defines two IANA registries in order to allow the allocation of 100 reserved transitive and non-transitive extended communities. These 101 are similar to the existing Well-known BGP communities defined in RFC 102 1997 but provides a control on inter-AS community advertisement as a 103 community could be chosen as transitive or non-transitive across 104 ASes. 106 2. IANA Considerations 108 IANA is requested to assign, from the registry "BGP Extended 109 Communities Type - extended, transitive type", a type value TBD for 110 "BGP Reserved transitive extended communities": 112 Registry Name: BGP Extended Communities Type - extended, transitive 114 Name Type Value 115 ---- ---------- 116 BGP Reserved transitive extended communities TBD (e.g. 0x9000) 118 IANA is requested to assign, from the registry "BGP Extended 119 Communities Type - extended, non-transitive", a type value TBD for 120 "BGP Reserved non-transitive extended communities": 122 Registry Name: BGP Extended Communities Type - extended, non-transitive 124 Name Type Value 125 ---- ---------- 126 BGP Reserved non-transitive extended communities TBD (e.g. 0xd000) 128 Note to the IANA: suggested value for the two reserved BGP Extended 129 Communities extended type are 0x9000 and 0xd000. Otherwise, both 130 values should be identical, except for their T - Transitive bit (bit 131 1 as defined in [RFC4360]). 133 The IANA is requested to create and maintain a registry entitled "BGP 134 Reserved transitive extended communities": 136 Registry Name: BGP Reserved transitive extended communities 138 Range Registration Procedures 139 --------------------------- ------------------------- 140 0x000000000000-FFFFFFFEFFFF Reserved 141 0xFFFFFFFF0000-00FFFFFF8000 First Come First Served 142 0x00FFFFFF8001-FFFFFFFFFFFF Standards Action/Early IANA Allocation 144 The IANA is requested to create and maintain a registry entitled "BGP 145 Reserved non-transitive extended communities": 147 Registry Name: BGP Reserved non-transitive extended communities 149 Range Registration Procedures 150 --------------------------- ------------------------- 151 0x000000000000-FFFFFFFEFFFF Reserved 152 0xFFFFFFFF0000-00FFFFFF8000 First Come First Served 153 0x00FFFFFF8001-FFFFFFFFFFFF Standards Action/Early IANA Allocation 155 An application may need both a transitive and non-transitive reserved 156 community. It may be beneficial to have the same value for both 157 communities. (Note that both extended community will still be 158 different as they will differ from their T bit). The IANA SHOULD try 159 to accommodate such request to have both a transitive and non- 160 transitive reserved community with the same value for both. 162 3. Security Considerations 164 This document defines IANA actions. In itself, it has no impact on 165 the security of the BGP protocol. 167 4. Normative References 169 [RFC1997] Chandrasekeran, R., Traina, P., and T. Li, "BGP 170 Communities Attribute", RFC 1997, August 1996. 172 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 173 Requirement Levels", BCP 14, RFC 2119, March 1997. 175 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 176 Communities Attribute", RFC 4360, February 2006. 178 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 179 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 180 May 2008. 182 Authors' Addresses 184 Bruno Decraene 185 France Telecom - Orange 186 38-40 rue du General Leclerc 187 Issy Moulineaux cedex 9 92794 188 France 190 Email: bruno.decraene@orange-ftgroup.com 192 Pierre Francois 193 UCL 194 Place Ste Barbe, 2 195 Louvain-la-Neuve 1348 196 BE 198 Email: francois@info.ucl.ac.be