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 06:08 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 DA3B53A3E38; Thu, 17 Jun 2021 23:08:17 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 ecmlsix_vm5f; Thu, 17 Jun 2021 23:08:11 -0700 (PDT)
Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (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 042923A3E37; Thu, 17 Jun 2021 23:08:07 -0700 (PDT)
Received: by mail-qk1-x730.google.com with SMTP id f70so8231226qke.13; Thu, 17 Jun 2021 23:08:07 -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=c1EdSN1TbFLalMAjmjp2HPG9WNQCW8Q69pNrR3OTBhs=; b=Jn4KZQDo1aIsmoD3TOKm1m1keTX/D4XXv3ad1zV7hKO6grYI29t0GVs8bnS9MZgndk Bhll03aGhNF2Qj0wlJvPZjbyyecrN0cuvwb++61obrI7aLfHNNS3zGLcWXIOMSlhXarb 7w/OGJFiA4J5Wr/80xKO0aqPXwFBIbgPwcOCRndQPclQf0+yq/3z/q9uyROqyTYNPiyi yzKZn9Q6sdr1AQd9wiMDP/6pk3tpc1T9DIbRU+xFa+UTm66lLFDqIuxr5smz5asY5Ey5 KcsMP6an7ehZ2pAeq7ZFPVvNbOF0MIn/4YZrDmw0xaso0wFXFPbUst0lmVQ7ZEVHs+y1 y+7Q==
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=c1EdSN1TbFLalMAjmjp2HPG9WNQCW8Q69pNrR3OTBhs=; b=DbpmDptA38mqHaqgZ5e9MvhY2LN/wD/wnfLmmo39OryoSQGcOlbVZcfIbKVZwE8SdC 2DVKl316Ijtp0GjvmXYEffN71My/m2u3KAHQh+CoumaI9627GBZhr+kYZXs7KccZSkcq 4cAu48qXBiwIgsbh9mXxK9Nebv2cLB8esGEV/qe0wGCMxr2BJaZhDGqlsLKIS91R7teT /ogLSFGEJGdjgNxtGTe1JzNKXXdrtH46SUQ3TXU4YjVxMFgV/qqtY+4ptHe7JOROFZZI 21Nu+VSjvcRIclIImB8cxZH+MP2LOA5W2AY02mSY/fHFyUrJrWhkboUpGC7BiQ1wGgrM Xopw==
X-Gm-Message-State: AOAM530Olmav8kdWpOdV7D9wz4PBo3jnN4DjQKWcQb5EdkOnKHscE9BD iVxFWpTvLKA6BMn7OWuvBgpSf6skwYE+T+/7Pis=
X-Google-Smtp-Source: ABdhPJxAqAq3/Z1ZmaoeWNfeq8XCEymdu/+z+cetmj6+Q3buMt9A0Mw4SPL2VwCSKCYC62F0z6Y3JP2+fl4dDe1KNkA=
X-Received: by 2002:ae9:ed91:: with SMTP id c139mr7665981qkg.454.1623996486443; Thu, 17 Jun 2021 23:08:06 -0700 (PDT)
MIME-Version: 1.0
References: <162383331612.20524.16296649297265738669@ietfa.amsl.com> <5b59fb83f5cd44f8b63cb4df49a63261@huawei.com>
In-Reply-To: <5b59fb83f5cd44f8b63cb4df49a63261@huawei.com>
From: Yoshifumi Nishida <nsd.ietf@gmail.com>
Date: Thu, 17 Jun 2021 23:07:55 -0700
Message-ID: <CAAK044SzqyRuXe_Hb2oCtAUiqZWEvs1zqU0sEkvXDap1ESM+cQ@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="000000000000b0e6da05c5042516"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/cUQwT03ACVhEQEkXrRVNnulmeDs>
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 06:08:18 -0000

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
>
>
>