Re: [netmod] WGLC - Comparison of NMDA datastores - draft-ietf-netmod-nmda-diff-03

Schönwälder, Jürgen <J.Schoenwaelder@jacobs-university.de> Wed, 26 February 2020 08:55 UTC

Return-Path: <J.Schoenwaelder@jacobs-university.de>
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 063713A10E3; Wed, 26 Feb 2020 00:55:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jacobsuniversity.onmicrosoft.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 H253cAj6TvTn; Wed, 26 Feb 2020 00:54:59 -0800 (PST)
Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2068.outbound.protection.outlook.com [40.107.21.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 041C73A10E2; Wed, 26 Feb 2020 00:54:56 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ljdLGyDkp18gCXIp+DR4uheADK7co6Ep4/3DgC6/6x8yc493+/OggVEX3G+4fnAPAoKSbFai4LHIcJoqODSvkvVAS8xRrkLB0czlHRZ9iVdxTSR0tVNsidL8nivBLX4UgA+e+iBpSXESY1ae/YNUAHyOWf2vT5aLJudzzcNumoDhU+o/aSRnQT3Vwh6ryEoEdos5QRgy8L+jOTd/MKEd6En84CkeiXS8I/aj6qyK5nn9O0XkpmqkC3smjjaicgXxQ3nAWqh0NdUfqWokinc2nvFeHTrStgfRWRIDEpwyqZN666dFMFCDlYFmKrBJPChaJMYfy10I+nfeZePIUllvaQ==
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=Vin5CWlWVeB7fM2S3Pp1z/LDy67FvQu3DcoV9J1AYWE=; b=VOTWgvULaqZT+0kys+6p9xBmVKrecKCA51hsQk+S4wF3DUfYzgK0lNbAX6FjdtVeiORZE3y1ToKNRYkTXo66/al2s3eUglW8udgeC14Jlm37TaI9Ulacorz7tTs3aAjnwb5VlXPVFFBnTkFxEbQmgSwwhFoMon9s6gPLXFc3C9mMVPeoFmmT/AeLUyDApbJz+Gy7hlRGCRwTzLQKaddFsOEKVVLd/8C65fodcIWGHiUPV8Yu89lErK+4qXb0DYWVm4lArie8gYDSTpPjQdr7oJJFQczl8AbQJDoi4U/i3dQsAGzcM3OJy4PjEKWNMu+IyGe3yno9gRXkTEToen7UHw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=jacobs-university.de; dmarc=pass action=none header.from=jacobs-university.de; dkim=pass header.d=jacobs-university.de; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jacobsuniversity.onmicrosoft.com; s=selector2-jacobsuniversity-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Vin5CWlWVeB7fM2S3Pp1z/LDy67FvQu3DcoV9J1AYWE=; b=PajbJ/nhYlxBNuUAN6hLsfKuNyJjmSxyNAsqcKl5hPK+l0APQCkiRcGytwwKJvzj8DU53+33zEdB0cD61KJb9jBrV6MfkyYBWd0/a/d9lz19zcAcbwG0O32HO+k9hEpOaoOHgmDXTMr2U1qE5vWtvYyCsZfmVozYC3IhwO3d4YE=
Received: from DB6P190MB0312.EURP190.PROD.OUTLOOK.COM (10.165.140.31) by DB6P190MB0295.EURP190.PROD.OUTLOOK.COM (10.175.242.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2750.21; Wed, 26 Feb 2020 08:54:53 +0000
Received: from DB6P190MB0312.EURP190.PROD.OUTLOOK.COM ([fe80::2cda:e754:4835:c579]) by DB6P190MB0312.EURP190.PROD.OUTLOOK.COM ([fe80::2cda:e754:4835:c579%3]) with mapi id 15.20.2772.012; Wed, 26 Feb 2020 08:54:53 +0000
Received: from localhost (212.201.44.247) by FR2P281CA0010.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:a::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2750.18 via Frontend Transport; Wed, 26 Feb 2020 08:54:53 +0000
From: =?iso-8859-1?Q?Sch=F6nw=E4lder=2C_J=FCrgen?= <J.Schoenwaelder@jacobs-university.de>
To: Alexander Clemm <alex@futurewei.com>
CC: Joel Jaeggli <joelja@bogus.com>, "netmod-chairs@ietf.org" <netmod-chairs@ietf.org>, "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: [netmod] WGLC - Comparison of NMDA datastores - draft-ietf-netmod-nmda-diff-03
Thread-Index: AQHV5cpjTZuQg6TmkkSwH9n+2ZnT06giv7+AgAn+EQCAAHtsAA==
Date: Wed, 26 Feb 2020 08:54:53 +0000
Message-ID: <20200226085452.xcwtwpjun2qer64p@anna.jacobs.jacobs-university.de>
References: <687b863b-4d54-db67-e3af-b08588c85360@bogus.com> <20200219165727.ha6hhu5onoueznvw@anna.jacobs.jacobs-university.de> <MN2PR13MB330960834522F5BFD4012284DBEA0@MN2PR13MB3309.namprd13.prod.outlook.com>
In-Reply-To: <MN2PR13MB330960834522F5BFD4012284DBEA0@MN2PR13MB3309.namprd13.prod.outlook.com>
Reply-To: =?iso-8859-1?Q?Sch=F6nw=E4lder=2C_J=FCrgen?= <J.Schoenwaelder@jacobs-university.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-clientproxiedby: FR2P281CA0010.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:a::20) To DB6P190MB0312.EURP190.PROD.OUTLOOK.COM (2603:10a6:6:34::31)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=J.Schoenwaelder@jacobs-university.de;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [212.201.44.247]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 018e9f13-d7a1-4bcf-f573-08d7ba998bab
x-ms-traffictypediagnostic: DB6P190MB0295:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <DB6P190MB0295A96678611B8E29998963DEEA0@DB6P190MB0295.EURP190.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0325F6C77B
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39850400004)(396003)(376002)(346002)(136003)(366004)(189003)(199004)(2906002)(66574012)(786003)(316002)(26005)(478600001)(52116002)(6496006)(54906003)(53546011)(3450700001)(186003)(4326008)(1076003)(956004)(6916009)(8936002)(71200400001)(81156014)(81166006)(8676002)(6486002)(5660300002)(66446008)(66946007)(16526019)(66476007)(66556008)(86362001)(64756008); DIR:OUT; SFP:1101; SCL:1; SRVR:DB6P190MB0295; H:DB6P190MB0312.EURP190.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: jacobs-university.de does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: trRVI02vPiXYQM57x9wgo2s+zdX9nEwUxe5jhBr8t4bQDHBLqnkR4EET9p0o3W5Qbcz1U5dX8OekD9PlBw5CKN6Xk4cn9uTX71TKw5tkaF56Six52edzbYz7HeWwv6WmYgforGtOU9e9OUN6iWm+p1ol+pa+2Q3L5L5NNbuJrv2tNPUk8lsnuN5Uc3mAAOPsCrUwPjQkcmmc/Wh/zN61v9hEagcsrE9xX24ycBPll8MlPMRGFDrJLZifLjNrnDKYKO/VP2fDztdqCGA1Z0G/HOq7xRSdlpHgKfvII0Yp92xd7EnoTBT+Pj4Gn+LedgTaM3gzi2+8GuGGCBaMXcZccuD2bnA9LUzILV8chVyK7NHT0tn2pnL/+P2aI5MGrkPkY9CdaFWHBNk0rrpnEyNJAZ/9+nxJrUXbnHKlF9oCSz0dxHy3sFWR3APGn8N/7g8alXM0RgvWdoiuV53EveD3jckqkyA08teOnlSYKFpi9Dd6ss10vADV48vPMaO/exKIOjKWls1oIqAW+dPclPi+gg==
x-ms-exchange-antispam-messagedata: lO7xIYe8/W2wgZK4ZYr8ARL/a5V+7hPGfFg43+hYkuagifQtf5fapPpgPYIQlRR/5rokHhOr9QFJO8UNdyximMMZpynd6J2wf2fpAWAq97FuuyI8zqqV1f4hzUZzn48eIKk4RdYTZOBhw+T3Z5UlTA==
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <B9905F9F8F53364A9EE81815B2860FD1@EURP190.PROD.OUTLOOK.COM>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: jacobs-university.de
X-MS-Exchange-CrossTenant-Network-Message-Id: 018e9f13-d7a1-4bcf-f573-08d7ba998bab
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Feb 2020 08:54:53.3758 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: f78e973e-5c0b-4ab8-bbd7-9887c95a8ebd
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: e5ntk90W0V+g7xUZhSZbCoXPE+jwdb1lzFpFX9Y+Qp7cSm3qPNmRgtk87Zp3BL3bVrPp0h1p9acRTEPUzf1nZHzhRCwOzXZ/8O8PodgVN3A=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6P190MB0295
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/Ou5BcW1KF_56ICxfHpIXx0XuHRI>
Subject: Re: [netmod] WGLC - Comparison of NMDA datastores - draft-ietf-netmod-nmda-diff-03
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: Wed, 26 Feb 2020 08:55:03 -0000

On Wed, Feb 26, 2020 at 01:33:08AM +0000, Alexander Clemm wrote:
> Hi Juergen,
> 
> thank you for your comments!  Please find replies inline, <ALEX>
> 
> --- Alex
> 
> > -----Original Message-----
> > From: netmod <netmod-bounces@ietf.org> On Behalf Of Schönwälder, Jürgen
> > Sent: Wednesday, February 19, 2020 8:57 AM
> > To: Joel Jaeggli <joelja@bogus.com>
> > Cc: netmod-chairs@ietf.org; netmod@ietf.org
> > Subject: Re: [netmod] WGLC - Comparison of NMDA datastores - draft-ietf-
> > netmod-nmda-diff-03
> > 
> > Hi,
> > 
> > this is a good document that deserves to go forward. Some comments...
> > 
> > - In the introduction, you may want to mention that applied config
> >   often differs from config because applied config includes stuff that
> >   was learned or generated by the system (e.g., IP addresses obtained
> >   via DHCP or generated by the kernel itself). This applies to systems
> >   that otherwise implement NC or RC in a synchronous update manner,
> >   i.e., a difference between <intended> and <applied> is for many
> >   operational systems likely the normal situation and not an
> >   exceptional one.
> 
> <ALEX>  
> Agreed.  Adding the following text in the Introduction to bring this out clearer: " Likewise, during the course of operation, some data values may be learned or updated by the system itself over time, causing datastores to diverge. "
> </ALEX>

OK

> > - I do not understand this:
> > 
> >       [...]  (The filter dow not contain expressions that
> >       would match values data nodes, as this is not required by most use
> >       cases and would complicate the scheme, from implementation to
> >       dealing with race conditions.)
> > 
> >   Despite the wording nits, I fail to understand the race condition
> >   argument. It seems the filters are the same as we have them in other
> >   places and this is good and a strong argument by itself. Reusing
> >   concepts is a good thing. Just state that and remove potentially
> >   hand-waving arguments about race conditions created by filtering on
> >   values. (And subtree filters can filter out certain interfaces by
> >   matching the <name/> element.)
> 
> <ALEX>  What this meant to explain is that the filter simply defines which nodes are in and out of scope, independent of their actual value.  In other words, you would not be able to specify something like "have this be in scope, but only if its value is between 5 and 10".  This is to keep things simple; the race condition concerns if there are different speeds at which values propagate.  
> In order to simplify this, I suggest we simply remove the text in parantheses (which was meant to provide clarification, but seems to add confusion, hence best to simply strike.)  
> </ALEX>

If the filters work exactly the same way as they do elsewhere, then I
am happy and yes removing the text in parenthesis is good.

> > - I think you should import the term 'schema node' (and if necessary
> >   also other terms) from RFC 7950. Perhaps merge section 2+3 into a
> >   section Terminology that has the RFC2119 blurb and states that this
> >   specification uses the terminology defined in RFC 7950 and RFC 8342.
> > 
> 
> <ALEX>
> OK, we are merging 2+3 (both are very short anyway).  Putting the following sentence in lieu of the acronyms: This specification uses the terminology defined in [RFC7950] and [RFC8342].  For definitions of terms such as "datastore", "schema node", "<intended>",  or "origin", please refer to those RFCs.  
> </ALEX>

This works for me.

> > - Given that the applied configuration includes learned and system
> >   provided data, it may make a lot of sense to filter on origin so
> >   that learned or system generated config is not part of the
> >   comparison. I think this is really missing. Of course, one can
> >   filter the result to get rid of all 'learned' items but the whole
> >   point of the compare RPC is to avoid long responses that are not
> >   needed. The get-data operation defined in RFC 8526 has an origin
> >   filter that may be reused. (Perhaps it makes sense to align the
> >   parameters with RFC 8526 get-data even further.)
> 
> <ALEX>Hmm, what are you exactly suggesting here?  We could add a parameter to include (or exclude) data of a certain origin.  However, that would raise the possibility that some differences are not found whose cause is precisely that they have a different origin than anticipated (e.g., for which it was not clear that they could be learned, or that they would be preconfigured).  Hence not making changes just yet; could you explain your requirement/suggestion a little more?  
> </ALEX>

I believe that there will be quite large differences between say
<running> and <operational> due to learned applied config (think of
address mapping tables or forwarding table entries originating from
control plane protocols) and if I am not interested in this learned
state, I like to have a filter that allows me to express that I like
to have some of the learned data ignored. Similarly, I having a filter
to express that I like to have all config false leafs ignored seems
useful if I compare a configuration datastore with <operational>.
There are several useful filters in the definition of get-data [RFC
8526] and I feel we are missing several of them here.

Yes, there may be cases where I do not want to use some of the filters
but that does not justify that other use cases like comparing
<running> against <operational> are not well supported.

> > - Why do we need the 'no-matches' leaf? Why not simply return an empty
> >   'differences' container?
> > 
> <ALEX>
> I guess this is a design choice.  I guess we could return an empty container as well; the "no-matches" makes it more "explicit", and in terms of response size it does not make a difference.  Unless there is a strong preference, we would like to prefer to keep it.  (Or perhaps Andy wants to jump in?)
> </ALEX>

$ diff rfc7950.txt rfc7950.txt
$ echo $?
0

Good old tools tend to return an empty diff and not a special value if
there is no difference hence I found the design a bit surprising.
Perhaps there is a reason behind the design but then it is not obvious
to me.

> > - Nit
> > 
> >   OLD
> > 
> >    RPC request to compare <operational< (source of the comparison) with
> >    <intended>(target of the comparison):
> > 
> >   NEW
> > 
> >    RPC request to compare <operational> (source of the comparison) with
> >    <intended> (target of the comparison):
> 
> <ALEX> fixed the spacing 
> </ALEX>

OK
 
> > - I have not validated the examples.
> > 
> > - Section 7 talks about rejecting frequent requests. It may be useful
> >   to specify which error response is returned in this case so that
> >   coders implement the same behavior.
> > 
> <ALEX> We could add that.  Which one would be appropriate to return / what should be returned?  
> Should we simply return error-type "rpc", with error-tag "resource-denied"?   
> If we do that, should we also include error-info, specifying a time interval after which it would be "safe" to issue the next diff request?  
> </ALEX>

I don't have the answer but obviously it makes sense to clearly spell
out the error behavior. ;-)

> > - Perhaps the document should spell out how compare interacts with
> >   NACM. I kind of assume that NACM rules are applied before the
> >   content is compared, i.e., data that is not accessible won't get
> >   compared. Well, whatever the correct behavior is, I think this
> >   deserves to be spelled out.
> 
> <ALEX> Per RFC 8341, the same access control rules apply to all datastores subjected to NACM - presumably also to all datastores that can be subjected to nmda-diff.  From that perspective we didn't think it necessary to spell it out, but perhaps it should be.  
> How about adding the following at the end of the first paragraph of Section 4:
> "Any access control rules as configured by NACM [RFC 8341] are applied by the server before the comparison is performed, that is, only datastore schema nodes for which the client has read access are included in the comparison."  
> </ALEX>

OK
 
> > - I would probably have picked in ietf-interfaces example to avoid a
> >   reference to a work in progress but this does not really matter
> >   much.
> 
> <ALEX> That would have been possible as well.  We prefer sticking with this example (it's just an example, so non-normative) if acceptable since it generates less work, however, if there is insistence that we update, we will be happy to do so. 
>

As I said, this does not really matter much to me. (I would have
picked ietf-interfaces because it is stable and most likely widely
understood by pretty much everybody and it nicely can be used to
explain why <running> and <operational> differ in many different ways,
i.e., loopback addresses configured by the system, IP privacy
addresses created by the system, IP addresses obtained by DHCP, IP
addresses not in <operational> due to hardware not present.)

/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/>