Re: [netmod] system configuration sync mechanism

[Andy Bierman <[e-mail]>]

Hi,


I do not agree that a new datastore is needed to supposedly retrieve the
system created nodes that exist (already supported by get-data) or
the nodes that could be created by the server but do not currently exist.
The  <config> element is way too simplistic to represent all the real-world
possibilities.

Current XPath procedures define several contexts for evaluating expressions.
None of these procedures support an additional <system> datastore that is
somehow
merged with the other datastores for XPath purposes.  YANG 1.1 does not
support
this proposal at all.


Andy




On Tue, Aug 3, 2021 at 8:34 PM maqiufang (A) <[e-mail]> wrote:

> Hi, Andy,
>
>
>
> Apologize for my chiming in. Please see my reply inline.
>
>
>
> *From:* netmod [mailto:[e-mail]] *On Behalf Of *Andy
> Bierman
> *Sent:* Wednesday, August 4, 2021 1:11 AM
> *To:* Fengchong (frank) <[e-mail]>
> *Cc:* Balázs Lengyel <balazs.lengyel=[e-mail]>;
> [e-mail]
> *Subject:* Re: [netmod] 答复: system configuration sync mechanism
>
>
>
>
>
>
>
> On Tue, Aug 3, 2021 at 12:34 AM Fengchong (frank) <
> [e-mail]> wrote:
>
> Hi juergen,
>   Please see my comments inline.
>
>   /frank
>
> -----邮件原件-----
> 发件人: Jürgen Schönwälder [mailto:[e-mail]]
> 发送时间: 2021年8月3日 12:15
> 收件人: Fengchong (frank) <[e-mail]>
> 抄送: Andy Bierman <[e-mail]>; Kent Watsen <[e-mail]>;
> Balázs Lengyel <balazs.lengyel=[e-mail]>;
> [e-mail]
> 主题: Re: [netmod] 答复: system configuration sync mechanism
>
> On Tue, Aug 03, 2021 at 01:45:40AM +0000, Fengchong (frank) wrote:
> > Hi andy and all.
> >
> > I don’t think get-data with origin can solve the issues below:
> >
> >
> > 1.       Some leafs like interface type CAN NOT be modified by user, but
> can be referenced by other config nodes(e.g. using leafref or occur in
> when/must). The validation will be fail if these leafs are not be
> configured by user now explicitly (we assume these leafs are optional and
> no default value).
>
> The interface type in the RFC 8343 module is config true. YANG does not
> allow you to refer to config false nodes in constraints that apply to
> config true nodes. A core principle is that the content of a configuration
> datastore can be validated without knowing the actual state of the system.
>
> Frank: yes, interface type is a config node, but it isn't allow to be
> modified. If a config node reference if-type, in order to validate data
> successfully ,user must have to config if-type with determined value again.
> For example, user must config if-type with 'ethernet' for ethernet0/0/1. I
> don't think it makes sense. The if-type has been created by system, when
> running config is merged to <operational>, it can work and the validation
> is successful. If you think running datastore is self-contained, I will
> think the system configuration should be imported to running datastore
> automatically to ensure successful validation
>
>
>
>
>
> I doubt another rewrite of ietf-interfaces would gain much support.
>
>
>
> There are many objects that have user access restrictions that are not
> standardized
>
> with machine-readable statements.  I am interested in the 2 use cases that
> Balazs described.
>
> The system does its own access control (not NACM) wrt/ these objects. The
> server just
>
> rejects the edit requests, even though the standard YANG indicates it
> should be writable.
>
> Some standard extensions to tag the data would help applications better
> predict server behavior.
>
>
>
> There is no way in YANG 1.1 to have a config=true node reference
> config=false in the XPath.
>
> (Well, we implement it but the developer has to enable it).
>
>
>
> I do not see the point of the system datastore if it contains config=true
> nodes,
>
> just so that XPath can reference it.  I do not agree that it is useful or
> easy to implement,
>
> especially since the contents of <system> are visible in <intended>.
> Representing the possible
>
> instances is non-trivial (e.g. pattern allowed, not a fixed name,
> resulting in 6 million possible values).
>
> *[Qiufang Ma] I don’ t see any system configuration handling behavior
> standards in non-NMDA; NMDA defines that system configuration should only
> be included in <operational>. I think it necessary to distinguish between
> system configuration and operational state.*
>
> *Since there may be some requirements to reference the system
> configuration, it doesn’t seem sensible to treat system configuration as
> operational state. I don’t think retrieval from <operational> should be the
> only way to get system configurations, given the definition of operational
> datastore.*
>
> *That is to say, <operational> contains all applied configurations which
> go through configuration combination and template expansion. Only the
> system configurations which take effect are included and will be tagged as
> “origin=intended” once being referenced in <running>. I believe there would
> be a need to get the pure system configurations regardless of whether being
> applied or not.*
>
>
>
> If the system datastore contains config=false nodes, then you are talking
> about a rewrite
>
> of the YANG validation architecture and a new version of YANG.  IMO there
> is no need for that.
>
> *[Qiufang Ma] I don’t think <system> would contain config=false nodes. A
> rewrite of the YANG validation architecture and a new version of YANG are
> not our
> intention.
> *
>
>
>
> Best Regards,
>
> Qiufang Ma
>
>
>
>
>
> Andy
>
>
>
>
>
> > 2.       Some instances are generated by system, but these instances can
> be referenced by other config nodes. The validation must be fail if these
> instances are not be recreated by user explicitly now.
>
> Yes, a configuration datastore is self-contained. If a client wants to
> configure the interface x, it has to define the interface x in the
> configuration. Note that this should not be confused with a system
> generating an interface x after probing the hardware. Note the difference
> between operational state, applied config, and running config.
>
> Frank: for example , predefined policies are provided by system, user
> configuration can reference these predefined policy directly. but because
> predefined policies are not configured by user explicitly, the validation
> will be fail. If you want to get a successful validation , user MUST have
> to redefined the system predefined policies.
> So, system predefined data are useless. I think it is unreasonable.
>
>
>
> Let me add that the underlying model is that the client(s) have control
> over the configuration. A system making ad-hoc changes to the config (even
> with the best intentions) will be surprising. In this model, the only way
> to inject config into running on system boot is to have a client making
> changes to running following the normal procedures - at least conceptually.
> This means that conceptually the other clients need to be aware that there
> is a system client injecting configuration.
>
> If you follow this logic, it seems wrong to define a system datastore that
> is somehow magically merged into running - and it is not needed.
>
> Frank: system configuration not only includes some instances generated on
> reboot time, but also includes the configuration when hardware is plugged
> in, or a function is enabled (for example, in huawei's implementation, when
> QOS function is enabled, many qos predefined policies are created by
> system) or a user-created list instance is created, some leafs' value will
> be created by system. So , we need a system datastore to hold these
> configuration.
>
> > 3.       User may need know what the original system configuration is,
> if we get data from <operational>, you may get the modified system
> configuration.(for example, user modify or template is expanded, or only
> active instances)
>
> If you have multiple clients managing shared configuration, then yes it is
> good if they are aware of what is going on. I am not sure yet that exposing
> other clients intentions via additional datastores and defining merge
> mechanisms and semantics is the way to go.
>
> > I don’t care about whether system datastore is imported to running or
> intended datastores. But I think if a config node reference a system node,
> the validation (running or intended datastores) will be successful even if
> the system node is not configured by user explicitly.
>
> I am concerned about having to define what "is imported" means precisely
> and whether moving to a model multiple datastores have to be merged before
> validation is the way to go. We already acknowledged that there are
> template expansions in some implementations without working out how they
> work.
>
> > Especially on the client side,  if a client need validate all data
> retrieved from server, the validation SHOULD be successful. If system
> configuration are not imported to running, at a minimum, the client needs
> to know what the original system configuration is. Another way is adding
> with-system-used parameter to get-config operation to retrieved all user
> configuration and system configuration referenced by user configuration.
>
> Let me repeat, in the original model, the running configuration datastore
> is self-contained and can be validated without knowing additional
> datastores.
>
> /js
>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   [phone]         <https://www.jacobs-university.de/>
>
>