Global Routing Operations J. Snijders Internet-DraftNTTJ. Heasley Intended status: InformationalM. SchmidtNTT Expires:June 10,August 20, 2017 M. Schmidt i3D.netDecember 7, 2016February 16, 2017 Usage ofLargeBGP Large Communitiesdraft-ietf-grow-large-communities-usage-01draft-ietf-grow-large-communities-usage-02 Abstract Examples and inspiration for operatorson how tofor the useLargeof BGP Large Communities. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire onJune 10,August 20, 2017. Copyright Notice Copyright (c)20162017 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. The Generic Design Pattern . . . . . . . . . . . . . . . . . 3 2.1. Informational Communities . . . . . . . . . . . . . . . . 3 2.2. Action Communities . . . . . . . . . . . . . . . . . . . 4 3. Examples of Informational Communities . . . . . . . . . . . . 4 3.1. Location . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1.1. An ISO 3166-1 numeric function . . . . . . . . . . . 4 3.1.2. An UNSD region function . . . . . . . . . . . . . . . 5 3.2. Relation . . . . . . . . . . . . . . . . . . . . . . . . 5 3.3. Combining Informational Communities . . . . . . . . . . . 6 4. Examples of Action Communities . . . . . . . . . . . . . . . 6 4.1. Selective NO_EXPORT . . . . . . . . . . . . . . . . . . . 6 4.1.1. Peer ASN Based Selective NO_EXPORT . . . . . . . . . 6 4.1.2. Location Based Selective NO_EXPORT . . . . . . . . . 7 4.2. Selective AS_PATH Prepending . . . . . . . . . . . . . . 7 4.2.1. Peer ASN Based Selective AS_PATH Prepending . . . . . 7 4.2.2. Location Based Selective AS_PATH Prepending . . . . . 8 4.3. Location based manipulation of LOCAL_PREF . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 8.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 1. IntroductionLargeBGP Large Communities[I-D.ietf-idr-large-community][RFC8092] provide a mechanism to signal opaque information between Autonomous Systems. This document presents a set of examplesonof how Large BGP Communities could beimplementedemployed by an operator to achieve various goals. This document draws from experience in Operational Communities such as NANOG [1] and NLNOG [2]. The opaque nature ofLargeBGP Large Communities allows for rapid deployment of new features or changes to the product. Operators are encouraged to publicly publishan up to date versionand maintain documentation of the purpose oftheir routing policy in which they document whateach Large BGPCommunity means.Community, both informational and action, that they support or are visible in looking glasses. 2. The Generic Design PatternLargeBGP Large Communities are composed of a 4-octet Global Administrator field followed by two 4-octet Local Data fields. Large BGP Communities are compose three 4-octet fields. Thedesign pattern described in thisfirst is the Global Administrator field, whose value is the ASN of AS that has defined the meaning of the remaining two 4-octet fields, the Local Data fields. This documentuses adescribes an approach defining these fields as "ASN:Function:Parameter"-approach to fill the three fields. In deployments of both BGP Communities [RFC1997] andLargeBGP Large Communities, two categories of Communitiesare recognised:exist: o Informational Communities o Action Communities Foreach contexteach, ideas are provided regarding the contents of each of the three fields inLargeBGP Large Communities. Throughout the document a topology of four Autonomous Systems is used to illustrate the usage of Communities in the following configuration: AS 65551 | ^ | AS 64497 / \ ^ \ / ^ AS 64498 \ | | `<->- AS 64499 AS 64497 obtains transit services from AS65551.65551, a 32-bit ASN. AS 64497 provides transit services to both AS 64498 and AS 64499. AS 64498 and AS 64499 maintain a peeringrelationrelationship in which they only exchange their customer routes. 2.1. Informational Communities Informational Communitesserveare labels for attributes such asmarkers regarding theorigin of the route announcement, the relation with the EBGP neighbor or for instance the intended propagation audience. Informational Communities also assist in network operations such as debugging. The Global Administrator field is set to the ASN which is marking the routes with the Informational Communities.As an example: on a route which AS 64497 announces to AS 64498,For example, AS 64497 might add a community with theLarge BGP Community 64497:100:31 to signalGA 64497 toAS 64498a route learned from an iBGP or eBGP peer that means that the route was learned from or originated by a device in the Netherlands. In general the intended audience of Informational Communities are downstreamnetworks,networks and the Global Administrator itself, but anyadjacentAutonomous System could benefit from receiving these communities. 2.2. Action Communities Action Communities are attached to routes to request non-default behaviour in this, a conferation or anadjacent Autonomous System. For instance,external AS. Action Communitiesarecould be used to change the route's propagation characteristics, theroute's LOCAL_PREF valueLOCAL_PREFENCE or theamountnumber of AS_PATH prependsthat should be addedto add when exporting or importing a route. The Global Administrator field is set to the ASN which is expected to performa non-default action upon receivingtheroute.action. For instance,ifAS 64499would wantmight add a Large Community with the GA 64497 torequestsignal AS 64497 tolower the LOCAL_PREFERENCE below the default, AS 64499 could tag the route with 64497:20:50.perform an action upon that route. In general the intended audience of Action Communities is an upstreamprovider.provider, but realistically could be any AS willing to act upon it. 3. Examples of Informational Communities 3.1. Location AS 64497 can inform its downstream networks about the geographical entity where AS 64497 learned a route by marking the route withLargeBGP Large Communities following one or a combination of the following schemes. 3.1.1. An ISO 3166-1 numeric function AS 64497 could assign a value of 1 to the first Local Data field to designate the function of theparameter in thesecond Local Data field as ISO-3166-1 numeric country identifiers. +---------------------+-------------------------------------------+ |LargeBGP Large Community |MeaningDescription | +---------------------+-------------------------------------------+ | 64497:1:528 | Route learned in Netherlands | | 64497:1:392 | Route learned in Japan | | 64497:1:840 | Route learned in United States of America | +---------------------+-------------------------------------------+ Example documentation for AS 64497 using InformationalCommuntiesCommunities describing the origin of routes using ISO 3166-1 numeric identifiers. Table 1: Information: ISO 3166-1 3.1.2. An UNSD region function AS 64497 could assign a value of 2 to the first Local Data field to designate the function of the parameter in the second Local Data field as an identifier for the macro geographical (continental) regions, geographical sub-regions, or selected economic and other groupings following a set of published identifiers by the United Nations Statistics Division [3]. +---------------------+-------------------------------+ |LargeBGP Large Community |MeaningDescription | +---------------------+-------------------------------+ | 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 | +---------------------+-------------------------------+ Example documentation for AS 64497 using InformationalCommuntiesCommunities describing the origin of routes using numeric identifiers provided by the UN Statistics Division. Table 2: Information: Regions 3.2. Relation AS 64497 could assign a value of 3 to the first Local Data field to designate that the second Local Data field contains an identifier showing the relation with the EBGP neighbor from whom the route was received. +---------------------+-----------------------------------------+ |LargeBGP Large Community |MeaningDescription | +---------------------+-----------------------------------------+ | 64497:3:1 | Route learned from a customer | | 64497:3:2 | Route learned from a peering partner | | 64497:3:3 | Route learned from an upstream provider | +---------------------+-----------------------------------------+ Example documentation for AS 64497 using InformationalCommuntiesCommunities describing the relation with the ASN from which the route was received. Table 3: Information: Relation 3.3. Combining Informational Communities Multiple Informational Communities can be tagged on a route, for example: a route learned in the Netherlands from a customer can contain both 64497:1:528 and 64497:2:150 and 64497:3:1. 4. Examples of Action Communities 4.1. Selective NO_EXPORT As part of the commercial agreement between AS 64497 and AS 64498, AS 64497 might offer AS 64498 certain BGP Traffic Engineering features such as selectively not export routes learned from 64498 to certain EBGP neighbors of AS 64497. 4.1.1. Peer ASN Based Selective NO_EXPORT AS 64497 might assign function identifier 4 to allow preventing propagation of routes to the ASN listed in the second Local Data field. +---------------------+---------------------------------+ |LargeBGP Large Community |MeaningDescription | +---------------------+---------------------------------+ | 64497:4:2914 | Do not export route to AS 2914 | | 64497:4:7018 | Do not export route to AS 7018 | | 64497:4:65551 | Do not export route to AS 65551 | +---------------------+---------------------------------+ Example documentation for AS 64497 offering ActionCommuntiesCommunities to limit propagation of routes based on the Peer ASN described in the third field. Table 4: Action: Peer ASN NO_EXPORT 4.1.2. Location Based Selective NO_EXPORT AS 64497 might assign function identifier 5 to allow its customers to request selectively not exporting routes on EBGP sessions within a certain geographical area. This example follows the ISO 3166-1 numeric encoding. +------------------+------------------------------------------------+ |LargeBGP Large |MeaningDescription | | 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 United | | | States of America | +------------------+------------------------------------------------+ Example documentation for AS 64497 offering ActionCommuntiesCommunities to trigger NO_EXPORT on routes only when propagating the route to a certain geographical region. Table 5: Action: NO_EXPORT in Region 4.2. Selective AS_PATH Prepending As part of the commercial agreement between AS 64497 and AS 64498, AS 64497 might offer AS 64498 certain BGP Traffic Engineering features such as selectively prepending the AS_PATH with 64497's ASN to certain EBGP neighbors of AS 64497. 4.2.1. Peer ASN Based Selective AS_PATH Prepending AS 64497 might assign function identifier 6 to allow prepending the AS_PATH on propagation of routes to the ASN listed in the second Local Data field. +---------------------+------------------------------------------+ |LargeBGP Large Community |MeaningDescription | +---------------------+------------------------------------------+ | 64497:6:2914 | Prepend 64497 once on export to AS 2914 | | 64497:6:7018 | Prepend 64497 once on export to AS 7018 | | 64497:6:65551 | Prepend 64497 once on export to AS 65551 | +---------------------+------------------------------------------+ Example documentation for AS 64497 offering ActionCommuntiesCommunities to trigger prepending of the AS_PATH only when propagating the route to a certain Peer ASN. Table 6: Action: Prepend to Peer ASN 4.2.2. Location Based Selective AS_PATH Prepending AS 64497 might assign function identifier 7 to allow prepending of the AS_PATH on propagation of routes to on any EBGP neighbor's interconnection in the geographical entity listed in the second Local Data field. This example follows the ISO 3166-1 numeric regions codes in the Local Data 2 field. +------------------+------------------------------------------------+ |LargeBGP Large |MeaningDescription | | 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 United | | | States of America | +------------------+------------------------------------------------+ Example documentation for AS 64497 offering ActionCommuntiesCommunities to trigger prepending of the AS_PATH only when propagating the route to a certain geographical region. Table 7: Action: Prepend in Region 4.3. Location based manipulation of LOCAL_PREF In some cases, it can be desirable for an autonomous system to allow adjacent Autonomous Systems to directly influence the degree of preference associated with a route, usually expressed within the LOCAL_PREF attribute. Furthermore, in the case of large networks spanning significant geography, it is often also useful to be able to extend this capability and scope its effect to a geographic region. This is a more powerful mechanism than AS_PATH prepending, but since degree of preference determines BGP route selection and thus onward advertisement, it can also be self-limiting in its scope. Since the LOCAL_PREF attribute which influences degree of preference is locally significant within each autonomous system, it is not usually practical or useful to compare LOCAL_PREF attribute values between autonomous systems. Instead it can be useful to classify the major types of route likely to exist within an autonomous system's routing hierarchy and provide an ability to set one's route to that preference: o A qualified customer route. Usually the highest preference. o A peer, or network-share, route. A co-operating network provider engaged in a partnership for customer coverage ("peering"). o A last resort, or backup route. It is entirely possible that some providers may have more classes of route preference but it is possible to codify both the route preference class and the regional scope within the Local Data fields of the Large Community attribute. For example, AS64497 might establish the following function identifiers to set route preference class, which could allow pairing with a location or peer-based operand to determine scope. +----------+-----------------------------------------------+ | Function | Preference Class | +----------+-----------------------------------------------+ | 10 | Qualified customer route. Highest preference. | | 15 | Peering partner. Median preference. | | 19 | Route of last resort. Lowest preference. | +----------+-----------------------------------------------+ Table 8: Action: Preference Function Identifiers Once established, these route preference setting functions can be linked with a scoping operand such as per-peer or per-location based identifiers in order to provide AS64497's customers with a comprehensive and rich toolset to influence route preference. +--------------------+----------------------------------------------+ |LargeBGP Large |MeaningDescription | | Community | | +--------------------+----------------------------------------------+ | 64497:15:528 | Set as peer route in Netherlands | | 64497:19:840 | Set as backup route in United States of | | | America | +--------------------+----------------------------------------------+ Table 9: Action: Regional Preference Communities Since the degree of preference influences BGP best path selection (which in turn influences onward route propagation) Operators should take special care with a traffic engineering tool such as location based local preference influence (BGP Wedgies [RFC4264]). 5. Security Considerations Network operators should note the recommendations in Section 11 of BGP Operations and Security [RFC7454]. 6. IANA Considerations None. 7. Acknowledgements The authors would like to gratefully acknowledge the insightful comments, contributions, critique and support from John Heasley, AdamChappell andChappell, JonathanStewart.Stewart, and Will Hargrave. 8. References 8.1. Normative References[I-D.ietf-idr-large-community] Heitz, J., Snijders, J., Patel, K., Bagdonas, I., and N. Hilliard, "BGP Large Communities", draft-ietf-idr-large- community-11 (work in progress), December 2016.[RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996, <http://www.rfc-editor.org/info/rfc1997>. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>. [RFC4264] Griffin, T. and G. Huston, "BGP Wedgies", RFC 4264, DOI 10.17487/RFC4264, November 2005, <http://www.rfc-editor.org/info/rfc4264>. [RFC7454] Durand, J., Pepelnjak, I., and G. Doering, "BGP Operations and Security", BCP 194, RFC 7454, DOI 10.17487/RFC7454, February 2015, <http://www.rfc-editor.org/info/rfc7454>. [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, <http://www.rfc-editor.org/info/rfc8092>. 8.2. URIs [1] http://nanog.net [2] http://nlnog.net [3] http://unstats.un.org/unsd/methods/m49/m49regin.htm Authors' Addresses Job Snijders NTT Communications Theodorus Majofskistraat 100 Amsterdam 1065 SZNLThe Netherlands Email: job@ntt.net John Heasley NTT Communications 12160 NW Coleman Drive Portland, OR 97229 United States of America Email: heas@shrubbery.net Martijn Schmidt i3D.net Rivium 1e Straat 1 Capelle aan den IJssel 2909 LE NL Email: martijnschmidt@i3d.net