Re: [netmod] WG Last Call: draft-ietf-netmod-intf-ext-yang-07

"Rob Wilton (rwilton)" <rwilton@cisco.com> Thu, 22 August 2019 15:09 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 48B7E120921 for <netmod@ietfa.amsl.com>; Thu, 22 Aug 2019 08:09:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=MtoGXbwV; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=rwWbOV8T
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 3moC7PdF8D7n for <netmod@ietfa.amsl.com>; Thu, 22 Aug 2019 08:09:49 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 686A612091D for <netmod@ietf.org>; Thu, 22 Aug 2019 08:09:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11110; q=dns/txt; s=iport; t=1566486589; x=1567696189; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=TXonbMcpax5ZQhX+yBZ6TmXREJHksW2utsi3LX3JZh4=; b=MtoGXbwVsxag2B1KLf823CK5Z9iaEo+OGhzjLjWGEjOOH8uVhf/dyIMw nW3UacgnJk/qGfeiIV5DB9u4HoQh4pxbY4vNAg290+BVVg3Fu8wGzez3t K/37pjpcoQVBjEX0nxeC2pM1r0gCC6AqKlkthxHLWuBJMirQTVOY3JxcW o=;
IronPort-PHdr: =?us-ascii?q?9a23=3ALk1oeRGzjmWDYu916mHZyJ1GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e4z1A3SRYuO7fVChqKWqK3mVWEaqbe5+HEZON0pNV?= =?us-ascii?q?cejNkO2QkpAcqLE0r+eeT1bigmG8JqX15+9Hb9Ok9QS47z?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AoAADyr15d/51dJa1kGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBVgIBAQEBCwGBRFADbVUgBAsqCoQWg0cDimqCXJdmglIDVAk?= =?us-ascii?q?BAQEMAQEYCwoCAQGDekUCF4JIIzcGDgIJAQEEAQEDAQYEbYUtDIVKAQEBAQM?= =?us-ascii?q?BARALBhEMAQEsCwELBAIBCA4DBAEBAQICJgICAiULFQgIAgQOBQgagwGBagM?= =?us-ascii?q?dAQIMn0wCgTiIYXOBMoJ7AQEFgTIBg2YYghYDBoEMKAGLbhiBQD+BV4JMPoJ?= =?us-ascii?q?hAQGBSxgVgnQygiaMc4IlhTKXFgkCgh2GaY1vgjGHMI5pjxWGLpAvAgQCBAU?= =?us-ascii?q?CDgEBBYFmIoFYcBU7gjgBAQExgkIMF4NPhRSFPgFygSmJDyuBBAGBIAEB?=
X-IronPort-AV: E=Sophos;i="5.64,417,1559520000"; d="scan'208";a="619596236"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 22 Aug 2019 15:09:37 +0000
Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id x7MF9bEJ026562 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 22 Aug 2019 15:09:37 GMT
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 22 Aug 2019 10:09:37 -0500
Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 22 Aug 2019 11:09:35 -0400
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 22 Aug 2019 10:09:35 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=D+A+NlXoXiXCMBq8B93+kWd1PdU0wgmAupQGrv75PUxQryCriKEE8BP+PGHCdg+E6zwKQ9qLIQqTrWWvGk46HOGBPMxxWMuC6A3W9RMIyoz7P9fb4kiesj1d8wiSGoj8T4aZe7q+C3RIDa0SQq+kFhtOVMZs9AroVg7u0QqVORmz23AMDAipc4ue23fFW6MqVw3smzlNVe4RruxS8beaPbAcXrDgDc5iVVHqTKy8QvS/EdqViWjj6BtL6vAbFHGcDxnGz9g6Ulg7kSZjclECRcdnsOZELfrtrBChWrQgqpII+7y1Byf8ygicVH2ZyBnEcp37sqoz5eZnhvTXIl4CmQ==
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=TXonbMcpax5ZQhX+yBZ6TmXREJHksW2utsi3LX3JZh4=; b=lGFOGaI8DQQwMFVBBIq5Y+wZo7jSBdSfYNRkSRz3ybNzBn7r2LnWah/FcMUAI/qCLwNrBlLHqOKWL2MY8vGXfmrwyEf9rntpzk9w93jFdfcaOY9ews8ItQ2PAtNxFo/i38uOSZrmXHZGKNmqzSb4FaqrwQPFoWPaDEWbDRRwohBwrcgriAyLuQDe9tujN5dT4wW8bk3XmuP80zdfSm6BOhAofUlIDRkMz+CiM5ehjsAN5WZu8NUJkpoXb1BONgxuvkzPVS/rhfmZ0N/Da/LNaey18T3mCECAg1APfYH/Goe6aP12OEhUoJNEbR9oEyprR9huerwkVM6B+D0Kc41CsA==
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=TXonbMcpax5ZQhX+yBZ6TmXREJHksW2utsi3LX3JZh4=; b=rwWbOV8TcKO28M7nQiwRIXaA/72ZPsDwnTx9szbmt622LhuxllJLu77SNP8Ohg/VBd7hCdyWT4X0og3ASvTcWjA4WG0blrVTWu6n5UtTR3Rbf7mkm31SWrokruv/QTFwplLbP+NDhEjAatmzMZg9rdQduuesJuD4FmLME7kM2Rs=
Received: from MN2PR11MB4366.namprd11.prod.outlook.com (52.135.38.209) by MN2SPR01MB0035.namprd11.prod.outlook.com (20.178.251.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2178.16; Thu, 22 Aug 2019 15:09:34 +0000
Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::6db3:f4c:467b:30f6]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::6db3:f4c:467b:30f6%7]) with mapi id 15.20.2178.020; Thu, 22 Aug 2019 15:09:34 +0000
From: "Rob Wilton (rwilton)" <rwilton@cisco.com>
To: Martin Bjorklund <mbj@tail-f.com>
CC: "vladimir@transpacket.com" <vladimir@transpacket.com>, "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: [netmod] WG Last Call: draft-ietf-netmod-intf-ext-yang-07
Thread-Index: AQHVNrSsI3r62XsUgUy/9VeuuC2cP6b5dGgAgAxs3iCAAWyGgIAAJk+A
Date: Thu, 22 Aug 2019 15:09:34 +0000
Message-ID: <MN2PR11MB4366DA593D42209D7F44C8EFB5A50@MN2PR11MB4366.namprd11.prod.outlook.com>
References: <0100016bd93bfe12-b7c7407d-7c5f-4d61-a714-3aa38b0d1da7-000000@email.amazonses.com> <b15d63e7-fc96-0942-afef-a45c260522af@transpacket.com> <MN2PR11MB4366C1CD8F0567D0C360F1BAB5A50@MN2PR11MB4366.namprd11.prod.outlook.com> <20190822.133449.502914144686905879.mbj@tail-f.com>
In-Reply-To: <20190822.133449.502914144686905879.mbj@tail-f.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.59]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 35980c64-a3b6-4a68-8397-08d72712be13
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600166)(711020)(4605104)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:MN2SPR01MB0035;
x-ms-traffictypediagnostic: MN2SPR01MB0035:
x-ms-exchange-purlcount: 4
x-microsoft-antispam-prvs: <MN2SPR01MB0035876CC1E483391AE223ABB5A50@MN2SPR01MB0035.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 01371B902F
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(376002)(346002)(396003)(39860400002)(366004)(13464003)(51444003)(189003)(199004)(9686003)(64756008)(6246003)(66066001)(6916009)(54906003)(81166006)(99286004)(8676002)(316002)(11346002)(229853002)(5660300002)(86362001)(446003)(7736002)(14454004)(81156014)(7696005)(53936002)(76176011)(476003)(478600001)(305945005)(74316002)(8936002)(6436002)(102836004)(76116006)(66556008)(66446008)(6306002)(486006)(4326008)(66946007)(3846002)(2906002)(33656002)(6116002)(71190400001)(71200400001)(6506007)(186003)(52536014)(53546011)(25786009)(55016002)(966005)(66476007)(256004)(14444005)(26005); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2SPR01MB0035; 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-message-info: hZ1Lf5bT6X4Qlq8ivHMh4MsTvN8csxTopdmb13Hl59DaLByxzyBOvseg04T61SufjRfDzM7z0mYA/D1Ngo65I6HqrUbHN5+qKmJSbtcyyIi9cQD+cb0wQMGpOUuWk5qYyC458t9BcujmRabS/iGIS+MXbdNLD529juP6SUythR2A/En49qTK8XO/Oc1+lGaodTam7EglIQ4t0qrqYfbMPWtHzw66fCB0G0bt4a+16lO77MiiiD5bkkZiXNcqpEDuxy4kxVz+4DxYZ50Y0g/o6QZ9yjLjaFSgpj+qw9Dn3xT5NZqMu6UKoOKdno0JllTZFadBoeNbLbrvfpGJFOkgUldLd0VTjt4FejtnGTDGdjQoos0tCqVdbASyQcGbhvVxdrk72B38MvR6ZoegqBjw4YpF73P3r4iyMiVi8+8tJtQ=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 35980c64-a3b6-4a68-8397-08d72712be13
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Aug 2019 15:09:34.6090 (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: xl/kKkB82TRMnK3184mBxsWXJAj1BekcU6YlP9XQs8dVKPIIBMW+VwhNMyi1Wb4vi9CNNXCobv2BLehk8j9IwQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2SPR01MB0035
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.12, xch-rcd-002.cisco.com
X-Outbound-Node: rcdn-core-6.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/MpqdZqH3YFbewOoDal7A6OlaXlc>
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-intf-ext-yang-07
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: Thu, 22 Aug 2019 15:09:52 -0000

Hi Martin,

Please see comments inline ...

> -----Original Message-----
> From: Martin Bjorklund <mbj@tail-f.com>;
> Sent: 22 August 2019 12:35
> To: Rob Wilton (rwilton) <rwilton@cisco.com>;
> Cc: vladimir@transpacket.com; netmod@ietf.org
> Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-intf-ext-yang-07
> 
> Hi,
> 
> Some comments inline.
> 
> 
> "Rob Wilton (rwilton)" <rwilton@cisco.com>; wrote:
> > Hi Vladimir,
> >
> > Thanks for your detailed review.  Sorry for the slow reply, I've been
> > away.  I'm also about to be away again for a couple of days.
> >
> > Please see my comments inline ...
> >
> > I'll also track these issues to closure on
> > https://github.com/netmod-wg/interface-extensions-yang/issues
> >
> > > -----Original Message-----
> > > From: netmod <netmod-bounces@ietf.org>; On Behalf Of Vladimir
> > > Vassilev
> > > Sent: 13 August 2019 17:05
> > > To: Kent Watsen <kent+ietf@watsen.net>;; netmod@ietf.org
> > > Subject: Re: [netmod] WG Last Call:
> > > draft-ietf-netmod-intf-ext-yang-07
> > >
> > > I have reviewed the draft. I have the following (19) IMO useful
> > > proposals:
> > >
> > > 1. Dedicated module (ietf-if-oper-status-debounce.yang) for the
> > > oper- status debouncing/dampening functionality currently in
> > > ietf-interfaces-
> > > common.yang.
> >
> > I don't think that we want a proliferation of too many separate YANG
> > modules for small features.  Each of the areas of different
> > functionality within this module are already conditional on
> > if-feature, so I don't think that there is a strong justification to
> > separating this out as a separate module.
> 
> I agree.
> 
> > > 4. Dedicated module (ietf-if-loopback.yang) for the loopback
> > > functionality currently in ietf-interfaces-common.yang.
> >
> > Same answer as for 1. I don't think that we should have too many
> > really small modules.
> 
> I agree.
> 
> 
> > > 10. Introducing config true "forwarding-mode" leaf breaks clients
> > > that support e.g. rfc8344 ietf-ip (which has its dedicated
> > > forwarding leafs e.g.
> > > /ietf-interfaces:interfaces/interface/ietf-ip:ipv4/forwarding ) by
> > > introducing this new module with a new leaf they know nothing about.
> > > I support this leaf as config false. If NETCONF was not
> > > transactional a global leaf enabling the forwarding configuration
> would be a feature.
> > > But NETCONF is transactional.
> >
> > I don't get the relevance of transactions, but it isn't intended to
> > break existing clients/YANG modules.
> >
> > The idea of this leaf is that if it is configured then the system can
> > use it to check other constraints.  E.g. to validate that an L2 QoS
> > policy isn’t being configured on an L3 interface.  If the leaf isn't
> > configured then those constraints are not checked.
> 
> Hmm.  Are you saying that this leaf doesn't have any direct effect in the
> server?

It depends on the device.  Some devices require a leaf like this (or similar) to correctly provision the services.  Other devices don't need it.



> 
> > > 12. I do not agree we need this text. Normally NETCONF devices
> > > should accept transactions to any valid configuration:
> > >
> > > OLD:
> > >     ...
> > >     Normally devices will not allow the parent-interface leaf to be
> > >     changed after the interfce has been created.  If an
> > > implementation
> > >     did allow the parent-interface leaf to be changed then it could
> > > cause
> > >     all traffic on the affected interface to be dropped.  The
> > > affected
> > >     leaf is:
> > >
> > >     o  /if:interfaces/if:interface/parent-interface
> > >     ...
> > >
> > > NEW:
> > >     ...
> > >     Changing the parent-interface leaf could cause
> > >     all traffic on the affected interface to be dropped.
> > >     The affected leaf is:
> > >
> > >     o  /if:interfaces/if:interface/parent-interface
> > >     ...
> >
> > This isn't about transactions so much as valid configuration.
> >
> > Normally, the name of the sub-interface is tightly bound to the parent
> > interface.  E.g. if the parent in "Ethernet0/1" then the sub-interface
> > would be "Ethernet0/1.1".  If you tried to change the parent-interface
> > leaf of "Ethernet0/1.1" to "Ethernet2/2" then I would expect the
> > system to reject that change (because the configuration is invalid not
> > because of transactions).
> 
> Well, this is already described in section 3.6.  The quoted text is from
> Security Considerations.  I agree with Vladimir; I think his suggested
> text is better.

Ah, OK.  If it is in the security section, then I agree that it isn't required.


> 
> > > 14. I propose the in-pkts and out-pkts counters standardized too.
> > > https://github.com/YangModels/yang/blob/master/vendor/cisco/xe/1641/
> > > ietf-
> > > interfaces-ext.yang.
> > > And yes someone forgot to update the boilerplate text.
> >
> > This one I think that we need to get further input on.
> >
> > https://github.com/YangModels/yang/blob/master/standard/ieee/published
> > /802.3/ieee802-ethernet-interface.yang
> >
> > defines in-frames and out-frames, but these are only for Ethernet, but
> > you are probably looking for a counter across all interface types.
> 
> in-pkts is presumably in-unicast-pkts + in-broadcast-pkts + in-multicast-
> pkts.  So is this really needed?

It seems that this might be an issue related to the route policy language that wants the policy to use the total number of good pkts, but is unable of adding the 3 individual values together.

It seems slightly strange to me that the total input/output pkt counters don't exist, particularly if you had a point-to-point L2 protocol that doesn't differentiate between ucast, mcast and bcast.


> 
> > > 19. ietf-if-common.yang and ietf-if-ethernet-like.yang instead of
> > > ietf-
> > > interfaces-common.yang and ietf-interfaces-ethernet-like.yang.
> > > Setting a shorter naming precedent for future modules augmenting
> > > ietf- interfaces.
> >
> > I'm not opposed to shorter names, but would be interested in the views
> > of others in the WG.
> 
> I had a similar concern for the modules in the sub-intf-vlan draft (I will
> post my review of that doc later).
> 
> Currently we have:
> 
>   ietf-interfaces-common
>   ietf-interfaces-ethernet-like
>   ietf-if-l3-vlan
>   ietf-flexible-encapsulation
> 
> I think we should have consistency, either:
> 
>   ietf-interfaces-common
>   ietf-interfaces-ethernet-like
>   ietf-interfaces-l3-vlan
>   ietf-interfaces-flexible-encapsulation
> 
> or
> 
>   ietf-if-common
>   ietf-if-ethernet-like
>   ietf-if-l3-vlan
>   ietf-if-flexible-encapsulation
> 

I prefer the shorter names personally.

Thanks,
Rob


> 
> /martin
> 
> 
> >
> > Thanks again for the review.  It is appreciated.
> >
> > Rob
> >
> >
> > >
> > > /Vladimir
> > >
> > > On 10/07/2019 02.15, Kent Watsen wrote:
> > > > All,
> > > >
> > > > This starts a twelve-day working group last call for
> > > > draft-ietf-netmod-intf-ext-yang-07
> > > >
> > > > The working group last call ends on July 21 (the day before the
> > > > NETMOD
> > > 105 sessions).  Please send your comments to the working group
> > > mailing list.
> > > >
> > > > Positive comments, e.g., "I've reviewed this document and believe
> > > > it is
> > > ready for publication", are welcome!  This is useful and important,
> > > even from authors.
> > > >
> > > > Thank you,
> > > > NETMOD Chairs
> > > > _______________________________________________
> > > > netmod mailing list
> > > > netmod@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/netmod
> > >
> > > _______________________________________________
> > > netmod mailing list
> > > netmod@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netmod
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod