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
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
