Re: [ippm] v6 option types for IOAM data fields

["Frank Brockners (fbrockne)" <[e-mail]>]

Thanks Mike. On the scope of an IOAM deployment: 
draft-ietf-ippm-ioam-data-04 clarifies in section 3 that IOAM is a domain focused feature, i.e. not expected to be deployed on the open Internet.

Frank

-----Original Message-----
From: C. M. Heard <[e-mail]> 
Sent: Montag, 29. Oktober 2018 16:03
To: 6man <[e-mail]>; IPPM <[e-mail]>
Cc: Frank Brockners (fbrockne) <[e-mail]>
Subject: Re: v6 option types for IOAM data fields

On Thu, 25 Oct 2018 15:06:57 +0000 Frank Brockners (fbrockne) wrote:
> Quick heads up: In the 6MAN meeting in BKK, we’ll review
> draft-ioametal-ippm-6man-ioam-ipv6-options-01 – which requests 2 
> option types from the DO/HbyH options sub-registry.
>
> While the bulk of the IOAM work is progressed in the IPPM WG, we’d 
> greatly appreciate your feedback on 
> draft-ioametal-ippm-6man-ioam-ipv6-options-01,
> which defines how IOAM data fields are carried using v6 extension headers.
> Cc’ing the IPPM WG as well, to keep everyone on the same page.

I have two brief comments on this work.

First, I see that the Incremental Tracing Option changes length in transit.
It is not appropriate for it to be carried in an IPv6 option intended for use on the open Internet, for exactly the same reason that insertion of extension headers by intermediate nodes is not allowed on the open Internet.

Second, I see that two IPv6 option code points are requested, one with the "chg" flag set, the other with the "chg" flag clear. While there is no harm in this, it is not strictly necessary; the only real purpose of this flag is to determine whether the option data is or is not included in the Authentication Header Integrity Check Value computation.

Mike Heard