Re: [Tsv-art] Tsvart last call review of draft-ietf-6man-ipv6-alt-mark-06

Yoshifumi Nishida <nsd.ietf@gmail.com> Fri, 18 June 2021 16:23 UTC

Return-Path: <nsd.ietf@gmail.com>
X-Original-To: tsv-art@ietfa.amsl.com
Delivered-To: tsv-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 631603A186E; Fri, 18 Jun 2021 09:23:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, 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 nyYVQGoKpm1f; Fri, 18 Jun 2021 09:22:59 -0700 (PDT)
Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) (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 93A3D3A16EC; Fri, 18 Jun 2021 09:22:58 -0700 (PDT)
Received: by mail-qt1-x82c.google.com with SMTP id o20so7931378qtr.8; Fri, 18 Jun 2021 09:22:58 -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=yfDhBk3m4ENohv2ykXt2SvPAVk8AyeGL6IjuvYOInE0=; b=B02Ma1D1AzvnWd40GdlevUnLU+hyJvBHpcNQ8B8XtwJv7vXyID/ezqzSpvMyyVM4XW VHHh1JTB+iIQJLVFyrknATSpWcnE2Wz9aTc2NqjRgIKiDbcs2iKHjBFCE76lu0KSuV8m uzt0qTPr+KtHiO6syR1+PloJe5R3lqwj7GMXLJ/49crx/dnLZDO4mjxKQpV53I1pXZ9y fzAoMh/gHK9S9JO5D5cyufbbZm2hvchTl+KmtO67Ggo+vLbp4v1WEMVGuzMAUdwq7DIm jPZSEHhuZXIONSFKeQIOnM3V+Sri5Sy7VwWnAaDpDyeZDNWHPSPtwt/wA2eq/TGMc5Ud E+9Q==
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=yfDhBk3m4ENohv2ykXt2SvPAVk8AyeGL6IjuvYOInE0=; b=bwMHa2c8Bx62op4B9AR7nE4/6gBDB7V9k1gccf0uCTjMELz4R4Fvm7MFg8u1hK/1kU QjCYabW0puDpALcv2Q+mSIKeVQh0um/A9+V+kFVBQU1IF21PzClPo4VqB6Z2Rtqa8aYd UFtICh3Dlb1QIdEiLhP1Zm19UJ0C8MlkTc/6Y8zjSTcWSyTtdbV1k/+7LQPEPqoIDS5o zG3uKfMBSPOe/OMlgaGn8EoueC2uCoYaMzkLG1f3c32J2bj/4wdGk2D9fI2ZplWT3Ktx 2KQESPjGiwlXGhvPUTYZi0ZSuFtXk6oNrv0W28dzJsImnf6K2ATOeDgWccpJ66fuYBDL +1NA==
X-Gm-Message-State: AOAM532c8dkpMO2uwBVCBcp3MEF61o1AIdM2HCicd2jwe4iqb7rJqaiE FQqWK+QgZumDg7HWkW1QGixTjnKYHa9EC7+HUnY=
X-Google-Smtp-Source: ABdhPJxc6sa8ehtKLPC2I7ta1Ae/Z4kcMr1mA7t12ngO0q1I5dre/dAG6ZxemAQOGS9CkSttzkhBTMcWH4HFsrvdzQk=
X-Received: by 2002:ac8:140a:: with SMTP id k10mr11466370qtj.190.1624033375484; Fri, 18 Jun 2021 09:22:55 -0700 (PDT)
MIME-Version: 1.0
References: <162383331612.20524.16296649297265738669@ietfa.amsl.com> <5b59fb83f5cd44f8b63cb4df49a63261@huawei.com> <CAAK044SzqyRuXe_Hb2oCtAUiqZWEvs1zqU0sEkvXDap1ESM+cQ@mail.gmail.com> <b86b23bb46dc4b69939a107c737fcdca@huawei.com>
In-Reply-To: <b86b23bb46dc4b69939a107c737fcdca@huawei.com>
From: Yoshifumi Nishida <nsd.ietf@gmail.com>
Date: Fri, 18 Jun 2021 09:22:44 -0700
Message-ID: <CAAK044SwfE8p8+WNCa2rGH1CmPymJ+tk8b6GDNry=LF1_duJCA@mail.gmail.com>
To: Giuseppe Fioccola <giuseppe.fioccola@huawei.com>
Cc: "tsv-art@ietf.org" <tsv-art@ietf.org>, "draft-ietf-6man-ipv6-alt-mark.all@ietf.org" <draft-ietf-6man-ipv6-alt-mark.all@ietf.org>, "ipv6@ietf.org" <ipv6@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000072ffa605c50cbcb3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/qJg0T8R4PF7LIQBDf0WSKvWW7ew>
Subject: Re: [Tsv-art] Tsvart last call review of draft-ietf-6man-ipv6-alt-mark-06
X-BeenThere: tsv-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Review Team <tsv-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsv-art/>
List-Post: <mailto:tsv-art@ietf.org>
List-Help: <mailto:tsv-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 18 Jun 2021 16:23:05 -0000

Hi Giuseppe,

Oh, sorry. I overlooked that RFC8321 is an experimental doc.
Yes, it makes sense.

Thanks,
--
Yoshi

On Fri, Jun 18, 2021 at 2:43 AM Giuseppe Fioccola <
giuseppe.fioccola@huawei.com> wrote:

> Dear Yoshi,
>
> Regarding the relationship with RFC 8321, we already discussed this point
> with 6MAN chairs and ADs. RFC8321 is experimental while this document is
> standards track, since it aims to apply the method described in RFC 8321 to
> the IPv6 protocol.
>
> For this reason, to avoid that this draft totally relies on an
> experimental RFC, it was agreed to include the detailed description of the
> methodology and lighten this dependency. Indeed it is now an informative
> reference.
>
>
>
> I would suggest to include in the next revision some more consideration
> from RFC8321. Looking at the Last Call comments, it seems there are some
> parts of RFC 8321 (e.g. section 3.2. and section 4.1) that need to be
> described also in this document to clarify the applicability.
>
> We plan to revise the section on Alternate Marking Method Operation
> accordingly.
>
>
>
> Regards,
>
>
>
> Giuseppe
>
>
>
>
>
> *From:* Yoshifumi Nishida <nsd.ietf@gmail.com>
> *Sent:* Friday, June 18, 2021 8:08 AM
> *To:* Giuseppe Fioccola <giuseppe.fioccola@huawei.com>
> *Cc:* tsv-art@ietf.org; draft-ietf-6man-ipv6-alt-mark.all@ietf.org;
> ipv6@ietf.org; last-call@ietf.org
> *Subject:* Re: Tsvart last call review of draft-ietf-6man-ipv6-alt-mark-06
>
>
>
> Hi Giuseppe,
>
>
>
> Sounds good to me. Thank you so much.
>
> While you're updating documents, I think it would be better to elaborate
> on the relationships
>
> between this draft and RFC8312 a bit more as the doc seems to depend on
> the doc to some extent.
>
> The draft would be a supplemental doc for the RFC or does it update some
> parts?
>
> If it updates, I think the header should contain the info.
>
> Also, I am thinking that you might want to add it to normative references.
>
>
>
> Thanks,
>
> --
>
> Yoshi
>
>
>
> On Wed, Jun 16, 2021 at 7:05 AM Giuseppe Fioccola <
> giuseppe.fioccola@huawei.com> wrote:
>
> Dear Yoshi,
> Thanks a lot for your review.
> Please find my answers inline tagged as [GF].
>
> Regards,
>
> Giuseppe
>
>
> -----Original Message-----
> From: Yoshifumi Nishida via Datatracker <noreply@ietf.org>
> Sent: Wednesday, June 16, 2021 10:49 AM
> To: tsv-art@ietf.org
> Cc: draft-ietf-6man-ipv6-alt-mark.all@ietf.org; ipv6@ietf.org;
> last-call@ietf.org
> Subject: Tsvart last call review of draft-ietf-6man-ipv6-alt-mark-06
>
> Reviewer: Yoshifumi Nishida
> Review result: On the Right Track
>
> This document has been reviewed as part of the transport area review
> team's ongoing effort to review key IETF documents. These comments were
> written primarily for the transport area directors, but are copied to the
> document's authors and WG to allow them to address any issues raised and
> also to the IETF discussion list for information.
>
> When done at the time of IETF Last Call, the authors should consider this
> review as part of the last-call comments they receive. Please always CC
> tsv-art@ietf.org if you reply to or forward this review.
>
> Summary: I think this document is on the right track, but it needs to
> address
>                    the following points to be published as a PS document.
>
>
> 1: I think the doc should provide a high-level view of the usage of this
>    method. For example, it is not clear to me how measurement nodes
> interact
>    each other, exchange and compare information, etc. If it is provided in
>    other documents, it should be referred.
>
> [GF]: Sure, this is the base document on the data plane. We are already
> working on some documents for the control plane mechanisms, e.g.
> draft-ietf-idr-sr-policy-ifit, draft-chen-pce-pcep-ifit. They will be
> referred in the next version.
>
> 2: Section 5.1: "By counting the number of packets in each batch and
>    comparing the values measured by different network nodes along the path,
>    it is possible to measure the packet loss occurred in any single batch
>    between any two nodes."
>
>     -> It is not clear to me how two nodes exchanges the measured counts.
>        This point should be clarified even if if it's out-of-scope of the
>        document.
>
> [GF]: In the implementation the counters can be sent out to the
> controllers that is responsible of the calculation. Anyway it is also
> possible to exchange this information by using other on-path techniques. We
> will add more details in the next version but the detailed description will
> be done in a separate document.
>
> 3: Section 5.1: "In a few words this implies that the length of the batches
>    MUST be chosen large enough so that the method is not affected by those
>    factors."
>
>     -> It would be better to have recommended length values here.
>        At least, it would be better to provide some guidances to decide
>        the value.
>
> [GF]: Agree. I will add a pointer to section 3.2 of RFC 8321, where it is
> possible to find the guidance to and in particular the mathematical
> formulation to decide the value.
>
> 4: Section 5.1:
>    Can we change the length of batch in the middle of data transfer?
>    Also, is there any concerns to use different length for each flow?
>    I think it would be better to specify on these points.
>
> [GF]: In theory it is possible. It is up to the implementation. The length
> of batches can be changed over time and among different flows. It could
> complicate the correlation of the information but it can be done to allow a
> flexible monitoring. We can specify these aspects.
>
> 5: Section 5.2:
>    I am wondering if this approach requires time sync between nodes or not.
>    This point should be clarified.
>
> [GF]: As explained in section 4.1 of RFC 8321, the Alternate Marking
> technique does not require a strong synchronization. In section 3.2 of RFC
> 8321 it is reported the condition that must be satisfied on the
> synchronization accuracy. I'm thinking to add a pointer or summarize the
> concept in this document as well.
>
> 6: Section 5.2:
>    "Whenever the L bit changes and a new batch starts, a network node
>    can store the timestamp of the first packet of the new batch, that
>    timestamp can be compared with the timestamp of the first packet of the
>    same batch on a second node to compute packet delay."
>
>      -> It is not clear to me how two nodes compare the stored timestamps.
>         This point should be clarified.
>
> [GF]: It is similar to the case of packet loss. In the implementation the
> timestamps can be sent out to the controllers that is responsible of the
> calculation or could also be exchanged using other on-path techniques. We
> will add more details here too.
>
> 7: Section 5.2:
>    What's the benefits for using the approach described in 1.?
>    The use cases for it should be described.
>
> [GF]: The approach with double marking is better but we also mention the
> single marking for the sake of completeness. I can explain this and we can
> also highlight that the two approaches can also be combined to have more
> information.
>
> --
> Yoshi
>
>