Re: [OPSAWG] draft-ietf-ippm-pam-04, draft-clemm-opsawg-pam-ipfix-00

Thomas.Graf@swisscom.com Sat, 19 August 2023 07:06 UTC

Return-Path: <Thomas.Graf@swisscom.com>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0407C15106F; Sat, 19 Aug 2023 00:06:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.905
X-Spam-Level:
X-Spam-Status: No, score=-6.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
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 gwdp0F06Bxbz; Sat, 19 Aug 2023 00:06:49 -0700 (PDT)
Received: from mail.swisscom.com (mailout110.swisscom.com [138.188.166.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FB4AC14CE4F; Sat, 19 Aug 2023 00:06:47 -0700 (PDT)
Received: by mail.swisscom.com; Sat, 19 Aug 2023 09:06:44 +0200
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="----=_Part_101278_347166141.1692428803698"
X-Mailer: Totemo_TrustMail_(Notification)
From: Thomas.Graf@swisscom.com
To: gregimirsky@gmail.com
CC: opsawg@ietf.org, ippm@ietf.org
Thread-Topic: [OPSAWG] draft-ietf-ippm-pam-04, draft-clemm-opsawg-pam-ipfix-00
Thread-Index: AdnABHKKhn+NCESzR5yR1xy3QrobHAO2VEiAAL88DSAACIkuAAAbttny
Date: Sat, 19 Aug 2023 07:06:40 +0000
Message-ID: <11331783-F27A-4DA2-91D6-C02B0D9BBBD6@swisscom.com>
References: <c64305be6851427c99db9ca4e938f011@swisscom.com> <CA+RyBmVyURk2FobDs5uQgmQ+zdhrnY7P=m_DT3oV5zLGVTL9kw@mail.gmail.com> <2aa0bd97a2f34e4c9f1bd3da2a66c9ec@swisscom.com>, <CA+RyBmW0UAnHttunf3_zQYssknRKC93XSPp44mnXGNRFZH=EWA@mail.gmail.com>
In-Reply-To: <CA+RyBmW0UAnHttunf3_zQYssknRKC93XSPp44mnXGNRFZH=EWA@mail.gmail.com>
Accept-Language: en-US, de-CH
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
X-CFilter-Loop: Reflected
X-Trustmail: processed
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/TBPslosJVS-msUsgPLtAuac-KBs>
Subject: Re: [OPSAWG] draft-ietf-ippm-pam-04, draft-clemm-opsawg-pam-ipfix-00
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 19 Aug 2023 07:06:53 -0000

Dear Greg,

Thanks a lot. Valid point on connectivity service terminology. The proposed text works for me. Perfect.

Best wishes
Thomas

On 18 Aug 2023, at 21:53, Greg Mirsky <gregimirsky@gmail.com> wrote:


Hi Thomas,
thank you for the feedback and proposed update. Please find my notes below tagged by GIM2>>.

Regards,
Greg

On Fri, Aug 18, 2023 at 6:56 AM <Thomas.Graf@swisscom.com<mailto:Thomas.Graf@swisscom.com>> wrote:
Dear Greg,

Thanks a lot for addressing my comments.

GIM> It could be easier to take out "flow" altogether. WDYT?

TG> Let me propose something else:

Change from

"When analyzing the availability metrics of a service flow between two nodes"

To

"When analyzing the availability metrics of a connectivity service between two measurement points"
GIM2>> Prior to IETF-117 the authors extensively discussed the definition of a connectivity service. Because we couldn't find it being formulated in published documents we agreed to avoid referencing it in the PAM document. I hope that you will agree to the following update:
OLD TEXT:
   When analyzing the availability metrics of a service flow between two
   nodes, a time interval as the unit of PAM needs to be selected.
NEW TEXT:
   When analyzing the availability metrics of a service between two
   measurement points, a time interval as the unit of PAM needs to be
   selected.

GIM>> I agree. Check the attached diff.

TG> Perfect thanks!
GIM2>> Great!

Best wishes
Thomas

From: Greg Mirsky <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>>
Sent: Monday, August 14, 2023 10:33 PM
To: Graf Thomas, INI-NET-VNC-HCS <Thomas.Graf@swisscom.com<mailto:Thomas.Graf@swisscom.com>>
Cc: opsawg@ietf.org<mailto:opsawg@ietf.org>; ippm@ietf.org<mailto:ippm@ietf.org>
Subject: Re: [OPSAWG] draft-ietf-ippm-pam-04, draft-clemm-opsawg-pam-ipfix-00

Hi Thomas,
thank you for supporting this work and for your helpful comments. Please find my notes inlined below tagged by GIM>>.

Regards,
Greg

On Wed, Jul 26, 2023 at 2:24 PM <Thomas.Graf@swisscom.com<mailto:Thomas.Graf@swisscom.com>> wrote:
Dear Alex and Greg,

I reviewed draft-ietf-ippm-pam-04 and draft-clemm-opsawg-pam-ipfix-00 and have some comments and questions.

Section 3.1 of draft-ietf-ippm-pam-04 (https://datatracker.ietf.org/doc/html/draft-ietf-ippm-pam-04#section-3.1) mentions the term "service flow".

I haven't been able to find in any IETF document describing/defining the term. I suggest to describe it in the terminology section 2.1 and specify it as an IPFIX and YANG element.
GIM>> I checked and found that "service flow" is used only once in the document:

   When analyzing the availability metrics of a service flow between two
   nodes, a time interval as the unit of PAM needs to be selected.

It could be easier to take out "flow" altogether. WDYT?

Section 3.3 of draft-ietf-ippm-pam-04 specifies an "Unavailability threshold". I suggest to specify in Section 3.1 of draft-clemm-opsawg-pam-ipfix-00 (https://datatracker.ietf.org/doc/html/draft-clemm-opsawg-pam-ipfix-00#section-3.1) this as IPFIX element as well.

The "service flow" describes that the SLO metrics are measured between two nodes. However in draft-clemm-opsawg-pam-ipfix the SLO metrics are measured and export on one node. I would appreciate if you could describe how this information is being measured. Presumably by leveraging of probing.
GIM>> The PAM document will not specify how to measure but where and what to be measured. We will work on clarifying that all PAM metrics are measured between two Measurement Points in the PAM IPFIX draft.

In general I feel that draft-ietf-ippm-pam-04 would benefit of having a reference to the Performance Metrics Registry defined in RFC 8911/8912.
 GIM>> I agree. Check the attached diff.

I would be interested to understand wherever the authors intend to create a draft document describing a service YANG module.
GIM>> That's a great suggestion, thank you. Let us discuss it.

Best wishes
Thomas
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org<mailto:OPSAWG@ietf.org>
https://www.ietf.org/mailman/listinfo/opsawg