Re: [ippm] Lars Eggert's Discuss on draft-ietf-ippm-rfc8321bis-02: (with DISCUSS and COMMENT)
Giuseppe Fioccola <giuseppe.fioccola@huawei.com> Wed, 13 July 2022 07:55 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 7569FC15AB6B; Wed, 13 Jul 2022 00:55:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.907
X-Spam-Level:
X-Spam-Status: No, score=-6.907 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_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 ffudYW35_C-T; Wed, 13 Jul 2022 00:55:35 -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 7BDB8C15B24B; Wed, 13 Jul 2022 00:55:35 -0700 (PDT)
Received: from fraeml714-chm.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4LjVG43qYsz6H6nT; Wed, 13 Jul 2022 15:52:28 +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 09:55:32 +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 09:55:32 +0200
From: Giuseppe Fioccola <giuseppe.fioccola@huawei.com>
To: Lars Eggert <lars@eggert.org>, 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: Lars Eggert's Discuss on draft-ietf-ippm-rfc8321bis-02: (with DISCUSS and COMMENT)
Thread-Index: AQHYliyShnqwFbSzDUak7yvtTkqbfK17PMwg
Date: Wed, 13 Jul 2022 07:55:31 +0000
Message-ID: <a5a16617cb504326bbeab9c6a328963d@huawei.com>
References: <165765710968.5209.16575382467376968647@ietfa.amsl.com>
In-Reply-To: <165765710968.5209.16575382467376968647@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.81.216.74]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/5Ilhn8WnrBFd3K4km2zRYEOkp10>
Subject: Re: [ippm] Lars Eggert's Discuss on draft-ietf-ippm-rfc8321bis-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: Wed, 13 Jul 2022 07:55:39 -0000
Hi Lars, Thank you for your review. Please see my replies inline tagged as [GF]. Note that I will address your comments in the next revision. Best Regards, Giuseppe -----Original Message----- From: Lars Eggert via Datatracker <noreply@ietf.org> Sent: Tuesday, July 12, 2022 10:18 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: Lars Eggert's Discuss on draft-ietf-ippm-rfc8321bis-02: (with DISCUSS and COMMENT) Lars Eggert 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: ---------------------------------------------------------------------- # GEN AD review of draft-ietf-ippm-rfc8321bis-02 CC @larseggert Thanks to Elwyn Davies for the General Area Review Team (Gen-ART) review (https://mailarchive.ietf.org/arch/msg/gen-art/tX3DO8ZB3yeiaKC_xnI1khVAcss). ## Discuss ### Section 3.1, paragraph 5 ``` The rest of the document assumes that the blocks are created according to a fixed timer. The switching after a fixed number of packets is an additional possibility but its detailed specification is out of scope. ``` This should more strongly say that the use fixed timers are REQUIRED when implementing the spec. This document should then also be stripped of all text discussing the "fixed number of packets" approach, to improve clarity. (You could move it to a non-normative appendix, if there is a desire to keep the text around.) [GF]: I will revise that sentence and say that the use of a fixed timer is REQUIRED when implementing the specification. ### Section 3.1, paragraph 16 ``` Two different strategies that can be used when implementing the method: ``` If both of these strategies are part of the standard, concrete guidance needs to be given when to use one or the other. The text below about "a limited number of traffic flows") is too unspecific. [GF]: I will highlight that the flow-based strategy is REQUIRED when implementing this specification. I will also revise the text and replace "limited number of traffic flows" with "well defined traffic flows". I could probably delete the part on the link-based strategy. ### Section 3.2, paragraph 1 ``` The same principle used to measure packet loss can be applied also to one-way delay measurement. There are three alternatives, as described hereinafter. ``` As above, there is a lot of discussion text around these alternatives, but no concrete guidance when one SHOULD be used but not the other two. If that guidance cannot be given, I wonder if we have enough deployment experience to lift this to the Standards Track. [GF]: I can surely add more details and guidance in section 7. Regarding the alternatives for delay measurements, there are some considerations to do in order to provide guidelines, such as the number of flags available (If there is only one flag you have no choice) or the kind of information needed (double marking is more robust and allows to get more statistics) or software/hardware limitations (mean delay calculation is resource consuming), and so on ### Section 5, paragraph 1 ``` This document introduces two color-switching methods: one is based on a fixed number of packets, and the other is based on a fixed timer. But the method based on a fixed timer is preferable because it is more deterministic, and it is considered in the document. ``` Section 3.1 says that the fixed-number-based approach is out of scope for this specification. The text above is inconsistent with that. Again, please remove the text that talks about the option that is not actually part of the intended standard (or move it to an appendix.) [GF]: I will remove the text that talks about the fixed-number-based approach ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- ## Comments ### Section 1, paragraph 5 ``` [RFC7276] provides a good overview of existing Operations, Administration, and Maintenance (OAM) mechanisms defined in the IETF, ITU-T, and IEEE. In the IETF, a lot of work has been done on fault detection and connectivity verification, while little has been thus far dedicated to performance monitoring. The IETF has defined standard metrics to measure network performance; however, its methods mainly focus on Active measurement techniques.For example, [RFC6374] defines mechanisms for measuring packet loss, one-way and two-way delay, and delay variation in MPLS networks, but its applicability to Passive measurements has some limitations, especially for connection- less networks. ``` This statement on the current state of work in the IETF might not age well in an RFC - maybe remove? [GF]: Agree. It can be removed. ### Section 1.2, paragraph 0 ``` 1.2. Requirements Language ``` Like draft-ietf-ippm-rfc8889bis, this document is very light on RFC2119 language, which leaves it quite unclear what the actually specified technique is intended to be. There are a lot of options for various pieces, but not enough guidance on when an option MUST/SHOULD/MAY be chosen and why. [GF]: As per RFC8889bis, I will try to fix. ### Section 3.1, paragraph 17 ``` Using a fixed timer for color switching offers better control over the method: the (time) length of the blocks can be chosen large enough to simplify the collection and the comparison of measures taken by different network devices. It's preferable to read the value of the counters not immediately after the color switch: some packets could arrive out of order and increment the counter associated with the previous block (color), so it is worth waiting for some time. A safe choice is to wait L/2 time units (where L is the duration for each block) after the color switch, to read the counter of the previous color. The drawback is that the longer the duration of the block, the less frequently the measurement can be taken. ``` Example of a paragraph that can be removed or moved, since the "fixed timer" option isn't being standardized. [GF]: The fixed-timer approach is in scope ### Section 4.3, paragraph 9 ``` The Alternate-Marking Method described in this document literally splits the packets of the measured flow into different measurement blocks. An implementation MAY use a Block Number (BN) for data correlation. The BN MAY be assigned to each measurement block and associated with each packet count and timestamp reported to or pulled by other nodes or NMSs. ``` Shouldn't the second MAY be a MUST? It MAY be done, and if it's done it MUST be done in this specific way? [GF]: Agree. I will replace it. ### Section 5, paragraph 8 ``` It is assumed that all network devices are synchronized to a common reference time with an accuracy of +/- A/2. Thus, the difference between the clock values of any two network devices is bounded by A. ``` This should be made an RFC2119 deployment requirement, because if this cannot be guaranteed, wouldn't the mechanism break down? [GF]: The condition that MUST be satisfied is d<L/2. I will use the RFC2119 wording ### Section 5, paragraph 17 ``` If the time duration L of each block is not so small, the synchronization requirement could be satisfied even with a relatively inaccurate synchronization method. This is true for packet loss and two-way delay measurement, but not for one-way delay measurement, where clock synchronization must be accurate. Therefore, a system that uses only packet loss and two-way delay measurement may not require a very precise synchronization. This is because the value of the clocks of network devices does not affect the computation of the two-way delay measurement. ``` This paragraph does not give actionable guidance on what clock sync scheme to use for a given deployment. [GF]: These are just generic considerations. I think they can also be omitted. ### Section 6, paragraph 5 ``` Measurement points MAY simply ignore unmarked fragments and count marked fragments as full packets. However, if resources allow, measurement points MAY make note of both marked and unmarked initial fragments and only increment the corresponding counter if (a) other fragments are also marked, or (b) it observes all other fragments and they are unmarked. ``` Shouldn't this more strongly RECOMMEND noting marked fragments, and give resource consumption as a reason to not follow the recommendation? [GF]: Yes, the first MAY can be replaced with SHOULD. ### Section 7, paragraph 2 ``` Either one or two flag bits might be available for marking in different deployments: ``` The combination of SHOULDs and MAYs in the two following paragraphs leaves things underspecified. [GF]: I will revise. Regarding the packet loss measurement SHOULD can be replaced with MUST since it is the only option. For delay measurements, I will also replace SHOULD/MAY with MUST for the cases with single option, otherwise I will leave the two possibilities with SHOULD for the primary option and MAY for the secondary option. ### Section 7.1, paragraph 3 ``` For security reasons, the Alternate Marking Method is RECOMMENDED only for controlled domains. ``` Shouldn't this be a MUST-level requirement? I thought the security considerations were only valid inside a limited domain. [GF]: Agree. It will be replaced with a MUST requirement. ### Inclusive language Found terminology that should be reviewed for inclusivity; see https://www.rfc-editor.org/part2/#inclusive_language for background and more guidance: * Term `man`; alternatives might be `individual`, `people`, `person` [GF]: Ok ## Nits All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. ### Boilerplate Document still refers to the "Simplified BSD License", which was corrected in the TLP on September 21, 2021. It should instead refer to the "Revised BSD License". ### Grammar/style #### Section 3.1, paragraph 1 ``` packets is an additional possibility but its detailed specification is out o ^^^^ ``` Use a comma before "but" if it connects two independent clauses (unless they are closely connected and short). [GF]: Ok #### Section 3.1, paragraph 18 ``` where load-balancing is seldom used and static joins are frequently used to ^^^^ ``` Use a comma before "and" if it connects two independent clauses (unless they are closely connected and short). [GF]: Ok #### Section 3.1, paragraph 22 ``` rent to intermediate nodes and independent from the path followed by traffic ^^^^^^^^^^^^^^^^ ``` The usual collocation for "independent" is "of", not "from". Did you mean "independent of"? [GF]: Yes, I will replace it. #### Section 13.2, paragraph 4 ``` ut not detailed. o Explanation of the the intrinsic error in section 3.3.1 on ^^^^^^^ ``` Possible typo: you repeated a word. [GF]: Ok ## Notes This review is in the ["IETF Comments" Markdown format][ICMF], You can use the [`ietf-comments` tool][ICT] to automatically convert this review into individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT]. [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md [ICT]: https://github.com/mnot/ietf-comments [IRT]: https://github.com/larseggert/ietf-reviewtool
- [ippm] Lars Eggert's Discuss on draft-ietf-ippm-r… Lars Eggert via Datatracker
- Re: [ippm] Lars Eggert's Discuss on draft-ietf-ip… Giuseppe Fioccola