draft-mvmd-opsawg-ipfix-fwd-exceptions-00.txt   draft-mvmd-opsawg-ipfix-fwd-exceptions-02.txt 
IP Flow Information Export C. Munukutla IP Flow Information Export C. Munukutla
Internet-Draft S. Vaid Internet-Draft S. Vaid
Intended status: Standards Track Juniper Networks, Inc. Intended status: Standards Track Juniper Networks, Inc.
Expires: January 28, 2021 A. Mahale Expires: August 8, 2021 A. Mahale
D. Patel D. Patel
Google, Inc. Google, Inc.
July 27, 2020 February 4, 2021
IP Flow Information Export (IPFIX) Information Elements Extension for IP Flow Information Export (IPFIX) Information Elements Extension for
Forwarding Exceptions Forwarding Exceptions
draft-mvmd-opsawg-ipfix-fwd-exceptions-00 draft-mvmd-opsawg-ipfix-fwd-exceptions-02
Abstract Abstract
This draft proposes couple of new Forwarding exceptions related This draft proposes couple of new Forwarding exceptions related
Information Elements (IEs) and Templates for the IP Flow Information Information Elements (IEs) and Templates for the IP Flow Information
Export (IPFIX) protocol. These new Information Elements and Export (IPFIX) protocol. These new Information Elements and
Exception Template can be used to export information about any Exception Template can be used to export information about any
forwarding errors in a network. This essential information is forwarding errors in a network. This essential information is
adequate to correlate packet drops to any control plane entity and adequate to correlate packet drops to any control plane entity and
map it to an impacted service. Once exceptions are correlated to a map it to an impacted service. Once exceptions are correlated to a
skipping to change at page 1, line 42 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 28, 2021. This Internet-Draft will expire on August 8, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Information Elements . . . . . . . . . . . . . . . . . . . . 4 3. Information Elements . . . . . . . . . . . . . . . . . . . . 4
4. New Information Elements . . . . . . . . . . . . . . . . . . 6 4. New Information Elements . . . . . . . . . . . . . . . . . . 6
4.1. Proposed New Information Elements . . . . . . . . . . . . 6 4.1. Proposed New Information Elements . . . . . . . . . . . . 6
4.2. Definition of Exceptions . . . . . . . . . . . . . . . . 6 4.2. Definition of Exceptions . . . . . . . . . . . . . . . . 6
5. Exception Templates . . . . . . . . . . . . . . . . . . . . . 7 4.2.1. forwardingExceptionCode . . . . . . . . . . . . . . . 6
5.1. IPFIX Exception Template 1 for Forwarding Exceptions . . 7 4.2.2. forwardingNexthopId . . . . . . . . . . . . . . . . . 7
5.2. IPFIX Exception Template 2 for Forwarding Exceptions . . 8 5. Exception Templates . . . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 5.1. IPFIX Exception Template 1 for Forwarding Exceptions . . 9
6.1. Information Elements . . . . . . . . . . . . . . . . . . 9 5.2. IPFIX Exception Template 2 for Forwarding Exceptions . . 9
6.2. Forwarding Exception Codes . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6.1. Information Elements . . . . . . . . . . . . . . . . . . 10
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 6.2. Forwarding Exception Codes . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . 11 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 9.1. Normative References . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
All networks are susceptible to traffic drops due to a number of All networks are susceptible to traffic drops due to a number of
factors. Traffic drops can go unnoticed unless they are service factors. Traffic drops can go unnoticed unless they are service
impacting. In a multi-layered network architecture, it is tedious impacting. In a multi-layered network architecture, it is tedious
manual work to localize and root cause traffic blackholing issues. manual work to localize and root cause traffic blackholing issues.
Transient drops are even harder to detect. Existing methodologies Transient drops are even harder to detect. Existing methodologies
that rely on periodically monitoring interfaces on several hosts in a that rely on periodically monitoring interfaces on several hosts in a
network does not guarantee timely detection, and are not scalable for network does not guarantee timely detection, and are not scalable for
skipping to change at page 6, line 29 skipping to change at page 6, line 29
| forwardingNextHopID | unsigned64 | Forwarding NH - | | forwardingNextHopID | unsigned64 | Forwarding NH - |
| | | index associated| | | | index associated|
| | | with packet that| | | | with packet that|
| | | encountered | | | | encountered |
| | | this exception | | | | this exception |
+---------------------------+---------------------+-----------------+ +---------------------------+---------------------+-----------------+
Table 2: New Information Elements Table 2: New Information Elements
New Information Elements New Information Elements
The Information Elements defined in Figure 1 are proposed to be The Information Elements defined in Table 2 are proposed to be
incorporated into the IANA IPFIX Information Elements registry incorporated into the IANA IPFIX Information Elements registry
[IANA-IPFIX] [IANA-IPFIX]
4.2. Definition of Exceptions 4.2. Definition of Exceptions
Every network will encounter issues like packet loss, from time to Every network will encounter issues like packet loss, from time to
time. Some of the causes for such a loss of traffic or a block in time. Some of the causes for such a loss of traffic or a block in
transmission of data packets include overloaded system conditions, transmission of data packets include overloaded system conditions,
misconfiguration, profiles and policies that restrict the bandwidth misconfiguration, profiles and policies that restrict the bandwidth
or priority of traffic, network outages, or disruption with physical or priority of traffic, network outages, or disruption with physical
cable faults. Packet loss could also happen because of incorrect cable faults. Packet loss could also happen because of incorrect
stitching of the forwarding path or a mismatch between control plane stitching of the forwarding path or a mismatch between control plane
and data plane state. Exception code entails the reason/error code and data plane state. Exception code entails the reason/error code
due to which this packet has been dropped. due to which this packet has been dropped.
4.2.1. forwardingExceptionCode
forwardingExceptionCode will be defined in "IPFIX Information forwardingExceptionCode will be defined in "IPFIX Information
Elements" registry. This list can be expanded in the future as Elements" registry. This list can be expanded in the future as
necessary. The data record will have corresponding exception code necessary. The data record will have corresponding exception code
value to indicate forwarding error that caused the traffic drop. value to indicate forwarding error that caused the traffic drop.
An implementation may choose to encode device internal exception An implementation may choose to encode device internal exception
codes as forwardingExceptionCode. In such scenarios, Enterprise Bit codes as forwardingExceptionCode. In such scenarios, Enterprise Bit
MUST be set to 1 and corresponding Enterprise Number MUST be present MUST be set to 1 and corresponding Enterprise Number MUST be present
as described in [RFC7011] as described in [RFC7011]
There is an existing IE 89 - forwardingStatus [IANA-IPFIX] but it
allows a very limited number of exceptions to be reported from the
system (6-bit reason code). The exception codes also need to be
standardized for use. Different forwarding ASICs would have
different pipelines and hence discard reasons (which could be very
specific to that pipeline) cannot be generalized. Hence it makes
sense to have a standalone IE for reporting exception which not only
provides support to report larger number of exceptions but also
provides freedom for reporting application specific exceptions using
the enterprise bit.
A list of commonly used forwarding Exception codes will be identified A list of commonly used forwarding Exception codes will be identified
and listed as part of Table 3 below. and listed as part of Table 3 below.
+----------------+--------------------------------------------------+ +----------------+--------------------------------------------------+
| Forwarding | Reason | | Forwarding | Reason |
| Exception Code | | | Exception Code | |
+----------------+--------------------------------------------------+ +----------------+--------------------------------------------------+
| 1 | FIREWALL_DISCARD | | 1 | FIREWALL_DISCARD |
| 2 | TTL_EXPIRY | | 2 | TTL_EXPIRY |
| 3 | DISCARD_ROUTE | | 3 | DISCARD_ROUTE |
skipping to change at page 7, line 29 skipping to change at page 7, line 43
| 6 | BAD_IPV4_HEADER (Version incorrect or IHL < 5)| | 6 | BAD_IPV4_HEADER (Version incorrect or IHL < 5)|
| 7 | BAD_IPV6_HEADER (Version incorrect) | | 7 | BAD_IPV6_HEADER (Version incorrect) |
| 8 | BAD_IPV4_HEADER_LENGTH (V4 frame is too short) | | 8 | BAD_IPV4_HEADER_LENGTH (V4 frame is too short) |
| 9 | BAD_IPV6_HEADER_LENGTH | | 9 | BAD_IPV6_HEADER_LENGTH |
| 10 | BAD_IPV6_OPTIONS_PACKET(too many option headers) | | 10 | BAD_IPV6_OPTIONS_PACKET(too many option headers) |
| .. | .. | | .. | .. |
+----------------+--------------------------------------------------+ +----------------+--------------------------------------------------+
Table 3: Exception Codes Table 3: Exception Codes
Reachability to any given destination inside the router is defined 4.2.2. forwardingNexthopId
using a next-hop which is typically represented in the forwarding
path as an index. The nexthop index uniquely identifies the egress
path a packet would take to reach the destination. This could
include information about the outgoing interface, forwarding features
configured for the packet path etc.
An implementation may choose to report linecard and forwarding ASIC In terms of a network device, next hop is the gateway to which packet
information on which an exception occurs, but mechanism to export should be forwarded corresponding to the path to final destination.
these fields is out of the scope of this document. A given router doesn't need to store the entire forwarding path
information for a destination. As long as it can identify the next
hop to be used for forwarding to a destination, the end to end
forwarding can happen. This helps reduce size of forwarding table.
The nexthop index uniquely identifies the egress path a packet would
take to reach the destination. This could include information about
the outgoing interface, layer 2 address to be used, forwarding
features configured for the packet path etc.
For instance, consider we have a L3VPN topology like below
CE1 -------- PE1 ----- MPLS Network ----- PE2 ------- CE2
Figure 1: MPLS VPN Network
Figure 1 above illustrates an example where reporting of exception
can provide an insight into the error scenario. CE1 and CE2
communicate with each other over an MPLS VPN network. The labels are
typically advertised using protocols like RSVP or LDP. When a packet
is received from core network on PE1, a lookup on MPLS label results
in packet getting forwarded towards CE1. The entries in MPLS table
are populated by corresponding protocol. If label entries don't get
populated in the MPLS table due to a probable glitch in the protocol
configuration or some software inconsistency, the packets traversing
on that LSP tunnel path shall get discarded on PE1.
In case of route lookups, that result in hierarchical forwarding
chains, the mis-programming may manifest at different levels of the
forwarding structure. The forwarding lookup may fail on any level of
the hierarchy in the forwarding chain. It is expected that software
at least report the nexthop where the lookup terminates. Its
desirable for software to report the top level nexthop in the chain.
Using the mechanism described in this RFC, it will be possible to
capture such packets and report them in IPFIX format with
corresponding exception set (eg. DISCARD_ROUTE) along with relevant
packet bytes and meta-data. This can help the operator/software to
immediately understand root cause of the problem and take appropriate
action.
An implementation may choose to report linecard number, linecard
type, forwarding ASIC type and forwarding ASIC number on which an
exception occurs, but mechanism to export these fields is out of the
scope of this document.
5. Exception Templates 5. Exception Templates
This section presents a list of templates for reporting exceptions This section presents a list of templates for reporting exceptions
using newly proposed IEs in addition to few existing IEs. using newly proposed IEs in addition to few existing IEs.
5.1. IPFIX Exception Template 1 for Forwarding Exceptions 5.1. IPFIX Exception Template 1 for Forwarding Exceptions
Exception Template defined in Figure 1 may be used to export Exception Template defined in Figure 1 may be used to export
forwarding Exceptions. forwarding Exceptions.
 End of changes. 12 change blocks. 
28 lines changed or deleted 81 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/