Hello Med, Adding a new IE to signal the issue, why not ? I usually do not like too much having a ‘negative signalling’, i.e., the absence of an IE having an important meaning. But, up to the authors & WG to decide of course
Regards -éric From: [email protected] <[email protected]> Date: Monday, 9 October 2023 at 14:10 To: Eric Vyncke (evyncke) <[email protected]>, [email protected] <[email protected]> Cc: [email protected] <[email protected]> Subject: Full or Truncated EHs RE: Some comments on draft-ietf-opsawg-ipfix-tcpo-v6eh Hi Éric, “There should be a way to convey the information that the exporter was (un)able to parse the *full* extension header chain due to HW limitation. This could be done by adding a bit/counter “KNOWN” (the opposite of UNKNOWN in the sense of a known layer-4 header).” I think that it would be simple to return that in a separate IE. Please refer to the proposal at: Extended TCP Options and IPv6 Extension Headers IPFIX Information Elements (boucadair.github.io)<https://boucadair.github.io/ipfix-tcpoptions-and-v6eh/draft-ietf-opsawg-ipfix-tcpo-v6eh.html#name-ipv6extensionheaderslimit-i>. The absence of this IE is an indication that any EH-related IE reflect the full set of enclosed EHs. Cheers, Med De : OPSAWG <[email protected]> De la part de Eric Vyncke (evyncke) Envoyé : vendredi 6 octobre 2023 14:49 À : [email protected] Cc : [email protected] Objet : [OPSAWG] Some comments on draft-ietf-opsawg-ipfix-tcpo-v6eh Benoît and Med, Thanks for this useful document, please find below some comments (obviously without any hat). Should the “No Next-Header” (next-header=59) be included (cfr my other remarks on the companion I-D) ? There should be a way to convey the information that the exporter was (un)able to parse the *full* extension header chain due to HW limitation. This could be done by adding a bit/counter “KNOWN” (the opposite of UNKNOWN in the sense of a known layer-4 header). About having counters per extension header how is “This Information Element echoes the order and number of occurrences” to be interpreted for the following flow? HBH-RH-DST HBH-DST-RH-FRA0-DST HBH-DST-RH-FRA1-... RH-DST Will it be a single IE with HBH=3, DST=5, RH=3, FRA0=1, FRA1=1 or 4 IE exported (one for each chain) ? I think that the 4 IE sounds more logical and useful, then there is no need to count the occurrences of one specific EH but more how often a specific EH chain was seen. I still wonder why the tcpOptions and ipv6ExtensionHeaders are in the same I-D though ;-) Hope this helps, -é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.
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
