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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 <noreply@xxxxxxxx> 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, 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.
 
-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux