I reviewed the v12 and it looks good.
Ready for publication.
Thank you
Gyan
On Thu, Feb 8, 2024 at 9:27 PM Greg Mirsky <gregimirsky@xxxxxxxxx> wrote:
Hi Gyan,thank you for your review, comments, and question. Please note that the new version of the draft includes all the updates listed earlier. I hope that we've addressed 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.GregOn Tue, Feb 6, 2024 at 6:30 AM Greg Mirsky <gregimirsky@xxxxxxxxx> wrote:Hi Gyan,thank you for your thorough review, thoughtful question, and helpful suggestion. Please find my notes below tagged GIM>>.Best regards,GregOn Fri, Feb 2, 2024 at 10:31 PM Gyan Mishra via Datatracker <noreply@xxxxxxxx> wrote:Reviewer: Gyan Mishra
Review result: Ready with Nits
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please treat these comments just
like any other last call comments.
For more information, please see the FAQ at
<https://wiki.ietf.org/en/group/gen/GenArtFAQ>.
Document: draft-ietf-detnet-ip-oam-??
Reviewer: Gyan Mishra
Review Date: 2024-02-02
IETF LC End Date: 2024-02-02
IESG Telechat date: Not scheduled for a telechat
Summary:
This document defines the principles for using Operations, Administration, and
Maintenance protocols and mechanisms in the Deterministic Networking networks
with the IP data plane.
The draft is well written and almost ready for publication.
Major issues:
NoneGIM>> Thank you.
Minor issues:
Should Detnet OAM over IP data plane include IOAM RFC 9378 integrated OAM
where the OAM packets are sent in-situ with the data packets. Should OAM DEX
postcard based telemetry described in draft below and RFC 9232 Network
telemetry framework.
https://datatracker.ietf.org/doc/html/draft-mb-mpls-ioam-dex-05GIM>> IOAM is an example of performance measurement methods (hybrid per RFC 7799) using on-path telemetry. As I understand it, only applicability of IOAM in IPv6 networks is standardized while the discussion continues as part of the MPLS Network Action in the MPLS WG. Also, IETF standardized the Alternate Marking Method in RFC 9341, and several new proposals of interesting on-path telemetry solutions (e.g., HPCC++, CSIG, and Path Tracing) have been presented and are discussed. It seems that once we learn more about these solutions, and how they can be applied in IP and MPLS networks, the applicability of on-path telemetry in DetNet can be described in the new document. What are your thoughts?
Nits/editorial comments:
Section 3 last paragraph
Most of on-demand failure detection and localization in IP networks is being
done by using the Internet Control Message Protocol (ICMP) Echo Request, Echo
Reply and the set of defined error messages, e.g., Destination Unreachable,
with the more detailed information provided through code points. [RFC0792] and
[RFC4443] define the ICMP for IPv4 and IPv6 networks, respectively. Because
ICMP is another IP protocol like, for example, UDP, a DetNet node must able to
associate an ICMP packet generated by the specified IP DetNet node an addressed
to the another IP DetnNet node with an IP DetNet flow between this pair of
endpoints.
Comment on the last line or above paragraph.
Technically IPv4 is protocol 4, IPv6 is protocol 41, UDP protocol 17. So all
have different protocol numbers. However ICMP is part of the IP protocol suite
for diagnostics and uses the same IP header to forward the packet.
New
Because ICMP RFC 792 is part of the IP protocol suite and uses a basic IP
header, with data portion used for diagnostics, similarly UDP utilizes the IP
header as well and is part of the transport layer, thereby facilitating a
DETNET node that must be able to associate an ICMP packet generated by the
specified IP DetNet node and addressed to the another IP DetnNet node with an
IP DetNet flow between this pair of endpoints.GIM>> Thank you for the suggestion and the proposed update. Would the following update address your concern:OLD TEXT:BecauseICMP is another IP protocol like, for example, UDP, a DetNet node must able toassociate an ICMP packet generated by the specified IP DetNet node an addressedto the another IP DetnNet node with an IP DetNet flow between this pair ofendpoints.NEW TEXT:In order to use ICMP for these purposes with DetNet, DetNet nodes must be ableto associate ICMP traffic between DetNet nodes with IP DetNet traffic, e.g., ensure thatsuch ICMP traffic uses the DetNet IP data plane in each node, otherwise ICMP maybe unable to detect and localize failures that are specific to the DetNet IP data plane.
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
