Dear All, Please note that we have published the new version of the draft to address the comments from Med.
Your reviews are always welcomed. Regards, Giuseppe From: Giuseppe Fioccola <giuseppe.fioccola=40huawei....@dmarc.ietf.org> Sent: Monday, July 15, 2024 11:34 AM To: mohamed.boucad...@orange.com; draft-ietf-opsawg-ipfix-alt-m...@ietf.org; opsawg@ietf.org Subject: RE: Review of draft-ietf-opsawg-ipfix-alt-mark Hi Med, Thank you for your detailed review! I will definitely address your comments in the next version. Regarding the issue you raised about the operation mode, we will also add more text to clarify. With Alternate Marking (RFC 9341, RFC 9342), each node needs to export the packet counters and timestamps at each period for the monitored flow, according to AltMark operation. To identify and export telemetry data for an AltMark monitored flow, it is needed a combination of already existing IEs and new IEs, which are introduced in this draft. A flow can be identified using IEs such as source address, destination address, protocol and ports. But, according to RFC 9343 and any other AltMark protocol extensions, we also need to define new IEs (the flow identifier FlowMonID, the Period ID, the L flag and the D flag) to complete the AltMark information to be exported. I think it makes sense to add those considerations in the draft in order to answer your questions. Regards, Giuseppe From: mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com> <mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>> Sent: Friday, July 12, 2024 5:20 PM To: draft-ietf-opsawg-ipfix-alt-m...@ietf.org<mailto:draft-ietf-opsawg-ipfix-alt-m...@ietf.org>; opsawg@ietf.org<mailto:opsawg@ietf.org> Subject: Review of draft-ietf-opsawg-ipfix-alt-mark Hi Thomas, all, I couldn't manage to review this spec during the call for adoption, but here is quick review of the adopted version :-) I failed to understand the theory of operations. The text talks about new IEs (but there are none). There is a new registry, but the description text fails (at least to me) to convey how the pieces are plugged together. I'm sure I'm missing something. May be I'm puzzled because the alternate making can be present in various layers (see RFC 9506) and wasn't sure how the spec helps unambiguously identify which channel the bits comes from nor whether you intend to cover cases where the alternate marking is set in distinct layers (this is suboptimal but this may happen if no coordination is in place). FWIW, you can see the detailed comments at: * Pdf: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/2024/draft-ietf-opsawg-ipfix-alt-mark-00-rev%20Med.pdf * Doc: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/2024/draft-ietf-opsawg-ipfix-alt-mark-00-rev%20Med.doc Cheers, Med ____________________________________________________________________________________________________________ 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 -- opsawg@ietf.org To unsubscribe send an email to opsawg-le...@ietf.org
