Re: [Netmo] Initial topics and areas of work

[Benoit Claise <[e-mail]>]

Dear all,

Let me add some more background info to Rob's examples.
Adrian, hopefully, this will be helpful.

On 11/22/2023 12:27 AM, Rob Wilton (rwilton) wrote:
> Hi Adrain,
>
> Thanks for your input/feedback.
>
> Some comments inline ...
>
>> -----Original Message-----
>> From: Adrian Farrel<[e-mail]>
>> Sent: Tuesday, November 21, 2023 12:15 PM
>> To: Rob Wilton (rwilton)<[e-mail]>;[e-mail]
>> Subject: RE: [Netmo] Initial topics and areas of work
>>
>> Hi,
>>
>> A little surprised to not see more discussion of Rob's initial work list.
...
>
>> Reading the charter (which I think looks otherwise pretty good) I don't see
>> any indication of how items that are beyond, "Incubate ideas," and,
>> "Implement small protocol enhancements," will be processed. Indeed, I don't
>> easily see how work items 1, 3, and 4 fit into the charter: perhaps the
>> meaning of "incubate" needs fleshing out.
> To give some concrete examples, if we take:
>
>> (1) YANG Telemetry/Kafka integration
> Much of the actual protocol updates for this work are already happening on NETCONF and OPSAWG.  I think that work can stay where it is.
> But I also know that operators are actively developing and prototyping this work.  I would like to see presentations about their progress, open-source efforts, what issues they are hitting, what the suggestions are for solutions to those problems.
>
> I also see a little bit of this as going beyond developing a bag of independent protocols and instead trying to develop a coherent set of protocols and associated glue to make everything work together.  Arguably, that hasn't necessarily been something that IETF has been great at, at least over the last few years, and where I think that the IETF is perhaps losing ground to efforts such as OpenConfig.  This could be done in IEPG (but that presumably gets a reduced audience anyway), or in side meetings, but I thought that having a dedicated WG on the main agenda would be a better, more robust, home for these discussions.
The YANG Telemetry/Kafka integration had side meetings for multiple 
IETFs now, with a growing interest.
At each IETF, there is some additional opensource developments. So 
clearly, a group of people dedicates some time on this.
The issues with these meetings are
1. Well, obviously, they are side meetings. "These are unofficial and do 
not appear on the meeting agenda." 
[https://www.ietf.org/how/meetings/side-meetings/]
2. The developments lead to a long series of IETF drafts, which are 
presented independently

  * draft-ietf-netconf-udp-notif
    <https://datatracker.ietf.org/doc/draft-ietf-netconf-udp-notif/>
  * draft-tgraf-netconf-notif-sequencing
    <https://datatracker.ietf.org/doc/draft-tgraf-netconf-notif-sequencing/>
  * draft-ietf-netconf-distributed-notif
    <https://datatracker.ietf.org/doc/draft-ietf-netconf-distributed-notif/>
  * draft-lincla-netconf-yang-library-augmentation
    <https://datatracker.ietf.org/doc/draft-lincla-netconf-yang-library-augmentation/>
  * draft-ahuang-netconf-notif-yang
    <https://datatracker.ietf.org/doc/draft-ahuang-netconf-notif-yang/>
  * draft-ietf-netconf-yang-notifications-versioning
    <https://datatracker.ietf.org/doc/draft-ietf-netconf-yang-notifications-versioning/>
  * draft-netconf-tgraf-yang-push-observation-time
    <https://datatracker.ietf.org/doc/draft-netconf-tgraf-yang-push-observation-time/>
  * draft-netconf-yang-notifications-versioning
    <https://datatracker.ietf.org/doc/draft-netconf-yang-notifications-versioning/>

At first glance, those drafts seem unrelated, as they solve point issues 
from the bigger project.
Having an official IETF meeting looking at the big picture, explaining 
how all this fits together, and showing progress has real value, for the 
IETF and operators.

The two examples below "Anomaly detection and Incident Management" and 
"Digital Map" would fall into the same category IMO: side meeting to 
collect requirements & show progress, issues discovery, multiple drafts 
(I could 4 already for the Digital Map"). One difference with " YANG 
Telemetry/Kafka integration" though: "YANG Telemetry/Kafka integration" 
is way more mature, as it started at IETF 113 IIRC.

Regards, Benoit
>
>> (3) Anomaly detection and Incident management
> I think that this is somewhat at the idea incubation stage but has some interesting ideas and questions about how one identifies and tags incidents and what level of tracing can be tagged to the config & operational data exported from the system.  I put this topic into the incubate ideas stage at the moment, but it could develop into small protocol updates (e.g., to add metadata).
>
>
>> (4) Issues related to deployment/usage of YANG topology modules (e.g.,
>> digital map)
> In this case, I see the work on Digital Map as being a bit more near term research, falling into 3 parts:
> (i) Soliciting the general idea and concept of what problem they are trying to solve and what issues they are hitting.
> (ii) Starting to bring some of the first step parts of the Digital Twin concept in NMRG into the IETF (rather than IRTF).  I thought that the concept of digital twin was a long way out, but now I'm starting to think that some aspects of it may be a bit closer to deployable engineering - although I still question whether a full solution would really be robust or feasible.
> (iii) As part of their work of trying to use IETF topology YANG modules, they are hitting problems with how that model is structured that makes it hard to model what they are trying to achieve, it would be useful to understand whether this is because (a) they are trying to go beyond what RFC 8345 was ever intended to model, or (b) because there are deficiencies in RFC 8345.  If there are deficiencies in RFC 8345, and if there is consensus that they should be fixed, and given I2RS is closed down, then there is a question as to where the best place is to that work (RTGWG or OPSAWG maybe, here, or perhaps a new short lived WG like IVY)
>
> But really, it is input from the operators on what they think that focus should be that I would ideally want to hear.
>
> After these expanded examples, do you still think that the charter needs more clarity on this aspect, and if so, then do you have any suggestions please?
>
> Regards,
> Rob
>
>
>> Cheers,
>> Adrian
>>
>> -----Original Message-----
>> From: Netmo<[e-mail]>  On Behalf Of Rob Wilton (rwilton)
>> Sent: 17 November 2023 11:53
>> To:[e-mail]
>> Subject: [Netmo] Initial topics and areas of work
>>
>> Hi,
>>
>> As per my introduction email, it would be helpful to have list of initial
>> topics and work that this WG will focus on progressing.  This doesn't mean
>> that all agenda time and presentations need to be focussed solely on these
>> topics, but it means which areas the WG intends to primary concentrate on
>> (e.g., if it adopts drafts).
>>
>> Ideally, I think that I'm looking for the top three topics for the WG to
>> focus on, but could be more or less, depending on feedback.
>>
>> Based on the recent side meetings, and other topics that have come up in
>> discussion, I think that some potential topics could be:
>>
>> (1) YANG Telemetry/Kafka integration
>> (2) Issues related to mapping configuration, and agreement on north bound
>> interfaces from the device (protocol and model families)
>> (3) Anomaly detection and Incident management
>> (4) Issues related to deployment/usage of YANG topology modules (e.g.,
>> digital map)
>> (5) Controller architectures for management of pluggable optics (there are
>> several drafts currently in CCAMP)
>> (6) An update of operator requirements on Network Mgmt
>> protocols/modelling
>> within the IETF.  E.g., something like RFC 3535-bis.
>>
>> Are there other topics that the operators are interested in the near term,
>> and which of these topics are most important to focus on?
>>
>> Regards,
>> Rob
>>
>> --
>> Netmo mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/netmo