Re: [OPSAWG] FW: [OPS-DIR] Opsdir last call partial review of draft-boydseda-ipfix-psamp-bulk-data-yang-model-02

Gerhard Muenz <muenz@net.in.tum.de> Sat, 28 December 2019 10:47 UTC

Return-Path: <muenz@net.in.tum.de>
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 B96C21200E0 for <opsawg@ietfa.amsl.com>; Sat, 28 Dec 2019 02:47:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.195
X-Spam-Level:
X-Spam-Status: No, score=-4.195 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 2AdLbOgFDmek for <opsawg@ietfa.amsl.com>; Sat, 28 Dec 2019 02:47:50 -0800 (PST)
Received: from mail-out2.informatik.tu-muenchen.de (mail-out2.in.tum.de [131.159.0.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D399912009C for <opsawg@ietf.org>; Sat, 28 Dec 2019 02:47:49 -0800 (PST)
Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.net.in.tum.de (Postfix) with ESMTPSA id 7B076289D826; Sat, 28 Dec 2019 11:47:41 +0100 (CET)
To: Mehmet Ersue <mersue@gmail.com>, opsawg@ietf.org
Cc: bclaise@cisco.com, paitken@cisco.com
References: <157522515633.22084.6939046103700071190@ietfa.amsl.com> <018d01d5a87b$5f374880$1da5d980$@gmail.com>
From: Gerhard Muenz <muenz@net.in.tum.de>
Message-ID: <6b724263-0d76-5c55-a355-e4de84efd7ee@net.in.tum.de>
Date: Sat, 28 Dec 2019 11:47:36 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <018d01d5a87b$5f374880$1da5d980$@gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/ZaSNbPM-r_jBVXTmH6sWBoB82MI>
Subject: Re: [OPSAWG] FW: [OPS-DIR] Opsdir last call partial review of draft-boydseda-ipfix-psamp-bulk-data-yang-model-02
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.29
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, 28 Dec 2019 10:47:53 -0000

Dear Mehmet,

Thank you for forwarding this e-mail. I have not subscribed to the 
OPSAWG mailing list. So maybe, you need to forward my reply.

Together with Benoir and Paul, I was the main author of RFC 6728. For 
many years, however, I have neither been involved in IETF 
standardization nor in IPFIX/PSAMP activities. Therefore, I do not feel 
in a position to provide a complete review of the draft as an IPFIX 
expert. Nevertheless, I have a brief look at it and can share a few 
comments.

The main challenge of RFC 6728 was to create a configuration data model 
that covers all the metering and protocol features specified in the 
other PSAMP/IPFIX RFCs, and to also fit to the IPFIX MIB. We had long 
discussions to clarify and differentiate the functionality of each 
abstract functional block of an IPFIX Device (e.g. Metering Process, 
Exporting Process). So, it is good that the new draft does not reinvent 
the wheel but adopts the original configuration data model with only a 
few changes.

Most of the proposed changes of the original configuration data model 
shall facilitate extensions of the model for other use cases of the 
IPFIX protocol. The second contribution is the addition of bulk data 
export parameters to the model. If I understand correctly, bulk data 
transfer with IPFIX has not been standardized by IETF.

It would be possible to split the draft into two parts: (1) a revision 
of RFC 6728 covering the original scope of configuration (IPFIX/PSAMP 
Devices) including the changes to facilitate extensions for other use 
cases, and (2) a new draft with the specific extension for bulk data 
export (if IETF wants to standardize this).
Maybe, such a split would make it clear that bulk data export is not an 
IPFIX/PSAMP feature standardized by IETF.

Some further comments:
- RFC 7011 requires PR-SCTP for all compliant IPFIX devices. Therefore, 
the part is mandatory in configuration data model of RFC 6728. If we 
make SCTP optional, this would possibly reflect reality much better - 
but there would be a mismatch to RFC 7011.
- The Exporting Process does not influence the generation of Data 
Records, it may only throttle the speed of sending them in IPFIX packets 
(or drop in case of congestion). The proposed new parameter 
"export-interval" seems to refer to the generation of Data Records and 
therefore should not be configured as part of the Exporting Process, but 
as part of the process that generates the bulk data.
- I am not aware of any implementation of RFC 6728. It would be good to 
know whether there are any (possibly from Cisco, the main driver of 
IPFIX), and to get feedback from there.

Best regards,
Gerhard



On 01.12.2019 20:13, Mehmet Ersue wrote:
> I think this draft should be reviewed and commented by OPSAWG WG before
> publishing as "AD sponsored standard track RFC" obsoleting RFC 6728.
> (RFC 6728 authors CCed).
>
> BR,
> Mehmet
>
> -----Original Message-----
> From: OPS-DIR <ops-dir-bounces@ietf.org> On Behalf Of Mehmet Ersue via
> Datatracker
> Sent: Sunday, December 1, 2019 7:33 PM
> To: ops-dir@ietf.org
> Cc: last-call@ietf.org; opsawg@ietf.org;
> draft-boydseda-ipfix-psamp-bulk-data-yang-model.all@ietf.org
> Subject: [OPS-DIR] Opsdir last call partial review of
> draft-boydseda-ipfix-psamp-bulk-data-yang-model-02
>
>
> Review is partially done. Another assignment may be needed to complete it.
>
> Reviewer: Mehmet Ersue
> Review result: Not Ready
>
> I reviewed the document "YANG Data Models for the IP Flow Information Export
> (IPFIX) Protocol, Packet Sampling (PSAMP) Protocol, and Bulk Data Export
> (draft-boydseda-ipfix-psamp-bulk-data-yang-model-02) as part of the
> Operational directorate's ongoing effort to review all IETF documents being
> processed by the IESG. These comments were written primarily for the benefit
> of the operational area directors.  Document editors and WG chairs should
> treat these comments just like any other last call comments.
>
> Obsoletes: 6728 (if approved)
> Intended status: Standards Track
> Current IESG state: I-D Exists
>
> Summary:
> The document aims to replace the YANG model for packet sampling (PSAMP) and
> bulk data collection and export via the IPFIX protocol originally defined in
> standard track RFC 6728 (Configuration Data Model for the IP Flow
> Information Export (IPFIX) and Packet Sampling (PSAMP) Protocols). The YANG
> data model in the document also aims to be conform with the Network
> Management Datastore Architecture (NMDA) defined in RFC 8342. FYI: The YANG
> model is currently in review by Martin Bjorklund from YANG modeling
> perspective.
>
> The document further aims to decouple the PSAMP collecting process and the
> IPFIX exporting process as well as defining an exporting process which does
> not require SCTP support. The document tries to enable the export frequency
> to be controlled by the exporting process, support of large IPFIX mediation
> functions, and flexible referencing of interfaces. The new functionality
> described above and the necessary restructuring of the model in RFC 6728
> might become useful if done properly as an extension to RFC 6728.
>
> However based on missing IPFIX and PSAMP expertise, unfortunately I'm not
> able to give a solid statement on to whether the document is capable to
> replace the standard track RFC 6728. Moreover the new functionality and
> changes to the original model require thorough and in-depth review by IPFIX
> and PSAMP experts.
>
> Also as the document is largely based on RFC 6728, introducing the authors
> of RFC 6728 as co-authors and involving them for review would very useful.
> As a minimum they need to be involved as reviewers and mentioned in the
> Acknowledgments section.
>
> The document is proposed to publish as an AD sponsored draft, which is not
> an issue per se. It is also not forbidden but very unusual that an AD
> sponsored draft is proposed to replace a standard track RFC. I would be
> highly interested to know why this path has been chosen.
>
> However I believe it is a substantial issue that this draft has not been
> discussed and supported in any IETF maillist until today. There was only a
> short presentation in OPSAWG WG session one year ago without any record of
> support. The authors are not known at IETF and have not written any other
> than the current draft. The authors have most likely BBF background.
>
> As IPFIX and PSAMP WGs have already concluded, I would like to recommend
> _urgently_ to introduce the draft to OPSAWG maillist and ask for support. It
> is IMO essentially important that the document gets discussed and reviewed
> by IPFIX and PSAMP people available in OPSAWG and by the authors of RFC 6728
> before publication. It also needs to be clarified whether the draft has been
> already or is going to be implemented.
>
> In case there is no support in OPSAWG WG for this draft to replace the
> standard track RFC 6728 I believe it would be appropriate to publish it as
> an "AD sponsored Experimental RFC". It can still become a standard track RFC
> after getting implementation reports and appropriate community feedback on
> its usage.
>
> Sorry for not being the right expert reviewer for the draft content.
> Therefore I've set the review result to "Partially Completed - extra
> reviewer is to be assigned" and hope the draft gets a proper review in
> OPSAWG WG and by the authors of RFC 6728.
>
> Mehmet
>
>
> _______________________________________________
> OPS-DIR mailing list
> OPS-DIR@ietf.org
> https://www.ietf.org/mailman/listinfo/ops-dir
>