[netmod] WG LC for draft-ietf-netmod-intf-ext-yang
"Rob Wilton (rwilton)" <rwilton@cisco.com> Tue, 05 November 2019 15:03 UTC
Return-Path: <rwilton@cisco.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 174621208E6 for <netmod@ietfa.amsl.com>; Tue, 5 Nov 2019 07:03:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.5
X-Spam-Level:
X-Spam-Status: No, score=-9.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_SUMOF=5, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=WlfVVn/N; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=ERBOEVyp
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 2f_g0_d1RcHy for <netmod@ietfa.amsl.com>; Tue, 5 Nov 2019 07:03:39 -0800 (PST)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C37F512001A for <netmod@ietf.org>; Tue, 5 Nov 2019 07:03:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8564; q=dns/txt; s=iport; t=1572966218; x=1574175818; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=Wtan71GOybwrqcaYPckA7s3ov7h5DaFPzySdRe5hi+A=; b=WlfVVn/NvpSW+HLeNRvdEFfkVRwMJ57bXaZEDNITmM/NzD8sxIs+FXI5 Nmu4dGXk0CbEZrD6HIJ817903v2CpJbHFNOf66CMe16dd7UMu+MapgIJC bKvvmdpcxHeUf9rSe1ReeEsM8bKBoCZV0qStqxEUBCYjsIlBtXKyh4Qpk o=;
IronPort-PHdr: 9a23:Mxy57xYjcpZX+rZQRPIC/Eb/LSx94ef9IxIV55w7irlHbqWk+dH4MVfC4el20gebRp3VvvRDjeee87vtX2AN+96giDgDa9QNMn1NksAKh0olCc+BB1f8KavwcC0+AMNEfFRk5Hq8d0NSHZW2ag==
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0D1CQDVjcFd/5RdJa1mHAEBAQEBBwEBEQEEBAEBgX6BS1AFbFggBAsqCodlA4p7ToIQl36CUgNUCQEBAQwBARgNCAIBAYN7RQKEDiQ4EwIDCwEBBAEBAQIBBQRthTcMhVEBAQEBBAEQKAYBASUHDAsGARkBAwEBHzcLFwYJAQQBEggagwGCRgMuAQIMpS8CgTiIYIIngn4BAQWBOAIOQYJ5GIIXCYE2jBMYgUA/gRFGhWwBAQIBARaBSYNAgiyVYJgaCoIkhxWOQoI8coZpj1KOQ4gukS4CBAIEBQIOAQEFgWkiKoEucBUaIYJsCUcRFIMGCRqDUIUUhT90gSiPTwGBDQEB
X-IronPort-AV: E=Sophos;i="5.68,271,1569283200"; d="scan'208";a="435446013"
Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 05 Nov 2019 15:03:36 +0000
Received: from XCH-ALN-015.cisco.com (xch-aln-015.cisco.com [173.36.7.25]) by rcdn-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id xA5F3aC2020301 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 5 Nov 2019 15:03:36 GMT
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-ALN-015.cisco.com (173.36.7.25) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 5 Nov 2019 09:03:36 -0600
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 5 Nov 2019 09:03:34 -0600
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 5 Nov 2019 09:03:33 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KnV8Q3G8H9wD4SxArtQH7zAk1VRhiNItxhu6PXG9pXHc47PF12cJ6T2RJBNklKXoMiynJ74FMYbfqf9d36lKyx2y8DkFRh+HPVmnVaMecAtDtMU/VJd1lbs+GkEVxcQcXNKbh9zfvdwh8+HXWma6/osPATTZX92ke5nRjz5rCRACFScEvh81htDb2jp+nIxIy7RF6im9kKJ3WWRANTLzhWR5ZQeDZuUQ/BP7wA6aqRaLB+eCEScYbOVmPA8K4LS81uspOjkMUjcXUBqIorW21tsY/nZk+lughFtpTZ6jUA7bdJsiefKkAcmRfjYC1M+Dr2AAoQ/JCZ6FXzgiOlj8Lw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VaiJLvjTZPpp1R5Bb13n99PN0iH4hzuBy8HOUtUsrJU=; b=CnuvbR0H1ho6vqbALIdw2NRl0irPOzDBghLRz883+JYCQsPa06ao6hdCwBn1IbdgCqiGlQFm1LPI6TwzN26w9fRzv7IUTC4DOx3hPeze3UcVT38p4SPoraQsuSzOnbUDoouMczkxzcSsK8HZo0M8O67kN+Qr6+hDkumzViHBCcEvSvuqX3iHFbHfX8dHmY0gk9AUgpV529ibByrkx0Jr7ZcvD3SzgNALh9D/AxDsw3bhMoHlppqVXqakPXfbtcFzQ9Jo1J1pCR1l3iI44ITQGg5A00cZJ0uUx2NCGmOY/nA8tCRDQ/qmtP1mwrZxfkudxM1dGiTRNGwM3ZD1btZu3Q==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VaiJLvjTZPpp1R5Bb13n99PN0iH4hzuBy8HOUtUsrJU=; b=ERBOEVypUDAHJIoJ1ImbGNcK3NlpAn9qzDkIDWluyWEi6jf8yxlcZPJeikaOFXIGrCvSaBKdGt4OV+kh3OkER4C4GQLXuKVjpxmabUSkHnhmr/XbEAxvN9YR7a6GyENpTrwuYjMC0nJiJAmSBKpAJpEjr6mQceg2FiORYxd3K88=
Received: from MN2PR11MB4366.namprd11.prod.outlook.com (52.135.38.209) by MN2PR11MB3821.namprd11.prod.outlook.com (20.178.253.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2408.24; Tue, 5 Nov 2019 15:03:31 +0000
Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::49b6:bc5c:bd3e:203c]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::49b6:bc5c:bd3e:203c%5]) with mapi id 15.20.2408.024; Tue, 5 Nov 2019 15:03:31 +0000
From: "Rob Wilton (rwilton)" <rwilton@cisco.com>
To: "netmod@ietf.org" <netmod@ietf.org>, Martin Bjorklund <mbj@tail-f.com>, Qin Wu <bill.wu@huawei.com>, Vladimir Vassilev <vladimir@transpacket.com>
Thread-Topic: WG LC for draft-ietf-netmod-intf-ext-yang
Thread-Index: AdWTzcFFz/BahgfCQfq/ydz7shK2ZA==
Date: Tue, 05 Nov 2019 15:03:31 +0000
Message-ID: <MN2PR11MB4366F8D91F32D95754ED57A8B57E0@MN2PR11MB4366.namprd11.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=rwilton@cisco.com;
x-originating-ip: [173.38.220.45]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: da9ee4cc-e65d-40ab-01e8-08d7620152c1
x-ms-traffictypediagnostic: MN2PR11MB3821:
x-ms-exchange-purlcount: 8
x-microsoft-antispam-prvs: <MN2PR11MB38212DC0E3990CF96A2906B0B57E0@MN2PR11MB3821.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0212BDE3BE
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(4636009)(39860400002)(396003)(366004)(136003)(376002)(346002)(51444003)(189003)(13464003)(199004)(316002)(256004)(476003)(102836004)(478600001)(66476007)(53546011)(6436002)(52536014)(7696005)(64756008)(66946007)(66446008)(14454004)(25786009)(186003)(55016002)(6306002)(9686003)(6506007)(33656002)(26005)(86362001)(66066001)(14444005)(3846002)(6116002)(110136005)(81166006)(66556008)(76116006)(966005)(8936002)(66574012)(5660300002)(2906002)(305945005)(486006)(99286004)(7736002)(8676002)(71190400001)(74316002)(71200400001)(2501003)(81156014)(21314003)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3821; H:MN2PR11MB4366.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: gvpK3Ivz2qZH3fJcfRJ4FqlhIXSObIaOngj6KNGLxb1zx/Bll1rvzIKhpI4xSJZhJtDbeR9bMjVZ7SJ62GeFOURNKTRr9+KhR1N8hQOFg0Rpalaqi6bvMWXOXzql+jdvZe+JKlUsp8o06bC5wZhf+JUYaIzI5P0k35pSdzBC4Larz/SoHmyHqgdS7p8m6LcuyrkJNkYPjeDm0PAD2+5eXcYNMx2cWhKEa56d3nQM1y/l690V+24WI4wbWQcHCxNxkPaMkcGG7PVakjCh2HUeRaYeNa3tJGJ1yHzFE9MrHWJRA05yKvJWMtun/dMxPDlLqhokzO5W+1Z+yYXGWwEhhxo3ea14zKLe5JjCp5UNA1kzRNQdb2UfwhuQhjs5byrtLYeG9dikxH6U67uoQVMQuhWunq0H+hf9A/hCHnX98rbfPPxg5vQ5LwV8aSG5IrBOxvlwJ+jRTRWJH9he5ievVT6qMzdnwuDZDcjKIJicuhI=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: da9ee4cc-e65d-40ab-01e8-08d7620152c1
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Nov 2019 15:03:31.7795 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: p6sdi6WMKNh3iG+7ytYJ5+VptfwsCDqtxfKKtTCvtEjN0x0IPrrx9NYN8CgKHE6adgCnrbAc36mameeykw4sVQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3821
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.25, xch-aln-015.cisco.com
X-Outbound-Node: rcdn-core-12.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/A3KK4nxTH5CPL4ZJfRp3wHe25wY>
Subject: [netmod] WG LC for draft-ietf-netmod-intf-ext-yang
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Nov 2019 15:03:43 -0000
Hi, draft-ietf-netmod-intf-ext-yang-08.txt should fix most of the issues raised during the WG LC. Please can you check the diff (https://datatracker.ietf.org/doc/draft-ietf-netmod-intf-ext-yang/history/) to ensure that your comments have been correctly addressed, closed issues are tracked at https://github.com/netmod-wg/interface-extensions-yang/issues?q=is%3Aissue+is%3Aclosed . There are still some open issues, at https://github.com/netmod-wg/interface-extensions-yang/issues that need to be resolved, with proposed resolutions below: 1. Do we rename "Carrier-delay". Possibly, this could be renamed to something like "link-flap-suppression" or "state-flap-suppression"? 2. Do we add in-pkts and out-pkts counters? Effectively, these counters would be equivalent to the sum of the in-unicast-pkts + in-broadcast-pkts + in-multicast-pkts. In hindsight, I wish the counters had been defined as: in-pkts, in-broadcast-pkts, in-multicast-pkts. I.e. where the broadcast and multicast counters are a subset of in-pkts. This approach works for interfaces that don't distinguish between the types. However, I'm not sure whether adding these counters into interface extensions is the right place. If we were to add these counters, I think that it would be better to add them to a new revision of ietf-interfaces.yang. 3. Do we add a new "in-discards-overflow" counter? I propose that we add this counter, with the following definition: leaf in-discards-overflow { type yang:counter32; description "The number of inbound packets that could have been deliverable to a high-layer protocol but have been discarded due to lack of resources to process the packet. This counter does not change the meaning of the 'in-discards' counter, and hence discarded packets Counted against this counter MUST also be counted in the 'in-discards' counter. This counter does not include packets that are discarded due to exceeding a QoS policy, only those dropped due to resource constraints. Discontinuities in the values of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of the 'discontinuity-time' leaf defined in the ietf-interfaces YANG module (RFC 8343)."; reference "RFC 2863: The Interfaces Group MIB - ifInDiscards"; } If we add this counter for ingress, then I suggest that we also define a similar counter for egress as well. 4. As discussed at IETF 105, I propose adding the following discard counter, unless there are strong objections: /* * Add discard counter for unknown sub-interface encapsulation */ augment "/if:interfaces/if:interface/if:statistics" { when "derived-from-or-self(../if:type, 'ianaift:ethernetCsmacd') or derived-from-or-self(../if:type, 'ianaift:ieee8023adLag') or derived-from-or-self(../if:type, 'ianaift:ifPwType')" { description "Applies to interfaces that can demux to sub-interfaces"; } if-feature "sub-interfaces"; description "Augment the interface model statistics with a sub-interface demux discard counter."; leaf in-discard-unknown-encaps { type yang:counter64; units frames; description "A count of the number of frames that were well formed, but otherwise discarded because their encapsulation does not classify to the interface or any child sub-interface. E.g., a packet might be discarded because the it has an unknown VLAN Id, or does not have a VLAN Id when one is expected. For consistency, frames counted against this counter are also counted against the IETF interfaces statistics. In particular, they are included in in-octets and in-discards, but are not included in in-unicast-pkts, in-multicast-pkts or in-broadcast-pkts, because they are not delivered to a higher layer. Discontinuities in the values of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of the 'discontinuity-time' leaf defined in the ietf-interfaces YANG module (RFC 8343)."; } } 5. l2-mtu leaf I've changed the name and definition from "l2-mtu" to "max-frame-size". I've changed the definition to be more encaps agnostic, so it included FCS bytes, and doesn't have any special IEEE 802.3 VLAN definition, and increased its size to uint32 to accommodate the Linux loopback MTU of 65536 bytes. The propose new text is: 2.5. Maximum frame size A maximum frame size configuration leaf (max-frame-size) is provided to specify the maximum size of a layer 2 frame that may be transmitted or received on an interface. The value includes the overhead of any layer 2 header, the maximum length of the payload, and any frame check sequence (FCS) bytes. If configured, the max- frame-size leaf on an interface also restricts the max-frame-size of any child sub-interfaces, and the available MTU for protocols. And the YANG: /* * Allows the maximum frame size to be configured or reported. */ leaf max-frame-size { if-feature "max-frame-size"; type uint32 { range "64 .. max"; } description "The maximum size of layer 2 frames that may be transmitted or received on the interface (including any frame header, maximum frame payload size, and frame checksum sequence). If configured, the max-frame-size also limits the maximum frame size of any child sub-interfaces. The MTU available to higher layer protocols is restricted to the maximum frame payload size, and MAY be further restricted by explicit layer 3 or protocol specific MTU configuration."; reference "RFC XXX, Section 2.5 Maximum Frame Size"; } Thanks for all of your review comments, Rob -----Original Message----- From: netmod <netmod-bounces@ietf.org> On Behalf Of internet-drafts@ietf.org Sent: 04 November 2019 21:40 To: i-d-announce@ietf.org Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-intf-ext-yang-08.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Modeling WG of the IETF. Title : Common Interface Extension YANG Data Models Authors : Robert Wilton David Ball Tapraj Singh Selvakumar Sivaraj Filename : draft-ietf-netmod-intf-ext-yang-08.txt Pages : 32 Date : 2019-11-04 Abstract: This document defines two YANG modules that augment the Interfaces data model defined in the "YANG Data Model for Interface Management" with additional configuration and operational data nodes to support common lower layer interface properties, such as interface MTU. The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA) defined in RFC 8342. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-intf-ext-yang/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netmod-intf-ext-yang-08 https://datatracker.ietf.org/doc/html/draft-ietf-netmod-intf-ext-yang-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-intf-ext-yang-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
- [netmod] WG LC for draft-ietf-netmod-intf-ext-yang Rob Wilton (rwilton)