Eric,
On 10/6/2023 4:19 PM, [email protected] 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 <[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.
_______________________________________________
IPFIX mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipfix
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
