Re: [Lsr] Benjamin Kaduk's Discuss on draft-ietf-isis-yang-isis-cfg-40: (with DISCUSS and COMMENT)

"Acee Lindem (acee)" <acee@cisco.com> Tue, 08 October 2019 17:08 UTC

Return-Path: <acee@cisco.com>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92351120033; Tue, 8 Oct 2019 10:08:47 -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=h6fzbcxP; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Ql33pKTl
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 fICUa-L7ZBSY; Tue, 8 Oct 2019 10:08:45 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10CBF120013; Tue, 8 Oct 2019 10:08:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5690; q=dns/txt; s=iport; t=1570554525; x=1571764125; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=yPXdKuBeBO1QYhCpAFygDBNB7K3UZCy0pxUc67ce7mc=; b=h6fzbcxPKv/dmzgf0EuUvdksM5s81K+OlLvbrMzHUPcCwkaEgr2PC+dM Tf/ZgK3Zeax0TDHqQ+e0Ejr1H01P1OIR6ymBHfQ61nEFYtdDsLgEuiKCD VpQTbw3IEl/9NTT4wTewtdf3wuypmn1kjPFuWeTbhBBR4ucAmWjfuLQeU U=;
IronPort-PHdr: =?us-ascii?q?9a23=3AZF6yqhUsnSj3vVDTA/oDZXQmK3XV8LGuZFwc94?= =?us-ascii?q?YnhrRSc6+q45XlOgnF6O5wiEPSANiJ8OpK3uzRta2oGXcN55qMqjgjSNRNTF?= =?us-ascii?q?dEwd4TgxRmBceEDUPhK/u/Zic3EexJVURu+DewNk0GUMs=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AUAABowpxd/49dJa1mDgwBAQEBAQE?= =?us-ascii?q?BAQEDAQEBAREBAQECAgEBAQGBaQMBAQEBCwGBSlADbVYgBAsqhCODRwOKS4J?= =?us-ascii?q?ciWqOE4EugSQDVAkBAQEMAQEjCgIBAYRAAheCLiM2Bw4CAwkBAQQBAQECAQU?= =?us-ascii?q?EbYUtDIVLAQEBAQIBEhERDAEBNwELBAIBCBEEAQEBAgImAgICHxEVCAgCBAE?= =?us-ascii?q?NBSKDAAGBagMODwECDKM+AoE4iGF1gTKCfQEBBYUKDQuCFwMGgQwoAYwNGIF?= =?us-ascii?q?/gRABJx+CTD6CGkcBAQIBgV4mgmgygiaMd4JBN45ljjJBCoIihwiKCQSEBBu?= =?us-ascii?q?COodOjziOLYgigg6PBgIEAgQFAg4BAQWBWQIwgVhwFWUBgkFQEBSBTziDO4U?= =?us-ascii?q?UhQQ7dAGBKI9rAQE?=
X-IronPort-AV: E=Sophos;i="5.67,270,1566864000"; d="scan'208";a="555842039"
Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 08 Oct 2019 17:08:16 +0000
Received: from XCH-RCD-006.cisco.com (xch-rcd-006.cisco.com [173.37.102.16]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id x98H8GPC009757 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 8 Oct 2019 17:08:16 GMT
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-RCD-006.cisco.com (173.37.102.16) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 8 Oct 2019 12:08:15 -0500
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 8 Oct 2019 13:08:14 -0400
Received: from NAM01-BN3-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 8 Oct 2019 13:08:14 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SPnn5RG4bEB5N0KmSVDXVQH3mCWhNJu5m5ud44jbSF5jkHvLp6nJl+EW/h+MAXS6Atb4Q+rQ6+o0MwVVSaww/CYVjYElJ9GCJXbwMXPWvMc3CZSE24VUImZsqowJ8B7h3UMvk6XCYlbkihm0ldDv/dxF2eJP/EmmA8TFKixhv3doSr/BwcMat0FFVbS3sBxI6IoirCozIGMpBek/n++nR7Zbjgxz+54lM8q4pqMO2iCh75DLQtd3zswXPkRwxM/x5pMDhvZSn/sSolWOM1bBLcs9MPTTDKwQAURurSiOWQfpN+atZ+jxv6CO9JsDY8v+G6nrzI/R0zyNgKDq3qt89A==
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=yPXdKuBeBO1QYhCpAFygDBNB7K3UZCy0pxUc67ce7mc=; b=mET4dR+QSREWooPIt+OPWcQecNhXakSRCFJKEapsu7r4rF88ea0YJMF6XmCHVk8WRAj/2Gh1pjvCfPr7Q4VSd2jIVeAW1T4SJ4ZliTH19ACDQPw226j1LWtoZEswRMamg8SMAxPqIrySeV9Xtx/pnZrZzNalQh9lCFmvucpqmt3KwLR0ILxkG/A5UYsH3bsyoUtLQ5My5TnZ6CQ8+XylpmIJqSdXZP/n8rGp2Xiiuuthjx0KozWcF80KDAWN2XUnAFrwjHbNh8FiqqjnSHDbqkhRVNeeJF4IdqcmbkPfE8P5J+lSsO/rBPhlvmLSSLCJb0gMEcGmUVAr5doH+3NadA==
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=yPXdKuBeBO1QYhCpAFygDBNB7K3UZCy0pxUc67ce7mc=; b=Ql33pKTlTqj5riuLlukr1+FbwXqtbP1Rz/JPYFoQ8031q7gadKFGZna6FIK4mMVNv4vXIdmBEZEBx6Jc0bHs4qtgkng37kMJS4EM0NOjG+NHFDyLV9KvVZ1FnJlLl7+fB2+WOFNf1mBp0ggFVWUB4u8RQBG8bV376RU/uJ3rDoQ=
Received: from MN2PR11MB4221.namprd11.prod.outlook.com (52.135.38.14) by MN2PR11MB4462.namprd11.prod.outlook.com (52.135.38.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2347.16; Tue, 8 Oct 2019 17:08:13 +0000
Received: from MN2PR11MB4221.namprd11.prod.outlook.com ([fe80::787e:8cf4:6217:9f56]) by MN2PR11MB4221.namprd11.prod.outlook.com ([fe80::787e:8cf4:6217:9f56%4]) with mapi id 15.20.2327.026; Tue, 8 Oct 2019 17:08:13 +0000
From: "Acee Lindem (acee)" <acee@cisco.com>
To: Benjamin Kaduk <kaduk@mit.edu>, "slitkows.ietf@gmail.com" <slitkows.ietf@gmail.com>
CC: "'The IESG'" <iesg@ietf.org>, "draft-ietf-isis-yang-isis-cfg@ietf.org" <draft-ietf-isis-yang-isis-cfg@ietf.org>, "'Yingzhen Qu'" <yingzhen.ietf@gmail.com>, "aretana.ietf@gmail.com" <aretana.ietf@gmail.com>, "lsr-chairs@ietf.org" <lsr-chairs@ietf.org>, "lsr@ietf.org" <lsr@ietf.org>
Thread-Topic: Benjamin Kaduk's Discuss on draft-ietf-isis-yang-isis-cfg-40: (with DISCUSS and COMMENT)
Thread-Index: AQHVeL8agypWXt0pRU6/dg1NTfibYKdQdLiAgAAbqYCAADEBAA==
Date: Tue, 8 Oct 2019 17:08:13 +0000
Message-ID: <67F8EAEC-5EB8-4A02-98F5-CDA2CCB7A3E5@cisco.com>
References: <156997901245.26411.13754348016200348607.idtracker@ietfa.amsl.com> <00d501d57db3$1ca808d0$55f81a70$@gmail.com> <20191008101249.GC76545@kduck.mit.edu>
In-Reply-To: <20191008101249.GC76545@kduck.mit.edu>
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=acee@cisco.com;
x-originating-ip: [2001:420:c0c4:1006::11f]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: f66b9880-bba2-4e58-f7a2-08d74c121aa1
x-ms-traffictypediagnostic: MN2PR11MB4462:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <MN2PR11MB4462BBDCBBA475EA65F97D93C29A0@MN2PR11MB4462.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 01842C458A
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(346002)(366004)(136003)(376002)(396003)(13464003)(51914003)(199004)(189003)(966005)(54906003)(14454004)(256004)(2171002)(229853002)(6246003)(6512007)(6306002)(25786009)(71190400001)(71200400001)(6486002)(33656002)(2906002)(5660300002)(6436002)(478600001)(66946007)(66476007)(64756008)(66446008)(6116002)(66556008)(110136005)(8936002)(76116006)(36756003)(4326008)(7736002)(316002)(86362001)(186003)(46003)(305945005)(446003)(11346002)(2616005)(476003)(486006)(76176011)(2501003)(8676002)(99286004)(53546011)(102836004)(6506007)(81156014)(81166006); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4462; H:MN2PR11MB4221.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: fxRTIRmm3SPqowAPsTxE81wJGT4q8uTCdXV476hDsLgU1k2wmGqIv9NgIUjNv0A2VOHxlvuZEV4qY77JVxsZyrkvDAQOlhdwlvNbsQqCLYBiA8E5KCO/Vw8IAMmz2lLhGqu+KTHgWjlxHVa0yzyLwojVuCpd9BICkd/IvcCAv1MBToyk24rjFI39mnYeEvr7IBbZi2fhd702cHusaNaZW8OSkORUtqMCtyXwAUO9Mnlh1zoWvUanmh9GP26I6Jy55Z68vbt9A/vhBkeyHneF8S5K5lbJhu33fDYp5zXto+pTrSJiRnn/CRo7A7MIZhriMmzkmaLIz0zQTZ4duiYQQ3mztr9x+ZbCLXx0HrMJVDherm15Gb+SzEZxkgfSIfoPAnX5Vu/6qoVxVGMvRAxWwV1syEBZGya5+jtz9IzN0p/I5q7Pwv8YbzLuHQC48ytUIP1j6boXLb9CuQ3kuXxpUw==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <1D93CFBB1AC64046AAFBB875D8B0D18F@namprd11.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: f66b9880-bba2-4e58-f7a2-08d74c121aa1
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Oct 2019 17:08:13.4610 (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: /CDuIM2AuK8Il8fsLH4C+vkA4jsuKnnZ7VUME4E2ExZQBgZc+8w3GGrtpJYQraHx
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4462
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.16, xch-rcd-006.cisco.com
X-Outbound-Node: rcdn-core-7.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/YRXPuFBN3MXFXbQaMqmDnYYj4Z0>
Subject: Re: [Lsr] Benjamin Kaduk's Discuss on draft-ietf-isis-yang-isis-cfg-40: (with DISCUSS and COMMENT)
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Oct 2019 17:08:48 -0000

Hi Ben, 
Thanks for the excellent review - see one inline. 

´╗┐On 10/8/19, 6:13 AM, "Benjamin Kaduk" <kaduk@mit.edu>; wrote:

    Hi Stephane,
    
    Thanks for pulling in the fixes; just a few notes inline (and trimming)...
    
    On Tue, Oct 08, 2019 at 10:33:49AM +0200, slitkows.ietf@gmail.com wrote:
    > Hi Benjamin,
    > 
    > Thanks for your comment.
    > Please find some inline answers.
    > I'm doing the changes as part of the -41.
    > 
    > 
    > Stephane
    > 
    > -----Original Message-----
    > From: Benjamin Kaduk via Datatracker <noreply@ietf.org>; 
    > Sent: mercredi 2 octobre 2019 03:17
    > To: The IESG <iesg@ietf.org>;
    > Cc: draft-ietf-isis-yang-isis-cfg@ietf.org; Yingzhen Qu <yingzhen.ietf@gmail.com>;; aretana.ietf@gmail.com; lsr-chairs@ietf.org; yingzhen.ietf@gmail.com; lsr@ietf.org
    > Subject: Benjamin Kaduk's Discuss on draft-ietf-isis-yang-isis-cfg-40: (with DISCUSS and COMMENT)
    > 
    [...]
    > 
    > 
    > In the "protection-available" container, is there some sort of constraint that two of the alternate-metrics add up to the third?
    > [SLI] It is not really a constraint from a YANG point of view, these are operational counters.
    
    Sorry, I shouldn't have used the word "constraint", since that's a YANG
    verb.  I was just asking if the description should reiterate to the reader
    that in normal circumstances the two will add up to the third (and "no" is
    a fine answer).
    
    [...]
    >        container delay-metric {
    >          leaf metric {
    >            type std-metric;
    >            description "IS-IS delay metric for IPv4 prefix";
    >          }
    >          leaf supported {
    >            type boolean;
    > 
    > Should the "metric" leaf be conditional on "supported" being true?
    > (Same for the other flavors of metric, as well as when they appear later on in the "neighbor" grouping.)
    > 
    > 
    > [SLI] This is not a configuration leaf, so I don't think that there is a need for enforcement at YANG level.
    
    Oh, I had missed that it was config false; sorry about that.
    
    [...]
    > 
    >        container unidirectional-link-delay-variation {
    >          description
    >            "Container for the average delay variation
    >            from the local neighbor to the remote one.";
    >          leaf value {
    >            type uint32;
    >            units usec;
    >            description
    >              "Delay variation value expressed in microseconds.";
    > 
    > Is this a standard deviation (variance), mean absolute error, ...?
    > [SLI] We just mimic what is defined in RFC8570. As the reference is defined in the model. People should refer to it for more details.
    > Moreover this is a pure operational state.
    
    https://tools.ietf.org/html/rfc8570#section-4.3 still leaves me a little
    unclear about what exactly is being reported (it sounds like it's just an
    average link delay so the word "variation" confuses me), but I agree that
    we should not say any more in this document.
    
    >        container unidirectional-link-loss {
    >          [...]
    >          leaf value {
    >            type uint32;
    >            units percent;
    >            description
    >              "Link packet loss expressed as a percentage
    >              of the total traffic sent over a configurable interval.";
    > 
    > This document is all about specifying configuration.  How do I configure the interval in question?
    > [SLI] This is an operational state.
    
    The leaf value is operational state, yes, but it reports a valid computed
    "over a configurable interval".  How do I configure that interval?

I don't disagree that there is more configuration and state associated with these traffic metrics. However, these are not really under the purview of this model since IS-IS (and OSPF for that matter) are only serving as a mechanism to advertise these traffic metrics. 

Thanks,
Acee
    
    Thanks!
    
    -Ben