Hi Jeff,
Thanks for your review. You make a good point.
Like for any IPFIX-related drafts or RFCs, we have to distinguish the
IPFIX Exporting Process & the IPFIX Metering Process.
See RFC 7011 for the definitions.
The recently published IPFIX RFCs focus on the Exporting Process:
9870 <http://www.rfc-editor.org/info/rfc9870> *Export of UDP Options
Information in IP Flow Information Export (IPFIX)*
9740 <http://www.rfc-editor.org/info/rfc9740> *New IPFIX Information
Elements for TCP Options and IPv6 Extension Headers*
9565 <http://www.rfc-editor.org/info/rfc9565> *An Update to the
tcpControlBits IP Flow Information Export (IPFIX) Information Element
*9487 <http://www.rfc-editor.org/info/rfc9487> *Export of Segment
Routing over IPv6 Information in IP Flow Information Export (IPFIX)**
*
So basically, they specify the IPFIX Information Elements, assuming that
the IPFIX Metering Process is able to meter them.
To take an example closed to your heart: BGP
The Exporter must run BGP and the IPFIX Metering Process must be able to
do a lookup in the BGP table at the point of observation.
In the SAV example here, we must run the SAV enforcement on the
Observation Domain, like for BGP.
So far, I have not told you anything that you don't know, I know :-)
As you noted below, there is an extra condition in the SAV case, "as a
discrete layer in the forwarding pipeline" as you describe it.
Somehow, this SAV case is more like the ForwardingStatus (IE 89)
In essence, the Metering Process can not report what it can not
observe/loop up/deduce. If we don't know why it's dropped, we can't
report it.
This is an implicit statement in most of the IPFIX RFCs. As a kind of
proof, I looked up the 4 RFCs above, and there is only one occurrence of
"Metering Process".
However, we should document your statements
I believe they would be a perfect fit for the "Operational
Considerations", RFC5706bis. Does it make sense?
Or do you have something else in mind, such as having the SAV drops in
draft-ietf-opsawg-discardmodel and/or its companion draft
draft-evans-opsawg-ipfix-discard-class-ie-01
<https://datatracker.ietf.org/doc/draft-evans-opsawg-ipfix-discard-class-ie/>?
Regards, Benoit
Cao Qian,
Thanks for the draft. IPFIX is a good protocol to expose SAV
enforcement in a scalable fashion.
Unfortunately, it'll also be a difficult place to report properly. I
don't have explicit recommendations for your draft at this time to
address the points I'm about to raise, but I'd recommend much like all
of the existing SAV work to document challenges for better discussion.
The SAV architecture mechanisms covered in this draft can be reported
well only if the implementation is explicitly implementing SAV
enforcement as a discrete layer in the forwarding pipeline. When that
is the case, the proposed IEs are mostly appropriate for that proposed
architecture. As a note for OPSAWG, enforcement is likely to be
implemented via a mixture of mechanisms for scalability purposes - and
that can impact reporting.
To give two explicit examples of where such reporting can be problematic:
- When traffic is allowed, this may be done without having passed
through an explicit filter. In such a case, knowing that an interface
implements SAV filtering is possibly useful metadata associated with
the flow. However, it may simply be considered noise by the telemetry
infrastructure. I suggest documenting that explicit permit can only
be guaranteed in flow if the forwarding pipeline permits such
layer-wise tagging.
- When traffic is discarded, the forwarding pipeline may not
discretely know whether it is because of SAV enforcement vs. other
discard reasons. The caveat appropriate for your draft is that SAV
telemetry should consider not only explicitly tagged drops, but also
consider other sources of drops that may be applied in the pipeline as
part of the implementation. The discardmodel[1] is an example of
discussing such drops.
-- Jeff
[1] https://datatracker.ietf.org/doc/draft-ietf-opsawg-discardmodel/
On Oct 27, 2025, at 10:59 AM, 曹倩
<[email protected]> wrote:
Hello OPSAWG,
Apologies for the previous email with an incorrect link. Our draft
has now been officially posted.
The correct and active link is now available:
*
*
*Title: *Export of Source Address Validation (SAV) Information in IPFIX
*Datatracker
Link：*https://datatracker.ietf.org/doc/draft-cao-opsawg-ipfix-sav/
We welcome any feedback and thoughts on this draft.
Best Regards,
Cao Qian (on behalf of the co-authors)
-----原始邮件-----
*发件人:*曹倩 <[email protected]>
*发送时间:*2025-10-20 23:49:54 (星期一)
*收件人:*[email protected],[email protected]
*主题:*Individual draft submission: draft-cao-opsawg-ipfix-sav-00
Dear OPSAWG and SAVNET Working Groups,
<https://datatracker.ietf.org/doc/draft-opsawg-ipfix-sav/>
I'm pleased to share with you our new individual draft on IPFIX
for SAV.
*Title: *
Export of Source Address Validation (SAV) Information in IPFIX
*Abstract: *This document specifies the IP Flow Information
Export Information Elements to export the context and outcome of
Source Address Validation enforcement data, providing insight
into why packets are identified as spoofed by capturing the
specific SAV rules that triggered validation decisions.
The document is available at:
<https://datatracker.ietf.org/doc/draft-opsawg-ipfix-sav/>
https://datatracker.ietf.org/doc/draft-opsawg-ipfix-sav/
Please review the document and share your thoughts on the mailing
list. Comments and suggestions are welcome.
Thank you for your consideration.
Best regards,
Cao Qian
ZGC LAB
_______________________________________________
OPSAWG mailing list [email protected]
To unsubscribe send an email [email protected]
_______________________________________________
OPSAWG mailing list [email protected]
To unsubscribe send an email [email protected]
_______________________________________________
OPSAWG mailing list -- [email protected]
To unsubscribe send an email to [email protected]
