Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

"Acee Lindem (acee)" <acee@cisco.com> Tue, 26 July 2016 22:24 UTC

Return-Path: <acee@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 A614B12D575 for <netmod@ietfa.amsl.com>; Tue, 26 Jul 2016 15:24:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.807
X-Spam-Level:
X-Spam-Status: No, score=-15.807 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-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
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 hTD17TtGEnAc for <netmod@ietfa.amsl.com>; Tue, 26 Jul 2016 15:24:46 -0700 (PDT)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9A3B12DA39 for <netmod@ietf.org>; Tue, 26 Jul 2016 15:24:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13699; q=dns/txt; s=iport; t=1469571886; x=1470781486; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=szICJWu1xyDFZ1V5BIovDAqY2xOxo3psdgqaKFnAAx0=; b=GFzjuL839NpLWDcQxVonD/KhaCkjsshNZQYuJ0i4S2eBuO4PjWwAjA7y W9qBzcYu89DLbMmodigGAQBAoENIWhbHacE9T2Px1/e4to2Nf+S6aWyr+ FP0g7iQ5U8h7s0ns+2Xo9X4L7tv1/1ukHnIkutQv6fTaC3KshsYF1fuq5 U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DGAgDd4pdX/51dJa1egnFOVnwGgnqwfIJ2gg+BfYYdAhyBHjgUAQEBAQEBAV0nhFwBAQUMF2YCAQYCDgMDAQIoAwICAjAUCQgCBAESG4gWj1qdII1nAQEBAQEBAQEBAQEBAQEBAQEBAQEBHIp3hBxEgmGCWgWZMQGOeo8/jC2DdwEeNoN4bocSRX8BAQE
X-IronPort-AV: E=Sophos;i="5.28,427,1464652800"; d="scan'208,217";a="301886772"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Jul 2016 22:24:45 +0000
Received: from XCH-RTP-010.cisco.com (xch-rtp-010.cisco.com [64.101.220.150]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u6QMOjNR013617 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 26 Jul 2016 22:24:45 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-010.cisco.com (64.101.220.150) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 26 Jul 2016 18:24:44 -0400
Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Tue, 26 Jul 2016 18:24:44 -0400
From: "Acee Lindem (acee)" <acee@cisco.com>
To: Kent Watsen <kwatsen@juniper.net>, "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" <rwilton@cisco.com>, netmod WG <netmod@ietf.org>
Thread-Topic: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure
Thread-Index: AQHR25JaeXwJZYUBL0Wtuo0RKdx74KAjJxmAgADv8QCABT5TAIABj1SAgAAMLoCAAGPYAIAATsgA//++XAA=
Date: Tue, 26 Jul 2016 22:24:44 +0000
Message-ID: <D3BD5AF2.70E5B%acee@cisco.com>
References: <D3A935F0.6A4DC%acee@cisco.com> <eb15fd23-2c0a-50c4-1ebc-7c0e4867dfd8@cisco.com> <20160721174033.GB54646@elstar.local> <d18f5dd0-64d0-e223-88a9-faa4df4b7866@cisco.com> <DCB3EBBF-5EB1-4C8E-AA55-F59C4B5A8E4D@juniper.net> <bed9398c-0e6a-450e-d2ac-b381b6bebf87@cisco.com> <5296754B-8178-4B1B-B4A6-FE228ABB8E7F@juniper.net> <D3BD4DBB.70D87%acee@cisco.com> <D3FB31E6-75BD-44F9-A977-533FD03A9F11@juniper.net>
In-Reply-To: <D3FB31E6-75BD-44F9-A977-533FD03A9F11@juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.116.152.197]
Content-Type: multipart/alternative; boundary="_000_D3BD5AF270E5Baceeciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/EpUP9n_DVtpovKloi9lM-pz6ssc>
Subject: Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
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, 26 Jul 2016 22:24:49 -0000


From: Kent Watsen <kwatsen@juniper.net<mailto:kwatsen@juniper.net>>
Date: Wednesday, July 27, 2016 at 12:19 AM
To: Acee Lindem <acee@cisco.com<mailto:acee@cisco.com>>, "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" <rwilton@cisco.com<mailto:rwilton@cisco.com>>, netmod WG <netmod@ietf.org<mailto:netmod@ietf.org>>
Subject: Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

<Acee>
There are a number of issues here. The first is that you are now depending on the separate applied state data store being implemented on every network device if you are going to eliminate the duplication of actual values in the OpState. The second is that OpsState is MUCH more than just counters. For example, for routing protocols will many times include a local RIB. The third is that it is a big change for these draft models and, if you have been following the discussion on the list, you should know that this option is not universally accepted (reference the E-mail thread I started with options before IETF 96).
</Acee>


But I specifically called out that I was only talking about counters (e.g., 7223) and not applied config.   For applied config, I think that we’ll wait for the opstate solution, per decision ‘B’.

Why would we consider handling counters differently from other operational state that is not part of applied config???

Acee




Regardless, let’s not lose focus on my first question about how prevalent an issue this is.  If 7223 is a singularity, then we should stop worrying about this as a general problem.  I’d like to understand how big this box is before jumping into it.

We’ve had config false leafs mixed in config true trees forever.  Only when there are system-generated values or values whose lifetimes extend past the lifetime of the config true object is there an issue.   This isn’t a new thing, nor an applied config thing, but it can be nicely solved by the opstate solution.  The only question is what we do in the interim.

Kent  // as a contributor