Re: [netmod] WG adoption poll draft-bjorklund-netmod-rfc7227bis-00

Ladislav Lhotka <lhotka@nic.cz> Fri, 22 September 2017 12:01 UTC

Return-Path: <lhotka@nic.cz>
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 A643C1342D1 for <netmod@ietfa.amsl.com>; Fri, 22 Sep 2017 05:01:14 -0700 (PDT)
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] autolearn=ham autolearn_force=no
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 5z2tgxwRU8p1 for <netmod@ietfa.amsl.com>; Fri, 22 Sep 2017 05:01:11 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id B5847133344 for <netmod@ietf.org>; Fri, 22 Sep 2017 05:01:10 -0700 (PDT)
Received: by trail.lhotka.name (Postfix, from userid 109) id 95B3E1820E77; Fri, 22 Sep 2017 14:00:24 +0200 (CEST)
Received: from localhost (unknown [195.113.220.126]) by trail.lhotka.name (Postfix) with ESMTPSA id C29B81820E71; Fri, 22 Sep 2017 14:00:20 +0200 (CEST)
From: Ladislav Lhotka <lhotka@nic.cz>
To: Robert Wilton <rwilton@cisco.com>, netmod@ietf.org
In-Reply-To: <abda4c73-c8ba-abf5-2b08-f52b5873f02b@cisco.com>
References: <393d3f20-98e3-b4de-e2d7-d627de59ac1f@labn.net> <1505814417.5445.14.camel@nic.cz> <20170919.115915.1668734288988659917.mbj@tail-f.com> <87shfistam.fsf@nic.cz> <75221540-d587-cd90-60ab-7cf6a8ff5cd4@cisco.com> <1505830045.5445.47.camel@nic.cz> <4ec007bc-6eb6-38f9-562e-ce9d0b4e1c00@cisco.com> <87mv5p783v.fsf@nic.cz> <9e3e2d36-f99e-aa9c-844a-d61b3ca20213@cisco.com> <1506006652.6428.57.camel@nic.cz> <abda4c73-c8ba-abf5-2b08-f52b5873f02b@cisco.com>
Mail-Followup-To: Robert Wilton <rwilton@cisco.com>, netmod@ietf.org
Date: Fri, 22 Sep 2017 14:01:46 +0200
Message-ID: <87efqzdjrp.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/c0iVYyHaM9V9pfoZ4CRKXVPNEwk>
Subject: Re: [netmod] WG adoption poll draft-bjorklund-netmod-rfc7227bis-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
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, 22 Sep 2017 12:01:15 -0000

Robert Wilton <rwilton@cisco.com> writes:

> On 21/09/2017 16:10, Ladislav Lhotka wrote:
>> Robert Wilton píše v Čt 21. 09. 2017 v 10:38 +0100:
>>> On 20/09/2017 15:33, Ladislav Lhotka wrote:
>>>> Robert Wilton <rwilton@cisco.com> writes:
>>>>
>>>>> On 19/09/2017 15:07, Ladislav Lhotka wrote:
>>>>>> Robert Wilton píše v Út 19. 09. 2017 v 14:49 +0100:
>>>>>>> Hi Lada,
>>>>>>>
>>>>>>>
>>>>>>> On 19/09/2017 14:37, Ladislav Lhotka wrote:
>>>>>>>> Martin Bjorklund <mbj@tail-f.com> writes:
>>>>>>>>
>>>>>>>>> Ladislav Lhotka <lhotka@nic.cz> wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> I support the adoption but I propose two conceptual changes:
>>>>>>>>>>
>>>>>>>>>> 1. Introduce a new module name and namespace so that it is not
>>>>>>>>>> necessary to carry along the deprecated baggage. If readability
>>>>>>>>>> is
>>>>>>>>>> the primary concern, this is IMO the way to go. Instead of
>>>>>>>>>> "ietf-ip-2", I'd suggest something like "ietf- ip-nmda".
>>>>>>>>>>
>>>>>>>>>> 2. Avoid obsoleting RFC 7277. I believe the old modules may
>>>>>>>>>> continue
>>>>>>>>>> to be used
>>>>>>>>>> in areas where NMDA is an overkill, such as open source home
>>>>>>>>>> routers.
>>>>>>>>> Why wouldn't NMDA be appropriate in an open source home
>>>>>>>>> router?  Note
>>>>>>>>> that the new model really just have a single tree instead of two
>>>>>>>>> trees, so the data that needs to be instrumented is more or less
>>>>>>>>> the
>>>>>>>>> same.
>>>>>>>> It is quite likely that some parts of the data models will be
>>>>>>>> implemented only as configuration but not state data. In the "old
>>>>>>>> style"
>>>>>>>> modules it is easy to add a deviation for the node(s) under -state
>>>>>>>> but
>>>>>>>> in NMDA style this is not possible because we only have one node.
>>>>>>> The new YANG library allows different sets of modules to be available
>>>>>>> for <conventional> datastores vs <operational>.   The operational
>>>>>>> datastore can also have different features supported and different
>>>>>>> deviations vs the conventional datastores.
>>>>>> OK, I missed the 7895bis draft, sorry. Then there could be differences
>>>>>> in
>>>>>> mandatory/optional (e.g. a node is optional in configuration but
>>>>>> mandatory in
>>>>>> state data) or the data type of a leaf can differ. How can these be
>>>>>> handled?
>>>>> If the data type of the leaf can differ, then normally this should be
>>>>> modeled as two separate leaves.  Do you have a concrete example of
>>>>> this?
>>>> So, for example, duplex and duplex-state? And <operational> will
>>>> have both as siblings?
>>> Here I presume you are thinking that the configurable value for duplex
>>> is "full/half/auto", but the operational value is "full/half"?
>>>
>>> The solution here is really to model auto-negotiation on/off as a
>>> separate leaf (which also more closely reflects the actual behaviour of
>>> the auto-negotiation protocol).  Then for duplex both the space for both
>>> the configured and operational leaves are the same, i.e. both taking
>>> "full/half", and hence only a single leaf is required to model both the
>>> optional configured value and the operational value.
>> Yes, this sounds reasonable. Here also the config value should then be optional
>> while the state value mandatory.

> I think that this would mean that lots of "config false" leaves should 
> be marked mandatory.  But looking at the YANG models going through IETF 
> standardization that doesn't seem to be the case.

Many of them have defaults that effectively mean that the leaves have to
be implemented. Otherwise the guarantees provided by the data model are
really weaker - there is no way to tell whether a given server will send
a parameter or not.

>
> Perhaps a very simple device doesn't have the capability to report 
> duplexity because it is always full duplex, hence mandatory seems less

Then we have features and/or deviations to account for this.

> useful.  Or a device might be able to report duplexicty but not at that 
> instant in time (e.g. perhaps the optics module is missing)?  It seems 
> more natural for operational to say that if you don't know something 
> then don't return it.

Of course, transient effects need to be considered, and perhaps
statistics are also a bit special. But, for example, if an NM
application isn't able to learn actual router-id, it may be stuck.

>
> So, I wouldn't support marking this field as being mandatory in 
> <operational> regardless of model structure.
>
>>> A concrete example of the Ethernet interface YANG structured this way is @
>>> https://github.com/8023YangDesignTeam/EthernetYang/blob/nmda/standard/ieee/802
>>> .3/draft/ieee802-ethernet-interface.yang
>>>
>>>
>>>
>>>>> If some data is mandatory in config, but not necessarily mandatory in
>>>>> <operational> then normally it can be marked as mandatory true, since
>>>>> optional is allowed to violate this constraint if necessary, but
>>>>> implementations would generally be expected to conform to the constraint
>>>>> if possible.
>>>>>
>>>>> For the reverse case, we can't express that.  I think that you would
>>>>> have to leave out the "mandatory: true" constraint.  Again, can you
>>>>> provide a concrete example of this please?  That makes it a bit easier
>>>>> to reason about.
>>>> This should be quite typical: a config leaf is optional and if it is not
>>>> configured, the system sets it to some value (as in the case of
>>>> router-id). But in state data it is mandatory so that the client can see
>>>> what the system chose.
>>> Yes, I agree that this scenario is very likely, but I think that the
>>> solution here is just to not mark the leaf as mandatory.
>> But this makes the schema weaker, and implementors may think it needn't be
>> implemented.
> I think that implementations SHOULD implement everything in the schema 
> and use deviations if they don't.

This is not what YANG says - the state data tree is valid without a parameter
that is optional.

>
>>
>>> It is interesting to consider what "mandatory" exactly means in the
>>> <operational> datastore.  Given that the mandatory constraint may be
>> Yes, the semantics in the context of NM protocols is different from that of
>> configuration datastores. But in the context of document (data tree) validation
>> it is the same: the instance has to be present for a data tree to be valid.
> Yes, the NMDA architecture states that the <operational> tree may not be 
> valid.  There are several reasons why <operational> might not be valid, 
> a few that I can think of are:
> (1) The system is constant changing, and the device isn't able to 
> provide a consistent snapshot across the entire device (e.g. on a 
> distribute platform the FIBs on the LC may lag behind the RIB on the RP).
> (2) The system might be in the middle of a config change at the time 
> that <operational> is read meaning that either the device would have to 
> prevent <operational> from being read until the config change had 
> completed, or alternatively accept that it may provide an inconsistent view.
> (3) There may be bugs or errors in the implementation.  They may have 
> been a failure to program the hardware that means the state between 
> different parts of the system is not consistent.
>
>>
>>> violated in <operational>, then my interpretation is that it means that
>>> a correct implementation SHOULD always return a mandatory node (if it is
>>> in scope).  But a client has no way to force a device return this data
>>> (except perhaps shouting at the vendor :-), and so it seems that a
>>> robust client would need to be able to cope with the fact that the
>>> device is not behaving nicely and isn't returning the data regardless of
>>> any mandatory keyword specified in the schema.
>> I don't really share this view, it is IMO not much different from the situation
>> when a vendor fails to implement a config node. Either way, the implementation
>> doesn't conform to the data model.
> The difference is that a device can reject an invalid config.  A client 
> cannot reject an inconsistent state tree.  Perhaps it could choose to 
> ignore it, but I'm not sure that helps.  I think that the client 
> probably just has to cope with what is there.
>
>>
>> One of the benefits of a data model is that an application can offload
>> validation to an external tool, such as a generic YANG library, and then can
>> rely on data being valid so that the application's code needn't be cluttered
>> with all kinds of sanity checks.
> Yes, if there is data missing then I think that such a tool might need 
> to prune the operational tree provided to the application code, or 
> perhaps annotate the tree with additional metadata flags the 
> inconsistencies.
>
>>
>> I can imagine a tool collecting data from a number of devices that fails if a
>> mandatory state data are absent.
> I think that the tool needs a plan B.  E.g. perhaps if the interface is 
> admin-down then it doesn't matter whether or not the duplex setting has 
> been provided by the device.

Of course, but this is business as usual. The problem I am talking about
is an interface that is up and running but the server fails to provide
important data.

>
>>    
>>
>>> To further expand on this, a device is required to ensure that
>>> configuration datastores are valid, and hence all mandatory constraints
>>> are enforced, or a config change would be rejected, but I don't think
>>> that many devices are going to validate operational. They will just
>>> return the current state of the system back to the client, and let the
>>> client deal with any unexpected inconsistencies.
>> I could likewise expect the server to be prepared to deal with unexpected
>> inconsistencies in config data. The data model is a contract, so it should be
>> binding for both parties.
> But the server is allowed to just reject the change with an error. It 
> isn't possible to reject the response to a <get> request.

Either way, the NM application may fail, which defeats the purpose of
standardizing data models.

Lada

>
>>
>>> Also, what about all the regular config false nodes in the schema that
>>> are not marked as mandatory?  Is a device always required to return
>>> those leaves (if they are in scope)?  If a device is never going to
>> In terms of YANG, no.
> So, should a device deviate config false leaves that it will never return?
>
>>
>>> return those leaves then it should use a deviation to remove them, but
>>> is that actually required?
>>>
>>> Is seems that possibly the most useful use of mandatory in the context
>>> of operational is for something like an IP address/prefix length
>>> pairing, i.e. to indicate that the data really doesn't make any sense
>>> unless both address and prefix are provided.
>>>
>>> When the next version of YANG is specified, perhaps we should consider
>>> allowing an extra options to mandatory to that it only applies to the
>>> state datastores?  if so, we could add this to the YANG.Next issue tracker?
>> I believe the fundamental problem is that YANG was designed basically as a
>> document-oriented schema language, and NMDA tries to make the same schema work
>> for multiple different data trees. I am concerned this means a lot of complexity
>>   and CLRs that will render the next version unusable.
> OK.
>
> But I'm not convinced that this is really much of an issue in practice.  
> I've looked at converting quite a few YANG models either from an OC like 
> structure, or IETF split structure to a combined NMDA tree (* list 
> below).  In most cases, the models between config and state have been
> very closely aligned such that the config and state nodes are trivially 
> identical.  In the cases that they differ (e.g. boolean vs empty), or a 
> slight structure change, they have been pretty straight forward to 
> resolve.  When the operational structure really differs from the 
> configured structure then this can be represented using addition config 
> false nodes (when doing the conversion on the models below, I don't 
> recall having to add any extra config false leaves).
>
> * By a few YANG modules I mean IETF draft/standard YANG modules for: 
> interfaces, ip, routing, vrrp, rip, bgp, network, network-topology, te, 
> te-topology, mpls, mpls-ldp, mpls-static, rsvp, rsvp-te, te-device, 
> sr-topology, te-mpls, te-path-computation, te-service, transport services.
>
> Thanks,
> Rob
>
>
>>
>> Lada
>>
>>> So, in conclusion, I think that the NMDA modelling advice for mandatory
>>> on config true nodes might be to only use it when the node is mandatory
>>> in configuration datastores.
>>>
>>> If the WG isn't opposed, then I would suggested adding this to the NMDA FAQ.
>>>
>>> Thanks,
>>> Rob
>>>
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67