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

[Robert Wilton <[e-mail]>]

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