Re: [ippm] Zaheduzzaman Sarker's Discuss on draft-ietf-ippm-rfc8321bis-02: (with DISCUSS)

Giuseppe Fioccola <giuseppe.fioccola@huawei.com> Wed, 13 July 2022 13:48 UTC

Return-Path: <giuseppe.fioccola@huawei.com>
X-Original-To: ippm@ietfa.amsl.com
Delivered-To: ippm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17351C16ED00; Wed, 13 Jul 2022 06:48:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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
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 JVY9zaDXTvUL; Wed, 13 Jul 2022 06:48:03 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11261C15A720; Wed, 13 Jul 2022 06:48:03 -0700 (PDT)
Received: from fraeml714-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4Ljf3F11qCz67Kvx; Wed, 13 Jul 2022 21:43:37 +0800 (CST)
Received: from fraeml714-chm.china.huawei.com (10.206.15.33) by fraeml714-chm.china.huawei.com (10.206.15.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Wed, 13 Jul 2022 15:47:59 +0200
Received: from fraeml714-chm.china.huawei.com ([10.206.15.33]) by fraeml714-chm.china.huawei.com ([10.206.15.33]) with mapi id 15.01.2375.024; Wed, 13 Jul 2022 15:47:59 +0200
From: Giuseppe Fioccola <giuseppe.fioccola@huawei.com>
To: Zaheduzzaman Sarker <Zaheduzzaman.Sarker@ericsson.com>, The IESG <iesg@ietf.org>
CC: "draft-ietf-ippm-rfc8321bis@ietf.org" <draft-ietf-ippm-rfc8321bis@ietf.org>, "ippm-chairs@ietf.org" <ippm-chairs@ietf.org>, "ippm@ietf.org" <ippm@ietf.org>, "tpauly@apple.com" <tpauly@apple.com>
Thread-Topic: Zaheduzzaman Sarker's Discuss on draft-ietf-ippm-rfc8321bis-02: (with DISCUSS)
Thread-Index: AQHYlq/joqy+EHOgRk2MCEj9iVv4Ea18TCMg
Date: Wed, 13 Jul 2022 13:47:59 +0000
Message-ID: <f37fe9b5e7944c0e91bc2ac80a92cd57@huawei.com>
References: <165771350759.5080.2846281797758384277@ietfa.amsl.com>
In-Reply-To: <165771350759.5080.2846281797758384277@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.81.217.188]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/7yd2CKYmhpIDCCAEPDY-OfI0ccY>
Subject: Re: [ippm] Zaheduzzaman Sarker's Discuss on draft-ietf-ippm-rfc8321bis-02: (with DISCUSS)
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ippm/>
List-Post: <mailto:ippm@ietf.org>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Jul 2022 13:48:07 -0000

Hi Zaheduzzaman,
Thank you for the revision,
Please find my reply inline tagged as [GF].
I will also address your comments in the next version.

Best Regards,

Giuseppe

-----Original Message-----
From: Zaheduzzaman Sarker via Datatracker <noreply@ietf.org> 
Sent: Wednesday, July 13, 2022 1:58 PM
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-ippm-rfc8321bis@ietf.org; ippm-chairs@ietf.org; ippm@ietf.org; tpauly@apple.com; tpauly@apple.com
Subject: Zaheduzzaman Sarker's Discuss on draft-ietf-ippm-rfc8321bis-02: (with DISCUSS)

Zaheduzzaman Sarker has entered the following ballot position for
draft-ietf-ippm-rfc8321bis-02: Discuss

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ippm-rfc8321bis/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thanks for working on this specification.

My fellow AD colleagues have already put discusses on the concerns I have.
Overall, I found this document easy to ready but lacking some clarity on the
assumptions and instructions. For, this I am supporting Roman's and Lars's
discuss.

[GF]: Ok, I already replied to Roman and Lars and I plan to address their comments

Apart from those I have one additional concern.

## Section 7 : says -
      In the case where the marking method is applied by changing existing
   fields of the packets, it is RECOMMENDED to use an additional flag or
   some out-of-band signaling to indicate if the measurement is
   activated or not in order to inform the measurement points.

  It is not clear who is changing existing fields of which packets? It needs
  more specific description for at least which packets are we talking about (IP
  packets? ) and what additional flag we are referring to here.

[GF]: This paragraph is inherited from the original RFC8321 where it was mentioned the experimental use of the DSCP field or the unused bit of the IPv4 header as marking fields. In this case, it is needed to use some out-of-band signaling to inform about the activation of the measurements since these marking fields are not intended for AltMark. But, I think we can now delete this paragraph in RFC8321bis since the current approach is to leverage dedicated and reserved marking fields which are included in a protocol extension.