[IPFIX] RFC 6728 IETF IPFIX Yang Discussion

Marta Seda <Marta.Seda@calix.com> Thu, 04 January 2018 22:30 UTC

Return-Path: <Marta.Seda@calix.com>
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 0E3F3126D85 for <ipfix@ietfa.amsl.com>; Thu, 4 Jan 2018 14:30:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=calix.onmicrosoft.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 SYcKHf1p-nDi for <ipfix@ietfa.amsl.com>; Thu, 4 Jan 2018 14:30:34 -0800 (PST)
Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02lp0207.outbound.protection.outlook.com [IPv6:2a01:111:f400:7e46::207]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA8651242F5 for <ipfix@ietf.org>; Thu, 4 Jan 2018 14:30:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=CALIX.onmicrosoft.com; s=selector1-calix-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=/waJGrun+eQOJi0AOhPYIryPWfJvslas0ntVozLHK4g=; b=BL7Xe4GF5B27bIoeDQ+z5IY6j7SafNX8+vRi715iCwh+xFkCLs6HuN2rCwQp2Rg3N4LbTGEgvRYsfURl3K+OZj82W9OMOPQ3MarNz2TGzMaDxBpYkTLi7eoWa1kiL4zvtT7YEyLBJeyLKHmArjLpyXB4qK3bH6NTO2PF+VVHPCA=
Received: from BY2PR0501MB1734.namprd05.prod.outlook.com (10.163.154.20) by BY2PR0501MB1719.namprd05.prod.outlook.com (10.163.154.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.386.4; Thu, 4 Jan 2018 22:30:04 +0000
Received: from BY2PR0501MB1734.namprd05.prod.outlook.com ([10.163.154.20]) by BY2PR0501MB1734.namprd05.prod.outlook.com ([10.163.154.20]) with mapi id 15.20.0386.006; Thu, 4 Jan 2018 22:30:04 +0000
From: Marta Seda <Marta.Seda@calix.com>
To: "ipfix@ietf.org" <ipfix@ietf.org>
Thread-Topic: RFC 6728 IETF IPFIX Yang Discussion
Thread-Index: AdOFq4/g/UhqDUnGS1y9w5Kq6vABEg==
Date: Thu, 04 Jan 2018 22:30:04 +0000
Message-ID: <BY2PR0501MB173415D2260734074DD777CA9C1F0@BY2PR0501MB1734.namprd05.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Marta.Seda@calix.com;
x-originating-ip: [23.118.53.86]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BY2PR0501MB1719; 7:rNSSbOKL3fKjnAgsn9Fy89xmv64aj2oMtn98JpM7/xVH9Bm7j3+2/t2kTWfjjCRVBbxjj++3ZPhlWNyB7OV7Yvn/6j9T+4W9k+pYgE3R+sfXpt5twYJSwnOGKm3R5V1ctc11c/ameFQpGOfjFhH2LJ81CxC0gCZbt68xGAjqkbAAuEzw+1jou5x6rLdUQnChdanerCtyUdhcSGQ1bgSQUdrMzPmSvNbgmtFwz3o9ARG/5+DUhX5geoUYPvC3nCNZ
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 87a50f01-3d12-4d8e-2fd3-08d553c2b3c3
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(49563074); SRVR:BY2PR0501MB1719;
x-ms-traffictypediagnostic: BY2PR0501MB1719:
x-microsoft-antispam-prvs: <BY2PR0501MB171974A0A51CF8FD48D566C39C1F0@BY2PR0501MB1719.namprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040470)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(3231023)(944501075)(6041268)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123558120)(20161123562045)(20161123560045)(6072148)(201708071742011); SRVR:BY2PR0501MB1719; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:BY2PR0501MB1719;
x-forefront-prvs: 054231DC40
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39850400004)(376002)(366004)(346002)(39380400002)(396003)(199004)(189003)(5660300001)(55016002)(33656002)(2900100001)(68736007)(72206003)(790700001)(9326002)(9686003)(236005)(5640700003)(102836004)(1730700003)(8676002)(3846002)(6116002)(99286004)(77096006)(6306002)(86362001)(6436002)(606006)(316002)(81166006)(6916009)(14454004)(54896002)(81156014)(478600001)(7736002)(5890100001)(6506007)(99936001)(7696005)(2351001)(97736004)(2501003)(3660700001)(8936002)(2906002)(59450400001)(3280700002)(66066001)(106356001)(74316002)(5630700001)(25786009)(105586002)(53936002)(217873001); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR0501MB1719; H:BY2PR0501MB1734.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: calix.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: 44adEKc5u1rtEpt7H0Oihkmt5QT2JOz/Lv8hGZnEP5cqjQ820MvcNjZAZaE1RhDJCzQ5SpABCnG+ZhMgj9U3iQ==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/mixed; boundary="_004_BY2PR0501MB173415D2260734074DD777CA9C1F0BY2PR0501MB1734_"
MIME-Version: 1.0
X-OriginatorOrg: calix.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 87a50f01-3d12-4d8e-2fd3-08d553c2b3c3
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jan 2018 22:30:04.6529 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8ffae2e5-6ff0-4510-bbf3-ca842d7ca55e
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0501MB1719
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipfix/7s6Wedkq5P_QeDhPjRvWVirdYJw>
Subject: [IPFIX] 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: Thu, 04 Jan 2018 22:30:44 -0000

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).   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?

   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).
     *   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?



  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)?

Regards

Marta Seda