Hi, Jensen My understanding is that, if we’d like to take reactive mode (e.g., periodic push from yang datastore [1]) as an example, ALTO-server receives stream of updates from a specified YANG datastore at a fixed interval without needing to poll. Suppose the publisher supports RESTCONF as transport mechanism, either a “initiate” or a “listen” container (defined in rcc:restconf-client-app-grouping [2]) can be configured to ask the ALTO-server which works as a RESTCONF-client here, to initiate connections to publisher (i.e., to establish dynamic subscription or configured subscription [3] to the RESTCONF-server) or just listen and wait for a call-home[4] connection (i.e., to receive configured subscription as a YANG-push receiver).
I have provided an example as attached, I am using a call-home connection as exmaple here, so that the alto-server only needs to listen on a specified port and wait for the periodic arrival of stream network topology data. Besides, the example yang file is also updated as attached according to our discussion in last Tuesday-night meeting. [1] https://datatracker.ietf.org/doc/html/rfc8641 [2] https://datatracker.ietf.org/doc/draft-ietf-netconf-restconf-client-server/ [3] https://datatracker.ietf.org/doc/html/rfc8639 [4] https://datatracker.ietf.org/doc/rfc8071/ Best Regards, Qiufang From: Jensen Zhang [mailto:[email protected]] Sent: Friday, January 20, 2023 10:56 AM To: maqiufang (A) <[email protected]> Cc: [email protected]; [email protected] Subject: Re: [alto] Comments on data source configuration in alto-oam Hi Qiufang, I am preparing the new revision in the GitHub repo [1]. I am going to merge your proposed updates on the "data-source" part. I hope we can have an example in the appendix to show how to use the new reactive mode. Do you have any references or suggestions? [1] https://github.com/ietf-wg-alto/draft-ietf-alto-oam-yang Cheers, Jensen On Tue, Jan 17, 2023 at 4:46 PM Jensen Zhang <[email protected]<mailto:[email protected]>> wrote: Hi Qiufang, Many thanks for your deep review. See my feedback inline. On Tue, Jan 17, 2023 at 11:23 AM maqiufang (A) <[email protected]<mailto:[email protected]>> wrote: Hi, all I had a chance to take a deeper look at this -02 version — not the other parts, but only the YANG model related to the data-source configuration, which I believe is the section 5.3.1 and Appendix A.1 in the current draft. Following are some contributor thoughts: • I like the idea that we only define a very general list now and leave the parameters specific to each data source to be extended in future, while I am not convinced that the update-policy choice defined here is proper. My intuition is that for reactive mode, the alto server waits data feed without needing to poll. It could receive data as soon as it changes, but periodic collection could also be another mode. I don't fully understand the feed-interval property in reactive mode. The data-source list actually configures a list of data source listeners in the ALTO server. Should this property be configured by the data source side, instead of the ALTO server side? Do you have any example of how the feed-interval is used by a concrete data source listener? I question whether a Boolean type of reactive leaf is sufficient, and what if a false value is configured here? I would rather use an empty type. Make sense. I like this change. • I would like the update-policy choice to be defined outside data-source list (but not very strong feeling), it is not the property of data-source itself, but how the alto server get data from data-source. If we move update-policy outside, could someone configure a data source without configuring its update-policy? If so, how does the ALTO server decide how to get data updates? That said, my suggested data-source tree diagram is following: … +--rw data-source* [source-id] | +--rw source-id string | +--rw source-type identityref | +--rw (source-params)? +--rw data-update-policy* [source-id] | +--rw source-id -> ../../data-source/source-id | +--rw (update-policy)? | +--:(reactive) | | +--rw (reactive-mode)? | | +--:(on-change) | | | +--rw on-change empty | | +--:(period) | | +--rw feed-interval uint32 | +--:(proactive) | +--rw poll-interval uint32 … • Regarding the Appendix part, it seems to me that some parameters are still missing. The following tree diagram for a yang-datastore source example could be for the authors’ reference: module: example-ietf-alto-data-source augment /alto:alto-server/alto:data-source/alto:source-params: +--:(yang-datastore) +--rw source-server +--rw name? inet:domain-name +--rw datastore identityref +--rw target-paths* [name] | +--rw name string | +---u yp:selection-filter-types +--rw protocol* identityref +--rw restconf | +---u rcc:restconf-client-app-grouping +--rw netconf +---u ncc:netconf-client-app-grouping Thanks for the improvement. Just a small question. What is the usage of the name property of the source-server? Who will reference this name? Is this the duplicate of the source-id? The difference between *conf-client-app-grouping and *conf-client-listen-stack-grouping is that the former also supports initiating connections to servers proactively, which I believe is the more common case. Good suggestion. I like this change. All related YANG modules are attached. Many thanks. I will consider your proposed changes and merge them into the new revision. btw. We have received a lot of very good concrete editing comments and suggestions. We really appreciate your contributions. Would you like to become a coauthor of this document? Best Regards, Qiufang Thanks, Jensen
example.xml
Description: example.xml
example-ietf-alto-data-source.yang
Description: example-ietf-alto-data-source.yang
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
