NMOP

Session 1

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

• We have our first RFC: https://datatracker.ietf.org/doc/rfc9940/

Milestones

• Submit SIMAP concept to IESG (happening soon).
• Message broker architecture and anomaly management: dates still
  marked with question marks, to be discussed.
• Network incident management: targeted for November.
• Already-achieved milestones listed at the bottom of the slide.

Document Dependencies

• Email sent ~1 month ago about dependencies between NMOP documents
  and external ones.
• 8 documents (in yellow) are normative references located in NETCONF,
  NETMOD, and OPSAWG.
• Slide indicates status and action holder for each dependency.
• 3 documents (circled) have no pending normative references → can
  proceed independently.
• Documents with dependencies cannot fully advance until the
  referenced external documents progress.
• WGLC will be closed, but final advancement depends on progress of
  referenced documents.
• After this IETF, chairs will meet with authors to decide when to
  advance.
• The 3 anomaly detection documents (dependent on message broker) will
  advance afterward.

Chongfeng Xie asked: given several AI-agent-related presentations on the
agenda (and similar sessions across other WGs this week), what is NMOP's
role going forward, will it be a major venue for AI agent discussions,
or just a temporary home?
Chairs' response:

• Topic will be addressed in more detail in Session 2.
  Chairs are still figuring out where AI-related documents should
  ultimately be published.

• Plan (agreed with the AD) for Session 2: contact authors of
  AI-related drafts and ask:

  • How is their work progressing as an experiment?
  • What is the scope of the experiment?
  • Are they engaging with/planning open-source code?

• Goal: gather enough info to consider opening/updating the charter
  for a specific, experimental AI focus within NMOP.

AI (Done on August 3rd): chairs to send email to NMOP mailing list

2. YANG-Push to Message Broker Integration (15 mins)
Presenter: Thomas Graf
Reading Material:
draft-ietf-nmop-yang-message-broker-integration and
draft-ietf-message-broker-telemetry-message

Document Updates

Two new revisions: -12 and -13.

• Rev 12: completed security and operational considerations sections.
• Rev 13: incorporated feedback from implementers of the YANG message
  broker consumer side.
• Message broker integration and telemetry message documents are
  believed ready for Working Group Last Call (WGLC).

Reshad Rahman: did any of the message broker document already received a
YANG doctors early review?
Thomas Graf: Yes, the telemetry message received a YANG doctors early
and the message broker received a ops directorate early review.

Message Key Document

• Adopted by the working group at IETF 125.
• Updates (including open-source proof-of-concept code) to be
  presented later by Ahmed.
• Authors believe this document should follow after the telemetry
  message and message broker integration docs
• three docs proposed for first WGLC (message broker integration,
  telemetry message, message key), suggestion to do message key
  afterward, since it's newer/less stable (first proof-of-concept
  stage only). Agreed.

3. YANG Message Keys for Message Broker Integration (10 mins)
Presenter: Ahmed Elhassany
Reading Material: draft-netana-nmop-yang-message-broker-message-key

• Three-phase algorithm for keys
• Deterministic and collision-free (with hashing) topic derivation

Reshad asked for clarification on a point regarding Phase 1,
specifically how multiple subtree paths become a union of XPath
expressions.
Clarification given:

• In subtree filtering, it's possible to extract more than one subtree
  at once.
• When converting these subtrees to XPath, they are combined using
  XPath's union operator, producing a single combined expression from
  the multiple extracted subtrees

Rob Wilton commented (slide 6):

• Agrees with the algorithm/approach presented.
• There's no guarantee that YANG prefixes are unique. They often are,
  but not guaranteed.

Ahmed Elhassany: I agree. Because of this, the system must always fall
back to the actual subscription in the metadata. If there's a collision,
hashing must be used, noted that the last step of the algorithm was
already hashing to handle collisions. Guaranteeing full uniqueness would
require the full XPath / full YANG schema again, which is undesirable,
the point of having a metadata database is to be able to just look
values up there instead.

Rob Wilton: If you knew all the YANG modules/schemas involved across
devices in advance, you could run a uniqueness check on prefixes across
all of them, and in cases of conflict, allocate alternative prefixes to
restore uniqueness.
Ahmed Elhassany: Agrees it's technically possible, but raised concern
about feasibility at scale, with many vendors and many different
devices, doing this comprehensively becomes difficult.

Thomas Graf: Rob mentioned this already in previous IETF sessions. We
have looked into alternatives to YANG prefix and concluded that only the
YANG namespace is unique, however too long to be considered for topic
naming. The YANG module name is only unique within a YANG datastore on a
single network node and not accross the network. Therefore if the YANG
prefix would not be unique, hashing of the topic name is the proposed
way forward. We are looking forward from the NMOP community for more
reviews and feedback.
Rob Wilton: YANG module names should be unique across vendors.
Ahmed Elhassany: We have to account for these names not to be unique.
Thomas Graf: we have to consider YANG modules across the network (not
just per-device)

4. YANG data model for Network Incident Management (10 mins)
Presenter: Qin Wu
Reading Material:
draft-ietf-nmop-network-incident-yang

• Clarified relationship with network anomaly architecture document
• Added operational consideration section. Support both incident
  number and triple.

Reshad raised a question about why the incident number (a unique 64-bit
value per YANG model) is not used as the key. Asked if this is because
the incident number isn't always present in every case (some cases only
have the "triple" instead).

Presenter response:

• Confirmed the incident number can coexist with other identifiers.
• for IPC and notifications, need a single primary identifier for
  incidents.
• Similar to how SRv6 has a way to identify the whole end-to-end path,
  functionally equivalent concept applied here.

Reshad Rahman: I still don't understand why the 64-bit incident number
is not the key. Also we have both incident number and incident id
(string which can be empty according to the document), a bit confusing.
I'll follow up offline.

Qin Wu:

• We got comments from both chairs and would like a YANG Doctor
  review.
• Ready for WGLC?

Benoit Claise: As document shepherd, thanks for addressing the review
comments. I need to do some more checks before we decide on next step.

Reshad Rahman: once agreed to changes are made and Benoit gives thumbs
up, we can request YANG Doctor review.

AI: Chairs to review the latest revision and proceed accordingly

5. Network Anomaly Detection (10 mins)
Presenter: Thomas Graf
Reading Material:
draft-ietf-nmop-network-anomaly-architecture,
draft-ietf-nmop-network-anomaly-lifecycle and
draft-ietf-nmop-network-anomaly-semantics

• For the architecture, references to SIMAP and Knowledge Graph
  documents were changed from normative to informative.
• For semantics, the draft simplified the abstract and prefix names,
  added instance data examples, and introduced a temporary
  ietf-network-anomaly-service-topology module until permanent
  service models are defined.
• For the lifecycle draft, the transition between validation and
  refinement was clarified, and topic/subject name constraints were
  aligned with the message broker naming work.

Benoit Claise: which documents have actually been updated to implement
the mapping, just the architecture document, or the others (semantics,
lifecycle/workflow) as well?
Thomas Graf: the update explaining how the incident maps to the relevant
state notification on the anomaly detection system has been made on the
network incident draft side.
Benoit clarified/confirmed: so the anomaly detection documents
themselves (architecture, semantics, lifecycle) have not been updated to
point back to the incidents, only the network incident draft has been
updated.
Benoit Claise: have you been updated any of your drafts to point to the
incident draft from Qin?
Thomas Graf: no. There is only a reference from the incident draft to
draft-ietf-nmop-network-anomaly-architecture, not the reverse

Reshad Rahman: when would be a good time to go working group last call?

Thomas Graf: since the documents have a normative reference to message
broker, we suggest to do them afterwards. In the meanwhile a YANG
doctors early review would be helpful and we are looking forward to
bring more input from the postmortem system proof of concept with Vivek
from INSA Lyon.
Benoit Claise: would it make sense to request same YANG Doctor as for
the message broker documents?
Thomas Graf: not necessarily since there is only a minor reference.

AI: Chairs to request early YANG Doctor review

Reshad Rahman: suite of 3 SIMAP YANG presentations follows.
6. SIMAP YANG based on RFC8345 (10 mins)
Presenter: Olga Havel
Reading Material: draft-ietf-nmop-simap-concept
draft-havel-nmop-simap-yang

• Presented overview of the options which were investigated
• Favours option 4 where one of the 2 approaches is used depending on
  the usecase

Reshad Rahman: Asked which specific SIMAP draft was being referred to as
the "generic way" (the first of two approaches mentioned).
Olga's answer: refers to RFC 8345 extensions, not yet an RFC itself, but
a proposal the group is working on. The base draft is an initial draft,
open for proper review. Some extensions are being proposed, based on the
existing RFC 8345 terminology.
Reshad Rahman: asked if the second "detailed" approach refers to
existing TE-based YANG models?
Olga confirmed: yes.
Olga added clarification: TE (Traffic Engineering) YANG is used for
traffic engineering purposes because it has the necessary attributes.
However, once tunnels/paths are created, SIMAP sees them differently, as
layered links with supporting links.
As a result, SIMAP would have no impact in the optical domain, except
potentially for declarative intents and similar mechanisms.

Dan Voyer commented in support of Option 4:

• Said it makes sense from an operator perspective to use this option
  as a core foundation for SIMAP.

Nigel Davis supports for Option 4:

• Called it a pragmatic choice.
• Said it provides the right foundation/shape to build quite different
  topologies, including optical and others.

7. SIMAP YANG based on RFC8795 (10 mins)
Presenter: Italo Busi
Reading Material:
draft-busi-nmop-simap-rfc8795-applicability

• Applicability of TE YANG for SIMAP
• Uses profiles (WIP in TEAS)
• Multi-vendor integration issues with app-specific data models

Reshad Rahman: Confirming with presenter for everyone to understand
profiles:
The example shown uses the same YANG module across different
applications, even though each application doesn't support/use all of
its attributes.
It's the same schema, just conveyed to consumers via something like
customer documentation describing which attributes are relevant.
In the presenter's PoC: took the YANG tree from RFC 8795, and manually
removed leaves that weren't needed, sometimes resulting in a much
shorter tree. In this draft, this pruning was represented using
deviation statements.
It is the same model, same namespace, not a different module.
It's simply indicating which attributes are needed/used for a given
application.

Thomas Graf: I would say it's the same module but a different schema
tree, do you agree?
Italo Busi: That is a fair statement.

Benoit Claise:

• Confirmed the purpose of using profiles is that implementers don't
  want/need to implement the entire attribute set.
• That's why the tree is pruned rather than loading everything.
  Presenter confirmed.

Nigel Davis: I support your assertion that doing YANG modules is not
sufficient for interop.

Rob Wilton:

• Noted the presenter mentioned needing to create a new version of the
  module (RFC8795)
• Asked whether this is because:
  • The existing module needs to coexist for other use cases (as a
    separate thing), or
  • The concern is about not wanting to break the existing module.

Presenter clarified: This is specifically about the topology module, the
idea would be to split one model (with e.g. four attributes) into
multiple modules. This would mean existing attributes become deprecated,
since they'd now sit in a different namespace.

Olga Havel:
We agreed for the excercise to look at the 5 requirements and to show
the module, similar to what was demonstrated during the hackathon for IP
and other domains.

Italo Busi:

• Clarified that the draft is not intended to provide a complete
  analysis of all use cases or requirements.
• The current work started with a limited set of use cases (e.g.,
  bidirectional links and multipoint links), and the analysis is still
  ongoing.
• Explained that the draft includes an appendix showing examples of
  deviation statements that create a pruned version of the YANG tree
  for specific use cases.
• Emphasized that this is a significant amount of work and should only
  continue if there is interest in reusing RFC 8795.
• If the working group decides to pursue a different direction, he
  believes there is little value in continuing such a detailed
  applicability analysis. We need to continue the analysis.
• Stated that the analysis is still incomplete because the group does
  not yet have a clear understanding of which requirements are already
  satisfied by RFC 8795 and which are not.

Dieter Beller: Is Italo in favor of an approach that leverages existing
YANG modules as much as we can, rather than creating new ones,
potentially extending existing modules where needed? And that profiling
essentially means deviating out attributes not needed for a specific
application?
Italo confirmed: Correct.

8. SIMAP YANG discussions (15 mins)
Presenter: Reshad Rahman (as co-chair)

• Option 1 (common approach): no agreement between the 2 author groups
• Perceived pros/cons of options 2 and 3

Thomas Graf: in slide 8 of network anomaly presentation there's the
schema tree. My understanding of option 3 is that I may not be able to
refer to the topology, because I can't refer to a stable YANG schema
tree. This is an interoperability issue.
Reshad Rahman: I believe you are correct.
Italo Busi: For a node anomaly there's no issue. For a path anomaly, I'm
not sure how we could be missing data.
Thomas Graf: let's say it's an anomaly on a L2VPN or L3VPN service. At
operator level, we provide connectivity at the VPN level.
Reshad Rahman: needs further discussions.
Olga Havel: with RFC8345-based solution it won't matter. Could align
service and anomalities without to understand specific implementations
(tunnel, link, VPN-link issues) with the same reference points.
Otherwise you have to understand underlay, TTP, tunnel and potentially
different ones for data center.
Rob Wilton: caution regarding the use of "deviations" to profile models,
YANG deviations are intended to describe platform-specific
non-conformance rather than defining new standard specifications. Maybe
we need to go back to NETMOD with a request for a nw mechanism to
achieve this.

Poll question on whether to go with option 4, rough consensus is to go
with option 4.

Nigel Davis: Overlap is a common issue, we need to get better on how we
deal with that e.g. migration path.

AI: Chairs to send an email on how the SIMAP-YANG documents will
progress

9. NMRG and NMOP (10 mins)
Presenter: Jéferson Nobre
Rob commented on collaboration between working groups/research groups:

• Recalled that when NMOP was originally set up a few years ago, a
  similar discussion arose about dividing work between operational
  (IETF) and research (IRTF) tracks.
  The distinction landed on:
• NMOP: anything operators need in a near-term timeframe (~1–2 years),
  practical problems to solve now.
• NMRG: longer-term work, more like a 5-year-out horizon.
  Raised a concern specifically about AI: given how fast AI is moving,
  there isn't time to wait for the longer research-track timeline.
  Suggested he'd like to see experiments on how operators are using AI
  land within NMOP or elsewhere in the IETF, rather than in the IRTF.

Thomas Graf:

• Agreed that NMOP is doing experiments, and this should be shared
  with NMRG.
• Suggested NMOP should also start doing some explanation/sharing of
  its work with NMRG, and vice versa.

Diego Lopez:

• Suggested it would be ideal, since NMOP is a group oriented toward
  experimentation, to collect ideas coming out of NMRG and identify
  which experiments would be most interesting to pursue further within
  NMOP's work.
• Framed this as something practical: essentially saying "we'd like
  you (NMRG) to look into this particular area/topic" as a way of
  directing collaborative focus.

From the chat:
Dan Voyer
it feels like NMRG is not going fast enough in being ahead of nmop,
hence why the idea of merge

Alex Huang Feng
I agree with Rob, the difference is about the timeframe

Benoît Claise
timeframe ... and focus I would say. By "focus", I mean for example
hackathon commitments

Thomas Graf
@Dan, as Jeferson mentioned, IRTF does multiple explorations and does
not have to have consensus on which exploration is the best approach. I
suggest that NMOP and NMRG is collaborating on this aspect. Lets try to
close the timeline gap in order to bring explorations and experiments
more closer together.

Alex Huang Feng
@Benoit, I feel the only difference is really the problems we are trying
to tackle. Both problems (short-term as NMOP and long-term as NMRG) can
use the hackthon to explore PoC

Thomas Graf
@Alex +1

10. BMP YANG Model for Network Telemetry Messages (10 mins)
Presenter: Leonardo Rodoni
Reading Material: draft-netana-nmop-message-broker-bmp-telemetry-msg

Thomas Graf: At IETF 124, in the presentations at GROW and NMOP, we
raised the questions where this work should be adopted. We received
feedback https://datatracker.ietf.org/doc/minutes-125-nmop-202603200100/
from Med as the GROW AD, instead of GROW, NMOP would be better suited.

Mahesh Jethanandani: That's exactly where I wanted to comment. We should
clarify this before moving on with working group adoption at NMOP.

11. Model for distributed authorization policy sharing (10 mins)
Presenter: Lucia Cabanillas Rodriguez
Reading Material:
draft-cabanillas-nmop-authz-policy-sharing-model

Chat:
Mahesh Jethanandani
On the policy-sharing draft, the only question I would have is if there
is an overlap with other authorization/policy work.

Or do you want me to confirm with the RTG ADs?

AI: Chairs and AD to discuss with authors where this document should
reside

Session 2

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

• The chairs introduce the idea of an "AIOPS related experiment in
  NMOP", with potential recharting.
• Qin Wu: He asked whether the scope could be expanded to cover agent
  observability. We had a side meeting on Wed to discuss this agent
  observability and control, along with hackathon results.
• Thomas Graf: He emphasized that AI requires high-quality data. He
  noted that the ongoing data transformation work is relevant and
  should not be overlooked.

2. Swisscom BGP Routing Loop Network Incident (15 mins)
Presenter: Thomas Graf
Reading Material: Swisscom BGP Routing Loop Network Incident

• Boris Khasanov (chat): but why they sent the same attributes in
  different VPNs, what was the root cause ?

  • Thomas Graf: @Boris, the root cause was that multiple instead of
    one site-of-origin attributes were used. If the same
    site-of-origin would have been used, the loop would have been
    prevented.
  • Boris: @Thomas - thanks, i got it. But due to misconfig (all
    VPNs do belong to the same customer)?
  • Thomas: @boris, correct, it was a DCI VPN, connecting multiple
    data center shared services together

• Joe Clarke (chat): Thomas, can you share what model you used? I
  assert that, yes, some LLMs have some networking knowledge. How
  much that is and to what extent vary based on the model. I find
  frontier models like Sonnet/Opus do have a fair amount of
  knowledge up to what I would consider a mid-tier network engineer. I
  find some of the open weight models a bit lacking unless you provide
  more context to them as to how things interact/relate.

  • Thomas: qwem3.5
  • Joe: I haven't tried qwen. I did try gpt-oss-20b. It did okay
    with MCP input, but when asked to do more complex network
    analysis, it did hallucinate elements of BGP operational
    concepts as well as specific ways to extract BGP info (part of
    that maybe that I was using Cisco NX-OS rather than more
    traditional IOS).
  • Thomas Graf: @joe, since we are feeding the LLM's with YANG
    semantics yet, it tries to interpret the leaf names and
    sometimes comes to the wrong conclusions. That was our first
    take after 6 weeks so far. But we will play, especially in a
    postmortem/incident setting more on it and feedback at NMOP IETF
    127.
  • Joe Clarke: Do you also use skills with your data to "teach" the
    agent how to interpret YANG data? I found some value there with
    a YANG skill. I also find it useful with my MCP servers to make
    good use of rich JSON schema to explain the use/meaning of data
    elements.
  • Thomas Graf: @Joe, right now we did minimal manual effort to
    mirror the YANG information to skills. However our intent is to
    use the YANG schema registry MCP. That will not only make the
    YANG semantics available but also guide the agent where data
    needs to be consumed from.

3. AIOPS Side Meeting Logistics and Guidance on AI drafts (5 mins)
Presenter: Mahesh Jethanandani
Reading Material:
AI-Driven Network Operations: Evaluation Guidelines

Alex Huang Feng (chat): a BoF seems like more aligned with the IETF
process no?
Pierre Francois (chat): indeed
Dan Voyer (chat): Yes
Joe Clarke (chat): Yeah. This is starting to feel more like a BoF with
the need for chairs and discussion leads.

4. AI based Network Management Agent (5 mins)
Presenter: Xing Zhao
Reading Material:
draft-zhao-nmop-network-management-agent

• Where is the right home for this work? NMOP or new AINetOPS WG?
• What else is needed before requesting WG adoption (any WG)

5. Framework and YANG Data Model for the NMA A2U Interface (5 mins)

Presenter: Xing Zhao
Reading Material:
draft-zhao-nmop-nma-a2u-yang

• Joe Clarke: He expressed skepticism that agent developers would want
  to embed RESTCONF interfaces directly into agents. He said he has no
  objection to defining the interface in YANG, describing it as a
  useful and descriptive modeling language. However, he believes the
  overall NETCONF/RESTCONF ecosystem is too heavyweight for the way AI
  agents typically interact and questioned whether it is the right
  architectural fit.

• Diego asked why the proposal distinguishes between users and other
  entities, such as agents. He noted that, in a typical SDN
  architecture, the northbound interface does not distinguish who is
  consuming it, and asked why the proposal specifically introduces a
  user category.

  • The distinction is intentional because there are ongoing
    agent-to-agent (A2A) protocol discussions elsewhere in the IETF,
    and the proposal does not aim to address those. The focus is to
    provide an interface that can be used directly by non-agent
    systems, such as network operators. This allows operators to use
    the capabilities without waiting for A2A protocols to be
    standardized.

• Diego is conceptually wrong but it's practical. Let's continue the
  discussion.

• Haomian commented that having a clear taxonomy of interface types is
  important at this moment. Referring to the previous presentation by
  Mahesh, he noted that interfaces such as A2A and A2C may belong in
  the upcoming working group. Would like to confirm the place for the
  A2U.

6. Standardizing the northbound Task Interface (NTI) of the NMA (5
mins)
Presenter: Bo Wu
Reading Material:
draft-wu-nmop-nma-nti-problem-statement

• Reshad Rahman (chat): @Bo one slide mentioned agent capability,
  there was "a bit" of discussions on that in DAWN this week
  capability discovery
• Bo Wu (chat): @Reshad The capabilities here is refering the network
  management capabilies profile, e.g. fault management, network
  resource verification

7. A Framework for AI-Assisted Network Protocol Testing from
Specifications (5 mins)
Presenter: Yunze Wei
Reading Material:
draft-cui-nmop-auto-test

• Boris Khasanov (chat): IMO, this draft better suits for BMWG

• Reshad: the chairs do not believe the work belongs in the NMOP
  working group. He mentioned that the BMWG group had been suggested
  as a possible venue. He added that further follow-up is needed, but
  reiterated that, in the chairs' view, NMOP is not the appropriate
  home for this work.

• Qin Wu (chat): regarding protocol autotest, maybe RASPRG might be
  more relevant and could get interests

8. A Gateway for Network Knowledge Graph Management (5 mins)
Presenter: Mingzhe Xing
Reading Material:
draft-nmop-cui-nkg-gateway

9. Operational Requirements for Network State Exchange in
Agent-Assisted Network Operations (5 mins)
Presenter: Mingzhe Xing
Reading Material:draft-cui-nmop-agent-sketch-com-00

• Reshad Rahman: I will follow with a question on the mailing list
  @Thomas, question on the mailing list please

10. Applying the wiki guidance on AI drafts (5 mins)
Presenter: Mahesh Jethanandani

Mahesh: one document looked like an experiment (around NMA). NMOP does
experiments (regardless of the document status). Does the document
around NMA A2U fit this category
Xing Zhao: I think so.
Mahesh discussed about the experiment definition and invited people to
the Friday morning side meeting.
AI (Done on August 3rd): chairs to send email to NMOP mailing list