idnits 2.17.1 draft-ietf-grow-wkc-behavior-04.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 (May 16, 2019) is 1806 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Borkenhagen 3 Internet-Draft AT&T 4 Intended status: Best Current Practice R. Bush 5 Expires: November 17, 2019 Internet Initiative Japan 6 R. Bonica 7 Juniper Networks 8 S. Bayraktar 9 Cisco Systems 10 May 16, 2019 12 Well-Known Community Policy Behavior 13 draft-ietf-grow-wkc-behavior-04 15 Abstract 17 Popular BGP implementations manipulate Well-known Communities 18 differently from one another. This results in difficulties for 19 operators. Network operators are encouraged to deploy consistent 20 community handling across their networks, taking the inconsistent 21 behaviors from the various BGP implementations they operate into 22 consideration. This document recommends specific action items to 23 limit future inconsistency, namely BGP implementors are expected to 24 not create any further inconsistencies from this point forward. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on November 17, 2019. 43 Copyright Notice 45 Copyright (c) 2019 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 62 3. Manipulation of Communities by Policy . . . . . . . . . . . . 3 63 4. Community Manipulation Policy Differences . . . . . . . . . . 3 64 5. Documentation of Vendor Implementations . . . . . . . . . . . 4 65 5.1. Note on an Inconsistency . . . . . . . . . . . . . . . . 5 66 6. Note for Those Writing RFCs for New Community-Like Attributes 5 67 7. Action Items . . . . . . . . . . . . . . . . . . . . . . . . 5 68 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 69 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 70 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 71 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 11.1. Normative References . . . . . . . . . . . . . . . . . . 6 73 11.2. Informative References . . . . . . . . . . . . . . . . . 6 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 76 1. Introduction 78 The BGP Communities Attribute was specified in [RFC1997] which 79 introduced the concept of Well-Known Communities. In hindsight, 80 [RFC1997] did not prescribe as fully as it should have how Well-Known 81 Communities may be manipulated by policies applied by operators. 82 Currently, implementations differ in this regard, and these 83 differences can result in inconsistent behaviors that operators find 84 difficult to identify and resolve. 86 This document describes the current behavioral differences in order 87 to assist operators in generating consistent community-manipulation 88 policies in a multi-vendor environment, and to prevent the 89 introduction of additional divergence in implementations. 91 This document recommends specific action items to limit future 92 inconsistency. 94 2. Requirements Language 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 98 "OPTIONAL" in this document are to be interpreted as described in BCP 99 14 [RFC2119] [RFC8174] when, and only when, they appear in all 100 capitals, as shown here. 102 3. Manipulation of Communities by Policy 104 [RFC1997] says: 106 "A BGP speaker receiving a route with the COMMUNITIES path attribute 107 may modify this attribute according to the local policy." 109 One basic operational need is to add or remove one or more 110 communities to the received set. The focus of this document is 111 another common operational need, to replace all communities with a 112 new set. To simplify this second case, most BGP policy 113 implementations provide syntax to "set" community that operators use 114 to mean "remove any/all communities present on the route, and apply 115 this set of communities instead." 117 Some operators prefer to write explicit policy to delete unwanted 118 communities rather than using "set;" i.e. using a "delete community 119 *:*" and then "add community x:y ..." configuration statements in an 120 attempt to replace all received communities. The same community 121 manipulation policy differences described in the following section 122 exist in both "set" and "delete community *:*" syntax. For 123 simplicity, the remainder of this document refers only to the "set" 124 behaviors, which we refer to collectively as each implementation's 125 '"set" directive.' 127 4. Community Manipulation Policy Differences 129 Vendor implementations differ in the treatment of certain Well-Known 130 communities when modified using the syntax to "set" the community. 131 Some replace all communities including the Well-Known ones with the 132 new set, while others replace all non-Well-Known Communities but do 133 not modify any Well-Known Communities that are present. 135 These differences result in what would appear to be identical policy 136 configurations having very different results on different platforms. 138 5. Documentation of Vendor Implementations 140 In this section we document the syntax and observed behavior of the 141 "set" directive in several popular BGP implementations. 143 In Juniper Networks' Junos OS, "community set" removes all received 144 communities, Well-Known or otherwise. 146 In Cisco Systems' IOS XR, "set community" removes all received 147 communities except for the following: 149 +-------------+-----------------------------------+ 150 | Numeric | Common Name | 151 +-------------+-----------------------------------+ 152 | 0:0 | internet | 153 | 65535:0 | graceful-shutdown | 154 | 65535:1 | accept-own rfc7611 | 155 | 65535:65281 | NO_EXPORT | 156 | 65535:65282 | NO_ADVERTISE | 157 | 65535:65283 | NO_EXPORT_SUBCONFED (or local-AS) | 158 +-------------+-----------------------------------+ 160 Communities not removed by Cisco IOS XR 162 Table 1 164 IOS XR does allow Well-Known communities to be removed by explicitly 165 enumerating each one, not in the aggregate; for example, "delete 166 community accept-own". Operators are advised to consult IOS XR 167 documentation and/or Cisco Systems support for full details. 169 On Extreme networks' Brocade NetIron: "set community X" removes all 170 received communities and sets X. 172 In Huawei's VRP product, "community set" removes all received 173 communities, well-Known or otherwise. 175 In OpenBSD's OpenBGPD, "set community" does not remove any 176 communities, Well-Known or otherwise. 178 Nokia's SR OS has several directives that operate on communities. 179 Its "set" directive is called using the "replace" keyword, replacing 180 all received communities, Well-Known or otherwise, with the specified 181 communities. 183 5.1. Note on an Inconsistency 185 In IOS XR, "set community" will not overwrite some well-known 186 communities. However, it will overwrite other well-known 187 communities. Conversely, In IOS XR, "set community" will not 188 overwrite some communities that are not well-known (e.g., (internet 189 == 0:0). 191 This merely notes an inconsistency. It is not a plea to 'protect' 192 the entire IANA list from "set community." 194 6. Note for Those Writing RFCs for New Community-Like Attributes 196 When establishing new [RFC1997]-like attributes (large communities, 197 wide communities, etc.), RFC authors should state how the new 198 community attribute is to be handled. 200 7. Action Items 202 Network operators are encouraged to limit their use of the "set" 203 directive (within reason), to improve the readability of their 204 configurations and hopefully to achieve behavioral consistency across 205 platforms. 207 Unfortunately, it would be operationally disruptive for vendors to 208 change their current implementations. 210 Vendors SHOULD clearly document the behavior of "set" directive in 211 their implementations. 213 Vendors MUST ensure that their implementations' "set" directive 214 treatment of any specific community does not change if/when that 215 community becomes a new Well-Known Community through future 216 standardization. For most implementations, this means that the "set" 217 directive MUST continue to remove the community; for those 218 implementations where the "set" directive removes no communities, 219 that behavior MUST continue. 221 Given the implementation inconsistencies described in this document, 222 network operators are urged never to rely on any implicit 223 understanding of a neighbor ASN's BGP community handling. I.e., 224 before announcing prefixes with NO_EXPORT or any other community to a 225 neighbor ASN, the operator should confirm with that neighbor how the 226 community will be treated. 228 8. Security Considerations 230 Surprising defaults and/or undocumented behaviors are not good for 231 security. This document attempts to remedy that. 233 Also see Appendix A of [RFC5706]. 235 9. IANA Considerations 237 This document has no IANA Considerations. 239 10. Acknowledgments 241 The authors thank Martijn Schmidt, Qin Wu for the Huawei data point, 242 Greg Hankins, Job Snijders, David Farmer, John Heasley, and Jakob 243 Heitz. 245 11. References 247 11.1. Normative References 249 [RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities 250 Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996, 251 . 253 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 254 Requirement Levels", BCP 14, RFC 2119, 255 DOI 10.17487/RFC2119, March 1997, 256 . 258 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 259 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 260 May 2017, . 262 11.2. Informative References 264 [RFC5706] Harrington, D., "Guidelines for Considering Operations and 265 Management of New Protocols and Protocol Extensions", 266 RFC 5706, DOI 10.17487/RFC5706, November 2009, 267 . 269 Authors' Addresses 270 Jay Borkenhagen 271 AT&T 272 200 Laurel Avenue South 273 Middletown, NJ 07748 274 United States of America 276 Email: jayb@att.com 278 Randy Bush 279 Internet Initiative Japan 280 5147 Crystal Springs 281 Bainbridge Island, WA 98110 282 United States of America 284 Email: randy@psg.com 286 Ron Bonica 287 Juniper Networks 288 2251 Corporate Park Drive 289 Herndon, VA 20171 290 US 292 Email: rbonica@juniper.net 294 Serpil Bayraktar 295 Cisco Systems 296 170 W. Tasman Drive 297 San Jose, CA 95134 298 United States of America 300 Email: serpil@cisco.com