Re: [Detnet] John Scudder's No Objection on draft-ietf-detnet-ip-oam-12: (with COMMENT)

[Greg Mirsky <[e-mail]>]

Hi John,
I appreciate your support of this work. Please find my notes below tagged
GIM>>. I've attached the working version that includes all the updates
applied based on your suggestions.

Regards,
Greg

On Mon, Feb 12, 2024 at 1:19 PM John Scudder via Datatracker <
[e-mail]> wrote:

> John Scudder has entered the following ballot position for
> draft-ietf-detnet-ip-oam-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/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-detnet-ip-oam/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Thanks for this document. I have some mostly minor comments below, that I
> hope
> may be helpful. Also, thanks to Roman for being special guest AD, and to
> János
> for the clear and helpful shepherd write-up.
>
> ### Section 2.1, unused
>
> Defined, never used:
>
> - DiffServ (but I notice 'DSCP' is used without expansion in Section 3)
>
GIM>> Removed and replaced DSCP with the expanded form

> - PREF (except it's used by a later definition)
>
GIM>> REmoved and replaced PREF with the expanded form

> - POF
> - RDI
>
GIM>> Removed and removed

>
> I think all these could be removed (folding PREF into the 'Detnet Node'
> definition where it's used).
>
> Defined, only used once:
>
> - ACH is used in Figure 1, and you provide a definition in-line, which is
> sufficient, so I think this could be removed from §2.1. - Underlay
> network, in
> this case, the definition seems useful since it keeps the paragraph in §3
> more
> concise.
>
GIM>> Removed ACH from the Terminology. Added PREOF expansion as the
footnote of Figure 1.

>
> ### Section 3, this sentence no verb
>
> It took me longer than I would care to admit to work out that what's
> missing in
> this sentence is the verb "to be":
>
> "The DetNet data plane encapsulation in a transport network with IP
> encapsulations specified in Section 6 of [RFC8939]."
>
> I.e. it needs an "is" before "specified".
>
GIM>> Thank you, I agree.

>
> ### Section 3, "e.g." or "i.e."
>
> In the below-quoted sentence, do you really mean "e.g."? That is, are you
> stating an example? It doesn't look that way to me, it looks as though you
> mean
> "in other words", not "for example" which is what "e.g." means. If you
> mean "in
> other words", what you want is "i.e.", or just write out "in other words"
> for
> the avoidance of all uncertainty.
>
> "In order to use ICMP for these purposes with DetNet, DetNet nodes must be
> able
> to associate ICMP traffic between DetNet nodes with IP DetNet traffic,
> e.g.,
> ensure that such ICMP traffic uses the DetNet IP data plane in each node,
> otherwise ICMP may be unable to detect and localize failures that are
> specific
> to the DetNet IP data plane."
>
GIM>> Thank you for raising this question. You are correct; the intention
was "in other words," and I updated the text accordingly.

>
> ### Section 3.1, co-routing via UDP source port
>
> I'm mulling over "may be able to achieve co-routedness of OAM with the
> monitored IP DetNet flow in multipath environments, e.g., Link Aggregation
> Group or Equal Cost Multipath, via use of a UDP source port value that
> results
> in the OAM traffic and the monitored IP DetNet flow hashing to the same
> path
> based on the packet header hashes used for path selection".
>
> I guess this is true, but the word "may" is doing a lot of work here. The
> counter-case is when the hash function isn't uniform among all forwarders
> in
> the network. In such cases, it might not be possible to use this technique
> to
> co-route the OAM with a monitored flow.
>
> I guess this might just be a case of ¯\_(ツ)_/¯ though -- your document is
> saying "you have to have co-routing to get good OAM"... if the network
> isn't
> able to provide co-routed paths, then oh well, we can't have good OAM,
> perhaps
> it means we need to rearchitect the network?
>
> If you agree, is it worth saying a few words to that effect (maybe without
> the
> shrug emoji) in this section?
>
GIM>> You've captured and expressed the message correctly, thank you. Would
the following text make that position clear:
NEW TEXT:
   It is essential to ensure that specially constructed
   OAM packets traverse the same set of nodes and links and receive the
   same network QoS treatment as the monitored data flow, e.g., a DetNet
   flow, for making active OAM useful.

>
> ### Section 4, wrong xref
>
> "Interworking between DetNet domains with IP and MPLS data planes analyzed
> in
> Section 6.2 of [I-D.ietf-detnet-mpls-oam]."
>
> There is no Section 6.2 of draft-ietf-detnet-mpls-oam-15. Section 6 is
> Security
> Considerations. Probably you mean Section 4.2?
>
GIM>> Thank you for catching the stale reference. Fixed.

>
> ### Section 7
>
> You have "TBA" as the whole body of this section. I guess it's time to
> either
> put something there or delete the section. :-)
>
GIM>> Removed.