Dear authors, I finally got some time to read the draft. I have the same comment as Greg, Standard track seems more appropriate.
Also, I have also read RFC9341 and Alt-Mark can also compute the delay between the ingress interface and the egress interface within a single node (node monitoring). I have done a quick research on the IPFIX registry, AFAIK, the only delays defined in that registry are from the current work from draft-ietf-opsawg-ipfix-on-path-telemetry. Yet this delay is between the encapsulating node and the local node. I wonder if it is worth defining an IE for the delay between the ingress and the egress interface within a single node. I would imagine an implementation able to monitor both interfaces and just exporting the average delay directly from the node (or even the mean, max, min as draft-ietf-opsawg-ipfix-on-path-telemetry are doing). Any thoughts about this? Other than that, I think the draft is well written and it explains clearly why these IEs are necessary for IPFIX. Regards, Alex > On 25 Apr 2024, at 17:19, Greg Mirsky <gregimir...@gmail.com> wrote: > > Dear, Authors et al., > thank you for your continued work on the Alternate Marking method. In my > opinion, draft-gfz-opsawg-ipfix-alt-mark provides an essential IEs making the > use of IPFIX operationally viable option for the Alternate Marking method. > While I've read the document, it seems that its current track, Informational, > may not be consistent with the request for specific actions from IANA. Could > it be that the Standard track is more appropriate for the draft? > > Regards, > Greg > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
