Re: [Detnet] Genart last call review of draft-ietf-detnet-ip-oam-10
Gyan Mishra <hayabusagsm@gmail.com> Fri, 09 February 2024 03:35 UTC
Return-Path: <hayabusagsm@gmail.com>
X-Original-To: detnet@ietfa.amsl.com
Delivered-To: detnet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B31B7C14F6B8; Thu, 8 Feb 2024 19:35:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.093
X-Spam-Level:
X-Spam-Status: No, score=-2.093 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 88kmQBPxZlgP; Thu, 8 Feb 2024 19:35:10 -0800 (PST)
Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0:4864:20::532]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA5CBC14CF17; Thu, 8 Feb 2024 19:35:00 -0800 (PST)
Received: by mail-pg1-x532.google.com with SMTP id 41be03b00d2f7-5d4a1e66750so341687a12.0; Thu, 08 Feb 2024 19:35:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1707449700; x=1708054500; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=0iXnYTr0MNIqofv3Gs77c2EoEMGuB23H2xg+0ShPj0c=; b=Kta6xWb3WySIln6Y0qcSVCcp9OeSE24ei/y186dYkLewUEKXiIaWZgdjdHXdZPc7iT lRJmJFYCJpCpQFrV6a9vQ/VBHSsvM5663vkUR5/rjWsmAWZSZwKgu0LdKE+R1RjeKZTm C3QqmCzqIQSBzEFVRGhwdVnfY5tx3znPVCyd2YjOcqFndJY3dQaY18eJz2XyN/VxylDl BOZG5wXqsTGOlbioH9ycljhRrfnOfjAfN4NBXLYHDdtogGN936S6opIvKI85HmTwdcmu C9DCnS38cEVS3iarC1s/kWmxR2KgYixRRO22EwOxkmZrSsW3rccP68b6XBAN7kNnho2+ MAmg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707449700; x=1708054500; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=0iXnYTr0MNIqofv3Gs77c2EoEMGuB23H2xg+0ShPj0c=; b=RVTKG1lHprGk83BF/OOz6LNHqBjC4s1Zm4CLDRIi2QNA9yWPVjMUGe71DLuAEPrP81 OqRUxK53MdfSELOAp1gAOtGDwc+uVrp/PmoRHGE7KFoSmI756fL0ss7wEh4idHMGk9jx aiknGxHAzSbyN/r1aCR8aoEGTx85zrrn6SIWUE4lQKFc8JJ/S2g3HgJO31+MZvFQ3ZIc NQ1Pqfm18IixmATcQ7XvMuVhcCxPw9mTwescYlRcH5l1+qOvHYIe22QU2mvvwuusNDWc K6eVeJr7fFRICregtJU+XuGvbGITQGShLCGnOQbQb9Rgnm2eXKCi345djI+ffxWGVhWQ e1Zg==
X-Forwarded-Encrypted: i=1; AJvYcCVsm0j/1oPRJWH4sqnStN/8u7RtQKk9H73JjJh3YeItJtmyCTposg5b21Rp8ctuCYiugLxL0CMUF7WoczwuRqq8LlbQe+PCiWtJjEYlSTNp7v+TJKcVb6ruYyTHn+3tQj29e18qKtC2jfRszSxs9LN99lySYDZHzGBVjqw=
X-Gm-Message-State: AOJu0YzpajzWZUCsOZTsuYPuSu98tJwiW5WnQ0g4oAAoWwhVx7MfbAAK t2rC9etlV/Ga+hBb+rBFluZn3zQhvvvLvDVPlgGxHxnONkQII0sWf/V16KMPxWr2Q/KizH+Pdls FEsi0Cf8Wu81WKn2hLwpaW64mGOI=
X-Google-Smtp-Source: AGHT+IEjLs/7sPj+a99Lryy45eAs/axf2PP6v/Ru9sedWEqYxF2FDOJnCGG7mdeb/1o5o4jW9k0NogjhPE9w//vRqXw=
X-Received: by 2002:a17:90a:2dc9:b0:296:1ac3:c573 with SMTP id q9-20020a17090a2dc900b002961ac3c573mr309066pjm.15.1707449699676; Thu, 08 Feb 2024 19:34:59 -0800 (PST)
MIME-Version: 1.0
References: <170694187444.35291.6631377694612556761@ietfa.amsl.com> <CA+RyBmWcSNon03a51p+xL26BpCWjYA4rMxDfMecWvXLakJu=jQ@mail.gmail.com> <CA+RyBmXkcYT51Y7pbvo4mW6+c5OKyNCW87BuzMtAmJ-4Q=vBdQ@mail.gmail.com>
In-Reply-To: <CA+RyBmXkcYT51Y7pbvo4mW6+c5OKyNCW87BuzMtAmJ-4Q=vBdQ@mail.gmail.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Thu, 08 Feb 2024 22:34:48 -0500
Message-ID: <CABNhwV3Ac_+dNv2vRfvrEr2LnTDWo+URvpw396j0dc3=C2iGEQ@mail.gmail.com>
To: Greg Mirsky <gregimirsky@gmail.com>
Cc: detnet@ietf.org, draft-ietf-detnet-ip-oam.all@ietf.org, gen-art@ietf.org, last-call@ietf.org
Content-Type: multipart/alternative; boundary="000000000000d236370610ea9c18"
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/PyRvOA3p__5HGflN3Br0ojoSl8g>
Subject: Re: [Detnet] Genart last call review of draft-ietf-detnet-ip-oam-10
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Discussions on Deterministic Networking BoF and Proposed WG <detnet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/detnet>, <mailto:detnet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/detnet/>
List-Post: <mailto:detnet@ietf.org>
List-Help: <mailto:detnet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/detnet>, <mailto:detnet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Feb 2024 03:35:14 -0000
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 <gregimirsky@gmail.com> 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 <gregimirsky@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 < >> noreply@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. 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 gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>* *M 301 502-1347*
- [Detnet] Genart last call review of draft-ietf-de… Gyan Mishra via Datatracker
- Re: [Detnet] Genart last call review of draft-iet… Greg Mirsky
- Re: [Detnet] Genart last call review of draft-iet… Greg Mirsky
- Re: [Detnet] Genart last call review of draft-iet… Gyan Mishra
- Re: [Detnet] Genart last call review of draft-iet… Gyan Mishra