Re: [IPFIX] Desambiguite unknwon EH vs. unknown upper layer headers RE: Some comments on draft-ietf-opsawg-ipfix-tcpo-v6eh

[Benoit Claise <[e-mail]>]

Eric,

On 10/6/2023 4:19 PM, [e-mail] wrote:
>
> Re-,
>
> Your comment about “unknown L4” reminded me another comment you had 
> about how to disambiguate unknown EH vs. upper layer headers:
>
> Our local copy includes now the following NEW text:
>
>    If an implementation determines that it includes an extension header
>
>    that it does no support, then the exact observed code of that
>
>    extension header will be echoed in the ipv6ExtensionHeadersFull IE.
>
>    How an implementation disambiguates between unknown upper layers vs.
>
>    extension headers is not IPFIX-specific.
>
Med's proposal is about right.

You wrote "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.". Obviously, this would be an interesting information 
to know from a Collector point of view but the question is: Is IPFIX in 
the business of reporting Exporter capabilities, and specifically 
hardware capabilities? I am not convinced.

Regards, Benoit

> See Diff: draft-ietf-opsawg-ipfix-tcpo-v6eh-01.txt - 
> draft-ietf-opsawg-ipfix-tcpo-v6eh.txt 
> <https://author-tools.ietf.org/api/iddiff?doc_1=draft-ietf-opsawg-ipfix-tcpo-v6eh&url_2=https://boucadair.github.io/ipfix-tcpoptions-and-v6eh/draft-ietf-opsawg-ipfix-tcpo-v6eh.txt>
>
> Please let us know if you think this is (not) sufficient. Thanks
>
> Cheers,
>
> Med
>
> *De :*OPSAWG <[e-mail]> *De la part de* Eric Vyncke 
> (evyncke)
> *Envoyé :* vendredi 6 octobre 2023 14:49
> *À :* [e-mail]
> *Cc :* [e-mail]
> *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.
>
> _______________________________________________
> IPFIX mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ipfix