Re: [IPFIX] [QUAR] Re: RFC 6728 IETF IPFIX Yang Discussion

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Mon, 15 January 2018 18:51 UTC

Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC25D12EB61 for <ipfix@ietfa.amsl.com>; Mon, 15 Jan 2018 10:51:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01, 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 8MmSa1nPH6zJ for <ipfix@ietfa.amsl.com>; Mon, 15 Jan 2018 10:51:05 -0800 (PST)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83BBD12EB5F for <ipfix@ietf.org>; Mon, 15 Jan 2018 10:50:48 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id ACF5260; Mon, 15 Jan 2018 19:50:46 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id NlesdZwMM0kx; Mon, 15 Jan 2018 19:50:44 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Mon, 15 Jan 2018 19:50:46 +0100 (CET)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8E1A72013F; Mon, 15 Jan 2018 19:50:46 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id l_14knuReEJT; Mon, 15 Jan 2018 19:50:45 +0100 (CET)
Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3316B2013E; Mon, 15 Jan 2018 19:50:44 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 001D94210A43; Mon, 15 Jan 2018 19:50:43 +0100 (CET)
Date: Mon, 15 Jan 2018 19:50:43 +0100
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Andrew Feren <andrew.feren@plixer.com>
Cc: Gerhard Muenz <muenz@net.in.tum.de>, Benoit Claise <bclaise@cisco.com>, "Aitken, Paul" <paul.aitken@intl.att.com>, 'Marta Seda' <Marta.Seda@calix.com>, "'ipfix@ietf.org'" <ipfix@ietf.org>
Message-ID: <20180115185043.vj3ikpfqhsuycdm4@elstar.local>
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Mail-Followup-To: Andrew Feren <andrew.feren@plixer.com>, Gerhard Muenz <muenz@net.in.tum.de>, Benoit Claise <bclaise@cisco.com>, "Aitken, Paul" <paul.aitken@intl.att.com>, 'Marta Seda' <Marta.Seda@calix.com>, "'ipfix@ietf.org'" <ipfix@ietf.org>
References: <085c30b9-5797-863e-a63d-a027396f224f@gmail.com> <a3fc69e8-5773-5785-09ca-409c6a07db57@gmail.com> <A3625616CA873B4DAA779ABEFA624F1C8BE3CA@gbcdcmbx03.intl.att.com> <c20055e4-d9a1-0652-8221-ce54387dedea@cisco.com> <167798e2-f7a7-6946-8f3c-6bf996514bec@net.in.tum.de> <8E7542283B89BB4DB672EB49CEE5AAB7CDFB5429@PLXRDC01.plxr.local>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
X-Clacks-Overhead: GNU Terry Pratchett
Content-Transfer-Encoding: 8bit
In-Reply-To: <8E7542283B89BB4DB672EB49CEE5AAB7CDFB5429@PLXRDC01.plxr.local>
User-Agent: NeoMutt/20171215
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipfix/AZl-xAvxJ8Za52yi23osUuyZgrE>
Subject: Re: [IPFIX] [QUAR] Re: RFC 6728 IETF IPFIX Yang Discussion
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IPFIX WG discussion list <ipfix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipfix>, <mailto:ipfix-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipfix/>
List-Post: <mailto:ipfix@ietf.org>
List-Help: <mailto:ipfix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipfix>, <mailto:ipfix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Jan 2018 18:51:09 -0000

I fail to see why this would be the case. (But I agree that renaming
identifiers for the sake of renaming them is having little value.)

/js

On Mon, Jan 15, 2018 at 06:09:20PM +0000, Andrew Feren wrote:
> In particular renaming identifiers would break any implementations of RFC 7373 "Textual Representation of IP Flow Information Export (IPFIX) Abstract Data Types".
> 
> -Andrew
> 
> ________________________________
> From: IPFIX [ipfix-bounces@ietf.org] on behalf of Gerhard Muenz [muenz@net.in.tum.de]
> Sent: Saturday, January 13, 2018 4:43 AM
> To: Benoit Claise; Aitken, Paul; 'Marta Seda'
> Cc: 'ipfix@ietf.org'
> Subject: [QUAR] Re: [IPFIX] RFC 6728 IETF IPFIX Yang Discussion
> 
> 
> Marta, all,
> 
> A few additional thoughts regarding your questions:
> 
> 1) I would not expect that not following current naming convention hinders implementation of RFC 6728. On the other hand, if we change just the names of the identifiers, we lose interoperability with older implementations that may exist.
> 
> 2) I think that it is reasonable that destinationIPAddress is mandatory because network management systems should be able to query the IP address to which an Exporting Process sends data. As Paul stated, RFC 6728 does not say how the destination IP address is set.
> 
> 3) SCTP is still a mandatory transport for a compliant implementation of an IPFIX device, not a feature. See: https://tools.ietf.org/html/rfc7011#section-10.1<https://linkprotect.cudasvc.com/url?a=https://tools.ietf.org/html/rfc7011%23section-10.1&c=E,1,r3o6fj1SXot8TQIPgevXNx5yfL8QvlF982Ch9DX27MByjz7bAdEaF9tjDoDzj1XgWtTXYfN1Z9mXiFy81bK1Aq33fYFzGl5W-2Dh_-xePoq9GNzzaPGdYj0o&typo=1>
> 
> Best regards,
> Gerhard
> 
> 
> 
> On 10.01.2018 08:33, Benoit Claise wrote:
> Hi,
> Marta, Benoit,
> 
> 1. Are there efforts to update other RFCs to meet the latest YANG best practices?
> Yes. Ex: https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc7223bis/<https://linkprotect.cudasvc.com/url?a=https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc7223bis/&c=E,1,990HtCyvSKBHwQOS7jpHkeSpsvC2M7iKDlI_bfqIgW2gpaEOYhngASoi8LRRhuM67bRdHS2Hyi7cVHyXDuiheARWFxSpap_iznZ68ZknJgFbizFJolgU&typo=1>
> The goal is to specify NMDA-compliant (draft-ietf-netmod-revised-datastores-09<https://linkprotect.cudasvc.com/url?a=https://datatracker.ietf.org/doc/draft-ietf-netmod-revised-datastores/&c=E,1,ByKxVFeHf8k0Yb1kzzkQnQg33VfrR12Hy6dJzQTbkgStXZt3NzfCi7l981VvXCCM3L3iwQ3FF8lz77mT4C5yuZEfVe-78uXEs5xDZql2y--4iDlmOUQ,&typo=1>) YANG modules
> 
> 2. Since the IPFIX WG closed, there has been little ongoing IPFIX work in the IETF. Is there a specific need to update RFC 6728 rather than just recognising it as a product of it's time?
> This type of feedback should come from implementation experience.
> 
> Regards, Benoit
> Note that it's > 5 years old.
> 
> Also see @PJ inline:
> 
> 
> On 09/01/2018 16:01, Benoit Claise wrote:
> Hi Marta,
> Hello,
> I am reaching out to the IETF IPFIX mailing list  on some issues I have run into with respect to RFC 6728 “Configuration Data Model for the IP Flow Information Export (IPFIX)  and Packet Sampling (PSAMP) Protocols”
> 
> 
>   1.  RFC 6728 doesn’t meet the latest Yang Best Practices (https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-15#section-4.3.1<https://linkprotect.cudasvc.com/url?a=https://urldefense.proofpoint.com/v2/url%3fu%3dhttps-3A__tools.ietf.org_html_draft-2Dietf-2Dnetmod-2Drfc6087bis-2D15-23section-2D4.3.1%26d%3dDwMD-g%26c%3dLFYZ-o9_HUMeMTSQicvjIg%26r%3df8F8yzrqBTw6EPtR1rbibO_VFIc-cdnjIJ9he_qu7xs%26m%3d0c5ATjuT0-4IlDzLYM9h_RbPjCBQUv_6aExRL_fl-5M%26s%3dHhi7V6njCFNBbSsjC6sPgNfVu5DA8iQzdzsnA_iQBzQ%26e%3d&c=E,1,5Zsm8llhIef_jTZU2aAY2fj_KvmJs-zBz2HIfVEkrhY7UwWsg3UnykcCPzCUM7b_L6CTmk_VY1-To7t8aTM7RBz2ayGhe3OrxbBk7_Oy6I7gQSkKDC8Eig,,&typo=1>).   Leaf identifiers are camel case (e.g., destinationAddress instead of destination-address).  Are there any ongoing efforts to update RFC 6728 to meet the latest best practices?
> Not as far as I know.
> 
> Regards, Benoit
> 
> 
>   1.
> 
>    Identifiers SHOULD follow a consistent naming pattern throughout the
>    module.  Only lower-case letters, numbers, and dashes SHOULD be used
>    in identifier names.  Upper-case characters and the underscore
>    character MAY be used if the identifier represents a well-known value
>    that uses these characters.
> 
>    Identifiers SHOULD include complete words and/or well-known acronyms
>    or abbreviations.  Child nodes within a container or list SHOULD NOT
>    replicate the parent identifier.  YANG identifiers are hierarchical
>    and are only meant to be unique within the the set of sibling nodes
>    defined in the same module namespace.
> 
>    It is permissible to use common identifiers such as "name" or "id" in
>    data definition statements, especially if these data nodes share a
>    common data type.
> 
>    Identifiers SHOULD NOT carry any special semantics that identify data
>    modelling properties.  Only YANG statements and YANG extension
>    statements are designed to convey machine readable data modelling
>    properties.  For example, naming an object "config" or "state" does
>    not change whether it is configuration data or state data.  Only
>    defined YANG statements or YANG extension statements can be used to
>    assign semantics in a machine readable format in YANG.
> 
> 
>   1.  I generated the RFC 6728 yang tree (see attached).  The tcp and udp exporting processes support a destinationIPAddress (line 400, 455) which is mandatory.  The type is inet:ip-address.
> 
>      *   A collector may be doing load balancing.  Rather than managing ip-addresses, the collector may be using DNS (an exporter could resolve from the domain name where the collector is located).
> 
> @PJ: Load balancing and DNS are independent. Load balancing IPFIX is probably a bad idea since templates need to be available on all collectors, and out of step sequence numbers in the data records would cause spurious reports of lost data. If DNS is used to obtain the collector's address, arguably it should be a one-time lookup rather than incurring a DNS lookup per export packet.
> 
> 
> 
>   1.
> 
>      *
>      *   The collector address may be learnt via other methods (e.g., through DHCP options)
>      *   A choice statement to select what method to use seems more appropriate than what is presently in RFC 6728.  For example (use some shorthand)
> 
> choice destination-method{
>                 case destination-address{
>                                 leaf destination-address// rw with type inet:host
>                 }
>                 case dhcp-acquired-address{
>                                 container dcp-acquired-address{
>                                                 leaf destination-ip-address inet-address //ro
>                 }
> }
> 
>                                 However I can’t augment to ietf-ipfix because destinationIPAddress is mandatory.  Can the group suggest methods to (a) change the destinationIPAddress type and (b) allow a choice?
> 
> @PJ: The selection could also be done out of band so the exporter need not know how the address is determined. eg a configuration system could determine the address by any of these methods or otherwise, and impose that address using the current model.
> 
> 
> 
>   1.  RFC 6728 mandates SCTP transport.  I understand the logic behind this (IETF prefers use of SCTP).  There are situations where sctp is unnecessary and not supported (e.g., point to point connection).  During netconf negotiations you can announce your feature set (currently sctptransport is not a feature).  Is there ongoing work in updating RFC 6728 to include sctptransport as a feature (so that the device can announce whether or not it supports sctptransport)?
> 
> @PJ Same answer as point (2) above, ie is this necessary and useful?
> 
> P.
> 
> 
> 
> 
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org<mailto:IPFIX@ietf.org>
> https://www.ietf.org/mailman/listinfo/ipfix<https://linkprotect.cudasvc.com/url?a=https://www.ietf.org/mailman/listinfo/ipfix&c=E,1,QcSaORG4ENECojkXawtykKdqqGaKdIQCAXU_k7DUoimbxp4p9KhoEppQlQ1LswK1E5yY5kvIL8XYyqMbCphIEyv8aBgtyyQbbN31fnbrx9I,&typo=1>
> 
> 

> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www.ietf.org/mailman/listinfo/ipfix


-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>