Re: [ippm] Éric Vyncke's No Objection on draft-ietf-ippm-ioam-data-12: (with COMMENT)

[Tal Mizrahi <[e-mail]>]

Hi Éric,

Many thanks for the comments.
We are currently working on an updated version of the draft that will
accommodate the comments.

Please see our responses and proposed changes below.
Please let us know if there are further comments.

Thanks,
Tal.

On Thu, Mar 25, 2021 at 10:34 AM Éric Vyncke via Datatracker
<[e-mail]> wrote:
>
> Éric Vyncke has entered the following ballot position for
> draft-ietf-ippm-ioam-data-12: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-data/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Thank you for the work put into this document and thank you for acknowledging
> my comments and advices (as they were minor, I am not recusing myself).
> Sometimes the text is difficult to read as paragraphs and sentences are long
> and somehow repetitive.
>
> Please find below  some non-blocking COMMENT points (but replies would be
> appreciated), and some nits. Like Alvaro, I was hesitating to ballot a DISCUSS
> on one point about section 4 (insertion/deletion of data on the flight).
>
> I hope that this helps to improve the document,
>
> Regards,
>
> -éric
>
> == COMMENTS ==
>
> -- Abstract --
> "a path between two points in the network" does this mean that this document
> cannot be used with a multicast destination address ?
>

Proposed text update:
OLD:
traverses a path between two points in the network
NEW:
traverses a path in the network

> -- Section 2 --
> Is the list about 'contributors' (as in the section title) or 'co-authors' (as
> in the text) ?
>

After a bit of discussion with the WG chairs, this was the text that
was recommended for this section.

> -- Section 3 --
> Please use the BCP14 boilerplate
>

Right. Will be fixed.

> Please note that Geneve is now RFC 8926.
>

Right. Will be fixed.

> -- Section 4 --
> Should the 'deployment domain' include a reference to RFC 8799 ?
>
> I was about to ballot a DISCUSS on this one: While the actual encapsulation is
> out of scope, the definition of "IOAM control points" alludes to nodes at the
> edge and in the core being able to add/remove data fields. This behavior will
> obviously have some impacts on the PMTU discovery and possibly on the handling
> of ICMP. Did the authors think of writing a generic section in this document on
> how this can be done in a correct way?
>

Right. This was also pointed out by other IESG members, and we plan to
clarify this text, including a reference to RFC 8799.

> What is "live user traffic" ? I guess that this is not about end-user real-time
> video ;-) but a better wording would be welcome.
>

Right.
s/live / /

> I am afraid that "ships in the night" does not apply here as all ships are
> usually on the same layer ;-) (planes do flight at different flight levels)
> But, this is not that important. No need to reply.
>
> -- Section 5.1 --
> Is it expected to have additional IOAM data types than the 4 in this document?
> Text should clarify this.
>

Right. We will add the following text to section 5.1:
NEW:
Future IOAM-Option-Types can be allocated by IANA, as described in Section 8.1.

> -- Section 5.2 --
> "A transit node MUST NOT add new IOAM-Option-Types" seems to contradict the
> "IOAM control points" definition of section 4.
>

Section 4 says: "Devices which form an IOAM-Domain can add, update or
remove IOAM-Data-Fields."
Specifically, transit nodes can add data fields, but not option types.
This is clearly specified in Section 5.2, as well as the difference
between an encapsulating node and a transit node.


> -- Section 5.3 --
> If 0x0000 is already reserved, then I would suggest to make it part of the IANA
> range (i.e., making IANA range 0x0000 t 0x7FFF).
>

Right. This value is already defined in the IANA section as reserved.
The text just explicitly states what the meaning of value 0 is:
"0: default namespace (known to all IOAM nodes)"

> -- Section 5.4.2.5 --
> Should there be a precise definition (or reference) of "time in nanoseconds the
> packet spent in the transit node"? E.g., between first bit received and last
> bit sent ?
>

We tried to avoid explicitly specifying this, in order to avoid
mandating a specific hardware/software architecture.
We plan to add a general note to Section 5.4 that discusses the fact
that some of the node data fields have implementation specific
semantics:
NEW:
It should be noted that the semantics of some of the node data fields
that are defined below, such as the queue depth and buffer occupancy,
are implementation specific. This approach is intended to allow IOAM
nodes with various different architectures.


> -- Section 5.4.2.7 --
> Is there a reason why the queue depth is expressed in buffers and not in
> packets? (Both metrics have useful values imho)
>

Right, again this goes back to the note about implementation specific
semantics. We hope the note we are adding to Section 5.4 addresses
this.

> -- Section 5.5 --
> In "Random: Unique identifier for the packet" how are collisions resolved? Do
> they matter at all ?
>

Good point, and we will add some text about this to the PoT draft. The
current draft only defines the fields. The detailed functionality is
specified in the PoT draft.

> How can a transit/decaps node can handle the PoT (and also the E2E of section
> 5.6) as the length is not specified in the header ?
>

The length of the PoT option is constant, and thus a node that detects
the presence of a PoT option knows its length.
For the E2E option, a node that parses the IOAM-E2E-Type field knows
the length of the option.

> == NITS ==
>
> Usually "e.g." is enclosed between commas.
>
> The sentence "The definition of how IOAM-Data-Fields are encapsulated into
> other protocols is outside the scope of this document." or a minor variation of
> it occurs multiple times in the document. Please consider avoiding those
> repetitions.
>
>
>