Re: [Netconf] Draft Charter Proposal for NETCONF WG

["Susan Hares" <[e-mail]>]

Robert: 

Thank you for your response.   It was very helpful.  

Sue Hares 

-----Original Message-----
From: Robert Wilton [mailto:[e-mail]] 
Sent: Saturday, March 11, 2017 4:40 PM
To: Susan Hares; 'Netconf'
Subject: Re: [Netconf] Draft Charter Proposal for NETCONF WG

Hi Sue,


On 11/03/2017 13:29, Susan Hares wrote:
> Robert:
>
> Pulling your comment to the front for ease of reference.  You stated:
>   
> - YANG is the schema for that data.
> - Datastores are really just views on data, bound to the schema and 
> the data life cycle
> - Protocols are mechanism to access and modify that data, aided by the 
> schema & datastores.
>
> Can you explain what you mean by "bound to the schema" and "data life 
> cycle"?
By "bound to the schema", I mean nodes marked as "config: true" in YANG
exist in the schema associated with configuration datastores, but nodes
marked as "config: false" don't exist in the schema associated with
configuration datastores.  The operational state datastore contains both all
nodes defined in the YANG modules (both config: true and config: false).

Likewise, if I2RS defined an "i2rs:ephemeral" extension to YANG, then that
statement would help indicate which schema nodes are associated with the
I2RS datastore(s).

By "data life cycle", I mean that:
  - the running configuration datastore (basically) represents the
configuration sent to the device by the operators (via standard
NETCONF/RESTCONF mechanisms).  For various reasons nodes that exist in the
datatree in the running datastore might not exist in the other datastores
(e.g. inactive config, missing hardware, changed by dynamic configuration).
  - the intended datastore is basically running configuration with inactive
config removed and template expansion performed.  It is the intended
datastore where validation occurs.
  - the dynamic datastore(s) contain the configuration that has been
programmed by dynamic protocols (such as I2RS).
  - the operational state datastore contains the actual current operational
values used by the device.  There are several reasons why the data nodes in
this datastore may not match those in running (including, but not limited
to: time delay in acting on the intended configuration, missing hardware,
system controlled resources, configuration that was learned via a dynamic
datastore, system failures that mean that the operational value doesn't
match the desired configuration).

So, in short I mean the existence and value of a given data node may differ
between the different datastores.

>
> My understanding from the revised datastores draft was that control 
> plane datastores are:
>
> 1) form a place in which to mount modules
I think that mount can logically apply in other datastores as well.

>   
> 2) can have global characteristics [E.g. I2RS control plane datastore 
> is ephemeral]
Yes, this is fine.

> 3) have their own validation rules
Yes, this should be OK.

> 4) can be tracked by meta-data when mixed with other datastores for 
> installation - which the applied datastore tracks.
Yes.  Really, it is the operational state datastore that tracks this, and
the applied datastore just represented a view onto the operational state
datastore.  I.e. it was defined as the subset of operational that have
origin=static or origin=dynamic.  The datastore draft diagram showing
intended and control plane datatstores feeding into the applied datastore
and then operational-state datastore is a bit misleading.  We are trying to
simplify this diagram to make it clearer.

>   
> 5) protocols are mechanisms to access/modify data - aided by schema 
> and datastores, but the protocols (NETCONF and RESTCONF) may need 
> augmentation to support other datastores (E.g. "get data 
> <datatstore>")
Yes, this is right.

Thanks,
Rob


>   
>
> Sue
>
> -----Original Message-----
> From: Netconf [mailto:[e-mail]] On Behalf Of Robert 
> Wilton
> Sent: Thursday, March 9, 2017 10:29 AM
> To: t.petch; 'Netconf'
> Subject: Re: [Netconf] Draft Charter Proposal for NETCONF WG
>
> Hi Tom,
>
>
> On 09/03/2017 12:12, t.petch wrote:
>> ----- Original Message -----
>> From: "Robert Wilton" <[e-mail]>
>> Sent: Friday, March 03, 2017 5:41 PM
>>
>>> On 03/03/2017 17:18, t.petch wrote:
>>>> ----- Original Message -----
>>>> From: "Mehmet Ersue" <[e-mail]>
>>>> Sent: Friday, March 03, 2017 2:33 PM
>>>>
>>>>>> Back to your question, it seems obvious to me that YANG and the
>> XML
>>>>> encoding rules naturally belong to NETMOD, the 'NETCONF protocol
>>>> details
>>>>> that NETCONF
>>>>>> did not define' naturally belong to NETCONF.
>>>>> Basically it is our aim to make the YANG language specification
>>>> generally
>>>>> applicable to all protocols and to put protocol-specific details
>> into
>>>> the
>>>>> protocol specifications.
>>>> See my response to Juergen; I agree with you but I define XML as 
>>>> not being a protocol and so XML would remain; and I think that YANG 
>>>> will have to say something about operations on the data it defines, 
>>>> just
>> that
>>>> they are defined as an abstract 'create', 'delete' etc and not as
>> the
>>>> set that NETCONF currently offers.
>>> FWIW, this is the block
>>> "      Common protocol abstraction
>>> (that all YANG protocols should conform to). "
>>>
>>> That I was referring to in the diagram that I gave previously,
>> although
>>> I was suggesting that should belong in NETCONF WG rather than in YANG.
>> Robert
>>
>> It has taken me a while to work out what you mean but now I have, I 
>> disagree!
>>
>> You seem to place data(stores) at the heart of things, the root from 
>> which all else flows.  I think that this can work with application 
>> software in a stable, secure, delay-less environment where nothing 
>> ever goes wrong (a mobile phone app perhaps!).
> Yes, I definitely want to place accurate and meaningful data at the 
> heart of it.
>
> As I see it:
> - YANG is the schema for that data.
> - Datastores are really just views on data, bound to the schema and 
> the data life cycle
> - Protocols are mechanism to access and modify that data, aided by the 
> schema & datastores.
>
> I really hope that the solution that we are constructing will work 
> well for systems that have real delays, unreliable communications, and 
> potentially buggy software.  Certainly, that is my goal ... Some of 
> this will need protocol assistance.
>
>> Network management is different;  the failing network is both the 
>> subject under consideration and an integral part of the solution.  
>> The operator has to use the failing network to find out what is 
>> failing and what might be done about it and then use the failing 
>> network to convey changes to the failing component of the network.  
>> SNMP recognised this but I am not sure the NETCONF/YANG do - after 
>> all, their focus is on configuration, before things start going wrong.
> I don't know the history, but my perception is that NETCONF/YANG was 
> focused on config because that is the part of SNMP that failed to gain 
> traction in the industry.  As NETCONF/YANG gains traction, it seems 
> reasonable to want to fix the operational state aspect of it that 
> seems somewhat incomplete today.
>
>> I see revised-datastores as an attempt to fix this but one that will 
>> fail, in the sense that it cannot go far enough; what may be needed 
>> is a paradigm shift in Computer Science so a server can say that the 
>> model it has been given cannot reflect reality but here is a better 
>> one freshly created for the client to use!
> So, I think that that issue that you are raising here is that a device 
> might not be able to accurately populate the schema being used for the 
> operational state datastore.  The latest (unpublished) datastores 
> draft states that even all values (including defaults) are returned in 
> the operational state datastore.  I.e. everything is explicit, meaning 
> that if a device cannot return the correct value for a node then it 
> has the choice of returning no value at all.
>
> In terms of dynamic schema, devices can already define their own 
> custom schema and augmentations that can carry any extra vendor/device 
> specific data that cannot be readily mapped back into the standard 
> schema.  The problem here is that these schema are non standard 
> (between vendors and/or
> devices) and hence much harder for automated clients to use.  I think 
> that there is also a scope question of these additional vendor schema, 
> given that a lot of the data is likely to be verbose, possibly 
> expensive to obtain, and perhaps more diagnostics orientated.
>
>> I don't see that happening just yet so revised-datastores will have 
>> to do but I think it wrong to make that central - it will not be 
>> close enough to reality.
> It will be central in the sense that YANG models will either be built 
> assuming that it exists, or that it doesn't.  I don't think that you 
> can really have well constructed, fully useful, YANG models where the 
> operational state datastore is optional.
>
> I don't think that the datastores draft is going to be a silver bullet 
> that solves all problems, but if the solution gains traction then I do 
> think that it will give a step improvement to making it easier to 
> manage network devices in an automated and robust way.
>
> Regards,
> Rob
>
>
>> Tom Petch
>>
>>> Rob
>>>
>>>> Tom Petch
>>>>
>>>>> Mehmet
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- 
>>>>>> university.de]
>>>>>> Sent: Friday, March 3, 2017 2:35 PM
>>>> <snip>
>>>>
>>>> _______________________________________________
>>>> Netconf mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/netconf
>>>> .
>>>>
>> .
>>
> _______________________________________________
> Netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf
>
> .
>