idnits 2.17.1 draft-ietf-grow-large-communities-usage-07.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 (April 19, 2017) is 2535 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 610 -- Looks like a reference, but probably isn't: '2' on line 612 -- Looks like a reference, but probably isn't: '3' on line 614 -- Looks like a reference, but probably isn't: '4' on line 616 Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 5 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: October 21, 2017 M. Schmidt 6 i3D.net 7 April 19, 2017 9 Use of BGP Large Communities 10 draft-ietf-grow-large-communities-usage-07 12 Abstract 14 This document presents examples and inspiration for operator's 15 application of BGP Large Communities. Based on operational 16 experience with BGP Communties, this document suggests logical 17 categories of BGP Large Communities and demonstrates an orderly 18 manner of organizing community values within them to achieve typical 19 goals in routing policy. Any operator can consider using the 20 concepts presented as the basis for their own BGP Large Communities 21 repertoire. 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 October 21, 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 Design Overview . . . . . . . . . . . . . . . . . . . . . 3 59 2.1. Informational Communities . . . . . . . . . . . . . . . . 4 60 2.2. Action Communities . . . . . . . . . . . . . . . . . . . 4 61 3. Examples of Informational Communities . . . . . . . . . . . . 5 62 3.1. Location . . . . . . . . . . . . . . . . . . . . . . . . 5 63 3.1.1. An ISO 3166-1 Numeric Function . . . . . . . . . . . 5 64 3.1.2. An UN M.49 Region Function . . . . . . . . . . . . . 5 65 3.2. Relation Function . . . . . . . . . . . . . . . . . . . . 6 66 3.3. Combining Informational Communities . . . . . . . . . . . 6 67 4. Examples of Action Communities . . . . . . . . . . . . . . . 7 68 4.1. Selective NO_EXPORT . . . . . . . . . . . . . . . . . . . 7 69 4.1.1. ASN Based Selective NO_EXPORT . . . . . . . . . . . . 7 70 4.1.2. Location Based Selective NO_EXPORT . . . . . . . . . 7 71 4.2. Selective AS_PATH Prepending . . . . . . . . . . . . . . 8 72 4.2.1. ASN Based Selective AS_PATH Prepending . . . . . . . 8 73 4.2.2. Location Based Selective AS_PATH Prepending . . . . . 9 74 4.3. Manipulation of the LOCAL_PREF Attribute . . . . . . . . 9 75 4.3.1. Global Manipulation of LOCAL_PREF . . . . . . . . . . 10 76 4.3.2. Region Based Manipulation of LOCAL_PREF . . . . . . . 10 77 4.3.3. Note of Caution for LOCAL_PREF Functions . . . . . . 11 78 4.4. Route Server Prefix Distribution Control . . . . . . . . 11 79 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 80 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 81 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 82 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 83 8.1. Normative References . . . . . . . . . . . . . . . . . . 13 84 8.2. Informative References . . . . . . . . . . . . . . . . . 13 85 8.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 14 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 88 1. Introduction 90 BGP Large Communities [RFC8092] provide a mechanism to signal opaque 91 information between Autonomous Systems (ASs). In very much the same 92 way that [RFC1998] provides a concrete real-world application for 93 [RFC1997] communities, this document presents examples of how 94 operators might utilize BGP Large Communities to achieve various 95 goals. This document draws on the experience of operator communities 96 such as NANOG [1] and NLNOG [2]. 98 2. The Design Overview 100 BGP Large Communities are composed of three 4-octet fields. The 101 first is the Global Administrator (GA) field, whose value is the 102 Autonomous System Number (ASN) of the AS that has defined the meaning 103 of the remaining two 4-octet fields, known as "Local Data Part 1" and 104 "Local Data Part 2". This document describes an approach where the 105 "Local Data Part 1" field contains a function identifier and the 106 "Local Data Part 2" contains a parameter value. Using the canonical 107 notation this format can be summarized as "ASN:Function:Parameter". 109 +----------------------+---------------+ 110 | RFC 8092 | this document | 111 +----------------------+---------------+ 112 | Global Administrator | ASN | 113 | Local Data Part 1 | Function | 114 | Local Data Part 2 | Parameter | 115 +----------------------+---------------+ 117 A mapping table on the use of fields in BGP Large Communities between 118 [RFC8092] and this document. 120 Table 1: Field Mapping 122 In contemporary deployments of both BGP Communities [RFC1997] and BGP 123 Large Communities, the function of a community can be divided into 124 two categories: 126 o Informational Communities 128 o Action Communities 130 Throughout the document a topology of four ASs is used to illustrate 131 the use of communities in the following configuration: 133 AS 65551 134 | 135 ^ 136 | 137 AS 64497 138 / \ 139 ^ \ 140 / ^ 141 AS 64498 \ 142 | | 143 `<->- AS 64499 145 AS 64497 obtains transit services from (is a customer of) AS 65551, a 146 4-octet ASN. AS 64497 provides transit services to both AS 64498 and 147 AS 64499. AS 64498 and AS 64499 maintain a peering relationship in 148 which they only exchange their customer routes. 150 The opaque nature of BGP Large Communities allows for rapid 151 deployment of new features or changes to their routing policy that 152 perform an action. Operators are encouraged to publicly publish and 153 maintain documentation on the purpose of each BGP Large Community, 154 both informational and action, that they support or are visible in 155 BGP RIBs. 157 2.1. Informational Communities 159 Informational Communities are labels for attributes such as the 160 origin of the route announcement, the nature of the relation with an 161 EBGP neighbor or the intended propagation audience. Informational 162 Communities can also assist in providing valuable information for 163 day-to-day network operations such as debugging or capacity planning. 165 The Global Administrator field is set to the ASN which labels the 166 routes with the Informational Communities. For example, AS 64497 167 might add a community with the GA 64497 to a route accepted from an 168 IBGP or EBGP neighbor as a means of signaling that it was imported in 169 a certain geographical region. 171 In general, the intended audiences of Informational Communities are 172 downstream networks and the Global Administrator itself, but any AS 173 could benefit from receiving these communities. 175 2.2. Action Communities 177 Action Communities are added as a label to request that a route be 178 treated in a particular way within an AS. The operator of the AS 179 defines a routing policy that adjusts path attributes based on the 180 community. For example, the route's propagation characteristics, the 181 LOCAL_PREF (local preference), the next-hop, or the number of AS_PATH 182 prepends to be added when it is received or propagated can be 183 changed. 185 The Global Administrator field is set to the ASN which has defined 186 the functionality of that BGP Large Community and is the ASN that is 187 expected to perform the action. For example, AS 64499 might label a 188 route with a BGP Large Community containing GA 64497 to request that 189 AS 64497 perform a pre-defined action on that route. 191 In general, the intended audience of Action Communities are transit 192 providers taking action on behalf of a customer or the Global 193 Administrator itself, but any AS could take action if they choose and 194 any AS could add an Action Community with the GA of a non-adjacent 195 ASN. However, note that an Action Community could also be 196 informational. Its presence is an indicator that the GA may have 197 performed the action and that an AS in the AS_PATH requested it. 199 Operators are recommended to publish the relative order in which 200 Action Communities (both BGP Communities and BGP Large Communities) 201 are processed in their routing policy. 203 3. Examples of Informational Communities 205 3.1. Location 207 An AS, AS 64497 in these examples, may inform other networks about 208 the geographical region where AS 64497 imported a route by labeling 209 it with BGP Large Communities following one of the following schemes 210 or a combination of them. 212 3.1.1. An ISO 3166-1 Numeric Function 214 AS 64497 could assign a value of 1 to the Function field to designate 215 the content of the Parameter field as an ISO-3166-1 [3] numeric 216 country identifier. 218 +---------------------+---------------------------------------------+ 219 | BGP Large Community | Description | 220 +---------------------+---------------------------------------------+ 221 | 64497:1:528 | Route learned in the Netherlands | 222 | 64497:1:392 | Route learned in Japan | 223 | 64497:1:840 | Route learned in the United States of | 224 | | America | 225 +---------------------+---------------------------------------------+ 227 Example documentation for Informational Communities deployed by AS 228 64497 to describe the location where a route was imported using ISO 229 3166-1 numeric identifiers. 231 Table 2: Information: ISO 3166-1 233 3.1.2. An UN M.49 Region Function 235 AS 64497 could assign a value of 2 to the Function field to designate 236 the content of the Parameter field as the M.49 numeric code published 237 by the United Nations Statistics Division (UNSD) [4] for macro 238 geographical (continental) regions, geographical sub-regions, or 239 selected economic and other groupings. 241 +---------------------+-------------------------------+ 242 | BGP Large Community | Description | 243 +---------------------+-------------------------------+ 244 | 64497:2:2 | Route learned in Africa | 245 | 64497:2:9 | Route learned in Oceania | 246 | 64497:2:145 | Route learned in Western Asia | 247 | 64497:2:150 | Route learned in Europe | 248 +---------------------+-------------------------------+ 250 Example documentation for Informational Communities deployed by AS 251 64497 to describe the location where a route was imported using M.49 252 numeric codes published by the United Nations Statistics Division. 254 Table 3: Information: UNSD Regions 256 3.2. Relation Function 258 An AS, AS 64497 in this example, could assign a value of 3 to the 259 Function field to designate the content of the Parameter field as a 260 number indicating whether the route originated inside its own network 261 or was learned externally, and if learned externally, it might 262 simultaneously characterize the nature of the relation with that 263 specific EBGP neighbor. 265 +---------------------+---------------------------------------+ 266 | BGP Large Community | Description | 267 +---------------------+---------------------------------------+ 268 | 64497:3:1 | Route originated internally | 269 | 64497:3:2 | Route learned from a customer | 270 | 64497:3:3 | Route learned from a peering partner | 271 | 64497:3:4 | Route learned from a transit provider | 272 +---------------------+---------------------------------------+ 274 Example documentation for Informational Communities deployed by AS 275 64497 to describe the relation to the ASN from which the route was 276 learned. 278 Table 4: Information: Relation 280 3.3. Combining Informational Communities 282 A route may be labeled with multiple Informational Communities. For 283 example, a route learned in the Netherlands from a customer might be 284 labeled with communities 64497:1:528, 64497:2:150 and 64497:3:2 at 285 the same time. 287 4. Examples of Action Communities 289 4.1. Selective NO_EXPORT 291 As part of an agreement, often a commercial transit agreement, 292 between AS 64497 and AS 64498, AS 64497 might expose BGP traffic 293 engineering functions to AS 64498. One such BGP traffic engineering 294 function could be selective NO_EXPORT, which is the selective 295 filtering of a route learned from one AS, AS 64498, to certain EBGP 296 neighbors of the GA, AS 64497. 298 4.1.1. ASN Based Selective NO_EXPORT 300 AS 64497 could assign a value of 4 to the Function field to designate 301 the content of the Parameter field as a neighboring ASN to which a 302 route should not be propagated. 304 +---------------------+---------------------------------+ 305 | BGP Large Community | Description | 306 +---------------------+---------------------------------+ 307 | 64497:4:64498 | Do not export route to AS 64498 | 308 | 64497:4:64499 | Do not export route to AS 64499 | 309 | 64497:4:65551 | Do not export route to AS 65551 | 310 +---------------------+---------------------------------+ 312 Example documentation for Action Communities deployed by AS 64497 to 313 expose a BGP traffic engineering function which selectively prevents 314 the propagation of routes to the neighboring ASN specified in the 315 Parameter field. 317 Table 5: Action: ASN NO_EXPORT 319 4.1.2. Location Based Selective NO_EXPORT 321 AS 64497 could assign a value of 5 to the Function field to designate 322 the content of the Parameter field as an ISO 3166-1 numeric country 323 identifier within which a labeled route is not propagated to EBGP 324 neighbors. However, this might not prevent one of those EBGP 325 neighbors from learning that route in another country and making it 326 available in the country specified by the BGP Large Community. 328 +-----------------+-------------------------------------------------+ 329 | BGP Large | Description | 330 | Community | | 331 +-----------------+-------------------------------------------------+ 332 | 64497:5:528 | Do not export to EBGP neighbors in the | 333 | | Netherlands | 334 | 64497:5:392 | Do not export to EBGP neighbors in Japan | 335 | 64497:5:840 | Do not export to EBGP neighbors in the United | 336 | | States of America | 337 +-----------------+-------------------------------------------------+ 339 Example documentation for Action Communities deployed by AS 64497 to 340 expose a BGP traffic engineering function which selectively prevents 341 the propagation of routes to all EBGP neighbors in the geographical 342 region specified in the Parameter field. 344 Table 6: Action: NO_EXPORT in Region 346 4.2. Selective AS_PATH Prepending 348 As part of an agreement between AS 64497 and AS 64498, AS 64497 might 349 expose BGP traffic engineering functions to AS 64498. One such BGP 350 traffic engineering function could be selective prepending of the 351 AS_PATH with AS 64497 to certain certain EBGP neighbors of AS 64497. 353 4.2.1. ASN Based Selective AS_PATH Prepending 355 AS 64497 could assign a value of 6 to the Function field to designate 356 the content of the Parameter field as a neighboring ASN to which 357 prepending of the AS_PATH with AS 64497 is requested on propagation 358 of the route. Additional AS_PATH prepending functions might also be 359 defined to support multiples of prepending, that is two, three or 360 more prepends of AS 64497. 362 +---------------------+------------------------------------------+ 363 | BGP Large Community | Description | 364 +---------------------+------------------------------------------+ 365 | 64497:6:64498 | Prepend 64497 once on export to AS 64498 | 366 | 64497:6:64499 | Prepend 64497 once on export to AS 64499 | 367 | 64497:6:65551 | Prepend 64497 once on export to AS 65551 | 368 +---------------------+------------------------------------------+ 370 Example documentation for Action Communities deployed by AS 64497 to 371 expose a BGP traffic engineering function which selectively prepends 372 the AS_PATH with AS 64497 when propagating the route to the specified 373 EBGP neighbor. 375 Table 7: Action: Prepend to ASN 377 4.2.2. Location Based Selective AS_PATH Prepending 379 AS 64497 could assign a value of 7 to the Function field to designate 380 the content of the Parameter field as an ISO 3166-1 numeric country 381 identifier to which the prepending of the AS_PATH with AS 64497 is 382 requested on propagation of the route to all EBGP neighbors in that 383 region. 385 +------------------+------------------------------------------------+ 386 | BGP Large | Description | 387 | Community | | 388 +------------------+------------------------------------------------+ 389 | 64497:7:528 | Prepend once to EBGP neighbors in the | 390 | | Netherlands | 391 | 64497:7:392 | Prepend once to EBGP neighbors in Japan | 392 | 64497:7:840 | Prepend once to EBGP neighbors in United | 393 | | States of America | 394 +------------------+------------------------------------------------+ 396 Example documentation for Action Communities deployed by AS 64497 to 397 expose a BGP traffic engineering function which selectively prepends 398 the AS_PATH with AS 64497 when propagating the route to all EBGP 399 neighbors in the geographical region specified in the Parameter 400 field. 402 Table 8: Action: Prepend in Region 404 4.3. Manipulation of the LOCAL_PREF Attribute 406 As part of an agreement between AS 64497 and AS 64498, AS 64497 might 407 expose BGP traffic engineering functions to AS 64498. One such BGP 408 traffic engineering function might allow AS 64498 to manipulate the 409 value of the LOCAL_PREF attribute of routes learned from AS 64498 410 within AS 64497, even though the LOCAL_PREF attribute is non- 411 transitive and is not propagated to EBGP neighbors. 413 The LOCAL_PREF value of routes are locally significant within each AS 414 and are impossible to list in this document. Instead, the typical 415 LOCAL_PREF values could be classified as a hierarchy and a BGP Large 416 Community function exposed allowing an EBGP neighbor to affect the 417 LOCAL_PREF value within the specified GA. The following example list 418 defines the classes of routes in the order of descending LOCAL_PREF 419 value and assigns a function identifier which could be used in the 420 Function field of a BGP Large Community. 422 +----------+--------------------------------------------------------+ 423 | Function | Preference Class | 424 +----------+--------------------------------------------------------+ 425 | 8 | Normal customer route | 426 | 9 | Backup customer route | 427 | 10 | Peering route | 428 | 11 | Upstream transit route | 429 | 12 | Fallback route, to be installed if no other path is | 430 | | available | 431 +----------+--------------------------------------------------------+ 433 Table 9: Action: Preference Function Identifiers 435 4.3.1. Global Manipulation of LOCAL_PREF 437 AS 64497 could place one of the previously defined Preference 438 Function Identifiers in the Function field and set the value 0 in the 439 Parameter field to designate that the LOCAL_PREF associated with that 440 function identifier should be applied for that route throughout the 441 whole AS. 443 +---------------------+---------------------------------------------+ 444 | BGP Large Community | Description | 445 +---------------------+---------------------------------------------+ 446 | 64497:9:0 | Assign LOCAL_PREF for a customer backup | 447 | | route | 448 | 64497:10:0 | Assign LOCAL_PREF for a peering route | 449 | 64497:12:0 | Assign LOCAL_PREF for a fallback route | 450 +---------------------+---------------------------------------------+ 452 Example documentation for Action Communities deployed by AS 64497 to 453 expose a BGP traffic engineering function which allows a BGP neighbor 454 to globally manipulate the LOCAL_PREF attribute for the route within 455 AS 64497. 457 Table 10: Action: Global LOCAL_PREF Manipulation 459 4.3.2. Region Based Manipulation of LOCAL_PREF 461 AS 64497 could place one of the previously defined Preference 462 Function Identifiers in the Function field and use an UN M.49 numeric 463 region identifier in the Parameter field to designate the 464 geographical region within which the non-default LOCAL_PREF 465 associated with that function identifier should be applied to the 466 route. The value of the LOCAL_PREF attribute should not deviate from 467 the default for that route class in any region not specified by one 468 or more of these Action Communities. 470 +--------------+----------------------------------------------------+ 471 | BGP Large | Description | 472 | Community | | 473 +--------------+----------------------------------------------------+ 474 | 64497:9:3 | Assign the LOCAL_PREF value equivalent to a | 475 | | customer backup class route on BGP routers in the | 476 | | North America region | 477 | 64497:10:5 | Assign the LOCAL_PREF value equivalent to a | 478 | | peering class route on BGP routers in the South | 479 | | America region | 480 | 64497:12:142 | Assign the LOCAL_PREF value equivalent to a | 481 | | fallback class route on BGP routers in the Asia | 482 | | region | 483 +--------------+----------------------------------------------------+ 485 Example documentation for Action Communities deployed by AS 64497 to 486 expose a BGP traffic engineering function which allows a BGP neighbor 487 to selectively manipulate the LOCAL_PREF attribute within AS 64497 in 488 the geographical region specified in the Parameter field. 490 Table 11: Action: Regional LOCAL_PREF Manipulation 492 4.3.3. Note of Caution for LOCAL_PREF Functions 494 The LOCAL_PREF attribute strongly influences the BGP Decision 495 Process, which in turn affects the scope of route propagation. 496 Operators should take special care when using Action Communities that 497 decrease the LOCAL_PREF value, and the degree of preference, to a 498 value below that of another route class. Some of the unintended BGP 499 states that might arise as a result of these traffic engineering 500 decisions are described as "BGP Wedgies" in [RFC4264]. 502 4.4. Route Server Prefix Distribution Control 504 Route Servers [RFC7947] use BGP to broker network reachability 505 information among their clients. As not all route server clients may 506 wish to interconnect with each other, the route server operator will 507 usually implement a mechanism to allow each client to control the 508 route server's export routing policy, as described in Section 4.6 of 509 [RFC7948]. One widely-used mechanism is a route server specific 510 adaption of "ASN Based Selective NO_EXPORT" (Section 4.1.1). 512 An example BGP Large Communities policy which enables client- 513 controlled prefix distribution for a route server operating as AS 514 64497, is outlined as follows: 516 +-------------------+-----------------------------------------------+ 517 | BGP Large | Description | 518 | Community | | 519 +-------------------+-----------------------------------------------+ 520 | 64497:13:peer-as | Explicitly prevent announcement of route to | 521 | | peer-as | 522 | 64497:14:peer-as | Explicitly announce route to peer-as | 523 | 64497:13:0 | Do not announce route to any peers by default | 524 | 64497:14:0 | Announce route to all peers by default | 525 +-------------------+-----------------------------------------------+ 527 Table 12: Action: Route Server Prefix Distribution Control 529 Multiple BGP Large Community values can be used together to implement 530 fine-grained route distribution control. For example, route server 531 client AS 64500 might wish to use a route server for interconnecting 532 to all other clients except AS 64510. In this case, they would label 533 all their outbound routes to the route server with 64497:14:0 (to 534 announce to all clients by default) and 64497:13:64510 (to prevent 535 announcement to AS 64510). 537 Alternatively, route server client AS 64501 may have a selective 538 routing policy and may wish to interconnect with only AS 64505 and AS 539 64506. This could be implemented by announcing routes labeled with 540 64497:13:0 (blocking all distribution by default) and 64497:14:64505, 541 64497:14:64506 to instruct the route server to force announcement to 542 those two ASNs. 544 5. Security Considerations 546 Operators should note the recommendations in Section 11 of BGP 547 Operations and Security [RFC7454] and handle BGP Large Communities 548 with their ASN in the Global Administrator field similarly. 550 In particular and in the same respect as BGP Communities [RFC1997], 551 operators should be congnizant that any Large Community can be 552 carried in a BGP UPDATE. Operators should recognize that BGP 553 neighbors, particularly customers and customers of customers, may 554 utilize communities defined by other BGP neighbors of the operator. 555 They may wish to send routes with action communities and receive 556 routes with informational communities to or from these other 557 neighbors and it is beneficial to all to permit this. 559 6. IANA Considerations 561 None. 563 7. Acknowledgments 565 The authors would like to gratefully acknowledge the insightful 566 comments, contributions, critique and support from Adam Chappell, 567 Jonathan Stewart, Greg Hankins, Nick Hilliard, Will Hargrave, Randy 568 Bush, Shawn Morris, Jay Borkenhagen and Stewart Bryant. 570 8. References 572 8.1. Normative References 574 [RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities 575 Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996, 576 . 578 [RFC7454] Durand, J., Pepelnjak, I., and G. Doering, "BGP Operations 579 and Security", BCP 194, RFC 7454, DOI 10.17487/RFC7454, 580 February 2015, . 582 [RFC8092] Heitz, J., Ed., Snijders, J., Ed., Patel, K., Bagdonas, 583 I., and N. Hilliard, "BGP Large Communities Attribute", 584 RFC 8092, DOI 10.17487/RFC8092, February 2017, 585 . 587 8.2. Informative References 589 [RFC1998] Chen, E. and T. Bates, "An Application of the BGP 590 Community Attribute in Multi-home Routing", RFC 1998, 591 DOI 10.17487/RFC1998, August 1996, 592 . 594 [RFC4264] Griffin, T. and G. Huston, "BGP Wedgies", RFC 4264, 595 DOI 10.17487/RFC4264, November 2005, 596 . 598 [RFC7947] Jasinska, E., Hilliard, N., Raszuk, R., and N. Bakker, 599 "Internet Exchange BGP Route Server", RFC 7947, 600 DOI 10.17487/RFC7947, September 2016, 601 . 603 [RFC7948] Hilliard, N., Jasinska, E., Raszuk, R., and N. Bakker, 604 "Internet Exchange BGP Route Server Operations", RFC 7948, 605 DOI 10.17487/RFC7948, September 2016, 606 . 608 8.3. URIs 610 [1] https://www.nanog.org 612 [2] https://nlnog.net 614 [3] https://www.iso.org/iso-3166-country-codes.html 616 [4] https://unstats.un.org/unsd/methodology/m49/ 618 Authors' Addresses 620 Job Snijders 621 NTT Communications 622 Theodorus Majofskistraat 100 623 Amsterdam 1065 SZ 624 The Netherlands 626 Email: job@ntt.net 628 John Heasley 629 NTT Communications 630 1111 NW 53rd Drive 631 Portland, OR 97210 632 United States of America 634 Email: heas@shrubbery.net 636 Martijn Schmidt 637 i3D.net 638 Rivium 1e Straat 1 639 Capelle aan den IJssel 2909 LE 640 NL 642 Email: martijnschmidt@i3d.net