Subject: [Netconf] Subscription with Replay

From: "Beauville, Yves (Nokia - BE)" <[email-masked]>
Date: Mon, 19 Dec 2016 15:03:07 +0000

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

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Mon, 19 Dec 2016 15:51:30 +0000

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,

Regards,
Yves Beauville

---

From: Yves Beauville <[email-masked]>
Date: Tue, 20 Dec 2016 08:28:02 +0100

Hi Eric,

I am definitely interested in a mechanism for subscription negotiation.

Note that in my use case, I do not want to trigger a replay if the 
server cannot perform it from the specified startTime. I expect that 
subscription negotiation could cover this case.

Yves

On 12/19/2016 4:51 PM, Eric Voit (evoit) wrote:
>
> 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.
>
> * 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)
>
>   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
>
> 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
>