On Tue, Aug 03, 2021 at 07:34:12AM +0000, Fengchong (frank) wrote: > Hi juergen, > Please see my comments inline. > > /frank > > -----邮件原件----- > 发件人: Jürgen Schönwälder [mailto:[email protected]] > 发送时间: 2021年8月3日 12:15 > 收件人: Fengchong (frank) <[email protected]> > 抄送: Andy Bierman <[email protected]>; Kent Watsen <[email protected]>; > Balázs Lengyel <[email protected]>; [email protected] > 主题: 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
You are writing about system configuration and operational state as if they are the same. I am not sure they are. Also note that interfaces are not static by any means, they come and go on a modular system. Do you consider plugging in an interface a system config change?? > > 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. Referential integrity of a configuration does have benefits and hence the config has to be there somehow. There was a strong desire to avoid dangling references that may resolve or not. > 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. Or you have a system client that is going to merge config into running. > > 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 > /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://www.jacobs-university.de/> _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
