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

[Greg Mirsky <[e-mail]>]

Hi David and John,
I followed David's suggestion and updated the draft using the text proposed
by John.

Regards,
Greg

On Tue, Feb 13, 2024 at 3:20 PM Black, David <[e-mail]> wrote:

> 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>
>
>