Re: [Detnet] Genart last call review of draft-ietf-detnet-ip-oam-10

[Greg Mirsky <[e-mail]>]

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 <
[e-mail]> 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.