Re: [ippm] RFC 8321 and 8889

Giuseppe Fioccola <giuseppe.fioccola@huawei.com> Sun, 29 August 2021 10:59 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 C23CB3A0905 for <ippm@ietfa.amsl.com>; Sun, 29 Aug 2021 03:59:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.796
X-Spam-Level:
X-Spam-Status: No, score=-1.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 6TciQner-27c for <ippm@ietfa.amsl.com>; Sun, 29 Aug 2021 03:59:52 -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 8D3273A0902 for <ippm@ietf.org>; Sun, 29 Aug 2021 03:59:51 -0700 (PDT)
Received: from fraeml707-chm.china.huawei.com (unknown [172.18.147.207]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4Gy9RM5dKGz67NpT; Sun, 29 Aug 2021 18:58:23 +0800 (CST)
Received: from fraeml714-chm.china.huawei.com (10.206.15.33) by fraeml707-chm.china.huawei.com (10.206.15.35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.8; Sun, 29 Aug 2021 12:59:46 +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.2308.008; Sun, 29 Aug 2021 12:59:46 +0200
From: Giuseppe Fioccola <giuseppe.fioccola@huawei.com>
To: "MORTON JR., AL" <acmorton@att.com>, Martin Duke <martin.h.duke@gmail.com>
CC: =?utf-8?B?UmFuIFBhbmco6IGU6YCa6ZuG5Zui5Lit5Zu96IGU6YCa56CU56m26ZmiLQ==?= =?utf-8?B?5pys6YOoKQ==?= <pangran@chinaunicom.cn>, IETF IPPM WG <ippm@ietf.org>, Erik Kline <ek.ietf@gmail.com>
Thread-Topic: [ippm] RFC 8321 and 8889
Thread-Index: AQHXj6gWPejcFtn9s0ywj57o9VM7G6t8gLIAgAAC0ACABOdSAIAA+1JggAVfngCAANHv8IAAuVIAgAD+CLA=
Date: Sun, 29 Aug 2021 10:59:46 +0000
Message-ID: <3e349603cc0342dc89b686664f160502@huawei.com>
References: <CAM4esxQHOV2uWJGeqhSyWAbgr36n71S8Ss1bc-1qFiFex9Wu3w@mail.gmail.com> <d392b3339899499590e0d1c9e7a761a0@M10-HQ-ML02.hq.cnc.intra> <CAM4esxS-zLVGO7oYLf+aRhWmYLg4FOzZ1cvTRDnx0kmQ2-_44Q@mail.gmail.com> <SJ0PR02MB78531F377BA2BED3CACB43DFD3C19@SJ0PR02MB7853.namprd02.prod.outlook.com> <CAM4esxTd76BDaGDxHzxqM8am+g2bAui7=Q06uGoXkLLq25Ur4Q@mail.gmail.com> <6c463f9daf414b9eaaa39e8db74898a0@huawei.com> <CAM4esxQWikydTakJOmwS2WcBZ2pXPu+M1CHw=f+53uKOYuBjmg@mail.gmail.com> <41994ffd49714d9385ab7b0de7faead5@huawei.com> <SJ0PR02MB7853F765AB1FD56E1192EDC8D3C99@SJ0PR02MB7853.namprd02.prod.outlook.com>
In-Reply-To: <SJ0PR02MB7853F765AB1FD56E1192EDC8D3C99@SJ0PR02MB7853.namprd02.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.95.117]
Content-Type: multipart/alternative; boundary="_000_3e349603cc0342dc89b686664f160502huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/zQPgfObxE3mPgNdTLCHKPDfOQlw>
Subject: Re: [ippm] RFC 8321 and 8889
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: Sun, 29 Aug 2021 10:59:58 -0000

Hi Al,
Yes, the use of the DSCP field as marking field was mentioned in RFC 8321 just to explain the initial experiment done in Telecom Italia in 2010 by leveraging the available router functions. But this is now outdated by the current implementations.

Regarding the applications listed in Section 5 (IPFPM, OAM Performance Measurement for BIER, SFC, MPLS, Active Performance Measurement) are all implemented at different stages by vendors (e.g. Huawei, Cisco, ZTE, Broadcom..) and deployed by operators (Telecom Italia, China Mobile, China Unicom..) as also confirmed by the answers to the poll launched by Martin Duke two weeks ago.
Since the number of the applications is expected to change over time, this section should be updated by adding the latest implementations (SR-MPLS, IPv6, SRv6) and, maybe, omitted in a Proposed Standard document.

Regards,

Giuseppe


From: MORTON JR., AL <acmorton@att.com>
Sent: Saturday, August 28, 2021 10:12 PM
To: Giuseppe Fioccola <giuseppe.fioccola@huawei.com>om>; Martin Duke <martin.h.duke@gmail.com>
Cc: Ran Pang(联通集团中国联通研究院-本部) <pangran@chinaunicom.cn>cn>; IETF IPPM WG <ippm@ietf.org>rg>; Erik Kline <ek.ietf@gmail.com>
Subject: RE: [ippm] RFC 8321 and 8889

Hi Giuseppe,

I read in the [0] that
... it is possible to use the two least-significant bits of
   the DSCP field (bit 0 and bit 1) to implement the method without
   affecting QoS policies.
but this was a single domain solution for the experiment described.

Of the four alternate marking method applications (for bit locations) listed in section 5, which ones have been implemented?

thanks,
Al

[0] https://datatracker.ietf.org/doc/html/rfc8321#section-5

From: Giuseppe Fioccola <giuseppe.fioccola@huawei.com<mailto:giuseppe.fioccola@huawei.com>>
Sent: Saturday, August 28, 2021 3:19 AM
To: Martin Duke <martin.h.duke@gmail.com<mailto:martin.h.duke@gmail.com>>
Cc: MORTON JR., AL <acmorton@att.com<mailto:acmorton@att.com>>; Ran Pang(联通集团中国联通研究院-本部) <pangran@chinaunicom.cn<mailto:pangran@chinaunicom.cn>>; IETF IPPM WG <ippm@ietf.org<mailto:ippm@ietf.org>>; Erik Kline <ek.ietf@gmail.com<mailto:ek.ietf@gmail.com>>
Subject: RE: [ippm] RFC 8321 and 8889

Hi Martin,
Thanks a lot for launching the IETF Last Call for the status change of RFC8321 and RFC8889.
Please note that I’m available to inventory and work on a possible new draft on RFC8321bis and RFC8889bis, depending on the outcome from the Last Call.

Regards,

Giuseppe


From: Martin Duke <martin.h.duke@gmail.com<mailto:martin.h.duke@gmail.com>>
Sent: Friday, August 27, 2021 10:37 PM
To: Giuseppe Fioccola <giuseppe.fioccola@huawei.com<mailto:giuseppe.fioccola@huawei.com>>
Cc: MORTON JR., AL <acmorton@att.com<mailto:acmorton@att.com>>; Ran Pang(联通集团中国联通研究院-本部) <pangran@chinaunicom.cn<mailto:pangran@chinaunicom.cn>>; IETF IPPM WG <ippm@ietf.org<mailto:ippm@ietf.org>>; Erik Kline <ek.ietf@gmail.com<mailto:ek.ietf@gmail.com>>
Subject: Re: [ippm] RFC 8321 and 8889

Hi all,

Thanks for all the feedback.

I have launched an IETF last call for the status change:
https://datatracker.ietf.org/doc/status-change-rfc8321-rfc8889-alt-mark-to-ps/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/status-change-rfc8321-rfc8889-alt-mark-to-ps/__;!!BhdT!337sv1u42kl9wmAzWIEjgBRRkvACHnb4mqVGIZgNmvHrDo_wKq9HrNco9TS_$>

As this call continues, it would be worthwhile for someone to inventory 8321 (and especially 8889) to see if there are any pieces that ought not to progress. We already have a volunteer to shepherd a bis document for either document, if need be.

Martin


On Tue, Aug 24, 2021 at 1:36 AM Giuseppe Fioccola <giuseppe.fioccola@huawei.com<mailto:giuseppe.fioccola@huawei.com>> wrote:
Hi Martin,
In RFC 8321 there are only two alternatives in relation to the number of bits: single marking and double marking. And both are implemented.
As author of RFC 8321, I think that it can be simply elevated as is to PS by slightly revising or by omitting some text that refers to the experiment already done (e.g. section 5).

Regards,

Giuseppe

From: ippm <ippm-bounces@ietf.org<mailto:ippm-bounces@ietf.org>> On Behalf Of Martin Duke
Sent: Monday, August 23, 2021 9:34 PM
To: MORTON JR., AL <acmorton@att.com<mailto:acmorton@att.com>>
Cc: Ran Pang(联通集团中国联通研究院-本部) <pangran@chinaunicom.cn<mailto:pangran@chinaunicom.cn>>; IETF IPPM WG <ippm@ietf.org<mailto:ippm@ietf.org>>
Subject: Re: [ippm] RFC 8321 and 8889

Hi Al, this is my impression as well. In a perfect world I would ask the WG to do a bis draft to inventory what is mature and to deprecate the bits that haven't seen real deployment. If it turns out that it's all deployed, then we could do a simpler document action.

Is this work that anyone is interested in taking on?

On Fri, Aug 20, 2021 at 9:41 AM MORTON JR., AL <acmorton@att.com<mailto:acmorton@att.com>> wrote:
Hi Martin,

While I don’t have a serious concern, I’d prefer to elevate the parts of 8321 that *were implemented* to PS.  I think I read that some parts were not implemented and I look to those who reported on their implementations to say what they did.

This thinning-out of non-implemented capabilities was a feature of Standards Track Advancement processes in the past, so it makes sense to apply it here as well.  I realize this means a new draft, but the processing could be accelerated to match the need.

If the entire RFC 8321 was implemented, then this point is a non-issue.

hope this helps,
Al

From: ippm <ippm-bounces@ietf.org<mailto:ippm-bounces@ietf.org>> On Behalf Of Martin Duke
Sent: Friday, August 20, 2021 12:31 PM
To: Ran Pang(联通集团中国联通研究院-本部) <pangran@chinaunicom.cn<mailto:pangran@chinaunicom.cn>>
Cc: IETF IPPM WG <ippm@ietf.org<mailto:ippm@ietf.org>>
Subject: Re: [ippm] RFC 8321 and 8889

Thanks all,

I'm hearing strong consensus that 8321 should be a PS and somewhat weaker support for 8889, but no dissents.

If anyone has serious concerns, this would be a good time to say so.

On Fri, Aug 20, 2021 at 3:02 AM Ran Pang(联通集团中国联通研究院-本部) <pangran@chinaunicom.cn<mailto:pangran@chinaunicom.cn>> wrote:
Hi Martin and WG,

The alt-mk described in RFC8321/8889 has been deployed in some of our networks.
It works well.
So I would like the WG consider elevate them to proposed standard.

Best regards,
Pang Ran.

From: Martin Duke<mailto:martin.h.duke@gmail.com>
Date: 2021-08-13 02:26
To: IETF IPPM WG<mailto:ippm@ietf.org>
Subject: [ippm] RFC 8321 and 8889
Hello IPPM,

(with AD hat on)

The IESG is currently considering
https://datatracker.ietf.org/doc/html/draft-ietf-6man-ipv6-alt-mark-08<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-6man-ipv6-alt-mark-08__;!!BhdT!04s1Z7EtCnJrifRI3dUP1d0hps2MsV_B1gLCAqMQ1jJwmHnx-jiXCBYQM6IB$>
which is the implementation of RFC 8321<https://urldefense.com/v3/__https:/www.rfc-editor.org/rfc/rfc8321.html__;!!BhdT!04s1Z7EtCnJrifRI3dUP1d0hps2MsV_B1gLCAqMQ1jJwmHnx-jiXCEt7L0EO$> and 8889<https://urldefense.com/v3/__https:/www.rfc-editor.org/rfc/rfc8889.html__;!!BhdT!04s1Z7EtCnJrifRI3dUP1d0hps2MsV_B1gLCAqMQ1jJwmHnx-jiXCD5jrkAO$> techniques in an IPv6 framework. IIUC, this is very much how things are "supposed to work" -- measurement definitions and methodology are done by IPPM, and the protocol-specific instantiations are in the respective working groups.

However, there are complications in that 8321 and 8889 are Experimental RFCs, and the ipv6-alt-mark draft is a Proposed Standard. This has resulted in text from 8321/8889 going into ipv6-alt-mark so that it can be elevated to PS. I'm told that, if the status quo holds, other drafts will reference ipv6-alt-mark to avoid a downref. This seems suboptimal.

I would prefer that we take one of the two following actions:
1) If the WG has consensus that we are comfortable that there is enough experience with 8321 and/or 8889 to elevate them to PS, I can initiate a document action to change their status.

2) If there is no such consensus, ipv6-alt-mark should be Experimental.

In either case, the draft can probably lose some of the duplicate text.

Logically, there is a third option -- that the bits of the RFCs copied in the draft are mature enough to be a standard, but that the others aren't. Though I'm not an expert, I doubt this is the case. But if people believe it to be true, we'll have to come up with new options.

I would be grateful for the working group's thoughts about these documents and the ideas therein. Is it reasonable for people to read and reflect on this by 26 August (2 weeks from today?)

Thanks,
Martin
如果您错误接收了该邮件,请通过电子邮件立即通知我们。请回复邮件到 hqs-spmc@chinaunicom.cn<mailto:hqs-spmc@chinaunicom.cn>,即可以退订此邮件。我们将立即将您的信息从我们的发送目录中删除。 If you have received this email in error please notify us immediately by e-mail. Please reply to hqs-spmc@chinaunicom.cn<mailto:hqs-spmc@chinaunicom.cn> ,you can unsubscribe from this mail. We will immediately remove your information from send catalogue of our.