[netmod] 答复: 答复: system configuration sync mechanism

["Fengchong (frank)" <[e-mail]>]

Hi,andy,

发件人: Andy Bierman [mailto:[e-mail]]
发送时间: 2021年8月4日 1:11
收件人: Fengchong (frank) <[e-mail]>
抄送: Juergen Schoenwaelder <[e-mail]>; Kent Watsen <[e-mail]>; Balázs Lengyel <balazs.lengyel=[e-mail]>; [e-mail]
主题: Re: [netmod] 答复: system configuration sync mechanism



On Tue, Aug 3, 2021 at 12:34 AM Fengchong (frank) <[e-mail]<mailto:[e-mail]>> wrote:
Hi juergen,
  Please see my comments inline.

  /frank

-----邮件原件-----
发件人: Jürgen Schönwälder [mailto:[e-mail]<mailto:[e-mail]>]
发送时间: 2021年8月3日 12:15
收件人: Fengchong (frank) <[e-mail]<mailto:[e-mail]>>
抄送: Andy Bierman <[e-mail]<mailto:[e-mail]>>; Kent Watsen <[e-mail]<mailto:[e-mail]>>; Balázs Lengyel <balazs.lengyel=[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[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.


Frank:I don’t know what’s the another rewrite of ietf-interfaces.


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.

Frank: yes. I agree with you. But in some cases, only part of the same list’s instances are read only, we can not place a tag on YANG node.


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

Frank: I don’t think it’s a correct way.

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

Frank: my object is solving the issues that when we want to reference a system predefined instance we must recreate it.

In RFC7950 sec 6.4.1, the context of XPATH also include default value and NP-container, even though they are not exist in datastore.
[cid:[e-mail]0]
It’s maybe a good idea that the context of XPATH can include running configuration and the system configuration and we don’t need to import system configuration to running datastore.
In this case, <system> datastore is necessary for client, because the client may need  system configuration for validation.

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.

Frank: I think it is not correct way.

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