Hi Greg Very welcome. Responses in-line.
On Tue, Feb 6, 2024 at 9: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. > Gyan> Agreed 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. > Gyan> Agreed 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? > >> Gyan> Makes sense. > >> >> 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. > > Gyan> Perfect -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mis...@verizon.com <gyan.s.mis...@verizon.com>* *M 301 502-1347*
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
