Dear Med and OPSAWG Members,
Sorry for the delay in response. Thank you for your feedback and for bringing
historical context into the discussion. I appreciate you involving Dan to
provide additional insights.
Why Internal Realm Metrics Are Not Sufficient:
While internal realm metrics can offer a broad view of traffic, they lack the
granularity and context provided by NAT flow-level metrics. Specifically:
1. NAT-Specific Context: Flow-level metrics directly identify which
NAT pools or services are impacted by FAT flows. Internal realm metrics
aggregate data across flows, obscuring this visibility.
2. Flow Identification: Operators need flow-level granularity to
pinpoint specific high-bandwidth flows. Aggregated internal realm metrics do
not provide this.
3. Correlation With NAT Events: Flow-level metrics allow direct
correlation with session creation and deletion events, enabling more actionable
insights for network operations.
Importance of Flow-Level Throughput Metrics:
Including pps and bps metrics at the flow level allows:
• Quick identification of impacted NAT resources (e.g., pools,
services).
• Targeted traffic management for FAT flows.
• Operational efficiency by offloading computations from
collectors to NAT devices.
Please revert to me if any further queries.
Regards
yp
Juniper Business Use Only
From: [email protected] <[email protected]>
Date: Friday, November 22, 2024 at 3:02 AM
To: Prasad Yadati <[email protected]>, [email protected] <[email protected]>, Dan
Wing ([email protected]) <[email protected]>
Cc: [email protected] <[email protected]>, [email protected]
<[email protected]>
Subject: RE: Proposal to Enhance IPFIX NAT Logging with pps/bps Metrics for
Improved Flow Monitoring
[External Email. Be cautious of content]
Hi Prasad,
I lost the context whether this specific point was discussed in behave where
8158 started. However, I don’t see any similar tracking in relevant specs that
were developed at the time (RFC8512 (here in OPSAWG), CGN Requirements
(RFC6888, in behave), NAT-MIB (RFC7659, behave), RFC8513 (in softwire)). All
the policies are related to NAT-specific resources, not throughput/rate for
specific BIB/Mapping.
I add Dan (co-chair of behave) in case he still has the context.
If the throughput IEs are needed, what prevents you from exporting based on the
internal realm?
Cheers,
Med
Juniper Business Use Only
De : Prasad Yadati <[email protected]>
Envoyé : vendredi 1 novembre 2024 21:14
À : [email protected]
Cc : [email protected]; [email protected]
Objet : [OPSAWG]Proposal to Enhance IPFIX NAT Logging with pps/bps Metrics for
Improved Flow Monitoring
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).
1. 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
____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.
_______________________________________________
OPSAWG mailing list -- [email protected]
To unsubscribe send an email to [email protected]
