Re: [ippm] Alvaro Retana's Discuss on draft-ietf-ippm-rfc8889bis-02: (with DISCUSS and COMMENT)
Giuseppe Fioccola <giuseppe.fioccola@huawei.com> Tue, 12 July 2022 16:00 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 C8E62C14F741; Tue, 12 Jul 2022 09:00:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.898
X-Spam-Level:
X-Spam-Status: No, score=-6.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_HELO_TEMPERROR=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 pO0bTlT9c3wr; Tue, 12 Jul 2022 09:00:20 -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 42DB7C14F735; Tue, 12 Jul 2022 09:00:20 -0700 (PDT)
Received: from fraeml709-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4Lj53v1qQ8z6J6Vq; Tue, 12 Jul 2022 23:57:15 +0800 (CST)
Received: from fraeml714-chm.china.huawei.com (10.206.15.33) by fraeml709-chm.china.huawei.com (10.206.15.37) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Tue, 12 Jul 2022 18:00:16 +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; Tue, 12 Jul 2022 18:00:16 +0200
From: Giuseppe Fioccola <giuseppe.fioccola@huawei.com>
To: Alvaro Retana <aretana.ietf@gmail.com>, The IESG <iesg@ietf.org>
CC: "draft-ietf-ippm-rfc8889bis@ietf.org" <draft-ietf-ippm-rfc8889bis@ietf.org>, "ippm-chairs@ietf.org" <ippm-chairs@ietf.org>, "ippm@ietf.org" <ippm@ietf.org>, "tpauly@apple.com" <tpauly@apple.com>
Thread-Topic: Alvaro Retana's Discuss on draft-ietf-ippm-rfc8889bis-02: (with DISCUSS and COMMENT)
Thread-Index: AQHYlWvkZGY/ezE3CU6Kz8OX3g2cMa164YTA
Date: Tue, 12 Jul 2022 16:00:16 +0000
Message-ID: <820c7f7149a0406b91feedaf5ad8d9c7@huawei.com>
References: <165757435591.4931.9146839768451175920@ietfa.amsl.com>
In-Reply-To: <165757435591.4931.9146839768451175920@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.81.214.34]
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/fC9fzlIBVimYDcErz32hF542KRc>
Subject: Re: [ippm] Alvaro Retana's Discuss on draft-ietf-ippm-rfc8889bis-02: (with DISCUSS and COMMENT)
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: Tue, 12 Jul 2022 16:00:24 -0000
Hi Alvaro, Thanks again for your review. Please find my replies inline tagged as [GF]. I will publish a new version to address your comments. Best Regards, Giuseppe -----Original Message----- From: Alvaro Retana via Datatracker <noreply@ietf.org> Sent: Monday, July 11, 2022 11:19 PM To: The IESG <iesg@ietf.org> Cc: draft-ietf-ippm-rfc8889bis@ietf.org; ippm-chairs@ietf.org; ippm@ietf.org; tpauly@apple.com Subject: Alvaro Retana's Discuss on draft-ietf-ippm-rfc8889bis-02: (with DISCUSS and COMMENT) Alvaro Retana has entered the following ballot position for draft-ietf-ippm-rfc8889bis-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-rfc8889bis/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- §9 ("Results of the Multipoint Alternate Marking Experiment") makes several recommendations about the use of one or two flag bits: One flag: packet loss measurement SHOULD be done as described in Section 6 by applying the network clustering partition described in Section 5. While delay measurement MAY be done according to the Mean delay calculation representative of the multipoint path, as described in Section 7.1.1. Single-marking method based on the first/last packet of the interval cannot be applied, as mentioned in Section 7.2.1. Two flags: packet loss measurement SHOULD be done as described in Section 6 by applying the network clustering partition described in Section 5. While delay measurement SHOULD be done on a single packet basis according to double-marking method Section 7.2.1. In this case the Mean delay calculation (Section 7.1.1) MAY also be used as a representative value of a multipoint path. One flag and hash-based selection: packet loss measurement SHOULD be done as described in Section 6 by applying the network clustering partition described in Section 5. Hash-based selection methodologies, introduced in Section 7.2.2, MAY be used for delay measurement. These recommendations are good, as they are the result of experimentation. However, they don't provide any deployment or operational guidelines of when it is ok to follow them and when it isn't. For example, for the one flag case, when it is ok to not measure packet loss as described in §6? Why is the use of that mechanism only recommended and not required? I have the same questions for all the recommendations and optional indications in the text above. To clear this DISCUSS I expect deployment or operational recommendations that can be used as implementation/deployment guidance. [GF]: Similarly to RFC8321bis, I will surely add more details. Regarding the packet loss measurement SHOULD can be replaced with MUST since it is the only option for multipoint measurements. Regarding the delay measurements, there are some considerations to take into account in order to provide guidelines, such as the number of flags available, the kind of information needed, the computational resources (e.g. to implement hashing selection). ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I support Roman's DISCUSS position and have a related question about this text in §9: The Multipoint Alternate Marking Method is RECOMMENDED only for controlled domains, as per [I-D.ietf-ippm-rfc8321bis]. When is it ok to use the Multipoint Alternate Marking Method in any other deployment? IOW, given the definition of a controlled domain in rfc8321bis, why is its use only recommended and not required? Note that if this consideration depends entirely on rfc8321bis, you may be able to refer to it and eliminate the Normative language. [I did not include this point as a DISCUSS because I expect it to be solved when Roman's concern is addressed.] [GF]: Yes it is similar to RFC8321bis. I will refer to it or just replace that sentence with: "The Multipoint Alternate Marking Method MUST only be applied to controlled domains."
- [ippm] Alvaro Retana's Discuss on draft-ietf-ippm… Alvaro Retana via Datatracker
- Re: [ippm] Alvaro Retana's Discuss on draft-ietf-… Giuseppe Fioccola
- Re: [ippm] Alvaro Retana's Discuss on draft-ietf-… Alvaro Retana
- Re: [ippm] Alvaro Retana's Discuss on draft-ietf-… Giuseppe Fioccola