Re: [ippm] RFC 8321 and 8889

Martin Duke <martin.h.duke@gmail.com> Fri, 27 August 2021 20:37 UTC

Return-Path: <martin.h.duke@gmail.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 3436D3A1732 for <ippm@ietfa.amsl.com>; Fri, 27 Aug 2021 13:37:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 Q7hXEv5JmgMw for <ippm@ietfa.amsl.com>; Fri, 27 Aug 2021 13:37:21 -0700 (PDT)
Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE5A33A172C for <ippm@ietf.org>; Fri, 27 Aug 2021 13:37:21 -0700 (PDT)
Received: by mail-io1-xd2c.google.com with SMTP id a13so10095442iol.5 for <ippm@ietf.org>; Fri, 27 Aug 2021 13:37:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MLV5j8LksvlDP3VkVaeIG36j6slKhGkQUph8gofgG28=; b=nCaXztxV67QH9Z4/5inYr5vnPZCI6I04/BQF8x2SUpEbNo8AHMceVqKoBivTCaG7UH l83ake9tkX44VW18DH+gdPLfa9QUimgYLq1xyb5xxR6ZINu9ktAAucT7csgIjI3JLE3M yU0YhjGBxfl13OHh8SUK/Kjb5YT5KE8awK0v+DWa5HbFz4op7cFUDu/TbURoYSi+MgHG rzAzzghLbVpoiFljt14q1BSA9pfNo900NBcZSzvXJbsAIywKUEmcNBujWCQNFi6SixP+ ObksyvtEX2OWtE86YQL4x3cOcCGvcGYQyQAOMhepatI26vzSq+IPyafI1hMmmn7fYevP mM5Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MLV5j8LksvlDP3VkVaeIG36j6slKhGkQUph8gofgG28=; b=TGEFBzuypbxZ+puS/ohS4+Ff36XUpGo0g1mjJjyRR3faQWM7X+SPmOD1bgvBM0yWAo Lrozuo/lZp26D1ZwMCyIZuOHykBsn2i2Da8xpRW/MuZHoybjkdlQN9KzCaXyir+dKwlP Ci69y5G3tWojVuN+ezCjSZ2LRXgF/qoCrAMw7qkjhaI9U5+HhUWfcEgRmi4BChP1/D23 FQv0Epo/wkWxSYt6Pqv9cv6hUQdRtWn4XIQ2p75c6Li0zkwqOD7mmPOmI8qtJfze1GAz 9qt0AMvTfmLc++2DtNDs/ucLjre9UH7gvq00RdHgGwGGDAnYAq00JJH4UXOtt7O7oQuz D1kA==
X-Gm-Message-State: AOAM531bc0OTaaVkqtqBdzyGcrmH+N9Brrr08OcMsypMa/Szvg76EKdh 30FF0AaFlyg2KGNSVP8SHYUcESTChRgKdy3rbMc=
X-Google-Smtp-Source: ABdhPJzr7/CGOY0E8NREwig5sbD2vJYJ4ZE/g4czblfOGWjn2YfJtO8g9q0Yf4byS41YpyAbI1tSqAHOvpF029ewpWY=
X-Received: by 2002:a02:cf34:: with SMTP id s20mr9910313jar.121.1630096639890; Fri, 27 Aug 2021 13:37:19 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <6c463f9daf414b9eaaa39e8db74898a0@huawei.com>
From: Martin Duke <martin.h.duke@gmail.com>
Date: Fri, 27 Aug 2021 13:37:08 -0700
Message-ID: <CAM4esxQWikydTakJOmwS2WcBZ2pXPu+M1CHw=f+53uKOYuBjmg@mail.gmail.com>
To: Giuseppe Fioccola <giuseppe.fioccola@huawei.com>
Cc: "MORTON JR., AL" <acmorton@att.com>, =?UTF-8?B?UmFuIFBhbmco6IGU6YCa6ZuG5Zui5Lit5Zu96IGU6YCa56CU56m26ZmiLeacrOmDqCk=?= <pangran@chinaunicom.cn>, IETF IPPM WG <ippm@ietf.org>, Erik Kline <ek.ietf@gmail.com>
Content-Type: multipart/alternative; boundary="0000000000002b9cb405ca9073a0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/6pupHjKvhVxk_KhLkWZ-dnGwiEQ>
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: Fri, 27 Aug 2021 20:37:29 -0000

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/

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> 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> *On Behalf Of * Martin Duke
> *Sent:* Monday, August 23, 2021 9:34 PM
> *To:* MORTON JR., AL <acmorton@att.com>
> *Cc:* Ran Pang(联通集团中国联通研究院-本部) <pangran@chinaunicom.cn>cn>; IETF IPPM WG <
> 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> 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> *On Behalf Of *Martin Duke
> *Sent:* Friday, August 20, 2021 12:31 PM
> *To:* Ran Pang(联通集团中国联通研究院-本部) <pangran@chinaunicom.cn>
> *Cc:* IETF IPPM WG <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> 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 <martin.h.duke@gmail.com>
>
> *Date:* 2021-08-13 02:26
>
> *To:* IETF IPPM WG <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,即可以退
> 订此邮件。我们将立即将您的信息从我们的发送目录中删除。 If you have received this email in error
> please notify us immediately by e-mail. Please reply to
> hqs-spmc@chinaunicom.cn ,you can unsubscribe from this mail. We will
> immediately remove your information from send catalogue of our.
>
>