Re: [netmod] What's the problem with NMDA? was Re: 答复: 答复: Please clarify implementation about ‘when’

"Rob Wilton (rwilton)" <rwilton@cisco.com> Fri, 27 September 2019 10:40 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 7C731120115 for <netmod@ietfa.amsl.com>; Fri, 27 Sep 2019 03:40:10 -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=Otm9l4X6; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=g1rS5zEQ
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 qYZsD35Q1GvC for <netmod@ietfa.amsl.com>; Fri, 27 Sep 2019 03:40:08 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D5B712001E for <netmod@ietf.org>; Fri, 27 Sep 2019 03:40:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6902; q=dns/txt; s=iport; t=1569580808; x=1570790408; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=yThZ9seVa7eQDcnwOQPBd9Mt4j0H+vGjnxiWtQS15K4=; b=Otm9l4X6khnYsgZ3mv511vHGwHVSVoHezSDsaRxPHm+Od27qA6TCmqq/ CpDTcHv1ZCBLqBuel9KtOAIPEfeoWd1SpT0CkcuNcP2HauQsyQVvax5X8 6WUzfM3rOFR8TNsM06qw3VHu5E/TUXpNB+2/razZmc+kRDb9x06piHEJN s=;
IronPort-PHdr: 9a23:b6av5xMFLt16jy7hzpgl6mtXPHoupqn0MwgJ65Eul7NJdOG58o//OFDEu60/l0fHCIPc7f8My/HbtaztQyQh2d6AqzhDFf4ETBoZkYMTlg0kDtSCDBjhM//ucys8NM9DT1RiuXq8NBsdFQ==
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AOAAB85o1d/5hdJa1jAxoBAQEBAQIBAQEBDAIBAQEBgVQEAQEBAQsBgUpQA21WIAQLKgqEGINHA4pYglyXdoEugSQDVAkBAQEMAQEYCwoCAQGBTIIvRQIXgyAjNQgOAgMJAQEEAQEBAgEFBG2FLQyFSwEBAQMBAQEQEREMAQEsCwELAgICAQYCEAEEAQEBAgIfBwICAhkMCxUFAwgCBAENBQgagwGBagMODwECDJFdkGECgTiIYXOBMoJ9AQEFhRcYghcDBgWBBygBjAsYgUA/gRFGgkw+gmEBAYFLGBUKJoJEMoImjHOCaZ0+CoIilSaCN4dMjzGDQIphlCiEdgIEAgQFAg4BAQWBUwE2KoEucBU7gmxQEBSBTjgbgx8zhGGFP3SBKYx3AYEiAQE
X-IronPort-AV: E=Sophos;i="5.64,555,1559520000"; d="scan'208";a="635038037"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 27 Sep 2019 10:40:05 +0000
Received: from xch-rcd-011.cisco.com (xch-rcd-011.cisco.com [173.37.102.21]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id x8RAe3hv015560 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 27 Sep 2019 10:40:04 GMT
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-RCD-011.cisco.com (173.37.102.21) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 27 Sep 2019 05:40:03 -0500
Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 27 Sep 2019 05:40:01 -0500
Received: from NAM01-SN1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 27 Sep 2019 05:40:01 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=I1qZcTmi3ikNWTLE3Wan0Dx0X6GGoLan+DBsP0YZp6JXAVZ7BnESrHLmuf6sJX2yacE+jvkekNOcMC3PwqTtRHLjhiJk6zCJ7tuCo7/yAxyvKH/rxbTGU2xvWz7T817ddtu5Y0/YtIvy6AmHLR3sU5BWl4n14t38Um5OYnP8Cl+myxO6jvgdyy1pyB34h8Ptj1JonD00T46BTwwoxefdJ0on9qbyO+l/qcjXdHhJ+n+fkuK/5VYfeccpVRcaeU/xKARouQxDyp5b+qFEs9y66mK8ztI/13sCMGmJSCri6Wz248pWj17DoUQc9+mS4wzz33lqOhZ9ifHPAe6t9w7JRA==
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=yThZ9seVa7eQDcnwOQPBd9Mt4j0H+vGjnxiWtQS15K4=; b=HdZZlK9es4D3sgFso6hjNqXhfjCOiVY5FgRsKGh0Mqf19oX84AcBHZPtRZQ4vn85tXemcRvakCP/ABWKcf08loi2cY749Mli4ccKY8/nerYJ0/O7Ld7r6PSDZRaAQQkMRgKxCVkLDLhfO9KIfEYPCcDFsUeXO2+ynTCKdMdGTjP3+5ZsyqnxuVbWW69aja/QslIwKA7Cu47zm+mJpweb6Pvmu5SkqeC1GCXq++a+NzDcWTO03Sux2O75LrwMw4Nh7RZoeJu5pf3ER/nLzU+TCmIcIHMCQqHwNV+8pIqfBtooX92oTylq++4gXsJe+eAeU6jOy0CwtlcP1MN/i/jYtA==
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=yThZ9seVa7eQDcnwOQPBd9Mt4j0H+vGjnxiWtQS15K4=; b=g1rS5zEQ9GZInWvjcIE/fno+i6l0h5U0QV4BTBUWrhrFZaHi+ewmZaXiKiZwHKsMnJ9lKMVzahScyrJupWra5yTiqqaj3p55w3aeG90fGHz0K22zt5liwzZwrx4v1sYPSAcg/BF9JZ/xQqNSqI+C0UxIECOrgZqrhR6Cl9LzJlc=
Received: from MN2PR11MB4366.namprd11.prod.outlook.com (52.135.38.209) by MN2PR11MB3872.namprd11.prod.outlook.com (10.255.180.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2305.17; Fri, 27 Sep 2019 10:40:00 +0000
Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::cca:41bd:b0bb:c549]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::cca:41bd:b0bb:c549%2]) with mapi id 15.20.2305.017; Fri, 27 Sep 2019 10:40:00 +0000
From: "Rob Wilton (rwilton)" <rwilton@cisco.com>
To: "Schönwälder, Jürgen" <J.Schoenwaelder@jacobs-university.de>, Andy Bierman <andy@yumaworks.com>
CC: "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: [netmod] What's the problem with NMDA? was Re: 答复: 答复: Please clarify implementation about ‘when’
Thread-Index: AQHVdJIYDpQE2kJ+bEi4w1hDPZjYjKc+SSEAgAEDnIA=
Date: Fri, 27 Sep 2019 10:40:00 +0000
Message-ID: <MN2PR11MB4366886642F8F9693F0A22F2B5810@MN2PR11MB4366.namprd11.prod.outlook.com>
References: <87h84z4kmw.fsf@nic.cz> <20190926.085644.1268671875357328723.mbj@tail-f.com> <9bc06f9f3f1c87c79ccce4e1c4d40755c804875a.camel@nic.cz> <20190926.094526.272771637371098799.mbj@tail-f.com> <MN2PR11MB4366078636D6030398489551B5860@MN2PR11MB4366.namprd11.prod.outlook.com> <CABCOCHQzmDjH+7wqFmrSsnaD0T_Q1LPsDi0yuY9Ow2gSvef4SA@mail.gmail.com> <01c701d57485$400d8d40$4001a8c0@gateway.2wire.net> <CABCOCHRse2RJkoQ1r6pf+F4qP8MUn+4ypBY3M5zH+0QWoqBpuQ@mail.gmail.com> <20190926183514.6jxnybluwdubrzvy@anna.jacobs.jacobs-university.de>
In-Reply-To: <20190926183514.6jxnybluwdubrzvy@anna.jacobs.jacobs-university.de>
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.37]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: d867ef5e-f0e1-48a1-3331-08d743370c63
x-ms-traffictypediagnostic: MN2PR11MB3872:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: <MN2PR11MB3872891A6AC97BFD7066EB03B5810@MN2PR11MB3872.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0173C6D4D5
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(366004)(396003)(346002)(376002)(136003)(13464003)(189003)(199004)(86362001)(5660300002)(6506007)(71200400001)(99286004)(71190400001)(7696005)(66066001)(446003)(26005)(486006)(14444005)(478600001)(256004)(14454004)(53546011)(52536014)(66446008)(186003)(64756008)(102836004)(66946007)(11346002)(476003)(25786009)(305945005)(76176011)(966005)(66476007)(8936002)(74316002)(76116006)(7736002)(81166006)(6436002)(33656002)(66556008)(224303003)(3846002)(110136005)(316002)(6246003)(229853002)(81156014)(4326008)(6116002)(66574012)(2906002)(9686003)(6306002)(55016002); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3872; 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: Z5/jTL+qRvDxsJhCqkqUXpGngmYtJYkF2v5AxZNs9tg01X4E4a5JNQtdPORSsDsPUb/rJoSyRBUFclOX5v6MwEUu6dD5FKItE7oQFj+4bDyPtlxhW655hAyIbzRamTtaewfpbEvdL5xkfjOxhj2+NmQ0s/OMNP+cZBh9bPJ70Rz/Qe2JHY30PQ78u2EH5230sP4FFk0DkB1rnMThtZC3yFIB0mWSA2N5sJFvQgGPCQf9MpGEspuwkBZ37fSV00UL9VLskBS+XxP32viJiep1TGSfnsNRUa66t1dObtwHNJ8PVoxl0iefJA9QWaViQGkGAOEdnYBrLCfjX6J8f9XVJrjfavNPY+2kRWpw1Ygk2VMiQ/5RNDInaA0CaZR2/p5reKrTPxceYDrRZr3UD90q1zb53BOZwEMGQ1c96IA5EM9sXTeF6l1MMHNRan2S1ogfuilfStbih4UwwZictNEgrA==
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: d867ef5e-f0e1-48a1-3331-08d743370c63
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Sep 2019 10:40:00.5455 (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: ab4XnVYImBVqKQGsPHqJZb5zaLEPDXTkOAHyhhPGMcPG01RUWHRhzXQayKeGHDUULS37ejMPhBu5WFCawXjDkg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3872
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.21, xch-rcd-011.cisco.com
X-Outbound-Node: rcdn-core-1.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/D4yS1secFhv-69h_Tdt9OLH_8Jg>
Subject: Re: [netmod] What's the problem with NMDA? was Re: 答复: 答复: Please clarify implementation about ‘when’
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: Fri, 27 Sep 2019 10:40:10 -0000

Hi,

> -----Original Message-----
> From: netmod <netmod-bounces@ietf.org> On Behalf Of Schönwälder, Jürgen
> Sent: 26 September 2019 19:35
> To: Andy Bierman <andy@yumaworks.com>
> Cc: netmod@ietf.org
> Subject: Re: [netmod] What's the problem with NMDA? was Re: 答复: 答复:
> Please clarify implementation about ‘when’
> 
> On Thu, Sep 26, 2019 at 10:44:01AM -0700, Andy Bierman wrote:
> 
> > The IETF has completely punted the problem of converting data for a
> > configuration datastore to the schema tree for <operational>.
> 
> I am not sure. The <operational> model consists of the applied
> configuration plus any config false extras. NMDA simplifies things since
> there is now a single tree structure instead of two if you have to handle
> models where applied configuration can be different than intended config.
> If I configure /foo/bar in <running>, I can check /foo/bar in
> <operational> whether it exists and matches what I configured.
> 
> > Deviations may be different.  A leaf may be string in 1 tree and
> > decimal64 in the other. There is an incorrect assumption that software
> > developers will deal with these corner-cases (correctly and
> > consistently).
> 
> Not really true for applied config. And with non NMDA, there is no
> guarantee either that /foo/bar and /foo-state/bar use the same type and
> semantics.

Indeed.  For non-NMDA, even if /foo/bar and /foo-state/bar are the same type in the published model, there is no guarantee that a server won't deviate the /foo-state/bar leaf to change its type to differ from /foo/bar, and this is allowed.

But NMDA is aiming to be better than this.  One of the fundamental aims is that the config and operational values should be comparable, on the same relative datastore path and have the same type.

That is why RFC 8342 does not allow a server to change the type of a data node in operational, they are only allowed to remove it to indicate that it is not supported.

RFC 8342, section 5.3 The Operational State Datastore(operational):

   The datastore schema for <operational> MUST be a superset of the
   combined datastore schema used in all configuration datastores,
   except that configuration data nodes supported in a configuration
   datastore MAY be omitted from <operational> if a server is not able
   to accurately report them.

The intention here is:
 - If a server does a deviate "add|replace|delete" deviation on a config data node then that same deviation MUST be applied to all datastores that contain that data node in their schema (or otherwise operational cannot be a superset).
 - A server MAY have operational datastore specific deviate "not-supported" deviations.  The purpose of this is meant to help migration, ideally servers would not have these deviations.

Hence, a client/server can construct a single "superset" schema for the device, and then the schema for each individual datastore must be a subset of that "superset" schema (with the added requirement that there is only a single schema for all conventional datastores).

I appreciate that the new YANG library structurally allows invalid schemas to be defined, but then so does the old YANG library as well.  E.g. there is nothing in the old YANG library structure to prevent a server from reporting that it implements two different revisions of the same YANG 1.1 module.

Thanks,
Rob


> 
> > The other big problem is an untested NMDA transition strategy that is
> > not well understood by vendors.
> > Should non-NMDA (/foo-state) be visible to <get-data> or just <get>?
> 
> Perhaps there is more explanation necessary. The idea here is that an NMDA
> client should not bother to search for /foo-state, it should send a <get>
> for /foo/state in operational.
> 
> Yes, NMDA requires updates to clients. Whether these are visible or in
> which form they are visible to application logic likely depends on the
> client design. But yes, NMDA is not for free for clients. But once you
> have updated, we believe NMDA actually makes things simpler and more
> consistent.
> 
> > Using the YANG library to separate the modules relies on the
> > assumption that the client is capable of managing each datastore
> > independently (instead of
> > 1 schema tree per server).
> 
> Yes, YANG library can express pretty complex server model organizations.
> This does not mean that all server have to use server model organizations.
> I assume that also many clients will not be interested to understand the
> entire server model, they likely want to check the existance of only those
> pieces that they care about.
> 
> /js
> 
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod