Re: [netmod] <running> vs <intended>

[Robert Wilton <[e-mail]>]

On 28/09/2017 16:39, t.petch wrote:
> Robert
>
> I would like you to tweak the definition of running configuration
> datastore slightly.
>
> You say
>
> " The running configuration datastore (<running>) is a configuration
>    datastore that holds the complete current configuration
>    on the device"
>
> which I see as black and white, the terminology is <running>.
>
> But then you say
>
> "This datastore is commonly referred to
>    as "<running>".
>
> which I see as introducing wiggle room with the use of 'commonly' so I
> would like you to excise 'commonly' leaving
>
> NEW
> This datastore is referred to as "<running>".
Yes. fine with me.  We should also make the equivalent update for the 
other datastore definitions as well.

Thanks,
Rob

>
> Black and white.
>
> Tom Petch
>
> ----- Original Message -----
> From: "Robert Wilton" <[e-mail]>
> Sent: Thursday, September 28, 2017 10:37 AM
>> After comment from the other authors, an updated proposed description
>> for <running> is as follows:
>>
>> OLD:
>>
>> 4.3. The Running Configuration Datastore (<running>)
>>
>>    The running configuration datastore (<running>) holds the complete
>>    current configuration on the device. It may include inactive
>>    configuration or template-mechanism-oriented configuration that
>>    require further expansion.
>>
>>    If a device does not have a distinct <startup> and non-volatile is
>>    available, the device will typically use that non-volatile storage
> to
>>    allow <running> to persist across reboots.
>>
>> NEW:
>>
>> 4.1.3. The Running Configuration Datastore (<running>)
>>
>>    The running configuration datastore (<running>) is aconfiguration
>>    datastore that holds the complete current configuration
>>    on the device. It may include configuration that requires further
>>    transformation before it can be applied, e.g., inactive
>>    configuration, or template-mechanism-oriented configuration that
>>    needs further expansion. However, <running> MUST always be a 'valid
>>    configuration data tree' as defined in Section 8.1 of [RFC7950].
>>
>>    <running> MUST be supported if the device can be configured via
>>    conventional configuration datastores.
>>
>>    If a device does not have a distinct <startup> and non-volatile is
>>    available, the device will typically use that non-volatile storage
> to
>>    allow <running> to persist across reboots.
>>
>>
>> Given that the definition of <running> and <intended> are being
> updated,
>> I think that the definitions should similarly be updated. Hence I
> propose:
>>
>>
>> OLD:
>>    o running configuration datastore: A configuration datastore holding
>>    the current configuration of the device. It may include inactive
>>    configuration or template-mechanism-oriented configuration that
>>    require further expansion. This datastore is commonly referred to
>>    as "<running>".
>>
>> NEW (based on the new description of running above):
>>    o running configuration datastore: A configuration datastore holding
>>    the current configuration of the device. It may include
>>    configuration that requires furthertransformations before it can
>>    be applied. This datastore is commonly referred to
>>    as "<running>".
>>
>>
>>
>> OLD:
>>
>>    o intended configuration: Configuration that is intended to be used
>>    by the device. For example, intended configuration excludes any
>>    inactive configuration and it would include configuration produced
>>    through the expansion of templates.
>>
>>
>> NEW (based on the proposed updated description of intended):
>>
>>    o intended configuration: Configuration that is intended to be used
>>    by the device. It represents the configuration after all
>>    configuration transformations to <running> have been performed and
>>    is the configuration that the system attempts to apply.
>>
>>
>>
>> It may also be helpful if we define "configuration transformation", or
>> would that be better captured in the introduction text?
>>
>> A possible definition could be along the lines of:
>>
>>    configuration transformation: The addition, modification or removal
> of
>>    configuration between the <running> and <intended> datastores.
>>    Examples of configuration transformations include the removal of
>>    inactive configuration and the configuration produced through the
>>    expansion of templates.
>>
>> If I don't hear anything back, I'll take that as a tacit approval of
>> these proposed changes.
>>
>> Thanks,
>> Rob
>>
>>
>> On 22/09/2017 18:12, Robert Wilton wrote:
>>> Hi Tom,
>>>
>>>
>>> On 22/09/2017 17:34, t.petch wrote:
>>>> Robert
>>>>
>>>> I wonder if this says the opposite of what is intended
>>>>
>>>> - <running> holds the complete current configuration on the device.
>>> I agree.
>>>
>>>> - This could include inactiveconfiguration
>>> I agree.
>>>
>>>> - <running> must always be a 'valid configuration data tree' as
>>>> defined in Section 8.1 of [RFC7950].
>>> I agree.
>>>
>>>> Ergo, inactiveconfiguration must form part of a valid configuration
>>>> tree.
>>> Ergo, inactive configuration can form part of a valid configuration
>>> tree.
>>>
>>>> I thought the idea was that inactiveconfiguration was logically
> removed
>>>> before validation but this seems to state the opposite..
>>> I don't think that this is necessarily true. One choice is inactive
>>> configuration is removed before validation, but this isn't quite
> what
>>> I'm proposing. I'm proposing that the act of validation itself is
>>> refined (via an tbd inactive configuration draft) such that it
> ignores
>>> configuration nodes marked as inactive.
>>>
>>> Thanks,
>>> Rob
>>>
>>>> Tom Petch
>>>>
>>>> ----- Original Message -----
>>>> From: "Robert Wilton" <[e-mail]>
>>>> Sent: Friday, September 22, 2017 10:03 AM
>>>>
>>>>> Hi,
>>>>>
>>>>> Regarding whether <running> is always valid, the proposed
> modification
>>>>> to the draft is to add the following text to section 4.3 that
>>>> describes
>>>>> <running>:
>>>>>
>>>>> OLD:
>>>>>
>>>>> 4.3. The Running Configuration Datastore (<running>)
>>>>>
>>>>> The running configuration datastore (<running>) holds the complete
>>>>> current configuration on the device. It may include inactive
>>>>> configuration or template-mechanism-oriented configuration that
>>>>> require further expansion.
>>>>>
>>>>> If a device does not have a distinct <startup> and non-volatile is
>>>>> available, the device will typically use that non-volatile storage
>>>> to
>>>>> allow <running> to persist across reboots.
>>>>>
>>>>> NEW:
>>>>>
>>>>> 4.3. The Running Configuration Datastore (<running>)
>>>>>
>>>>> The running configuration datastore (<running>) holds the complete
>>>>> current configuration on the device. This could, for example,
>>>> include
>>>>> inactiveconfiguration or template-mechanism-oriented configuration
>>>>> thatrequires further expansion.However, <running> must always be a
>>>>> 'valid configuration data tree' as defined in Section 8.1 of
>>>> [RFC7950].
>>>>> If a device does not have a distinct <startup> and non-volatile is
>>>>> available, the device will typically use that non-volatile storage
>>>> to
>>>>> allow <running> to persist across reboots.
>>>>>
>>>>> END
>>>>>
>>>>>
>>>>> Then the intention is that if inactive or a templating solution is
>>>>> standardized then those drafts would update the validation rules
> in
>>>> RFC
>>>>> 7950 such that <running> is still valid. E.g. an inactive config
> draft
>>>>> would probably indicate that validation excludes all configuration
>>>> nodes
>>>>> that are marked as inactive.
>>>>>
>>>>> Does anyone have any comments?
>>>>>
>>>>> Do we also need to state that <startup> must always be a 'valid
>>>>> configuration data tree'?
>>>>>
>>>>> Thanks,
>>>>> Rob
>>>>>
>>>>>
>>>>> On 19/09/2017 16:22, Robert Wilton wrote:
>>>>>> On 19/09/2017 10:55, Martin Bjorklund wrote:
>>>>>>> Robert Wilton <[e-mail]> wrote:
>>>>>>>> On 18/09/2017 19:25, Andy Bierman wrote:
>>>>>>>>> On Mon, Sep 18, 2017 at 11:07 AM, Martin Bjorklund
>>>> <[e-mail]
>>>>>>>>> <mailto:[e-mail]>> wrote:
>>>>>>>>>
>>>>>>>>> Juergen Schoenwaelder <[e-mail]
>>>>>>>>> <mailto:[e-mail]>> wrote:
>>>>>>>>>> On Mon, Sep 18, 2017 at 05:17:46PM +0100, Robert Wilton
> wrote:
>>>>>>>>>>>> No. I do not agree that the MUST in RFC 7950 can be
>>>>>>>>> removed.
>>>>>>>>>>>> I do not agree the architecture should update YANG at all.
>>>>>>>>>>> OK.
>>>>>>>>>> I am with Andy here. <running> has always had the
>>>>>>>>> requirement to be
>>>>>>>>>> valid and we are not supposed to change that. Mechanisms for
>>>>>>>>> inactive
>>>>>>>>>> configuration or templating must be designed to be backwards
>>>>>>>>> compatible
>>>>>>>>>> I think.
>>>>>>>>> Ok. If we keep the requirement that <running> in itself must
> be
>>>>>>>>> valid, it just restricts the usefulness/expressiveness of
>>>>>>>>> inactive and
>>>>>>>>> template mechanisms, but it might be ok.
>>>>>>>>>
>>>>>>>>> I think that even w/o this requirement, the observable
>>>>>>>>> behavior for a
>>>>>>>>> client can be backwards compatible. For example, suppose we
>>>>>>>>> have an
>>>>>>>>> inactive access control rule that refers to a non-existing
>>>>>>>>> interface in
>>>>>>>>> <running>. If a client that doesn't know anything about
>>>>>>>>> inactive asks
>>>>>>>>> for the contents of <running>, our implementation removes the
>>>>>>>>> inactive
>>>>>>>>> nodes from the reply to the client. Only a client that
>>>>>>>>> opts-in to
>>>>>>>>> inactive will receive a reply with things that looks invalid
>>>>>>>>> if you
>>>>>>>>> don't take the inactive annotation into account.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> There are many ways that validation can fail because inactive
>>>> nodes
>>>>>>>>> are present,
>>>>>>>>> and considered part of the validation.
>>>>>>>>>
>>>>>>>>> e,g, min-elements, max-elements, mandatory, unique.
>>>>>>>>>
>>>>>>>>> I think we all agree that validation on the enabled nodes is
>>>> supposed
>>>>>>>>> to continue to work.
>>>>>>> Yes.
>>>>>>>
>>>>>>>>> Here is an attempt at a backwards-compatible solution:
>>>>>>>>>
>>>>>>>>> 1) current <get-config> and <get> responses only include
> enabled
>>>>>>>>> nodes.
>>>>>>>>> 2) old-style <edit-config> operations do not alter inactive
> nodes
>>>>>>>>> 3) NMDA clients use <get-data>, not <get-config> or <get>.
> These
>>>>>>>>> responses
>>>>>>>>> include enabled and disabled nodes, so validation does not
> apply
>>>>>>>>> for <running>
>>>>>>>>> 4) new style <edit-config> (i.e. <datastore> parameter used)
> can
>>>> alter
>>>>>>>>> any type of data node
>>>>>>>> //I think that inactive should always be an optional extension.
>>>> Not
>>>>>>>> everything needs the additional complexity.
>>>>>>>>
>>>>>>>> Hence rather than tying this function to specific NETCONF
>>>> operations,
>>>>>>>> I would suggest that there should be an extra parameter (like
> for
>>>>>>>> with-defaults) to allow a client to indicate to the server that
> a
>>>> get
>>>>>>>> or edit request is using the "with-inactive" extension.
>>>>>>>> 1) The server should also have a capability (or perhaps a leaf
>>>> defined
>>>>>>>> in YANG library) to indicate that it supports inactive
>>>> configuration.
>>>>>>>> 2) If a client doesn't use the extra "with-inactive" parameter
>>>> during
>>>>>>>> a get request then only active nodes are returned.
>>>>>>>> 3) If a client doesn't use the extra "with-inactive" parameter
>>>> during
>>>>>>>> an edit-data request then the request cannot include an extra
>>>> inactive
>>>>>>>> meta-data. The request is processed in a way that is equivalent
> to
>>>> an
>>>>>>>> existing NETCONF implementation, but it may unknowingly remove
>>>> some
>>>>>>>> inactive configuration (e.g. via a replace or remove operation
> on
>>>> an
>>>>>>>> inactive node). Operations like create, delete, none, replace
>>>> should
>>>>>>>> all treat an inactive target node the same way as in the node
>>>> doesn't
>>>>>>>> exist (e.g. delete on an inactive node would return a
>>>> "data-missing"
>>>>>>>> error), this ensures that the behaviour that an unaware client
>>>>>>>> observes is the same as the existing behaviour that it would
>>>> expect
>>>>>>>> from a regular 6241 compliant NETCONF implementation.
>>>>>>>> 4) It a client makes a get request including the
> "with-inactive"
>>>>>>>> parameter then they also get the inactive nodes as well, marked
>>>> with a
>>>>>>>> meta-data annotation.
>>>>>>>> 5) If a client makes an edit request including the
> "with-inactive"
>>>>>>>> parameter, then the inactive meta-data annotation can be used
> to
>>>> label
>>>>>>>> inactive nodes. Inactive nodes are regarded as regular data
> nodes
>>>> for
>>>>>>>> create/delete/replace/none operation error checking.
>>>>>>>>
>>>>>>>> I think that this approach is similar (perhaps even the same)
> as
>>>>>>>> Martin described.
>>>>>>> This is indeed how our implementation works (except I think we
>>>> don't
>>>>>>> do 5; if the client sends an "inactive" attribute it doesn't
> have
>>>> to
>>>>>>> also send with-inactive).
>>>>>>>
>>>>>>>>> Note that the YANG MUST rule still applies, because validation
> is
>>>> only
>>>>>>>>> done on enabled nodes.
>>>>>>>>> It is only the response message representations that cannot be
>>>>>>>>> validated, not the contents
>>>>>>>>> of <running> on a server.
>>>>>>> So the question is how we can make sure that the text in the
> NMDA
>>>>>>> draft covers this yet-to-be-defined feature w/o having to define
> it
>>>>>>> now? We thought that the current text was sufficient, but do we
>>>> have
>>>>>>> to make any changes to it?
>>>>>> 1) Do we also need to illustrate a similar proof of concept
>>>> templating
>>>>>> implementation to show that templating could work whilst keeping
>>>>>> running valid? I would prefer that this is just deferred to
>>>> whichever
>>>>>> draft defines templating.
>>>>>>
>>>>>> 2) I think that we need to reach a decision as to whether the
> NMDA
>>>>>> architecture needs to explicitly state that <running> is always
>>>> valid,
>>>>>> or if that can be left to the existing statement in 7950. My
>>>> thinking
>>>>>> is that if the conclusion is that <running> must always be valid,
>>>> then
>>>>>> it would be helpful to explicitly state it the descriptions of
> both
>>>>>> <running> and <startup> in the NMDA architecture.
>>>>>>
>>>>>> 3) I think that it would be useful to further refine my previous
>>>>>> proposed text for intended, particularly rewriting the text on
>>>>>> validation. This should hopefully also address Balazs' concern
> about
>>>>>> default values be included in validation.
>>>>>>
>>>>>> <Old>
>>>>>>
>>>>>> 4.4. The Intended Configuration Datastore (<intended>)
>>>>>>
>>>>>> The intended configuration datastore (<intended>) is a read-only
>>>>>> configuration datastore. It is tightly coupled to <running>. When
>>>>>> data is written to <running>, the data that is to be validated is
>>>>>> also conceptually written to <intended>. Validation is performed
> on
>>>>>> the contents of <intended>.
>>>>>>
>>>>>> For simple implementations, <running> and <intended> are
> identical.
>>>>>> <intended> does not persist across reboots; its relationship with
>>>>>> <running> makes that unnecessary.
>>>>>>
>>>>>> Currently there are no standard mechanisms defined that affect
>>>>>> <intended> so that it would have different contents than
> <running>,
>>>>>> but this architecture allows for such mechanisms to be defined.
>>>>>>
>>>>>> One example of such a mechanism is support for marking nodes as
>>>>>> inactive in <running>. Inactive nodes are not copied to
> <intended>,
>>>>>> and are thus not taken into account when validating the
>>>>>> configuration.
>>>>>>
>>>>>> Another example is support for templates. Templates are expanded
>>>>>> when copied into <intended>, and the expanded result is
> validated.
>>>>>> </Old>
>>>>>> <Proposed>
>>>>>>
>>>>>> 4.1.4. The Intended Configuration Datastore (<intended>)
>>>>>>
>>>>>> The intended configuration datastore (<intended>) is a read-only
>>>>>> configuration datastore. It represents the configuration after
> all
>>>>>> configuration transformations to <running> are performed (e.g.
>>>>>> template expansion, removal of inactive configuration), and is
> the
>>>>>> configuration that the system attempts to apply.
>>>>>>
>>>>>> <intended> is tightly coupled to <running>. Whenever data is
> written
>>>>>> to <running>, then <intended> is also immediately updated by
>>>>>> performing all necessary transformations to the contents of
>>>> <running>
>>>>>> and then <intended> is validated.
>>>>>>
>>>>>> <intended> may also be updated independently of <running> (e.g.,
> if
>>>>>> one of the configuration transformations is changed), but
> <intended>
>>>>>> must always be a 'valid configuration data tree' as defined in
>>>>>> Section 8.1 of [RFC7950].
>>>>>>
>>>>>> For simple implementations, <running> and <intended> are
> identical.
>>>>>> The contents of <intended> is also related to the 'config true'
>>>>>> subset of <operational>, and hence a client can determine to what
>>>>>> extent the intended configuration is currently in use by checking
>>>>>> whether the contents of <intended> also appears in <operational>.
>>>>>>
>>>>>> <intended> does not persist across reboots; its relationship with
>>>>>> <running> makes that unnecessary.
>>>>>>
>>>>>> Currently there are no standard mechanisms defined that affect
>>>>>> <intended> so that it would have different contents than
> <running>,
>>>>>> but this architecture allows for such mechanisms to be defined.
>>>>>>
>>>>>> One example of such a mechanism is support for marking nodes as
>>>>>> inactive in <running>. Inactive nodes are not copied to
> <intended>.
>>>>>> A second example is support for templates, which can perform
>>>>>> transformations on the configuration from <running> to the
>>>>>> configuration written to <intended>.
>>>>>>
>>>>>> </Proposed>
>>>>>>
>>>>>> Thanks,
>>>>>> Rob
>>>>>>
>>>>>>
>>>>>>> /martin
>>>>>>> .
>>>>>>>
>>>>>> .
>>>>>>
>>>> .
>>>>
>> _______________________________________________
>> netmod mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/netmod
>>
> .
>