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

["Black, David" <[e-mail]>]

Hi John,

I like your suggested addition - you're correct about that dependency on consistent hashing (and "consistent" is a great word, e.g., as "identical" is not required).  It's better to call that out than assume that the reader can figure it out.

Thanks, --David

-----Original Message-----
From: John Scudder <[e-mail]> 
Sent: Tuesday, February 13, 2024 1:34 PM
To: Greg Mirsky
Cc: The IESG; [e-mail]; DetNet Chairs; DetNet WG; Lou Berger; Janos Farkas
Subject: Re: John Scudder's No Objection on draft-ietf-detnet-ip-oam-12: (with COMMENT)


[EXTERNAL EMAIL] 

Hi Greg,

Looks good. Concerning the

> ### Section 3.1, co-routing via UDP source port

point, I think the text you’ve added is good and helpful. However, I wonder if it’s worth explicitly pointing out that co-routedness depends on (or may depend on) consistent hashing being done end-to-end. Perhaps this is obvious enough that it doesn’t need to be stated explicitly, but if you agree that it’s worth mentioning, possibly something like:

OLD:
   When the UDP destination port
   number used by the OAM protocol is assigned by IANA, then judicious
   selection of the UDP source port 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.

NEW:
   When the UDP destination port
   number used by the OAM protocol is assigned by IANA, then judicious
   selection of the UDP source port 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. This does assume that forwarding 
   equipment along the multipath makes consistent hashing decisions, which 
   might not always be true in a heterogeneous environment.

Please don’t feel obligated to use the text I’ve supplied, or even to make any change at all. 

Thanks,

—John

> On Feb 12, 2024, at 9:02 PM, Greg Mirsky <[e-mail]> wrote:
> 
> 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://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!LpKI!g0o6JGqoeVfAkZKpNtTv2HsZH5ZRX6_vPk73ckPFGHEowq-wSQD2nYkC1tQ9igxnFBJyOJ5T6OXO$ [ietf[.]org] 
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-detnet-ip-oam/__;!!LpKI!g0o6JGqoeVfAkZKpNtTv2HsZH5ZRX6_vPk73ckPFGHEowq-wSQD2nYkC1tQ9igxnFBJyOAInQxO7$ [datatracker[.]ietf[.]org]
> 
> 
> 
> ----------------------------------------------------------------------
> 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. 
> <draft-ietf-detnet-ip-oam-13.txt>