Hi Yingzhen,
thank you for your review, comments, and questions. Please note that the new version of the draft includes all updates listed earlier. We hope that updates in versions 11 and 12 address your concerns.
Best regards,Name: draft-ietf-detnet-ip-oam
Revision: 12
Title: Operations, Administration and Maintenance (OAM) for Deterministic Networks (DetNet) with IP Data Plane
Date: 2024-02-08
Group: detnet
Pages: 9
URL: https://www.ietf.org/archive/id/draft-ietf-detnet-ip-oam-12.txt
Status: https://datatracker.ietf.org/doc/draft-ietf-detnet-ip-oam/
HTML: https://www.ietf.org/archive/id/draft-ietf-detnet-ip-oam-12.html
HTMLized: https://datatracker.ietf.org/doc/html/draft-ietf-detnet-ip-oam
Diff: https://author-tools.ietf.org/iddiff?url2=draft-ietf-detnet-ip-oam-12
Abstract:
This document discusses the use of existing IP Operations,
Administration, and Maintenance protocols and mechanisms in
Deterministic Networking networks that use the IP data plane.
Greg
On Mon, Feb 5, 2024 at 8:45 AM Black, David <David.Black@xxxxxxxx> wrote:
Hi Yingzhen,
Thanks for the review - it turned up a number of issues that are common with Bernard's review, so we decided to deal with his review first (see the recently posted -11) version and then look at this one. In general, please take a look at the -11 version, which should be clearer.
David> Comments inline on specific items.
Thanks, --David
-----Original Message-----
From: Yingzhen Qu via Datatracker <noreply@xxxxxxxx>
Sent: Friday, February 2, 2024 1:45 AM
To: ops-dir@xxxxxxxx
Cc: detnet@xxxxxxxx; draft-ietf-detnet-ip-oam.all@xxxxxxxx; last-call@xxxxxxxx
Subject: Opsdir last call review of draft-ietf-detnet-ip-oam-10
[EXTERNAL EMAIL]
Reviewer: Yingzhen Qu
Review result: Has Issues
Hi,
Thanks for the draft.
I am the assigned OPSDIR reviewer to conduct a last call review of this draft.
General comments:
The draft lists how existing OAM protocols/tools can be used in DetNet with IP
data plane. However, I don't think it's clearly stated in either the abstract
or the introduction section, so it's not clear to me what information the draft
is trying to deliver. OAM principles as stated in the abstract? or how existing
solutions may work in DetNet?
David> The latter is intended - this should be clarified and consistent in the -11 version, please check.
There are some editorial nits in the draft, and some of them made the draft
hard to read. I'd suggest an editorial pass and then I can do another round of
review.
Detail comments with line number from idnits:
80 usually performed on-demand. These tasks achieved by a combination
s/usually performed/are usually performed
s/achieved/are achieved
David> Fixed in the -11 version.
In Section 2.1, there should be a ":" after each term/abbreviation.
David> Agree, should be done for consistency.
145 packets. For example, that can be achieved with a 3-tuple
146 (destination and source IP addresses in combination with DSCP value)
147 used to identify the IP DetNet flow. In such a scenario, an IP OAM
148 session between the same pair of IP nodes would share the network
149 treatment with the monitored IP DetNet flow regardless of whether
150 ICMP, BFD, or STAMP protocol is used.
Q: Do you mean as long as two protocols, for example ICMP and BFD, have the
same DSCP value, the network treatment will be the same?
David> No, please see the new text in -11, which should be clearer.
In 20/20 hindsight, we omitted the assumption for the example that DetNet
is using 3-tuples (e.g., and not 5-tuples) to determine which traffic
receives DetNet handling/QoS. The overall concern is that the OAM traffic
use the same network path and receive the same DetNet forwarding treatment
as the DetNet traffic that is being monitored.
158 protocol like, for example, UDP, a DetNet node must able to associate
s/must able to/must be able to
David> Ok, will fix.
168 protocol is one of the assigned by IANA, then the UDP source port can
s/the assigned/those assigned
David> Removed as part of rewriting that paragraph in -11.
167 DetNet flow. When the UDP destination port number used by the OAM
168 protocol is one of the assigned by IANA, then the UDP source port can
169 be used to achieve co-routedness of OAM, and the monitored IP DetNet
170 flow in the multipath environments, e.g., Link Aggregation Group or
171 Equal Cost Multipath.
Q: It's not clear how using the same UDP source port the OAM packets will be
guaranteed to follow the same path as the monitored IP flow. Please clarify.
David> Clarification/explanation improved in -11, please take a look at the new text.
266 and MPLS data planes analyzed in Section 6.2 of
268 [I-D.ietf-detnet-mpls-oam]. Also, requirements and recommendations
nits: broken line.
David> I suspect that's a tooling artifact, RFC Editor will deal with this.
268 [I-D.ietf-detnet-mpls-oam]. Also, requirements and recommendations
269 for OAM interworking between a DetNet domain with MPLS data plane and
270 OAM of a TSN equally apply to a DetNet domain with an IP data plane.
I'd suggest rewriting this sentence. I can't understand what it's trying to say.
David> Yes, it's a bit terse and unclear for that reason. We'll propose new text in a subsequent message.
Thanks,
Yingzhen
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
