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

"Rob Wilton (rwilton)" <rwilton@cisco.com> Tue, 05 November 2019 15:05 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 45E39120089 for <netmod@ietfa.amsl.com>; Tue, 5 Nov 2019 07:05:01 -0800 (PST)
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=RWOCCdEO; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=fxaNg4FU
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 1pkDMSQE_dVm for <netmod@ietfa.amsl.com>; Tue, 5 Nov 2019 07:04:56 -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 C0CE9120090 for <netmod@ietf.org>; Tue, 5 Nov 2019 07:04:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=37416; q=dns/txt; s=iport; t=1572966295; x=1574175895; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=2OaJszSnOxA2BFwND0Hud6XYcIsgyBkBqvOJKaowtlQ=; b=RWOCCdEOEw78s9IwjoUxUCIt6ZuyV4NtBMZFfQmf7sJBv0+Je3bnFsA1 kb+zqbtX7Rz974sLNU8z49+HGRKYpCiIHLWNy22c/ZrSFe7l6GySpESoW JLTiPyOQYHJpJQxAU+QEMIprAhA7DOSctB+sB6rI8rbfsbt8qTEBGOTAH Y=;
IronPort-PHdr: =?us-ascii?q?9a23=3AJguPZxG/RpVV61afy21Ff51GYnJ96bzpIg4Y7I?= =?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?A0DTAABBj8Fd/4oNJK1dAwYbAQEBAQE?= =?us-ascii?q?BAQUBAQERAQEDAwEBAYFtAwEBAQsBgUpQBWxYIAQLKgqEH2GCZQOKek6CEJd?= =?us-ascii?q?+gUKBEANUCQEBAQwBARgLCgIBAYN7RQIXg3ckNwYOAgMLAQEEAQEBAgEFBG2?= =?us-ascii?q?FNwyFUQEBAQECAQEBEAgJBA0MAQElBwQIBAcEAgEGAhEEAQEBAgImAgICJQs?= =?us-ascii?q?VCAgCBAESCBqDAYJGAw4gAQIMlEuQYgKBOIhgdX8zgn4BAQWBNAGDTRiCFwM?= =?us-ascii?q?GgQ4oAYwSGIFAP4FXgkw+gmIBAYE3EgoQFRWCZDKCLIx2IAEjDwOCNIVgiRW?= =?us-ascii?q?PBQqCJIcVjkKCPIdbj1KOQ4FAhm6RLgIEAgQFAg4BAQWBaCOBWHAVO4JsUBE?= =?us-ascii?q?UgRyBagwXg1CFFIU/dIEojiArgQQBgQ0BAQ?=
X-IronPort-AV: E=Sophos;i="5.68,271,1569283200"; d="scan'208";a="435446447"
Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 05 Nov 2019 15:04:41 +0000
Received: from XCH-RCD-008.cisco.com (xch-rcd-008.cisco.com [173.37.102.18]) by alln-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id xA5F4fPf022145 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 5 Nov 2019 15:04:41 GMT
Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-RCD-008.cisco.com (173.37.102.18) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 5 Nov 2019 09:04:40 -0600
Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 5 Nov 2019 09:04:40 -0600
Received: from NAM03-CO1-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; Tue, 5 Nov 2019 09:04:40 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eSN9gQl/CjNFCZX2XluYMra/3Liqej7kSED+AzG5m+ssU32+u9sxDzUR2u5tI1dma6toOmSJDUkbu7Idinf4Z1BJ7SRRL9nnPvmpv6F+7Y0haTMLTNikvWYAQjdmDmJaG9Hpr/AXr2nuympVUAFMWlz9w+WRrzElguY5tD71NFTqZmyyIBL7HBqYa52z8OPTiWuFwr9W7Ss5C1jyokrXoeNDM75FMhh737B3g2entarNsPCfBZSQq2r8WodG9+NV56UCHEFiQl4bx83B8z/+asZNCXGreTRsEu7jpjMgpfXqIYxoBJJOpDpLF0W5FbSg0z2Xa2JC7xxEwqbn3YJDPg==
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=2OaJszSnOxA2BFwND0Hud6XYcIsgyBkBqvOJKaowtlQ=; b=AwRM1cnWlO0flXOhiZXfb5AAsgaelRXZmVr0emAt/mtfwF7CA6Fr06nhCmypsNEp/NqbXGTlb/uvBELpqSOS+lBaOB3lqie6azx8Iye2potQflkrTKDnkq4EtACxnoquRce+uopKa7LEJTn2+1cT1ti2Qa5dyb41/6PWthHXMIEcn+9wAsezdNkw0NKeh8LP4FXln6BGDkAobVBkKyvL3hf2ae4qUz8/emWbXL1RKupgrhIogAMU8PGg0SSqZGKfVwcgrWqDyTw8fLT0q5vGM8aE/acfUIqGSiLk8YXzCH02iOnMXMechpRT2/CpWv3Xw8TS/tdF33oYemjgLfonAw==
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=2OaJszSnOxA2BFwND0Hud6XYcIsgyBkBqvOJKaowtlQ=; b=fxaNg4FUMlu8vQfClNb5VI0KuzevYcKNEy5rxRz+a0qHRg5PWL6OunxzpohUVLgZrvcghvWaQ9irD0ReIfLcutzywnLEb6NRObEODgnetDVgw/4x9IOrf/UI3adehMBmhSX5DfX3xX/loza7aZiZEeeYv8xTe+OZjrfdF70QhpI=
Received: from MN2PR11MB4366.namprd11.prod.outlook.com (52.135.38.209) by MN2PR11MB3597.namprd11.prod.outlook.com (20.178.251.157) 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:04:38 +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:04:38 +0000
From: "Rob Wilton (rwilton)" <rwilton@cisco.com>
To: Vladimir Vassilev <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/9VeuuC2cP6b5dGgAgAxs3iCACYAKAIACzdNAgGsicOA=
Date: Tue, 5 Nov 2019 15:04:38 +0000
Message-ID: <MN2PR11MB436694C0EACC125CA91927A6B57E0@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> <783a4e9b-397d-c34e-dd18-2c350d8181e1@transpacket.com> <MN2PR11MB4366A3BA57D1BFD4A99E425AB5A20@MN2PR11MB4366.namprd11.prod.outlook.com>
In-Reply-To: <MN2PR11MB4366A3BA57D1BFD4A99E425AB5A20@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: 2b39fa4d-3b3c-472f-d48a-08d762017a82
x-ms-traffictypediagnostic: MN2PR11MB3597:
x-ms-exchange-purlcount: 4
x-microsoft-antispam-prvs: <MN2PR11MB3597C1382244FEE7EB64FE63B57E0@MN2PR11MB3597.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 0212BDE3BE
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(396003)(136003)(346002)(39860400002)(376002)(51444003)(199004)(13464003)(189003)(66476007)(6116002)(76116006)(66556008)(256004)(3846002)(6506007)(53546011)(102836004)(2501003)(316002)(76176011)(99286004)(74316002)(446003)(11346002)(2906002)(110136005)(64756008)(26005)(66446008)(66946007)(33656002)(71200400001)(71190400001)(55016002)(6436002)(86362001)(30864003)(478600001)(6306002)(14454004)(9686003)(52536014)(966005)(305945005)(14444005)(5024004)(229853002)(7696005)(66066001)(7736002)(186003)(476003)(5660300002)(25786009)(8676002)(81156014)(81166006)(8936002)(6246003)(486006)(559001)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3597; H:MN2PR11MB4366.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX: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: IW3UHujWUwZlpIsTZZvcNF89rBVhlCtvRxplcOHIzk7rQcQuX1hV7lB21CWQs2u6wNugk++ljoz/1BArrbnywqvyInRmYjW3GuXaQVQkMt9engpy5OvSCeI8vOeFs/QtO2t2JeMNFA1Q4hIeBSEi1aG4zYAGx3eiJETpxv5F9hbmMvZDyu7Rl6O1KkM9dvtKh77kbHwQVDhjolW5UN0g35cGsXbBPkc3Sb0MbNsIZrwX/+cKyN7+Ina3gJj24+WP9xZ3CfAlVJphYNRSt/O3FZKS5zbT+oPqbfpGAsAqt5hzftmJQEH4QOzf1gjpxfNpv5xKM3GSuWO4/5hF9OQXwSjcNkUOcSKE0mo/PHmKTKEUPB2OCnrpsheG3gv8j7PSsAR66aEWne6sH2g+yq7/YmmMoxbCDQJKwuFfrddKX4kryWdbTcJTHeqTtyjqy90nZpY3voXMyB87j6kiB+QSsMtQ69JouPZwK/CN/EoU5mY=
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: 2b39fa4d-3b3c-472f-d48a-08d762017a82
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Nov 2019 15:04:38.4369 (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: vXe1SI+2D4AzSKVQM0X3ncffsM2/rv3v/9ikFDmGcIQNKCQsHkZycMCgY79RLH6O4EFQyYoPErWrv2vlU5XWJA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3597
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.18, xch-rcd-008.cisco.com
X-Outbound-Node: alln-core-5.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/Q_itNBOran0K_EHMf4BD0iTKMNA>
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: Tue, 05 Nov 2019 15:05:01 -0000

Hi Vladamir,

> -----Original Message-----
> From: netmod <netmod-bounces@ietf.org>; On Behalf Of Rob Wilton (rwilton)
> Sent: 29 August 2019 17:20
> To: Vladimir Vassilev <vladimir@transpacket.com>;; netmod@ietf.org
> Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-intf-ext-yang-07
> 
> Hi Vladimir,
> 
> Please see inline ...
> 
> > -----Original Message-----
> > From: Vladimir Vassilev <vladimir@transpacket.com>;
> > Sent: 27 August 2019 15:55
> > To: Rob Wilton (rwilton) <rwilton@cisco.com>;; netmod@ietf.org
> > Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-intf-ext-yang-07
> >
> > On 22/08/2019 12.13, Rob Wilton (rwilton) 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 still think that especially the "dampening" mechanism is not common
> > enough and is quite complex to be added to ietf-interfaces-common. If
> > a feature is not common or does not enable the use of generic modeling
> > mechanism (like sub-interfaces etc.) it should not be in
> > ietf-interfaces- common. I do not think "dampening" (maybe at some
> > point we should go back to damping instead e.g. rfc2439 ... seems
> > there is difference between dampening and damping and damping seems to
> > be the correct one) is that common to deserve a place in ietf-
> interfaces-common.
> [RW]
> 
> I've renamed the module to ietf-if-extensions.yang.
> 
> I still don't see that splitting this to a separate YANG module is
> helpful.
> 
[RW] 
I've now closed this issue (with the module renaming).

> 
> >
> > >
> > >> 2. In sec "3.1 Carrier delay" use of the under-defined "Carrier"
> > >> definition can be replaced with direct reference to the oper-status
> > >> leaf (which is what is actually targeted by the algorithm)
> > >> "Operational status transition debouncing".
> > > I think that different vendors have different names for this
> technology.
> > I've just used the one that our products use.  I think that this is
> > just a name, rather than something that has to be defined.  I could
> > add a comment that this feature is sometimes called hold time?
> >
> > I looked for precedents -  "carrier-delay" leaf Cisco, "debouncing-
> > interval" leaf Juniper, "interface-phys-holdtime-config"
> > leaf OpenConfig.
> >
> > I think "Carrier" is confusing since what is delayed actually is the
> > transition of the oper-status.
> [RW]
> 
> But it is not just the oper-status that is delayed (which would only
> affect manageability).
> 
> Instead, it is the internal notification to the higher layer protocols
> that the underlying interface link state has changed.  E.g. with carrier-
> delay down, the IP layer may still think that the interface is up when the
> Ethernet layer signalling indicates that the interface is actually down.
> 
> I'll have a think and see if I can come up with a clearer name for this.
[RW] 

Possibly, this could be renamed to something like "link-flap-suppression" or "state-flap-suppression"?

I've included this as one of the open issues, and will track on a separate thread.  


> 
> 
> >
> > >> 3. "timer-running" and "suppressed" leafs are both "config false"
> > >> and have "default" statements. Although this is valid YANG I do not
> > >> think the "default" statements are intended.
> > > I think that this is a more general question that needs a bit more
> > discussion.  Here, I am using defaults for the config false node to
> > document what the normal value is expected.
> > Well not a real issue but I thought it was an unusual use of default.
> 
[RW] 

I've removed the default values because they could potentially confusion if no value is returned (although RFC 8342 section 5.3 indicates the expected semantics in this case).




> 
> 
> > >
> > >
> > >> 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.
> > If the loopback was modeled as a boolean leaf (as in OpenConfig) I
> > would have agreed. However even small modules that define base
> > identities benefit from dedicated namespace. For me
> > ietf-if-loopback.yang will pay off since loopback='internal' is better
> then loopback='loopback-internal'
> > and there are going to be many test cases that use that line. An last
> > but not least I never had problems with too much modularity.
> 
> OK.  So, I think that this issue is really the same issue as (5) below.
> I.e. you are asking for a separate module to keep the name of the
> identities shorter.
> 
> 
> > >
> > >> 5. Less verbose loopback identities. With dedicated module the
> > >> (loopback-* identities can be shortened skipping the prefix).
> > > I think that it is normal to bind the identity names to the common
> > > base
> > identity.  I don't see that the length of the identities should really
> > be an issue.
> > For me the length of identities does matter since I often use command
> > line tools. But it is mostly the irritation caused by the tautology
> > loopback='loopback-internal' that everyone writing network
> > interconnect testcases is going to be stuck with forever if we leave
> > the loopback control model as part of ietf-interfaces-common and not
> > separate ietf-if- loopback. What do others think?
> 
> There are some choices here:
> (1) Keep with identities with a "loopback-" prefix.  This causes
> loopback='loopback-internal'
> (2) Keep with identities, but loose the common prefix, i.e. the identities
> become "internal", "line", "connector"
> (3) Use shorter identities, but also put them in a separate module.
> (4) Use an enum rather than identities.  Although this has the potential
> issue that enums cannot be extended.
> 
> I've also asked the YANG doctors for their input on this question -
> consistent modelling behaviour across modules is also important.
> 
> So far the consensus is to keep them in the same module but drop the
> "loopback-" prefix.  Hence, this is my proposed resolution.
[RW] 
Issue closed.  I've keep the prefixes in the same module, but with shorter names by loosing the prefix.


> 
> 
> > >
> > >> 6. The draft introduces "loopback-internal", "loopback-line" and
> > >> "loopback-connector" loopback identities. What is confusing is that
> > >> "internal loopback" is historically the opposite of "external
> loopback"
> > >> which is a loopback with a connector. I think terminology already
> > >> in use like "near-end" and "far-end" is less confusing.
> > > The internal/line loopback configuration has been used in parts of
> > > the
> > industry for at least 20 years, so this terminology is already in use.
> > >
> > > I'm not sure that "near-end" and "far-end" would be less confusing.
> > Assuming that "loopback far-end" was equivalent to "loopback-line"
> > then it would be somewhat of a misnomer since it acts on the near end,
> > not the far end.
> > >
> > > I.e. both loopback internal, and loopback line act on the local
> > interface, the only difference is in which direction they reflect the
> > signals, i.e. Egress -> Ingress (internal), or Ingress -> Egress (line).
> 
> 
> > I can live with local/line/connector but I do not agree near-end/far-
> > end/connector  is more confusing.
> 
> OK.
[RW] 
Issue closed.


> 
> 
> > >
> > > Perhaps the description text could be slightly clarified here to
> > > help
> > avoid confusion?
> > >
> > > OLD:
> > >
> > >     The following loopback modes are defined:
> > >
> > >     o  Internal loopback - All egress traffic on the interface is
> > >        internally looped back within the interface to be received on
> the
> > >        ingress path.
> > >
> > >     o  Line loopback - All ingress traffic received on the interface
> is
> > >        internally looped back within the interface to the egress path.
> > >
> > >     o  Loopback Connector - The interface has a physical loopback
> > >        connector attached that loops all egress traffic back into the
> > >        interface's ingress path, with equivalent semantics to internal
> > >        loopback.
> > >
> > > NEW:
> > >
> > >     The following loopback modes are defined:
> > >
> > >     o  Internal loopback - All frames that egress out of the interface
> > >        are looped back internally within the interface hardware
> > >        to be received on the ingress path.
> > >
> > >     o  Line loopback - All ingress frames received on the interface
> from
> > >        the line are looped back within the interface hardware and
> > >        transmitted back out of the interface.
> > >
> > >     o  Loopback connector - The interface has a physical loopback
> > >        connector attached that loops all egress frames back into the
> > >        interface's ingress path, with equivalent semantics to internal
> > >        loopback.
> > Adding frames excludes continuous stream (no frame) devices like
> > legacy serial links and high speed transceivers, optical links.
> > Loopback is applicable there too. IMO the OLD text was better.
> 
> OK, I will keep with the current definitions.
> 
[RW] 
Issue closed.



> 
> 
> 
> > >> 7. I am not sure standardizing the "loopback-connector" identity is
> > >> justified. All usecases of connecting a loopback connector I can
> > >> think of require the system to not be aware there is special
> > >> external loopback connector on the interface.
> > > I think that it will depend on how smart of dumb the external
> > > loopback
> > connector is.  If it is just a dumb electrical or optical loopback
> > then the source and destination MAC addresses need to be swapped, or
> > otherwise any egress frames out of the interface will fail the
> > destination MAC address filter when they are looped around.
> > OK
> 
> I've closed this issue.
> 
> > >
> > > Some implementations also use this configuration to force self ping
> > packets out through the interface, so that the full datapath is
> > tested, rather than the packets being looped internally within the L3
> > forwarding code.
> > >
> > >
> > >> 8. Some interfaces that implement "loopback-internal" do not
> > >> implement "loopback-line" - e.g. classical ethernetCsmacd
> > >> (Carrier-sense multiple access with collision detection) has a
> > >> physical layer that by design can not implement such loopback.
> > >> Maybe introducing a dedicated feature to enable the "loopback-line"
> > >> is a good
> > idea.
> > > I'm not sure on this one, i.e. whether it really helps or just adds
> > extra clutter.
> > > Realistically, I think that ethernetCsmacd is dead.  Do you have
> > > other
> > examples of interface types that do support loopback, but not in both
> > directions?
> > All interfaces that are not point-to-point (e.g. common wifi).
> 
> Even then, I still think that loopback internal and line can both work.
> 
> Loopback internal - you loop all frames that would have been transmitted
> out of the radio interface.
> Loopback line - you loop and frames received on the radio interface.
> 
> Having a connector on a radio interface probably doesn't make as much
> sense.
> 
> But still suggest that we rely on deviations to handle this case, and
> hence close this issue.
[RW] 

Issue closed.


> 
> 
> > > This might be something better handled via a deviation, or the
> > > device
> > failing the configuration when it is verified.
> > OK
> > > As a side note, one of the limitations of features and deviations is
> > that the apply to all interfaces on the device, but the actual
> > properties of an interface might vary depending on the speed, type and
> > hardware associated with the interface.
> > >
> > >
> > >> 9. Appropriate entry in the "11. Security Considerations" noting
> > >> the possibility of DoS attacks and broadcast traffic storms
> > >> resulting from
> > >> loopbacks:
> > >>
> > >> OLD:
> > >>
> > >>      The following leaf could cause the interface to go down, and
> stop
> > >>      processing any ingress or egress traffic on the interface:
> > >>
> > >>      o  /if:interfaces/if:interface/loopback
> > >>
> > >> NEW:
> > >>
> > >>      The following leaf could cause the interface to go down, and
> stop
> > >>      processing any ingress or egress traffic on the interface. It
> > could
> > >>      cause broadcast traffic storms.
> > >>
> > >>      o  /if:interfaces/if:interface/loopback
> > >>
> > > Ack.
[RW] 

Draft updated.


> > >
> > >
> > >
> > >> 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.
> > If this leaf is only enabling optional additional constrains (and this
> > is the only backward compatible option) It won't be that useful as
> > config true.
> > >
> > >
> > >> 11. The "forwarding-mode" leaf has the following set of identities
> > >> {optical-layer, l2-forwarding, network-layer}. We could make the
> > identity
> > >> names shorter and consistent. l1,l2,l3 or physical,data-link,network.
> > > I've tried to use names here that network engineers are most likely
> > > to
> > be familiar with.
> > >
> > > I think that using the OSI layer names (e.g. l1, l2, l3) would be
> > > too
> > terse.
> > >
> > > We could change "l2-forwarding" to "data-link-layer", but I would
> > > think
> > that people would be more familiar with "l2-forwarding" as a term.  E.g.
> > related to L2VPN.
[RW] 

I've made this leaf config false, and changed the names to "physical", "data-link", and "network".



> > >
> > >
> > >> 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).
> > >
[RW] 

I have made this change (the text is in the security section).


> > >
> > >> 13. The in-drop-unknown-dest-mac-pkts changes the behavior of the
> > >> in- unicast-pkts,in-multicast-pkts and in-broadcast-pkts. I do not
> > >> agree
> > any
> > >> discarded packets in the forwarding process should be subtracted
> > >> from
> > the
> > >> interface counters.
> > >>
> > >> Here is the current description:
> > >>
> > >> OLD:
> > >>                   For consistency, frames counted against this drop
> > >>                   counters 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.
> > >> NEW:
> > >>                   The implementation of this counter does not
> > >>                   change the behavior of the counters defined in
> > >>                   IETF interfaces statistics.
> > >>
> > > It is not changing the definitions of those counters at all.  It is
> > > just
> > explaining the relationship between them.
> >
> > The problem I see is that today there are existing systems that
> > implement ietf-interfaces and discard packets because they have
> > unknown MAC destination. But those systems do not subtract the number
> > of discarded packets from the "in-unicast-pkts" counter. Those systems
> > will have to change their behavior in a non-backward compatible way to
> > be able to implement the in-drop-unknown-dest-mac-pkts with this
> > description. In my view this text changes the definition of
> > in-unicast-pkts enforcing certain design that was not enforced before.
> 
> I don't think that those systems are correctly implementing the "in-
> unicast-pkts" counter.
> 
> I.e. you shouldn't be handing packets off to the IP layer to forward, if
> it fails an L2 dest MAC check.  If you don't hand the packet to IP, then
> you shouldn't be incrementing "in-unicast-pkts" as per the "delivered by
> this sub-layer to a higher (sub-layer)" comment.
> 
>            leaf in-unicast-pkts {
>              type yang:counter64;
>              description
>                "The number of packets, delivered by this sub-layer to a
>                 higher (sub-)layer, that were not addressed to a
>                 multicast or broadcast address at this sub-layer.
>                 ..."
> 
> And also the "prevent their being deliverable to a higher-layer protocol"
> comment in in-discards:
> 
>            leaf in-discards {
>              type yang:counter32;
>              description
>                "The number of inbound packets that were chosen to be
>                 discarded even though no errors had been detected to
>                 prevent their being deliverable to a higher-layer
>                 protocol.  One possible reason for discarding such a
>                 packet could be to free up buffer space.
> 
[RW] 

I've kept the original text, it is useful clarification, and does not
change the meaning of the existing counter.




> 
> 
> 
> 
> >
> > >
> > >
> > >
> > >>
> > >> 14. I propose the in-pkts and out-pkts counters standardized too.
> > >>
> > https://github.com/YangModels/yang/blob/master/vendor/cisco/xe/1641/ie
> > tf-
> > >> interfaces-ext.yang.
> > >> And yes someone forgot to update the boilerplate text.
> > > This one I think that we need to get further input on.
[RW] 

I've kept this as an open issue to get closure 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.
> > Yes. in-pkts and out-pkts are used by OpenFlow, OpenDaylight,
> > OpenConfig, Cisco etc. Those are interface independent. It is
> > impossible to implement ietf-interfaces for devices that provide only
> > in-pkts and out-pkts (that would be all OpenFlow switches) which is a
> > good argument to have the counters standardized.
> > >
> > >> 15. I propose that new "ietf-interfaces-common:in-discards-overflow"
> > >> counter is added. Currently the "ietf-interfaces:in-discards" can
> > contain
> > >> both discards like the ones accumulated in
> > >> in-drop-unknown-dest-mac-
> > pkts
> > >> and discards caused by overflows (performance related loss of
> > >> packets
> > like
> > >> freeing buffer space in devices that in certain cases are
> > >> forwarding slower then the line speed). Turns out knowing if device
> > >> is discarding
> > >> (loosing) packets due to performance shortage and discarding
> > (filtering)
> > >> unwanted packets are two different events that one needs to
> > differentiate
> > >> between are currently in the same in-discards counter. We can fix
> > >> that with the introduction of in-discards-overflow counter.
> > > This one I think that we need to get further input on.  I think that
> > this might be useful.  But we might need some care to ensure that it
> > fits cleanly with QoS drops.
> > >
> > > If we were to add this then the definition of "ietf-interfaces:in-
> > discards" cannot change.  i.e. In-discards-overflow would be a subset
> > of "in-discards".
> > OK
[RW] 

I've kept this as an open issue.


> > >
> > >
> > >> 16. We can replace
> > >> "ietf-interfaces-ethernet-like:in-drop-unknown-dest-mac-pkts" with
> > >> (in- discards - in-discards-overflow) for MAC Bridges or any other
> > >> Ethernet interface plus save us the introduction of technology
> > >> specific similar counters for the rest of the Bridges and non-
> Ethernet interfaces.
> > > For Ethernet, having a technology specific
> > > in-drop-unknown-dest-mac-pkts
> > is useful.
> > >
> > > In the WG discussion, there was agreement to also add a drop counter
> > > for
> > packets that are dropped because they cannot be demuxed to any sub-
> > interface.
> > >
> > > Personally, I think that it is useful to have an overall drop
> > > counter
> > that captures everything, along with more specific drop counters that
> > sometimes give more information as to what has causes specific drops.
> > Specifically, just because a more specific drop counter has been
> > defined, that doesn't mean that it shouldn't also be included in the
> > general drop counter.
> 
> > IMO the in-discards counter should be incremented in very rare
> > circumstances (e.g. ingress clock frequency above supported) and
> > ideally reserved for reporting performance issues in the MAC that
> > should normally not exist. The "unknown-dest-mac" and "packets that
> > are dropped because they cannot be demuxed to any sub-interface"
> > should be handled at another "sub-layer" and do not need to be
> > subtracted from the ietf-interfaces in-*-pkt counters because this is
> > very confusing. But probably there are systems out there that already
> > use "in-discards" for all sorts of discards.
> 
> My interpretation of RFC 8343 is that ingress packets to an interface are
> all included in the in-octets counter, and then categorized into one of 6
> packet counters:
>  - good packets (delivered to a high layer protocol) are counted against
> one of in-unicast-pkts, in-broadcast-pkts or in-multicast-pkts
>  - valid packets dropped because the higher layer protocol is unknown (or
> not configured/enabled) are counted against in-unknown-protos
>  - erroneous packets (e.g. all framing errors, too long, too short) are
> counted against in-errors,
>  - all other packets dropped on the ingress interface for any other reason
> not covered above are counted against in-discards
> 
> in-drop-unknown-dest-mac-pkts doesn't change the above definitions.  Is
> this the subset of in-discards that are dropped because the dest MAC
> address is invalid.  If frames counted against in-drop-unknown-dest-mac-
> pkts weren't also counted against in-discards then that would effectively
> changes the definition in-discards, and would break implementations that
> are not checking the in-drop-unknown-dest-mac-pkts counter.
> 
[RW] 

I have kept in-drop-unknown-dest-mac-pkts, because it is useful counter.

Thanks,
Rob


> Thanks,
> Rob
> 
> 
> > >
> > >
> > >> 17. I have separately posted my arguments against introduction of
> > >> leaf named l2-mtu and the need of a config false leaf that has
> > >> similar semantics as the ifMtu object from IF-MIB.
> > > OK, lets keep this issue on that other thread.
> > OK
> > >
> > >
> > >> 18. Some references to relevant IEEE standards and IEEE maintained
> > >> YANG modules should be added (in the scope of
> > >> ietf-interfaces-ethernet-
> > like).
> > >> Also a few lines explaining the policy change and why none of the
> > >> RFC3635 managed objects are part of the new
> > >> ietf-interfaces-ethernet-
> > like
> > >> YANG module.
> > > Yes, OK.
> > >
> > >
> > >> 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.
> >
> > OK
> >
> >
> > /Vladimir
> >
> > >
> > > Thanks again for the review.  It is appreciated.
> > >
> > > Rob
> > >
> > >
> > >> /Vladimir
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod