Dear OPSAWG Members and RFC 8158 Authors,
I hope this message finds you well. I would like to start by acknowledging the
excellent work done on RFC 8158, which has standardized IPFIX Information
Elements (IEs) for NAT Event Logging. This document provides essential logging
capabilities for Network Address Translation (NAT) events and has been
invaluable for ensuring consistency in NAT event tracking across network
devices.
As a potential enhancement to this RFC, I propose the inclusion of packets per
second (pps) and bits per second (bps) metrics for each NAT flow. The goal is
to provide more detailed insights into NAT flow behavior, particularly to
identify FAT flows that consume excessive bandwidth or hijack available
throughput.
Motivation: While RFC 8158 efficiently logs critical NAT session events (e.g.,
creation and deletion), it lacks specific metrics related to throughput that
would allow operators to understand real-time bandwidth consumption of
individual NAT flows. Adding pps and bps to the existing template would enable
operators to:
* Detect and manage FAT flows that consume excessive bandwidth.
* Monitor throughput per NAT flow to identify potential bottlenecks or
misbehaving flows.
* Improve operational efficiency by reducing the overhead on collectors,
allowing NAT devices or IPFIX exporters to compute and export throughput values
directly.
* Enhance network management by correlating throughput metrics with NAT
events like session creation and deletion.
Proposed Additions to the IPFIX Template: To extend the current template, I
propose adding the following new IEs:
1. PacketsPerSecond (pps): The number of packets transmitted per second for
a given NAT flow.
* Type: Float or Integer
* Formula: Calculated from packetDeltaCount divided by flow duration
(flowEndSysUpTime - flowStartSysUpTime).
2. BitsPerSecond (bps): The number of bits transmitted per second for a
given NAT flow.
* Type: Float or Integer
* Formula: Calculated by converting octetTotalCount to bits (octets * 8)
and dividing by flow duration (flowEndSysUpTime - flowStartSysUpTime).
These metrics would add visibility into real-time performance of NAT flows,
allowing operators to better manage high-bandwidth flows and mitigate
congestion before it becomes an issue.
Integration with Existing IEs: The new IEs would integrate seamlessly with RFC
8158’s current elements:
* Session Creation (natEvent): Remains unchanged but now includes
throughput metrics for each session.
* Session Deletion (natEvent): Could include throughput values at the end
of the session, giving a complete view of flow behavior.
* octetTotalCount and packetDeltaCount: Existing IEs can serve to calculate
the new pps and bps values.
This extended logging provides both an event-based and performance-based view
of NAT flows, enabling network operators to optimize traffic, apply QoS
measures, and prevent bandwidth hogging.
Rationale: While pps and bps can technically be derived from octetTotalCount,
packetDeltaCount, and flow timestamps, separate IEs offer several advantages:
1. Pre-processed Data for Real-Time Monitoring: Exporting pre-calculated pps
and bps values reduces processing overhead on collectors, especially in
high-flow environments.
2. Reduced Overhead on Collectors: By offloading computations to NAT
devices, collectors can focus on aggregation and analysis, improving
scalability in high-traffic environments.
3. Timely, Accurate Data from NAT Devices: Devices exporting real-time pps
and bps provide accurate, up-to-date data, reducing error risk in
post-collection calculations.
4. Standardization and Uniformity: Standardizing pps and bps in IPFIX
templates ensures consistency across NAT devices and exporters, preventing
discrepancies.
5. Simplified Analysis: Including pps and bps in exports makes key
throughput metrics immediately available, facilitating troubleshooting.
Conclusion: Adding pps and bps metrics to IPFIX NAT logging would enhance
network operators' capabilities in managing networks, providing granular
visibility into NAT flows and enabling effective traffic shaping. These
enhancements would also reduce the processing load on collectors, improving
scalability and performance.
Thank you for considering this proposal. I welcome any feedback from the
working group and the authors of RFC 8158 and am open to collaboration on
refining these enhancements.
Regards
yp
Juniper Business Use Only
_______________________________________________
OPSAWG mailing list -- opsawg@ietf.org
To unsubscribe send an email to opsawg-le...@ietf.org
