idnits 2.17.1 draft-ietf-grow-large-communities-usage-06.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 14, 2017) is 2563 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 593 -- Looks like a reference, but probably isn't: '2' on line 595 -- Looks like a reference, but probably isn't: '3' on line 597 -- Looks like a reference, but probably isn't: '4' on line 599 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 16, 2017 M. Schmidt 6 i3D.net 7 April 14, 2017 9 Use of BGP Large Communities 10 draft-ietf-grow-large-communities-usage-06 12 Abstract 14 Examples and inspiration for operators to use BGP Large Communities. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on October 16, 2017. 33 Copyright Notice 35 Copyright (c) 2017 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. The Design Overview . . . . . . . . . . . . . . . . . . . . . 2 52 2.1. Informational Communities . . . . . . . . . . . . . . . . 4 53 2.2. Action Communities . . . . . . . . . . . . . . . . . . . 4 54 3. Examples of Informational Communities . . . . . . . . . . . . 5 55 3.1. Location . . . . . . . . . . . . . . . . . . . . . . . . 5 56 3.1.1. An ISO 3166-1 Numeric Function . . . . . . . . . . . 5 57 3.1.2. An UN M.49 Region Function . . . . . . . . . . . . . 5 58 3.2. Relation Function . . . . . . . . . . . . . . . . . . . . 6 59 3.3. Combining Informational Communities . . . . . . . . . . . 6 60 4. Examples of Action Communities . . . . . . . . . . . . . . . 7 61 4.1. Selective NO_EXPORT . . . . . . . . . . . . . . . . . . . 7 62 4.1.1. ASN Based Selective NO_EXPORT . . . . . . . . . . . . 7 63 4.1.2. Location Based Selective NO_EXPORT . . . . . . . . . 7 64 4.2. Selective AS_PATH Prepending . . . . . . . . . . . . . . 8 65 4.2.1. ASN Based Selective AS_PATH Prepending . . . . . . . 8 66 4.2.2. Location Based Selective AS_PATH Prepending . . . . . 9 67 4.3. Manipulation of the LOCAL_PREF Attribute . . . . . . . . 9 68 4.3.1. Global Manipulation of LOCAL_PREF . . . . . . . . . . 10 69 4.3.2. Region Based Manipulation of LOCAL_PREF . . . . . . . 10 70 4.3.3. Note of Caution for LOCAL_PREF Functions . . . . . . 11 71 4.4. Route Server Prefix Distribution Control . . . . . . . . 11 72 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 73 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 74 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 75 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 76 8.1. Normative References . . . . . . . . . . . . . . . . . . 13 77 8.2. Informative References . . . . . . . . . . . . . . . . . 13 78 8.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 13 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 81 1. Introduction 83 BGP Large Communities [RFC8092] provide a mechanism to signal opaque 84 information between Autonomous Systems (ASs). In very much the same 85 way that [RFC1998] provides a concrete real-world application for 86 [RFC1997] communities, this document presents examples of how 87 operators might utilize BGP Large Communities to achieve various 88 goals. This document draws on the experience of operator communities 89 such as NANOG [1] and NLNOG [2]. 91 2. The Design Overview 93 BGP Large Communities are composed of three 4-octet fields. The 94 first is the Global Administrator (GA) field, whose value is the 95 Autonomous System Number (ASN) of the AS that has defined the meaning 96 of the remaining two 4-octet fields, known as "Local Data Part 1" and 97 "Local Data Part 2". This document describes an approach where the 98 "Local Data Part 1" field contains a function identifier and the 99 "Local Data Part 2" contains a parameter value. Using the canonical 100 notation this format can be summarized as "ASN:Function:Parameter". 102 +----------------------+---------------+ 103 | RFC 8092 | this document | 104 +----------------------+---------------+ 105 | Global Administrator | ASN | 106 | Local Data Part 1 | Function | 107 | Local Data Part 2 | Parameter | 108 +----------------------+---------------+ 110 A mapping table on the use of fields in BGP Large Communities between 111 [RFC8092] and this document. 113 Table 1: Field Mapping 115 In contemporary deployments of both BGP Communities [RFC1997] and BGP 116 Large Communities, the function of a community can be divided into 117 two categories: 119 o Informational Communities 121 o Action Communities 123 Throughout the document a topology of four ASs is used to illustrate 124 the use of communities in the following configuration: 126 AS 65551 127 | 128 ^ 129 | 130 AS 64497 131 / \ 132 ^ \ 133 / ^ 134 AS 64498 \ 135 | | 136 `<->- AS 64499 138 AS 64497 obtains transit services from (is a customer of) AS 65551, a 139 4-octet ASN. AS 64497 provides transit services to both AS 64498 and 140 AS 64499. AS 64498 and AS 64499 maintain a peering relationship in 141 which they only exchange their customer routes. 143 The opaque nature of BGP Large Communities allows for rapid 144 deployment of new features or changes to their routing policy that 145 perform an action. Operators are encouraged to publicly publish and 146 maintain documentation on the purpose of each BGP Large Community, 147 both informational and action, that they support or are visible in 148 BGP RIBs. 150 2.1. Informational Communities 152 Informational Communities are labels for attributes such as the 153 origin of the route announcement, the nature of the relation with an 154 EBGP neighbor or the intended propagation audience. Informational 155 Communities can also assist in providing valuable information for 156 day-to-day network operations such as debugging or capacity planning. 158 The Global Administrator field is set to the ASN which labels the 159 routes with the Informational Communities. For example, AS 64497 160 might add a community with the GA 64497 to a route accepted from an 161 IBGP or EBGP neighbor as a means of signaling that it was imported in 162 a certain geographical region. 164 In general, the intended audiences of Informational Communities are 165 downstream networks and the Global Administrator itself, but any AS 166 could benefit from receiving these communities. 168 2.2. Action Communities 170 Action Communities are added as a label to request that a route be 171 treated in a particular way within an AS. The operator of the AS 172 defines a routing policy that adjusts path attributes based on the 173 community. For example, the route's propagation characteristics, the 174 LOCAL_PREF (local preference), the next-hop, or the number of AS_PATH 175 prepends to be added when it is received or propagated can be 176 changed. 178 The Global Administrator field is set to the ASN which has defined 179 the functionality of that BGP Large Community and is the ASN that is 180 expected to perform the action. For example, AS 64499 might label a 181 route with a BGP Large Community containing GA 64497 to request that 182 AS 64497 perform a pre-defined action on that route. 184 In general, the intended audience of Action Communities are transit 185 providers taking action on behalf of a customer or the Global 186 Administrator itself, but any AS could take action if they choose and 187 any AS could add an Action Community with the GA of a non-adjacent 188 ASN. However, note that an Action Community could also be 189 informational. Its presence is an indicator that the GA may have 190 performed the action and that an AS in the AS_PATH requested it. 192 Operators are recommended to publish the relative order in which 193 Action Communities (both BGP Communities and BGP Large Communities) 194 are processed in their routing policy. 196 3. Examples of Informational Communities 198 3.1. Location 200 An AS, AS 64497 in these examples, may inform other networks about 201 the geographical region where AS 64497 imported a route by labeling 202 it with BGP Large Communities following one of the following schemes 203 or a combination of them. 205 3.1.1. An ISO 3166-1 Numeric Function 207 AS 64497 could assign a value of 1 to the Function field to designate 208 the content of the Parameter field as an ISO-3166-1 [3] numeric 209 country identifier. 211 +---------------------+---------------------------------------------+ 212 | BGP Large Community | Description | 213 +---------------------+---------------------------------------------+ 214 | 64497:1:528 | Route learned in the Netherlands | 215 | 64497:1:392 | Route learned in Japan | 216 | 64497:1:840 | Route learned in the United States of | 217 | | America | 218 +---------------------+---------------------------------------------+ 220 Example documentation for Informational Communities deployed by AS 221 64497 to describe the location where a route was imported using ISO 222 3166-1 numeric identifiers. 224 Table 2: Information: ISO 3166-1 226 3.1.2. An UN M.49 Region Function 228 AS 64497 could assign a value of 2 to the Function field to designate 229 the content of the Parameter field as the M.49 numeric code published 230 by the United Nations Statistics Division (UNSD) [4] for macro 231 geographical (continental) regions, geographical sub-regions, or 232 selected economic and other groupings. 234 +---------------------+-------------------------------+ 235 | BGP Large Community | Description | 236 +---------------------+-------------------------------+ 237 | 64497:2:2 | Route learned in Africa | 238 | 64497:2:9 | Route learned in Oceania | 239 | 64497:2:145 | Route learned in Western Asia | 240 | 64497:2:150 | Route learned in Europe | 241 +---------------------+-------------------------------+ 243 Example documentation for Informational Communities deployed by AS 244 64497 to describe the location where a route was imported using M.49 245 numeric codes published by the United Nations Statistics Division. 247 Table 3: Information: UNSD Regions 249 3.2. Relation Function 251 An AS, AS 64497 in this example, could assign a value of 3 to the 252 Function field to designate the content of the Parameter field as a 253 number indicating whether the route originated inside its own network 254 or was learned externally, and if learned externally, it might 255 simultaneously characterize the nature of the relation with that 256 specific EBGP neighbor. 258 +---------------------+---------------------------------------+ 259 | BGP Large Community | Description | 260 +---------------------+---------------------------------------+ 261 | 64497:3:1 | Route originated internally | 262 | 64497:3:2 | Route learned from a customer | 263 | 64497:3:3 | Route learned from a peering partner | 264 | 64497:3:4 | Route learned from a transit provider | 265 +---------------------+---------------------------------------+ 267 Example documentation for Informational Communities deployed by AS 268 64497 to describe the relation to the ASN from which the route was 269 learned. 271 Table 4: Information: Relation 273 3.3. Combining Informational Communities 275 A route may be labeled with multiple Informational Communities. For 276 example, a route learned in the Netherlands from a customer might be 277 labeled with communities 64497:1:528, 64497:2:150 and 64497:3:2 at 278 the same time. 280 4. Examples of Action Communities 282 4.1. Selective NO_EXPORT 284 As part of an agreement, often a commercial transit agreement, 285 between AS 64497 and AS 64498, AS 64497 might expose BGP traffic 286 engineering functions to AS 64498. One such BGP traffic engineering 287 function could be selective NO_EXPORT, which is the selective 288 filtering of a route learned from one AS, AS 64498, to certain EBGP 289 neighbors of the GA, AS 64497. 291 4.1.1. ASN Based Selective NO_EXPORT 293 AS 64497 could assign a value of 4 to the Function field to designate 294 the content of the Parameter field as a neighboring ASN to which a 295 route should not be propagated. 297 +---------------------+---------------------------------+ 298 | BGP Large Community | Description | 299 +---------------------+---------------------------------+ 300 | 64497:4:64498 | Do not export route to AS 64498 | 301 | 64497:4:64499 | Do not export route to AS 64499 | 302 | 64497:4:65551 | Do not export route to AS 65551 | 303 +---------------------+---------------------------------+ 305 Example documentation for Action Communities deployed by AS 64497 to 306 expose a BGP traffic engineering function which selectively prevents 307 the propagation of routes to the neighboring ASN specified in the 308 Parameter field. 310 Table 5: Action: ASN NO_EXPORT 312 4.1.2. Location Based Selective NO_EXPORT 314 AS 64497 could assign a value of 5 to the Function field to designate 315 the content of the Parameter field as an ISO 3166-1 numeric country 316 identifier within which a labeled route is not propagated to EBGP 317 neighbors. However, this might not prevent one of those EBGP 318 neighbors from learning that route in another country and making it 319 available in the country specified by the BGP Large Community. 321 +-----------------+-------------------------------------------------+ 322 | BGP Large | Description | 323 | Community | | 324 +-----------------+-------------------------------------------------+ 325 | 64497:5:528 | Do not export to EBGP neighbors in the | 326 | | Netherlands | 327 | 64497:5:392 | Do not export to EBGP neighbors in Japan | 328 | 64497:5:840 | Do not export to EBGP neighbors in the United | 329 | | States of America | 330 +-----------------+-------------------------------------------------+ 332 Example documentation for Action Communities deployed by AS 64497 to 333 expose a BGP traffic engineering function which selectively prevents 334 the propagation of routes to all EBGP neighbors in the geographical 335 region specified in the Parameter field. 337 Table 6: Action: NO_EXPORT in Region 339 4.2. Selective AS_PATH Prepending 341 As part of an agreement between AS 64497 and AS 64498, AS 64497 might 342 expose BGP traffic engineering functions to AS 64498. One such BGP 343 traffic engineering function could be selective prepending of the 344 AS_PATH with AS 64497 to certain certain EBGP neighbors of AS 64497. 346 4.2.1. ASN Based Selective AS_PATH Prepending 348 AS 64497 could assign a value of 6 to the Function field to designate 349 the content of the Parameter field as a neighboring ASN to which 350 prepending of the AS_PATH with AS 64497 is requested on propagation 351 of the route. Additional AS_PATH prepending functions might also be 352 defined to support multiples of prepending, that is two, three or 353 more prepends of AS 64497. 355 +---------------------+------------------------------------------+ 356 | BGP Large Community | Description | 357 +---------------------+------------------------------------------+ 358 | 64497:6:64498 | Prepend 64497 once on export to AS 64498 | 359 | 64497:6:64499 | Prepend 64497 once on export to AS 64499 | 360 | 64497:6:65551 | Prepend 64497 once on export to AS 65551 | 361 +---------------------+------------------------------------------+ 363 Example documentation for Action Communities deployed by AS 64497 to 364 expose a BGP traffic engineering function which selectively prepends 365 the AS_PATH with AS 64497 when propagating the route to the specified 366 EBGP neighbor. 368 Table 7: Action: Prepend to ASN 370 4.2.2. Location Based Selective AS_PATH Prepending 372 AS 64497 could assign a value of 7 to the Function field to designate 373 the content of the Parameter field as an ISO 3166-1 numeric country 374 identifier to which the prepending of the AS_PATH with AS 64497 is 375 requested on propagation of the route to all EBGP neighbors in that 376 region. 378 +------------------+------------------------------------------------+ 379 | BGP Large | Description | 380 | Community | | 381 +------------------+------------------------------------------------+ 382 | 64497:7:528 | Prepend once to EBGP neighbors in the | 383 | | Netherlands | 384 | 64497:7:392 | Prepend once to EBGP neighbors in Japan | 385 | 64497:7:840 | Prepend once to EBGP neighbors in United | 386 | | States of America | 387 +------------------+------------------------------------------------+ 389 Example documentation for Action Communities deployed by AS 64497 to 390 expose a BGP traffic engineering function which selectively prepends 391 the AS_PATH with AS 64497 when propagating the route to all EBGP 392 neighbors in the geographical region specified in the Parameter 393 field. 395 Table 8: Action: Prepend in Region 397 4.3. Manipulation of the LOCAL_PREF Attribute 399 As part of an agreement between AS 64497 and AS 64498, AS 64497 might 400 expose BGP traffic engineering functions to AS 64498. One such BGP 401 traffic engineering function might allow AS 64498 to manipulate the 402 value of the LOCAL_PREF attribute of routes learned from AS 64498 403 within AS 64497, even though the LOCAL_PREF attribute is non- 404 transitive and is not propagated to EBGP neighbors. 406 The LOCAL_PREF value of routes are locally significant within each AS 407 and are impossible to list in this document. Instead, the typical 408 LOCAL_PREF values could be classified as a hierarchy and a BGP Large 409 Community function exposed allowing an EBGP neighbor to affect the 410 LOCAL_PREF value within the specified GA. The following example list 411 defines the classes of routes in the order of descending LOCAL_PREF 412 value and assigns a function identifier which could be used in the 413 Function field of a BGP Large Community. 415 +----------+--------------------------------------------------------+ 416 | Function | Preference Class | 417 +----------+--------------------------------------------------------+ 418 | 8 | Normal customer route | 419 | 9 | Backup customer route | 420 | 10 | Peering route | 421 | 11 | Upstream transit route | 422 | 12 | Fallback route, to be installed if no other path is | 423 | | available | 424 +----------+--------------------------------------------------------+ 426 Table 9: Action: Preference Function Identifiers 428 4.3.1. Global Manipulation of LOCAL_PREF 430 AS 64497 could place one of the previously defined Preference 431 Function Identifiers in the Function field and set the value 0 in the 432 Parameter field to designate that the LOCAL_PREF associated with that 433 function identifier should be applied for that route throughout the 434 whole AS. 436 +---------------------+---------------------------------------------+ 437 | BGP Large Community | Description | 438 +---------------------+---------------------------------------------+ 439 | 64497:9:0 | Assign LOCAL_PREF for a customer backup | 440 | | route | 441 | 64497:10:0 | Assign LOCAL_PREF for a peering route | 442 | 64497:12:0 | Assign LOCAL_PREF for a fallback route | 443 +---------------------+---------------------------------------------+ 445 Example documentation for Action Communities deployed by AS 64497 to 446 expose a BGP traffic engineering function which allows a BGP neighbor 447 to globally manipulate the LOCAL_PREF attribute for the route within 448 AS 64497. 450 Table 10: Action: Global LOCAL_PREF Manipulation 452 4.3.2. Region Based Manipulation of LOCAL_PREF 454 AS 64497 could place one of the previously defined Preference 455 Function Identifiers in the Function field and use an UN M.49 numeric 456 region identifier in the Parameter field to designate the 457 geographical region within which the non-default LOCAL_PREF 458 associated with that function identifier should be applied to the 459 route. The value of the LOCAL_PREF attribute should not deviate from 460 the default for that route class in any region not specified by one 461 or more of these Action Communities. 463 +--------------+----------------------------------------------------+ 464 | BGP Large | Description | 465 | Community | | 466 +--------------+----------------------------------------------------+ 467 | 64497:9:3 | Assign the LOCAL_PREF value equivalent to a | 468 | | customer backup class route on BGP routers in the | 469 | | North America region | 470 | 64497:10:5 | Assign the LOCAL_PREF value equivalent to a | 471 | | peering class route on BGP routers in the South | 472 | | America region | 473 | 64497:12:142 | Assign the LOCAL_PREF value equivalent to a | 474 | | fallback class route on BGP routers in the Asia | 475 | | region | 476 +--------------+----------------------------------------------------+ 478 Example documentation for Action Communities deployed by AS 64497 to 479 expose a BGP traffic engineering function which allows a BGP neighbor 480 to selectively manipulate the LOCAL_PREF attribute within AS 64497 in 481 the geographical region specified in the Parameter field. 483 Table 11: Action: Regional LOCAL_PREF Manipulation 485 4.3.3. Note of Caution for LOCAL_PREF Functions 487 The LOCAL_PREF attribute strongly influences the BGP Decision 488 Process, which in turn affects the scope of route propagation. 489 Operators should take special care when using Action Communities that 490 decrease the LOCAL_PREF value, and the degree of preference, to a 491 value below that of another route class. Some of the unintended BGP 492 states that might arise as a result of these traffic engineering 493 decisions are described as "BGP Wedgies" in [RFC4264]. 495 4.4. Route Server Prefix Distribution Control 497 Route Servers [RFC7947] use BGP to broker network reachability 498 information among their clients. As not all route server clients may 499 wish to interconnect with each other, the route server operator will 500 usually implement a mechanism to allow each client to control the 501 route server's export routing policy, as described in Section 4.6 of 502 [RFC7948]. One widely-used mechanism is a route server specific 503 adaption of "ASN Based Selective NO_EXPORT" (Section 4.1.1). 505 An example BGP Large Communities policy which enables client- 506 controlled prefix distribution for a route server operating as AS 507 64497, is outlined as follows: 509 +-------------------+-----------------------------------------------+ 510 | BGP Large | Description | 511 | Community | | 512 +-------------------+-----------------------------------------------+ 513 | 64497:0:peer-as | Explicitly prevent announcement of route to | 514 | | peer-as | 515 | 64497:1:peer-as | Explicitly announce route to peer-as | 516 | 64497:0:0 | Do not announce route to any peers by default | 517 | 64497:1:0 | Announce route to all peers by default | 518 +-------------------+-----------------------------------------------+ 520 Table 12: Action: Route Server Prefix Distribution Control 522 Multiple BGP Large Community values can be used together to implement 523 fine-grained route distribution control. For example, route server 524 client AS 64500 might wish to use a route server for interconnecting 525 to all other clients except AS 64510. In this case, they would label 526 all their outbound routes to the route server with 64497:1:0 (to 527 announce to all clients by default) and 64497:1:64510 (to prevent 528 announcement to AS 64510). 530 Alternatively, route server client AS 64501 may have a selective 531 routing policy and may wish to interconnect with only AS 64505 and AS 532 64506. This could be implemented by announcing routes labeled with 533 64497:0:0 (blocking all distribution by default) and 64497:1:64505, 534 64497:1:64506 to instruct the route server to force announcement to 535 those two ASNs. 537 5. Security Considerations 539 Operators should note the recommendations in Section 11 of BGP 540 Operations and Security [RFC7454]. 542 6. IANA Considerations 544 None. 546 7. Acknowledgments 548 The authors would like to gratefully acknowledge the insightful 549 comments, contributions, critique and support from Adam Chappell, 550 Jonathan Stewart, Greg Hankins, Nick Hilliard, Will Hargrave, Randy 551 Bush, Shawn Morris and Jay Borkenhagen. 553 8. References 555 8.1. Normative References 557 [RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities 558 Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996, 559 . 561 [RFC7454] Durand, J., Pepelnjak, I., and G. Doering, "BGP Operations 562 and Security", BCP 194, RFC 7454, DOI 10.17487/RFC7454, 563 February 2015, . 565 [RFC8092] Heitz, J., Ed., Snijders, J., Ed., Patel, K., Bagdonas, 566 I., and N. Hilliard, "BGP Large Communities Attribute", 567 RFC 8092, DOI 10.17487/RFC8092, February 2017, 568 . 570 8.2. Informative References 572 [RFC1998] Chen, E. and T. Bates, "An Application of the BGP 573 Community Attribute in Multi-home Routing", RFC 1998, 574 DOI 10.17487/RFC1998, August 1996, 575 . 577 [RFC4264] Griffin, T. and G. Huston, "BGP Wedgies", RFC 4264, 578 DOI 10.17487/RFC4264, November 2005, 579 . 581 [RFC7947] Jasinska, E., Hilliard, N., Raszuk, R., and N. Bakker, 582 "Internet Exchange BGP Route Server", RFC 7947, 583 DOI 10.17487/RFC7947, September 2016, 584 . 586 [RFC7948] Hilliard, N., Jasinska, E., Raszuk, R., and N. Bakker, 587 "Internet Exchange BGP Route Server Operations", RFC 7948, 588 DOI 10.17487/RFC7948, September 2016, 589 . 591 8.3. URIs 593 [1] https://www.nanog.org 595 [2] https://nlnog.net 597 [3] https://www.iso.org/iso-3166-country-codes.html 599 [4] https://unstats.un.org/unsd/methodology/m49/ 601 Authors' Addresses 603 Job Snijders 604 NTT Communications 605 Theodorus Majofskistraat 100 606 Amsterdam 1065 SZ 607 The Netherlands 609 Email: job@ntt.net 611 John Heasley 612 NTT Communications 613 1111 NW 53rd Drive 614 Portland, OR 97210 615 United States of America 617 Email: heas@shrubbery.net 619 Martijn Schmidt 620 i3D.net 621 Rivium 1e Straat 1 622 Capelle aan den IJssel 2909 LE 623 NL 625 Email: martijnschmidt@i3d.net