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

[Greg Mirsky <[e-mail]>]

Hi John,
thank you for the proposed text. The use of the multipath environment in a
DetNet network, IP DetNet in particular, is a risky solution precisely
because of a potential inconsistency of hashing decisions that affect the
forwarding. RFC 8939 <https://datatracker.ietf.org/doc/rfc8939/> that
describes the use of IP networks for DetNet expresses that as follows:
   The use of multiple paths or links, e.g., ECMP, to support a single
   DetNet flow is NOT RECOMMENDED.  ECMP MAY be used for non-DetNet
   flows within a DetNet domain.
I appreciate it that you agree to leaving the text as-is. I will hold off
uploading the working version until after the IESG telechat on Thursday.

Regards,
Greg

On Tue, Feb 13, 2024 at 10:34 AM John Scudder <[e-mail]> wrote:

> 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://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.
> > <draft-ietf-detnet-ip-oam-13.txt>
>
>