idnits 2.17.1 draft-ietf-grow-large-communities-usage-02.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (February 16, 2017) is 2619 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 468 -- Looks like a reference, but probably isn't: '2' on line 470 -- Looks like a reference, but probably isn't: '3' on line 472 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Global Routing Operations J. Snijders 3 Internet-Draft J. Heasley 4 Intended status: Informational NTT 5 Expires: August 20, 2017 M. Schmidt 6 i3D.net 7 February 16, 2017 9 Usage of BGP Large Communities 10 draft-ietf-grow-large-communities-usage-02 12 Abstract 14 Examples and inspiration for operators for the use of BGP Large 15 Communities. 17 Requirements Language 19 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 21 document are to be interpreted as described in [RFC2119]. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on August 20, 2017. 40 Copyright Notice 42 Copyright (c) 2017 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. The Generic Design Pattern . . . . . . . . . . . . . . . . . 3 59 2.1. Informational Communities . . . . . . . . . . . . . . . . 3 60 2.2. Action Communities . . . . . . . . . . . . . . . . . . . 4 61 3. Examples of Informational Communities . . . . . . . . . . . . 4 62 3.1. Location . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3.1.1. An ISO 3166-1 numeric function . . . . . . . . . . . 4 64 3.1.2. An UNSD region function . . . . . . . . . . . . . . . 5 65 3.2. Relation . . . . . . . . . . . . . . . . . . . . . . . . 5 66 3.3. Combining Informational Communities . . . . . . . . . . . 6 67 4. Examples of Action Communities . . . . . . . . . . . . . . . 6 68 4.1. Selective NO_EXPORT . . . . . . . . . . . . . . . . . . . 6 69 4.1.1. Peer ASN Based Selective NO_EXPORT . . . . . . . . . 6 70 4.1.2. Location Based Selective NO_EXPORT . . . . . . . . . 7 71 4.2. Selective AS_PATH Prepending . . . . . . . . . . . . . . 7 72 4.2.1. Peer ASN Based Selective AS_PATH Prepending . . . . . 7 73 4.2.2. Location Based Selective AS_PATH Prepending . . . . . 8 74 4.3. Location based manipulation of LOCAL_PREF . . . . . . . . 8 75 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 76 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 77 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 78 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 79 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 80 8.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 11 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 83 1. Introduction 85 BGP Large Communities [RFC8092] provide a mechanism to signal opaque 86 information between Autonomous Systems. This document presents a set 87 of examples of how Large BGP Communities could be employed by an 88 operator to achieve various goals. This document draws from 89 experience in Operational Communities such as NANOG [1] and NLNOG 90 [2]. 92 The opaque nature of BGP Large Communities allows for rapid 93 deployment of new features or changes to the product. Operators are 94 encouraged to publicly publish and maintain documentation of the 95 purpose of each Large BGP Community, both informational and action, 96 that they support or are visible in looking glasses. 98 2. The Generic Design Pattern 100 BGP Large Communities are composed of a 4-octet Global Administrator 101 field followed by two 4-octet Local Data fields. Large BGP 102 Communities are compose three 4-octet fields. The first is the 103 Global Administrator field, whose value is the ASN of AS that has 104 defined the meaning of the remaining two 4-octet fields, the Local 105 Data fields. This document describes an approach defining these 106 fields as "ASN:Function:Parameter"-approach to fill the three fields. 108 In deployments of both BGP Communities [RFC1997] and BGP Large 109 Communities, two categories of Communities exist: 111 o Informational Communities 113 o Action Communities 115 For each, ideas are provided regarding the contents of each of the 116 three fields in BGP Large Communities. 118 Throughout the document a topology of four Autonomous Systems is used 119 to illustrate the usage of Communities in the following 120 configuration: 122 AS 65551 123 | 124 ^ 125 | 126 AS 64497 127 / \ 128 ^ \ 129 / ^ 130 AS 64498 \ 131 | | 132 `<->- AS 64499 134 AS 64497 obtains transit services from AS 65551, a 32-bit ASN. AS 135 64497 provides transit services to both AS 64498 and AS 64499. AS 136 64498 and AS 64499 maintain a peering relationship in which they only 137 exchange their customer routes. 139 2.1. Informational Communities 141 Informational Communites are labels for attributes such as origin of 142 the route announcement, the relation with the EBGP neighbor or for 143 instance the intended propagation audience. Informational 144 Communities also assist in network operations such as debugging. 146 The Global Administrator field is set to the ASN which is marking the 147 routes with the Informational Communities. For example, AS 64497 148 might add a community with the GA 64497 to a route learned from an 149 iBGP or eBGP peer that means that the route was learned from or 150 originated by a device in the Netherlands. 152 In general the intended audience of Informational Communities are 153 downstream networks and the Global Administrator itself, but any 154 Autonomous System could benefit from receiving these communities. 156 2.2. Action Communities 158 Action Communities are attached to routes to request non-default 159 behaviour in this, a conferation or an external AS. Action 160 Communities could be used to change the route's propagation 161 characteristics, the LOCAL_PREFENCE or the number of AS_PATH prepends 162 to add when exporting or importing a route. 164 The Global Administrator field is set to the ASN which is expected to 165 perform the action. For instance, AS 64499 might add a Large 166 Community with the GA 64497 to signal AS 64497 to perform an action 167 upon that route. 169 In general the intended audience of Action Communities is an upstream 170 provider, but realistically could be any AS willing to act upon it. 172 3. Examples of Informational Communities 174 3.1. Location 176 AS 64497 can inform its downstream networks about the geographical 177 entity where AS 64497 learned a route by marking the route with BGP 178 Large Communities following one or a combination of the following 179 schemes. 181 3.1.1. An ISO 3166-1 numeric function 183 AS 64497 could assign a value of 1 to the first Local Data field to 184 designate the function of the second Local Data field as ISO-3166-1 185 numeric country identifiers. 187 +---------------------+-------------------------------------------+ 188 | BGP Large Community | Description | 189 +---------------------+-------------------------------------------+ 190 | 64497:1:528 | Route learned in Netherlands | 191 | 64497:1:392 | Route learned in Japan | 192 | 64497:1:840 | Route learned in United States of America | 193 +---------------------+-------------------------------------------+ 195 Example documentation for AS 64497 using Informational Communities 196 describing the origin of routes using ISO 3166-1 numeric identifiers. 198 Table 1: Information: ISO 3166-1 200 3.1.2. An UNSD region function 202 AS 64497 could assign a value of 2 to the first Local Data field to 203 designate the function of the parameter in the second Local Data 204 field as an identifier for the macro geographical (continental) 205 regions, geographical sub-regions, or selected economic and other 206 groupings following a set of published identifiers by the United 207 Nations Statistics Division [3]. 209 +---------------------+-------------------------------+ 210 | BGP Large Community | Description | 211 +---------------------+-------------------------------+ 212 | 64497:2:2 | Route learned in Africa | 213 | 64497:2:9 | Route learned in Oceania | 214 | 64497:2:145 | Route learned in Western Asia | 215 | 64497:2:150 | Route learned in Europe | 216 +---------------------+-------------------------------+ 218 Example documentation for AS 64497 using Informational Communities 219 describing the origin of routes using numeric identifiers provided by 220 the UN Statistics Division. 222 Table 2: Information: Regions 224 3.2. Relation 226 AS 64497 could assign a value of 3 to the first Local Data field to 227 designate that the second Local Data field contains an identifier 228 showing the relation with the EBGP neighbor from whom the route was 229 received. 231 +---------------------+-----------------------------------------+ 232 | BGP Large Community | Description | 233 +---------------------+-----------------------------------------+ 234 | 64497:3:1 | Route learned from a customer | 235 | 64497:3:2 | Route learned from a peering partner | 236 | 64497:3:3 | Route learned from an upstream provider | 237 +---------------------+-----------------------------------------+ 239 Example documentation for AS 64497 using Informational Communities 240 describing the relation with the ASN from which the route was 241 received. 243 Table 3: Information: Relation 245 3.3. Combining Informational Communities 247 Multiple Informational Communities can be tagged on a route, for 248 example: a route learned in the Netherlands from a customer can 249 contain both 64497:1:528 and 64497:2:150 and 64497:3:1. 251 4. Examples of Action Communities 253 4.1. Selective NO_EXPORT 255 As part of the commercial agreement between AS 64497 and AS 64498, AS 256 64497 might offer AS 64498 certain BGP Traffic Engineering features 257 such as selectively not export routes learned from 64498 to certain 258 EBGP neighbors of AS 64497. 260 4.1.1. Peer ASN Based Selective NO_EXPORT 262 AS 64497 might assign function identifier 4 to allow preventing 263 propagation of routes to the ASN listed in the second Local Data 264 field. 266 +---------------------+---------------------------------+ 267 | BGP Large Community | Description | 268 +---------------------+---------------------------------+ 269 | 64497:4:2914 | Do not export route to AS 2914 | 270 | 64497:4:7018 | Do not export route to AS 7018 | 271 | 64497:4:65551 | Do not export route to AS 65551 | 272 +---------------------+---------------------------------+ 274 Example documentation for AS 64497 offering Action Communities to 275 limit propagation of routes based on the Peer ASN described in the 276 third field. 278 Table 4: Action: Peer ASN NO_EXPORT 280 4.1.2. Location Based Selective NO_EXPORT 282 AS 64497 might assign function identifier 5 to allow its customers to 283 request selectively not exporting routes on EBGP sessions within a 284 certain geographical area. This example follows the ISO 3166-1 285 numeric encoding. 287 +------------------+------------------------------------------------+ 288 | BGP Large | Description | 289 | Community | | 290 +------------------+------------------------------------------------+ 291 | 64497:5:528 | Do not export to EBGP neighbors in the | 292 | | Netherlands | 293 | 64497:5:392 | Do not export to EBGP neighbors in Japan | 294 | 64497:5:840 | Do not export to EBGP neighbors in United | 295 | | States of America | 296 +------------------+------------------------------------------------+ 298 Example documentation for AS 64497 offering Action Communities to 299 trigger NO_EXPORT on routes only when propagating the route to a 300 certain geographical region. 302 Table 5: Action: NO_EXPORT in Region 304 4.2. Selective AS_PATH Prepending 306 As part of the commercial agreement between AS 64497 and AS 64498, AS 307 64497 might offer AS 64498 certain BGP Traffic Engineering features 308 such as selectively prepending the AS_PATH with 64497's ASN to 309 certain EBGP neighbors of AS 64497. 311 4.2.1. Peer ASN Based Selective AS_PATH Prepending 313 AS 64497 might assign function identifier 6 to allow prepending the 314 AS_PATH on propagation of routes to the ASN listed in the second 315 Local Data field. 317 +---------------------+------------------------------------------+ 318 | BGP Large Community | Description | 319 +---------------------+------------------------------------------+ 320 | 64497:6:2914 | Prepend 64497 once on export to AS 2914 | 321 | 64497:6:7018 | Prepend 64497 once on export to AS 7018 | 322 | 64497:6:65551 | Prepend 64497 once on export to AS 65551 | 323 +---------------------+------------------------------------------+ 325 Example documentation for AS 64497 offering Action Communities to 326 trigger prepending of the AS_PATH only when propagating the route to 327 a certain Peer ASN. 329 Table 6: Action: Prepend to Peer ASN 331 4.2.2. Location Based Selective AS_PATH Prepending 333 AS 64497 might assign function identifier 7 to allow prepending of 334 the AS_PATH on propagation of routes to on any EBGP neighbor's 335 interconnection in the geographical entity listed in the second Local 336 Data field. This example follows the ISO 3166-1 numeric regions 337 codes in the Local Data 2 field. 339 +------------------+------------------------------------------------+ 340 | BGP Large | Description | 341 | Community | | 342 +------------------+------------------------------------------------+ 343 | 64497:7:528 | Prepend once to EBGP neighbors in the | 344 | | Netherlands | 345 | 64497:7:392 | Prepend once to EBGP neighbors in Japan | 346 | 64497:7:840 | Prepend once to EBGP neighbors in United | 347 | | States of America | 348 +------------------+------------------------------------------------+ 350 Example documentation for AS 64497 offering Action Communities to 351 trigger prepending of the AS_PATH only when propagating the route to 352 a certain geographical region. 354 Table 7: Action: Prepend in Region 356 4.3. Location based manipulation of LOCAL_PREF 358 In some cases, it can be desirable for an autonomous system to allow 359 adjacent Autonomous Systems to directly influence the degree of 360 preference associated with a route, usually expressed within the 361 LOCAL_PREF attribute. 363 Furthermore, in the case of large networks spanning significant 364 geography, it is often also useful to be able to extend this 365 capability and scope its effect to a geographic region. This is a 366 more powerful mechanism than AS_PATH prepending, but since degree of 367 preference determines BGP route selection and thus onward 368 advertisement, it can also be self-limiting in its scope. 370 Since the LOCAL_PREF attribute which influences degree of preference 371 is locally significant within each autonomous system, it is not 372 usually practical or useful to compare LOCAL_PREF attribute values 373 between autonomous systems. Instead it can be useful to classify the 374 major types of route likely to exist within an autonomous system's 375 routing hierarchy and provide an ability to set one's route to that 376 preference: 378 o A qualified customer route. Usually the highest preference. 380 o A peer, or network-share, route. A co-operating network provider 381 engaged in a partnership for customer coverage ("peering"). 383 o A last resort, or backup route. 385 It is entirely possible that some providers may have more classes of 386 route preference but it is possible to codify both the route 387 preference class and the regional scope within the Local Data fields 388 of the Large Community attribute. 390 For example, AS64497 might establish the following function 391 identifiers to set route preference class, which could allow pairing 392 with a location or peer-based operand to determine scope. 394 +----------+-----------------------------------------------+ 395 | Function | Preference Class | 396 +----------+-----------------------------------------------+ 397 | 10 | Qualified customer route. Highest preference. | 398 | 15 | Peering partner. Median preference. | 399 | 19 | Route of last resort. Lowest preference. | 400 +----------+-----------------------------------------------+ 402 Table 8: Action: Preference Function Identifiers 404 Once established, these route preference setting functions can be 405 linked with a scoping operand such as per-peer or per-location based 406 identifiers in order to provide AS64497's customers with a 407 comprehensive and rich toolset to influence route preference. 409 +--------------------+----------------------------------------------+ 410 | BGP Large | Description | 411 | Community | | 412 +--------------------+----------------------------------------------+ 413 | 64497:15:528 | Set as peer route in Netherlands | 414 | 64497:19:840 | Set as backup route in United States of | 415 | | America | 416 +--------------------+----------------------------------------------+ 418 Table 9: Action: Regional Preference Communities 420 Since the degree of preference influences BGP best path selection 421 (which in turn influences onward route propagation) Operators should 422 take special care with a traffic engineering tool such as location 423 based local preference influence (BGP Wedgies [RFC4264]). 425 5. Security Considerations 427 Network operators should note the recommendations in Section 11 of 428 BGP Operations and Security [RFC7454]. 430 6. IANA Considerations 432 None. 434 7. Acknowledgements 436 The authors would like to gratefully acknowledge the insightful 437 comments, contributions, critique and support from John Heasley, Adam 438 Chappell, Jonathan Stewart, and Will Hargrave. 440 8. References 442 8.1. Normative References 444 [RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities 445 Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996, 446 . 448 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 449 Requirement Levels", BCP 14, RFC 2119, 450 DOI 10.17487/RFC2119, March 1997, 451 . 453 [RFC4264] Griffin, T. and G. Huston, "BGP Wedgies", RFC 4264, 454 DOI 10.17487/RFC4264, November 2005, 455 . 457 [RFC7454] Durand, J., Pepelnjak, I., and G. Doering, "BGP Operations 458 and Security", BCP 194, RFC 7454, DOI 10.17487/RFC7454, 459 February 2015, . 461 [RFC8092] Heitz, J., Ed., Snijders, J., Ed., Patel, K., Bagdonas, 462 I., and N. Hilliard, "BGP Large Communities Attribute", 463 RFC 8092, DOI 10.17487/RFC8092, February 2017, 464 . 466 8.2. URIs 468 [1] http://nanog.net 470 [2] http://nlnog.net 472 [3] http://unstats.un.org/unsd/methods/m49/m49regin.htm 474 Authors' Addresses 476 Job Snijders 477 NTT Communications 478 Theodorus Majofskistraat 100 479 Amsterdam 1065 SZ 480 The Netherlands 482 Email: job@ntt.net 484 John Heasley 485 NTT Communications 486 12160 NW Coleman Drive 487 Portland, OR 97229 488 United States of America 490 Email: heas@shrubbery.net 492 Martijn Schmidt 493 i3D.net 494 Rivium 1e Straat 1 495 Capelle aan den IJssel 2909 LE 496 NL 498 Email: martijnschmidt@i3d.net