idnits 2.17.1 draft-ietf-opsawg-ipfix-bgp-community-11.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 (November 25, 2018) is 1980 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: May 29, 2019 J. Dong 6 Huawei Technologies 7 November 25, 2018 9 Export BGP community information in IP Flow Information Export (IPFIX) 10 draft-ietf-opsawg-ipfix-bgp-community-11 12 Abstract 14 By introducing new Information Elements (IEs), this draft extends the 15 existing BGP-related IEs to enable IPFIX [RFC7011] to export BGP 16 community information, including BGP standard communities [RFC1997], 17 BGP extended communities [RFC4360], and BGP large communities 18 [RFC8092]. Network traffic information can then be accumulated and 19 analyzed at the BGP community granularity, which represents the 20 traffic of different kinds of customers, services, or geographical 21 regions according to the network operator's BGP community planning. 22 Network traffic information at the BGP community granularity is 23 useful for network traffic analysis and engineering. 25 To clarify, no new BGP community attribute is defined in this 26 document and this document does not replace BGP Monitoring Protocol 27 (BMP) defined in RFC7854. The IEs introduced in this document are 28 used by IPFIX, together with other IEs, to facilitate the IPFIX 29 Collector analyzing network traffic at the BGP community granularity 30 without needing to run the heavy BGP itself. When needed, the IPFIX 31 Mediator or Collector can use the IEs introduced in this document to 32 report the BGP community-related traffic flow information it gets 33 either from Exporters or through local correlation to other IPFIX 34 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 May 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 . . . . . . . . . . . . . . . . . . . . . 14 85 A.2. Data Set . . . . . . . . . . . . . . . . . . . . . . . . 14 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 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, and can then optimize 95 their network when needed. For example, they can shift some flows 96 from congested links to low utilized links through an SDN controller 97 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 Tier 1 or Tier 2 105 operators' backbone networks, traffic flow information based on these 106 IEs may not be completely suitable or sufficient. For example, flow 107 information based on IP address or IP prefix may provide much too 108 fine granularity for a large network. On the contrary, flow 109 information based on AS number may be too coarse. 111 BGP community is a BGP path attribute that includes standard 112 communities [RFC1997], extended communities [RFC4360], and large 113 communities [RFC8092]. The BGP community attribute has a variety of 114 use cases, one of which is to use BGP community with planned specific 115 values to represent groups of customers, services, and geographical 116 or topological regions, as used by operators in their networks. 117 Detailed examples can be found in [RFC4384], [RFC8195] and Section 3 118 of this document. To understand the traffic generated by different 119 kinds of customers, from different geographical or topological 120 regions, by different kinds of customers in different regions, we 121 need the corresponding community information related to the traffic 122 flow information exported by IPFIX. Network traffic statistics at 123 the BGP community granularity are useful not only for the traffic 124 analyzing, but also can then be used by other applications, such as 125 traffic optimization applications located in an IPFIX Collector, SDN 126 controller or PCE. [Community-TE] also states that analyzing network 127 traffic information at the BGP community granularity is preferred for 128 inbound traffic engineering. However, [IANA-IPFIX] lacks IEs defined 129 for the BGP community attribute. 131 Flow information based on BGP community may be collected by an IPFIX 132 Mediator defined in [RFC6183]. IPFIX Mediator is responsible for the 133 correlation between flow information and BGP community. However, no 134 IEs are defined in [RFC6183] for exporting BGP community information 135 in IPFIX. Furthermore, to correlate the BGP community with the flow 136 information, the IPFIX Mediator needs to learn BGP routes and perform 137 lookups in the BGP routing table to get the matching entry for a 138 specific flow. Neither BGP route learning nor routing table lookup 139 are trivial for an IPFIX Mediator. The IPFIX Mediator is mainly 140 introduced to reduce the performance requirement for the Exporter 141 [RFC5982]. In fact, to obtain the information for the already 142 defined BGP related IEs, such as bgpSourceAsNumber, 143 bgpDestinationAsNumber, and bgpNextHopIPv4Address, etc, the Exporter 144 has to hold the up-to-date BGP routing table and perform lookups in 145 the table. The Exporter can obtain the BGP community information in 146 the same procedure, thus the additional load added by exporting BGP 147 community information is minimal if the Exporter is already exporting 148 the existing BGP-related IEs. It is RECOMMENDED that the BGP 149 community information be exported by the Exporter directly using 150 IPFIX. 152 Through running BGP [RFC4271] or BMP [RFC7854] and performing lookups 153 in the BGP routing table to correlate the matching entry for a 154 specific flow, IPFIX Collectors and other applications, such as SDN 155 controller or PCE, can determine the network traffic at the BGP 156 community granularity. However, neither running BGP or BMP protocol 157 nor routing table lookup are trivial for the IPFIX Collectors and 158 other applications. Moreover, correlation between IPFIX flow 159 information and the BGP RIB on the Exporter (such as a router) is 160 more accurate, compared to the correlation on a Collector, since the 161 BGP routing table may be updated when the IPFIX Collectors and other 162 applications receive the IPFIX flow information. And as stated 163 above, the Exporter can obtain the BGP community information during 164 the same procedure when it obtains other BGP related information. So 165 exporting the BGP community information directly by the Exporter to 166 the Collector is both efficient and accurate. If the IPFIX 167 Collectors and other applications only want to determine the network 168 traffic at the BGP community granularity, they do not need to run the 169 full BGP or BMP protocols when the BGP community information can be 170 obtained by IPFIX. However, the BMP protocol has its own application 171 scenario, and the mechanism introduced in this document is not meant 172 to replace it. 174 By introducing new IEs, this draft extends the existing BGP-related 175 IEs to enable IPFIX [RFC7011] to export BGP community information, 176 including the BGP standard communities [RFC1997], BGP extended 177 communities [RFC4360], and BGP large communities [RFC8092]. Flow 178 information, including packetDeltaCount, octetDeltaCount [RFC7012], 179 etc., can then be accumulated and analyzed by the Collector or other 180 applications, such as an SDN controller or PCE [RFC4655], at the BGP 181 community granularity, which is useful for measuring the traffic 182 generated by different kinds of customers, from different 183 geographical or topological regions according to the operator's BGP 184 community plan, and can then be used by the traffic engineering or 185 traffic optimization applications, especially in the backbone 186 network. 188 The IEs introduced in this document are applicable for both IPv4 and 189 IPv6 traffic. Both the Exporter and the IPFIX Mediator can use these 190 IEs to export BGP community information in IPFIX. When needed, the 191 IPFIX Mediator or Collector can use these IEs to report BGP community 192 related traffic flow information it gets either from Exporters or 193 through local correlation to other IPFIX devices. 195 As stated above, the method introduced in this document is not the 196 definitive and the only one to obtain BGP community information 197 related to a specific traffic flow, but a possible, efficient and 198 accurate one. 200 No new BGP community attributes are defined in this document. 202 Note that this document does not update the IPFIX specification 203 [RFC7011] and the Information Model [RFC7012]. Rather, IANA's IPFIX 204 registry [IANA-IPFIX] contains the current complete Information 205 Element reference, per Section 1 of [RFC7012]. 207 Please refer to [IANA-IPFIX] for the complete list of BGP-related 208 IEs. 210 Please refer to Appendix A of this document for the encoding example 211 and Section 3 for a detailed use case. 213 2. Terminology 215 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 216 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 217 document are to be interpreted as described in [RFC2119]. 219 IPFIX-specific terminology used in this document is defined in 220 Section 2 of [RFC7011] and Section 2 of [RFC6183]. 222 BGP standard community: The BGP Communities attribute defined in 223 [RFC1997]. In order to distinguish it from BGP extended communities 224 [RFC4360], and large communities [RFC8092], BGP Communities attribute 225 is called BGP standard community in this document. 227 3. BGP Community-based Traffic Collection 229 [RFC4384] introduces the mechanism of using BGP standard community 230 and extended community to collect the geographical and topological 231 related information in the BGP routing system. [RFC8195] gives some 232 examples of the application of BGP large communities to represent the 233 geographical regions. Since the network traffic at the BGP community 234 granularity represents the traffic generated by different kinds of 235 customers, from different geographical regions according to the 236 network operator's BGP community plan, it is useful for network 237 operators to analyze and optimize the network traffic among different 238 customers and regions. This section gives a use case in which the 239 network operator uses the BGP community-based traffic information to 240 adjust the network paths for different traffic flows. 242 Consider the following scenario, AS C provides a transit connection 243 between ASes A and B. By tagging with different BGP communities, the 244 routes of AS A and B are categorized into several groups respectively 245 in the operator's plan. For example, communities A:X and A:Y are 246 used for the routes originated from different geographical regions in 247 AS A, and communities B:M and B:N are used for the routes 248 representing the different kinds of customers in AS B, such as B:M is 249 for the mobile customers and B:N is for the fixed line customers. By 250 default, all traffic originating from AS A and destined to AS B (we 251 call it traffic A-B) goes through path C1-C2-C3 (call it Path-1) in 252 AS C. When the link between C1 and C2 is congested, we cannot simply 253 steer all the traffic A-B from Path-1 to Path C1-C4-C3 (call it Path- 254 2), because it will cause congestion in Path-2. 256 +----------+ 257 | PCE/SDN | 258 +-------|Controller|-------+ 259 | +----------+ | 260 | | 261 | AS C | 262 | | +----------+ | | 263 | | +---|Router C2 |---+ | | 264 | | | +----------+ | | | 265 AS A | | |100 50| | | AS B 266 +--------+ | +---------+ +---------+ | +--------+ 267 |Router A|--|--|Router C1| |Router C3|--|--|Router B| 268 +--------+ | +---------+ +---------+ | +--------+ 269 Community: | |100 100| | Community: 270 A:X | | +----------+ | | B:M 271 A:Y | +---|Router C4 |---+ | B:N 272 +----------+ 274 Figure 1: BGP Community based Traffic Collection 276 If the PCE/SDN controller in AS C can obtain the network traffic 277 information at the BGP community granularity, it can steer some 278 traffic related to some BGP communities (when we consider only the 279 source or destination of the traffic), or some BGP community pairs 280 (when we consider both the source and the destination of the traffic) 281 from Path-1 to Path-2 according to the utilization of different 282 paths. For instance, steer the traffic generated by community A:X 283 from Path-1 to Path-2 by deploying a route policy at Router C1, or 284 steer the traffic from community A:Y to community B:M from Path-1 to 285 Path-2. Using the IEs defined in this document, IPFIX can export the 286 BGP community information related to a specific traffic flow together 287 with other flow information. The traffic information can then be 288 accumulated at the BGP community granularity and used by the PCE/SDN 289 controller to steer the appropriate traffic from Path-1 to Path-2. 291 4. IEs for BGP Standard Community 293 [RFC1997] defines the BGP Communities attribute, called BGP Standard 294 Community in this document, which describes a group of routes sharing 295 some common properties. BGP Standard Community is treated as 32 bit 296 value as stated in [RFC1997]. 298 In order to export BGP standard community information along with 299 other flow information defined by IPFIX, three new IEs are 300 introduced. One is bgpCommunity, which is used to identify that the 301 value in this IE is a BGP standard community. The other two are 302 bgpSourceCommunityList and bgpDestinationCommunityList, which are 303 both basicList [RFC6313] of bgpCommunity, and are used to export BGP 304 standard community information corresponding to a specific flow's 305 source and destination IP address respectively. 307 The detailed information of the three new IEs are shown in Section 9, 308 IANA Considerations. 310 5. IEs for BGP Extended Community 312 [RFC4360] defines the BGP Extended Communities attribute, which 313 provides a mechanism for labeling the information carried in BGP. 314 Each Extended Community is encoded as an 8-octet quantity with the 315 format defined in [RFC4360]. 317 In order to export BGP Extended Community information together with 318 other flow information by IPFIX, three new IEs are introduced. The 319 first one is bgpExtendedCommunity, which is used to identify that the 320 value in this IE is a BGP Extended Community. The other two are 321 bgpSourceExtendedCommunityList and 322 bgpDestinationExtendedCommunityList, which are both basicList 323 [RFC6313] of bgpExtendedCommunity, and are used to export the BGP 324 Extended Community information corresponding to a specific flow's 325 source and destination IP address respectively. 327 The detailed information of the three new IEs are shown in Section 9, 328 IANA Considerations. 330 6. IEs for BGP Large Community 332 [RFC8092] defines the BGP Large Communities attribute, which is 333 suitable for use with all Autonomous System Numbers (ASNs) including 334 four-octet ASNs. Each BGP Large Community is encoded as a 12-octet 335 quantity with the format defined in [RFC8092]. 337 In order to export BGP Large Community information together with 338 other flow information by IPFIX, three new IEs are introduced. The 339 first one is bgpLargeCommunity, which is used to identify that the 340 value in this IE is a BGP Large Community. The other two are 341 bgpSourceLargeCommunityList and bgpDestinationLargeCommunityList, 342 which are both basicList [RFC6313] of bgpLargeCommunity, and are used 343 to export the BGP Large Community information corresponding to a 344 specific flow's source and destination IP address respectively. 346 The detailed information of the three new IEs are shown in Section 9, 347 IANA Considerations. 349 7. Operational Considerations 351 The maximum length of an IPFIX message is 65535 bytes as per 352 [RFC7011] , and the maximum length of a normal BGP message is 4096 353 bytes as per [RFC4271]. Since BGP communities, including standard, 354 extended, and large communities , are BGP path attributes carried in 355 BGP Update messages, the total length of these attributes can not 356 exceed the length of a BGP message, i.e. 4096 bytes. So one IPFIX 357 message with a maximum length of 65535 bytes has enough space to fit 358 all the communities related to a specific flow, relating to both the 359 source and destination IP addresses. 361 [I-D.ietf-idr-bgp-extended-messages] extends the maximum size of a 362 BGP Update message to 65535 bytes. In that case, the BGP community 363 information related to a specific flow could theoretically exceed the 364 length of one IPFIX message. However, according to information 365 regarding actual networks in the field, the number of BGP communities 366 in one BGP route is usually no more than ten. Nevertheless, BGP 367 speakers that support the extended message SHOULD be careful to 368 export the BGP communities in the IPFIX message properly, so that 369 they only convey as many communities as possible in the IPFIX 370 message. The Collector which receives an IPFIX message with maximum 371 length and BGP communities contained in its data set SHOULD be aware 372 that the BGP communities may be truncated due to limited message 373 space. In this case, it is RECOMMENDED to configure the export 374 policy of BGP communities to limit the BGP communities by including 375 or excluding specific communities. 377 If needed, the IPFIX message length could be extended from 16 bits to 378 32 bits to solve this problem completely. The details of increasing 379 the IPFIX message length is out of scope of this document. 381 To align with the size of the BGP extended community and large 382 community attributes, the size of IE bgpExtendedCommunity and 383 bgpLargeCommunity is 8 octets and 12 octets respectively. In the 384 event that the bgpExtendedCommunity or bgpLargeCommunity IE is not of 385 its expected size, the IPFIX Collector SHOULD ignore it. This is 386 intended to protect implementations using BGP logic from calling 387 their parsing routines with invalid lengths. 389 For the proper processing of the Exporter when it receives the 390 template requesting to report the BGP community information (refer to 391 Appendix A for an example), the Exporter SHOULD obtain the 392 corresponding BGP community information through BGP lookup using the 393 corresponding source or destination IP address of the specific 394 traffic flow. When exporting the IPFIX information to the Collector, 395 the Exporter SHOULD include the corresponding BGP communities in the 396 IPFIX message. 398 8. Security Considerations 400 This document only defines new IEs for IPFIX. This document itself 401 does not directly introduce any new security issues. The same 402 security considerations as for the IPFIX Protocol Specification 403 [RFC7011] and Information Model [RFC7012] apply. 405 As the BGP community information is deducible by other means, there 406 are no increased privacy concerns as well. 408 9. IANA Considerations 410 This draft specifies the following IPFIX IEs to export BGP community 411 information along with other flow information. 413 The Element IDs for these IEs are requested to be assigned by IANA. 414 The following table is for IANA's use to place in each field in the 415 registry. 417 ---------------------------------------------------------------------- 418 |ElementID| Name | Data Type|Data Type Semantics| 419 |--------------------------------------------------------------------| 420 | TBA1 | bgpCommunity |unsigned32| identifier | 421 |--------------------------------------------------------------------| 422 | TBA2 | bgpSourceCommunityList | basicList| list | 423 |--------------------------------------------------------------------| 424 | TBA3 |bgpDestinationCommunityList| basicList| list | 425 |--------------------------------------------------------------------| 426 | TBA4 | bgpExtendedCommunity |octetArray| default | 427 |--------------------------------------------------------------------| 428 | TBA5 | bgpSourceExtended | | | 429 | | CommunityList | basicList| list | 430 |--------------------------------------------------------------------| 431 | TBA6 | bgpDestinationExtended | | | 432 | | CommunityList | basicList| list | 433 |--------------------------------------------------------------------| 434 | TBA7 | bgpLargeCommunity |octetArray| default | 435 |--------------------------------------------------------------------| 436 | TBA8 |bgpSourceLargeCommunityList| basicList| list | 437 |--------------------------------------------------------------------| 438 | TBA9 | bgpDestinationLarge | | | 439 | | CommunityList | basicList| list | 440 |--------------------------------------------------------------------| 442 ---------------------------------------------------------------------- 443 |ElementID| Description | Units | 444 |--------------------------------------------------------------------| 445 | TBA1 | BGP community as defined in [RFC1997] | | 446 |--------------------------------------------------------------------| 447 | | basicList of zero or more bgpCommunity IEs, | | 448 | TBA2 | containing the BGP communities corresponding| | 449 | | with source IP address of a specific flow | | 450 |--------------------------------------------------------------------| 451 | | basicList of zero or more bgpCommunity IEs, | | 452 | TBA3 |containing the BGP communities corresponding | | 453 | |with destination IP address of a specific flow| | 454 |--------------------------------------------------------------------| 455 | TBA4 |BGP Extended Community as defined in [RFC4360]| | 456 | |The size of this IE MUST be 8 octets | | 457 |--------------------------------------------------------------------| 458 | |basicList of zero or more bgpExtendedCommunity| | 459 | TBA5 |IEs, containing the BGP Extended Communities | | 460 | |corresponding with source IP address of | | 461 | | a specific flow | | 462 |--------------------------------------------------------------------| 463 | |basicList of zero or more bgpExtendedCommunity| | 464 | TBA6 |IEs, containing the BGP Extended Communities | | 465 | | corresponding with destination IP address | | 466 | | of a specific flow | | 467 |--------------------------------------------------------------------| 468 | TBA7 | BGP Large Community as defined in [RFC8092] | | 469 | | The size of this IE MUST be 12 octets. | | 470 |--------------------------------------------------------------------| 471 | | basicList of zero or more bgpLargeCommunity | | 472 | | IEs, containing the BGP Large Communities | | 473 | TBA8 | corresponding with source IP address | | 474 | | of a specific flow | | 475 |--------------------------------------------------------------------| 476 | | basicList of zero or more bgpLargeCommunity | | 477 | | IEs, containing the BGP Large Communities | | 478 | TBA9 | corresponding with destination IP address | | 479 | | of a specific flow | | 480 |--------------------------------------------------------------------| 482 ---------------------------------------------------------------------- 483 |ElementID| Range | References | Requester | Revision | date | 484 |--------------------------------------------------------------------| 485 | TBA1 | | RFC1997 |this draft | 0 | | 486 |--------------------------------------------------------------------| 487 | TBA2 | |RFC6313,RFC1997|this draft | 0 | | 488 |--------------------------------------------------------------------| 489 | TBA3 | |RFC6313,RFC1997|this draft | 0 | | 490 |--------------------------------------------------------------------| 491 | TBA4 | | RFC4360 |this draft | 0 | | 492 |--------------------------------------------------------------------| 493 | TBA5 | |RFC6313,RFC4360|this draft | 0 | | 494 |--------------------------------------------------------------------| 495 | TBA6 | |RFC6313,RFC4360|this draft | 0 | | 496 |--------------------------------------------------------------------| 497 | TBA7 | | RFC8092 |this draft | 0 | | 498 |--------------------------------------------------------------------| 499 | TBA8 | |RFC6313,RFC8092|this draft | 0 | | 500 |--------------------------------------------------------------------| 501 | TBA9 | |RFC6313,RFC8092|this draft | 0 | | 502 |--------------------------------------------------------------------| 504 Figure 2: IANA Considerations 506 10. Acknowledgements 508 The authors would like to thank Benoit Claise and Paul Aitken for 509 their comments and suggestions to promote this document. We also 510 thank Tianran Zhou, Warren Kumari, Jeffrey Haas, Ignas Bagdonas, 511 Stewart Bryant, Paolo Lucente, Job Snijders, Jared Mauch, Rudiger 512 Volk, and Andrew Malis for their discussion, comments, and 513 suggestions to improve this document.. 515 11. References 517 11.1. Normative References 519 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 520 Requirement Levels", BCP 14, RFC 2119, 521 DOI 10.17487/RFC2119, March 1997, 522 . 524 [RFC6313] Claise, B., Dhandapani, G., Aitken, P., and S. Yates, 525 "Export of Structured Data in IP Flow Information Export 526 (IPFIX)", RFC 6313, DOI 10.17487/RFC6313, July 2011, 527 . 529 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 530 "Specification of the IP Flow Information Export (IPFIX) 531 Protocol for the Exchange of Flow Information", STD 77, 532 RFC 7011, DOI 10.17487/RFC7011, September 2013, 533 . 535 11.2. Informative References 537 [Community-TE] 538 Shao, W., Devienne, F., Iannone, L., and JL. Rougier, "On 539 the use of BGP communities for fine-grained inbound 540 traffic engineering", Computer Science 27392(1):476-487, 541 November 2015. 543 [I-D.ietf-idr-bgp-extended-messages] 544 Bush, R., Patel, K., and D. Ward, "Extended Message 545 support for BGP", draft-ietf-idr-bgp-extended-messages-26 546 (work in progress), June 2018. 548 [IANA-IPFIX] 549 "IP Flow Information Export (IPFIX) Entities", 550 . 552 [RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities 553 Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996, 554 . 556 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 557 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 558 DOI 10.17487/RFC4271, January 2006, 559 . 561 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 562 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 563 February 2006, . 565 [RFC4384] Meyer, D., "BGP Communities for Data Collection", BCP 114, 566 RFC 4384, DOI 10.17487/RFC4384, February 2006, 567 . 569 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 570 Element (PCE)-Based Architecture", RFC 4655, 571 DOI 10.17487/RFC4655, August 2006, 572 . 574 [RFC5982] Kobayashi, A., Ed. and B. Claise, Ed., "IP Flow 575 Information Export (IPFIX) Mediation: Problem Statement", 576 RFC 5982, DOI 10.17487/RFC5982, August 2010, 577 . 579 [RFC6183] Kobayashi, A., Claise, B., Muenz, G., and K. Ishibashi, 580 "IP Flow Information Export (IPFIX) Mediation: Framework", 581 RFC 6183, DOI 10.17487/RFC6183, April 2011, 582 . 584 [RFC7012] Claise, B., Ed. and B. Trammell, Ed., "Information Model 585 for IP Flow Information Export (IPFIX)", RFC 7012, 586 DOI 10.17487/RFC7012, September 2013, 587 . 589 [RFC7854] Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP 590 Monitoring Protocol (BMP)", RFC 7854, 591 DOI 10.17487/RFC7854, June 2016, 592 . 594 [RFC8092] Heitz, J., Ed., Snijders, J., Ed., Patel, K., Bagdonas, 595 I., and N. Hilliard, "BGP Large Communities Attribute", 596 RFC 8092, DOI 10.17487/RFC8092, February 2017, 597 . 599 [RFC8195] Snijders, J., Heasley, J., and M. Schmidt, "Use of BGP 600 Large Communities", RFC 8195, DOI 10.17487/RFC8195, June 601 2017, . 603 Appendix A. Encoding Example 605 In this section, we provide an example to show the encoding format 606 for the new introduced IEs. 608 Flow information, including BGP communities, is shown in the 609 following table. In this example, all the fields are reported by 610 IPFIX. 612 ---------------------------------------------------------------------- 613 | Source |Destination| BGP community | BGP community | 614 | IP | IP | corresponding with | corresponding with | 615 | | | Source IP | Destination IP | 616 ---------------------------------------------------------------------- 617 | 1.1.1.1 | 2.2.2.2 | 1:1001,1:1002,8:1001 | 2:1002,8:1001 | 618 ---------------------------------------------------------------------- 619 | 3.3.3.3 | 4.4.4.4 | 3:1001,3:1002,8:1001 | 4:1001,8:1001 | 620 ---------------------------------------------------------------------- 622 Figure 3: Flow information including BGP communities 624 A.1. Template Record 626 0 1 2 3 627 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 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 629 | SET ID = 2 | Length = 24 | 630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 631 | Template ID = 256 | Field Count = 4 | 632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 633 |0| SourceIPv4Address = 8 | Field length = 4 | 634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 635 |0| DestinationIPv4Address = 12 | Field length = 4 | 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 |0| bgpSourceCommunityList= TBA2| Field length = 0xFFFF | 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 |0| bgpDestinationCommunityList | Field length = 0xFFFF | 640 | | = TBA3 | | 641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 Figure 4: Template Record Encoding Format 645 In this example, the Template ID is 256, which will be used in the 646 Data Record. The field length for bgpSourceCommunityList and 647 bgpDestinationCommunityList is 0xFFFF, which means the length of this 648 IE is variable, and the actual length of this IE is indicated by the 649 list length field in the basic list format as per [RFC6313]. 651 A.2. Data Set 653 The data set is represented as follows: 655 0 1 2 3 656 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 657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 658 | SET ID = 256 | Length = 92 | 659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 660 | SourceIPv4Address = 1.1.1.1 | 661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 662 | DestinationIPv4Address = 2.2.2.2 | 663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 664 | 255 | List length = 17 |semantic=allof | 665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 666 | bgpCommunity = TBA1 | Field Len = 4 | 667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 668 | BGP Source Community Value 1 = 1:1001 | 669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 670 | BGP Source Community Value 2 = 1:1002 | 671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 672 | BGP Source Community Value 3 = 8:1001 | 673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 674 | 255 | List length = 13 |semantic =allof| 675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 676 | bgpCommunity = TBA1 | Field Len = 4 | 677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 678 | BGP Destination Community Value 1 = 2:1002 | 679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 680 | BGP Destination Community Value 2 = 8:1001 | 681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 682 | SourceIPv4Address = 3.3.3.3 | 683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 684 | DestinationIPv4Address = 4.4.4.4 | 685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 686 | 255 | List length = 17 |semantic =allof| 687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 688 | bgpCommunity = TBA1 | Field Len = 4 | 689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 690 | BGP Source Community Value 1 = 3:1001 | 691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 692 | BGP Source Community Value 2 = 3:1002 | 693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 694 | BGP Source Community Value 3 = 8:1001 | 695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 696 | 255 | List length = 13 |semantic =allof| 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 | bgpCommunity = TBA1 | Field Len = 4 | 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 700 | BGP Destination Community Value 1 = 4:1001 | 701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 702 | BGP Destination Community Value 2 = 8:1001 | 703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 Figure 5: Data Set Encoding Format 707 Authors' Addresses 709 Zhenqiang Li 710 China Mobile 711 32 Xuanwumen West Ave, Xicheng District 712 Beijing 100053 713 China 715 Email: li_zhenqiang@hotmail.com 717 Rong Gu 718 China Mobile 719 32 Xuanwumen West Ave, Xicheng District 720 Beijing 100053 721 China 723 Email: gurong_cmcc@outlook.com 725 Jie Dong 726 Huawei Technologies 727 Huawei Campus, No. 156 Beiqing Rd. 728 Beijing 100095 729 China 731 Email: jie.dong@huawei.com