Re: [ippm] John Scudder's Discuss on draft-ietf-ippm-ioam-ipv6-options-10: (with DISCUSS and COMMENT)

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

Hi John,

Thanks a lot for your comments - and thanks for already clearing your DISCUSS based on the draft-ietf-ippm-ioam-ipv6-options-11 - which addresses the "IOAM-Domain" topic. We've just posted  version -12 - which also addresses your other comments. Please see below.

> -----Original Message-----
> From: John Scudder via Datatracker <[e-mail]>
> Sent: Wednesday, 8 March 2023 21:29
> To: The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail]
> Subject: John Scudder's Discuss on draft-ietf-ippm-ioam-ipv6-options-10:
> (with DISCUSS and COMMENT)
> 
> John Scudder has entered the following ballot position for
> draft-ietf-ippm-ioam-ipv6-options-10: Discuss
> 
> 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/about/groups/iesg/statements/handling-ballot-
> positions/
> for more information about how to handle DISCUSS and COMMENT
> positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-ipv6-options/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> # John Scudder, RTG AD, comments for draft-ietf-ippm-ioam-ipv6-options-
> 10
> CC @jgscudder
> 
> ## DISCUSS
> 
> Thanks for taking care of my previous DISCUSS! I'm so sorry to have to raise
> another one, related to the new text.
> 
>    C1  IOAM MUST be deployed as a limited domain feature as defined in
>       [RFC8799].
> 
> I applaud your desire to be prescriptive and concise. Unfortunately, I think
> there are a few problems here. First the small ones: you have RFC 8799 as
> an
> Informative reference, which is problematic since you want to make
> adherence to
> it mandatory. But, if you move it to be a Normative reference (as seems
> indicated), then we encounter two further issues: first and less importantly,
> it’s not an IETF document, so possibly needs to be treated as a downref?
> 
> But most importantly, as far as I can tell RFC 8799 does not define “a
> limited
> domain feature”. It provides a taxonomy for talking about limited domains
> and
> various considerations, but nothing I would call a “definition”. I confess I’ve
> only briefly reviewed 8799 just now, not fully re-read it, so maybe you will
> be
> able to point me to a clear and actionable definition, that an implementor
> of
> your spec could apply in order to comply with C1. If so, please do let me
> know
> what that definition is, and also update your reference to cite it
> specifically, rather than just the RFC number. In my own review of 8799, the
> closest I see is Section 6, "Functional Requirements of Limited Domains”. I
> will be a little surprised if you really want to require adherence
> requirements
> 1-11 in that section, though.
> 
> Sadly, I suspect that you’ll end up concluding that RFC 8799 isn’t fit for the
> purpose you’re trying to use it for and that you’ll need to write out in your
> own words what the specific requirements are for your case. It looks to me
> as
> though the taxonomy section of RFC 8799 might be quite useful to you in
> that
> respect, indeed that seems to be partly what it’s for:
> 
> ```
> A.9. Making Use of This Taxonomy
> 
> This taxonomy could be used to design or analyze a specific type of limited
> domain. ```
> 
> It’s unfortunate that we don’t have a good, citable definition of “limited
> domain” in our document set... but we don’t. This might be merely because
> nobody has bothered to write it yet, although I think the real reason is
> more
> likely that it turns out to be a sticky problem to nail it down to a definition
> that is both general enough to be broadly applicable and specific enough to
> be
> actionable.

...FB: Thanks again for the comments above - and thanks for already clearing the DISCUSS based on revision -11.
The approach that revision -11 took for the IOAM-Domain is similar to what was done for segment routing architecture  RFC8402 (Sections 8.2. and 2.).


> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> ## COMMENT
> 
> Thanks for taking care of many of my previous comments. A few appear not
> to
> have been addressed in version 10 nor responded to in email, please forgive
> me
> if I've missed a response. I repeat the comments below, with section
> numbers
> updated to match the numbering in version 10.
> 
> ### Section 3, reference for IOAM Type, nomenclature
> 
> ```
> IOAM Type: 8-bit field as defined in section 7.1 in [RFC9197].
> ```
> 
> Section 7.1 of RFC 9197 is the IOAM Option-Type Registry in the IANA
> Considerations section. I wouldn't say an IANA registry "defines" anything,
> it
> lists code points. I think a better reference would be Section 4 of 9197,
> which
> does indeed define IOAM-Option-Types (in Section 4.1).
> 
> Also, it would be better to be consistent with your naming, in RFC 9197 you
> don't call this the "IOAM Type" but rather the "IOAM-Option-Type" (34
> occurrences in 9197) or "IOAM Option-Type" without the first hyphen (4
> occurrences in 9197). I see why you don't want to use the full string from
> RFC
> 9197 in your packet diagram (too many characters) but "IOAM-Opt-Type"
> would fit
> in the character budget.

...FB: Thanks. This is indeed confusing. 
The latest revision uses "IOAM-Opt-Type" in the diagram and "IOAM-Option-Type" 
in the associated description:

   IOAM-Option-Type:  Abbreviated to "IOAM-Opt-Type" in the diagram
      above: 8-bit field as defined in section 4.1 of [RFC9197].

> 
> ### Section 4.2, encapsulation?
> 
> ```
> For deployments where the IOAM domain is bounded by hosts, hosts will
> perform
> the operation of IOAM data field encapsulation and decapsulation. ```
> 
> Do you intend to imply that the hosts at the edge of the domain are
> sending
> IP-in-IPv6 encapsulated data? It wouldn't seem to be required; since the
> hosts
> are the source/sink of the packets, the problem described in C6 doesn't
> apply,
> and the host can directly place the IOAM data in the header. (What would
> be the
> "inner header" in an overlay solution.)
> 
> I suppose it's technically accurate to describe this as an "encapsulation and
> decapsulation" operation, insofar as any data placed in any header might be
> said to be encapsulated in that header -- but it's misleading. I think this
> section needs to be rewritten to make the meaning plain. For example,
> something
> like "... hosts will place the IOAM data field directly in the IPv6 header."
> (You could say "outer IPv6 header" since there's nothing precluding a host
> from
> sending tunneled packets for some purpose.)
> 
> (I notice Éric Vyncke raises a similar concern about the nontraditional use of
> the term "encapsulation" in his comments.)

...FB: "Encapsulation/Decapsulation" could indeed be misread - as you and Eric pointed out.
Revision -12 now references RFC 9197 for the definition of these terms for this document - and also provides a short description in the intro section:

   The terms "encapsulation" and "decapsulation" are used in this
   document in the same way as in [RFC9197]: An IOAM encapsulating node
   incorporates one or more IOAM-Option-Types into packets.  An IOAM
   decapsulating node removes IOAM-Option-Type(s) from packets.

In addition, we've updated section 4.2 according to your suggestion:

4.2.  IOAM domains bounded by hosts

   For deployments where the IOAM domain is bounded by hosts, hosts will
   perform the operation of IOAM data field encapsulation and
   decapsulation, i.e., hosts will place the IOAM data fields directly
   in the IPv6 header or remove the IOAM data fields directly from the
   IPv6 header.  IOAM data is carried in IPv6 packets as hop-by-hop or
   destination options as specified in this document.

> 
> ### Section 4.3, encapsulation again
> 
> This one is less misleading, but by analogy to 4.2 I suspect more clarity is
> required here too.
> 
> ```
> For deployments where the IOAM domain is bounded by network devices,
> network
> devices such as routers form the edge of an IOAM domain. Network devices
> will
> perform the operation of IOAM data field encapsulation and decapsulation.
> ```
> 
> For example, a more straightforwardly understandable version of the last
> sentence might be "Network devices will encapsulate in-flight packets in an
> outer IPv6 header which carries the IOAM data field."

...FB: Much like for section 4.2 - we also followed you suggestion for 4.3:

4.3.  IOAM domains bounded by network devices

   For deployments where the IOAM domain is bounded by network devices,
   network devices such as routers form the edge of an IOAM domain.
   Network devices will perform the operation of IOAM data field
   encapsulation and decapsulation.  Network devices will encapsulate
   IOAM data fields in an additional, outer, IPv6 header which carries
   the IOAM data fields.


Thanks again for all your guidance and help!

Cheers, Frank
 
> 
> ## Notes
> 
> This review is in the ["IETF Comments" Markdown format][ICMF], You can
> use the
> [`ietf-comments` tool][ICT] to automatically convert this review into
> individual GitHub issues.
> 
> [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
> [ICT]: https://github.com/mnot/ietf-comments
> 
>