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

Martin Bjorklund <mbj@tail-f.com> Thu, 22 August 2019 11:35 UTC

Return-Path: <mbj@tail-f.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 D3B8B12081E for <netmod@ietfa.amsl.com>; Thu, 22 Aug 2019 04:35:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 7UU-IIuXL0ao for <netmod@ietfa.amsl.com>; Thu, 22 Aug 2019 04:35:15 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id C8A0E120026 for <netmod@ietf.org>; Thu, 22 Aug 2019 04:35:14 -0700 (PDT)
Received: from localhost (unknown [173.38.220.50]) by mail.tail-f.com (Postfix) with ESMTPSA id 039261AE0981; Thu, 22 Aug 2019 13:35:11 +0200 (CEST)
Date: Thu, 22 Aug 2019 13:34:49 +0200 (CEST)
Message-Id: <20190822.133449.502914144686905879.mbj@tail-f.com>
To: rwilton@cisco.com
Cc: vladimir@transpacket.com, netmod@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <MN2PR11MB4366C1CD8F0567D0C360F1BAB5A50@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>
X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=utf-8
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/VfPJleTAMqbRbThxVoMTrRGWBa4>
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 11:35:17 -0000

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?

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

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

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


/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