Re: [IPFIX] Full or Truncated EHs RE: Some comments on draft-ietf-opsawg-ipfix-tcpo-v6eh

["Aitken, Paul" <[e-mail]>]

Med, I reviewed the current draft-ietf-opsawg-ipfix-tcpo-v6eh.


1.1 "Specify how to automatically update the IANA IPFIX registry"

- is "automatically" correct? I didn't see any mention of this later in the draft.



1.2 "Support means to report the observed Experimental Identifiers (ExIDs) that are carried in shared TCP options (kind=253 or 254)"

- it took me far too long to parse this correctly. Would "Allow reporting of the observed Experimental Identifiers ..." be clearer?



2. Conventions and Definitions

- s/Template/Template Record/

- Collector, Data Record, Flow Record, Exporting Process, Collecting Process are not used in the document, so they should be removed.



3. "to address some of the issues listed in Section 1.1."

- just some of the issues but not all of them?



3.1 "while bit 254 corresponds to the most-significant bit of the IE."

- 256 bits (2^8) are numbered 0 to 255 or 1 to 256, but never up to 254.



3.1 The "No Next Header" (59) value is used if there is no upper-layer header in an IPv6 packet. Even if the value is not considered as an extension header as such, the corresponding bit is set in the ipv6ExtensionHeadersFull IE whenever that value is encountered in the Flow.

- This goes against the previous paragraph, "In doing so, few octets will be needed to encode common IPv6 extension headers when observed in a Flow." because flows with no EH will require at least 8 octets to set bit 59.



3.1 "Several extension header chains may be observed in a Flow. These extension headers may be aggregated in one single ipv6ExtensionHeadersFull Information Element or be exported in separate ipv6ExtensionHeadersFull IEs, one for each extension header chain."

- say whether or not the order of those IEs is important. eg, an intermediate IPFIX device might not preserve the order.



3.2. ipv6ExtensionHeaderCount Information Element

- consider naming this in plural, "ipv6ExtensionHeadersCount", for consistency with the other IEs defined here.



3.2 "and number of consecutive occurrences"

- remove "consecutive"?



3.2. "If several extension header chains are observed in a Flow, each header chain MUST be exported in a separate ipv6ExtensionHeaderCount IE."

- say whether or not the order of those IEs is important.



3.2 "the occurrences that are observed before the Fragment header and the occurrences right after the Fragment header."

- singular, "the occurrence".



3.2 (Figure)

- please name/number the figure and move the bit numbers rightwards one place, consistent with the figures in section 6.

- the count is limited to 8 bits, bu there was no previous mention of this. Say what to do when the count is exceeded.



3.2 Data Type Semantics:

- this is not an identifier. It seems be a new type consisting of (type, count) tuples.



3.3 e.g., ipv6ExtensionHeaderFull

- typo: it's ipv6ExtensionHeadersFull



3.3. ipv6ExtensionHeadersLimit Information Element

- Why use negative logic (ie, where "false" indicates a complete set of IPv6 headers). It would make more sense for this to be "true" when matching and "false" when not matching.



3.3 See [RFC8883] for an example of IPv6 packets processing

- singular "packet processing"



3.4. However, it was regularly reported

- by who? Where? Cite references or it didn't happen!



3.4 "The ipv6ExtensionHeadersChainLength IE is used to report, in octets, the length of an extension header chain observed in a Flow. The length is the sum of the length of all extension headers of the chain."

- say whether multiple IEs are to be exported, one per chain. If so, then say whether order is important.



4.1 Option number X is mapped to bit position "254 - X".

- please, NO! Nobody's going to do that. Please use the same encoding as in 3.1.

- BTW TCP option numbers begin at 0 so it should be "255 - X".



4.2. tcpSharedOptionExID Information Element

- From the description here, I did not understand how to encode the IE.



4.2 Expermients IDs ... (or 4-bute)

- typos



6.1 IPv6 Extension Headers

- this section is actually about "ipv6ExtensionHeadersFull"



6.1 This section provides few examples to illustrate the use of some IEs defined in the document.

- move this text to section 6.



6.1 Figure 1

- there should be 256 bits, numbered 0 to 255.

- the numbering above the middle and right-most blocks is mis-aligned. Compare with Figure 2.



6.1 Figure 2

- again there should be 256 bits, numbered 0 to 255.

- draw figures 1 and 2 as figure 3, with only one section of ellipsis.

- referring to section 9.1 of I-D.ietf-opsawg-ipfix-fixes] for the IPv6 Hop-by-Hop Options, Routing, and Destination Options headers bits:

     1, HOP       0       Hop-by-hop option header
     0, DST      60       Destination option header
     5, RH       43       Routing header

- so please list the headers in order!

- this shows that the bits 0, 1, and 5 should be set - so the figure should show "1 0 0 0 1 1" rather than "0|1|0|0|1|1|".



6.2. TCP Options

- Reword "Given TCP kind allocation practices"

- "Concretely, the tcpOptionsFull IE will be set to 15." --> no, "1|1|0|1|" = 8 + 4 + 1 = 13.



8 TBD3 ipv6ExtensionHeaderLimit

- typo, it's "ipv6ExtensionHeadersLimit"



P.