[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