Re: [Teas] Review of draft-ietf-teas-actn-pm-telemetry-autonomics-05

Dhruv Dhody <dhruv.ietf@gmail.com> Wed, 25 August 2021 17:40 UTC

Return-Path: <dhruv.ietf@gmail.com>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD5713A10CA; Wed, 25 Aug 2021 10:40:29 -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 biYXwj2x-Z-8; Wed, 25 Aug 2021 10:40:24 -0700 (PDT)
Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (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 D01233A10C7; Wed, 25 Aug 2021 10:40:23 -0700 (PDT)
Received: by mail-io1-xd2d.google.com with SMTP id b10so20376ioq.9; Wed, 25 Aug 2021 10:40:23 -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=b+zD2mPExZhh/+dmxudm+1qhMyE2G4b/+5RjV6ieSCw=; b=idqCJJ6uXMV++l92eBCANbLetVczpGLXzCDe0Pfb6/Iz03evlx6BavTnWBgylag6Qd KEp62exL+jIYyNAaYuvd2WayxqEk/yrbjz6JYdl2Z7cpaSCUYdz6qX5TonMA2P4Qw2fF W9epBK3N7ThGvlLe1jqjkBnqnjJSpvejRMBXTOIB+6W6INcIrJkG4XtjVKExYpcsWfB/ XH+pXdDIE970z58m2dHiU4DAx55zm+ZY7VxTfOehimMwDToZ0KMCHeZZqKXCpk0h3lT/ OROpKa2TmmIx7plWQkjlXvSJjTgsxoRtPJFH8XBGMP6sgIe7Txmmsoltuck2LneiP+/q TQhg==
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=b+zD2mPExZhh/+dmxudm+1qhMyE2G4b/+5RjV6ieSCw=; b=XkqadnJ0Q+m0y5E/j8ie6LourUA4Cl7krDbLd8I8z9Jp7mk7QVyldZB3TZMUlAg4nD g5/ySqsXpz5toM/2U9GgdseicUMMbzEgnCs5dvR4sMYMB2OPKVnMzDYMXYu6yPxGa0yc hU7/JGDfZwQP5u6xyMv5LfmCWlx5MZgcGbq/Es2y+uuypnkxCj+D1m4PC8ZX9/3plDeZ B/Ln8f+E8QpqG6QgLvdXjVSRlFWdP3keA1kpIyhy/ZGsO88QhL2fKTYA4sJLLHNMlnH+ q5N18UNHNeKGS87yVEs/eagDyotR7wKayGhFbTN2mfYGJdRN/THm7R43WOmGeyqHtdOp CM0w==
X-Gm-Message-State: AOAM5321yrZHJ5gb1i3uhITQfNuknKoQtSF/AEeJ1hR5cOahM3dxErp1 IquuUUc25pcphWrqBLWZbRynk0wslLN/Q6yoxL9n5cf8qX5J7e1V
X-Google-Smtp-Source: ABdhPJxP5T5wzp2PaWoyvz27Tf+MvG2/J4DdGb/m3GHB94AQ6aIEoKM+aCw8YTMIuThiFcQ72XHG73C/VLIvJZODRto=
X-Received: by 2002:a6b:f30b:: with SMTP id m11mr26733752ioh.0.1629913221642; Wed, 25 Aug 2021 10:40:21 -0700 (PDT)
MIME-Version: 1.0
References: <158801d7892e$3fae2fc0$bf0a8f40$@olddog.co.uk>
In-Reply-To: <158801d7892e$3fae2fc0$bf0a8f40$@olddog.co.uk>
From: Dhruv Dhody <dhruv.ietf@gmail.com>
Date: Wed, 25 Aug 2021 23:09:45 +0530
Message-ID: <CAB75xn5H1brWLc_Dq+Z+KJ9DLW06OzEgfsnACzzWiZ_AMq+Nxg@mail.gmail.com>
To: Farrel Adrian <adrian@olddog.co.uk>
Cc: draft-ietf-teas-actn-pm-telemetry-autonomics@ietf.org, "TEAS WG (teas@ietf.org)" <teas@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000097409005ca65be23"
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/z-6qEDmhDQX-va7s1UskVSr4SXM>
Subject: Re: [Teas] Review of draft-ietf-teas-actn-pm-telemetry-autonomics-05
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Aug 2021 17:40:30 -0000

Hi Adrian,

Thanks for your comments. I have made an update to the I-D based on your
excellent review. See
https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-actn-pm-telemetry-autonomics-06

More inline...

On Wed, Aug 4, 2021 at 6:13 PM Adrian Farrel <adrian@olddog.co.uk> wrote:

> Hi authors,
>
> I thought it was probably time to give this document a review. Here
> are some comments.
>
> Having digested this document, I strongly advise the TEAS chairs to
> send a notification to OPSAWG flagging that this work is handling
> performance metrics and uses an intent-based approach.
>
>
Dhruv: While the metrics are coming from RFC 8776 te-types directly
(reusing the grouping performance-metrics-attributes); it would be good to
have the "scaling intent" reviewed from the OPSAWG.



> Best,
> Adrian
>
> ===
>
> == Substance ==
>
> In Section 1 you have
>
>    [Editor's Note: A suggestion is made to remove the word KPI from the
>    name of the model.  Further discussion is needed.]
>
> It seems that the only use of "KPI" is in the model names.  It would,
> therefore, seem reasonable to remove the name and clean up the one
> paragraph in Section 1...
>
> OLD
>    [RFC8233] describes key network performance data to be considered for
>    end-to-end path computation in TE networks.  Key performance
>    indicator (KPI) is a term that describes critical performance data
>    that may affect VN/TE-tunnel service.  The services provided can be
>    optimized to meet the requirements (such as traffic patterns,
>    quality, and reliability) of the applications hosted by the
>    customers.
> NEW
>    [RFC8233] describes key network performance data to be considered for
>    end-to-end path computation in TE networks.  The services provided
>    can be optimized to meet the requirements (such as traffic patterns,
>    quality, and reliability) of the applications hosted by the
>    customers.
>
>
Dhruv: Removed KPI from the I-D



> ---
>
> 1.1
>
> The only place the term "Key Performance Data" is used is in this
> section (apart from the Abstract and Introduction). Perhaps it doesn't
> need to be in this section?
>
>
Dhruv: done.



> ---
>
> 1.1.1
>
> With the nit fix to section 4 (see below) there is no use of 2119
> language. So you can strike this section, remove the boilerplate from
> the two models, and remove the references to 2119 and 8174.
>
>
Dhruv: done.


> ---
>
> 2.
>
> Is [I-D.xu-actn-perf-dynamic-service-control] the wisest reference to
> make here? That document expired as an individual submission in 2015.
>
> Since this document mainly reproduces materials, why not just make the
> points you want to make and move on.
>
>
Dhruv: done.



> ---
>
> The term "transport network" is used a few times. Is this a left-over
> from when ACTN was "Transport" not "TE"?
>
>
Dhruv: updated to TE.



> ---
>
> Section 2, bullet 2
>
>       However, for other performance parameters, there are
>       no such mechanisms.
>
> I think you mean "SLA requirements" not "performance parameters"
>
>
Dhruv: yes!



> ---
>
> 3.2
>
>    This module describes performance telemetry for VN model.  The
>    telemetry data is augmented both at the VN Level as well as
>    individual VN member level.
>
> Is it the telemetry data that is augmented?
> I think the VN model is augmented by/with the telemetry data.
>
>
Dhruv: updated.



> ---
>
> Question about the overlap between the models.
>
> I was going to write a long thing saying that there was overlap
> between the models and that you should have a common model that augments
> both the TE and VN models and which is itself augmented by the
> VN-telemetry model.
>
>
Dhruv: Updated figure 3 to show the relationship.



> In fact, when I got to Section 7 I found this is exactly what you have!
>
> However, the whole of the rest of the document talks about the two
> models being entirely separate. Even the trees are out of date. That all
> needs fixing.
>
>
Dhruv: updated



> ---
>
> When leaf threshold-value (which is a string) is applied to the
> different members of telemetry-param-type, I think more help is needed
> to know how to interpret the value. For example, is one-way-delay
> measured in hours or weeks, or is it a percentage?
>
> I think the way to handle this is in the description clauses for each
> telemetry-param-type where you can say:
>
>    "The threshold-value for this type is interpreted as..."
>
>
Dhruv: added for each identity.



> ---
>
> I believe it would be helpful to explain why the TE model has
> scaling-operation while the VN model adds grouping-operation. That is,
> the reader wonders why grouping is not applicable to TE tunnels.
>
> The answer is presumably that, with a VN, grouping can be applied across
> a number of TE tunnels that are members of the VN, and that doesn't
> apply to telemetry for a single tunnel. However, I didn't learn this
> from the text and had to work it out for myself.
>
>
Dhruv: See
https://www.ietf.org/archive/id/draft-ietf-teas-actn-pm-telemetry-autonomics-06.html#section-3.2-4



> ---
>
> It's great that Section 5 includes examples for notifications. This is a
> considerable help to the reader.
>
> I think that it would be useful to include an example of the use of the
> models defined in this document for both a single TE tunnel and for a
> VN. This would also help explain the use of scaling and grouping.
>
>
Dhruv: Added
https://www.ietf.org/archive/id/draft-ietf-teas-actn-pm-telemetry-autonomics-06.html#section-5.2



> ---
>
> 8.
>
>    These are the subtrees and data nodes
>    and their sensitivity/vulnerability:
>
>    o  /te:te/te:tunnels/te:tunnel/te-scaling-intent/scale-in-intent
>
>    o  /te:te/te:tunnels/te:tunnel/te-scaling-intent/scale-out-intent
>
>    o  /vn:vn/vn:vn/vn-scaling-intent/scale-in-intent
>
>    o  /vn:vn/vn:vn/vn-scaling-intent/scale-out-intent
>
> Seems to me that you have successfully listed the subtrees / data nodes,
> but you haven't mentioned their sensitivity/vulnerability.
>
>
Dhruv: Updated



> ---
>
> Prefix names...
> I am not an expert, but it seems to me that the two names requested in
> Section 9 (te-tel and vn-tel) are not used consistently in the rest of
> the document.
> For example, in 7.2 I see vn-kpi instead of vn-tel.
> Can you please look through the whole document and make sure everything
> is clean.
>
>
Dhruv: ack.



> == Nits==
>
>
Dhruv: thanks for spotting them!

Thanks!
Dhruv