idnits 2.17.1 draft-snijders-grow-large-communities-usage-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 30, 2016) is 2727 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 393 -- Looks like a reference, but probably isn't: '2' on line 395 -- Looks like a reference, but probably isn't: '3' on line 397 == Outdated reference: A later version (-12) exists of draft-ietf-idr-large-community-06 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 GROW J. Snijders 3 Internet-Draft NTT 4 Intended status: Informational M. Schmidt 5 Expires: May 3, 2017 i3D.net 6 October 30, 2016 8 Usage of Large BGP Communities 9 draft-snijders-grow-large-communities-usage-00 11 Abstract 13 Examples and inspiration for operators on how to use Large BGP 14 Communities. 16 Requirements Language 18 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 19 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 20 document are to be interpreted as described in [RFC2119]. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on May 3, 2017. 39 Copyright Notice 41 Copyright (c) 2016 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. The Generic Design Pattern . . . . . . . . . . . . . . . . . 3 58 2.1. Informational Communities . . . . . . . . . . . . . . . . 3 59 2.2. Action Communities . . . . . . . . . . . . . . . . . . . 4 60 3. Examples of Informational Communities . . . . . . . . . . . . 4 61 3.1. Location . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3.1.1. An ISO 3166-1 numeric function . . . . . . . . . . . 4 63 3.1.2. An UNSD region function . . . . . . . . . . . . . . . 5 64 3.2. Relation . . . . . . . . . . . . . . . . . . . . . . . . 5 65 3.3. Combining Informational Communities . . . . . . . . . . . 6 66 4. Examples of Action Communities . . . . . . . . . . . . . . . 6 67 4.1. Selective NO_EXPORT . . . . . . . . . . . . . . . . . . . 6 68 4.1.1. Peer ASN Based Selective NO_EXPORT . . . . . . . . . 6 69 4.1.2. Location Based Selective NO_EXPORT . . . . . . . . . 7 70 4.2. Selective AS_PATH Prepending . . . . . . . . . . . . . . 7 71 4.2.1. Peer ASN Based Selective AS_PATH Prepending . . . . . 7 72 4.2.2. Location Based Selective AS_PATH Prepending . . . . . 8 73 4.3. Region-Specific LOCAL_PREFERENCE . . . . . . . . . . . . 8 74 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 76 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 77 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 78 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 79 8.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 9 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 82 1. Introduction 84 Large BGP Communities [I-D.ietf-idr-large-community] provide a 85 mechanism to signal opaque information between Autonomous Systems. 86 This document presents a set of examples on how Large BGP Communities 87 could be implemented by an operator to achieve various goals. This 88 document draws from experience in Operational Communities such as 89 NANOG [1] and NLNOG [2]. 91 The opaque nature of Large BGP Communities allows for rapid 92 deployment of new features or changes to the product. Operators are 93 encouraged to publicly publish an up to date version of their routing 94 policy in which they document what each Large BGP Community means. 96 2. The Generic Design Pattern 98 Large BGP Communities are composed of a 4-octet Global Administrator 99 field followed by two 4-octet Local Data fields. The design pattern 100 described in this document uses a "ASN:Function:Parameter"-approach 101 to fill the three fields. 103 In deployments of both BGP Communities [RFC1997] and Large BGP 104 Communities, two categories of Communities are recognised: 106 o Informational Communities 108 o Action Communities 110 For each context ideas are provided regarding the contents of each of 111 the three fields in Large BGP Communities. 113 Throughout the document a topology of four Autonomous Systems is used 114 to illustrate the usage of Communities in the following 115 configuration: 117 AS 65551 118 | 119 ^ 120 | 121 AS 64497 122 / \ 123 ^ \ 124 / ^ 125 AS 64498 \ 126 | | 127 `<->- AS 64499 129 AS 64497 obtains transit services from AS 65551. AS 64497 provides 130 transit services to both AS 64498 and AS 64499. AS 64498 and AS 131 64499 maintain a peering relation in which they only exchange their 132 customer routes. 134 2.1. Informational Communities 136 Informational Communites serve as markers regarding the origin of the 137 route announcement, the relation with the EBGP neighbor or for 138 instance the intended propagation audience. Informational 139 Communities also assist in network operations such as debugging. 141 The Global Administrator field is set to the ASN which is marking the 142 routes with the Informational Communities. As an example: on a route 143 which AS 64497 announces to AS 64498, AS 64497 might add the Large 144 BGP Community 64497:100:31 to signal to AS 64498 that the route was 145 learned in the Netherlands. 147 In general the intended audience of Informational Communities are 148 downstream networks, but any adjacent Autonomous System could benefit 149 from receiving these communities. 151 2.2. Action Communities 153 Action Communities are attached to routes to request non-default 154 behaviour in an adjacent Autonomous System. For instance, Action 155 Communities are used to change the route's propagation 156 characteristics, the route's LOCAL_PREF value or the amount of 157 AS_PATH prepends that should be added when exporting or importing a 158 route. 160 The Global Administrator field is set to the ASN which is expected to 161 perform a non-default action upon receiving the route. For instance, 162 if AS 64499 would want to request AS 64497 to lower the 163 LOCAL_PREFERENCE below the default, AS 64499 could tag the route with 164 64497:20:50. 166 In general the intended audience of Action Communities is an upstream 167 provider. 169 3. Examples of Informational Communities 171 3.1. Location 173 AS 64497 can inform its downstream networks about the geographical 174 entity where AS 64497 learned a route by marking the route with Large 175 BGP Communities following one or a combination of the following 176 schemes. 178 3.1.1. An ISO 3166-1 numeric function 180 AS 64497 could assign a value of 1 to the first Local Data field to 181 designate the function of the parameter in the second Local Data 182 field as ISO-3166-1 numeric country identifiers. 184 +---------------------+-------------------------------------------+ 185 | Large BGP Community | Meaning | 186 +---------------------+-------------------------------------------+ 187 | 64497:1:528 | Route learned in Netherlands | 188 | 64497:1:392 | Route learned in Japan | 189 | 64497:1:840 | Route learned in United States of America | 190 +---------------------+-------------------------------------------+ 192 Example documentation for AS 64497 using Informational Communties 193 describing the origin of routes using ISO 3166-1 numeric identifiers. 195 Table 1: Information: ISO 3166-1 197 3.1.2. An UNSD region function 199 AS 64497 could assign a value of 2 to the first Local Data field to 200 designate the function of the parameter in the second Local Data 201 field as an identifier for the macro geographical (continental) 202 regions, geographical sub-regions, or selected economic and other 203 groupings following a set of published identifiers by the United 204 Nations Statistics Division [3]. 206 +---------------------+-------------------------------+ 207 | Large BGP Community | Meaning | 208 +---------------------+-------------------------------+ 209 | 64497:2:2 | Route learned in Africa | 210 | 64497:2:9 | Route learned in Oceania | 211 | 64497:2:145 | Route learned in Western Asia | 212 | 64497:2:150 | Route learned in Europe | 213 +---------------------+-------------------------------+ 215 Example documentation for AS 64497 using Informational Communties 216 describing the origin of routes using numeric identifiers provided by 217 the UN Statistics Division. 219 Table 2: Information: Regions 221 3.2. Relation 223 AS 64497 could assign a value of 3 to the first Local Data field to 224 designate that the second Local Data field contains an identifier 225 showing the relation with the EBGP neighbor from whom the route was 226 received. 228 +---------------------+-----------------------------------------+ 229 | Large BGP Community | Meaning | 230 +---------------------+-----------------------------------------+ 231 | 64497:3:1 | Route learned from a customer | 232 | 64497:3:2 | Route learned from a peering partner | 233 | 64497:3:3 | Route learned from an upstream provider | 234 +---------------------+-----------------------------------------+ 236 Example documentation for AS 64497 using Informational Communties 237 describing the relation with the ASN from which the route was 238 received. 240 Table 3: Information: Relation 242 3.3. Combining Informational Communities 244 Multiple Informational Communities can be tagged on a route, for 245 example: a route learned in the Netherlands from a customer can 246 contain both 64497:1:528 and 64497:2:150 and 64497:3:1. 248 4. Examples of Action Communities 250 4.1. Selective NO_EXPORT 252 As part of the commercial agreement between AS 64497 and AS 64498, AS 253 64497 might offer AS 64498 certain BGP Traffic Engineering features 254 such as selectively not exporting routes learned from 64498 to 255 certain EBGP neighbors of AS 64497. 257 4.1.1. Peer ASN Based Selective NO_EXPORT 259 AS 64497 might assign function identifier 4 to allow preventing 260 propagation of routes to the ASN listed in the second Local Data 261 field. 263 +---------------------+---------------------------------+ 264 | Large BGP Community | Meaning | 265 +---------------------+---------------------------------+ 266 | 64497:4:2914 | Do not export route to AS 2914 | 267 | 64497:4:7018 | Do not export route to AS 3356 | 268 | 64497:4:65551 | Do not export route to AS 65551 | 269 +---------------------+---------------------------------+ 271 Example documentation for AS 64497 offering Action Communties to 272 limit propagation of routes based on the Peer ASN described in the 273 third field. 275 Table 4: Action: Peer ASN NO_EXPORT 277 4.1.2. Location Based Selective NO_EXPORT 279 AS 64497 might assign function identifier 5 to allow its customers to 280 request selectively not exporting routes on EBGP sessions within a 281 certain geographical area. This example follows the ISO 3166-1 282 numeric encoding. 284 +------------------+------------------------------------------------+ 285 | Large BGP | Meaning | 286 | Community | | 287 +------------------+------------------------------------------------+ 288 | 64497:5:528 | Do not export to EBGP neighbors in the | 289 | | Netherlands | 290 | 64497:5:392 | Do not export to EBGP neighbors in Japan | 291 | 64497:5:840 | Do not export to EBGP neighbors in United | 292 | | States of America | 293 +------------------+------------------------------------------------+ 295 Example documentation for AS 64497 offering Action Communties to 296 trigger NO_EXPORT on routes only when propagating the route to a 297 certain geographical region. 299 Table 5: Action: NO_EXPORT in Region 301 4.2. Selective AS_PATH Prepending 303 As part of the commercial agreement between AS 64497 and AS 64498, AS 304 64497 might offer AS 64498 certain BGP Traffic Engineering features 305 such as selectively prepending the AS_PATH with 64497's ASN to 306 certain EBGP neighbors of AS 64497. 308 4.2.1. Peer ASN Based Selective AS_PATH Prepending 310 AS 64497 might assign function identifier 6 to allow prepending the 311 AS_PATH on propagation of routes to the ASN listed in the second 312 Local Data field. 314 +---------------------+------------------------------------------+ 315 | Large BGP Community | Meaning | 316 +---------------------+------------------------------------------+ 317 | 64497:6:2914 | Prepend 64497 once on export to AS 2914 | 318 | 64497:6:7018 | Prepend 64497 once on export to AS 7018 | 319 | 64497:6:65551 | Prepend 64497 once on export to AS 65551 | 320 +---------------------+------------------------------------------+ 322 Example documentation for AS 64497 offering Action Communties to 323 trigger prepending of the AS_PATH only when propagating the route to 324 a certain Peer ASN. 326 Table 6: Action: Prepend to Peer ASN 328 4.2.2. Location Based Selective AS_PATH Prepending 330 AS 64497 might assign function identifier 7 to allow prepending of 331 the AS_PATH on propagation of routes to on any EBGP neighbor's 332 interconnection in the geographical entity listed in the second Local 333 Data field. This example follows the ISO 3166-1 numeric encoding. 335 +------------------+------------------------------------------------+ 336 | Large BGP | Meaning | 337 | Community | | 338 +------------------+------------------------------------------------+ 339 | 64497:7:528 | Prepend once to EBGP neighbors in the | 340 | | Netherlands | 341 | 64497:7:392 | Prepend once to EBGP neighbors in Japan | 342 | 64497:7:840 | Prepend once to EBGP neighbors in United | 343 | | States of America | 344 +------------------+------------------------------------------------+ 346 Example documentation for AS 64497 offering Action Communties to 347 trigger prepending of the AS_PATH only when propagating the route to 348 a certain geographical region. 350 Table 7: Action: Prepend in Region 352 4.3. Region-Specific LOCAL_PREFERENCE 354 To be filled in. 356 5. Security Considerations 358 Network operators should note the recommendations in Section 11 of 359 BGP Operations and Security [RFC7454]. 361 6. IANA Considerations 363 None. 365 7. Acknowledgements 367 Thanks to ... 369 8. References 371 8.1. Normative References 373 [I-D.ietf-idr-large-community] 374 Heitz, J., Snijders, J., Patel, K., Bagdonas, I., Simpson, 375 A., and N. Hilliard, "Large BGP Communities", draft-ietf- 376 idr-large-community-06 (work in progress), October 2016. 378 [RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities 379 Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996, 380 . 382 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 383 Requirement Levels", BCP 14, RFC 2119, 384 DOI 10.17487/RFC2119, March 1997, 385 . 387 [RFC7454] Durand, J., Pepelnjak, I., and G. Doering, "BGP Operations 388 and Security", BCP 194, RFC 7454, DOI 10.17487/RFC7454, 389 February 2015, . 391 8.2. URIs 393 [1] http://nanog.net 395 [2] http://nlnog.net 397 [3] http://unstats.un.org/unsd/methods/m49/m49regin.htm 399 Authors' Addresses 401 Job Snijders 402 NTT Communications 403 Theodorus Majofskistraat 100 404 Amsterdam 1065 SZ 405 NL 407 Email: job@ntt.net 408 Martijn Schmidt 409 i3D.net 410 Rivium 1e Straat 1 411 Capelle aan den IJssel 2909 LE 412 NL 414 Email: martijnschmidt@i3d.net