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

From: Andy Bierman <[email-masked]>
Date: Thu, 16 Aug 2018 10:59:27 -0700

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

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 16 Aug 2018 20:25:10 +0200 (CEST)

Hi,

> that every single data node instance in the subscription has its own

For a configuration datastore, I think it will be quite easy to
implement on-change, if it wasn't for dampening.  Now, dampening
probably is not that interesting for a configuration datastore.  Maybe
it should be possible for the server to reject requests with a
dampening period in this case?

> and I am not really sure it actually helps the client that much.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Thu, 16 Aug 2018 13:08:44 -0700

> dampening period in this case?

The dampening parameter is mandatory-to-implement for the server.
I suspect there will be many restrictions that may be difficult for the
client to predict.
For example, will servers really implement a timer or detect changes at the
leaf level?
One timer per list or container is bad enough. I doubt firmware will report
statistics updates
at the leaf level.

I can imagine developers ignoring what the RFC says and using 1 timer per
subscription or
1 timer per container/list (at most).  A very useful compromise is for the
server to implement a periodic update, except do not send anything unless
there was a change (so on-change sends at most 1 update per period,
where periodic always sends 1 update per period)

Andy

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 16 Aug 2018 20:49:09 +0000

Hi Andy,

Cisco has on-change implemented, and has been in production since January:
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/prog/configuration/167/b_167_programmability_cg/model_driven_telemetry.html

A dampening period is optional (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 <[email-masked]> On Behalf Of Andy Bierman
Sent: Thursday, August 16, 2018 1:59 PM
To: Netconf <[email-masked]>
Subject: [Netconf] yang-push-17 on-change subscriptions

Hi,

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

Andy

---

From: Andy Bierman <[email-masked]>
Date: Thu, 16 Aug 2018 18:32:56 -0700

On Thu, Aug 16, 2018 at 1:49 PM, Eric Voit (evoit) <[email-masked]> wrote:

> https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/prog/
> configuration/167/b_167_programmability_cg/model_driven_telemetry.html
>
>
>
> A dampening period is optional (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.
>
>
>

The dampening period is per subscription because to do otherwise leads to
extreme resource use
and many corner-cases that require even more resources to resolve.

IMO the "per object" dampening should be removed from the draft and it
should be per-subscription instead.
As a client developer, I would rather have consistent server
implementations than unimplemented requirements
causing lots of variance in server implementations (all vendors trying to
pick their own reasonable subset).

It will be more efficient and easier to manage for the client to set up
multiple subscriptions,
manually managing on-change data-sets.  Even if there is one spinning
counter that causes
the whole subscription to be updated, this will cause the on-change to
degrade to periodic delivery,
containing the spinning counter and whatever else changed in the dampening
period.

Most importantly, this does not require massive resources to implement and
does not have out-of-order
corner-cases that can occur with per-object dampening.

Andy

>
>
> *From:* Netconf <[email-masked]> *On Behalf Of *Andy Bierman
> *Sent:* Thursday, August 16, 2018 1:59 PM
> *To:* Netconf <[email-masked]>
> *Subject:* [Netconf] yang-push-17 on-change subscriptions
>
>
>
> Hi,
>
>
>
>
>

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 17 Aug 2018 09:48:25 +0200 (CEST)

Hi,

"Eric Voit \(evoit\)" <evoit=[email-masked]> 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.

/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: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 17 Aug 2018 13:40:43 +0000

> From: Martin Bjorklund, August 17, 2018 3:48 AM
> 
> Hi,
> 
> 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

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

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 17 Aug 2018 16:08:06 +0200 (CEST)

Hi,

"Eric Voit (evoit)" <[email-masked]> wrote:
> > and no
> 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.
> 
> 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

---

From: Andy Bierman <[email-masked]>
Date: Sat, 18 Aug 2018 10:22:35 -0700

Hi,

I would like to clarify sec. 3.3. para 5.
The text is confusing wrt/ the dampening period is per-object or
per-subscription.

   Once an update record for a given object is generated, no
   other updates for this particular subscription will be created until
   the end of the dampening period.  Values sent at the end of the
   dampening period are the current values of all changed objects which
   are current at the time the dampening period expires.

The first sentence makes me think the dampening period is per-object, but
the 2nd sentence
seems the say "the" dampening period (meaning 1 of them) applies to "all
changed objects".

Suggest:

OLD:

 Once an update record for a given object is generated,

NEW:

 Once an update record for any object in the subscription is generated,

Andy

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Sat, 18 Aug 2018 19:02:36 +0000

Agree this change should be made.

Eric

From: Andy Bierman <[email-masked]>
Sent: Saturday, August 18, 2018 1:23 PM
To: Martin Bjorklund <[email-masked]>
Cc: Eric Voit (evoit) <[email-masked]>; Netconf <[email-masked]>
Subject: Re: [Netconf] yang-push-17 on-change subscriptions

Hi,

I would like to clarify sec. 3.3. para 5.
The text is confusing wrt/ the dampening period is per-object or per-subscription.

The first sentence makes me think the dampening period is per-object, but the 2nd sentence
seems the say "the" dampening period (meaning 1 of them) applies to "all changed objects".

Suggest:

OLD:

NEW:

Andy

On Fri, Aug 17, 2018 at 7:08 AM, Martin Bjorklund <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

"Eric Voit (evoit)" <[email-masked]<mailto:[email-masked]>> wrote:
> > "Eric Voit \(evoit\)" <evoit=[email-masked]<mailto:[email-masked]>> wrote:

I agree.

/martin

> > > From: Netconf <[email-masked]<mailto:[email-masked]>> On Behalf Of Andy Bierman
> > > To: Netconf <[email-masked]<mailto:[email-masked]>>