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

John Scudder via Datatracker <noreply@ietf.org> Mon, 12 February 2024 21:19 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: detnet@ietf.org
Delivered-To: detnet@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 368C9C151553; Mon, 12 Feb 2024 13:19:40 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: John Scudder via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-detnet-ip-oam@ietf.org, detnet-chairs@ietf.org, detnet@ietf.org, lberger@labn.net, janos.farkas@ericsson.com, janos.farkas@ericsson.com
X-Test-IDTracker: no
X-IETF-IDTracker: 12.5.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: John Scudder <jgs@juniper.net>
Message-ID: <170777278020.35385.2975291673486366426@ietfa.amsl.com>
Date: Mon, 12 Feb 2024 13:19:40 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/PloD-SM7OEC-_JyHWizc4Au96DM>
Subject: [Detnet] John Scudder's No Objection on draft-ietf-detnet-ip-oam-12: (with COMMENT)
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.39
List-Id: Discussions on Deterministic Networking BoF and Proposed WG <detnet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/detnet>, <mailto:detnet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/detnet/>
List-Post: <mailto:detnet@ietf.org>
List-Help: <mailto:detnet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/detnet>, <mailto:detnet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Feb 2024 21:19:40 -0000

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)
- PREF (except it's used by a later definition)
- POF
- RDI

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.

### 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".

### 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."

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

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

### 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. :-)