Re: [ippm] WGLC for draft-ietf-ippm-pam

Greg Mirsky <gregimirsky@gmail.com> Tue, 15 August 2023 16:13 UTC

Return-Path: <gregimirsky@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 A48EAC151983 for <ippm@ietfa.amsl.com>; Tue, 15 Aug 2023 09:13:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Level:
X-Spam-Status: No, score=-2.095 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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_HTML_ATTACH=0.01, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mOGCNSsoxMxb for <ippm@ietfa.amsl.com>; Tue, 15 Aug 2023 09:13:24 -0700 (PDT)
Received: from mail-yb1-xb36.google.com (mail-yb1-xb36.google.com [IPv6:2607:f8b0:4864:20::b36]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18278C15198D for <ippm@ietf.org>; Tue, 15 Aug 2023 09:13:24 -0700 (PDT)
Received: by mail-yb1-xb36.google.com with SMTP id 3f1490d57ef6-d712d86eb96so551134276.3 for <ippm@ietf.org>; Tue, 15 Aug 2023 09:13:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1692116003; x=1692720803; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=QuoPJ+BQWRN9IoDgM9gl0DHSSvFs+hHBHfCEWwKJ6Ps=; b=cRMoUS/68k8OeqgGO9dlxiAz/GDTJqUrWqbpZ/44cZwUrBpwoh+7eOFFDfw+WSTsiH IYQVMIJXxd3gSHncy1ug8T72codh66yaeA0ICyTt4wp1tzz8oXHpOSNPfFcuhpLRL4XT Ph+3ZJsVNqvdP4pFzTuuHCVkMzIcyzm9xzDN5WOfO0bOQ7oAerfsck0t6AMwidmTTJUN jTn47sVN5VR75bhWohAQcu+PLMeY8w2mAWhpvRq7P8owapxYTlPfwzLG8mzYk9h3rmTr UQgyGdbdmROSG3q1TZQcOxWkzuGPJum+HW0nEiVuiIvAhYhtgzlLRxg1NVZpn8zFOC75 6wLQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692116003; x=1692720803; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=QuoPJ+BQWRN9IoDgM9gl0DHSSvFs+hHBHfCEWwKJ6Ps=; b=iFWYcKn+l1N1b3+PJkYPqZw8bM2h6w6a8D4Ii/Hu/B6ZkBofqinoihf853Thsezvlg fcVwvVzAdlfB+/0CVmIfCWBYgcepL6hKDYXa+M6qtwM/8nGwVrdHD9rtv1TZMnIgWEI/ t2hgDyFc/1z9vpmdSNsq4QUt0/J6kwzNx+wzq5NIioYhEGkD3TTNSBmSlWL/1952k+DY JAweCOrRIxIozBRuo8rtIuxpyQpF1Q+eQsIXDHksO/OBMSLYazvKQ3rq2pgZyGmBxvdR akGISOQ91ZQEgchoYxdUAXuYGEF1Tlex093tSEyGQVRz8oKNCUS7kb7s1e+AnAv093i2 uGaQ==
X-Gm-Message-State: AOJu0YwiYT0CF1UPQh3ZgLV8Y+SLiUOMNL89+wFeB9c3kuHiijTVZP0H 3DAwPN8Rv6T38O3Af19PgyVLHlVSWt4QBNr1Dv99BRo2
X-Google-Smtp-Source: AGHT+IFIpyxnM7P5DDW2oPnLIG6oeUq92X2nqnfsrpxqbO4UQlmC1cupniguMvkD0Uzzx/begEqmuYoFsHHzrRQr5U0=
X-Received: by 2002:a25:2e0b:0:b0:d32:e73d:6bfa with SMTP id u11-20020a252e0b000000b00d32e73d6bfamr10556674ybu.12.1692116002995; Tue, 15 Aug 2023 09:13:22 -0700 (PDT)
MIME-Version: 1.0
References: <40618A8A-B2A5-4BA4-B206-FC061299D9AD@apple.com> <CAE4dcxnBbyKbPyibejmRa2fnjFfSBBoKg6iBWqgfoEouLJroOQ@mail.gmail.com>
In-Reply-To: <CAE4dcxnBbyKbPyibejmRa2fnjFfSBBoKg6iBWqgfoEouLJroOQ@mail.gmail.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Tue, 15 Aug 2023 09:13:11 -0700
Message-ID: <CA+RyBmWSKw43YEnvinRejARv8GwLu7mySLWOrWzHJ=5f5q+i-g@mail.gmail.com>
To: "Luis M. Contreras" <contreras.ietf@gmail.com>
Cc: Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org>, IETF IPPM WG <ippm@ietf.org>
Content-Type: multipart/mixed; boundary="0000000000004736810602f875f2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/XzkdD81Jclelc9jI2EPnE26-2sQ>
Subject: Re: [ippm] WGLC for draft-ietf-ippm-pam
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.39
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: Tue, 15 Aug 2023 16:13:29 -0000

Hi Luis,
thank you for supporting the work on PAM and for your thoughtful comments
and suggestions. Please find responses below inline under the GIM>> tag.
Please review the attached diff that highlights updates (including those to
address comments received from Thomas)

Regards,
Greg

On Fri, Aug 11, 2023 at 3:43 AM Luis M. Contreras <contreras.ietf@gmail.com>
wrote:

> Hi all,
>
> After reviewing the document, I do support the progress of this draft as
> it provides a useful approach for service characterization when multiple
> SLOs are in place.
>
> Some few comments / questions:
>
> - Abstract refers to Network Slice service, shouldn’t be better to name it
> as IETF Network Slice service for consistency with TEAS work?
>
> - Also in Abstract: "PAM can be used by providers and/or users of a
> Network Slice service". It would be good to align terminology with the one
> in IETF Network Slice framework (e.g., customer instead of user).
>
GIM>> Thank you for pointing that out. Perhaps the following update be
acceptable addressing both comments above:

OLD TEXT:
   For example, PAM can be
   used by providers and/or users of a Network Slice service to assess
   whether the service is provided in compliance with its defined SLOs.
NEW TEXT:
   For example, PAM can be
   used by providers and/or customers of an network slice service, e.g.,
   IETF Network Slice Service, to assess whether the service is provided
   in compliance with its defined SLOs.

> - When introducing violated intervals, in section 3.1 it is referred that
> the calculation is done between two nodes. I assume those nodes should not
> be necessary adjacent nodes, but maybe it could be worth clarifying that.
>
GIM>> I agree, the determination of an interval (violated, severely
violated, or free of violation) follows the determination of the applicable
SLO. Would the following update be acceptable?

OLD TEXT:

   Mechanisms of setting levels of threshold of an SLO are outside the

   scope of this document.

NEW TEXT:

   The monitoring performance parameters to determine the quality of an

   interval is performed between the elements of the network that are

   referred to for the SLO corresponding to the performance parameter.

   Mechanisms of setting levels of a threshold of an SLO are outside the

   scope of this document.

> Furthermore, thinking on IETF Network Slice services, there could be
> additional considerations: (1) the calculation can involve more than two
> nodes (e.g., in point to multipoint or any to any connectivity constructs),
>
GIM>> To the best of my understanding, SLA and SLO, even for p2mp or mp2mp
services, are defined between two UNIs. WDYT?

> and (2) the definition probably need to consider the fact of being
> measured between SDPs (i.e., client ports of nodes, even considering the
> situation where those client ports could also be part of the same node).
> With these considerations, the mentioned calculation is equally
> applicable?
>
GIM>> I think that the list of where a measurement point (MP) may be
located can be extended by adding, for example, a probe. Often (I don't
know if "always") the location of MPs is specified in the SLA or a
normative document that defines the relevant Service OAM. And yes, the
monitoring of PAM and calculation of PAM-related metrics would be
applicable if an MP is placed at an SDP. Would you suggest a text to add?

> - How to account for events that could impact more than one SLO at the
> same time? For instance, a mis-ordered packet could impact at the same time
> the SLOs of packet ordering and jitter (for instance). It would be
> interesting to have some guidance on how to consider those situations,
> i.e., if the SLO violation should be accounted per SLO or summarized for
> instance accounting simply the one of highest severity. Another possibility
> could be to include an additional indicator reflecting these situations.
>
GIM>> That is an interesting scenario. I think that we have covered that by
pointing out that the violation is determined by the degradation of at
least one of the set of monitored parameters:

   *  VI is a time interval during which at least one of the performance

      parameters degraded below its pre-defined optimal level threshold.

   *  SVI is a time interval during which at least one the performance

      parameters degraded below its pre-defined critical threshold.
Thus, as I think of that scenario, a failure may constitute itself as a VI
or SVI of one or more SLOs.

> - Being PAM targeting multi-SLO services, would it not be worthy to define
> the same kind of precision metrics per SLO as well? As today, the
> precision metrics show an aggregated view of the potential issues found,
> but it would be beneficial to provide more detailed insights by showing the
> same kind of metrics per SLO so that the provider or consumer can have more
> insightful information about what issue is affecting the service.
>
GIM>> If we imagine a service that is defined by a single SLO, then, in my
opinion, the PAM is applicable as we have defined it. Do you think that we
need to add some text illustrating how PAM metrics can be applied to each
SLO that composes SLA and then to the combination of those SLOs as a
multi-SLO governed service?

>
>
> Thanks,
>
> best regards
>
> Luis
>
>
>
>
>
>
>
>
>
>
>
> El mar, 8 ago 2023 a las 17:30, Tommy Pauly (<tpauly=
> 40apple.com@dmarc.ietf.org>) escribió:
>
>> Hello IPPM,
>>
>> This email starts a Working Group Last Call for "Precision Availability
>> Metrics for Services Governed by Service Level Objectives
>> (SLOs)”, draft-ietf-ippm-pam.
>>
>> https://www.ietf.org/archive/id/draft-ietf-ippm-pam-05.html
>> https://datatracker.ietf.org/doc/draft-ietf-ippm-pam/
>>
>> Please review the document and send your comments in response to this
>> email, along with whether you think the document is ready to progress.
>>
>> Please send your reviews and feedback by *Tuesday, August 22*.
>>
>> Best,
>> Tommy & Marcus
>> _______________________________________________
>> ippm mailing list
>> ippm@ietf.org
>> https://www.ietf.org/mailman/listinfo/ippm
>>
>
>
> --
> ___________________________________________
> Luis M. Contreras
> contreras.ietf@gmail.com
> luismiguel.contrerasmurillo@telefonica.com
> Global CTIO unit / Telefonica
> _______________________________________________
> ippm mailing list
> ippm@ietf.org
> https://www.ietf.org/mailman/listinfo/ippm
>