idnits 2.17.1 draft-ietf-opsawg-ipfix-bgp-community-09.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 (September 25, 2018) is 2011 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-26 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: March 29, 2019 J. Dong 6 Huawei Technologies 7 September 25, 2018 9 Export BGP community information in IP Flow Information Export (IPFIX) 10 draft-ietf-opsawg-ipfix-bgp-community-09 12 Abstract 14 By introducing new Information Elements (IEs), this draft extends the 15 existing BGP related IEs to enable IPFIX [RFC7011] to export the BGP 16 community information, including the information of BGP standard 17 community [RFC1997], BGP extended community [RFC4360], and BGP large 18 community [RFC8092]. Network traffic information can then be 19 accumulated and analysed at the BGP community granularity, which 20 represents the traffic of different kinds of customers, services, or 21 geographical regions according to the network operator's BGP 22 community planning. Network traffic information at the BGP community 23 granularity is useful for network 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. When needed, the 31 IPFIX Mediator or Collector can use the IEs introduced in this 32 document to report the BGP community related traffic flow information 33 it gets either from Exporters or through local correlation to other 34 IPFIX devices. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at https://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on March 29, 2019. 53 Copyright Notice 55 Copyright (c) 2018 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (https://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 71 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 3. BGP Community based Traffic Collection . . . . . . . . . . . 5 73 4. IEs for BGP Standard Community . . . . . . . . . . . . . . . 7 74 5. IEs for BGP Extended Community . . . . . . . . . . . . . . . 7 75 6. IEs for BGP Large Community . . . . . . . . . . . . . . . . . 7 76 7. Operational Considerations . . . . . . . . . . . . . . . . . 8 77 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 78 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 79 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 80 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 81 11.1. Normative References . . . . . . . . . . . . . . . . . . 11 82 11.2. Informative References . . . . . . . . . . . . . . . . . 12 83 Appendix A. Encoding Example . . . . . . . . . . . . . . . . . . 13 84 A.1. Template Record . . . . . . . . . . . . . . . . . . . . . 13 85 A.2. Data Set . . . . . . . . . . . . . . . . . . . . . . . . 14 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 88 1. Introduction 90 IP Flow Information Export (IPFIX) [RFC7011] provides network 91 administrators with traffic flow information using the Information 92 Elements (IEs) defined in [IANA-IPFIX] registries. Based on the 93 traffic flow information, network administrators know the amount and 94 direction of the traffic in their network, then they can optimize 95 their network when needed. For example, they can shift some flows 96 from the congested links to the low utilized links through a SDN 97 controller or PCE [RFC4655]. 99 [IANA-IPFIX] has already defined the following IEs for traffic flow 100 information exporting in different granularities: sourceIPv4Address, 101 sourceIPv4Prefix, destinationIPv4Address, destinationIPv4Prefix, 102 bgpSourceAsNumber, bgpDestinationAsNumber, bgpNextHopIPv4Address, 103 etc. In some circumstances, however, especially when traffic 104 engineering and optimization are executed in the Tier 1 or Tier 2 105 operators' backbone networks, traffic flow information based on these 106 IEs may not be suitable. Flow information based on IP address or IP 107 prefix may provide much too fine granularity for a large network. On 108 the contrary, flow information based on AS number may be too coarse. 110 BGP community is a BGP path attribute defined in IDR (Inter Domain 111 Routing) working group. The already defined BGP community attribute 112 includes the standard community defined in [RFC1997], the extended 113 community defined in [RFC4360], and the large community defined in 114 [RFC8092]. BGP community attribute has a variety of use cases, one 115 practice of which is to use BGP community with planned specific 116 values to represent the groups of customers, services, geographical 117 and topological regions, which is used by a lot of operators in their 118 field networks. Please refer to [RFC4384], [RFC8195] and Section 3 119 of this document for the detailed examples. To know the traffic 120 generated by different kinds of customers, from different 121 geographical or topological regions, by different kinds of customers 122 in different regions, we need the corresponding community information 123 related to the traffic flow exported by IPFIX. Network traffic 124 statistics at the BGP community granularity is useful not only for 125 the traffic analyzing, but also can then be used by other 126 applications, such as the traffic optimization applications located 127 in IPFIX Collector, SDN controller or PCE. [Community-TE] also 128 states analyzing network traffic information at the BGP community 129 granularity is prefered for inbound traffic engineering. However, 130 there is no IE defined for BGP community attribute in [IANA-IPFIX] 131 yet. 133 Flow information based on BGP community may be collected by an IPFIX 134 Mediator defined in [RFC6183]. IPFIX Mediator is responsible for the 135 correlation between flow information and BGP community. However no 136 IEs are defined in [RFC6183] for exporting BGP community information 137 in IPFIX. Furthermore, to correlate the BGP community with the flow 138 information, the IPFIX Mediator needs to learn BGP routes and perform 139 lookup in the BGP routing table to get the matching entry for a 140 specific flow. Neither BGP route learning nor routing table lookup 141 is trivial for an IPFIX Mediator. The IPFIX Mediator is mainly 142 introduced to release the performance requirement for the Exporter 143 [RFC5982]. In fact, to obtain the information for the already 144 defined BGP related IEs, such as bgpSourceAsNumber, 145 bgpDestinationAsNumber, and bgpNextHopIPv4Address, etc, the Exporter 146 has to hold the up-to-date BGP routing table and perform lookup in 147 the BGP routing table. The Exporter can obtain the BGP community 148 information in the same procedure, thus the additional load added by 149 exporting BGP community information is minimal if the Exporter is 150 already exporting the existing BGP related IEs. It is RECOMMENDED 151 that the BGP community information be exported by the Exporter 152 directly using IPFIX. 154 Through running BGP [RFC4271] or BMP [RFC7854] and performing lookup 155 in the BGP routing table to get the matching entry for a specific 156 flow (we call it correlation), IPFIX Collectors and other 157 applications, such as SDN controller or PCE, can determine the 158 network traffic at the BGP community granularity. However, neither 159 running BGP or BMP protocol nor routing table lookup is trivial for 160 the IPFIX Collectors and other applications. Moreover correlation 161 between IPFIX flow information and the BGP RIB on the Exporter (such 162 as router) is more accurate, compared to the correlation on a 163 Collector, since the BGP routing table may be updated when the IPFIX 164 Collectors and other applications reveive the IPFIX flow information. 165 And as stated above, the Exporter can obtain the BGP community 166 information in the same procedure when it obtains other BGP related 167 informaiton. So exporting the BGP community information directly by 168 the Exporter to the Collector is the efficient and accurate way. If 169 the IPFIX Collectors and other applications only want to determine 170 the network traffic at the BGP community granularity, they do not 171 need to run the heavy BGP or BMP protocol when the BGP community 172 information can be obtained by IPFIX. However, we have to clarify, 173 the BMP protocol has its own application scenario, the mechanism 174 introduced in this document has no purpose to replace it. 176 By introducing new IEs, this draft extends the existing BGP related 177 IEs to enable IPFIX [RFC7011] to export the BGP community 178 information, including BGP standard community defined in [RFC1997], 179 BGP extended community defined in [RFC4360], and BGP large community 180 defined in [RFC8092]. Flow information, including packetDeltaCount, 181 octetDeltaCount [RFC7012] etc, can then be accumulated and analysed 182 by the Collector or other applications, such as SDN controller or PCE 183 [RFC4655], at the BGP community granularity, which is useful for 184 knowing the traffic generated by different kinds of customers, from 185 different geographical or topological regions according to the 186 operator's BGP community plan, and can then be used by the traffic 187 engineering or traffic optimization applications, especially in the 188 backbone network. 190 The IEs introduced in this document are applicable for both IPv4 and 191 IPv6 traffic. Both the Exporter and the IPFIX Mediator can use these 192 IEs to export BGP community information in IPFIX. When needed, the 193 IPFIX Mediator or Collector can use these IEs to report the BGP 194 community related traffic flow information it gets either from 195 Exporters or through local correlation to other IPFIX devices. 197 To clarify, no new BGP community attribute is defined in this 198 document, IDR (Inter Domain Routing) working group is the right place 199 to define new community attributes for the BGP protocol. 201 Note that this document does not update the IPFIX specification 202 [RFC7011] and the Information Model [RFC7012] because IANA's IPFIX 203 registry [IANA-IPFIX] is the ultimate Information Element reference, 204 per Section 1 of [RFC7012]. 206 Please refer to [IANA-IPFIX] for the whole list of the already 207 defined BGP related IEs. 209 Please refer to Appendix A for the encoding example and Section 3 for 210 a detailed use case. 212 2. Terminology 214 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 215 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 216 document are to be interpreted as described in [RFC2119]. 218 IPFIX-specific terminology used in this document is defined in 219 Section 2 of the IPFIX protocol specification [RFC7011] and Section 2 220 of [RFC6183] 222 3. BGP Community based Traffic Collection 224 [RFC4384] introduces the mechanism of using BGP standard communities 225 and extended communities to collect the geographical and topological 226 related information in BGP routing system. [RFC8195] gives some 227 examples about the application of BGP large communities to represent 228 the geographical regions. Since the network traffic at the BGP 229 community granularity represents the traffic generted by different 230 kinds of customers, from different geographical regions according to 231 the network operator's BGP community plan, it is useful for the 232 network operators to analyze and optimize the network traffic among 233 different customers and regions. This section gives a use case in 234 which the network operator uses the BGP community based traffic 235 information to adjust the network paths for different traffic flows. 237 Considering the following scenario, AS C provides transit connection 238 between AS A and B. By tagging with different BGP communities, the 239 routes of AS A and B are categorized into several groups respectively 240 with the operator's plan. For example community A:X and A:Y are used 241 for the routes originated from different geographical regions in AS 242 A, and community B:M and B:N are used for the routes representing the 243 different kinds of customers in AS B, such as B:M is for the mobile 244 customers and B:N is for the fixed line customers. By default, all 245 traffic originating from AS A and destined to AS B (we call it 246 traffic A-B) goes through path C1-C2-C3 (call it Path-1) in AS C. 247 When the link between C1 and C2 is congested, we cannot simply steer 248 all the traffic A-B from Path-1 to Path C1-C4-C3 (call it Path-2), 249 becuse it will cause congestion in Path-2. 251 +----------+ 252 | PCE/SDN | 253 +-------|Controller|-------+ 254 | +----------+ | 255 | | 256 | AS C | 257 | | +----------+ | | 258 | | +---|Router C2 |---+ | | 259 | | | +----------+ | | | 260 AS A | | |100 50| | | AS B 261 +--------+ | +---------+ +---------+ | +--------+ 262 |Router A|--|--|Router C1| |Router C3|--|--|Router B| 263 +--------+ | +---------+ +---------+ | +--------+ 264 Community: | |100 100| | Community: 265 A:X | | +----------+ | | B:M 266 A:Y | +---|Router C4 |---+ | B:N 267 +----------+ 269 Figure 1: BGP Community based Traffic Collection 271 If the PCE/SDN controller in AS C can obtain the network traffic 272 information at the BGP community granularity, it can steer some 273 traffic related to some BGP communities (when we consider only the 274 source or destination of the traffic), or some BGP community pairs 275 (when we consider both the source and the destination of the traffic) 276 from Path-1 to Path-2 according to the utilization of different 277 paths. For instance, steer the traffic generated by community A:X 278 from Path-1 to Path-2 by deploying route policy at Router C1, or 279 steer the traffic from community A:Y to community B:M from Path-1 to 280 Path-2. Using the IEs defined in this document, IPFIX can export the 281 BGP community information related to a specific traffic flow together 282 with other flow information. The traffic information can then be 283 accumulated at the BGP community granularity and used by the PCE/SDN 284 controller to steer the appropriate traffic from Path-1 to Path-2. 286 4. IEs for BGP Standard Community 288 [RFC1997] defines the BGP Communities attribute, called BGP Standard 289 Community in this document, which describes a group of routes sharing 290 some common properties. BGP Standard Communities are treated as 32 291 bit values as stated in[RFC1997]. 293 In order to export BGP standard community information along with 294 other flow information defined by IPFIX, three new IEs are 295 introduced. One is bgpCommunity, which is used to identify that the 296 value in this IE is a BGP standard community. The other two are 297 bgpSourceCommunityList and bgpDestinationCommunityList, which are 298 both basicList [RFC6313] of bgpCommunity, and are used to export BGP 299 standard community information corresponding to a specific flow's 300 source and destination IP address respectively. 302 The detailed information of the three new IEs are shown in Section 9 303 IANA Considerations. 305 5. IEs for BGP Extended Community 307 [RFC4360] defines the BGP Extended Communities attribute, which 308 provides a mechanism for labeling the information carried in BGP. 309 Each Extended Community is encoded as an 8-octet quantity with the 310 format defined in [RFC4360]. 312 In order to export BGP Extended Community information together with 313 other flow information by IPFIX, three new IEs are introduced. The 314 first one is bgpExtendedCommunity, which is used to identify that the 315 value in this IE is a BGP Extended Community. The other two are 316 bgpSourceExtendedCommunityList and 317 bgpDestinationExtendedCommunityList, which are both basicList 318 [RFC6313] of bgpExtendedCommunity, and are used to export the BGP 319 Extended Community information corresponding to a specific flow's 320 source and destination IP address respectively. 322 The detailed information of the three new IEs are shown in Section 9 323 IANA Considerations. 325 6. IEs for BGP Large Community 327 [RFC8092] defines the BGP Large Communities attribute, which is 328 suitable for use with all Autonomous System Numbers (ASNs) including 329 four-octet ASNs. Each BGP Large Community is encoded as a 12-octet 330 quantity with the format defined in [RFC8092]. 332 In order to export BGP Large Community information together with 333 other flow information by IPFIX, three new IEs are introduced. The 334 first one is bgpLargeCommunity, which is used to identify that the 335 value in this IE is a BGP Large Community. The other two are 336 bgpSourceLargeCommunityList and bgpDestinationLargeCommunityList, 337 which are both basicList [RFC6313] of bgpLargeCommunity, and are used 338 to export the BGP Large Community information corresponding to a 339 specific flow's source and destination IP address respectively. 341 The detailed information of the three new IEs are shown in Section 9 342 IANA Considerations. 344 7. Operational Considerations 346 The maximum length of an IPFIX message is 65535 bytes as per 347 [RFC7011] , and the maximum length of a normal BGP message is 4096 348 bytes as per [RFC4271]. Since BGP communities, including standard, 349 extended, and large communities , are BGP path attributes carried in 350 BGP Update messages, the total length of these attributes can not 351 exceed the length of a BGP message, i.e. 4096 bytes. So one IPFIX 352 message with maximum length of 65535 bytes has enough space to fit 353 all the communities related to a specific flow, relating to both the 354 source and destination IP addresses. 356 [I-D.ietf-idr-bgp-extended-messages] extends the maximum size of a 357 BGP Update message to 65535 bytes. Then theoretically the BGP 358 community information related to a specific flow may exceed the 359 length of one IPFIX message. However, according to information about 360 networks in the field, the number of BGP communities in one BGP route 361 is usually no more than 10. Nevertheless, BGP speakers that support 362 the extended message SHOULD be careful to export the BGP communities 363 in the IPFIX message properly, such as only convey as many 364 communities as possible in the IPFIX message. The Collector which 365 receives an IPFIX message with maximum length and BGP communities 366 contained in its data set SHOULD be aware that the BGP communities 367 may be truncated due to limited message space. In this case, it is 368 RECOMMENDED to configure the export policy of BGP communities to 369 limit the BGP communities by including or excluding specific 370 communities. 372 If needed, we may consider to extend the message length of IPFIX 373 [RFC7011] from 16 bits to 32 bits to solve this problem completely. 374 The details of increasing IPFIX message length is out of scope of 375 this document. 377 To align with the size of BGP extended community and large community, 378 the size of IE bgpExtendedCommunity and bgpLargeCommunity is 8 octets 379 and 12 octets respectively. In the event that the 380 bgpExtendedCommunity or bgpLargeCommunity IE is not of its expected 381 size, the IPFIX Collector SHOULD ignore it. This is intended to 382 protect implementations using BGP logic from calling their parsing 383 routines with invalid lengths. 385 For the proper processing of the Exporter, when it receives the 386 template requesting to report the BGP community information (refer to 387 Appendix A for an example), the Exporter SHOULD obtain the 388 corresponding BGP community information through BGP lookup using the 389 corresponding source or destination IP address of the specific 390 traffic flow. When exporting the IPFIX information to the Collector, 391 the Exporter SHOULD include the corresponding BGP communities in the 392 IPFIX message. 394 8. Security Considerations 396 This document only defines new IEs for IPFIX. This document itself 397 does not directly introduce security issues. The same security 398 considerations as for the IPFIX Protocol Specification [RFC7011] and 399 Information Model [RFC7012] apply. 401 As the BGP community information is deducible by other means, there 402 are no increased privacy concerns, neither. 404 9. IANA Considerations 406 This draft specifies the following IPFIX IEs to export BGP community 407 information along with other flow information. 409 The Element IDs for these IEs are solicited to be assigned by IANA. 410 The following table is for IANA's reference to put in each field in 411 the registry. 413 ---------------------------------------------------------------------- 414 |ElementID| Name | Data Type|Data Type Semantics| 415 |--------------------------------------------------------------------| 416 | TBA1 | bgpCommunity |unsigned32| identifier | 417 |--------------------------------------------------------------------| 418 | TBA2 | bgpSourceCommunityList | basicList| list | 419 |--------------------------------------------------------------------| 420 | TBA3 |bgpDestinationCommunityList| basicList| list | 421 |--------------------------------------------------------------------| 422 | TBA4 | bgpExtendedCommunity |octetArray| default | 423 |--------------------------------------------------------------------| 424 | TBA5 | bgpSourceExtended | | | 425 | | CommunityList | basicList| list | 426 |--------------------------------------------------------------------| 427 | TBA6 | bgpDestinationExtended | | | 428 | | CommunityList | basicList| list | 429 |--------------------------------------------------------------------| 430 | TBA7 | bgpLargeCommunity |octetArray| default | 431 |--------------------------------------------------------------------| 432 | TBA8 |bgpSourceLargeCommunityList| basicList| list | 433 |--------------------------------------------------------------------| 434 | TBA9 | bgpDestinationLarge | | | 435 | | CommunityList | basicList| list | 436 |--------------------------------------------------------------------| 438 ---------------------------------------------------------------------- 439 |ElementID| Description | Units | 440 |--------------------------------------------------------------------| 441 | TBA1 | BGP community as defined in [RFC1997] | | 442 |--------------------------------------------------------------------| 443 | TBA2 | zero or more BGP communities corresponding | | 444 | | with source IP address of a specific flow | | 445 |--------------------------------------------------------------------| 446 | TBA3 | zero or more BGP communities corresponding | | 447 | |with destination IP address of a specific flow| | 448 |--------------------------------------------------------------------| 449 | TBA4 |BGP Extended Community as defined in [RFC4360]| | 450 | |The size of this IE MUST be 8 octets | | 451 |--------------------------------------------------------------------| 452 | | zero or more BGP Extended Communities | | 453 | TBA5 | corresponding with source IP address of | | 454 | | a specific flow | | 455 |--------------------------------------------------------------------| 456 | | zero or more BGP Extended communities | | 457 | TBA6 | corresponding with destination IP address | | 458 | | of a specific flow | | 459 |--------------------------------------------------------------------| 460 | TBA7 | BGP Large Community as defined in [RFC8092] | | 461 | | The size of this IE MUST be 12 octets. | | 462 |--------------------------------------------------------------------| 463 | | zero or more BGP Large Communities | | 464 | TBA8 | corresponding with source IP address | | 465 | | of a specific flow | | 466 |--------------------------------------------------------------------| 467 | | zero or more BGP Large communities | | 468 | TBA9 | corresponding with destination IP address | | 469 | | of a specific flow | | 470 |--------------------------------------------------------------------| 472 ---------------------------------------------------------------------- 473 |ElementID| Range | References | Requester | Revision | date | 474 |--------------------------------------------------------------------| 475 | TBA1 | | RFC1997 |this draft | 0 | | 476 |--------------------------------------------------------------------| 477 | TBA2 | |RFC6313,RFC1997|this draft | 0 | | 478 |--------------------------------------------------------------------| 479 | TBA3 | |RFC6313,RFC1997|this draft | 0 | | 480 |--------------------------------------------------------------------| 481 | TBA4 | | RFC4360 |this draft | 0 | | 482 |--------------------------------------------------------------------| 483 | TBA5 | |RFC6313,RFC4360|this draft | 0 | | 484 |--------------------------------------------------------------------| 485 | TBA6 | |RFC6313,RFC4360|this draft | 0 | | 486 |--------------------------------------------------------------------| 487 | TBA7 | | RFC8092 |this draft | 0 | | 488 |--------------------------------------------------------------------| 489 | TBA8 | |RFC6313,RFC8092|this draft | 0 | | 490 |--------------------------------------------------------------------| 491 | TBA9 | |RFC6313,RFC8092|this draft | 0 | | 492 |--------------------------------------------------------------------| 494 Figure 2: IANA Considerations 496 10. Acknowledgements 498 The authors would like to thank Benoit Claise and Paul Aitken for 499 their comments and suggestions to promote this document. 500 Appreciations are given to Tianran Zhou, Warren Kumari, Jeffrey Haas, 501 Ignas Bagdonas, Stewart Bryant, Paolo Lucente, Job Snijders, Jared 502 Mauch, Rudiger Volk, etc, for their discussion, comments and 503 suggestions in the face to face meetings and in the mail list. 505 11. References 507 11.1. Normative References 509 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 510 Requirement Levels", BCP 14, RFC 2119, 511 DOI 10.17487/RFC2119, March 1997, 512 . 514 [RFC6313] Claise, B., Dhandapani, G., Aitken, P., and S. Yates, 515 "Export of Structured Data in IP Flow Information Export 516 (IPFIX)", RFC 6313, DOI 10.17487/RFC6313, July 2011, 517 . 519 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 520 "Specification of the IP Flow Information Export (IPFIX) 521 Protocol for the Exchange of Flow Information", STD 77, 522 RFC 7011, DOI 10.17487/RFC7011, September 2013, 523 . 525 11.2. Informative References 527 [Community-TE] 528 Shao, W., Devienne, F., Iannone, L., and JL. Rougier, "On 529 the use of BGP communities for fine-grained inbound 530 traffic engineering", Computer Science 27392(1):476-487, 531 November 2015. 533 [I-D.ietf-idr-bgp-extended-messages] 534 Bush, R., Patel, K., and D. Ward, "Extended Message 535 support for BGP", draft-ietf-idr-bgp-extended-messages-26 536 (work in progress), June 2018. 538 [IANA-IPFIX] 539 "IP Flow Information Export (IPFIX) Entities", 540 . 542 [RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities 543 Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996, 544 . 546 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 547 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 548 DOI 10.17487/RFC4271, January 2006, 549 . 551 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 552 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 553 February 2006, . 555 [RFC4384] Meyer, D., "BGP Communities for Data Collection", BCP 114, 556 RFC 4384, DOI 10.17487/RFC4384, February 2006, 557 . 559 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 560 Element (PCE)-Based Architecture", RFC 4655, 561 DOI 10.17487/RFC4655, August 2006, 562 . 564 [RFC5982] Kobayashi, A., Ed. and B. Claise, Ed., "IP Flow 565 Information Export (IPFIX) Mediation: Problem Statement", 566 RFC 5982, DOI 10.17487/RFC5982, August 2010, 567 . 569 [RFC6183] Kobayashi, A., Claise, B., Muenz, G., and K. Ishibashi, 570 "IP Flow Information Export (IPFIX) Mediation: Framework", 571 RFC 6183, DOI 10.17487/RFC6183, April 2011, 572 . 574 [RFC7012] Claise, B., Ed. and B. Trammell, Ed., "Information Model 575 for IP Flow Information Export (IPFIX)", RFC 7012, 576 DOI 10.17487/RFC7012, September 2013, 577 . 579 [RFC7854] Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP 580 Monitoring Protocol (BMP)", RFC 7854, 581 DOI 10.17487/RFC7854, June 2016, 582 . 584 [RFC8092] Heitz, J., Ed., Snijders, J., Ed., Patel, K., Bagdonas, 585 I., and N. Hilliard, "BGP Large Communities Attribute", 586 RFC 8092, DOI 10.17487/RFC8092, February 2017, 587 . 589 [RFC8195] Snijders, J., Heasley, J., and M. Schmidt, "Use of BGP 590 Large Communities", RFC 8195, DOI 10.17487/RFC8195, June 591 2017, . 593 Appendix A. Encoding Example 595 In this section, we give an example to show the encoding format for 596 the new introduced IEs. 598 Flow information including BGP communities is shown in the below 599 table. Suppose we want all the fields to be reported by IPFIX. 601 ---------------------------------------------------------------------- 602 | Source |Destination| BGP community | BGP community | 603 | IP | IP | corresponding with | corresponding with | 604 | | | Source IP | Destination IP | 605 ---------------------------------------------------------------------- 606 | 1.1.1.1 | 2.2.2.2 | 1:1001,1:1002,8:1001 | 2:1002,8:1001 | 607 ---------------------------------------------------------------------- 608 | 3.3.3.3 | 4.4.4.4 | 3:1001,3:1002,8:1001 | 4:1001,8:1001 | 609 ---------------------------------------------------------------------- 611 Figure 3: Flow information including BGP communities 613 A.1. Template Record 614 0 1 2 3 615 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 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 | SET ID = 2 | Length = 24 | 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 619 | Template ID = 256 | Field Count = 4 | 620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 621 |0| SourceIPv4Address = 8 | Field length = 4 | 622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 623 |0| DestinationIPv4Address = 12 | Field length = 4 | 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 |0| bgpSourceCommunityList= TBA2| Field length = 0xFFFF | 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 |0| bgpDestinationCommunityList | Field length = 0xFFFF | 628 | | = TBA3 | | 629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 631 Figure 4: Template Record Encoding Format 633 In this example, the Template ID is 256, which will be used in the 634 Data Record. The field length for bgpSourceCommunityList and 635 bgpDestinationCommunityList is 0xFFFF, which means the length of this 636 IE is variable, the actual length of this IE is indicated by the list 637 length field in the basic list format as per [RFC6313]. 639 A.2. Data Set 641 The data set is represented as follows: 643 0 1 2 3 644 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 645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 646 | SET ID = 256 | Length = 92 | 647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 648 | SourceIPv4Address = 1.1.1.1 | 649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 650 | DestinationIPv4Address = 2.2.2.2 | 651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 652 | 255 | List length = 17 |semantic=allof | 653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 654 | bgpCommunity = TBA1 | Field Len = 4 | 655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 656 | BGP Source Community Value 1 = 1:1001 | 657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 658 | BGP Source Community Value 2 = 1:1002 | 659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 660 | BGP Source Community Value 3 = 8:1001 | 661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 662 | 255 | List length = 13 |semantic =allof| 663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 664 | bgpCommunity = TBA1 | Field Len = 4 | 665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 666 | BGP Destination Community Value 1 = 2:1002 | 667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 668 | BGP Destination Community Value 2 = 8:1001 | 669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 670 | SourceIPv4Address = 3.3.3.3 | 671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 672 | DestinationIPv4Address = 4.4.4.4 | 673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 674 | 255 | List length = 17 |semantic =allof| 675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 676 | bgpCommunity = TBA1 | Field Len = 4 | 677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 678 | BGP Source Community Value 1 = 3:1001 | 679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 680 | BGP Source Community Value 2 = 3:1002 | 681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 682 | BGP Source Community Value 3 = 8:1001 | 683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 684 | 255 | List length = 13 |semantic =allof| 685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 686 | bgpCommunity = TBA1 | Field Len = 4 | 687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 688 | BGP Destination Community Value 1 = 4:1001 | 689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 690 | BGP Destination Community Value 2 = 8:1001 | 691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 Figure 5: Data Set Encoding Format 695 Authors' Addresses 697 Zhenqiang Li 698 China Mobile 699 32 Xuanwumen West Ave, Xicheng District 700 Beijing 100053 701 China 703 Email: li_zhenqiang@hotmail.com 704 Rong Gu 705 China Mobile 706 32 Xuanwumen West Ave, Xicheng District 707 Beijing 100053 708 China 710 Email: gurong_cmcc@outlook.com 712 Jie Dong 713 Huawei Technologies 714 Huawei Campus, No. 156 Beiqing Rd. 715 Beijing 100095 716 China 718 Email: jie.dong@huawei.com