Re: [netconf] Adoption poll for draft-tgraf-netconf-yang-notifications-versioning

[Benoit Claise <[e-mail]>]

Dear all,

Typically, I try to avoid sending a message such as "As co-author, I 
support ..." which doesn't carry much weight IMO.

However, I have been observing the discussion and it's about time to 
share my views.

First, it seems that we have mixing the WG Call of Adoption of this 
draft with the "Joint WGLC on "semver" and "module-versioning" drafts" 
in NETMOD.
Granted, the two issues are linked but I don't see the point to redo the 
NETMOD WGLC on this NETCONF new draft.
This draft is not about supporting multiple YANG module revisions in a 
server.

My interest in this draft is about YANG-PUSH tooling. Exactly like I can 
directly onboard a new IPFIX router to the analytic system:
     - Template Records and Flow Records are sent automatically from the 
router,
     - basically, the IPFIX Flow Records, with the IPFIX Information 
Elements and Template Record semantic are automatically known to the 
Collector and most importantly to the analytic tool.
     - the data processing chain can digest the information

YANG-PUSH is currently changing, with UDP export 
(draft-ietf-netconf-udp-notif), with distributed export from line card 
(draft-ietf-netconf-distributed-notif*)
*You see the analogy with IPFIX. Similarly to IPFIX toolchain, we need 
to ingest any new router with YANG-PUSH subscription automatically into 
the analytic system.  This justifies the addition of revision/revision 
labels in YANG-PUSH.
Granted, we could be sending YANG-PUSH without those fields, then use 
the IETF-YANG-LIBRARY to understand the revision, and keep a lookup 
table in YANG-PUSH receiver ... as long as the router has not changed: 
no software update, no reboot, no offline. Basically ,we constantly need 
to check that nothing has changed. (remember the interface counter SNMP 
Polling with sysUpTime discontinuity counter).

If the router is upgraded with NBC YANG modules (and yes, that could 
happen) , it's best to stop streaming those 
not-supported-by-the-pipeline YANG module (revisions). Hence the 
revision selection. We have to stop thinking that the end goal is for 
the routers to spit telemetry data. The end goal is that the entire 
onboarding/collection system up to analytics, can make sense of the 
telemetry data.  So yes, having garbage in my analytic system is a big 
deal. In other words, we don't want to break the end to end data 
processing chain (the pipeline) b/c of NBC YANG modules.

So, in case it is not obvious, I support the WG call for adoption based 
on these valid use cases. :-)

Regards, Benoit

On 5/30/2023 1:09 PM, Rob Wilton (rwilton) wrote:
> Hi,
>
> I think that it would be helpful to decouple the discussion about whether the YANG version number should be changed to the NETMOD WGLC review of the module versioning draft.  I don't think that part of the discussion is particularly relevant to the adoption call for this document.
>
> My understanding of the goal here is to make it easier to export network device telemetry data (exposed via YANG push) in a way that can integrate well with message bus services like Kafka.  I think that this is a good aim for the industry, and thus I support efforts (like this draft) to try and achieve this.
>
> I'm not intimately familiar with Kafka but I understand that it assumes that schema for the data being published can changed over time (e.g., perhaps due to a software upgrade on a publisher, or different instances of publishers running slightly different versions of software).  Hence Kafka maintains a schema registry and allows a reference to the schema to be associated with the published data records.  This allows entities in the data pipeline to check and confirm that the telemetry data conforms to the schema, and potentially to handle the data differently, if needed.
>
> I appreciate that RFC 6020 and RFC 7950 both are defined to try and ensure that YANG definitions only evolve in a backwards compatible way, but I see many examples within the wider industry and some examples in standards bodies where definitions are changed in ways that may impact clients.
>
> Hence, I think that this problem space, and draft, is about how to easily/robustly connect YANG data sources into Kafka data buses:
> - one choice is to do this entirely off the box, having the entities managing the subscriptions also tracking changes to the device schema (e.g., through subscribing to YANG library updates).  Perhaps this can be made to work, but probably adds additional timing complexity relating to when the subscriptions actually start sending data relative to receiving notifications that the content in YANG library has changed.  Another choice here could be to always tear down all subscriptions if the device schema changes at all.
> - the alternative is to augment the subscription-started/modified notifications to give an indication that the data for that subscription has changed.  All data sent before this notification uses a previous schema, and all data sent after that notification uses the new schema.  This allows the schema to change without completely tearing down existing subscriptions.
>
> I'm less sure about the ability to restrict subscription requests to particular versions.  At a minimum I would suggest putting this under a feature statement, but I'm not quite sure whether it should be needed at all.
>
> I also agree with Andy's comment that we need to resolve how the revision-date/label applies to all the potential data under a subscription.  To reuse part of Andy's example:
>
>     <A:top>
>        <B:list1 />
>           <C:container1 />
>     <A:top>
>
> If the subscription is to B/list1, but during upgrade the only change was to the contents of C:container1 then for the subscription the revision-date/label for B:list1 wouldn't have changed, but the data received in the subscription would have changed.  I.e., at the moment, YANG has no way to version everything under a subscription.  Hence, I think that the notification would need to list all the module versions that are being used by the subscription, but I'm not convinced that is easy to do in practice.  The alternative would be to just version the entire schema of the datastore (e.g., either a YANG library checksum, or a version label for a YANG package instance that represents the datastore schema), but this has the downside that all subscriptions would see a reported change in schema if any single module is changed on the device, even one that isn't being used (directly or indirectly) by the subscription.  But then an off-device tool can figure out if the actual schema for the subscription has changed.
>
> In summary, I support NETCONF working in this space, and I believe that this draft is a reasonable starting point, but it still requires some refinement, which could be done as part of the WG work on this problem.
>
> Rob
>
> // As an individual contributor.
>
>
>> -----Original Message-----
>> From: netconf<[e-mail]>  On Behalf Of Jürgen Schönwälder
>> Sent: 22 May 2023 19:25
>> To: Camilo Cardona<[e-mail]>
>> Cc: netconf<[e-mail]>; netconf-chairs<[e-mail]>
>> Subject: Re: [netconf] Adoption poll for draft-tgraf-netconf-yang-notifications-
>> versioning
>>
>> On Mon, May 22, 2023 at 12:43:20PM -0500, Camilo Cardona wrote:
>>
>>> - I like the insights shared by Jürgen and Andy regarding how hacky
>>>    versioning is for YANG 1.1. It makes sense, but I guess nobody
>>>    wants to start a 1.2 project..
>> If it is too hard to change the YANG version number, why should I
>> believe it will be easy to change all the future module version
>> numbers?
>>
>> If people are serious about versioning, the first thing they should
>> do is proposing to bump the YANG version number when they make
>> incompatible changes.
>>
>> /js
>>
>> --
>> Jürgen Schönwälder              Constructor University Bremen gGmbH
>> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
>> Fax:   [phone]<https://constructor.university/>
>>
>> _______________________________________________
>> netconf mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/netconf
> _______________________________________________
> netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf