[netconf] Re: YANG Push (RFC 8641) on-change example

[Andy Bierman <[e-mail]>]

On Thu, May 23, 2024 at 7:51 AM Rob Wilton (rwilton) <[e-mail]>
wrote:

> Hi Andy,
>
> Please see inline.
>
>
> On 22 May 2024, at 17:21, Andy Bierman <[e-mail]> wrote:
>
>
>
> On Wed, May 22, 2024 at 3:36 AM Rob Wilton (rwilton) <rwilton=
> [e-mail]> wrote:
>
>> Hi,
>>
>>
>>
>> The YANG Push RFC provides the following example for an on-change update.
>>
>> According to the text accompanying the figure 2 in section 3.7, the
>> example is for:
>>
>>
>> “   Figure 1 provides an example of a notification message for a
>>
>>    subscription tracking the operational status of a single Ethernet
>>
>>    interface (per [RFC8343 <https://www.rfc-editor.org/rfc/rfc8343>]).  This notification message is encoded XML
>>
>>    [W3C.REC-xml-20081126 <https://www.rfc-editor.org/rfc/rfc8641#ref-W3C.REC-xml-20081126>] over …”
>>
>>
> I agree that a replace on the ancestor node is not correct.
>
>
> Okay.
>


The example is correct if the operation is changed to "merge"


>
>
> I cannot find any details on the example filter that was provided to set
> up this subscription.
>
> Thanks for bringing up two of the critical problems with YANG Push that
> need to get fixed.
>
> 1) The arbitrarily complex XPath and subtree filtering mechanisms are NOT
> interoperable since NO SERVER
> actually supports that.  A much more restricted filter is actually
> supported by the industry,
> except restricted differently for every server.
>
>
> Agreed.
>
>
>
> A much more useful filter would be based on a subset of instances of a
> single object.
>
> Since multiple subscriptions are allowed, there is no need to pile all
> objects into a single filter anyway.
>
>
> I'm not sure on this.  I think that it would be helpful to get input from
> the operators that are planning on consuming this data to understand what
> they want/need here.  I.e., putting them into a single subscription may be
> beneficial from a resync and sequencing perspective (presuming that there
> is no guarantee on sequencing between subscriptions).
>
>

Agreed.

The operStatus example is a bit odd since fault monitoring is supposed to
be done with an event stream (e.g linkUp/linkDown)

It would be good to know if the application wants the the result of the
patch or the edit list.
If they are just creating a new record to store a data point then examining
individual edits
is just extra work for them.

I cannot find any text that says a patch MUST or SHOULD contain only the
minimum set of
changed nodes.  The server is free to choose whatever edit list they want.
This makes it even harder to use for the application.



>
>
> 2) The YANG Patch reporting mechanism is difficult to use and there are no
> clear guidelines on how
> an on-change update is constructed.  Arbitrarily complex edit lists are
> not useful to telemetry applications
> that just want a new representation of the object subset when it changes
> at all.
>
>
> Yes, I basically agree.  YANG patch may work okay for the config
> datastore, but I think that it is overkill for operational data, where
> really the notification is of existence of a value, or non-existence.
>
>

It requires the application to keep the replicated datastore up to date.


>
>
> E.g., a server may accept only container and list objects for the target.
> The server may not be able to push a single leaf as the target. (This
> example is the RFC is not very good).
>
>
> Yes, also agree.
>
>
>
> New example:
>
> The client monitors /interfaces-state.
> The server reports the /interfaces-state/interface child node changes.
>
> Let's say 10 counters change per interface.
> An edit list with 10 replace operations is complex to generate and complex
> to use.
> Instead, the server reports 1 replace operation on
> /interfaces-state/interface[name='foo'].
>
>
> Yes, agreed.  But given that it is a patch replace operation, it needs to
> include all the data in the subscription under that subtree.
>
>

IMO it is OK for the server to report descendant nodes in the patch.
It does not have to replace the target object every time.

But change my example to:
client monitors /interfaces-state/interface.
server returns patches that replace or merge any interface entry.



> Maybe there is 1 replace interface per update or maybe multiple interfaces.
> The client should expect either case.
> The server should never report a replace on /interfaces-state unless every
> interface is included.
>
> IMO the periodic updates (which do not use YANG Patch) are much more
> usable by the client.
> YANG Push should be changed so the client can request this format for
> on-change updates.
>
>
> Maybe.  The issue here may be representing deleted data.
>

deletes have to be reported explicitly or implicitly within a replace.

The server can report descendant nodes and not a complete interface every
time.

Use case:  Client wants the same APIs that are provided for a periodic
subscription,
except just suppress duplicates.  Report once every dampening period if
anything changed,
instead of once every period even if the last update was identical to the
new update.




>
>  Certainly, I would like to see if there is a more efficient way of
> encoding this data.  I also think that providing a complete single message
> to resync is probably problematic.  It assumes that there is a single
> consistent operational datastore, where for some systems this operational
> data is highly distributed to the individual daemons and hence you can
> never get a consistent very of the operational data, only eventual
> consistency.
>
> But the general sentiment that we should try and improve YANG Push
> on-change encoding I definitely agree with.
>
> Regards,
> Rob
>
>
>
Andy


>
>
> Andy
>
>
> The example notification is given as:
>>
>>   <notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
>>
>>    <eventTime>2017-10-25T08:22:33.44Z</eventTime>
>>
>>    <push-change-update
>>
>>         xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-push">
>>
>>      <id>89</id>
>>
>>      <datastore-changes>
>>
>>        <yang-patch>
>>
>>          <patch-id>0</patch-id>
>>
>>          <edit>
>>
>>            <edit-id>edit1</edit-id>
>>
>>            <operation>replace</operation>
>>
>>            <target>/ietf-interfaces:interfaces</target>
>>
>>            <value>
>>
>>              <interfaces
>>
>>                   xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">
>>
>>                <interface>
>>
>>                  <name>eth0</name>
>>
>>                  <oper-status>down</oper-status>
>>
>>                </interface>
>>
>>              </interfaces>
>>
>>            </value>
>>
>>          </edit>
>>
>>        </yang-patch>
>>
>>      </datastore-changes>
>>
>>    </push-change-update>
>>
>>   </notification>
>>
>>
>>
>> But I would expect a receiver to interpret this replace operation as replacing the entire operational state for all interfaces with a single eth0 interface entry reporting just the oper-status as down.  Is my interpretation correct?
>>
>> Instead, I think that the notification target should have identified only the oper-status leaf on the specific interface.  I.e., the generated notification should instead be:
>>
>>   <notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
>>
>>    <eventTime>2017-10-25T08:22:33.44Z</eventTime>
>>
>>    <push-change-update
>>
>>         xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-push">
>>
>>      <id>89</id>
>>
>>      <datastore-changes>
>>
>>        <yang-patch>
>>
>>          <patch-id>0</patch-id>
>>
>>          <edit>
>>
>>            <edit-id>edit1</edit-id>
>>
>>            <operation>replace</operation>
>>
>>            <target>/ietf-interfaces:interfaces/interface=eth0/oper-status</target>
>>
>>            <value>
>>
>>              <oper-status xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">down</oper-status>
>>
>>            </value>
>>
>>          </edit>
>>
>>        </yang-patch>
>>
>>      </datastore-changes>
>>
>>    </push-change-update>
>>
>>   </notification>
>>
>>
>> If folks agree, then I can file an errata.
>>
>> Regards,
>> Rob
>>
>>
>> _______________________________________________
>> netconf mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>
>
>