Subject: Re: [netconf] some comments on netconf-adaptive-subscription

From: Qin Wu <[email-masked]>
Date: Fri, 25 Jun 2021 16:37:03 +0000

-----邮件原件-----
发件人: Michael Richardson [mailto:[email-masked]] 
发送时间: 2021年6月26日 0:10
收件人: Qin Wu <[email-masked]>; [email-masked]; [email-masked]
主题: Re: some comments on netconf-adaptive-subscription

Qin Wu <[email-masked]> wrote:
    > [Qin]: That's a good suggestion, WiFi provides a good use case for this
    > adaptive subscription mechanism. we did try some existing published
    > YANG models, but it seems YANG models size is too big.  That's why we
    > create simplified Wifi mac example Module. If you can provide a link to
    > CHIP/MATTER WIFI statistics module, we are happy to quote that existing
    > module.

The CHIP/MATTER document not public yet, but Huawei is a member and can get the document.
But, it's not a YANG module.  The fact that they have a set of wifi statistics in their base definition argues that there ought to be an equivalent YANG model though.

[Qin]:Thanks, I will take a look at it and see if something can be reused.

    > [Qin]: The intention is to optimize the existing YANG push mechanism
    > for NETCONF/RESTCONF and other management protocols. And the network
    > device can support multiple capture periodic intervals, the mechanism
    > we introduce is to allow the network device switch to different capture
    > periodic interval automatically without asking the NMS for permission
    > each time. I hope this clarifies.

yes, I understood that from the document.

    > [Qin]: I am also hoping RESTCONF and CORECONF can work together, but
    > they seems to look into different use cases (constrained device
    > management vs unconstrained device management) .  I am not sure we
    > should generalized RESTCONF and CORECONF into a single protocol.

That's not what I'm suggesting.
I'm asking, if bandwidth is an issue, why not use a smaller encoding.
[Qin]: For YANG push, usually the server learns the encoding supported by the client at the beginning of the management session. Two relevant drafts are:
draft-ietf-netconf-https-notif
draft-tao-netconf-data-export-capabilities
I am not sure we can switch encoding in the middle of session, which probably needs to tear down the session and loss the service continuity.
For the network device support multiple capture periodic intervals, switch the interval is cheap and doesn't cause the session to be interrupted.
That is why we not consider a smaller encoding in the solution.
And, why not integrate with CoAP Observe?
[Qin]: I have a quick look at COAP Observe. I see the commonality between CoAP Observer and this draft is 
The server or network device in both cases, need to send notification to the client to inform the current temperature or subscribed data.
The client in both case needs to observer resource change or data change in the server.
But the difference is the server in adaptive-subscription draft has some control and can switch capture periodic interval. In addition, the server in the adaptive-subscription draft
Can send interval switching notification to the client.
So based on this analysis, I believe CoAP Observe has been integrated into this draft which is similar to what RFC8641 specifies (i.e., Pub Sub mechanism).

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Qin Wu <[email-masked]>
Date: Fri, 25 Jun 2021 17:12:00 +0000

-----邮件原件-----
发件人: Michael Richardson [mailto:[email-masked]] 
发送时间: 2021年6月26日 0:58
收件人: Qin Wu <[email-masked]>; [email-masked]; [email-masked]
主题: Re: [core] some comments on netconf-adaptive-subscription

Qin Wu <[email-masked]> wrote:
    mcr> I didn't finish my thought here.  Specifically, it seems that the CORE
    mcr> WG is doing a lot of stuff with CoAP Observes and SENML and all sorts
    mcr> of interesting triggers.

    Qin> data modeling language such as YANG can be common work for both CORE
    Qin> WG and NETCONF WG, But they may choose different transport protocol,
    Qin> such as NETCONF, RESTCONF, HTTP 2.0, COAP, MQTT, COMI Secondly, I
    Qin> think it will be nice to separate constrained device management from
    Qin> resource unconstrained network device management, Constraint device
    Qin> as IoT device can be temperature sensor, current, voltage sensor
    Qin> which can be seen as affiliated devices pertaining to resource
    Qin> unstrained network device.

temperature, current are critical values for routing equipment, aren't they?

[Qin]: My understanding is yes, there is hardware YANG model which can be used to collect these inventory data associated with the routing equipment
See RFC8348.

    Qin> In data center scenarios, we do see a lot of such affiliated devices or
    Qin> sensors such as air conditioner, water leakage alarm sensor deployed
    Qin> together with data center switch devices.  These IoT devices only
    Qin> use MQTT/COAP/HTTP to communicate with their IoT platform, for data
    Qin> center switch devices, you may still rely on network management
    Qin> protocols such as NETCONF, SNMP, gRPC, etc.  Do you see this
    Qin> differently? Michael?

It seems that we ought to seek convergence here.
That's what I'm saying.  That any split here is for historical reasons, and does not make sense going forward.

[Qin]: Tend to agree, unified data modeling or semantics interoperability may be the solution. One of example is to
Build digital twin data model and models sensor data and network device health data together.