idnits 2.17.1 draft-mvmd-opsawg-ipfix-fwd-exceptions-04.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 (7 February 2022) is 801 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: 11 August 2022 A. Mahale 6 D. Patel 7 Google, Inc. 8 7 February 2022 10 IP Flow Information Export (IPFIX) Information Elements Extension for 11 Forwarding Exceptions 12 draft-mvmd-opsawg-ipfix-fwd-exceptions-04 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 11 August 2022. 43 Copyright Notice 45 Copyright (c) 2022 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 (https://trustee.ietf.org/ 50 license-info) in effect on the date of publication of this document. 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. Code Components 53 extracted from this document must include Revised BSD License text as 54 described in Section 4.e of the Trust Legal Provisions and are 55 provided without warranty as described in the Revised BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 62 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3. Information Elements . . . . . . . . . . . . . . . . . . . . 4 64 4. New Information Elements . . . . . . . . . . . . . . . . . . 6 65 4.1. Proposed New Information Elements . . . . . . . . . . . . 6 66 4.2. Definition of Exceptions . . . . . . . . . . . . . . . . 7 67 4.2.1. forwardingExceptionCode . . . . . . . . . . . . . . . 7 68 4.2.2. forwardingNexthopId . . . . . . . . . . . . . . . . . 8 69 4.2.3. forwardingLookupType . . . . . . . . . . . . . . . . 9 70 4.2.4. underlyingIngressInterface . . . . . . . . . . . . . 9 71 5. Exception Templates . . . . . . . . . . . . . . . . . . . . . 10 72 5.1. IPFIX Exception Template 1 for Forwarding Exceptions . . 10 73 5.2. IPFIX Exception Template 2 for Forwarding Exceptions . . 11 74 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 75 6.1. Information Elements . . . . . . . . . . . . . . . . . . 11 76 6.2. Forwarding Exception Codes . . . . . . . . . . . . . . . 12 77 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 78 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13 79 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 80 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 81 9.2. Informative References . . . . . . . . . . . . . . . . . 14 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 84 1. Introduction 86 All networks are susceptible to traffic drops due to a number of 87 factors. Traffic drops can go unnoticed unless they are service 88 impacting. In a multi-layered network architecture, it is tedious 89 manual work to localize and root cause traffic blackholing issues. 90 Transient drops are even harder to detect. Existing methodologies 91 that rely on periodically monitoring interfaces on several hosts in a 92 network does not guarantee timely detection, and are not scalable for 93 large networks. 95 In order to eliminate this tedious monitoring work-flow, objective is 96 to simplify localization and build correlation of dropped packets to 97 particular entity. The network entity shall identify the dropped 98 packets by monitoring dropped counters or doing a deep packet 99 inspection of the packet discarded by the forwarding ASIC. The 100 implementation of the method used to detect the drop is outside the 101 scope of this document. Dropped packets will be sampled in the 102 forwarding-path and sent to a host or software queue along with type 103 of exception, in/out interface information and other relevant meta 104 data. This will be a push model where the node encountering the 105 error will emit the information about dropped packets and associated 106 meta-data. Techniques for IP Packet Selection [RFC5475] describes 107 Sampling and Filtering techniques for IP packet selection either 108 using Systematic Sampling or Random Sampling. 110 The IPFIX Protocol Specification [RFC7011] defines a generic exchange 111 mechanism for collecting flow information. It supports source- 112 triggered export of information via the push model approach. The 113 IPFIX Information Model [IANA-IPFIX] defines a list of standard 114 Information Elements (IEs) which can be carried by the IPFIX 115 protocol. 117 This document focuses on telemetry information for dropped packet 118 exceptions, and proposes an extension to IPFIX message format for 119 collecting sampled exceptions. Some of the IPFIX Information 120 Elements (IEs) already exist, some will be defined along with 121 corresponding formats. It is also possible to achieve sampling of 122 the dropped packets by using sampling methods like SFLOW but details 123 of other sampling methods are outside the scope of this document. 125 1.1. Terminology 127 IPFIX-specific terminology (e.g. Information Element, Template, 128 Template Record, Options Template Record, Template Set, Collector, 129 Exporter, Data Record) used in this document is defined in Section 2 130 of [RFC7011]. As in [RFC7011] these IPFIX-specific terms have the 131 first letter of a word capitalized. This document also makes use of 132 the same terminology and definitions as Section 2 of [RFC5470]. 134 1.2. Requirements Language 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 138 "OPTIONAL" in this document are to be interpreted as described in BCP 139 14 [RFC2119] [RFC8174] when, and only when, they appear in all 140 capitals, as shown here. 142 2. Scope 144 This document specifies the information model used for reporting 145 packet-based forwarding exceptions. [RFC7011] provides guidance on 146 the choices of the transport protocols used for IPFIX and their 147 effects. Encoded IPFIX exception packets need to be reliably 148 transported to the collector. The choice of the actual transport 149 protocol is beyond the scope of this document. 151 This document assumes that all devices reporting exceptions will use 152 existing IPFIX framework/module to send encoded packets to the 153 collector. This would mean that the network device will specify the 154 template that it is going to use for each of the events. The 155 templates can be of varying length, and there could be multiple 156 templates that a network device could use to encode the exceptions. 158 The implementation details of the collector application are beyond 159 the scope of this document. 161 3. Information Elements 163 The Exception template could contain a subset of the IEs shown in 164 Table 1, depending upon the exception reported. 166 Whenever packet drop happens inside forwarding plane, following 167 information is key to understanding the issue: reason for packet 168 drop, flow which encountered the drop (packet content), additional 169 meta-data e.g. flow direction (ingress/egress), nexthop index, input 170 interface, output interface, etc. on which this packet was flowing. 172 The following table includes all the existing IEs that a device 173 reporting IPFIX Exceptions using various Exception Templates would 174 typically need. The formats of IEs and IPFIX IDs are listed in the 175 table below. 177 +-------------------------------+--------+-------+--------------+ 178 | Field Name | Size | IANA | Description | 179 | | (bits) | IPFIX | | 180 | | | ID | | 181 +-------------------------------+--------+-------+--------------+ 182 | flowDirection | 8 | 61 | The direction| 183 | | | | of the Flow | 184 | | | | observed at | 185 | | | | Observation | 186 | | | | point. | 187 | | | | | 188 | ingressInterface | 32 | 10 | Index of IP | 189 | | | | interface | 190 | | | | where packets| 191 | | | | of this flow | 192 | | | | are being | 193 | | | | received. | 194 | | | | | 195 | egressInterface | 32 | 14 | Index of IP | 196 | | | | interface | 197 | | | | where packets| 198 | | | | of this flow | 199 | | | | are being | 200 | | | | sent. | 201 | | | | | 202 | dataLinkFrameSize | 16 | 312 | Specified | 203 | | | | length of | 204 | | | | data link | 205 | | | | frame. | 206 | | | | | 207 | dataLinkFrameSection | 65535 | 315 | Carries n | 208 | | | | octets from | 209 | | | | data link | 210 | | | | frame of | 211 | | | | selected | 212 | | | | frame. | 213 | | | | | 214 | commonPropertiesID | 64 | 137 | Identifier of| 215 | | | | a set of | 216 | | | | common | 217 | | | | properties | 218 | | | | that is | 219 | | | | unique per | 220 | | | | observation | 221 | | | | domain. | 222 +-------------------------------+--------+-------+--------------+ 223 Table 1: Forwarding Exception Information Elements 224 Figure 1: Information Elements 226 4. New Information Elements 228 4.1. Proposed New Information Elements 230 The proposed new IEs that a device reporting Exceptions using 231 Exception template would need are listed in Table 2 below. 233 +---------------------------+---------------------+-----------------+ 234 | Field Name | Abstract Data Type | Description | 235 | | | | 236 +---------------------------+---------------------+-----------------+ 237 | forwardingExceptionCode | unsigned32 | Unique code for | 238 | | | every exception | 239 | | | | 240 | forwardingNextHopID | unsigned64 | Forwarding NH - | 241 | | | index associated| 242 | | | with packet that| 243 | | | encountered | 244 | | | this exception | 245 | | | | 246 | forwardingLookupType | unsigned8 | Last Lookup | 247 | | | type performed | 248 | | | on the packet in| 249 | | | in ingress path.| 250 | | | For instance, | 251 | | | IPV4, IPV6, | 252 | | | Bridge, MPLS, | 253 | | | Unknown etc. | 254 | | | | 255 | underlyingIngressInterface| unsigned32 | Underlying | 256 | | | interface from | 257 | | | which a packet | 258 | | | arrived in | 259 | | | ingress path. | 260 | | | For instance, | 261 | | | child interface | 262 | | | of aggregate | 263 | | | interface on | 264 | | | which packet | 265 | | | came in ingress;| 266 | | | where aggregate | 267 | | | interface is | 268 | | | captured in | 269 | | | ingressInterface| 270 +---------------------------+---------------------+-----------------+ 271 Table 2: New Information Elements 272 Figure 2: New Information Elements 274 The Information Elements defined in Table 2 are proposed to be 275 incorporated into the IANA IPFIX Information Elements registry 276 [IANA-IPFIX] 278 4.2. Definition of Exceptions 280 Every network will encounter issues like packet loss, from time to 281 time. Some of the causes for such a loss of traffic or a block in 282 transmission of data packets include overloaded system conditions, 283 misconfiguration, profiles and policies that restrict the bandwidth 284 or priority of traffic, network outages, or disruption with physical 285 cable faults. Packet loss could also happen because of incorrect 286 stitching of the forwarding path or a mismatch between control plane 287 and data plane state. Exception code entails the reason/error code 288 due to which this packet has been dropped. 290 4.2.1. forwardingExceptionCode 292 forwardingExceptionCode will be defined in "IPFIX Information 293 Elements" registry. This list can be expanded in the future as 294 necessary. The data record will have corresponding exception code 295 value to indicate forwarding error that caused the traffic drop. 297 An implementation may choose to encode device internal exception 298 codes as forwardingExceptionCode. In such scenarios, Enterprise Bit 299 MUST be set to 1 and corresponding Enterprise Number MUST be present 300 as described in [RFC7011] 302 There is an existing IE 89 - forwardingStatus [IANA-IPFIX] but it 303 allows a very limited number of exceptions to be reported from the 304 system (6-bit reason code). The exception codes also need to be 305 standardized for use. Different forwarding ASICs would have 306 different pipelines and hence discard reasons (which could be very 307 specific to that pipeline) cannot be generalized. Hence it makes 308 sense to have a standalone IE for reporting exception which not only 309 provides support to report larger number of exceptions but also 310 provides freedom for reporting application specific exceptions using 311 the enterprise bit. 313 forwardingExceptionCode will also describe status of the flow with 314 first two bits. An implementation may choose to export 315 forwardingExceptionCode instead of IE89 - forwardingStatus. 317 A list of commonly used forwarding Exception codes will be identified 318 and listed as part of Table 3 below. 320 +----------------+--------------------------------------------------+ 321 | Forwarding | Reason | 322 | Exception Code | | 323 +----------------+--------------------------------------------------+ 324 | 1 | FIREWALL_DISCARD | 325 | 2 | TTL_EXPIRY | 326 | 3 | DISCARD_ROUTE | 327 | 4 | BAD_IPV4_CHECKSUM | 328 | 5 | REJECT_ROUTE | 329 | 6 | BAD_IPV4_HEADER (Version incorrect or IHL < 5)| 330 | 7 | BAD_IPV6_HEADER (Version incorrect) | 331 | 8 | BAD_IPV4_HEADER_LENGTH (V4 frame is too short) | 332 | 9 | BAD_IPV6_HEADER_LENGTH | 333 | 10 | BAD_IPV6_OPTIONS_PACKET(too many option headers) | 334 | .. | .. | 335 +----------------+--------------------------------------------------+ 337 Figure 3: Table 3: Exception Codes 339 4.2.2. forwardingNexthopId 341 In terms of a network device, next hop is the gateway to which packet 342 should be forwarded corresponding to the path to final destination. 343 A given router doesn't need to store the entire forwarding path 344 information for a destination. As long as it can identify the next 345 hop to be used for forwarding to a destination, the end to end 346 forwarding can happen. This helps reduce size of forwarding table. 347 The nexthop index uniquely identifies the egress path a packet would 348 take to reach the destination. This could include information about 349 the outgoing interface, layer 2 address to be used, forwarding 350 features configured for the packet path etc. 352 For instance, consider we have a L3VPN topology like below 354 CE1 -------- PE1 ----- MPLS Network ----- PE2 ------- CE2 356 Figure 4: Figure 1: MPLS VPN Network 358 Figure 1 above illustrates an example where reporting of exception 359 can provide an insight into the error scenario. CE1 and CE2 360 communicate with each other over an MPLS VPN network. The labels are 361 typically advertised using protocols like RSVP or LDP. When a packet 362 is received from core network on PE1, a lookup on MPLS label results 363 in packet getting forwarded towards CE1. The entries in MPLS table 364 are populated by corresponding protocol. If label entries don't get 365 populated in the MPLS table due to a probable glitch in the protocol 366 configuration or some software inconsistency, the packets traversing 367 on that LSP tunnel path shall get discarded on PE1. 369 In case of route lookups, that result in hierarchical forwarding 370 chains, the mis-programming may manifest at different levels of the 371 forwarding structure. The forwarding lookup may fail on any level of 372 the hierarchy in the forwarding chain. It is expected that software 373 at least report the nexthop where the lookup terminates. Its 374 desirable for software to report the top level nexthop in the chain. 376 Using the mechanism described in this RFC, it will be possible to 377 capture such packets and report them in IPFIX format with 378 corresponding exception set (eg. DISCARD_ROUTE) along with relevant 379 packet bytes and meta-data. This can help the operator/software to 380 immediately understand root cause of the problem and take appropriate 381 action. 383 An implementation may choose to report linecard number, linecard 384 type, forwarding ASIC type and forwarding ASIC number on which an 385 exception occurs, but mechanism to export these fields is out of the 386 scope of this document. 388 4.2.3. forwardingLookupType 390 A packet might undergo multiple lookups in the forwarding chain. 391 Lookup may fail at any level of the lookup hierarchy. When an 392 exception is reported in such cases, type of the last lookup 393 performed on the packet may help in identifying nature of the 394 erroneous path. 396 For instance, a Firewall Discard may happen for Layer2 or Layer3 397 packet. All such packets may be treated as FIREWALL_DISCARD for 398 generic exception reporting purposes. However, exact place of error 399 in the pipeline (IPV4, IPV6, MPLS etc.) may help with easily 400 correlating the exception. 402 4.2.4. underlyingIngressInterface 404 A packet can arrive on an aggregate ethernet(ae) interface where the 405 receive interface is the ae but actual physical interface is a child 406 member of this ae. If such a packet gets dropped because of an 407 exception, it will be very useful not only to know about the ae on 408 which it arrived but also the child link of that ae on which the 409 packet was received. 411 underlyingIngressInterface represents the interface underlying the 412 received interface (which in case of ae would be its child link) on 413 which the packet arrived in ingress. This helps in providing more 414 context about the nature of the packet processing for this path. 416 5. Exception Templates 418 This section presents a list of templates for reporting exceptions 419 using newly proposed IEs in addition to few existing Information 420 Elements (IEs). 422 Templates listed below are sample templates to demonstrate the 423 utility of newly introduced Information Elements in conjuction with 424 existing Information Elements to report meaningful data to the 425 collector. A specific implementation may add or remove Information 426 Elements from below templates based on their reporting requirements. 428 5.1. IPFIX Exception Template 1 for Forwarding Exceptions 430 Exception Template defined in Figure 1 demonstrates a sample set of 431 data to export forwarding Exceptions. 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 | Set ID = 2 | Length = N octets | 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 | Template ID = 256 | Field Count = N | 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 |0| forwardingExceptionCode | Field Length = 4 | 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 |0| forwardingNextHopId | Field Length = 8 | 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 |0| forwardingLookupType | Field Length = 1 | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 |0| flowDirection | Field Length = 1 | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 |0| ingressInterface | Field Length = 4 | 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 |0| egressInterface | Field Length = 4 | 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 |0| dataLinkFrameSize | Field Length = 2 | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 |0| dataLinkFrameSection | Field Length = 65535 | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | Padding (opt) | 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 Figure 5: IPFIX Exception Template for Forwarding Exceptions 459 5.2. IPFIX Exception Template 2 for Forwarding Exceptions 461 Alternatively, Exception Template defined in Figure 2 is a sample 462 template to export forwarding exceptions. This template demonstrates 463 the use of Information Element 137 to represent following fields: 464 forwardingExceptionCode, forwardingNexthopId, ingressInterface, 465 underlyingIngressInterface and egressInterface. 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 | Set ID = 2 | Length = N octets | 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 | Template ID = 256 | Field Count = N | 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 |0| commonPropertiesId1 | Field Length = 4 | 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 |0| flowDirection | Field Length = 1 | 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 |0| forwardingLookupType | Field Length = 1 | 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 |0| commonPropertiesId2 | Field Length = 8 | 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 |0| commonPropertiesId3 | Field Length = 8 | 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 |0| commonPropertiesId4 | Field Length = 8 | 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 |0| commonPropertiesId5 | Field Length = 8 | 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 |0| dataLinkFrameSize | Field Length = 2 | 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 |0| dataLinkFrameSection | Field Length = 65535 | 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 | Padding (opt) | 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 Figure 6: IPFIX Exception Template 2 for Forwarding Exceptions 495 6. IANA Considerations 497 6.1. Information Elements 499 IANA manages the IPFIX Information Elements registry at [IANA-IPFIX]. 500 This document introduces two new IPFIX Information Elements. 502 Name: forwardingExceptionCode ElementID: TBD Description: Exception 503 code is an identifier uniquely describing cause of irregularity or 504 traffic drop on a device. Abstract Data Type: unsigned32 Data Type 505 Semantics: identifier 506 Name: forwardingNexthopId ElementID: TBD Description: Nexthop ID is a 507 unique identifier for a Nexthop on a device. Abstract Data Type: 508 unsigned64 Data Type Semantics: identifier 510 Name: forwardingLookupType ElementID: TBD Description: Represents the 511 last lookup performed on the packet in forwarding path. Abstract 512 Data Type: unsigned8 Data Type Semantics: identifier 514 Name: underlyingIngressInterface ElementID: TBD Description: The 515 underlying interface index of the interface from where packet of a 516 given flow are received in ingress. For example, child interface of 517 an aggregate ethernet interface. Abstract Data Type: unsigned32 Data 518 Type Semantics: identifier 520 6.2. Forwarding Exception Codes 522 This document requests addition of a new registry for Forwarding 523 Exception Codes. 525 +----------------+--------------------------------------------------+ 526 | Forwarding | Reason | 527 | Exception Code | | 528 +----------------+--------------------------------------------------+ 529 | 1 | FIREWALL_DISCARD | 530 | 2 | TTL_EXPIRY | 531 | 3 | DISCARD_ROUTE | 532 | 4 | BAD_IPV4_CHECKSUM | 533 | 5 | REJECT_ROUTE | 534 | 6 | BAD_IPV4_HEADER (Version incorrect or IHL < 5)| 535 | 7 | BAD_IPV6_HEADER (Version incorrect) | 536 | 8 | BAD_IPV4_HEADER_LENGTH (V4 frame is too short) | 537 | 9 | BAD_IPV6_HEADER_LENGTH | 538 | 10 | BAD_IPV6_OPTIONS_PACKET(too many option headers) | 539 | .. | .. | 540 +----------------+--------------------------------------------------+ 542 Figure 7: Table 3: Exception Codes 544 All assignments in this registry are to be performed via Expert 545 Review. 547 7. Security Considerations 549 Security Considerations listed in detail for IPFIX in [RFC7011] apply 550 to this document as well. As described in [RFC7011], the IPFIX 551 messages exchanged between network device and collector MUST be 552 protected to provide confidentiality, integrity, and authenticity. 553 Without those characteristics, the messages are subject to various 554 kinds of attacks. These attacks are described in great detail in 555 [RFC7011]. 557 8. Contributors 559 Manikandan Musuvathi Poornachary 560 Juniper Networks, Inc. 561 Electra Exora Business Park~Marathahalli-Sarjapur Outer Ring Road, 562 Bangalore, KA - 560103 563 India 564 Email: mpoornachary@juniper.net 566 Vishnu Pavan Beeram 567 Juniper Networks, Inc. 568 1133 Innovation Way 569 Sunnyvale, CA 94089 570 USA 571 Email: vbeeram@juniper.net 573 Raveendra Torvi 574 Juniper Networks, Inc. 575 10 Technology Park Dr 576 Westford, MA 01886 577 USA 578 Email: rtorvi@juniper.net 580 9. References 582 9.1. Normative References 584 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 585 Requirement Levels", BCP 14, RFC 2119, 586 DOI 10.17487/RFC2119, March 1997, 587 . 589 [RFC5475] Zseby, T., Molina, M., Duffield, N., Niccolini, S., and F. 590 Raspall, "Sampling and Filtering Techniques for IP Packet 591 Selection", RFC 5475, DOI 10.17487/RFC5475, March 2009, 592 . 594 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 595 "Specification of the IP Flow Information Export (IPFIX) 596 Protocol for the Exchange of Flow Information", STD 77, 597 RFC 7011, DOI 10.17487/RFC7011, September 2013, 598 . 600 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 601 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 602 May 2017, . 604 9.2. Informative References 606 [IANA-IPFIX] 607 IANA, "IP Flow Information Export (IPFIX) Entities", 608 . 610 [RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, 611 "Architecture for IP Flow Information Export", RFC 5470, 612 DOI 10.17487/RFC5470, March 2009, 613 . 615 Authors' Addresses 617 Venkata Naga Chaitanya Munukutla 618 Juniper Networks, Inc. 619 10 Technology Park Dr 620 Westford, MA 01886 621 United States of America 623 Email: vmunuku@juniper.net 625 Shivam Vaid 626 Juniper Networks, Inc. 627 Electra, Exora Business Park- Marathahalli-Sarjapur Outer Ring Road 628 Bangalore 560103 629 Karnataka 630 India 632 Email: shivamv@juniper.net 634 Aditya Mahale 635 Google, Inc. 636 1600 Amphitheatre Parkway 637 Mountain View, CA 94043 638 United States of America 639 Email: amahale@google.com 641 Devang Patel 642 Google, Inc. 643 1600 Amphitheatre Parkway 644 Mountain View, CA 94043 645 United States of America 647 Email: pateldevang@google.com