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.
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. Best regards, Greg On Tue, Feb 6, 2024 at 6:30 AM Greg Mirsky <gregimir...@gmail.com> wrote: > Hi Gyan, > thank you for your thorough review, thoughtful question, and helpful > suggestion. Please find my notes below tagged GIM>>. > > Best regards, > Greg > > On Fri, Feb 2, 2024 at 10:31 PM Gyan Mishra via Datatracker < > nore...@ietf.org> 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: >> None >> > GIM>> 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-05 > > GIM>> 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 > <https://datatracker.ietf.org/doc/rfc9341/>, 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: > 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. > > NEW TEXT: > 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. > >
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
