idnits 2.17.1 draft-ietf-opsawg-ipfix-bgp-community-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC8092], [RFC4360], [RFC7011], [RFC1997]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 6 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 22, 2018) is 2227 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-36) exists of draft-ietf-idr-bgp-extended-messages-24 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 opsawg Z. Li 3 Internet-Draft R. Gu 4 Intended status: Standards Track China Mobile 5 Expires: September 23, 2018 J. Dong 6 Huawei Technologies 7 March 22, 2018 9 Export BGP community information in IP Flow Information Export (IPFIX) 10 draft-ietf-opsawg-ipfix-bgp-community-06 12 Abstract 14 This draft introduces several information elements (IEs) to enable 15 IPFIX [RFC7011] to export the BGP community information, including 16 the information of BGP standard community [RFC1997], BGP extended 17 community [RFC4360], and BGP large community [RFC8092]. Network 18 traffic information can then be accumulated and analysed at the BGP 19 community granularity, which represents the traffic of different 20 kinds of customers, services, or geographical regions according to 21 the network operator's BGP community planning. Network traffic 22 information at the BGP community granularity is useful for network 23 traffic analysis and engineering. 25 To clarify, no new BGP community attribute is defined in this 26 document and this document has no purpose to replace BGP Monitoring 27 Protocol (BMP) defined in RFC7854. The IEs introduced in this 28 document are used by IPFIX together with other IEs to facilitate the 29 IPFIX collector analyzing the network traffic at the BGP community 30 granularity without running the heavy BGP protocol. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on September 23, 2018. 49 Copyright Notice 51 Copyright (c) 2018 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 3. BGP Community based Traffic Collection . . . . . . . . . . . 5 69 4. IEs for BGP Standard Community . . . . . . . . . . . . . . . 6 70 4.1. bgpCommunity . . . . . . . . . . . . . . . . . . . . . . 7 71 4.2. bgpSourceCommunityList . . . . . . . . . . . . . . . . . 7 72 4.3. bgpDestinationCommunityList . . . . . . . . . . . . . . . 8 73 5. IEs for BGP Extended Community . . . . . . . . . . . . . . . 8 74 5.1. bgpExtendedCommunity . . . . . . . . . . . . . . . . . . 8 75 5.2. bgpSourceExtendedCommunityList . . . . . . . . . . . . . 9 76 5.3. bgpDestinationExtendedCommunityList . . . . . . . . . . . 9 77 6. IEs for BGP Large Community . . . . . . . . . . . . . . . . . 10 78 6.1. bgpLargeCommunity . . . . . . . . . . . . . . . . . . . . 10 79 6.2. bgpSourceLargeCommunityList . . . . . . . . . . . . . . . 11 80 6.3. bgpDestinationLargeCommunityList . . . . . . . . . . . . 11 81 7. Operational Considerations . . . . . . . . . . . . . . . . . 12 82 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 83 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 84 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 85 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 86 11.1. Normative References . . . . . . . . . . . . . . . . . . 15 87 11.2. Informative References . . . . . . . . . . . . . . . . . 16 88 Appendix A. Encoding Example . . . . . . . . . . . . . . . . . . 17 89 A.1. Template Record . . . . . . . . . . . . . . . . . . . . . 18 90 A.2. Data Set . . . . . . . . . . . . . . . . . . . . . . . . 18 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 93 1. Introduction 95 IP Flow Information Export (IPFIX) [RFC7011] provides network 96 administrators with traffic flow information using the information 97 elements (IEs) defined in [IANA-IPFIX] registries. Based on the 98 traffic flow information, network administrators know the amount and 99 direction of the traffic in their network, then they can optimize 100 their network when needed. For example, they can shift some flows 101 from the congested links to the low utilized links through a SDN 102 controller or PCE [RFC4655]. 104 [IANA-IPFIX] has already defined the following IEs for traffic flow 105 information exporting in different granularities: sourceIPv4Address, 106 sourceIPv4Prefix, destinationIPv4Address, destinationIPv4Prefix, 107 bgpSourceAsNumber, bgpDestinationAsNumber, bgpNextHopIPv4Address, 108 etc. In some circumstances, however, especially when traffic 109 engineering and optimization are executed in the Tier 1 or Tier 2 110 operators' backbone networks, traffic flow information based on these 111 IEs may not be suitable. Flow information based on IP address or IP 112 prefix may provide much too fine granularity for a large network. On 113 the contrary, flow information based on AS number may be too coarse. 115 BGP community is a BGP path attribute defined in IDR (Inter Domain 116 Routing) working group. The already defined BGP community attribute 117 includes the standard community defined in [RFC1997], the extended 118 community defined in [RFC4360], and the large community defined in 119 [RFC8092]. BGP community attribute has a variety of use cases, one 120 common practice of which for the operators is to use BGP community 121 with planned specific values in their field networks to represent the 122 groups of customers, services, geographical and topological regions. 123 Please refer to [RFC4384], [RFC8195] and Section 3 of this document 124 for the detailed examples. To know the traffic generated by differnt 125 kinds of customers, from differnt geographical or topological 126 regions, by differnt kinds of customers in differnt regions, we need 127 the corresponding community information related to the traffic flow 128 exported by IPFIX. Netwok traffic statistic at the BGP community 129 granularity is useful not only for the traffic analyzing, but also 130 can then be used by other applications, such as the traffic 131 optimization applications located in IPFIX collector, SDN controller 132 or PCE. [Community-TE] also states analyzing network traffic 133 information at the BGP community granularity is prefered for inbound 134 traffic engineering. However, there is no IE defined for BGP 135 community attribute in [IANA-IPFIX] yet. 137 Flow information based on BGP community may be collected by a 138 mediator defined in [RFC6183]. Mediator is responsible for the 139 correlation between flow information and BGP community. However no 140 IEs are defined in [RFC6183] for exporting BGP community information 141 in IPFIX. Furthermore, to correlate the BGP community with the flow 142 information, mediator needs to learn BGP routes and perform lookup in 143 the BGP routing table to get the matching entry for a specific flow. 144 Neither BGP route learning nor routing table lookup is trivial for a 145 mediator. Mediator is mainly introduced to release the performance 146 requirement for the exporter [RFC5982]. In fact, to obtain the 147 information for BGP related IEs that have already been defined, such 148 as bgpSourceAsNumber, bgpDestinationAsNumber, and 149 bgpNextHopIPv4Address, etc, exporter has to hold the up-to-date BGP 150 routing table and perform lookup in the BGP routing table. The 151 exporter can obtain the BGP community information in the same 152 procedure, thus exporting BGP community information adds no more 153 requirement for exporter. It is RECOMMENDED that the BGP community 154 information be exported by the exporter directly using IPFIX. 156 Through running BGP [RFC4271] or BMP [RFC7854] and performing lookup 157 in the BGP routing table to get the matching entry for a specific 158 flow (we call it correlation), IPFIX collectors and other 159 applications, such as SDN controller or PCE, can figure up the 160 network traffic at the BGP community granularity. However, neither 161 running BGP or BMP protocol nor routing table lookup is trivial for 162 the IPFIX collectors and other applications. Moreover correlation 163 between IPFIX flow information and the BGP RIB on the exporter (such 164 as router) is more accurate, compared to the correlation on a 165 collector, since the BGP routing table may be updated when the IPFIX 166 collectors and other applications reveive the IPFIX flow information. 167 And as stated above, the exporter can obtain the BGP community 168 information in the same procedure when it obtains other BGP related 169 informaiton. So exporting the BGP community information directly by 170 the exporter to the collector is the efficient and accurate way. If 171 the IPFIX collectors and other applications only want to figure up 172 the network traffic at the BGP community granularity, they do not 173 need to run the heavy BGP or BMP protocol when the BGP community 174 information can be obtained by IPFIX. However, we have to clarify, 175 the BMP protocol has its own application scenario, the mechanisum 176 introduced in this document has no purpose to replace it. 178 This draft introduces new IEs to enable IPFIX [RFC7011] to export the 179 BGP community information, including BGP standard community defined 180 in [RFC1997], BGP extended community defined in [RFC4360], and BGP 181 large community defined in [RFC8092]. Flow information, including 182 packetDeltaCount, octetDeltaCount [RFC7012] etc, can then be 183 accumulated and analysed by the collector or other applications, such 184 as SDN controller or PCE [RFC4655], at the BGP community granularity, 185 which is useful for knowing the traffic generted by different kinds 186 of customers, from differnt geographical or topological regions 187 according to the operator's BGP community plan, and can then be used 188 by the traffic engineering or traffic optimization applications, 189 especially in the backbone network. To clarify, no new BGP community 190 attribute is defined in this document, IDR (Inter Domain Routing) 191 working group is the right place to define new community attributes 192 for the BGP protocol. 194 The IEs introduced in this document are applicable for both IPv4 and 195 IPv6 traffic. Both exporter and mediator can use these IEs to export 196 BGP community information in IPFIX. 198 Note that this document does not update the IPFIX specification 199 [RFC7011] and the Information Model [RFC7012] because IANA's IPFIX 200 registry [IANA-IPFIX] is the ultimate Information Element reference, 201 per Section 1 of [RFC7012]. 203 Please refer Appendix A for the encoding example and Section 3 for a 204 detailed use case. 206 2. Terminology 208 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 209 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 210 document are to be interpreted as described in [RFC2119]. 212 3. BGP Community based Traffic Collection 214 [RFC4384] introduces the mechanism of using BGP standard communities 215 and extended communities to collect the geographical and topological 216 related information in BGP routing system. [RFC8195] gives some 217 examples about the application of BGP large communities to represent 218 the geographical regions. Since the network traffic at the BGP 219 community granularity represents the traffic generted by different 220 kinds of customers, from differnt geographical regions according to 221 the network operator's BGP community plan, it is useful for the 222 network operators to analyze and optimize the network traffic among 223 different customers and regions. This section gives a use case in 224 which the network operator uses the BGP community based traffic 225 information to adjust the network paths for different traffic flows. 227 Considering the following scenario, AS C provides transit connection 228 between AS A and B. By tagging with different BGP communities, the 229 routes of AS A and B are categorized into several groups respectively 230 with the operator's plan. For example community A:X and A:Y are used 231 for the routes originated from different geographical regions in AS 232 A, and community B:M and B:N are used for the routes representing the 233 different kinds of customers in AS B, such as B:M is for the mobile 234 customers and B:N is for the fixed line customers. By default, all 235 traffic originated from AS A and destinated to AS B (we call it 236 traffic A-B) goes through path C1-C2-C3 (call it Path-1) in AS C. 238 When the link between C1 and C2 is congested, we cannot simply steer 239 all the traffic A-B from Path-1 to Path C1-C4-C3 (call it Path-2), 240 becuse it will cause the congestion in Path-2. 242 +----------+ 243 | PCE/SDN | 244 +-------|Controller|-------+ 245 | +----------+ | 246 | | 247 | AS C | 248 | | +----------+ | | 249 | | +---|Router C2 |---+ | | 250 | | | +----------+ | | | 251 AS A | | |100 50| | | AS B 252 +--------+ | +---------+ +---------+ | +--------+ 253 |Router A|--|--|Router C1| |Router C3|--|--|Router B| 254 +--------+ | +---------+ +---------+ | +--------+ 255 Community: | |100 100| | Community: 256 A:X | | +----------+ | | B:M 257 A:Y | +---|Router C4 |---+ | B:N 258 +----------+ 260 Figure 1: BGP Community based Traffic Collection 262 If the PCE/SDN controller in AS C can obtain the network traffic 263 information at the BGP community granularity, it can steer some 264 traffic related to some BGP communities (when we consider only the 265 source or destination of the traffic), or some BGP community pairs 266 (when we consider both the source and the destination of the traffic) 267 from Path-1 to Path-2 according to the utilization of different 268 paths. For instance, steer the traffic generated by community A:X 269 from Path-1 to Path-2 by deploying route policy at Router C1, or 270 steer the traffic from community A:Y to community B:M from Path-1 to 271 Path-2. Using the IEs defined in this document, IPFIX can export the 272 BGP community information related to a specific traffic flow togecher 273 with other flow information. The traffic information can then be 274 accumulated at the BGP community granularity and used by the PCE/SDN 275 controller to steer the appropriate traffic from Path-1 to Path-2. 277 4. IEs for BGP Standard Community 279 [RFC1997] defines the BGP Communities attribute, called BGP Standard 280 Community in this document, which describes a group of routes sharing 281 some common properties. BGP Standard Communities are treated as 32 282 bit values as stated in[RFC1997]. 284 In order to export BGP standard community information along with 285 other flow information defined by IPFIX, three new IEs are 286 introduced. One is bgpCommunity, which is used to identify that the 287 value in this IE is a BGP standard community. The other two are 288 bgpSourceCommunityList and bgpDestinationCommunityList, which are 289 both basicList [RFC6313] of bgpCommunity, and are used to export BGP 290 standard community information corresponding to a specific flow's 291 source IP and destination IP respectively. 293 The detailed information of the three new IEs are shown in the 294 following sections. 296 4.1. bgpCommunity 298 ---------------------------------------------------------------------- 299 | ElementID | to be assigned by IANA | 300 |--------------------------------------------------------------------| 301 | Name | bgpCommunity | 302 |--------------------------------------------------------------------| 303 | Data Type | unsigned32 | 304 |--------------------------------------------------------------------| 305 | Data Type Semantics | identifier | 306 |--------------------------------------------------------------------| 307 | Description | BGP community as defined in [RFC1997] | 308 |--------------------------------------------------------------------| 309 | Units | none | 310 |--------------------------------------------------------------------| 312 Figure 2: bgpCommunity 314 4.2. bgpSourceCommunityList 316 ---------------------------------------------------------------------- 317 | ElementID | to be assigned by IANA | 318 |--------------------------------------------------------------------| 319 | Name | bgpSourceCommunityList | 320 |--------------------------------------------------------------------| 321 | Data Type | basicList, as specified in [RFC6313] | 322 |--------------------------------------------------------------------| 323 | Data Type Semantics | list | 324 |--------------------------------------------------------------------| 325 | Description | zero or more BGP communities corresponding | 326 | | with source IP address of a specific flow | 327 |--------------------------------------------------------------------| 328 | Units | none | 329 |--------------------------------------------------------------------| 331 Figure 3: bgpSourceCommunityList 333 4.3. bgpDestinationCommunityList 335 --------------------------------------------------------------------- 336 | ElementID | to be assigned by IANA | 337 |--------------------------------------------------------------------| 338 | Name | bgpDestinationCommunityList | 339 |--------------------------------------------------------------------| 340 | Data Type | basicList, as specified in [RFC6313] | 341 |--------------------------------------------------------------------| 342 | Data Type Semantics | list | 343 |--------------------------------------------------------------------| 344 | Description | zero or more BGP communities corresponding | 345 | |with destination IP address of a specific flow| 346 |--------------------------------------------------------------------| 347 | Units | none | 348 |--------------------------------------------------------------------| 350 Figure 4: bgpDestinationCommunityList 352 5. IEs for BGP Extended Community 354 [RFC4360] defines the BGP Extended Communities attribute, which 355 provides a mechanism for labeling the information carried in BGP. 356 Each Extended Community is encoded as an 8-octet quantity with the 357 format defined in [RFC4360]. 359 In order to export BGP Extended Community information together with 360 other flow information by IPFIX, three new IEs are introduced. The 361 first one is bgpExtendedCommunity, which is used to identify that the 362 value in this IE is a BGP Extended Community. The other two are 363 bgpSourceExtendedCommunityList and 364 bgpDestinationExtendedCommunityList, which are both basicList 365 [RFC6313] of bgpExtendedCommunity, and are used to export the BGP 366 Extended Community information corresponding to a specific flow's 367 source IP and destination IP respectively. 369 The detailed information of the three new IEs are shown in the 370 following sections. 372 5.1. bgpExtendedCommunity 373 ---------------------------------------------------------------------- 374 | ElementID | to be assigned by IANA | 375 |--------------------------------------------------------------------| 376 | Name | bgpExtendedCommunity | 377 |--------------------------------------------------------------------| 378 | Data Type | octetArray | 379 |--------------------------------------------------------------------| 380 | Data Type Semantics | default | 381 |--------------------------------------------------------------------| 382 | |BGP Extended Community as defined in [RFC4360]| 383 | Description |The size of this Information Element is 8 | 384 | |octets. | 385 |--------------------------------------------------------------------| 386 | Units | none | 387 |--------------------------------------------------------------------| 389 Figure 5: bgpExtendedCommunity 391 5.2. bgpSourceExtendedCommunityList 393 ---------------------------------------------------------------------- 394 | ElementID | to be assigned by IANA | 395 |--------------------------------------------------------------------| 396 | Name | bgpSourceExtendedCommunityList | 397 |--------------------------------------------------------------------| 398 | Data Type | basicList, as specified in [RFC6313] | 399 |--------------------------------------------------------------------| 400 | Data Type Semantics | list | 401 |--------------------------------------------------------------------| 402 | | zero or more BGP Extended Communities | 403 | Description | corresponding with source IP address | 404 | | of a specific flow | 405 |--------------------------------------------------------------------| 406 | Units | none | 407 |--------------------------------------------------------------------| 409 Figure 6: bgpSourceExtendedCommunityList 411 5.3. bgpDestinationExtendedCommunityList 412 ---------------------------------------------------------------------- 413 | ElementID | to be assigned by IANA | 414 |--------------------------------------------------------------------| 415 | Name | bgpDestinationExtendedCommunityList | 416 |--------------------------------------------------------------------| 417 | Data Type | basicList, as specified in [RFC6313] | 418 |--------------------------------------------------------------------| 419 | Data Type Semantics | list | 420 |--------------------------------------------------------------------| 421 | | zero or more BGP Extended communities | 422 | Description | corresponding with destination IP address | 423 | | of a specific flow | 424 |--------------------------------------------------------------------| 425 | Units | none | 426 |--------------------------------------------------------------------| 428 Figure 7: bgpDestinationExtendedCommunityList 430 6. IEs for BGP Large Community 432 [RFC8092] defines the BGP Large Communities attribute, which is 433 suitable for use with all Autonomous System Numbers (ASNs) including 434 four-octet ASNs. Each BGP Large Community is encoded as a 12-octet 435 quantity with the format defined in [RFC8092]. 437 In order to export BGP Large Community information together with 438 other flow information by IPFIX, three new IEs are introduced. The 439 first one is bgpLargeCommunity, which is used to identify that the 440 value in this IE is a BGP Large Community. The other two are 441 bgpSourceLargeCommunityList and bgpDestinationLargeCommunityList, 442 which are both basicList [RFC6313] of bgpLargeCommunity, and are used 443 to export the BGP Large Community information corresponding to a 444 specific flow's source IP and destination IP respectively. 446 The detailed information of the three new IEs are shown in the 447 following sections. 449 6.1. bgpLargeCommunity 450 ---------------------------------------------------------------------- 451 | ElementID | to be assigned by IANA | 452 |--------------------------------------------------------------------| 453 | Name | bgpLargeCommunity | 454 |--------------------------------------------------------------------| 455 | Data Type | octetArray | 456 |--------------------------------------------------------------------| 457 | Data Type Semantics | default | 458 |--------------------------------------------------------------------| 459 | | BGP Large Community as defined in [RFC8092] | 460 | Description | The size of this Information Element is 12 | 461 | | octets. | 462 |--------------------------------------------------------------------| 463 | Units | none | 464 |--------------------------------------------------------------------- 466 Figure 8: bgpLargeCommunity 468 6.2. bgpSourceLargeCommunityList 470 ---------------------------------------------------------------------- 471 | ElementID | to be assigned by IANA | 472 |--------------------------------------------------------------------| 473 | Name | bgpSourceLargeCommunityList | 474 |--------------------------------------------------------------------| 475 | Data Type | basicList, as specified in [RFC6313] | 476 |--------------------------------------------------------------------| 477 | Data Type Semantics | list | 478 |--------------------------------------------------------------------| 479 | | zero or more BGP Large Communities | 480 | Description | corresponding with source IP address | 481 | | of a specific flow | 482 |--------------------------------------------------------------------| 483 | Units | none | 484 |--------------------------------------------------------------------| 486 Figure 9: bgpSourceLargeCommunityList 488 6.3. bgpDestinationLargeCommunityList 489 ---------------------------------------------------------------------- 490 | ElementID | to be assigned by IANA | 491 |--------------------------------------------------------------------| 492 | Name | bgpDestinationLargeCommunityList | 493 |--------------------------------------------------------------------| 494 | Data Type | basicList, as specified in [RFC6313] | 495 |--------------------------------------------------------------------| 496 | Data Type Semantics | list | 497 |--------------------------------------------------------------------| 498 | Description | zero or more BGP Large communities | 499 | | corresponding with destination IP address | 500 | | of a specific flow | 501 |--------------------------------------------------------------------| 502 | Units | none | 503 |--------------------------------------------------------------------| 505 Figure 10: bgpDestinationLargeCommunityList 507 7. Operational Considerations 509 The maximum length of an IPFIX message is 65535 bytes as per 510 [RFC7011] , and the maximum length of a normal BGP message is 4096 511 bytes as per [RFC4271]. Since BGP communities, including standard, 512 extended, and large communities , are BGP path attributes carried in 513 BGP Update messages, the total length of these attributes can not 514 exceed the length of a BGP message, i.e. 4096 bytes. So one IPFIX 515 message with maximum length of 65535 bytes has enough space to fit 516 all the communities related to a specific flow, both the source IP 517 and the destination IP related. 519 [I-D.ietf-idr-bgp-extended-messages] extends the maximum size of a 520 BGP Update message to 65535 bytes. Then theoretically the BGP 521 community information related to a specific flow may exceed the 522 length one IPFIX message. However, according to the information 523 about the networks in the field, the number of BGP communities in one 524 BGP route is usually no more than 10. Nevertheless, BGP speakers 525 that support the extended message SHOULD be careful to export the BGP 526 communities in the IPFIX message properly, such as only convey as 527 many communities as possible in the IPFIX message. The collector 528 which receives an IPFIX message with maximum length and BGP 529 communities contained in its data set SHOULD be aware that the BGP 530 communities may be truncated due to limited message space. In this 531 case, it is RECOMMENDED to configure export policy of BGP communities 532 on the exporter to limit the BGP communities to be exported, so as to 533 only export some specific communities,or not to export some specific 534 communities. 536 If needed, we may consider to extend the message length of IPFIX 537 [RFC7011] from 16 bits to 32 bits to solve this problem completely. 538 The detailed mechanism is out of the scope of this document. 540 To align with the size of BGP extended community and large community, 541 the size of IE bgpExtendedCommunity and bgpLargeCommunity is 8 octets 542 and 12 octets respectively. In the event that the 543 bgpExtendedCommunity or bgpLargeCommunity Elements are not of their 544 expected sizes (8 and 12 octets, respectively), the IPFIX collector 545 SHOULD ignore them. This is intended to protect implementations 546 using BGP logic from calling their parsing routines with invalid 547 lengths. 549 For the proper processing of the exporter, when it receives the 550 template requesting to report the BGP community information (refer 551 Appendix A for an example), the exporter SHOULD obtain the 552 corresponding BGP community information through BGP lookup using the 553 corresponding source or destination IP of the specific traffic flow. 554 When exporting the IPFIX information to the collector, the exporter 555 SHOULD include the corresponding BGP communities in the IPFIX 556 message. 558 8. Security Considerations 560 This document only defines three new IEs for IPFIX. This document 561 itself does not directly introduce security issues. The same 562 security considerations as for the IPFIX Protocol Specification 563 [RFC7011] and Information Model [RFC7012] apply. 565 As the BGP community information is deducible by other means, there 566 are no increased privacy concerns, neither. 568 9. IANA Considerations 570 This draft specifies the following IPFIX IEs to export BGP community 571 information along with other flow information. 573 The Element IDs for these IEs are solicited to be assigned by IANA. 574 The following table is for IANA's reference to put in each field in 575 the registry. 577 ---------------------------------------------------------------------- 578 |ElementID| Name | Data Type|Data Type Semantics| 579 |--------------------------------------------------------------------| 580 | TBA1 | bgpCommunity |unsigned32| identifier | 581 |--------------------------------------------------------------------| 582 | TBA2 | bgpSourceCommunityList | basicList| list | 583 |--------------------------------------------------------------------| 584 | TBA3 |bgpDestinationCommunityList| basicList| list | 585 |--------------------------------------------------------------------| 586 | TBA4 | bgpExtendedCommunity |octetArray| default | 587 |--------------------------------------------------------------------| 588 | TBA5 | bgpSourceExtended | | | 589 | | CommunityList | basicList| list | 590 |--------------------------------------------------------------------| 591 | TBA6 | bgpDestinationExtended | | | 592 | | CommunityList | basicList| list | 593 |--------------------------------------------------------------------| 594 | TBA7 | bgpLargeCommunity |octetArray| default | 595 |--------------------------------------------------------------------| 596 | TBA8 |bgpSourceLargeCommunityList| basicList| list | 597 |--------------------------------------------------------------------| 598 | TBA9 | bgpDestinationLarge | | | 599 | | CommunityList | basicList| list | 600 |--------------------------------------------------------------------| 602 ---------------------------------------------------------------------- 603 |ElementID| Description | Units | 604 |--------------------------------------------------------------------| 605 | TBA1 | BGP community as defined in [RFC1997] | | 606 |--------------------------------------------------------------------| 607 | TBA2 | zero or more BGP communities corresponding | | 608 | | with source IP address of a specific flow | | 609 |--------------------------------------------------------------------| 610 | TBA3 | zero or more BGP communities corresponding | | 611 | |with destination IP address of a specific flow| | 612 |--------------------------------------------------------------------| 613 | TBA4 |BGP Extended Community as defined in [RFC4360]| | 614 | |The size of this IE is 8 octets | | 615 |--------------------------------------------------------------------| 616 | | zero or more BGP Extended Communities | | 617 | TBA5 | corresponding with source IP address of | | 618 | | a specific flow | | 619 |--------------------------------------------------------------------| 620 | | zero or more BGP Extended communities | | 621 | TBA6 | corresponding with destination IP address | | 622 | | of a specific flow | | 623 |--------------------------------------------------------------------| 624 | TBA7 | BGP Large Community as defined in [RFC8092] | | 625 | | The size of this IE is 12 octets. | | 626 |--------------------------------------------------------------------| 627 | | zero or more BGP Large Communities | | 628 | TBA8 | corresponding with source IP address | | 629 | | of a specific flow | | 630 |--------------------------------------------------------------------| 631 | | zero or more BGP Large communities | | 632 | TBA9 | corresponding with destination IP address | | 633 | | of a specific flow | | 634 |--------------------------------------------------------------------| 636 ---------------------------------------------------------------------- 637 |ElementID| Range | References | Requester | Revision | date | 638 |--------------------------------------------------------------------| 639 | TBA1 | | RFC1997 |this draft | 0 | | 640 |--------------------------------------------------------------------| 641 | TBA2 | |RFC6313,RFC1997|this draft | 0 | | 642 |--------------------------------------------------------------------| 643 | TBA3 | |RFC6313,RFC1997|this draft | 0 | | 644 |--------------------------------------------------------------------| 645 | TBA4 | | RFC4360 |this draft | 0 | | 646 |--------------------------------------------------------------------| 647 | TBA5 | |RFC6313,RFC4360|this draft | 0 | | 648 |--------------------------------------------------------------------| 649 | TBA6 | |RFC6313,RFC4360|this draft | 0 | | 650 |--------------------------------------------------------------------| 651 | TBA7 | | RFC8092 |this draft | 0 | | 652 |--------------------------------------------------------------------| 653 | TBA8 | |RFC6313,RFC8092|this draft | 0 | | 654 |--------------------------------------------------------------------| 655 | TBA9 | |RFC6313,RFC8092|this draft | 0 | | 656 |--------------------------------------------------------------------| 658 Figure 11: IANA Considerations 660 10. Acknowledgements 662 The authors would like to thank Benoit Claise and Paul Aitken for 663 their comments and suggestions to promote this document. 664 Appreciations are given to Tianran Zhou, Warren Kumari, Jeffrey Haas, 665 Ignas Bagdonas, Stewart Bryant, Paolo Lucente, Job Snijders, Jared 666 Mauch, Rudiger Volk, etc, for their discussion, comments and 667 suggestions in the face to face meetings and in the mail list. 669 11. References 671 11.1. Normative References 673 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 674 Requirement Levels", BCP 14, RFC 2119, 675 DOI 10.17487/RFC2119, March 1997, 676 . 678 [RFC6313] Claise, B., Dhandapani, G., Aitken, P., and S. Yates, 679 "Export of Structured Data in IP Flow Information Export 680 (IPFIX)", RFC 6313, DOI 10.17487/RFC6313, July 2011, 681 . 683 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 684 "Specification of the IP Flow Information Export (IPFIX) 685 Protocol for the Exchange of Flow Information", STD 77, 686 RFC 7011, DOI 10.17487/RFC7011, September 2013, 687 . 689 11.2. Informative References 691 [Community-TE] 692 Shao, W., Devienne, F., Iannone, L., and JL. Rougier, "On 693 the use of BGP communities for fine-grained inbound 694 traffic engineering", Computer Science 27392(1):476-487, 695 November 2015. 697 [I-D.ietf-idr-bgp-extended-messages] 698 Bush, R., Patel, K., and D. Ward, "Extended Message 699 support for BGP", draft-ietf-idr-bgp-extended-messages-24 700 (work in progress), November 2017. 702 [IANA-IPFIX] 703 "IP Flow Information Export (IPFIX) Entities", 704 . 706 [RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities 707 Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996, 708 . 710 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 711 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 712 DOI 10.17487/RFC4271, January 2006, 713 . 715 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 716 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 717 February 2006, . 719 [RFC4384] Meyer, D., "BGP Communities for Data Collection", BCP 114, 720 RFC 4384, DOI 10.17487/RFC4384, February 2006, 721 . 723 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 724 Element (PCE)-Based Architecture", RFC 4655, 725 DOI 10.17487/RFC4655, August 2006, 726 . 728 [RFC5982] Kobayashi, A., Ed. and B. Claise, Ed., "IP Flow 729 Information Export (IPFIX) Mediation: Problem Statement", 730 RFC 5982, DOI 10.17487/RFC5982, August 2010, 731 . 733 [RFC6183] Kobayashi, A., Claise, B., Muenz, G., and K. Ishibashi, 734 "IP Flow Information Export (IPFIX) Mediation: Framework", 735 RFC 6183, DOI 10.17487/RFC6183, April 2011, 736 . 738 [RFC7012] Claise, B., Ed. and B. Trammell, Ed., "Information Model 739 for IP Flow Information Export (IPFIX)", RFC 7012, 740 DOI 10.17487/RFC7012, September 2013, 741 . 743 [RFC7854] Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP 744 Monitoring Protocol (BMP)", RFC 7854, 745 DOI 10.17487/RFC7854, June 2016, 746 . 748 [RFC8092] Heitz, J., Ed., Snijders, J., Ed., Patel, K., Bagdonas, 749 I., and N. Hilliard, "BGP Large Communities Attribute", 750 RFC 8092, DOI 10.17487/RFC8092, February 2017, 751 . 753 [RFC8195] Snijders, J., Heasley, J., and M. Schmidt, "Use of BGP 754 Large Communities", RFC 8195, DOI 10.17487/RFC8195, June 755 2017, . 757 Appendix A. Encoding Example 759 In this section, we give an example to show the encoding format for 760 the new introduced IEs. 762 Flow information including BGP communities is shown in the below 763 table. Suppose we want all the fields to be reported by IPFIX. 765 ----------------------------------------------------------------------- 766 |Source ip|Destination ip |Source BGP community| Destination BGP | 767 | | | | community | 768 ----------------------------------------------------------------------- 769 | 1.1.1.1 | 2.2.2.2 |1:1001,1:1002,8:1001| 2:1002,8:1001 | 770 ----------------------------------------------------------------------- 771 | 3.3.3.3 | 4.4.4.4 |3:1001,3:1002,8:1001| 4:1001,8:1001 | 772 ----------------------------------------------------------------------- 774 Figure 12: Flow information including BGP communities 776 A.1. Template Record 778 0 1 2 3 779 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 781 | SET ID = 2 | Length = 24 | 782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 783 | Template ID = 256 | Field Count = 4 | 784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 785 |0| SourceIPv4Address = 8 | Field length = 4 | 786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 787 |0| DestinationIPv4Address = 12 | Field length = 4 | 788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 789 |0| bgpSourceCommunityList = 459| Field length = 0xFFFF | 790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 791 |0| bgpDestinationCommunityList | Field length = 0xFFFF | 792 | | = 460 | | 793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 795 Figure 13: Template Record Encoding Format 797 In this example, the Template ID is 256, which will be used in the 798 data record. The field length for bgpSourceCommunityList and 799 bgpDestinationCommunityList is 0xFFFF, which means the length of this 800 IE is variable, the actual length of this IE is indicated by the list 801 length field in the basic list format as per [RFC6313]. 803 A.2. Data Set 805 The data set is represented as follows: 807 0 1 2 3 808 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 810 | SET ID = 256 | Length = 92 | 811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 812 | SourceIPv4Address = 1.1.1.1 | 813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 814 | DestinationIPv4Address = 2.2.2.2 | 815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 816 | 255 | List length = 17 |semantic=allof | 817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 818 | bgpCommunity = 458 | Field Len = 4 | 819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 820 | BGP Source Community Value 1 = 1:1001 | 821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 822 | BGP Source Community Value 2 = 1:1002 | 823 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 824 | BGP Source Community Value 3 = 8:1001 | 825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 826 | 255 | List length = 13 |semantic =allof| 827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 828 | bgpCommunity = 458 | Field Len = 4 | 829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 830 | BGP Destination Community Value 1 = 2:1002 | 831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 832 | BGP Destination Community Value 2 = 8:1001 | 833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 834 | SourceIPv4Address = 3.3.3.3 | 835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 836 | DestinationIPv4Address = 4.4.4.4 | 837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 838 | 255 | List length = 17 |semantic =allof| 839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 840 | bgpCommunity = 458 | Field Len = 4 | 841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 842 | BGP Source Community Value 1 = 3:1001 | 843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 844 | BGP Source Community Value 2 = 3:1002 | 845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 846 | BGP Source Community Value 3 = 8:1001 | 847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 848 | 255 | List length = 13 |semantic =allof| 849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 850 | bgpCommunity = 458 | Field Len = 4 | 851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 852 | BGP Destination Community Value 1 = 4:1001 | 853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 854 | BGP Destination Community Value 2 = 8:1001 | 855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 857 Figure 14: Data Set Encoding Format 859 Authors' Addresses 861 Zhenqiang Li 862 China Mobile 863 32 Xuanwumen West Ave, Xicheng District 864 Beijing 100053 865 China 867 Email: li_zhenqiang@hotmail.com 869 Rong Gu 870 China Mobile 871 32 Xuanwumen West Ave, Xicheng District 872 Beijing 100053 873 China 875 Email: gurong_cmcc@outlook.com 877 Jie Dong 878 Huawei Technologies 879 Huawei Campus, No. 156 Beiqing Rd. 880 Beijing 100095 881 China 883 Email: jie.dong@huawei.com