idnits 2.17.1 draft-mvmd-opsawg-ipfix-fwd-exceptions-00.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 (July 27, 2020) is 1341 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: January 28, 2021 A. Mahale 6 D. Patel 7 Google, Inc. 8 July 27, 2020 10 IP Flow Information Export (IPFIX) Information Elements Extension for 11 Forwarding Exceptions 12 draft-mvmd-opsawg-ipfix-fwd-exceptions-00 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 January 28, 2021. 43 Copyright Notice 45 Copyright (c) 2020 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 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 5. Exception Templates . . . . . . . . . . . . . . . . . . . . . 7 69 5.1. IPFIX Exception Template 1 for Forwarding Exceptions . . 7 70 5.2. IPFIX Exception Template 2 for Forwarding Exceptions . . 8 71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 72 6.1. Information Elements . . . . . . . . . . . . . . . . . . 9 73 6.2. Forwarding Exception Codes . . . . . . . . . . . . . . . 10 74 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 75 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 76 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 77 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 78 9.2. Informative References . . . . . . . . . . . . . . . . . 11 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 81 1. Introduction 83 All networks are susceptible to traffic drops due to a number of 84 factors. Traffic drops can go unnoticed unless they are service 85 impacting. In a multi-layered network architecture, it is tedious 86 manual work to localize and root cause traffic blackholing issues. 87 Transient drops are even harder to detect. Existing methodologies 88 that rely on periodically monitoring interfaces on several hosts in a 89 network does not guarantee timely detection, and are not scalable for 90 large networks. 92 In order to eliminate this tedious monitoring work-flow, objective is 93 to simplify localization and build correlation of dropped packets to 94 particular entity. The network entity shall identify the dropped 95 packets by monitoring dropped counters or doing a deep packet 96 inspection of the packet discarded by the forwarding ASIC. The 97 implementation of the method used to detect the drop is outside the 98 scope of this document. Dropped packets will be sampled in the 99 forwarding-path and sent to a host or software queue along with type 100 of exception, in/out interface information and other relevant meta 101 data. This will be a push model where the node encountering the 102 error will emit the information about dropped packets and associated 103 meta-data. Techniques for IP Packet Selection [RFC5475] describes 104 Sampling and Filtering techniques for IP packet selection either 105 using Systematic Sampling or Random Sampling. 107 The IPFIX Protocol Specification [RFC7011] defines a generic exchange 108 mechanism for collecting flow information. It supports source- 109 triggered export of information via the push model approach. The 110 IPFIX Information Model [IANA-IPFIX] defines a list of standard 111 Information Elements (IEs) which can be carried by the IPFIX 112 protocol. 114 This document focuses on telemetry information for dropped packet 115 exceptions, and proposes an extension to IPFIX message format for 116 collecting sampled exceptions. Some of the IPFIX Information 117 Elements (IEs) already exist, some will be defined along with 118 corresponding formats. It is also possible to achieve sampling of 119 the dropped packets by using sampling methods like SFLOW but details 120 of other sampling methods are outside the scope of this document. 122 1.1. Terminology 124 IPFIX-specific terminology (e.g. Information Element, Template, 125 Template Record, Options Template Record, Template Set, Collector, 126 Exporter, Data Record) used in this document is defined in Section 2 127 of [RFC7011]. As in [RFC7011] these IPFIX-specific terms have the 128 first letter of a word capitalized. This document also makes use of 129 the same terminology and definitions as Section 2 of [RFC5470]. 131 1.2. Requirements Language 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 135 "OPTIONAL" in this document are to be interpreted as described in BCP 136 14 [RFC2119] [RFC8174] when, and only when, they appear in all 137 capitals, as shown here. 139 2. Scope 141 This document specifies the information model used for reporting 142 packet-based forwarding exceptions. [RFC7011] provides guidance on 143 the choices of the transport protocols used for IPFIX and their 144 effects. Encoded IPFIX exception packets need to be reliably 145 transported to the collector. The choice of the actual transport 146 protocol is beyond the scope of this document. 148 This document assumes that all devices reporting exceptions will use 149 existing IPFIX framework/module to send encoded packets to the 150 collector. This would mean that the network device will specify the 151 template that it is going to use for each of the events. The 152 templates can be of varying length, and there could be multiple 153 templates that a network device could use to encode the exceptions. 155 The implementation details of the collector application are beyond 156 the scope of this document. 158 3. Information Elements 160 The Exception template could contain a subset of the IEs shown in 161 Table 1, depending upon the exception reported. 163 Whenever packet drop happens inside forwarding plane, following 164 information is key to understanding the issue: reason for packet 165 drop, flow which encountered the drop (packet content), additional 166 meta-data e.g. flow direction (ingress/egress), nexthop index, input 167 interface, output interface, etc. on which this packet was flowing. 169 The following table includes all the existing IEs that a device 170 reporting IPFIX Exceptions using Exception Template would typically 171 need. The formats of IEs and IPFIX IDs are listed in the table 172 below. 174 +-------------------------------+--------+-------+--------------+ 175 | Field Name | Size | IANA | Description | 176 | | (bits) | IPFIX | | 177 | | | ID | | 178 +-------------------------------+--------+-------+--------------+ 179 | flowDirection | 8 | 61 | The direction| 180 | | | | of the Flow | 181 | | | | observed at | 182 | | | | Observation | 183 | | | | point. | 184 | | | | | 185 | ingressInterface | 32 | 10 | Index of IP | 186 | | | | interface | 187 | | | | where packets| 188 | | | | of this flow | 189 | | | | are being | 190 | | | | received. | 191 | | | | | 192 | egressInterface | 32 | 14 | Index of IP | 193 | | | | interface | 194 | | | | where packets| 195 | | | | of this flow | 196 | | | | are being | 197 | | | | sent. | 198 | | | | | 199 | dataLinkFrameSize | 16 | 312 | Specified | 200 | | | | length of | 201 | | | | data link | 202 | | | | frame. | 203 | | | | | 204 | dataLinkFrameSection | 65535 | 315 | Carries n | 205 | | | | octets from | 206 | | | | data link | 207 | | | | frame of | 208 | | | | selected | 209 | | | | frame. | 210 | commonPropertiesID | 64 | 137 | Identifier of| 211 | | | | a set of | 212 | | | | common | 213 | | | | properties | 214 | | | | that is | 215 | | | | unique per | 216 | | | | observation | 217 | | | | domain. | 218 +-------------------------------+--------+-------+--------------+ 219 Table 1: Forwarding Exception Information Elements 221 Information Elements 223 4. New Information Elements 225 4.1. Proposed New Information Elements 227 The proposed new IEs that a device reporting Exceptions using 228 Exception template would need are listed in Table 2 below. 230 +---------------------------+---------------------+-----------------+ 231 | Field Name | Abstract Data Type | Description | 232 | | | | 233 +---------------------------+---------------------+-----------------+ 234 | forwardingExceptionCode | unsigned32 | Unique code for | 235 | | | every exception | 236 | | | | 237 | forwardingNextHopID | unsigned64 | Forwarding NH - | 238 | | | index associated| 239 | | | with packet that| 240 | | | encountered | 241 | | | this exception | 242 +---------------------------+---------------------+-----------------+ 243 Table 2: New Information Elements 245 New Information Elements 247 The Information Elements defined in Figure 1 are proposed to be 248 incorporated into the IANA IPFIX Information Elements registry 249 [IANA-IPFIX] 251 4.2. Definition of Exceptions 253 Every network will encounter issues like packet loss, from time to 254 time. Some of the causes for such a loss of traffic or a block in 255 transmission of data packets include overloaded system conditions, 256 misconfiguration, profiles and policies that restrict the bandwidth 257 or priority of traffic, network outages, or disruption with physical 258 cable faults. Packet loss could also happen because of incorrect 259 stitching of the forwarding path or a mismatch between control plane 260 and data plane state. Exception code entails the reason/error code 261 due to which this packet has been dropped. 263 forwardingExceptionCode will be defined in "IPFIX Information 264 Elements" registry. This list can be expanded in the future as 265 necessary. The data record will have corresponding exception code 266 value to indicate forwarding error that caused the traffic drop. 268 An implementation may choose to encode device internal exception 269 codes as forwardingExceptionCode. In such scenarios, Enterprise Bit 270 MUST be set to 1 and corresponding Enterprise Number MUST be present 271 as described in [RFC7011] 273 A list of commonly used forwarding Exception codes will be identified 274 and listed as part of Table 3 below. 276 +----------------+--------------------------------------------------+ 277 | Forwarding | Reason | 278 | Exception Code | | 279 +----------------+--------------------------------------------------+ 280 | 1 | FIREWALL_DISCARD | 281 | 2 | TTL_EXPIRY | 282 | 3 | DISCARD_ROUTE | 283 | 4 | BAD_IPV4_CHECKSUM | 284 | 5 | REJECT_ROUTE | 285 | 6 | BAD_IPV4_HEADER (Version incorrect or IHL < 5)| 286 | 7 | BAD_IPV6_HEADER (Version incorrect) | 287 | 8 | BAD_IPV4_HEADER_LENGTH (V4 frame is too short) | 288 | 9 | BAD_IPV6_HEADER_LENGTH | 289 | 10 | BAD_IPV6_OPTIONS_PACKET(too many option headers) | 290 | .. | .. | 291 +----------------+--------------------------------------------------+ 293 Table 3: Exception Codes 295 Reachability to any given destination inside the router is defined 296 using a next-hop which is typically represented in the forwarding 297 path as an index. The nexthop index uniquely identifies the egress 298 path a packet would take to reach the destination. This could 299 include information about the outgoing interface, forwarding features 300 configured for the packet path etc. 302 An implementation may choose to report linecard and forwarding ASIC 303 information on which an exception occurs, but mechanism to export 304 these fields is out of the scope of this document. 306 5. Exception Templates 308 This section presents a list of templates for reporting exceptions 309 using newly proposed IEs in addition to few existing IEs. 311 5.1. IPFIX Exception Template 1 for Forwarding Exceptions 313 Exception Template defined in Figure 1 may be used to export 314 forwarding Exceptions. 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | Set ID = 2 | Length = N octets | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | Template ID = 256 | Field Count = N | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 |0| forwardingExceptionCode | Field Length = 4 | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 |0| forwardingNextHopId | Field Length = 8 | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 |0| flowDirection | Field Length = 1 | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 |0| ingressInterface | Field Length = 4 | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 |0| egressInterface | Field Length = 4 | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 |0| dataLinkFrameSize | Field Length = 2 | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 |0| dataLinkFrameSection | Field Length = 65535 | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | Padding (opt) | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 IPFIX Exception Template for Forwarding Exceptions 340 5.2. IPFIX Exception Template 2 for Forwarding Exceptions 342 Alternatively, Exception Template defined in Figure 2 may be used. 343 This includes Information Element 137 to represent following fields: 344 forwardingNexthopId, ingressInterface, underlyingIngressInterface and 345 egressInterface. 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 | Set ID = 2 | Length = N octets | 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | Template ID = 256 | Field Count = N | 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 |0| forwardingExceptionCode | Field Length = 4 | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 |0| flowDirection | Field Length = 1 | 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 |0| commonPropertiesId1 | Field Length = 8 | 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 |0| commonPropertiesId2 | Field Length = 8 | 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 |0| commonPropertiesId3 | Field Length = 8 | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 |0| commonPropertiesId4 | Field Length = 8 | 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 |0| dataLinkFrameSize | Field Length = 2 | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 |0| dataLinkFrameSection | Field Length = 65535 | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | Padding (opt) | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 IPFIX Exception Template 2 for Forwarding Exceptions 373 6. IANA Considerations 375 6.1. Information Elements 377 IANA manages the IPFIX Information Elements registry at [IANA-IPFIX]. 378 This document introduces two new IPFIX Information Elements. 380 Name: forwardingExceptionCode 381 ElementID: TBD 382 Description: Exception code is an identifier uniquely describing 383 cause of irregularity or traffic drop on a device. 384 Abstract Data Type: unsigned32 385 Data Type Semantics: identifier 387 Name: forwardingNexthopId 388 ElementID: TBD 389 Description: Nexthop ID is a unique identifier for a Nexthop on a 390 device. 391 Abstract Data Type: unsigned64 392 Data Type Semantics: identifier 394 6.2. Forwarding Exception Codes 396 This document requests addition of a new registry for Forwarding 397 Exception Codes. 399 +----------------+--------------------------------------------------+ 400 | Forwarding | Reason | 401 | Exception Code | | 402 +----------------+--------------------------------------------------+ 403 | 1 | FIREWALL_DISCARD | 404 | 2 | TTL_EXPIRY | 405 | 3 | DISCARD_ROUTE | 406 | 4 | BAD_IPV4_CHECKSUM | 407 | 5 | REJECT_ROUTE | 408 | 6 | BAD_IPV4_HEADER (Version incorrect or IHL < 5)| 409 | 7 | BAD_IPV6_HEADER (Version incorrect) | 410 | 8 | BAD_IPV4_HEADER_LENGTH (V4 frame is too short) | 411 | 9 | BAD_IPV6_HEADER_LENGTH | 412 | 10 | BAD_IPV6_OPTIONS_PACKET(too many option headers) | 413 | .. | .. | 414 +----------------+--------------------------------------------------+ 416 Table 3: Exception Codes 418 All assignments in this registry are to be performed via Expert 419 Review. 421 7. Security Considerations 423 Security Considerations listed in detail for IPFIX in [RFC7011] apply 424 to this document as well. As described in [RFC7011], the IPFIX 425 messages exchanged between network device and collector MUST be 426 protected to provide confidentiality, integrity, and authenticity. 427 Without those characteristics, the messages are subject to various 428 kinds of attacks. These attacks are described in great detail in 429 [RFC7011]. 431 8. Contributors 433 Manikandan Musuvathi Poornachary 434 Juniper Networks, Inc. 435 Electra Exora Business Park~Marathahalli-Sarjapur Outer Ring Road, 436 Bangalore, KA - 560103 437 India 438 Email: mpoornachary@juniper.net 439 Vishnu Pavan Beeram 440 Juniper Networks, Inc. 441 1133 Innovation Way 442 Sunnyvale, CA 94089 443 USA 444 Email: vbeeram@juniper.net 446 Raveendra Torvi 447 Juniper Networks, Inc. 448 10 Technology Park Dr 449 Westford, MA 01886 450 USA 451 Email: rtorvi@juniper.net 453 9. References 455 9.1. Normative References 457 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 458 Requirement Levels", BCP 14, RFC 2119, 459 DOI 10.17487/RFC2119, March 1997, 460 . 462 [RFC5475] Zseby, T., Molina, M., Duffield, N., Niccolini, S., and F. 463 Raspall, "Sampling and Filtering Techniques for IP Packet 464 Selection", RFC 5475, DOI 10.17487/RFC5475, March 2009, 465 . 467 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 468 "Specification of the IP Flow Information Export (IPFIX) 469 Protocol for the Exchange of Flow Information", STD 77, 470 RFC 7011, DOI 10.17487/RFC7011, September 2013, 471 . 473 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 474 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 475 May 2017, . 477 9.2. Informative References 479 [IANA-IPFIX] 480 IANA, "IP Flow Information Export (IPFIX) Entities", 481 . 483 [RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, 484 "Architecture for IP Flow Information Export", RFC 5470, 485 DOI 10.17487/RFC5470, March 2009, 486 . 488 Authors' Addresses 490 Venkata Naga Chaitanya Munukutla 491 Juniper Networks, Inc. 492 10 Technology Park Dr 493 Westford, MA 01886 494 USA 496 Email: vmunuku@juniper.net 498 Shivam Vaid 499 Juniper Networks, Inc. 500 Electra, Exora Business Park- Marathahalli-Sarjapur Outer Ring Road 501 Bangalore, Karnataka 560103 502 India 504 Email: shivamv@juniper.net 506 Aditya Mahale 507 Google, Inc. 508 1600 Amphitheatre Parkway 509 Mountain View, CA 94043 510 USA 512 Email: amahale@google.com 514 Devang Patel 515 Google, Inc. 516 1600 Amphitheatre Parkway 517 Mountain View, CA 94043 518 USA 520 Email: pateldevang@google.com