Re: [Netconf] Subscription with Replay

"Eric Voit (evoit)" <evoit@cisco.com> Mon, 19 December 2016 15:51 UTC

From: "Eric Voit (evoit)" <evoit@cisco.com>
To: "Beauville, Yves (Nokia - BE)" <yves.beauville@nokia.com>
Thread-Topic: Subscription with Replay
Thread-Index: AdJaCImWjYbGpT/+TTGf6QoaoXGE3AABSkkQ
Date: Mon, 19 Dec 2016 15:51:30 +0000
Message-ID: <05c52fa2cd6045e5b682edfb31bcf39b@XCH-RTP-013.cisco.com>
References: <3004A47FF33FC14B9680465CD90772CC47CD6215@FR711WXCHMBA08.zeu.alcatel-lucent.com>
In-Reply-To: <3004A47FF33FC14B9680465CD90772CC47CD6215@FR711WXCHMBA08.zeu.alcatel-lucent.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: multipart/alternative; boundary="_000_05c52fa2cd6045e5b682edfb31bcf39bXCHRTP013ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/ytwHWJEpVxKOXZL2_0uOrLN_A2I>
Cc: "netconf@ietf.org" <netconf@ietf.org>
Subject: Re: [Netconf] Subscription with Replay
Precedence: list

Hi Yves,

In 5277bis we have discussed using subscription negotiation for items like this.   For negotiation to work, we would send back a replay start time which would be acceptable to the publisher as part of the error response.   A publisher can determine the earliest possible start time as you describe below.

If you (and others) are ok with this mechanism, we can add details within a specific replay section of 5277bis.

Eric


From: Netconf, December 19, 2016 10:03 AM

Hi All,

I have a concern with RFC5277 that I do not see addressed in the scope of RFC5277bis. I would appreciate feedback whether the following point is valid or not.

I have the following use case for notification replay
* A NETCONF client caches a subset of the server data, E.G. a list of alarms
* The NETCONF client uses notifications to keep its cache up-to-date with the server
* The NETCONF client uses notification replay to re-synchronize its cache after a client/server disconnection
* In order to use notification replay, the client also caches the time-stamp of the last notification received from the server (lastNotificationTime)

The following re-synchronization scenario is used:

  Step 1. The client sends a <get> on the stream for replayLogCreationTime and replayLogAgedTime. The client uses lastNotificationTime, replayLogCreationTime and replayLogAgedTime to assess whether replay is possible.

  If replay is not possible, the client gets part of the YANG data tree from the server to re-synchronize its cache, E.G. a list of alarms, else, step 2 is played.

  Step 2. The client sends <create-subscription> on the stream with startTime=lastNotificationTime. The client processes re-played notifications to re-synchronize its cache

Open Point: between steps 1. & 2., new notifications may occur in the server and they may cause the stream to no longer be capable of replaying notifications since the last received notification.

Creating the subscription will succeed as specified in the RFC: If the <startTime> specified is earlier than the log can support, the replay will begin with the earliest available notification

Because of the above, the client will not be aware that notifications were lost.

Does RFC5277 provides a solution to overcome this issue? If not, should it provide means to let the client control the behavior of the create-subscription RPC when the server is not capable of replaying notifications since the startTime? By delegating to the server the responsibility to assess if the stream log is sufficient to allow replay, it could address my open point.

Regards,
Yves Beauville

[Netconf] Subscription with Replay Beauville, Yves (Nokia - BE)
Re: [Netconf] Subscription with Replay Eric Voit (evoit)
Re: [Netconf] Subscription with Replay Yves Beauville