Subject: [Netconf] Event notification: input on configured subscriptions and Call Home

From: "Alberto Gonzalez Prieto (albertgo)" <[email-masked]>
Date: Tue, 27 Sep 2016 14:57:32 +0000

Hello,

In draft-ietf-netconf-netconf-event-notification, we are looking into using Call Home for supporting configured subscriptions.
We would appreciate input from the group on how to leverage Call Home
Upon the creation of a configured subscription, the server would call the receiver to push notifications.
At that point, when the subscriber is called, the subscriber is not explicitly told whether it is being called for receiving notifications (vs. pushing configuration).
(Credit to Andy for identifying this)
Is there a way in Call Home to inform the callee of the reason for calling?
If not, an option is assigning semantics to the port used for calling home, so that clients would know that calls on port 'foo' are for event notifications.
The receiver could also check whether there is any configured subscription that includes it on the calling server, and assume that if there is any, the only reason for calling is receiving notifications
I find the option of including the reason for calling cleaner for it makes information explicit.
Input is most welcome.

Thanks,

Alberto

---

From: Kent Watsen <[email-masked]>
Date: Tue, 27 Sep 2016 23:43:59 +0000

Hi Alberto,

Please see my comments below.  Look for “KW”.

Thanks,
Kent

KW: none other than which address/port it connected to.  For instance, an NMS may reserve some endpoints for provisioning and others for telemetry data collection.

If not, an option is assigning semantics to the port used for calling home, so that clients would know that calls on port ‘foo’ are for event notifications.

KW: exactly.

KW: agreed.  Maybe we could introduce an RPC like <purpose-for-connection>, where responses might include “reconnection-after-drop”, “periodic-timeout”, “subscribed-data-pending”, etc.  Note, draft-ietf-netconf-netconf-client-server-00 says for “reconnect-timeout”:

                     "Sets the maximum amount of unconnected time the
                      NETCONF server will wait before re-establishing
                      a connection to the NETCONF client.  The NETCONF
                      server may initiate a connection before this
                      time if desired (e.g., to deliver an event
                      notification message).";

KW: Another idea is to abandon trying to use NETCONF/RESTCONF for configured subscriptions.   That is, only use these protocols for dynamic subscriptions, and other protocols (TLS, DTLS?) for configured subscriptions.  In this manner, the device would be configured to establish call-home connections to NC/RC client, which happens to be a “telemetry data collector” that would only ever accept call-home connections for the purpose of setting up a dynamic subscription.   Not great, but it works out of the box and we need to support it anyways.

Kent