idnits 2.17.1 draft-ietf-grow-large-communities-usage-01.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 (December 7, 2016) is 2696 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 465 -- Looks like a reference, but probably isn't: '2' on line 467 -- Looks like a reference, but probably isn't: '3' on line 469 == Outdated reference: A later version (-12) exists of draft-ietf-idr-large-community-11 Summary: 0 errors (**), 0 flaws (~~), 3 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 NTT 4 Intended status: Informational M. Schmidt 5 Expires: June 10, 2017 i3D.net 6 December 7, 2016 8 Usage of Large BGP Communities 9 draft-ietf-grow-large-communities-usage-01 11 Abstract 13 Examples and inspiration for operators on how to use Large BGP 14 Communities. 16 Requirements Language 18 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 19 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 20 document are to be interpreted as described in [RFC2119]. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on June 10, 2017. 39 Copyright Notice 41 Copyright (c) 2016 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. The Generic Design Pattern . . . . . . . . . . . . . . . . . 3 58 2.1. Informational Communities . . . . . . . . . . . . . . . . 3 59 2.2. Action Communities . . . . . . . . . . . . . . . . . . . 4 60 3. Examples of Informational Communities . . . . . . . . . . . . 4 61 3.1. Location . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3.1.1. An ISO 3166-1 numeric function . . . . . . . . . . . 4 63 3.1.2. An UNSD region function . . . . . . . . . . . . . . . 5 64 3.2. Relation . . . . . . . . . . . . . . . . . . . . . . . . 5 65 3.3. Combining Informational Communities . . . . . . . . . . . 6 66 4. Examples of Action Communities . . . . . . . . . . . . . . . 6 67 4.1. Selective NO_EXPORT . . . . . . . . . . . . . . . . . . . 6 68 4.1.1. Peer ASN Based Selective NO_EXPORT . . . . . . . . . 6 69 4.1.2. Location Based Selective NO_EXPORT . . . . . . . . . 7 70 4.2. Selective AS_PATH Prepending . . . . . . . . . . . . . . 7 71 4.2.1. Peer ASN Based Selective AS_PATH Prepending . . . . . 7 72 4.2.2. Location Based Selective AS_PATH Prepending . . . . . 8 73 4.3. Location based manipulation of LOCAL_PREF . . . . . . . . 8 74 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 76 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 77 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 78 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 79 8.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 11 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 82 1. Introduction 84 Large BGP Communities [I-D.ietf-idr-large-community] provide a 85 mechanism to signal opaque information between Autonomous Systems. 86 This document presents a set of examples on how Large BGP Communities 87 could be implemented by an operator to achieve various goals. This 88 document draws from experience in Operational Communities such as 89 NANOG [1] and NLNOG [2]. 91 The opaque nature of Large BGP Communities allows for rapid 92 deployment of new features or changes to the product. Operators are 93 encouraged to publicly publish an up to date version of their routing 94 policy in which they document what each Large BGP Community means. 96 2. The Generic Design Pattern 98 Large BGP Communities are composed of a 4-octet Global Administrator 99 field followed by two 4-octet Local Data fields. The design pattern 100 described in this document uses a "ASN:Function:Parameter"-approach 101 to fill the three fields. 103 In deployments of both BGP Communities [RFC1997] and Large BGP 104 Communities, two categories of Communities are recognised: 106 o Informational Communities 108 o Action Communities 110 For each context ideas are provided regarding the contents of each of 111 the three fields in Large BGP Communities. 113 Throughout the document a topology of four Autonomous Systems is used 114 to illustrate the usage of Communities in the following 115 configuration: 117 AS 65551 118 | 119 ^ 120 | 121 AS 64497 122 / \ 123 ^ \ 124 / ^ 125 AS 64498 \ 126 | | 127 `<->- AS 64499 129 AS 64497 obtains transit services from AS 65551. AS 64497 provides 130 transit services to both AS 64498 and AS 64499. AS 64498 and AS 131 64499 maintain a peering relation in which they only exchange their 132 customer routes. 134 2.1. Informational Communities 136 Informational Communites serve as markers regarding the origin of the 137 route announcement, the relation with the EBGP neighbor or for 138 instance the intended propagation audience. Informational 139 Communities also assist in network operations such as debugging. 141 The Global Administrator field is set to the ASN which is marking the 142 routes with the Informational Communities. As an example: on a route 143 which AS 64497 announces to AS 64498, AS 64497 might add the Large 144 BGP Community 64497:100:31 to signal to AS 64498 that the route was 145 learned in the Netherlands. 147 In general the intended audience of Informational Communities are 148 downstream networks, but any adjacent Autonomous System could benefit 149 from receiving these communities. 151 2.2. Action Communities 153 Action Communities are attached to routes to request non-default 154 behaviour in an adjacent Autonomous System. For instance, Action 155 Communities are used to change the route's propagation 156 characteristics, the route's LOCAL_PREF value or the amount of 157 AS_PATH prepends that should be added when exporting or importing a 158 route. 160 The Global Administrator field is set to the ASN which is expected to 161 perform a non-default action upon receiving the route. For instance, 162 if AS 64499 would want to request AS 64497 to lower the 163 LOCAL_PREFERENCE below the default, AS 64499 could tag the route with 164 64497:20:50. 166 In general the intended audience of Action Communities is an upstream 167 provider. 169 3. Examples of Informational Communities 171 3.1. Location 173 AS 64497 can inform its downstream networks about the geographical 174 entity where AS 64497 learned a route by marking the route with Large 175 BGP Communities following one or a combination of the following 176 schemes. 178 3.1.1. An ISO 3166-1 numeric function 180 AS 64497 could assign a value of 1 to the first Local Data field to 181 designate the function of the parameter in the second Local Data 182 field as ISO-3166-1 numeric country identifiers. 184 +---------------------+-------------------------------------------+ 185 | Large BGP Community | Meaning | 186 +---------------------+-------------------------------------------+ 187 | 64497:1:528 | Route learned in Netherlands | 188 | 64497:1:392 | Route learned in Japan | 189 | 64497:1:840 | Route learned in United States of America | 190 +---------------------+-------------------------------------------+ 192 Example documentation for AS 64497 using Informational Communties 193 describing the origin of routes using ISO 3166-1 numeric identifiers. 195 Table 1: Information: ISO 3166-1 197 3.1.2. An UNSD region function 199 AS 64497 could assign a value of 2 to the first Local Data field to 200 designate the function of the parameter in the second Local Data 201 field as an identifier for the macro geographical (continental) 202 regions, geographical sub-regions, or selected economic and other 203 groupings following a set of published identifiers by the United 204 Nations Statistics Division [3]. 206 +---------------------+-------------------------------+ 207 | Large BGP Community | Meaning | 208 +---------------------+-------------------------------+ 209 | 64497:2:2 | Route learned in Africa | 210 | 64497:2:9 | Route learned in Oceania | 211 | 64497:2:145 | Route learned in Western Asia | 212 | 64497:2:150 | Route learned in Europe | 213 +---------------------+-------------------------------+ 215 Example documentation for AS 64497 using Informational Communties 216 describing the origin of routes using numeric identifiers provided by 217 the UN Statistics Division. 219 Table 2: Information: Regions 221 3.2. Relation 223 AS 64497 could assign a value of 3 to the first Local Data field to 224 designate that the second Local Data field contains an identifier 225 showing the relation with the EBGP neighbor from whom the route was 226 received. 228 +---------------------+-----------------------------------------+ 229 | Large BGP Community | Meaning | 230 +---------------------+-----------------------------------------+ 231 | 64497:3:1 | Route learned from a customer | 232 | 64497:3:2 | Route learned from a peering partner | 233 | 64497:3:3 | Route learned from an upstream provider | 234 +---------------------+-----------------------------------------+ 236 Example documentation for AS 64497 using Informational Communties 237 describing the relation with the ASN from which the route was 238 received. 240 Table 3: Information: Relation 242 3.3. Combining Informational Communities 244 Multiple Informational Communities can be tagged on a route, for 245 example: a route learned in the Netherlands from a customer can 246 contain both 64497:1:528 and 64497:2:150 and 64497:3:1. 248 4. Examples of Action Communities 250 4.1. Selective NO_EXPORT 252 As part of the commercial agreement between AS 64497 and AS 64498, AS 253 64497 might offer AS 64498 certain BGP Traffic Engineering features 254 such as selectively not export routes learned from 64498 to certain 255 EBGP neighbors of AS 64497. 257 4.1.1. Peer ASN Based Selective NO_EXPORT 259 AS 64497 might assign function identifier 4 to allow preventing 260 propagation of routes to the ASN listed in the second Local Data 261 field. 263 +---------------------+---------------------------------+ 264 | Large BGP Community | Meaning | 265 +---------------------+---------------------------------+ 266 | 64497:4:2914 | Do not export route to AS 2914 | 267 | 64497:4:7018 | Do not export route to AS 7018 | 268 | 64497:4:65551 | Do not export route to AS 65551 | 269 +---------------------+---------------------------------+ 271 Example documentation for AS 64497 offering Action Communties to 272 limit propagation of routes based on the Peer ASN described in the 273 third field. 275 Table 4: Action: Peer ASN NO_EXPORT 277 4.1.2. Location Based Selective NO_EXPORT 279 AS 64497 might assign function identifier 5 to allow its customers to 280 request selectively not exporting routes on EBGP sessions within a 281 certain geographical area. This example follows the ISO 3166-1 282 numeric encoding. 284 +------------------+------------------------------------------------+ 285 | Large BGP | Meaning | 286 | Community | | 287 +------------------+------------------------------------------------+ 288 | 64497:5:528 | Do not export to EBGP neighbors in the | 289 | | Netherlands | 290 | 64497:5:392 | Do not export to EBGP neighbors in Japan | 291 | 64497:5:840 | Do not export to EBGP neighbors in United | 292 | | States of America | 293 +------------------+------------------------------------------------+ 295 Example documentation for AS 64497 offering Action Communties to 296 trigger NO_EXPORT on routes only when propagating the route to a 297 certain geographical region. 299 Table 5: Action: NO_EXPORT in Region 301 4.2. Selective AS_PATH Prepending 303 As part of the commercial agreement between AS 64497 and AS 64498, AS 304 64497 might offer AS 64498 certain BGP Traffic Engineering features 305 such as selectively prepending the AS_PATH with 64497's ASN to 306 certain EBGP neighbors of AS 64497. 308 4.2.1. Peer ASN Based Selective AS_PATH Prepending 310 AS 64497 might assign function identifier 6 to allow prepending the 311 AS_PATH on propagation of routes to the ASN listed in the second 312 Local Data field. 314 +---------------------+------------------------------------------+ 315 | Large BGP Community | Meaning | 316 +---------------------+------------------------------------------+ 317 | 64497:6:2914 | Prepend 64497 once on export to AS 2914 | 318 | 64497:6:7018 | Prepend 64497 once on export to AS 7018 | 319 | 64497:6:65551 | Prepend 64497 once on export to AS 65551 | 320 +---------------------+------------------------------------------+ 322 Example documentation for AS 64497 offering Action Communties to 323 trigger prepending of the AS_PATH only when propagating the route to 324 a certain Peer ASN. 326 Table 6: Action: Prepend to Peer ASN 328 4.2.2. Location Based Selective AS_PATH Prepending 330 AS 64497 might assign function identifier 7 to allow prepending of 331 the AS_PATH on propagation of routes to on any EBGP neighbor's 332 interconnection in the geographical entity listed in the second Local 333 Data field. This example follows the ISO 3166-1 numeric regions 334 codes in the Local Data 2 field. 336 +------------------+------------------------------------------------+ 337 | Large BGP | Meaning | 338 | Community | | 339 +------------------+------------------------------------------------+ 340 | 64497:7:528 | Prepend once to EBGP neighbors in the | 341 | | Netherlands | 342 | 64497:7:392 | Prepend once to EBGP neighbors in Japan | 343 | 64497:7:840 | Prepend once to EBGP neighbors in United | 344 | | States of America | 345 +------------------+------------------------------------------------+ 347 Example documentation for AS 64497 offering Action Communties to 348 trigger prepending of the AS_PATH only when propagating the route to 349 a certain geographical region. 351 Table 7: Action: Prepend in Region 353 4.3. Location based manipulation of LOCAL_PREF 355 In some cases, it can be desirable for an autonomous system to allow 356 adjacent Autonomous Systems to directly influence the degree of 357 preference associated with a route, usually expressed within the 358 LOCAL_PREF attribute. 360 Furthermore, in the case of large networks spanning significant 361 geography, it is often also useful to be able to extend this 362 capability and scope its effect to a geographic region. This is a 363 more powerful mechanism than AS_PATH prepending, but since degree of 364 preference determines BGP route selection and thus onward 365 advertisement, it can also be self-limiting in its scope. 367 Since the LOCAL_PREF attribute which influences degree of preference 368 is locally significant within each autonomous system, it is not 369 usually practical or useful to compare LOCAL_PREF attribute values 370 between autonomous systems. Instead it can be useful to classify the 371 major types of route likely to exist within an autonomous system's 372 routing hierarchy and provide an ability to set one's route to that 373 preference: 375 o A qualified customer route. Usually the highest preference. 377 o A peer, or network-share, route. A co-operating network provider 378 engaged in a partnership for customer coverage ("peering"). 380 o A last resort, or backup route. 382 It is entirely possible that some providers may have more classes of 383 route preference but it is possible to codify both the route 384 preference class and the regional scope within the Local Data fields 385 of the Large Community attribute. 387 For example, AS64497 might establish the following function 388 identifiers to set route preference class, which could allow pairing 389 with a location or peer-based operand to determine scope. 391 +----------+-----------------------------------------------+ 392 | Function | Preference Class | 393 +----------+-----------------------------------------------+ 394 | 10 | Qualified customer route. Highest preference. | 395 | 15 | Peering partner. Median preference. | 396 | 19 | Route of last resort. Lowest preference. | 397 +----------+-----------------------------------------------+ 399 Table 8: Action: Preference Function Identifiers 401 Once established, these route preference setting functions can be 402 linked with a scoping operand such as per-peer or per-location based 403 identifiers in order to provide AS64497's customers with a 404 comprehensive and rich toolset to influence route preference. 406 +--------------------+----------------------------------------------+ 407 | Large BGP | Meaning | 408 | Community | | 409 +--------------------+----------------------------------------------+ 410 | 64497:15:528 | Set as peer route in Netherlands | 411 | 64497:19:840 | Set as backup route in United States of | 412 | | America | 413 +--------------------+----------------------------------------------+ 415 Table 9: Action: Regional Preference Communities 417 Since the degree of preference influences BGP best path selection 418 (which in turn influences onward route propagation) Operators should 419 take special care with a traffic engineering tool such as location 420 based local preference influence (BGP Wedgies [RFC4264]). 422 5. Security Considerations 424 Network operators should note the recommendations in Section 11 of 425 BGP Operations and Security [RFC7454]. 427 6. IANA Considerations 429 None. 431 7. Acknowledgements 433 The authors would like to gratefully acknowledge the insightful 434 comments, contributions, critique and support from John Heasley, Adam 435 Chappell and Jonathan Stewart. 437 8. References 439 8.1. Normative References 441 [I-D.ietf-idr-large-community] 442 Heitz, J., Snijders, J., Patel, K., Bagdonas, I., and N. 443 Hilliard, "BGP Large Communities", draft-ietf-idr-large- 444 community-11 (work in progress), December 2016. 446 [RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities 447 Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996, 448 . 450 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 451 Requirement Levels", BCP 14, RFC 2119, 452 DOI 10.17487/RFC2119, March 1997, 453 . 455 [RFC4264] Griffin, T. and G. Huston, "BGP Wedgies", RFC 4264, 456 DOI 10.17487/RFC4264, November 2005, 457 . 459 [RFC7454] Durand, J., Pepelnjak, I., and G. Doering, "BGP Operations 460 and Security", BCP 194, RFC 7454, DOI 10.17487/RFC7454, 461 February 2015, . 463 8.2. URIs 465 [1] http://nanog.net 467 [2] http://nlnog.net 469 [3] http://unstats.un.org/unsd/methods/m49/m49regin.htm 471 Authors' Addresses 473 Job Snijders 474 NTT Communications 475 Theodorus Majofskistraat 100 476 Amsterdam 1065 SZ 477 NL 479 Email: job@ntt.net 481 Martijn Schmidt 482 i3D.net 483 Rivium 1e Straat 1 484 Capelle aan den IJssel 2909 LE 485 NL 487 Email: martijnschmidt@i3d.net