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/ |