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

["Rob Wilton (rwilton)" <[e-mail]>]

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]<mailto:[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.


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



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.



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.


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.

 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



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]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>