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

[Martin Bjorklund <[e-mail]>]

Hi,

"Eric Voit (evoit)" <[e-mail]> wrote:
> > 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. ";

Ok.  The definition of the "period-unsupported" identity should also
be updated accordingly.

BTW, I just realized that the yang-data structures have different
names in the module and the text.  For example, in the module you have
"establish-subscription-datastore-error-info" but the text uses
"establish-subscription-error-datastore" (in some places).


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

I suggest you keep the OLD text, but also add a sentence that explains
that the server MAY not support the given dampening period, and that
the period-hint can be used by the server to indicate an acceptable
dampening period (which may be 0).


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

I agree.


/martin


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