From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc8195.txt | 843 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 843 insertions(+) create mode 100644 doc/rfc/rfc8195.txt (limited to 'doc/rfc/rfc8195.txt') diff --git a/doc/rfc/rfc8195.txt b/doc/rfc/rfc8195.txt new file mode 100644 index 0000000..bc805a1 --- /dev/null +++ b/doc/rfc/rfc8195.txt @@ -0,0 +1,843 @@ + + + + + + +Internet Engineering Task Force (IETF) J. Snijders +Request for Comments: 8195 J. Heasley +Category: Informational NTT +ISSN: 2070-1721 M. Schmidt + i3D.net + June 2017 + + + Use of BGP Large Communities + +Abstract + + This document presents examples and inspiration for operator + application of BGP Large Communities. Based on operational + experience with BGP Communities, this document suggests logical + categories of BGP Large Communities and demonstrates an orderly + manner of organizing community values within them to achieve typical + goals in routing policy. Any operator can consider using the + concepts presented as the basis for their own BGP Large Communities + repertoire. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are a candidate for any level of Internet + Standard; see Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc8195. + + + + + + + + + + + + + + + +Snijders, et al. Informational [Page 1] + +RFC 8195 Use of BGP Large Communities June 2017 + + +Copyright Notice + + Copyright (c) 2017 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. The Design Overview . . . . . . . . . . . . . . . . . . . . . 3 + 2.1. Informational Communities . . . . . . . . . . . . . . . . 4 + 2.2. Action Communities . . . . . . . . . . . . . . . . . . . 5 + 3. Examples of Informational Communities . . . . . . . . . . . . 5 + 3.1. Location . . . . . . . . . . . . . . . . . . . . . . . . 5 + 3.1.1. An ISO 3166-1 Numeric Function . . . . . . . . . . . 6 + 3.1.2. A UN M.49 Region Function . . . . . . . . . . . . . . 6 + 3.2. Relation Function . . . . . . . . . . . . . . . . . . . . 7 + 3.3. Combining Informational Communities . . . . . . . . . . . 7 + 4. Examples of Action Communities . . . . . . . . . . . . . . . 7 + 4.1. Selective NO_EXPORT . . . . . . . . . . . . . . . . . . . 7 + 4.1.1. ASN-Based Selective NO_EXPORT . . . . . . . . . . . . 8 + 4.1.2. Location-Based Selective NO_EXPORT . . . . . . . . . 8 + 4.2. Selective AS_PATH Prepending . . . . . . . . . . . . . . 9 + 4.2.1. ASN-Based Selective AS_PATH Prepending . . . . . . . 9 + 4.2.2. Location-Based Selective AS_PATH Prepending . . . . . 10 + 4.3. Manipulation of the LOCAL_PREF Attribute . . . . . . . . 10 + 4.3.1. Global Manipulation of LOCAL_PREF . . . . . . . . . . 11 + 4.3.2. Region-Based Manipulation of LOCAL_PREF . . . . . . . 11 + 4.3.3. Note of Caution for LOCAL_PREF Functions . . . . . . 12 + 4.4. Route Server Prefix Distribution Control . . . . . . . . 12 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 + 7.1. Normative References . . . . . . . . . . . . . . . . . . 14 + 7.2. Informative References . . . . . . . . . . . . . . . . . 14 + Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 15 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 + + + + + +Snijders, et al. Informational [Page 2] + +RFC 8195 Use of BGP Large Communities June 2017 + + +1. Introduction + + BGP Large Communities [RFC8092] provide a mechanism to signal opaque + information between and within Autonomous Systems (ASes). In very + much the same way that [RFC1998] provides a concrete real-world + application for BGP Communities [RFC1997], this document presents + examples of how operators might utilize BGP Large Communities to + achieve various goals. This document draws on the experience of + operator communities such as the North American Network Operators' + Group (NANOG) and the Netherlands Network + Operator Group (NLNOG) . + +2. The Design Overview + + BGP Large Communities are composed of three 4-octet fields. The + first is the Global Administrator (GA) field, whose value is the + Autonomous System Number (ASN) of the AS that has defined the meaning + of the remaining two 4-octet fields, known as "Local Data Part 1" and + "Local Data Part 2". This document describes an approach where the + "Local Data Part 1" field contains a function identifier and the + "Local Data Part 2" contains a parameter value. Using the canonical + notation this format can be summarized as "ASN:Function:Parameter". + + +----------------------+---------------+ + | RFC 8092 | this document | + +----------------------+---------------+ + | Global Administrator | ASN | + | Local Data Part 1 | Function | + | Local Data Part 2 | Parameter | + +----------------------+---------------+ + + Table 1: Field Mapping + + The table above shows a mapping table between the fields in BGP Large + Communities [RFC8092] and this document. + + In contemporary deployments of both BGP Communities [RFC1997] and BGP + Large Communities [RFC8092], the function of a community can be + divided into two categories: + + o Informational Communities + + o Action Communities + + + + + + + + +Snijders, et al. Informational [Page 3] + +RFC 8195 Use of BGP Large Communities June 2017 + + + Throughout the document, a topology of four ASes is used to + illustrate the use of communities in the following configuration: + + AS 65551 + | + ^ + | + AS 64497 + / \ + ^ \ + / ^ + AS 64498 \ + | | + `<->- AS 64499 + + AS 64497 obtains transit services from (is a customer of) AS 65551, a + 4-octet ASN. AS 64497 provides transit services to both AS 64498 and + AS 64499. AS 64498 and AS 64499 maintain a peering relationship in + which they only exchange their customer routes. + + The opaque nature of BGP Large Communities allows for rapid + deployment of new features or changes to their routing policy that + perform an action. Operators are encouraged to publicly publish and + maintain documentation on the purpose of each BGP Large Community, + both Informational and Action, that they support or that are visible + in BGP RIBs. + +2.1. Informational Communities + + Informational Communities are labels for attributes such as the + origin of the route announcement, the nature of the relation with an + External BGP (EBGP) neighbor, or the intended propagation audience. + Informational Communities can also assist in providing valuable + information for day-to-day network operations such as debugging or + capacity planning. + + The Global Administrator field is set to the ASN of the network that + tags the routes with the Informational Communities. For example, AS + 64497 might add a community with the GA 64497 to a route accepted + from an Internal BGP (IBGP) or EBGP neighbor as a means of signaling + that it was imported in a certain geographical region. + + In general, the intended audiences of Informational Communities are + downstream networks and the GA itself, but any AS could benefit from + receiving these communities. + + + + + + +Snijders, et al. Informational [Page 4] + +RFC 8195 Use of BGP Large Communities June 2017 + + +2.2. Action Communities + + Action Communities are added as labels to request that a route be + treated in a particular way within an AS. The operator of the AS + defines a routing policy that adjusts path attributes based on the + community. For example, the route's propagation characteristics, the + LOCAL_PREF (local preference), the next hop, or the number of AS_PATH + prepends to be added when it is received or propagated can be + changed. + + The Global Administrator field is set to the ASN that has defined the + functionality of that BGP Large Community and is the ASN that is + expected to perform the action. For example, AS 64499 might label a + route with a BGP Large Community containing GA 64497 to request that + AS 64497 perform a predefined action on that route. + + In general, the intended audience of Action Communities are transit + providers taking action on behalf of a customer or the GA itself, but + any AS could take action if they choose and any AS could add an + Action Community with the GA of a non-adjacent ASN. However, note + that an Action Community could also be Informational. Its presence + is an indicator that the GA may have performed the action and that an + AS in the AS_PATH requested it. + + Operators are recommended to publish the relative order in which + Action Communities (both BGP Communities and BGP Large Communities) + are processed in their routing policy. + +3. Examples of Informational Communities + +3.1. Location + + An AS, AS 64497 in these examples, may inform other networks about + the geographical region where AS 64497 imported a route by labeling + it with BGP Large Communities following one of the following schemes + or a combination of them. + + + + + + + + + + + + + + + +Snijders, et al. Informational [Page 5] + +RFC 8195 Use of BGP Large Communities June 2017 + + +3.1.1. An ISO 3166-1 Numeric Function + + AS 64497 could assign a value of 1 to the Function field to designate + the content of the Parameter field as an ISO 3166-1 numeric country + identifier . + + +---------------------+---------------------------------------------+ + | BGP Large Community | Description | + +---------------------+---------------------------------------------+ + | 64497:1:528 | Route learned in the Netherlands | + | 64497:1:392 | Route learned in Japan | + | 64497:1:840 | Route learned in the United States of | + | | America | + +---------------------+---------------------------------------------+ + + Table 2: Informational: ISO 3166-1 + + The table above shows example documentation for Informational + Communities deployed by AS 64497 to describe the location where a + route was imported using ISO 3166-1 numeric identifiers. + +3.1.2. A UN M.49 Region Function + + AS 64497 could assign a value of 2 to the Function field to designate + the content of the Parameter field as the M.49 numeric code published + by the United Nations Statistics Division (UNSD) + for macro-geographical + (continental) regions, geographical sub-regions, or selected economic + and other groupings. + + +---------------------+-------------------------------+ + | BGP Large Community | Description | + +---------------------+-------------------------------+ + | 64497:2:2 | Route learned in Africa | + | 64497:2:9 | Route learned in Oceania | + | 64497:2:145 | Route learned in Western Asia | + | 64497:2:150 | Route learned in Europe | + +---------------------+-------------------------------+ + + Table 3: Informational: UNSD Regions + + The table above shows example documentation for Informational + Communities deployed by AS 64497 to describe the location where a + route was imported using M.49 numeric codes published by the UNSD. + + + + + + + +Snijders, et al. Informational [Page 6] + +RFC 8195 Use of BGP Large Communities June 2017 + + +3.2. Relation Function + + An AS, AS 64497 in this example, could assign a value of 3 to the + Function field to designate the content of the Parameter field as a + number indicating whether the route originated inside its own network + or was learned externally, and if learned externally, it might + simultaneously characterize the nature of the relation with that + specific EBGP neighbor. + + +---------------------+---------------------------------------+ + | BGP Large Community | Description | + +---------------------+---------------------------------------+ + | 64497:3:1 | Route originated internally | + | 64497:3:2 | Route learned from a customer | + | 64497:3:3 | Route learned from a peering partner | + | 64497:3:4 | Route learned from a transit provider | + +---------------------+---------------------------------------+ + + Table 4: Informational: Relation + + The table above shows example documentation for Informational + Communities deployed by AS 64497 to describe the relation to the ASN + from which the route was learned. + +3.3. Combining Informational Communities + + A route may be labeled with multiple Informational Communities. For + example, a route learned in the Netherlands from a customer might be + labeled with communities 64497:1:528, 64497:2:150, and 64497:3:2 at + the same time. + +4. Examples of Action Communities + +4.1. Selective NO_EXPORT + + As part of an agreement, often a commercial transit agreement, + between AS 64497 and AS 64498, AS 64497 might expose BGP traffic- + engineering functions to AS 64498. One such BGP traffic-engineering + function could be selective NO_EXPORT, which is the selective + filtering of a route learned from one AS, AS 64498, to certain EBGP + neighbors of the GA, AS 64497. + + + + + + + + + + +Snijders, et al. Informational [Page 7] + +RFC 8195 Use of BGP Large Communities June 2017 + + +4.1.1. ASN-Based Selective NO_EXPORT + + AS 64497 could assign a value of 4 to the Function field to designate + the content of the Parameter field as a neighboring ASN to which a + route should not be propagated. + + +---------------------+---------------------------------+ + | BGP Large Community | Description | + +---------------------+---------------------------------+ + | 64497:4:64498 | Do not export route to AS 64498 | + | 64497:4:64499 | Do not export route to AS 64499 | + | 64497:4:65551 | Do not export route to AS 65551 | + +---------------------+---------------------------------+ + + Table 5: Action: ASN NO_EXPORT + + The table above shows example documentation for Action Communities + deployed by AS 64497 to expose a BGP traffic-engineering function + that selectively prevents the propagation of routes to the + neighboring ASN specified in the Parameter field. + +4.1.2. Location-Based Selective NO_EXPORT + + AS 64497 could assign a value of 5 to the Function field to designate + the content of the Parameter field as an ISO 3166-1 numeric country + identifier within which a labeled route is not propagated to EBGP + neighbors. However, this might not prevent one of those EBGP + neighbors from learning that route in another country and making it + available in the country specified by the BGP Large Community. + + +-----------------+-------------------------------------------------+ + | BGP Large | Description | + | Community | | + +-----------------+-------------------------------------------------+ + | 64497:5:528 | Do not export to EBGP neighbors in the | + | | Netherlands | + | 64497:5:392 | Do not export to EBGP neighbors in Japan | + | 64497:5:840 | Do not export to EBGP neighbors in the United | + | | States of America | + +-----------------+-------------------------------------------------+ + + Table 6: Action: NO_EXPORT in Region + + The table above shows example documentation for Action Communities + deployed by AS 64497 to expose a BGP traffic-engineering function + that selectively prevents the propagation of routes to all EBGP + neighbors in the geographical region specified in the Parameter + field. + + + +Snijders, et al. Informational [Page 8] + +RFC 8195 Use of BGP Large Communities June 2017 + + +4.2. Selective AS_PATH Prepending + + As part of an agreement between AS 64497 and AS 64498, AS 64497 might + expose BGP traffic-engineering functions to AS 64498. One such BGP + traffic-engineering function could be selective prepending of the + AS_PATH with AS 64497 to certain EBGP neighbors of AS 64497. + +4.2.1. ASN-Based Selective AS_PATH Prepending + + AS 64497 could assign a value of 6 to the Function field to designate + the content of the Parameter field as a neighboring ASN to which + prepending of the AS_PATH with AS 64497 is requested on propagation + of the route. Additional AS_PATH prepending functions might also be + defined to support multiples of prepending, that is, two, three, or + more prepends of AS 64497. + + +---------------------+------------------------------------------+ + | BGP Large Community | Description | + +---------------------+------------------------------------------+ + | 64497:6:64498 | Prepend 64497 once on export to AS 64498 | + | 64497:6:64499 | Prepend 64497 once on export to AS 64499 | + | 64497:6:65551 | Prepend 64497 once on export to AS 65551 | + +---------------------+------------------------------------------+ + + Table 7: Action: Prepend to ASN + + The table above shows example documentation for Action Communities + deployed by AS 64497 to expose a BGP traffic-engineering function + that selectively prepends the AS_PATH with AS 64497 when propagating + the route to the specified EBGP neighbor. + + + + + + + + + + + + + + + + + + + + + +Snijders, et al. Informational [Page 9] + +RFC 8195 Use of BGP Large Communities June 2017 + + +4.2.2. Location-Based Selective AS_PATH Prepending + + AS 64497 could assign a value of 7 to the Function field to designate + the content of the Parameter field as an ISO 3166-1 numeric country + identifier to which the prepending of the AS_PATH with AS 64497 is + requested on propagation of the route to all EBGP neighbors in that + region. + + +-----------------+-------------------------------------------------+ + | BGP Large | Description | + | Community | | + +-----------------+-------------------------------------------------+ + | 64497:7:528 | Prepend once to EBGP neighbors in the | + | | Netherlands | + | 64497:7:392 | Prepend once to EBGP neighbors in Japan | + | 64497:7:840 | Prepend once to EBGP neighbors in the United | + | | States of America | + +-----------------+-------------------------------------------------+ + + Table 8: Action: Prepend in Region + + The table above shows example documentation for Action Communities + deployed by AS 64497 to expose a BGP traffic-engineering function + that selectively prepends the AS_PATH with AS 64497 when propagating + the route to all EBGP neighbors in the geographical region specified + in the Parameter field. + +4.3. Manipulation of the LOCAL_PREF Attribute + + As part of an agreement between AS 64497 and AS 64498, AS 64497 might + expose BGP traffic-engineering functions to AS 64498. One such BGP + traffic-engineering function might allow AS 64498 to manipulate the + value of the LOCAL_PREF attribute of routes learned from AS 64498 + within AS 64497, even though the LOCAL_PREF attribute is + non-transitive and is not propagated to EBGP neighbors. + + The LOCAL_PREF value of routes are locally significant within each AS + and are impossible to list in this document. Instead, the typical + LOCAL_PREF values could be classified as a hierarchy, and a BGP Large + Community function could be exposed, allowing an EBGP neighbor to + affect the LOCAL_PREF value within the specified GA. The following + example list defines the classes of routes in the order of descending + LOCAL_PREF value and assigns a function identifier that could be used + in the Function field of a BGP Large Community. + + + + + + + +Snijders, et al. Informational [Page 10] + +RFC 8195 Use of BGP Large Communities June 2017 + + + +----------+--------------------------------------------------------+ + | Function | Preference Class | + +----------+--------------------------------------------------------+ + | 8 | Normal customer route | + | 9 | Backup customer route | + | 10 | Peering route | + | 11 | Upstream transit route | + | 12 | Fallback route, to be installed if no other path is | + | | available | + +----------+--------------------------------------------------------+ + + Table 9: Action: Preference Function Identifiers + +4.3.1. Global Manipulation of LOCAL_PREF + + AS 64497 could place one of the previously defined Preference + Function Identifiers in the Function field and set the value 0 in the + Parameter field to designate that the LOCAL_PREF associated with that + function identifier should be applied for that route throughout the + whole AS. + + +---------------------+---------------------------------------------+ + | BGP Large Community | Description | + +---------------------+---------------------------------------------+ + | 64497:9:0 | Assign LOCAL_PREF for a customer backup | + | | route | + | 64497:10:0 | Assign LOCAL_PREF for a peering route | + | 64497:12:0 | Assign LOCAL_PREF for a fallback route | + +---------------------+---------------------------------------------+ + + Table 10: Action: Global LOCAL_PREF Manipulation + + The table above shows example documentation for Action Communities + deployed by AS 64497 to expose a BGP traffic-engineering function + that allows a BGP neighbor to globally manipulate the LOCAL_PREF + attribute for the route within AS 64497. + +4.3.2. Region-Based Manipulation of LOCAL_PREF + + AS 64497 could place one of the previously defined Preference + Function Identifiers in the Function field and use a UN M.49 numeric + region identifier in the Parameter field to designate the + geographical region within which the non-default LOCAL_PREF + associated with that function identifier should be applied to the + route. The value of the LOCAL_PREF attribute should not deviate from + the default for that route class in any region not specified by one + or more of these Action Communities. + + + + +Snijders, et al. Informational [Page 11] + +RFC 8195 Use of BGP Large Communities June 2017 + + + +--------------+----------------------------------------------------+ + | BGP Large | Description | + | Community | | + +--------------+----------------------------------------------------+ + | 64497:9:3 | Assign the LOCAL_PREF value equivalent to a | + | | customer backup class route on BGP routers in the | + | | North America region | + | 64497:10:5 | Assign the LOCAL_PREF value equivalent to a | + | | peering class route on BGP routers in the South | + | | America region | + | 64497:12:142 | Assign the LOCAL_PREF value equivalent to a | + | | fallback class route on BGP routers in the Asia | + | | region | + +--------------+----------------------------------------------------+ + + Table 11: Action: Regional LOCAL_PREF Manipulation + + The table above shows example documentation for Action Communities + deployed by AS 64497 to expose a BGP traffic-engineering function + that allows a BGP neighbor to selectively manipulate the LOCAL_PREF + attribute within AS 64497 in the geographical region specified in the + Parameter field. + +4.3.3. Note of Caution for LOCAL_PREF Functions + + The LOCAL_PREF attribute strongly influences the BGP Decision + Process, which in turn affects the scope of route propagation. + Operators should take special care when using Action Communities that + decrease the LOCAL_PREF value, and the degree of preference, to a + value below that of another route class. Some of the unintended BGP + states that might arise as a result of these traffic-engineering + decisions are described as "BGP Wedgies" in [RFC4264]. + +4.4. Route Server Prefix Distribution Control + + Route servers [RFC7947] use BGP to broker network reachability + information among their clients. As not all route server clients may + wish to interconnect with each other, the route server operator will + usually implement a mechanism to allow each client to control the + route server's export routing policy, as described in Section 4.6 of + [RFC7948]. One widely used mechanism is an adaption of "ASN-Based + Selective NO_EXPORT" (Section 4.1.1) that is specific to route + servers. + + + + + + + + +Snijders, et al. Informational [Page 12] + +RFC 8195 Use of BGP Large Communities June 2017 + + + An example BGP Large Communities policy that enables client- + controlled prefix distribution for a route server operating as AS + 64511 is outlined as follows: + + +-------------------+-----------------------------------------------+ + | BGP Large | Description | + | Community | | + +-------------------+-----------------------------------------------+ + | 64511:0:peer-as | Explicitly prevent announcement of route to | + | | peer-as | + | 64511:1:peer-as | Explicitly announce route to peer-as | + | 64511:0:0 | Do not announce route to any peers by default | + | 64511:1:0 | Announce route to all peers by default | + +-------------------+-----------------------------------------------+ + + Table 12: Action: Route Server Prefix Distribution Control + + Multiple BGP Large Community values can be used together to implement + fine-grained route distribution control. For example, route server + client AS 64500 might wish to use a route server for interconnecting + to all other clients except AS 64509. In this case, they would label + all their outbound routes to the route server with 64511:1:0 (to + announce to all clients by default) and 64511:0:64509 (to prevent + announcement to AS 64509). + + Alternatively, route server client AS 64501 may have a selective + routing policy and may wish to interconnect with only AS 64505 and AS + 64506. This could be implemented by announcing routes labeled with + 64511:0:0 (blocking all distribution by default) and 64511:1:64505, + 64511:1:64506 to instruct the route server to force announcement to + those two ASNs. + +5. Security Considerations + + Operators should note the recommendations in Section 11 of "BGP + Operations and Security" [RFC7454] and handle BGP Large Communities + with their ASN in the Global Administrator field similarly. + + In particular and in the same respect as BGP Communities [RFC1997], + operators should be cognizant that any Large Community can be carried + in a BGP UPDATE. Operators should recognize that BGP neighbors, + particularly customers and customers of customers, may utilize + communities defined by other BGP neighbors of the operator. They may + wish to send routes with Action Communities and receive routes with + Informational Communities to or from these other neighbors, and it is + beneficial to all to permit this. + + + + + +Snijders, et al. Informational [Page 13] + +RFC 8195 Use of BGP Large Communities June 2017 + + +6. IANA Considerations + + This document does not require any IANA actions. + +7. References + +7.1. Normative References + + [RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities + Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996, + . + + [RFC7454] Durand, J., Pepelnjak, I., and G. Doering, "BGP Operations + and Security", BCP 194, RFC 7454, DOI 10.17487/RFC7454, + February 2015, . + + [RFC8092] Heitz, J., Ed., Snijders, J., Ed., Patel, K., Bagdonas, + I., and N. Hilliard, "BGP Large Communities Attribute", + RFC 8092, DOI 10.17487/RFC8092, February 2017, + . + +7.2. Informative References + + [RFC1998] Chen, E. and T. Bates, "An Application of the BGP + Community Attribute in Multi-home Routing", RFC 1998, + DOI 10.17487/RFC1998, August 1996, + . + + [RFC4264] Griffin, T. and G. Huston, "BGP Wedgies", RFC 4264, + DOI 10.17487/RFC4264, November 2005, + . + + [RFC7947] Jasinska, E., Hilliard, N., Raszuk, R., and N. Bakker, + "Internet Exchange BGP Route Server", RFC 7947, + DOI 10.17487/RFC7947, September 2016, + . + + [RFC7948] Hilliard, N., Jasinska, E., Raszuk, R., and N. Bakker, + "Internet Exchange BGP Route Server Operations", RFC 7948, + DOI 10.17487/RFC7948, September 2016, + . + + + + + + + + + + +Snijders, et al. Informational [Page 14] + +RFC 8195 Use of BGP Large Communities June 2017 + + +Acknowledgments + + The authors would like to gratefully acknowledge the insightful + comments, contributions, critique, and support from Adam Chappell, + Jonathan Stewart, Greg Hankins, Nick Hilliard, Will Hargrave, Randy + Bush, Shawn Morris, Jay Borkenhagen, and Stewart Bryant. + +Authors' Addresses + + Job Snijders + NTT Communications + Theodorus Majofskistraat 100 + Amsterdam 1065 SZ + The Netherlands + + Email: job@ntt.net + + + John Heasley + NTT Communications + 1111 NW 53rd Drive + Portland, OR 97210 + United States of America + + Email: heas@shrubbery.net + + + Martijn Schmidt + i3D.net + Rivium 1e Straat 1 + Capelle aan den IJssel 2909 LE + The Netherlands + + Email: martijnschmidt@i3d.net + + + + + + + + + + + + + + + + + +Snijders, et al. Informational [Page 15] + -- cgit v1.2.3