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

[Gyan Mishra <[e-mail]>]

Hi Greg

Very welcome.  Responses in-line.

On Tue, Feb 6, 2024 at 9:30 AM Greg Mirsky <[e-mail]> 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 <
> [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.
>

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



*M 301 502-1347*