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

[Gyan Mishra <[e-mail]>]

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

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [e-mail] <[e-mail]>*



*M 301 502-1347*