Re: [netconf] system configuration sync mechanism

["maqiufang (A)" <[e-mail]>]

Hi, Kent:
Thanks for kicking off some discussion around this draft. Please see my reply inline.

From: Kent Watsen [mailto:[e-mail]]
Sent: Tuesday, June 29, 2021 7:44 AM
To: maqiufang (A) <[e-mail]>
Cc: [e-mail]
Subject: Re: [netconf] system configuration sync mechanism

Hi Qiufang,


I just read your draft and have a few comments:




1) I wish there were more examples, especially for "resource-independent” configuration.  I understand well enough "resource-dependent" (dynamic) configuration, but am unclear about what all "resource-independent” entails.  By example, JUNOS has a concept called “JUNOS defaults”, which is effectively read-only and hidden-by-default configuration that, most times, must be referenced in order to take effect.   For instance, check the examples halfway down this page: https://nextheader.net/2016/06/10/junos-defaults-group.  Is this similar to what you have in mind?
[Qiufang Ma]  Yes. Physical-resource-independent system configuration is generated when the device is powered on and has nothing to do with the physical resource. Loopback interface may be the most common physical-resource-independent system configuration. To my knowledge, many vendors ((e.g., Huawei NE40E and Cisco IOS XR) will provide several predefined user groups and/or task groups which are used for authentication, authorization and accounting (AAA) services. Since these configurations are provided by the device/system, they could  be treated as system configuration. I think your  information about the predefined hidden configuration group which contains preconfigured values should also be treated the same.
More examples about system configurations would be worked on and added in  the next version of the draft.:)
2) Please treat NETCONF and RESTCONF equally.  Currently the draft speaks only to how it impacts NETCONF, but it should equally show how RESTCONF in impacted.
[Qiufang Ma] Thanks for bringing it to my attention, I would take RESTCONF into consideration and see how the proposal works on RESTCONF.


3) The “basic mode” term sounds too close to the “with-defaults” basic modes...can we please pick another name (e.g., system-datastore-operating-mode)?
[Qiufang Ma] Yes, agree. Actually we don’t really want to cause any confusion or misunderstandings. This term controls whether the device will update <running> with system configuration change or not.
Your proposal looks good to me, other suggestions are also welcome here.

Regarding your question below I don’t feel ready to comment on it yet.  I do understand the JUNOS model and, if it is compatible, would recommend considering, as it is implemented and seems to be working well enough.  That said, it might be the case that every vendor has defined their own way and each needs to be documented in turn...
[Qiufang Ma] The issue we try to resolve here is that in order for system configurations being referenced or to make sure a successful validation when the system configuration is in the when/must statement, the system configuration must be retrieved from <operational> firstly and then copied into <running> manually, which is cumbersome. In this case, we would like to define some kind of mechanism to synchronize system configuration into <running>. Currently two system configuration data handling modes are specified. One will update <running> with any system configuration change automatically, and the other will not, so that the implementer may choose the mode more suitable for them. Hopefully this clarifies what we try to do. Please feel free to comment or suggest.


Best Regards,
Qiufang Ma

K.  // contributor



On Jun 22, 2021, at 11:43 PM, maqiufang (A) <[e-mail]<mailto:[e-mail]>> wrote:

Dear all,
One of the open issues of draft https://datatracker.ietf.org/doc/html/draft-ma-netconf-with-system-02 is about how to synchronize the system configuration into <running>.
I think we could have 2 options.
Option 1: Any update in <system> will be synced up into <running> automatically
  PRO:

       o  effective for the client: there is no need for the client to retrieve the referenced system configuration from <operational> and then copy it into <running> manually.
  CON:
            o   implementation complexity

Option 2: To define a RPC operation to propagate <running> with <system>
  PRO:
       o  client-driven: it totally depends on the client when and how to populate <running>.
  CON:
       o  The client needs to :
o   spend energy to detect the <system> update and operate the RPC every time the client references the system configuration or the system configuration is in the when/must statement.
o   subscribe the <system> update and copy it into <running> whenever an update is detected.

I incline to the view that this issue involves some kind of trade-off, which is hard to distinguish the preference.
Maybe both options can be reserved and differentiated by different modes, so that the server implementer may choose from.
Any thoughts?


Best Regards,
Qiufang Ma
_______________________________________________
netconf mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/netconf