Re: [IPFIX] Some IPv6 comments on draft-ietf-opsawg-ipfix-fixes-02

["Eric Vyncke (evyncke)" <[e-mail]>]

Hello Med,

Thanks for the conversation on this interesting topic.

See in-line for EVY>

Bien à toi,

-éric

From: [e-mail] <[e-mail]>
Date: Monday, 9 October 2023 at 11:32
To: Eric Vyncke (evyncke) <[e-mail]>, [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: RE: Some IPv6 comments on draft-ietf-opsawg-ipfix-fixes-02
Hi Éric,

Thank you for the review.

Please see inline.

Cheers,
Med

De : OPSAWG <[e-mail]> De la part de Eric Vyncke (evyncke)
Envoyé : vendredi 6 octobre 2023 13:46
À : [e-mail]
Cc : [e-mail]
Objet : [OPSAWG] Some IPv6 comments on draft-ietf-opsawg-ipfix-fixes-02

Benoît and Med,

Thanks for this document, please find below some comments on the IPv6 sections (4.1 and 9.1), obviously wearing no hat. I like the idea of creating a registry mapping IPFIX IE bits to IPv6 extension headers, even if there won’t be any new IPv6 extension headers.

Another important issue is to export whether the full extension header chain has been parsed as some HW can only process so many headers or so many bytes. In this case, the bit mask is obviously incomplete. This could of course be another bit in the mask and could be specified in the companion I-D, draft-ietf-opsawg-ipfix-tcpo-v6eh.

[Med] Added this note:

“Some implementations may not be able to export all enclosed extension headers because of a hardware of software limit (see, e.g., {{?I-D.ietf-6man-eh-limits}}. The specification of the ipv6ExtensionHeaders Information Element does not discuss whether it covers all enclosed extension header or only update to a limit.”

Let’s discuss whether an explicit signal is needed to be encoded for this in draft-ietf-opsawg-ipfix-tcpo-v6eh.

EVY> fair enough, i.e., it looks good to me ;-)


# Section 9.1

Should there be an entry to “no next header” value ?
[Med] Not sure there is a value in exporting this one as part of the set. Do you see any? Thanks.

EVY> I tend to see value in ‘sensing/measuring’ what happens in a network. Else, the operator will never know that this header is used, or did I miss something ?

Should there be different bits for “destination options” as this one can happen *before* and *after* routing header ? Similar to FRA0 and FRA1 bits ?
[Med] This would be a major change to the IE while draft-ietf-opsawg-ipfix-fixes is supposed to cover simple “fixes”. draft-ietf-opsawg-ipfix-tcpo-v6eh addresses this as part of ipv6ExtensionHeaderCount.

EVY> as long as the 2 destination headers issue is fixed, I do not care in which document (even if the bit mask – this document – is easy to parse).

Please replace the “IPv6 options” column by “IP protocol number” or “IPv6 Next-Header Values”
[Med] OK, changed to “Protocol Number”

Use “IPv6 Hop-by-Hop Options” (plural) per RFC 8200 (even the IANA-EH registry is singular)
[Med] ACK.

The first “Note” already appears a couple of lines above ;-)
[Med] Yes, the second one is for action by IANA.

Hope this helps
[Med] Thank you.

EV> thanks for your reply

-éric







____________________________________________________________________________________________________________

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.