IETF Logo Mail Archive

Re: [ippm] AD Review #2 of RFC8321bis

Giuseppe Fioccola <giuseppe.fioccola@huawei.com> Wed, 16 February 2022 13:03 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 A128F3A12D8; Wed, 16 Feb 2022 05:03:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.196
X-Spam-Level:
X-Spam-Status: No, score=-4.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2I8A9EFY0afK; Wed, 16 Feb 2022 05:03:09 -0800 (PST)
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 5B4343A12D6; Wed, 16 Feb 2022 05:03:09 -0800 (PST)
Received: from fraeml714-chm.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4JzJ5r6Rbsz67Mby; Wed, 16 Feb 2022 21:02:40 +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.2308.21; Wed, 16 Feb 2022 14:03:05 +0100
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.2308.021; Wed, 16 Feb 2022 14:03:05 +0100
From: Giuseppe Fioccola <giuseppe.fioccola@huawei.com>
To: Martin Duke <martin.h.duke@gmail.com>, "draft-fioccola-rfc8321bis.all@ietf.org" <draft-fioccola-rfc8321bis.all@ietf.org>
CC: IETF IPPM WG <ippm@ietf.org>
Thread-Topic: AD Review #2 of RFC8321bis
Thread-Index: AQHYIrelKFq0lND/tE+2EGwc4T2FM6yWCR5g
Date: Wed, 16 Feb 2022 13:03:05 +0000
Message-ID: <8cc60c2a6ce14ff6900a919d3d433e5b@huawei.com>
References: <CAM4esxQ8sFwHfuEai3jUt8uApFh4gQ+Yr76xX6D+JVNZMcMyhA@mail.gmail.com>
In-Reply-To: <CAM4esxQ8sFwHfuEai3jUt8uApFh4gQ+Yr76xX6D+JVNZMcMyhA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.48.220.44]
Content-Type: multipart/alternative; boundary="_000_8cc60c2a6ce14ff6900a919d3d433e5bhuaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/jwL7hT94srpkB-Jsi2uCTNeeB1s>
Subject: Re: [ippm] AD Review #2 of RFC8321bis
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.29
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, 16 Feb 2022 13:03:14 -0000

Hi Martin,
Thank you for your review.
I will publish the revision -02 soon and then I will prepare revision -03.

Please find my answers inline tagged as [GF]

Regards,

Giuseppe


From: Martin Duke <martin.h.duke@gmail.com>
Sent: Tuesday, February 15, 2022 11:01 PM
To: draft-fioccola-rfc8321bis.all@ietf.org
Cc: IETF IPPM WG <ippm@ietf.org>
Subject: AD Review #2 of RFC8321bis

Hi Giuseppe,

This is looking good.

1) The one conceptual problem I'm having is what it means for a packet to be "unmarked". If marking involves encapsulation, no problem: some packets can simply not be encapsulated, or one can omit the header option or whatever. But if it's passive measurement because there's a bit in the header, this bit has to be set to something, right?  So how would one mediate between flows that are to be measured or not measured in the latter case?

[GF]: Yes, can add some considerations. As you said, if marking is done in a dedicated option/encapsulation (as in all the existing cases), there is no problem. But, if it is used a bit in the header, we can recommend to use an additional flag or some out-of-band signaling to indicate if the measurement is activated or not.

2) Some minor rewording of the new fragmentation language in section 4.4:
OLD

Nodes that fragment packets within the measurement domain MUST NOT

replicate marks, but SHOULD mark the first fragment if they have the

capability to do so.



NEW

Nodes that fragment packets within the measurement domain SHOULD, if

they have the capability to do so, ensure that only one resulting

fragment carries the marking bit(s) of the original packet. Failure

to do so can introduce errors into the measurement.


[GF]: Ok, I will revise the text as suggested.

I would propose the following steps.

A) address these points and publish draft-02. We'll save the diff to show the delta between 8321 and 8321 bis.

B) Immediately reorganize the document as you intend and publish draft-03.

Then we'll take it through IETF Last Call.

[GF]: Good plan!

Thanks
Martin

v2.20.0 | Report a Bug | By Email