Re: [Last-Call] Opsdir telechat review of draft-ietf-detnet-ip-oam-12

Yingzhen Qu <yingzhen.ietf@gmail.com> Wed, 14 February 2024 16:40 UTC

Return-Path: <yingzhen.ietf@gmail.com>
X-Original-To: last-call@ietfa.amsl.com
Delivered-To: last-call@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD33DC14CE54; Wed, 14 Feb 2024 08:40:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.107
X-Spam-Level:
X-Spam-Status: No, score=-7.107 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_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 ZgAS11hmW3-0; Wed, 14 Feb 2024 08:39:58 -0800 (PST)
Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (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 338F8C151083; Wed, 14 Feb 2024 08:39:58 -0800 (PST)
Received: by mail-lj1-x231.google.com with SMTP id 38308e7fff4ca-2d0b4ea773eso74425531fa.0; Wed, 14 Feb 2024 08:39:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1707928796; x=1708533596; 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=zPLFjjiuixp7FFGLh39ZQrtDwSE3p9dWYMe30gt8cxs=; b=VzCeNx8NrLlV3zhfnQBiW8DalIEVGh/jm+fAvx72fgkFK/+5k99q3eQNmU5AHii5Em 9V/euV6uGjCrKU3e0ndrQWsoJRpV7o9WMYYlmJPr3ZfrvltTYsBx2aMUpm+S0xmoF0+M z+bsNayUDQikCP9Wt/Gy/9AV1pauM+A64fxsuH2MVxljNKChv5ThKD9M8/KmXQFj0ODJ ElG8xjUylXmysgbiwJKCSm1tYGJOai4c8cgPKt4DUhzgN6bUKc8rWzfMF+Lek88BmGoi PORMYXyn1Ty3uhdAPlV6ItdDlgQDeiFeq1qGtMVLOc4qZb4JQsNODeL0bA+oZxhreZss s6iw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707928796; x=1708533596; 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=zPLFjjiuixp7FFGLh39ZQrtDwSE3p9dWYMe30gt8cxs=; b=cucM4yfGNM7wQobENpvrBicb253NwXoPiEo2wcVml0cVIXUbF3t1omkPCQ+UPMg1vz DiMW5axPz467kSZuJTZz3KX52MORlzX4tHggiriZNicLGEgLHRv4b9H342Rd1rb4WLJj Ef985Wm0TSoJRTvg5mwfEYXjLqgkJ5j6ePzbi9o8DQKRK3eBdgKF1qGUJmv6+pkzHj0T m7BevQVJPXK+yWeZtiwTmoR0hddXfpe8yeodAUxniV4TmgZSpPPfGGdffjviq06dcZQt Wp7GSG4G6KEylkPX3S/R+I3dBNIn4jO+HlM+/J7zFbGnOFPc8nMqjZ851EIiPyj7X/xG 5ilw==
X-Forwarded-Encrypted: i=1; AJvYcCV3K+jTSNkHYMHZlqsngLoO+fifqFrBK58SgchNklUUNq67cYhe2DSx4BClZLs51Ij5++M9kP7+31m9ryzabQAsM5F/qMNnxMjOWvsambngKq0tXWQGArZsMzoXZOUMWEuSTkOnXxfvEYuZxrhVj8gf8sqZTYAbTTzIRw==
X-Gm-Message-State: AOJu0Yx/ftZJO2HV9KoEGETd7iAsFABv24Tv6ne29IoYnXBXZFpkI5eR KPeu2SYeNqZ0drzA1sYAbfg1Ue9yocLeis2Uhx3yAdNMRSAbAM77GS5t5ZZoe5211KyCsbhiOV/ UBZjQIoqp/bhYM0nPv40Bx9v0zCD28LyOwA==
X-Google-Smtp-Source: AGHT+IEKyyQLLkOpQ1F/25dsTtzrMDfhYRKgNEQDqBss6P+9SOxNgeCw67OuTb9h7CDPAktr222GesCrMZ1NDHwBcgQ=
X-Received: by 2002:a05:651c:33b:b0:2d0:a60c:5c36 with SMTP id b27-20020a05651c033b00b002d0a60c5c36mr2397648ljp.21.1707928795581; Wed, 14 Feb 2024 08:39:55 -0800 (PST)
MIME-Version: 1.0
References: <170788374355.55771.11998499550968611871@ietfa.amsl.com> <CA+RyBmWN-RJ62xNJR8oZ5fF8NGJ773fRhbtFDo5R8eY2+KknjQ@mail.gmail.com>
In-Reply-To: <CA+RyBmWN-RJ62xNJR8oZ5fF8NGJ773fRhbtFDo5R8eY2+KknjQ@mail.gmail.com>
From: Yingzhen Qu <yingzhen.ietf@gmail.com>
Date: Wed, 14 Feb 2024 08:39:43 -0800
Message-ID: <CABY-gOOZ2di1_JoMDKYesw+dte_Fh1f3KWxpSkudYtc8uLHq4Q@mail.gmail.com>
To: Greg Mirsky <gregimirsky@gmail.com>
Cc: ops-dir@ietf.org, detnet@ietf.org, draft-ietf-detnet-ip-oam.all@ietf.org, last-call@ietf.org
Content-Type: multipart/alternative; boundary="0000000000002991ca06115a2959"
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/x1bX9bRmIygTTOy4jV0N_UkQjVM>
Subject: Re: [Last-Call] Opsdir telechat review of draft-ietf-detnet-ip-oam-12
X-BeenThere: last-call@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF Last Calls <last-call.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/last-call>, <mailto:last-call-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/last-call/>
List-Post: <mailto:last-call@ietf.org>
List-Help: <mailto:last-call-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/last-call>, <mailto:last-call-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Feb 2024 16:40:03 -0000

Hi Greg,

Thanks for the reply. Please see my answers below inline.

Thanks,
Yingzhen


On Tue, Feb 13, 2024 at 9:48 PM Greg Mirsky <gregimirsky@gmail.com> wrote:

> Hi Yingzhen,
> thank you for your kind words in support of this work; much appreciated.
> Please find my notes below tagged GIM>>.
>
> Regards,
> Greg
>
> On Tue, Feb 13, 2024 at 8:09 PM Yingzhen Qu via Datatracker <
> noreply@ietf.org> wrote:
>
>> Reviewer: Yingzhen Qu
>> Review result: Ready
>>
>> I've reviewed version 10, and this is a follow up review.
>>
>> Thanks to the authors for working on this document and addressing my
>> comments.
>>
>> The document readability has improved a lot from my last review of
>> version -10,
>> and I believe it is ready for publication.
>>
>> There are a couple of nits for the authors to consider.
>>
>> The line numbers are generated using idnits.
>>
>> 160        is being done by using the Internet Control Message Protocol
>> (ICMP)
>>
>> nits: there should be a "." in the end.
>>
> GIM>> It seems like the long sentence may confuse a reader:
>    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.
> The intention is to note that Echo Request/Reply that are the mechanism
> used in ICMP are the common method for on-demand failure detection and
> localization, i.e., of ping and traceroute. Would a slight re-wording make
> it clearer:
> NEW TEXT:
>    Most of on-demand failure detection and localization in IP networks
>    is being done by using the Internet Control Message Protocol's (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.
> WDYT?
>

[Yingzhen]: Now I see I did break the long sentence wrong. Fortunately the
message of the sentence was still delivered correctly. Here is my
suggestion:
In IP networks, the majority of on-demand failure detection and
localization is achieved through the use of the Internet Control Message
Protocol (ICMP), utilizing Echo Request and Echo Reply messages, along with
a set of defined error messages such as Destination Unreachable, which
provide detailed information through assigned code points.


>> 166        traffic between DetNet nodes with IP DetNet traffic, e.g.,
>> ensure
>> 167        that such ICMP traffic uses the DetNet IP data plane in each
>> node,
>>
>> nits: somehow this sentence doesn't read well to me. "uses the DetNet IP
>> data plane" is not very clear to me, I think you're trying to say ICMP
>> traffic
>> should go through the same path/interface as DetNet traffic, for example,
>> there is ECMP between two DetNet nodes.
>>
> GIM>> Thank you for pointing this to me. You are correct, the intention is
> to stress the importance of ensuring that ICMP packets traverse the same
> set of nodes and interfaces and receieve the same QoS treatment as the
> monitored DetNet IP flow. I propose the following update:
> OLD 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.
>  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,
>    i.e., ensure that such ICMP traffic traverses the same interfaces and
>    receives the same QoS treatment as the monitored DetNet IP flow;
>    otherwise, ICMP may be unable to detect and localize failures that
>    are specific to the DetNet IP data plane.
> What are your thoughts? Is the text more clear now?
>

[Yingzhen]:  The new text is definitely more clear. Here is my suggestion,
and it's up to you to decide whether to use it or not.
To utilize ICMP effectively for these purposes within DetNet, DetNet nodes
must establish the association of ICMP traffic between DetNet nodes with IP
DetNet traffic. This entails ensuring that such ICMP traffic traverses the
same interfaces and receives identical QoS treatment as the monitored
DetNet IP flow. Failure to do so may result in ICMP being unable to detect
and localize failures specific to the DetNet IP data plane.