idnits 2.17.1 draft-mvmd-opsawg-ipfix-fwd-exceptions-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 26, 2021) is 1185 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IP Flow Information Export C. Munukutla 3 Internet-Draft S. Vaid 4 Intended status: Standards Track Juniper Networks, Inc. 5 Expires: July 30, 2021 A. Mahale 6 D. Patel 7 Google, Inc. 8 January 26, 2021 10 IP Flow Information Export (IPFIX) Information Elements Extension for 11 Forwarding Exceptions 12 draft-mvmd-opsawg-ipfix-fwd-exceptions-01 14 Abstract 16 This draft proposes couple of new Forwarding exceptions related 17 Information Elements (IEs) and Templates for the IP Flow Information 18 Export (IPFIX) protocol. These new Information Elements and 19 Exception Template can be used to export information about any 20 forwarding errors in a network. This essential information is 21 adequate to correlate packet drops to any control plane entity and 22 map it to an impacted service. Once exceptions are correlated to a 23 particular entity, an action can be assigned to mitigate such 24 problems essentially enabling self-driving networks. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on July 30, 2021. 43 Copyright Notice 45 Copyright (c) 2021 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 63 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3. Information Elements . . . . . . . . . . . . . . . . . . . . 4 65 4. New Information Elements . . . . . . . . . . . . . . . . . . 6 66 4.1. Proposed New Information Elements . . . . . . . . . . . . 6 67 4.2. Definition of Exceptions . . . . . . . . . . . . . . . . 6 68 4.2.1. forwardingExceptionCode . . . . . . . . . . . . . . . 6 69 4.2.2. forwardingNexthopId . . . . . . . . . . . . . . . . . 7 70 5. Exception Templates . . . . . . . . . . . . . . . . . . . . . 8 71 5.1. IPFIX Exception Template 1 for Forwarding Exceptions . . 8 72 5.2. IPFIX Exception Template 2 for Forwarding Exceptions . . 9 73 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 74 6.1. Information Elements . . . . . . . . . . . . . . . . . . 10 75 6.2. Forwarding Exception Codes . . . . . . . . . . . . . . . 11 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 77 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11 78 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 79 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 80 9.2. Informative References . . . . . . . . . . . . . . . . . 12 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 83 1. Introduction 85 All networks are susceptible to traffic drops due to a number of 86 factors. Traffic drops can go unnoticed unless they are service 87 impacting. In a multi-layered network architecture, it is tedious 88 manual work to localize and root cause traffic blackholing issues. 89 Transient drops are even harder to detect. Existing methodologies 90 that rely on periodically monitoring interfaces on several hosts in a 91 network does not guarantee timely detection, and are not scalable for 92 large networks. 94 In order to eliminate this tedious monitoring work-flow, objective is 95 to simplify localization and build correlation of dropped packets to 96 particular entity. The network entity shall identify the dropped 97 packets by monitoring dropped counters or doing a deep packet 98 inspection of the packet discarded by the forwarding ASIC. The 99 implementation of the method used to detect the drop is outside the 100 scope of this document. Dropped packets will be sampled in the 101 forwarding-path and sent to a host or software queue along with type 102 of exception, in/out interface information and other relevant meta 103 data. This will be a push model where the node encountering the 104 error will emit the information about dropped packets and associated 105 meta-data. Techniques for IP Packet Selection [RFC5475] describes 106 Sampling and Filtering techniques for IP packet selection either 107 using Systematic Sampling or Random Sampling. 109 The IPFIX Protocol Specification [RFC7011] defines a generic exchange 110 mechanism for collecting flow information. It supports source- 111 triggered export of information via the push model approach. The 112 IPFIX Information Model [IANA-IPFIX] defines a list of standard 113 Information Elements (IEs) which can be carried by the IPFIX 114 protocol. 116 This document focuses on telemetry information for dropped packet 117 exceptions, and proposes an extension to IPFIX message format for 118 collecting sampled exceptions. Some of the IPFIX Information 119 Elements (IEs) already exist, some will be defined along with 120 corresponding formats. It is also possible to achieve sampling of 121 the dropped packets by using sampling methods like SFLOW but details 122 of other sampling methods are outside the scope of this document. 124 1.1. Terminology 126 IPFIX-specific terminology (e.g. Information Element, Template, 127 Template Record, Options Template Record, Template Set, Collector, 128 Exporter, Data Record) used in this document is defined in Section 2 129 of [RFC7011]. As in [RFC7011] these IPFIX-specific terms have the 130 first letter of a word capitalized. This document also makes use of 131 the same terminology and definitions as Section 2 of [RFC5470]. 133 1.2. Requirements Language 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 137 "OPTIONAL" in this document are to be interpreted as described in BCP 138 14 [RFC2119] [RFC8174] when, and only when, they appear in all 139 capitals, as shown here. 141 2. Scope 143 This document specifies the information model used for reporting 144 packet-based forwarding exceptions. [RFC7011] provides guidance on 145 the choices of the transport protocols used for IPFIX and their 146 effects. Encoded IPFIX exception packets need to be reliably 147 transported to the collector. The choice of the actual transport 148 protocol is beyond the scope of this document. 150 This document assumes that all devices reporting exceptions will use 151 existing IPFIX framework/module to send encoded packets to the 152 collector. This would mean that the network device will specify the 153 template that it is going to use for each of the events. The 154 templates can be of varying length, and there could be multiple 155 templates that a network device could use to encode the exceptions. 157 The implementation details of the collector application are beyond 158 the scope of this document. 160 3. Information Elements 162 The Exception template could contain a subset of the IEs shown in 163 Table 1, depending upon the exception reported. 165 Whenever packet drop happens inside forwarding plane, following 166 information is key to understanding the issue: reason for packet 167 drop, flow which encountered the drop (packet content), additional 168 meta-data e.g. flow direction (ingress/egress), nexthop index, input 169 interface, output interface, etc. on which this packet was flowing. 171 The following table includes all the existing IEs that a device 172 reporting IPFIX Exceptions using Exception Template would typically 173 need. The formats of IEs and IPFIX IDs are listed in the table 174 below. 176 +-------------------------------+--------+-------+--------------+ 177 | Field Name | Size | IANA | Description | 178 | | (bits) | IPFIX | | 179 | | | ID | | 180 +-------------------------------+--------+-------+--------------+ 181 | flowDirection | 8 | 61 | The direction| 182 | | | | of the Flow | 183 | | | | observed at | 184 | | | | Observation | 185 | | | | point. | 186 | | | | | 187 | ingressInterface | 32 | 10 | Index of IP | 188 | | | | interface | 189 | | | | where packets| 190 | | | | of this flow | 191 | | | | are being | 192 | | | | received. | 193 | | | | | 194 | egressInterface | 32 | 14 | Index of IP | 195 | | | | interface | 196 | | | | where packets| 197 | | | | of this flow | 198 | | | | are being | 199 | | | | sent. | 200 | | | | | 201 | dataLinkFrameSize | 16 | 312 | Specified | 202 | | | | length of | 203 | | | | data link | 204 | | | | frame. | 205 | | | | | 206 | dataLinkFrameSection | 65535 | 315 | Carries n | 207 | | | | octets from | 208 | | | | data link | 209 | | | | frame of | 210 | | | | selected | 211 | | | | frame. | 212 | commonPropertiesID | 64 | 137 | Identifier of| 213 | | | | a set of | 214 | | | | common | 215 | | | | properties | 216 | | | | that is | 217 | | | | unique per | 218 | | | | observation | 219 | | | | domain. | 220 +-------------------------------+--------+-------+--------------+ 221 Table 1: Forwarding Exception Information Elements 223 Information Elements 225 4. New Information Elements 227 4.1. Proposed New Information Elements 229 The proposed new IEs that a device reporting Exceptions using 230 Exception template would need are listed in Table 2 below. 232 +---------------------------+---------------------+-----------------+ 233 | Field Name | Abstract Data Type | Description | 234 | | | | 235 +---------------------------+---------------------+-----------------+ 236 | forwardingExceptionCode | unsigned32 | Unique code for | 237 | | | every exception | 238 | | | | 239 | forwardingNextHopID | unsigned64 | Forwarding NH - | 240 | | | index associated| 241 | | | with packet that| 242 | | | encountered | 243 | | | this exception | 244 +---------------------------+---------------------+-----------------+ 245 Table 2: New Information Elements 247 New Information Elements 249 The Information Elements defined in Table 2 are proposed to be 250 incorporated into the IANA IPFIX Information Elements registry 251 [IANA-IPFIX] 253 4.2. Definition of Exceptions 255 Every network will encounter issues like packet loss, from time to 256 time. Some of the causes for such a loss of traffic or a block in 257 transmission of data packets include overloaded system conditions, 258 misconfiguration, profiles and policies that restrict the bandwidth 259 or priority of traffic, network outages, or disruption with physical 260 cable faults. Packet loss could also happen because of incorrect 261 stitching of the forwarding path or a mismatch between control plane 262 and data plane state. Exception code entails the reason/error code 263 due to which this packet has been dropped. 265 4.2.1. forwardingExceptionCode 267 forwardingExceptionCode will be defined in "IPFIX Information 268 Elements" registry. This list can be expanded in the future as 269 necessary. The data record will have corresponding exception code 270 value to indicate forwarding error that caused the traffic drop. 272 An implementation may choose to encode device internal exception 273 codes as forwardingExceptionCode. In such scenarios, Enterprise Bit 274 MUST be set to 1 and corresponding Enterprise Number MUST be present 275 as described in [RFC7011] 277 There is an existing IE 89 - forwardingStatus [IANA-IPFIX] but it 278 allows a very limited number of exceptions to be reported from the 279 system (6-bit reason code). The exception codes also need to be 280 standardized for use. Different forwarding ASICs would have 281 different pipelines and hence discard reasons (which could be very 282 specific to that pipeline) cannot be generalized. Hence it makes 283 sense to have a standalone IE for reporting exception which not only 284 provides support to report larger number of exceptions but also 285 provides freedom for reporting application specific exceptions using 286 the enterprise bit. 288 A list of commonly used forwarding Exception codes will be identified 289 and listed as part of Table 3 below. 291 +----------------+--------------------------------------------------+ 292 | Forwarding | Reason | 293 | Exception Code | | 294 +----------------+--------------------------------------------------+ 295 | 1 | FIREWALL_DISCARD | 296 | 2 | TTL_EXPIRY | 297 | 3 | DISCARD_ROUTE | 298 | 4 | BAD_IPV4_CHECKSUM | 299 | 5 | REJECT_ROUTE | 300 | 6 | BAD_IPV4_HEADER (Version incorrect or IHL < 5)| 301 | 7 | BAD_IPV6_HEADER (Version incorrect) | 302 | 8 | BAD_IPV4_HEADER_LENGTH (V4 frame is too short) | 303 | 9 | BAD_IPV6_HEADER_LENGTH | 304 | 10 | BAD_IPV6_OPTIONS_PACKET(too many option headers) | 305 | .. | .. | 306 +----------------+--------------------------------------------------+ 308 Table 3: Exception Codes 310 4.2.2. forwardingNexthopId 312 In terms of a network device, next hop is the gateway to which packet 313 should be forwarded corresponding to the path to final destination. 314 A given router doesn't need to store the entire forwarding path 315 information for a destination. As long as it can identify the next 316 hop to be used for forwarding to a destination, the end to end 317 forwarding can happen. This helps reduce size of forwarding table. 318 The nexthop index uniquely identifies the egress path a packet would 319 take to reach the destination. This could include information about 320 the outgoing interface, layer 2 address to be used, forwarding 321 features configured for the packet path etc. 323 For instance, consider we have a L3VPN topology like below 325 CE1 -------- PE1 ----- MPLS Network ----- PE2 ------- CE2 327 Figure 1: MPLS VPN Network 329 Figure 1 above illustrates an example where reporting of exception 330 can provide an insight into the error scenario. CE1 and CE2 331 communicate with each other over an MPLS VPN network. The labels are 332 typically advertised using protocols like RSVP or LDP. When a packet 333 is received from core network on PE1, a lookup on MPLS label results 334 in packet getting forwarded towards CE1. The entries in MPLS table 335 are populated by corresponding protocol. If label entries don't get 336 populated in the MPLS table due to a probable glitch in the protocol 337 configuration or some inconsistency, the packets traversing on that 338 LSP shall get discarded on PE1. 340 Using the mechanism described in this RFC, it will be possible to 341 capture such packets and report them in IPFIX format with 342 corresponding exception set (eg. DISCARD_ROUTE) along with relevant 343 packet bytes and meta-data. This can help the operator/software to 344 immediately understand root cause of the problem and take appropriate 345 action. 347 An implementation may choose to report linecard and forwarding ASIC 348 information on which an exception occurs, but mechanism to export 349 these fields is out of the scope of this document. 351 5. Exception Templates 353 This section presents a list of templates for reporting exceptions 354 using newly proposed IEs in addition to few existing IEs. 356 5.1. IPFIX Exception Template 1 for Forwarding Exceptions 358 Exception Template defined in Figure 1 may be used to export 359 forwarding Exceptions. 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | Set ID = 2 | Length = N octets | 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | Template ID = 256 | Field Count = N | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 |0| forwardingExceptionCode | Field Length = 4 | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 |0| forwardingNextHopId | Field Length = 8 | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 |0| flowDirection | Field Length = 1 | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 |0| ingressInterface | Field Length = 4 | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 |0| egressInterface | Field Length = 4 | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 |0| dataLinkFrameSize | Field Length = 2 | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 |0| dataLinkFrameSection | Field Length = 65535 | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | Padding (opt) | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 IPFIX Exception Template for Forwarding Exceptions 385 5.2. IPFIX Exception Template 2 for Forwarding Exceptions 387 Alternatively, Exception Template defined in Figure 2 may be used. 388 This includes Information Element 137 to represent following fields: 389 forwardingNexthopId, ingressInterface, underlyingIngressInterface and 390 egressInterface. 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | Set ID = 2 | Length = N octets | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | Template ID = 256 | Field Count = N | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 |0| forwardingExceptionCode | Field Length = 4 | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 |0| flowDirection | Field Length = 1 | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 |0| commonPropertiesId1 | Field Length = 8 | 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 |0| commonPropertiesId2 | Field Length = 8 | 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 |0| commonPropertiesId3 | Field Length = 8 | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 |0| commonPropertiesId4 | Field Length = 8 | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 |0| dataLinkFrameSize | Field Length = 2 | 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 |0| dataLinkFrameSection | Field Length = 65535 | 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | Padding (opt) | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 IPFIX Exception Template 2 for Forwarding Exceptions 418 6. IANA Considerations 420 6.1. Information Elements 422 IANA manages the IPFIX Information Elements registry at [IANA-IPFIX]. 423 This document introduces two new IPFIX Information Elements. 425 Name: forwardingExceptionCode 426 ElementID: TBD 427 Description: Exception code is an identifier uniquely describing 428 cause of irregularity or traffic drop on a device. 429 Abstract Data Type: unsigned32 430 Data Type Semantics: identifier 432 Name: forwardingNexthopId 433 ElementID: TBD 434 Description: Nexthop ID is a unique identifier for a Nexthop on a 435 device. 436 Abstract Data Type: unsigned64 437 Data Type Semantics: identifier 439 6.2. Forwarding Exception Codes 441 This document requests addition of a new registry for Forwarding 442 Exception Codes. 444 +----------------+--------------------------------------------------+ 445 | Forwarding | Reason | 446 | Exception Code | | 447 +----------------+--------------------------------------------------+ 448 | 1 | FIREWALL_DISCARD | 449 | 2 | TTL_EXPIRY | 450 | 3 | DISCARD_ROUTE | 451 | 4 | BAD_IPV4_CHECKSUM | 452 | 5 | REJECT_ROUTE | 453 | 6 | BAD_IPV4_HEADER (Version incorrect or IHL < 5)| 454 | 7 | BAD_IPV6_HEADER (Version incorrect) | 455 | 8 | BAD_IPV4_HEADER_LENGTH (V4 frame is too short) | 456 | 9 | BAD_IPV6_HEADER_LENGTH | 457 | 10 | BAD_IPV6_OPTIONS_PACKET(too many option headers) | 458 | .. | .. | 459 +----------------+--------------------------------------------------+ 461 Table 3: Exception Codes 463 All assignments in this registry are to be performed via Expert 464 Review. 466 7. Security Considerations 468 Security Considerations listed in detail for IPFIX in [RFC7011] apply 469 to this document as well. As described in [RFC7011], the IPFIX 470 messages exchanged between network device and collector MUST be 471 protected to provide confidentiality, integrity, and authenticity. 472 Without those characteristics, the messages are subject to various 473 kinds of attacks. These attacks are described in great detail in 474 [RFC7011]. 476 8. Contributors 478 Manikandan Musuvathi Poornachary 479 Juniper Networks, Inc. 480 Electra Exora Business Park~Marathahalli-Sarjapur Outer Ring Road, 481 Bangalore, KA - 560103 482 India 483 Email: mpoornachary@juniper.net 484 Vishnu Pavan Beeram 485 Juniper Networks, Inc. 486 1133 Innovation Way 487 Sunnyvale, CA 94089 488 USA 489 Email: vbeeram@juniper.net 491 Raveendra Torvi 492 Juniper Networks, Inc. 493 10 Technology Park Dr 494 Westford, MA 01886 495 USA 496 Email: rtorvi@juniper.net 498 9. References 500 9.1. Normative References 502 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 503 Requirement Levels", BCP 14, RFC 2119, 504 DOI 10.17487/RFC2119, March 1997, 505 . 507 [RFC5475] Zseby, T., Molina, M., Duffield, N., Niccolini, S., and F. 508 Raspall, "Sampling and Filtering Techniques for IP Packet 509 Selection", RFC 5475, DOI 10.17487/RFC5475, March 2009, 510 . 512 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 513 "Specification of the IP Flow Information Export (IPFIX) 514 Protocol for the Exchange of Flow Information", STD 77, 515 RFC 7011, DOI 10.17487/RFC7011, September 2013, 516 . 518 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 519 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 520 May 2017, . 522 9.2. Informative References 524 [IANA-IPFIX] 525 IANA, "IP Flow Information Export (IPFIX) Entities", 526 . 528 [RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, 529 "Architecture for IP Flow Information Export", RFC 5470, 530 DOI 10.17487/RFC5470, March 2009, 531 . 533 Authors' Addresses 535 Venkata Naga Chaitanya Munukutla 536 Juniper Networks, Inc. 537 10 Technology Park Dr 538 Westford, MA 01886 539 USA 541 Email: vmunuku@juniper.net 543 Shivam Vaid 544 Juniper Networks, Inc. 545 Electra, Exora Business Park- Marathahalli-Sarjapur Outer Ring Road 546 Bangalore, Karnataka 560103 547 India 549 Email: shivamv@juniper.net 551 Aditya Mahale 552 Google, Inc. 553 1600 Amphitheatre Parkway 554 Mountain View, CA 94043 555 USA 557 Email: amahale@google.com 559 Devang Patel 560 Google, Inc. 561 1600 Amphitheatre Parkway 562 Mountain View, CA 94043 563 USA 565 Email: pateldevang@google.com