Hi Jeffrey Haas & Benoit, Thank you for this very constructive discussion.
To build on Benoit's points from the SAV architecture perspective: to export SAV information, the Observation Domain must implement the SAVNET architecture. This means the exporters must run the SAV Agent and maintain the SAV Information Base (pls refer to Figure 3 Section 5.4 https://datatracker.ietf.org/doc/draft-ietf-savnet-intra-domain-architecture/). The IPFIX Metering Process for SAV retreives information from this SAV Information Base. This architecture is the foundation for the Metering Process to observe and report a discrete SAV action. In fact, the SAV architecture defines a clear sequence of validation -> decision -> monitoring. The IPFIX Sample action is triggered by the logical invalid state, prior to and independent of the final enforcement action (e.g., discard) (pls refer to the Section 4 the traffic monitor policies part https://datatracker.ietf.org/doc/draft-ietf-savnet-general-sav-capabilities/). This architectural design ensures that the Metering Process has clear and dedicated signals to report, regardless of whether the actual drop is implemented via ACL, uRPF, or other data-plane mechanisms. Thank you for your valuable feedback. We look forward to your further guidance. Cao Qian -----原始邮件----- 发件人:"Jeffrey Haas" <[email protected]> 发送时间:2025-10-30 22:21:11 (星期四) 收件人: "[email protected]" <[email protected]> 抄送: 曹倩 <[email protected]>, [email protected], 黄明庆 <[email protected]> 主题: Re: [OPSAWG]Re: [CORRECTED LINK] New I-D: draft-cao-opsawg-ipfix-sav-00 Benoit, On Oct 30, 2025, at 10:07 AM, [email protected] <[email protected]> wrote: 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 ? As I mentioned in my original mail, I don't have specific recommendations. This is where those with deeper expertise than my own old experience in flow implementations will be helpful. There is strong overlap with the forwarding status IE, and also the discard options we're exploring for the discardclass draft. I can see that it may make sense for SAV cases for SAV enforcement to be emitted using those IEs since the enforcement are just special cases of existing behaviors. However, whether this can be practically accomplished depends on the implementation not only of the forwarding pipeline, but also the SAV mechanism. My early goal is thus more to highlight that discrete events may be challenging and should be discussed. With regard to operational considerations, here is my opinion on boilerplate text: It is often the case in standards documents that a particular subject matter should be discussed in consistent wording. Especially when it is the case that the matter is not the primary subject of the document, nor particular expertise of the authors, it is better that there be consistency in how that matter is discussed. Having pre-defined recipes provided by subject matter experts for such important language is useful. Requiring it to be incorporated in a document not primarily about that subject matter is distracting and repetitious. Referencing well known sources is great! My favorite example of success for such things is RFC 4949 for Internet security. So, using this as an example, I'm highly supportive of a broad IPFIX operational considerations document that can be referenced in various documents. -- Jeff
_______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
