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" <rwil...@cisco.com> 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 <rwil...@cisco.com> wrote: > >>> > >>> On 18/09/2017 19:25, Andy Bierman wrote: > >>>> > >>>> On Mon, Sep 18, 2017 at 11:07 AM, Martin Bjorklund <m...@tail-f.com > >>>> <mailto:m...@tail-f.com>> wrote: > >>>> > >>>> Juergen Schoenwaelder <j.schoenwael...@jacobs-university.de > >>>> <mailto:j.schoenwael...@jacobs-university.de>> 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 netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
