Minutes IETF120: nmop: Fri 20:00
minutes-120-nmop-202407262000-00

Meeting Minutes Network Management Operations (nmop) WG
Date and time 2024-07-26 20:00
Title Minutes IETF120: nmop: Fri 20:00
State Active
Other versions markdown
Last updated 2024-08-07

minutes-120-nmop-202407262000-00

IETF 120 NMOP (Network Management Operations) Minutes

Chairs: Benoît Claise & Mohamed Boucadair

When: 2024-07-26

Current WG's priorities

  • P1: NETCONF/YANG Push integration with message brokers & time
    series databases
  • P2: Anomaly detection and incident management
  • P3: Issues related to deployment/usage of YANG topology modules
    (e.g., to model a Digital Map)
  • P4: Consider/plan an approach for updating RFC 3535 (collecting
    updated operator requirements for IETF network management solutions)

Compact Agenda

| Slot | Priority Label | Topic | Presenters |
| :-: :-: :-: :-
| 13:00 - 13:05 | | Agenda Bashing & Introduction | Chairs |
| 13:05 - 13:30 | P1 | YANG-Push to Message Broker Integration | Thomas |
| 13:30 - 13:50 | P2 | NMOP Terminology | Adrian |
| 13:50 - 14:10 | P2 | Anomaly detection: Experiments & Roadmap | Thomas/Pierre/Vincenzo |
| 14:10 - 14:25 | P3 | Digital Map Concepts & Requirements | Olga |
| 14:25 - 14:30 | P4 | NEMOPS Workshop | Chairs |
| 14:30 - 14:45 | P4 | Updates to Operators Requirements | Luis |
| 14:45 - 15:55 | | Knowledge Graphs | Nacho |
| 14:55 - 15:00 | | Wrap-up & Future Meetings | Chairs |

Detailed Agenda

1. Agenda Bashing & Introduction (Chairs) (5 min)

Chairs's slides are available here.

No comment about agenda.

2. NETCONF/YANG Push Integration (25 min) starts 1:05

Goals:

  • Experiment status update
  • Share pending issues
  • Next steps

2.1 An Architecture for YANG-Push to Message Broker Integration (20 min)

Slides are available here.

Mahesh: Thank you to have all dependencies in one presentation and going
through the hurdle of not doing it in a monolithic draft.
Suggestion: at the end, bring all the changes in a single document,
instead of reviewing multiple documents for just a couple of lines of
changes. This is just a suggestion.

Thomas: That makes perfectly sense.

Kent: As a NETCONF chair, when would that happen? They are all
individual drafts. Should that happen before they are adopted or at
WGLC?

Mahesh: Whenever the WG agrees that these changes are needed, adopt them
as WG document, and at that point just consolidate.

Olga:

  • I had a comment at NETCONF but there was no time
  • For sysName, it’s very important to have it, other standartization
    bodies have it as well, don’t see how it could work without it.
  • Although we should consider having it at the northbound interface
    from the controller

Thomas: yes to both points. We took sysName from SNMP. Agree that it is
pretty common standard in other bodies as well.

Per: I wonder how it would work with backward compatibiliy (RFC
8639/8641) with existing infrastructure.

Thomas: RFC 9196 describing the system and notification capabilities.
RFC 8641, there is a version number. For the Notification header, we
defined a YANG module, allowing future extensions if the community
agrees.

Alex: Going back to the original discussion when RFC 8639/8641 was
specified, sysName and sequence number were not included because we
assumed there is a reliable transport the YANG-Push receiver could
transform that information. Do you foresee any use on top of unreliable
transport? If not, it would be a luxury to have sequence numbers also on
the messaging layer.

Thomas: We had same question at NETCONF, they are OSI layers we should
not mix among the layers. The sequence number we refer to are related to
the messaging layer. It doesn't matter which transport layer we use:
NETCONF, RESTCONF HTTPS-notif, UDP-notif. Each transport has its own
sequencing number. Messaging has its own sequencing number as well for
end-2-end data processing, starting from YANG-Push publisher to message
broker data consumer for detecting loss and re-ordering and also helps
replicating messagess .

Alex: I will re-read. This argument should be made clear in the draft.

Benoit: Lets take it to the list.

Kent: About extending notification headers: Augmentation to RFC 8639
8641 could improve the YANG-Push part, but that’s not possible for RFC
5277 netconf notification header. In both cases, a capability could be
expressed. Still, it does not mean the client wants those extensions
(ex: legacy client). Recommendation: allow the client to opt into it =>
Subscription request could say whether we want these new headers

Thomas: Perfect input. On the capabilities side, on the notification
draft, we tried to extend all the discovery mechanisms to cover these
cases. On the configurable aspects, we have later in this session the
RFC3535bis discussion where we discuss what are the basic items which
should always be present and which one should be optional. It would be
good to get some feedback from audience.

James Cumming (on the chat): We should probably explicitly state in the
draft that there is no expectation to retransmit any missed messages so
the seq number would be used for detection of missed messages and the
collector side reordering only

Action Points (if any):

  • Mahesh's suggestion: Consolidate multiple drafts into a single one
    whenever we agree on a problem that needs solving

2.2 Q&A (5 min)

3. Anomaly Detection and Incident management (40 min), starts 1:33

Goals:

  • Sync on the approach/rationale and discuss issues related to NMOP
    terminology
  • Report the outcome of the side meeting on NMOP terminology
  • Structure the anomaly detection work & agree on a roadmap for the
    items to be delivered

3.1 Some Key Terms for Network Incident and Problem Management (20 min)

Slides are available here.

Adrian: Open issue #1 "What is the intended scope of this document?"
Rob: If we scope this down now, we are likely to reach consensus now.
Adrian: I tend to agree. The more compact this is, the easier it is to
reach consensus. Additionally, the bigger it is, the more it overlaps
with work in other SDOs making it a multi-dimensional problem.
Rob: I don’t want this document to block other, we should scope this
down, with the possibility of adding things later as needed.

Adrian: Chairs do you think that's what our charter tells us to do?

Benoit: I think so, but let’s ask the room: are we dealing with "network
incident"?

Laurent: Is the intention to have an RFC? Why not a reference to a wiki
page? Will there will be updates?

Adrian: Hard to see if we have consensus on a wiki page. But it is much
more flexible.

Mahesh as contributor: Agree with Rob that we should scope down.

Poll: Do you agree with Adrian's conclusion on the intended scope ?

74 participants
| Answer | Count |
|:------:|:-----:|
| yes| 32 |
| no| 0 |
|no opinion| 1 |

Benoit: This looks very supportive with no disagreement.

Kent: I didn't understand the question.

Adrian: Since the poll was phrased as "do you agree with Adrian's
conclusion" perhaps I should state my conclusion: that we should scope
down to network related terminology.

Adrian: unless I hear otherwise, I will assume that we are scoping own
like this.

Adrian: Open issue #2 "Who is the consumer of this work?"

Alex: It is necessary to harmonize terms with other bodies (specifically
ITIL). Should look at and potentially adopt.

Adrian: "Look at", I agree. ITIL is substantially at the service
interface. Nevertheless, if we find a term already defined, and we like
it, we should harmonise. If we find that 2 bodies use the same terms in
different meaning, then i don't know what we would do.

Alex: Agree that ITIL is on the service layer.

Mahesh: From a process perspective, how would you do this across the
IETF, which groups would you target? How to find terms in other RFCs and
will they line up?

Adrian: We need to get closer to consensus and then bring other people
in. Ultimately, we have an IETF last call.

Rob: I agree with this proposal. It looks pragmatic. In terms of
referencing terms from other RFCs, it would be nice to have the text
(maybe an informative copy) all in one place.

Poll: Do you agree with the overall proposed "possible conclusions" as
described on slide 6?

Mahesh: I'm still confused.

Adrian: Possible conclusion is "we target the first option; other things
might come along, but that is not our main thrust"

74 participants
| Answer | Count |
|:------:|:-----:|
| yes| 28 |
| no| 0 |
|no opinion| 2 |

Joseph: A lot of ticketing and monitoring systems are based on these
standards (ITIL, etc.) and use those terminologies. need to avoid having
different names for the same things.

Adrian: Got the answer, but I hear there is a little bit of caution on
this one.

Action Points (if any):

  • Scope reduced to network terms

3.2 Anomaly Detection (20 min)

3.2.2 An Architecture for a Network Anomaly Detection Framework (15 min) starts 1:54

Slides are available here.

3.2.3 Q&A (5 min)

Poll: Did you read draft-netana-nmop-network-anomaly-architecture?
74 participants
| Answer | Count |
|:------:|:-----:|
| yes| 12 |
| no| 15 |
|no opinion| 0 |

Poll: Do you support adopting
draft-netana-nmop-network-anomaly-architecture as an anchor to the
anomaly detection work in the WG?
75 participants
| Answer | Count |
|:------:|:-----:|
| yes| 23 |
| no| 0 |
|no opinion| 13 |

Action Points (if any):

Goals:

  • Share status update
  • Agree on the next steps

4.1 Digital Map: Concepts & Requirements (10 min)

Slides are available here.

4.2 Q&A (5 min)

Med: Let’s start a poll to see how the room feels about adoption

Italo: It is a good idea to split the concepts from the discussion.
Interaction between this and other use cases. are they going to be
addressed together, is it blocking for adoption?

Nacho: Should elaborate more on the relation with digital twin in NMRG.

Have the impression that this document is too much focused on the
topology, how to relate with other data such as SAIN or inventory?

Diego: Agree. This is much more general than a Digital Twin, is more
into a model of the overall network.

Olga: Looking for more feedback on the mailing list.

Poll: Do you object to the WG adoption of
draft-havel-nmop-digital-map-concept?
74 participants
| Answer | Count |
|:------:|:-----:|
| yes| 2 |
| no| 18 |
|no opinion| 8 |

Dan: On the "too much focused on toplogy", we’re not saying to not focus
on topology. It is needed.

Olga: Topology is the core from where different use cases can be covered
from.

Andrew Stone: Is their an intention to show the binding between
resources used between layers?

Olga: That would be captured in the modeling and solutions part.

Andrew: Capturing mapping between layers has been a challenge. Would
like to see that in the draft.

Olga: This document takes out definintions from other document, please
send your requirements.

Med: We have 2 objecting the adoption, if they can go to the mike?

Nacho: Too focused on topology as said earlier.

Med: Please feel free to send comments or modifications to the text, I
fully agree with this work. There’s a lot of work to do here.

Rob: Negative question, weird.

Benoit: Was to make sure nobody opposes.

Poll: Do you support the WG adoption of
draft-havel-nmop-digital-map-concept?
75 participants
| Answer | Count |
|:------:|:-----:|
| yes| 18 |
| no| 0 |
|no opinion| 15 |

Rob: Wasn’t clear that 8345-bis is the necessary step to go forward
with? Seem to have a wide impact on other modules. We need to treat this
carefully not to have modelled twice.

Olga: Majority of drafts seem to not need to be changed.
Completely generic digital map will not be possible because the
modelling of specific use case was done in a specific way. There is a
problem with 11 out of 52 modules which have the topology concept
defined in their own way.

Rob: I understood that in this 11 it was possible but complexity is very
high.
Olga: Minor changes in the core are needed. They are ways to align it
without breaking backward compatibility.

Action Points (if any): XXXX

5. Collecting Updated Operator Requirements for IETF Network Management Solutions (20 min) starts 2:30

Goals:

  • Updates on the NEMOPS IAB Workshop
  • Updates and Plans to meet NMOP-specific charter item, especially the
    following milestone:

Sep 2024 Adopt a document on updated operators requirements

5.1 NEMOPS IAB Workshop (5 min)

5.2 An Update of Operators Requirements on Network Management Protocols and Modelling (15 min) starts 2:33

Slides are available here.

Rob: Would suggest we keep individual draft. Otherwise would bias the
process into the workshop.

Mahesh: RFC 3535 captured requirements of the workshop. The document
still can be an input to NMOP.

Laurent: Let the workshop happen and see from there. We should avoid to
come in parallel to different conclusions.

Benoit: Do you think that input to IAB workshop is important?

Laurent: Yes, as an individual opinion

Rüdiger: #1 and #2 not mutually exclusive. Trying to establish a working
group concensus before the IAB workshop doesn't make much sense to me.
The outcome of the workshop might not relate to the document proposed
next steps.

Nils: It is good to have this document as an input for the IAB workshop.
We need to avoid that this working group comes to a different consensus
then the IAB workshop. Therefore keep it as an individual document.

Rob: If we do adopt it and send it to the IAB, I would expect a WGLC
before we send it to the IAB. And I don’t expect that we will reach
consensus.

Qin: Important to send the information to the IAB.

Benoit: Unless we say otherwise, no objection to send the input.
Question is whether as individual or as a WG document.

Poll: Do you support adopting draft-boucadair-nmop-rfc3535-20years-later
with the assumption that it may not be published as an RFC (if all
feedback is captured in the IAB report, WG decides no need for building
IETF consensus on specific items)?
71 participants
| Answer | Count |
|:------:|:-----:|
| yes| 8 |
| no| 12 |
|no opinion| 7 |

6. Misc.

6.1 Knowledge Graphs for YANG-based Network Management (10 min) start 2:46
  • Presenter: Ignacio Dominguez Martinez-Casanueva
  • Reading Material: draft-marcas-nmop-knowledge-graph-yang
  • Discussion: Share plans for experiments, hackathons, link with
    other items/current WG priorities, etc.

Slides are available here.

Rob: Really interesting idea. Looking forward to IETF 121.

7. Next Meetings & Wrap-up (All) (5 min) starts 2:55

  • Next scheduled interim: September 11 (anomaly detection)
  • Discussion: Preference to have other interims? Monthly interims
    dedicated to each items?

Benoit: Interim meeting on September 11 for network anomaly. What does
the WG think about having an interim meeting for digital map as well?

Dan: YES, one single meeting is too dense to digest and discuss
everything. Interims gives us more room to interact.

Benoit: Which one, YANG-push, digital map?

Dan: Both, YANG-push and digital map together. They are related.

Rob: There’s a concept part of digital map and an IETF ops in terms of
how we update the drafts

Italo: Definitely need more discussion on digital map. Not clear that
interim is better than weekly meetings as in IVY.

Benoit: Which weekly meeting?

Italo: An informal weekly meeting open to anybody.

Oscar: Was nice to collaborate to prepare this NMOP, maybe we need to
keep the momentum.

Adrian: I expect it will be useful to have interim meetings to prepare
terminology. Not ready to schedule one though since I need more time to
progress. I'd like to collect issues that need discussion and then come
to the chairs for an interim.

Benoit: You had 14 in your side meeting. These look like the key
contributors and they should sort things out themselves. Please
self-organise and loop back to WG.

Olga: Need to continue discussion, need to agree the use case. In regard
to weekly statuses, might be too often but maybe monthly.

Dan: This whole work is taking way too long. Having regular meetings is
very much needed because of this reason.