RFC 8549

Export of BGP Community Information in IP Flow Information Export (IPFIX)

📅 published April 2019, from ietf

RFC 8549: Export of BGP Community Information in IP Flow Information Export (IPFIX) 🦋

okay bestie, this one is a Standards Track doc from the IETF, ISSN 2070-1721, dated April 2019 📅. The authors are Z. Li and R. Gu from China Mobile, plus J. Dong from Huawei Technologies 🫶. The title block doesn't list anything it obsoletes or updates, but the body says it does not update the IPFIX spec [RFC7011] or the information model [RFC7012] 💅.

Abstract 💖

so basically, this doc adds new Information Elements (IEs) that extend the existing BGP-related ones, so IPFIX can export BGP community info ✨. That covers the BGP Standard Communities from RFC 1997, the BGP Extended Communities from RFC 4360, and the BGP Large Communities from RFC 8092 💜. With the operator's BGP community planning, traffic info can get piled up and analyzed at the community level, which means you can see traffic from different kinds of customers, services, or geographical regions 🌍. Traffic info at that granularity is super useful for traffic analysis and engineering, obsessed 😭.

Status of This Memo 📜

this is an Internet Standards Track document 🔥.

it's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community 🫶. it got public review and was approved for publication by the Internet Engineering Steering Group (IESG) ✅. for more on Internet Standards, check Section 2 of RFC 7841 🔍.

for the current status, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc8549 🌸.

Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. 🎀

this document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as in effect on the date of publication. please read these carefully, because they spell out your rights and restrictions for this document 🧾. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License 💜.

Table of Contents 🗂️

1. Introduction ....................................................3
2. Terminology .....................................................5
3. Traffic Collection Based on BGP Community .......................6
4. IEs for BGP Standard Community ..................................7
5. IEs for BGP Extended Community ..................................8
6. IEs for BGP Large Community .....................................8
7. Operational Considerations ......................................9
8. Security Considerations ........................................10
9. IANA Considerations ............................................11
10. References ....................................................13
   10.1. Normative References .....................................13
   10.2. Informative References ...................................14
Appendix A.  Encoding Example .....................................16
  A.1.  Template Record ...........................................16
  A.2.  Data Set ..................................................17
Acknowledgements ..................................................18
Authors' Addresses ................................................18

1. Introduction ✨

okay so IPFIX [RFC7011] gives network admins traffic flow info using the IEs defined in the "IPFIX Information Elements" registry [IANA-IPFIX] 📊. with that flow info, admins can tell how much traffic there is and which direction it's going, and then tune the network when needed 🔧. for example, the collected info can be used for traffic monitoring and, optionally, for traffic optimization based on the operator's policy 💅.

the "IPFIX Information Elements" registry [IANA-IPFIX] defines these IEs for flow info at different granularities: sourceIPv4Address, sourceIPv4Prefix, destinationIPv4Address, destinationIPv4Prefix, bgpSourceAsNumber, bgpDestinationAsNumber, bgpNextHopIPv4Address, etc. 📋. but ngl, flow info built on those might not be totally suitable or enough, especially when traffic engineering and optimization happen in Tier 1 or Tier 2 operators' backbone networks 🙈. like, IP address or IP prefix can be way too fine-grained for a big network 🔍, while flow info based on the Autonomous System Number (ASN) can be too coarse 🥲.

BGP community is a BGP path attribute that covers Standard Communities [RFC1997], Extended Communities [RFC4360], and Large Communities [RFC8092] 🌈. it has a bunch of use cases, and one of the big ones is using BGP community with planned specific values to represent groups of customers, services, and geographical or topological regions, which operators do in their networks 🗺️. you can find detailed examples in [RFC4384], [RFC8195], and Section 3 of this document 📖. to understand the traffic generated 1) by different kinds of customers, 2) from different geographical or topological regions, or 3) by different kinds of customers from different regions, we need the community info that matches the traffic flow info exported by IPFIX 🧩. network traffic stats at the BGP community granularity aren't just good for traffic analysis, they're also useful for other apps, like traffic optimization apps living in an IPFIX Collector, a Software-Defined Networking (SDN) controller, or a PCE 🧚. [COMMUNITY-TE] also says analyzing traffic at the BGP community granularity is preferred for inbound traffic engineering 💜. the problem is that the "IPFIX Information Elements" registry [IANA-IPFIX] didn't have any IEs for the BGP community attribute 😭.

flow info based on the BGP community attribute can be collected by an IPFIX Mediator (defined in [RFC6183]) 🦋. the Mediator is responsible for correlating flow info with the BGP community attribute 🔗. but no IEs are defined in [RFC6183] for exporting BGP community info in IPFIX 💀. and to correlate the BGP community attribute with the flow info, the Mediator has to learn BGP routes and do lookups in the BGP routing table to find the matching entry for a specific flow 🫠. BGP route learning and routing table lookup are not trivial for an IPFIX Mediator 🙈. the Mediator was mainly introduced to reduce the performance requirement for the Exporter [RFC5982] 🌸. but honestly, to get info for the already-defined BGP-related IEs, like bgpSourceAsNumber, bgpDestinationAsNumber, and bgpNextHopIPv4Address, etc., the Exporter already has to hold an up-to-date BGP routing table and do lookups in it 🧠. so the Exporter can get the BGP community info in that same procedure, which means the extra load from exporting community info is minimal if the Exporter is already exporting the existing BGP-related IEs ✨. It is RECOMMENDED that the BGP community information be exported by the Exporter directly using IPFIX. 👑

by running BGP [RFC4271] or the BGP Monitoring Protocol (BMP) [RFC7854], and doing routing table lookups to match a specific flow, IPFIX Collectors and other apps (like an SDN controller or PCE) can figure out network traffic at the BGP community granularity 🔍. however, running BGP or BMP and doing routing table lookups aren't trivial for IPFIX Collectors and other apps either 😩. plus, correlating IPFIX flow info with the BGP RIB on the Exporter (such as a router) is more accurate than doing it on a Collector, since the BGP routing table might get updated while the Collectors and other apps are receiving the IPFIX flow info ⏱️. the Exporter can grab the BGP community info during the same procedure where it grabs other BGP-related info, so exporting the BGP community info straight from the Exporter to the Collector is both efficient and accurate 🎯. if Collectors and other apps only want traffic at the BGP community granularity, they don't need to run full BGP or BMP protocols when IPFIX can provide the BGP community info 🙌. BMP does have its own application scenario though, and the mechanism in this document is not meant to replace it 🫶.

by introducing new IEs, this document extends the existing BGP-related IEs so that IPFIX [RFC7011] can export BGP community info, including the BGP Standard Communities [RFC1997], BGP Extended Communities [RFC4360], and BGP Large Communities [RFC8092] 🌈. flow info (including packetDeltaCount [RFC7011] [RFC7012], octetDeltaCount [RFC7011] [RFC7012], etc.) can then be accumulated and analyzed by the Collector or other apps, like an SDN controller or PCE [RFC4655], at the BGP community granularity 📈. this is useful for measuring the traffic generated 1) by different kinds of customers or 2) from different geographical or topological regions, according to the operator's BGP community plan 🗺️. the flow info can then be used by traffic engineering or traffic optimization apps, especially in the backbone network 👑.

the IEs introduced here apply to both IPv4 and IPv6 traffic 💖. both the Exporter and the IPFIX Mediator can use these IEs to export BGP community info in IPFIX 🦋. when needed, the IPFIX Mediator or Collector can use these IEs to report BGP community-related flow info it gets either from Exporters or through local correlation with other IPFIX devices 🔗.

as mentioned above, the method in this document is not the sole, definitive way to get BGP community info related to a specific traffic flow. it is, however, possible, efficient, and accurate 💅.

no new BGP community attributes are defined in this document 🚫.

note that this document does not update the IPFIX specification [RFC7011] or information model [RFC7012] 🙅. instead, the "IPFIX Information Elements" registry [IANA-IPFIX] holds the current complete reference for IPFIX Information Elements, per Section 1 of [RFC7012] 📚.

please refer to the "IPFIX Information Elements" registry [IANA-IPFIX] for the complete list of BGP-related IEs 🗂️.

please refer to Appendix A of this document for the encoding example, and Section 3 for a detailed use case 🎀.

2. Terminology ✨

okay bestie, let's get the vocab sorted first 💅 the big requirement words are MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL 🎀 they only count as BCP 14 key words [RFC2119] [RFC8174] when they show up in ALL CAPS, exactly like that 🔥 lowercase "should" is just vibes, not a rule 🙈

the IPFIX-specific terms are defined in Section 2 of [RFC7011] and Section 2 of [RFC6183] 🦋 go read those if you want the official definitions 📚

and this doc uses "BGP Standard Community" to mean the BGP community attribute from [RFC1997] 💜 we call it that so nobody mixes it up with BGP Extended Community [RFC4360] or Large Community [RFC8092] 🫶 three different things, no cap 😭

3. Traffic Collection Based on BGP Community 🌈

okay so [RFC4384] introduced the idea of using BGP Standard and Extended Communities to collect geographical and topological info in the BGP routing system 🗺️ and [RFC8195] gives examples of BGP Large Communities representing geographic regions 🌸 it's giving organized 💅

why does any of this matter? well, traffic measured at the BGP community level shows you either 1) which kinds of customers are generating it, or 2) which geographic regions it's coming from, based on the operator's community plan 📊 so operators can analyze and optimize traffic between different customers and regions ✨ this section shows a use case where the operator uses BGP-community traffic data to adjust network paths for different flows 🦋

here's the setup 👑 Autonomous System (AS) C provides a transit connection between ASes A and B 🛣️ the operator tags routes with different BGP communities, sorting AS A and AS B routes into groups 🏷️ communities A:X and A:Y are used for routes that started in different geographic regions inside AS A 🌍 and B:M and B:N represent different kinds of customers in AS B (B:M is mobile customers, B:N is fixed line customers) 📱

by default, all traffic from AS A going to AS B (that's traffic A-B) takes path C1-C2-C3 (Path-1) through AS C 🛤️ but when the link between C1 and C2 gets congested, we can't just move all of traffic A-B onto Path C1-C4-C3 (Path-2) 😬 because then Path-2 gets congested 💀

                                +----------+
                                | PCE/SDN  |
                        +-------|Controller|-------+
                        |       +----------+       |
                        |                          |
                        |           AS C           |
                |       |       +----------+       |       |
                |       |   +---|Router C2 |---+   |       |
                |       |   |   +----------+   |   |       |
       AS A     |       |   |100             50|   |       |     AS B
    +--------+  |  +---------+                +---------+  |  +--------+
    |Router A|--|--|Router C1|                |Router C3|--|--|Router B|
    +--------+  |  +---------+                +---------+  |  +--------+
    Community:  |           |100            100|           |  Community:
        A:X     |           |   +----------+   |           |     B:M
        A:Y     |           +---|Router C4 |---+           |     B:N
                                +----------+

            Figure 1: Traffic Collection Based on BGP Community

so if the PCE/SDN controller in AS C can get traffic info at the BGP community level, it can steer some traffic tied to certain communities (just the source or destination) or certain community pairs (source AND destination) from Path-1 to Path-2 🎯 based on how busy each path is 📈 for example, it can move the traffic from community A:X off Path-1 by setting a route policy at Router C1 💅 or move traffic from A:Y to B:M from Path-1 to Path-2 🦋

the IEs defined in this doc let IPFIX export the BGP community info for a specific flow along with the rest of the flow info 📦 then that traffic info gets added up at the BGP community level and the PCE/SDN controller uses it to steer the right traffic from Path-1 to Path-2 🚀 slay 👑

4. IEs for BGP Standard Community 💖

[RFC1997] defines the BGP community attribute (called "BGP Standard Community" in this doc) 🎀 it describes a group of routes that share some common properties 🌸 and per [RFC1997], BGP Standard Community is treated as a 32-bit value 🔢

so to export BGP Standard Community info alongside the other flow info IPFIX defines, this doc introduces three new IEs 🧚

  • bgpCommunity 💜 used to identify that the value in this IE is a BGP Standard Community
  • bgpSourceCommunityList 🌈 a basicList [RFC6313] of bgpCommunity, used to export BGP Standard Community info corresponding to a specific flow's source IP address
  • bgpDestinationCommunityList 🦋 a basicList [RFC6313] of bgpCommunity, used to export BGP Standard Community info corresponding to a specific flow's destination IP address

see Section 9 ("IANA Considerations") for the full details on these three new IEs 📚

5. IEs for BGP Extended Community 🫧

[RFC4360] defines the BGP Extended Communities attribute, which gives you a way to label the info carried in BGP 🏷️ each Extended Community is encoded as an 8-octet quantity in the format defined in [RFC4360] 🔢

to export BGP Extended Community info with the other flow info via IPFIX, this doc introduces three new IEs 💅

  • bgpExtendedCommunity 💜 used to identify that the value in this IE is a BGP Extended Community
  • bgpSourceExtendedCommunityList 🌸 a basicList [RFC6313] of bgpExtendedCommunity, used to export the BGP Extended Community info corresponding to a specific flow's source IP address
  • bgpDestinationExtendedCommunityList 🦋 a basicList [RFC6313] of bgpExtendedCommunity, used to export the BGP Extended Community info corresponding to a specific flow's destination IP address

see Section 9 ("IANA Considerations") for the full details on these three new IEs ✨

6. IEs for BGP Large Community 🌈

[RFC8092] defines the BGP Large Communities attribute, and it's suitable for use with all Autonomous System Numbers (ASNs), including 4-octet ASNs 🌍 each BGP Large Community is encoded as a 12-octet quantity in the format defined in [RFC8092] 🔢 big energy 👑

to export BGP Large Community info with the other flow info via IPFIX, this doc introduces three new IEs 🎀

  • bgpLargeCommunity 💜 used to identify that the value in this IE is a BGP Large Community
  • bgpSourceLargeCommunityList 🌸 a basicList [RFC6313] of bgpLargeCommunity, used to export the BGP Large Community info corresponding to a specific flow's source IP address
  • bgpDestinationLargeCommunityList 🦋 a basicList [RFC6313] of bgpLargeCommunity, used to export the BGP Large Community info corresponding to a specific flow's destination IP address

see Section 9 ("IANA Considerations") for the full details on these three new IEs 🫶

7. Operational Considerations 🧚

okay this part is the practical stuff, so pay attention bestie 🙈

the max length of an IPFIX message is 65535 bytes per [RFC7011] 📏 and the max length of a normal BGP message is 4096 bytes per [RFC4271] 📏 BGP communities (Standard, Extended, and Large) are BGP path attributes carried in BGP Update messages, so all of those attributes together cannot exceed the length of a BGP message, which is 4096 bytes 🔢 that means one IPFIX message with a max length of 65535 bytes has enough room to fit all the communities for a specific flow's source and destination IP addresses 🎉 it's giving plenty of space 💖

now, [EXT-MSG] extends the max size of a BGP Update message to 65535 bytes 📈 in that case, the BGP community info for one flow could theoretically go over the length of one IPFIX message 😳 but according to real network info from the field, the number of BGP communities in one BGP route is usually no more than ten 🔟 still, BGP speakers that support the extended message SHOULD only convey as many communities as they can without going over the 65535-byte IPFIX limit 🫧 and the Collector, which gets an IPFIX message at max length with BGP communities in its data set, SHOULD generate a warning or log message to say the BGP communities may have been truncated because of limited message space 🚨 in this case, it is recommended that the export policy of BGP communities be configured to limit them by including or excluding specific communities 💅

if needed, the IPFIX message length can be extended from 16 bits to 32 bits to fully solve this problem 🔧 but details on increasing the IPFIX message length are out of scope for this doc 🙅‍♀️

to line up with the sizes of the BGP Extended Community and Large Community attributes, bgpExtendedCommunity and bgpLargeCommunity are 8 octets and 12 octets respectively 📐 if the bgpExtendedCommunity or bgpLargeCommunity IE isn't the expected size, the IPFIX Collector SHOULD ignore it 🙈 this is meant to protect implementations that use BGP logic from calling their parsing routines with invalid lengths 🛡️

last one! to properly process the Exporter when it receives the template asking it to report BGP community info (see Appendix A for an example) 📝 the Exporter SHOULD get the matching BGP community info through a BGP lookup using the matching source or destination IP address of the specific traffic flow 🔍 and when it exports the IPFIX info to the Collector, the Exporter SHOULD include the corresponding BGP communities in the IPFIX message 🦋 bestie you did it 😭🫶

8. Security Considerations 🔐✨

okay so bestie, this section is SERIOUS but make it cute 🎀. This document defines new IEs for IPFIX 🦋. The exact same security considerations as the IPFIX protocol specification [RFC7011] and information model [RFC7012] apply, so go read those too 💅.

Okay now the spicy part 🌶️. Systems that process BGP community information collected by IPFIX Collectors need to be aware that communities can be used as an attack vector [WEAPONIZING-BGP] 💀. So they should only use the community info in decisions where they're confident it's valid 🙈. Basically, we cannot assume all BGP community information collected by IPFIX Collectors is credible and accurate. It is RECOMMENDED to only use the IPFIX-collected BGP community information that the processing system can trust 🫶. For example, the BGP communities generated by the consecutive neighboring ASes inside the same trust domain as the processing system, meaning the consecutive neighboring ASes and the processing system are operated by one carrier 🍓.

Next up, privacy 🔒. [RFC7011] notes that the storage of information collected by IPFIX must be protected, and its visibility must be confined to authorized users through both technical and policy means, so the privacy of the information stays safe 🌸. [RFC7011] also gives you mechanisms to keep IPFIX data confidential and integral as it moves from an Exporting Process to a Collecting Process 🔐. It also covers how to authenticate IPFIX Collecting and Exporting Processes ✨. If the community information contains sensitive information, the above recommendations and mechanisms are recommended 💜. Good news though: this document doesn't introduce any additional privacy risks 🧚.

9. IANA Considerations 🦋

This document specifies IPFIX IEs so that BGP community information can be exported along with other flow information 🌈. IANA has assigned the following ElementIDs for these IEs in the "IPFIX Information Elements" registry [IANA-IPFIX] 👑:

----------------------------------------------------------------------
|ElementID|            Name           |Abstract    |    Data Type    |
|         |                           |Data Type   |    Semantics    |
|--------------------------------------------------------------------|
|   483   |        bgpCommunity       |unsigned32  |     identifier  |
|--------------------------------------------------------------------|
|   484   |  bgpSourceCommunityList   | basicList  |        list     |
|--------------------------------------------------------------------|
|   485   |bgpDestinationCommunityList| basicList  |        list     |
|--------------------------------------------------------------------|
|   486   |     bgpExtendedCommunity  |octetArray  |       default   |
|--------------------------------------------------------------------|
|   487   |      bgpSourceExtended    |            |                 |
|         |        CommunityList      | basicList  |        list     |
|--------------------------------------------------------------------|
|   488   |  bgpDestinationExtended   |            |                 |
|         |       CommunityList       | basicList  |        list     |
|--------------------------------------------------------------------|
|   489   |     bgpLargeCommunity     |octetArray  |       default   |
|--------------------------------------------------------------------|
|   490   |bgpSourceLargeCommunityList| basicList  |        list     |
|--------------------------------------------------------------------|
|   491   |    bgpDestinationLarge    |            |                 |
|         |       CommunityList       | basicList  |        list     |
|--------------------------------------------------------------------|
----------------------------------------------------------
|ElementID|                 Description                  |
|---------------------------------------------------------
|   483   |    BGP community as defined in [RFC1997]     |
|---------------------------------------------------------
|         |  basicList of zero or more bgpCommunity IEs, |
|   484   |  containing the BGP communities corresponding|
|         |  with source IP address of a specific flow   |
|---------------------------------------------------------
|         |  basicList of zero or more bgpCommunity IEs, |
|   485   |containing the BGP communities corresponding  |
|         |with destination IP address of a specific flow|
|---------------------------------------------------------
|   486   |BGP Extended Community as defined in RFC 4360;|
|         |the size of this IE MUST be 8 octets          |
|---------------------------------------------------------
|         |basicList of zero or more bgpExtendedCommunity|
|   487   |IEs, containing the BGP Extended Communities  |
|         |corresponding with source IP address of       |
|         |               a specific flow                |
|---------------------------------------------------------
|         |basicList of zero or more bgpExtendedCommunity|
|   488   |IEs, containing the BGP Extended Communities  |
|         |  corresponding with destination IP address   |
|         |              of a specific flow              |
|---------------------------------------------------------
|   489   | BGP Large Community as defined in [RFC8092]; |
|         | the size of this IE MUST be 12 octets        |
|---------------------------------------------------------
|         |  basicList of zero or more bgpLargeCommunity |
|         |  IEs, containing the BGP Large Communities   |
|   490   |    corresponding with source IP address      |
|         |             of a specific flow               |
|---------------------------------------------------------
|         |  basicList of zero or more bgpLargeCommunity |
|         |  IEs, containing the BGP Large Communities   |
|   491   |   corresponding with destination IP address  |
|         |              of a specific flow              |
|---------------------------------------------------------
----------------------------------------------------------
|ElementID|    References        | Requester  | Revision |
|---------------------------------------------------------
|   483   |    RFC 1997          | RFC 8549   |    0     |
|---------------------------------------------------------
|   484   |  RFC 6313, RFC 1997  | RFC 8549   |    0     |
|---------------------------------------------------------
|   485   |  RFC 6313, RFC 1997  | RFC 8549   |    0     |
|---------------------------------------------------------
|   486   |     RFC 4360         | RFC 8549   |    0     |
|---------------------------------------------------------
|   487   |  RFC 6313, RFC 4360  | RFC 8549   |    0     |
|---------------------------------------------------------
|   488   |  RFC 6313, RFC 4360  | RFC 8549   |    0     |
|---------------------------------------------------------
|   489   |      RFC 8092        | RFC 8549   |    0     |
|---------------------------------------------------------
|   490   |  RFC 6313, RFC 8092  | RFC 8549   |    0     |
|---------------------------------------------------------
|   491   |  RFC 6313, RFC 8092  | RFC 8549   |    0     |
|---------------------------------------------------------

Figure 2: Updates to "IPFIX Information Elements" Registry 🍭

10. References 📚

10.1. Normative References 💖

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119,
           DOI 10.17487/RFC2119, March 1997,
           <https://www.rfc-editor.org/info/rfc2119>.

[RFC6313]  Claise, B., Dhandapani, G., Aitken, P., and S. Yates,
           "Export of Structured Data in IP Flow Information Export
           (IPFIX)", RFC 6313, DOI 10.17487/RFC6313, July 2011,
           <https://www.rfc-editor.org/info/rfc6313>.

[RFC7011]  Claise, B., Ed., Trammell, B., Ed., and P. Aitken,
           "Specification of the IP Flow Information Export (IPFIX)
           Protocol for the Exchange of Flow Information", STD 77,
           RFC 7011, DOI 10.17487/RFC7011, September 2013,
           <https://www.rfc-editor.org/info/rfc7011>.

[RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
           2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
           May 2017, <https://www.rfc-editor.org/info/rfc8174>.

10.2. Informative References 📚

okay so these are the extra reads that aren't required to implement this, but they're the receipts behind the ideas 💅

Appendix A. Encoding Example 🧚

okay bestie, this is the worked example 🎀 It shows exactly how the newly introduced IEs get encoded, so you can see the whole thing in action.

Here's the flow info, BGP communities included, in the table below. Every field in this example gets reported by IPFIX ✨

----------------------------------------------------------------------
|  Source |Destination|    BGP community       |    BGP community    |
|   IP    |    IP     |  corresponding with    | corresponding with  |
|         |           |      Source IP         |   Destination IP    |
----------------------------------------------------------------------
| 1.1.1.1 |  2.2.2.2  | 1:1001, 1:1002, 8:1001 |   2:1002, 8:1001    |
----------------------------------------------------------------------
| 3.3.3.3 |  4.4.4.4  | 3:1001, 3:1002, 8:1001 |   4:1001, 8:1001    |
----------------------------------------------------------------------

         Figure 3: Flow Information Including BGP Communities

A.1. Template Record 🌸

here's the template record, the blueprint that the data records will follow 💖

    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          SET ID = 2           |       Length = 24             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Template ID = 256        |        Field Count = 4        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|    SourceIPv4Address = 8    |        Field Length = 4       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0| DestinationIPv4Address = 12 |        Field Length = 4       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0| bgpSourceCommunityList=484  |      Field Length = 0xFFFF    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0| bgpDestinationCommunityList |      Field Length = 0xFFFF    |
   | |          = 485              |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 4: Template Record Encoding Format

In this example, the Template ID is 256, and that's the number the Data Record will use. The field length for bgpSourceCommunityList and bgpDestinationCommunityList is 0xFFFF, which means the length of each of these IEs is variable. The actual length gets carried in the List Length field of the basicList format, as per [RFC6313] ✨

A.2. Data Set 💜

and now the data set itself, all filled in 🦋

    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         SET ID = 256          |           Length = 92         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  SourceIPv4Address = 1.1.1.1                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               DestinationIPv4Address = 2.2.2.2                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      255      |        List Length = 17       |semantic=allof |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      bgpCommunity = 483       |         Field Length = 4      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        BGP Source Community Value 1 = 1:1001                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        BGP Source Community Value 2 = 1:1002                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        BGP Source Community Value 3 = 8:1001                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     255       |        List Length = 13       |semantic=allof |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      bgpCommunity = 483       |         Field Length = 4      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         BGP Destination Community Value 1 = 2:1002            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         BGP Destination Community Value 2 = 8:1001            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  SourceIPv4Address = 3.3.3.3                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               DestinationIPv4Address = 4.4.4.4                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     255       |        List Length = 17       | semantic=allof|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      bgpCommunity = 483       |         Field Length = 4      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        BGP Source Community Value 1 = 3:1001                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        BGP Source Community Value 2 = 3:1002                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        BGP Source Community Value 3 = 8:1001                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     255       |        List Length = 13       | semantic=allof|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      bgpCommunity = 483       |         Field Length = 4      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         BGP Destination Community Value 1 = 4:1001            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         BGP Destination Community Value 2 = 8:1001            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 5: Data Set Encoding Format

Acknowledgements 🫶

the authors want to give a huge thank you to Benoit Claise and Paul Aitken for their comments and suggestions that helped get this document going 💖 they also want to thank Tianran Zhou, Warren Kumari, Jeffrey Haas, Ignas Bagdonas, Stewart Bryant, Paolo Lucente, Job Snijders, Jared Mauch, Rudiger Volk, and Andrew Malis for their discussion, comments, and suggestions that made this document better ✨

Authors' Addresses 🌈

Zhenqiang Li
China Mobile
32 Xuanwumen West Ave, Xicheng District
Beijing  100053
China

Email: li_zhenqiang@hotmail.com


Rong Gu
China Mobile
32 Xuanwumen West Ave, Xicheng District
Beijing  100053
China

Email: gurong_cmcc@outlook.com


Jie Dong
Huawei Technologies
Huawei Campus, No. 156 Beiqing Rd.
Beijing  100095
China

Email: jie.dong@huawei.com
📦 where this page comes from