Re: [ippm] WG adoption call for RFC8321bis and 8889bis

Giuseppe Fioccola <giuseppe.fioccola@huawei.com> Fri, 22 April 2022 09:42 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 E17123A1229 for <ippm@ietfa.amsl.com>; Fri, 22 Apr 2022 02:42:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable 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 Y97ST69nB7jC for <ippm@ietfa.amsl.com>; Fri, 22 Apr 2022 02:42:38 -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 241733A130D for <ippm@ietf.org>; Fri, 22 Apr 2022 02:42:38 -0700 (PDT)
Received: from fraeml708-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4Kl8X83Gp0z688Mv; Fri, 22 Apr 2022 17:40:08 +0800 (CST)
Received: from fraeml714-chm.china.huawei.com (10.206.15.33) by fraeml708-chm.china.huawei.com (10.206.15.36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Fri, 22 Apr 2022 11:42:33 +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; Fri, 22 Apr 2022 11:42:33 +0200
From: Giuseppe Fioccola <giuseppe.fioccola@huawei.com>
To: "xiao.min2@zte.com.cn" <xiao.min2@zte.com.cn>
CC: "tpauly=40apple.com@dmarc.ietf.org" <tpauly=40apple.com@dmarc.ietf.org>, "ippm@ietf.org" <ippm@ietf.org>
Thread-Topic: Re:[ippm] WG adoption call for RFC8321bis and 8889bis
Thread-Index: AQHYStxJO21INiaCb0CNIlMKzP+ZxKz1KtkAgAGtT+CAAzDxAIAAYiyggAEE54CAAD4YgP//6/OAgAApHYA=
Date: Fri, 22 Apr 2022 09:42:33 +0000
Message-ID: <9ffcc0606a8147389b5537006ce17407@huawei.com>
References: CAM4esxQHrH7onttT6MV+DGuM24cQW99pZ83wOAK_88BcAP43Rw@mail.gmail.com, 202204221439275104452@zte.com.cn, 3c3d1d672e17404aa3d2e127079db926@huawei.com <202204221709553282408@zte.com.cn>
In-Reply-To: <202204221709553282408@zte.com.cn>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.48.193.119]
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/_quPJawrZ4qQWD6qyweNtQlys-Q>
Subject: Re: [ippm] WG adoption call for RFC8321bis and 8889bis
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: Fri, 22 Apr 2022 09:42:43 -0000

Hi Xiao,
Ok, great! I will check both drafts after the adoption call is completed.
Regards,

Giuseppe

-----Original Message-----
From: xiao.min2@zte.com.cn <xiao.min2@zte.com.cn> 
Sent: Friday, April 22, 2022 11:10 AM
To: Giuseppe Fioccola <giuseppe.fioccola@huawei.com>
Cc: tpauly=40apple.com@dmarc.ietf.org; ippm@ietf.org
Subject: Re:[ippm] WG adoption call for RFC8321bis and 8889bis

Giuseppe,

Please see inline...

Best Regards,
Xiao Min
------------------原始邮件------------------
发件人:GiuseppeFioccola
收件人:肖敏10093570;
抄送人:tpauly=40apple.com@dmarc.ietf.org;ippm@ietf.org;
日 期 :2022年04月22日 16:42
主 题 :RE: Re:[ippm] WG adoption call for RFC8321bis and 8889bis Hi Xiao, Please find my answers inline tagged as [GF].
Regards,
Giuseppe
-----Original Message-----
From: xiao.min2@zte.com.cn <xiao.min2@zte.com.cn>
Sent: Friday, April 22, 2022 8:39 AM
To: Giuseppe Fioccola <giuseppe.fioccola@huawei.com>
Cc: tpauly=40apple.com@dmarc.ietf.org; ippm@ietf.org
Subject: Re:[ippm] WG adoption call for RFC8321bis and 8889bis Giuseppe, Thanks for your considerations of my suggestion.
Please see inline for more remarks.
Best Regards,
Xiao Min
------------------原始邮件------------------
发件人:GiuseppeFioccola
收件人:肖敏10093570;
抄送人:tpauly=40apple.com@dmarc.ietf.org;ippm@ietf.org;
日 期 :2022年04月21日 21:25
主 题 :RE: Re:[ippm] WG adoption call for RFC8321bis and 8889bis 

Hi Xiao, I would not say theoretic options since they were all implemented even if some more than others.
[XM]>>> If a pointer to the implementations other than "flow-based" "double-marking methodology" can be provided, it's much appreciated.
What I know is only "flow-based" "double-marking methodology", the pointer is: https://datatracker.ietf.org/meeting/106/materials/slides-106-mpls-5-encapsulation-for-mpls-performance-measurement-with-alternate-marking-method-01.pdf
For sure, mean delay is not the most immediate solution but it could be useful in case of multipoint alternate marking.
[XM]>>> If so, then I suggest moving most of the text to RFC8889bis.
[GF]: yes, but for completeness, I think we should explain in RFC8321bis as well, since it was implemented.
[XM2]>>> That's OK with me.
I could try to reduce its text but it is now only half page.
[XM]>>> The length of the text is one aspect, the other more important aspect is that the current specification treats the options as parallel selections, four years later since RFC8321 was published in 2018, I don't think it's still the reality.
[GF]: I will recheck the text to avoid to describe the options on the same level. By the way, looking at the text, some differences are already highlighted, for example in section 3.2.2:
"The Single-Marking methodology for one-way delay measurement is sensitive to out-of-order reception of packets.  The first approach to overcome this problem has been described before and is based on the concept of mean delay.  But the limitation of mean delay is that it doesn't give information about the delay value's distribution for the duration of the block.  Additionally, it may be useful to have not only the mean delay but also the minimum, maximum, and median delay values and, in wider terms, to know more about the statistic distribution of delay values.  So, in order to have more information about the delay and to overcome out-of-order issues, a different approach can be introduced; it is based on a Double-Marking methodology."
Also, in section 7, a reader can get more information about the results of the experiment.
[XM2]>>> I believe you've got the core advice, thank you. Usually for a standards track specification, less is more :-) Regards, Giuseppe -----Original Message-----
From: xiao.min2@zte.com.cn <xiao.min2@zte.com.cn>
Sent: Thursday, April 21, 2022 11:14 AM
To: Giuseppe Fioccola <giuseppe.fioccola@huawei.com>
Cc: tpauly=40apple.com@dmarc.ietf.org; ippm@ietf.org
Subject: Re:[ippm] WG adoption call for RFC8321bis and 8889bis Hi Giuseppe, If you prefer to retain all theoretic options in RFC8321bis, then I propose to cut the length of description on non-preferred options.
As an example, now that "mean delay" option is not recommended, shall we reduce its text from one individual section (section 3.2.1.1) to one or two sentences?
Best Regards,
Xiao Min
------------------原始邮件------------------
发件人:GiuseppeFioccola
收件人:肖敏10093570;tpauly=40apple.com@dmarc.ietf.org;
抄送人:ippm@ietf.org;
日 期 :2022年04月19日 16:12
主 题 :RE: [ippm] WG adoption call for RFC8321bis and 8889bis Hi Xiao, Thank you for the support and for your suggestions.
Since this is not a protocol specific document, we can keep the description of the different methodologies that have been implemented. Indeed, RFC8321bis and RFC8889bis do not standardize any encapsulation.
We included the implementation recommendations in section 7 on the "Results of the Alternate Marking Experiment" and, as an example, we highlighted that the mean delay is not recommended.
Then, each protocol specific document can specify which variation is used based on the availability of one or two flags. For example, draft-ietf-6man-ipv6-alt-mark applies double-marking methodology.
Regards,
Giuseppe
-----Original Message-----
From: ippm <ippm-bounces@ietf.org> On Behalf Of xiao.min2@zte.com.cn
Sent: Monday, April 18, 2022 8:54 AM
To: tpauly=40apple.com@dmarc.ietf.org
Cc: ippm@ietf.org
Subject: Re: [ippm] WG adoption call for RFC8321bis and 8889bis Hi all, I support wg adoption of RFC8321bis.
I have no opinion on RFC8889bis because I don't know any implementation of it.
At the same time, I reserve my opinion on reducing the implementation options specified by this document, because IMHO that's a burden to the vendor, operator or even the general reader.
- In section 3.1, two implementation options "flow-based" and "link-based" are provided, I know only "flow-based" implementation.
- In section 3.2, three implementation options "single-marking methodology", "mean delay" and "double-marking methodology" are provided, I know only "double-marking methodology" implementation.
Best Regards,
Xiao Min
------------------原始邮件------------------
发件人:TommyPauly
收件人:IETF IPPM WG;
日 期 :2022年04月08日 08:04
主 题 :[ippm] WG adoption call for RFC8321bis and 8889bis _______________________________________________
ippm mailing list
ippm@ietf.org
https://www.ietf.org/mailman/listinfo/ippm
Hello IPPM,
This email starts an adoption call for draft-fioccola-rfc8321bis and draft-fioccola-rfc8889bis. Please see Martin’s emails below for details — the main idea here is that we’re moving two IPPM RFCs from Experimental to Proposed Standard.
The chairs would like to have a short amount of time spent in the WG processing these documents. If we adopt, we’d plan to very shortly thereafter do a working group last call.
Please reply to this email by Thursday, April 21 and indicate if you support adopting this document.
Best,
Tommy & MarcusOn Apr 7, 2022, at 1:16 PM, Martin Duke <martin.h.duke@gmail.com> wrote:
Hello IPPM,
You may recall that there was a need to progress RFC8321 and RFC8889 from Experimental to Proposed Standard. There was a feeling that the update would be trivial and we could therefore do it as an AD sponsored document.
I've done 3 rounds of AD review and I've seen the need to substantially adjust the scope of these documents and tweak the design in places. The changes are not revolutionary, but I'm a non-practitioner and have driven some design changes with minimal review. At this point I think it's important to get good IPPM review; if we're going to do that anyway, we might as well do the (expedited) working group process so that there's no confusion as to why IPPM didn't formally review an update to its own documents.
So, as first step, I invite the working group to adopt these two drafts:
https://datatracker.ietf.org/doc/draft-fioccola-rfc8321bis/
https://datatracker.ietf.org/doc/draft-fioccola-rfc8889bis/
Any objections to adoption, as always, should be to the value of doing the work at all, and the general direction of the drafts. I hope to follow up the adoption call with an immediate WGLC to shake out any detailed objections, though we will take as long as we need to address concerns that people have.
I invite you to consult the changelogs on both of these documents, which are not long, to get a sense of what we've done.
For those of you who like diffs, there was a big reorganization between draft-02 and -03 that is hard to follow in a diff. So here is a set of diffs that exclude the -02 to -03 transition:
https://www.ietf.org/rfcdiff?url1=rfc8321.txt&url2=draft-fioccola-rfc8321bis-02.txt
https://www.ietf.org/rfcdiff?url1=draft-fioccola-rfc8321bis-03.txt&url2=draft-fioccola-rfc8321bis-04.txt
https://www.ietf.org/rfcdiff?url1=rfc8889.txt&url2=draft-fioccola-rfc8889bis-02.txt
https://www.ietf.org/rfcdiff?url1=draft-fioccola-rfc8889bis-03.txt&url2=draft-fioccola-rfc8889bis-04.txt
I believe it's up to the chairs to start the adoption call. If people are good about reading the document during WGLC, I would like to think we could be done before IETF 114.
Your friendly Area Director,
Martin
_______________________________________________ippm mailing listippm@ietf.orghttps://www.ietf.org/mailman/listinfo/ippm
_______________________________________________
ippm mailing list
ippm@ietf.org
https://www.ietf.org/mailman/listinfo/ippm