Re: [Netconf] yang-push-17 on-change subscriptions

["Eric Voit (evoit)" <[e-mail]>]

> From: Martin Bjorklund, August 17, 2018 3:48 AM
> 
> Hi,
> 
> "Eric Voit \(evoit\)" <evoit=[e-mail]> wrote:
> > A dampening period is optional
> 
> How do you mean?  There is no if-feature on the "dampening-period", and no
> text indicating that a server can reject a request with a "dampening-period".
> AFAICT from the draft, the dampening feature must be implemented by a
> server.

While the "dampening-period" object must be supported by the RPC, that doesn't mean the platform needs to implement subscription dampening.  This can be accomplished by a dampening period of "0" being returned as a hint.   (Per section 3.2: "Such hints include ... acceptable dampening periods...". )   Using just the hint for conveying this info rather than the hint plus advertisement of an option feature "dampening" simplifies the interface.

If you are ok with it, Alex could tweak the following text in the draft:

(1) For the definition of leaf 'period-hint' in the YANG model:

OLD:   "Returned when the requested time period is too short. This hint can assert a viable period for either a periodic push cadence or an on-change dampening interval.";

NEW:   "Returned when the requested time period cannot be supported. This hint can assert a viable period for either a periodic push cadence or an on-change dampening interval.  In the case of dampening not being supported, a 'period-hint' of '0' must be returned. ";

(2) And in Section 3.1:

OLD: In order to protect against that, a dampening period MAY be used to  specify the interval which must pass before successive update records for the same subscription are generated for a receiver.

NEW: In order to protect against that, on-change dampening MAY be supported.  Where supported, a non-zero dampening period will specify the interval which must pass before successive update records for the same subscription are generated for a receiver. 

If you require more than these tweaks, Alex could also make an optional dampening feature.  But this seems to me to be unnecessarily heavyweight.

Eric

> /martin
> 
> 
> (based on your earlier comments).  And
> > the dampening period is per subscription rather than per object.
> > Cisco doesn’t have code at this time for dampened changes.
> >
> > Eric
> >
> > From: Netconf <[e-mail]> On Behalf Of Andy Bierman
> > Sent: Thursday, August 16, 2018 1:59 PM
> > To: Netconf <[e-mail]>
> > Subject: [Netconf] yang-push-17 on-change subscriptions
> >
> > Hi,
> >
> >
> > I would like to know if anybody has implemented on-change
> > subscriptions yet.
> > The implementation requirements seem very complex when you consider
> > that every single data node instance in the subscription has its own
> > dampening timer.
> >
> > Edits are not reported sequentially as they occur.
> > Instead every node is tracked and the change may only reported after
> > the dampening period expires.  It seems quite possible that nodes can
> > interact (e.g., leafrefs) so that reporting edit Y can depend on
> > previous edit X, which cannot be reported until the end of its
> > dampening period, in the future. So edit Y will be reported before X,
> > and the patch will fail to validate, because the current state of X is
> > incorrect on the receiver..
> >
> > All the state tracking on the server is expensive to implement, and I
> > am not really sure it actually helps the client that much.
> >
> >
> > Andy
> >