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

[John Scudder <[e-mail]>]

Hi Greg,

That’s an interesting point. I was just about to suggest you update the text under discussion with a reference to RFC 8939 §5.2, but then I realized it's making a subtly different point. RFC 8939 isn’t saying not to use ECMP in a DetNet domain, it’s saying not to use ECMP for "a single DetNet flow”. The wording looks to have been chosen that way carefully and deliberately. It should be relatively easy to use ECMP within a domain while at the same time avoiding it within a flow since most ECMP implementations already take pains to try to keep flows to a single path. The problem arises in your document because you need to cause OAM traffic to follow the same path as that used by the monitored DetNet flow, and so you’re at the mercy of the hashing algorithm(s) in use.

—John

> On Feb 13, 2024, at 3:22 PM, Greg Mirsky <[e-mail]> wrote:
> 
> 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 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>
>