Re: [Netconf] Subscription with Replay

[Yves Beauville <[e-mail]>]

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.
>
> 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
>