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

["t.petch" <[e-mail]>]

Robert

I wonder if this says the opposite of what is intended

- <running> holds the complete  current configuration on the device.

- This could include inactiveconfiguration

 - <running> must always be a  'valid configuration data tree' as
defined in Section 8.1 of [RFC7950].

Ergo, inactiveconfiguration must 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..

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