Dear Prasad, Speaking as an operator who has IPFIX NAT event logging as per RFC 8158, IPFIX Flow Aggregation as per RFC 7015/7011 and BMP as per RFC 7854/9069 on the same network nodes operational, we export both, NAT events, flow account information and BGP RIB state information and correlate BMP with NAT events and BMP with flow accounting in real-time at the data collection and making it as a data product available in the data mesh. Since BMP establishes the correlation to the connectivity service, both NAT events and flows can be attributed to the connectivity service. Giving network operation the ability to monitor the following use cases:
* How many NAT translations are being established/terminated for a given
connectivity service at which time -> Capacity Management
* How much traffic has been forwarded or dropped for a given connectivity
service at which time -> Connectivity SLI/SLO
* Which customer data plane L3/L4 dimensions have been translated to which
for a given connectivity service at which time -> Troubleshooting
NAT events and flows are in my opinion not aggregate able since the time
stamps, the lifecycle, isn't equal. Since in flow account starting with the
first packet, flows are being accounted by the flow metering process and in
intervals exported until last packet has been observed (active/inactive
timeout). Where in NAT events the start and the end of the translation is being
accounted as event vs. duration.
Best wishes
Thomas
From: Prasad Yadati <yprasad=40juniper....@dmarc.ietf.org>
Sent: Wednesday, January 22, 2025 6:41 PM
To: mohamed.boucad...@orange.com; opsawg@ietf.org; Dan Wing (danw...@gmail.com)
<danw...@gmail.com>
Cc: repe...@cisco.com; ssent...@cisco.com
Subject: [OPSAWG]Re: Proposal to Enhance IPFIX NAT Logging with pps/bps Metrics
for Improved Flow Monitoring
Be aware: This is an external email.
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: mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>
<mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>>
Date: Friday, November 22, 2024 at 3:02 AM
To: Prasad Yadati <ypra...@juniper.net<mailto:ypra...@juniper.net>>,
opsawg@ietf.org<mailto:opsawg@ietf.org>
<opsawg@ietf.org<mailto:opsawg@ietf.org>>, Dan Wing
(danw...@gmail.com<mailto:danw...@gmail.com>)
<danw...@gmail.com<mailto:danw...@gmail.com>>
Cc: repe...@cisco.com<mailto:repe...@cisco.com>
<repe...@cisco.com<mailto:repe...@cisco.com>>,
ssent...@cisco.com<mailto:ssent...@cisco.com>
<ssent...@cisco.com<mailto:ssent...@cisco.com>>
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
<yprasad=40juniper....@dmarc.ietf.org<mailto:yprasad=40juniper....@dmarc.ietf.org>>
Envoyé : vendredi 1 novembre 2024 21:14
À : opsawg@ietf.org<mailto:opsawg@ietf.org>
Cc : repe...@cisco.com<mailto:repe...@cisco.com>;
ssent...@cisco.com<mailto:ssent...@cisco.com>
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.
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ OPSAWG mailing list -- opsawg@ietf.org To unsubscribe send an email to opsawg-le...@ietf.org
