| Slot | Priority | Topic | Presenters |
| :-: :-: :-: :-
| 09:30 - 09:40 | | Agenda Bashing & Introduction | Chairs |
| 09:40 - 09:50 | P1 | Message Broker Telemetry Message | Ahmed |
| 09:50 - 10:00 | P2 | Anomaly semantics and lifecycle | Thomas |
| 10:00 - 10:15 | P3 | SIMAP concept, requirements and usecases | Olga |
| 10:15 - 10:25 | P3 | SIMAP external relationships | Vivekananda |
| 10:25 - 10:35 | P3 | SIMAP applicability to Transport networks | Italo |
| 10:35 - 10:50 | P4 | RFC 3535 20 years later | Luis |
| 10:50 - 11:05 | P2 | MTS: Sharing your incident | Boris |
| 11:05 - 11:20 | P2 | NBN: Sharing your incident | Brad and Alistair |
| 11:20 - 11:25 | | AI-based Network Management Agent | Xing |
| 11:25 - 11:30 | | Open | All |
| Slot | Priority | Topic | Presenters |
| :-: :-: :-: :-
| 16:00 - 16:05 | | Agenda Bashing & Introduction | Chairs |
| 16:05 - 16:15 | P1 | Validate YANG-Push Publisher Implementations | Thomas |
| 16:15 - 16:30 | P2 | Open-source: Anomaly lifecycle and semantics | Vince |
| 16:30 - 16:45 | P3 | SIMAP hackathon results | Vivekananda |
| 16:45 - 16:55 | P5 | Update on Knowledge Graphs | Michael |
| 16:55 - 17:00 | | Open | All |
Action Item: ETSI liaison statement, to follow up
Mohamed Boucadair: On the LSes, there was an LS sent out to 3GPP:
https://datatracker.ietf.org/liaison/1988/ on SIMAP. I don't remember we
received any reply.
Mahesh Jethanandani: Med kindly pointed me to the thread on the mailing
list discussing the LS from ETSI. I also see that NMRG had a workshop
with ETSI on the same subject. Has someobody looked at it?
Benoit Claise: On my todo list. At this time, it is too early for IETF
to respond to the LS other than acknowledge it.
Mahesh Jethanandani: On the knowledge graph design team. Are regular
updates to the mailing list foreseen?
Reshad Rahman: The intention is eventually yes. We don't know yet in
which form. We are still at the beginning.
Benoit Claise: On the ETSI liaison statement, does Mahesh as the AD have
guidance?
Mahesh Jethanandani: I admit, I haven't read the ZSM work yet either. I
only understood from the liaison statement that there is work happening
on both sides. I take it as an action item to read the ZSM work.
Robert Wilton: Minor comment, change names from module-name,
module-version to name and version and allign the naming to
draft-ietf-netmod-yang-semver.
Benoit Claise and Reshad Rahman as chairs: We forgot to mention in the
introduction of the session that we have also helped on reviewing
documents. However we like to remind the working group that it is a
collective effort.
Benoit Claise: In regards to second augmentation for IPFIX. What are
your intentions? Reshad and I were wondering at which point in time we
draw a line on the scoping of the document?
Ahmed Elhassany: At present stage, we show how, with YANG-Push, the YANG
module can be augmented. The augmentation for IPFIX will be most likely
be described in a further document. Any comments from the chairs?
Alex Huang-Feng (chat): +1 for supporting IPFIX in a different document
Dan Voyer (chat): perhaps the data provided by IPFIX makes sense here as
potential use case - as long as we are not deep in IPFIX itself
Reshad Rahman: I understand that
draft-ietf-nmop-network-anomaly-semantics and
draft-ietf-nmop-network-anomaly-lifecycle are two components of the
draft-ietf-nmop-network-anomaly-architecture.
Thomas Graf: Correct.
Reshad Rahman: There are also other components described in
draft-ietf-nmop-network-anomaly-architecture which are open not covered
yet. Benoit and I are suggesting to the working group and anybody
interested to contribute use cases, to look at the architecture and
describe how they could be integrated.
Chong Feng: I have read and reviewed the anomaly detection documents. My
understanding is that they are based on Network Telemetry (RFC 9232)
data, correct? Have you considered data from other sources?
Thomas Graf: Document is based on monitoring all three network planes
holistically. Did I understand correctly that you would like to add also
other data correct? -> question remained unanswered
Chong Feng: My second comment relates to the effectiveness of network
anomaly detection. How accurate can anomalies be detected?
Thomas Graf: We can give details of our implementation at Swisscom where
we monitor 13000 L3VPN's. We have up to 5 alerts per day and 4 of them
are valid and where connectivity services are impacted. 1 is a false
positive.
Mingzhe Xing: The data in described framework is mainly based on Network
Telemetry data. There are lots of other data that can be included. Have
you considered extending to cover other data such as multimodal text,
image or knowledge graph.
Thomas Graf: The semantics we are describing in the relevant state are
analytical metrics. These are not metrics from the network. As example,
the described network objects are not all the network observed, only for
the detected anomaly the relevant once. From there, you can establish
relationships with URI's, query the operational data as part of the
lifycecle refinement process.
No questions or comments made
Reshad Rahman: I have reviewed the document and I was asking myself is
this the only approach you discovered. Do you consider to describe also
other options?
Pierre Francois: The project is 9 months old. We were brainstorming
since day one and following two approaches. In the previous interim
meeting and document version, I was hinting some of the previous
approaches. To our conclusion, the approach we worked on is the most
promising. Please feedback wherever we should follow other approaches as
well.
Reshad Rahman: I think it would be useful. Consider to document in an
appendix or describe on the mailing list.
Alexander Clemm: Who is supposed to consume the template information?
Why should it be interoperable?
Pierre Francois: It is the code which is presenting the SIMAP or any
other application using the SIMAP information such a network manager. So
the code is checking in the template what is needed and supported on
each node and executes the data aquisition. Does that answer your
question?
Alexander Clemm: Yes, it does. However I have some more questions. Will
follow up on the mailing list.
Olga Havel: Regarding different options. Perhaps we get more people
involved about the different options and to give consensus.
Pierre Francois: Good point.
Reshad Rahman: Let's get more discussions on the mailing before we can
consider working group adoption.
Pierre Francois: Can I have a show of hands wherever this is interesting
work we should continue or not?
Benoit Claise Reshad Rahman: I think it is a bit early for this. I would
appreciate and updated document and more feedback on the mailing list
first.
Adrian Farrel: Can we have a better focus what transport network means.
In the document you describe that a transport network is anything that
carries traffic for a client network. But everywhere else you focus on
OTN and DWDM. Technically IP or MPLS could be a transport network.
Italo Busi: Agree, let me find a reference to be specific. Wherever it
covers other layers as well.
Mahesh Jethanandani: If you would consider anything including IP, that
would make NMOP the home.
Italo Busi: originally IP was not in scope. We will reconsider.
Benoit Claise: Could you describe whether the SIMAP concepts draft
already cover your transport use case? Does transport becomes another
extra layer?
Italo Busi: Very good point. There are some generic items but also some
are specific to OTN and DWDM.
Daniele Ceccarelli as CCAMP chair: Regarding the working group
placement, open to discuss.
Olga Havel: On top what Benoit already said. It would be great if you
could contribute to drat-ietf-nmop-simap-concept use cases and
requirements. Our goal is that our model is covering different layers
and being generic.
Joe Clarke: Curious why this is a NMOP item vs. OPSAWG, ONIONS, OPS
Area? Why has it be placed here vs. somewhere with broader coverage?
Benoit Claise: You are asking, why isn't it an AD sponsered document
like RFC 5706bis?
Joe Clarke: Yes!
Mahesh: Initial NMOP was intended as entry funnel for the OPS area
related work. What is the intended scope of the work? Is NMOP related
work only?
Joe Clark: I think some of the items are outside of NMOP.
Mahesh: Agree.
Benoit Claise: To summarize the discussion. The intention is to
collected requirements and sort them. Work on some of the items which
are actionable within the IETF. Potentially in NMOP and other OPS
working groups. Joe has a valid point. What is in the document items to
be worked on in NMOP vs. the OPS AD act on like creating a new working
group such as ONIONS.
Luis Miguel Contreras and Benoit: The intention is more that the
document is more as a documentation. From there the requirements
triggers other work in the various OPS area working groups.
Chonfeng Xie: Like to share the China Telecom view on network management
in terms of YANG data and service models. The slow industry adoption of
IETF models are imposing a challenge on network operators to deal with
propriety vendor specific models.
Dan Voyer: I like the document. It descibes well the problem of slow
industry adoption on standards in network management. I like that it is
defining and highlighting requirements but even more pointing out the
need that IETF is supporting agile incremential driven development.
Interestingly, at the same time we are asking us here in which working
group this fits best. How do you suggest we can move forward with this
work? For vendor and the operator community, this work is important.
Luis Miguel Contreras: We need a single place where we can collect these
requirements and define its next steps.
Dan Voyer: And I believe you should also mention who should help you to
get this forward with.
Robert Wilton: Doesn't matter where the work is done as long as the
right people are in the room. But also need to consider external
feedback from the operators who participated in the original IAB
workshop since we need wide review/input on this draft.
Benoit Claise: Agree, we need to differentiate between collecting the
requirements and what actions within the IETF should be done.
Thomas Graf: I suggest to collect feedback and additional requierements
from other OPS area working groups. The authors should propose next
steps and these should be reviewed by the OPS area.
Mahesh Jethanandani: I agree with Rob to obtain more input from other
operators. We should also distinguish on the outcome which items should
be worked on in NMOP and which somewhere else.
Benoit Claise: Yes, that makes sense. In case we take new work items on,
there is a NMOP rechartering needed where Mahesh as the AD is anyway
involved. Another opportunity would be to present and discuss this on
the OPS area standelone meeting. From there, we can decide where to move
which work.
Thomas Graf: In slide 14, you wrote COMM. I asume these are standard
communities correct?
Boris Hassanov: Yes!
Thomas Graf: Are you correlating between BMP and SFlow?
Boris Hassanov: Currently not, but we intend to.
Thomas Graf: That would help you to see how much traffic is flowing for
which BGP standard community tagged path.
Boris Hassanov: That makes sense. We also intend to leverage on-path
delay.
Thomas Graf: Makes sense. I asume that the reason why you detected the
blackholing so quickly was because of the probes correct?
Boris Hassanov: Yes exactly!
Thomas Graf: Since probes are just a simulation, I suggest to leverage
passive tracking monitoring like Network Anomaly Detection.
Dan Voyer (chat): Have you consider "conditional static route" ? (if you
stay with "static route")?
Reshad Rahman: Now I understand Brad's interest in Knowledge Graphs.
Ignacio Martinez Casanueva: Thanks for mentioning knowledge graphs.
Let's have a dicusssion on real-time applicability. We can also pickup
on Tuesday on the Knowledge Graphs side meeting.
Brad Peters: The short answer. This also something we are currently
looking at.
Dan (chat): yes, very solid use case for Knowledge Graphs.
Benoit Claise: All, we will not have the time to present this session
"AI-based Network Management Agent (if time permits)"
Benoit Claise: We had the NETMOD working group meeting on Monday. I
understood that there was mild support on
draft-netana-nmop-yang-anydata-validation. I don't see the anydata
validation in the hackathon work list items.
Thomas Graf: Well spotted. Code has been developed to be included in
libyang/yanglint however this has not been merged yet. We plan to
finalize it in the comming weeks and defintely it will be part of the
IETF 124 hackathon scope.
Ahmed Elhassany: We have validated anydata in another context before the
hackathon. For the notif-envelope we were not able due to a bug we
reported to libyang maintainers. This is partially fixed now and should
be by Friday where we can already demo at the side meeting. Related to
this work here. The anydata validation is relevant work to ensure that
the data being published by the YANG-Push publisher is data which can be
automatically be processed or not.
Benoit Claise (chat): I understood this will be important for the
overall architecture and there was medicore feedback at NETMOD. A better
understanding why this is needed needs to be established.
Thomas Graf (chat): That's correct. The message validation is a key
component of the overall architecture.
Mahesh Jethanandani (chat): Noticed that draft-ietf-netconf-https-notif
did not make it into the list of documents. I know there was an
implementation, but if is missing some part of the integration, the
implementers would be interested in knowing what is missing.
Thomas Graf (chat): That's correct, https-notif was not in scope.
NetGauze is the data collection where the described architecture has
been implemented. We are in contact with Meher. However we are not aware
what the current status on their implementations are.
Mahesh Jethanandani (chat): Thanks for the update. Will work with Meher
to see what it will take to fill the gap.
No questions or comments made
No questions or comments made
No questions or comments made
Reshad Rahman: Regarding draft-netana-nmop-yang-anydata-validation and
the informative reference from
draft-ietf-nmop-yang-message-broker-integration. If you haven't already,
consider to reach out to the NETMOD chairs and describe the reasoning of
validation and the document and the relationship to
draft-ietf-nmop-yang-message-broker-integration. Or even send an email
to the NETMOD mailing list. This could become a problem for
draft-ietf-nmop-yang-message-broker-integration if the reference is
normative.
Pierre Francois: I forgot to ask during my talk. We are monitoring VPN
services over SRv6. When I have a YANG module, do I come here or do I go
to ONIONS working group? And about IS-IS, I asume it's here since it is
topologial and VPN I go to ONIONS correct?
Mahesh Jethanandani: ONIONS is still in the forming process. I don't see
a reason why both of the work can't be done in NMOP.
Oscar Gonzalez de Dios: As one of the authors of RFC 9182, A YANG
Network Data Model for Layer 3 VPNs, update the document would be
another reasonable approach.
Benoit Claise: There appears to be 2 YANG models. One augmenting SIMAP.
What we foreseen is that we want also guidance for other models and
layers. I would like to hear from Pierre how this is related to what
Oscar just mentioned.
Pierre Francois: Olga should answer.
Olga Havel: Regarding SRv6. We modeled SRv6 from a topological
perspective using RFC 8345. Describing, segments, segment list, locators
etc. One layer with sub layers. There is similar but unrelated work also
at SRV6OPS. Are there any correlation requierements? For VPN over SRv6
it gets even more complicated.
Benoit Claise: That is new to me that there at SRv6OPS WG
topology-related SRv6 document. Dan Voyer, as the chair of SRv6OPS sits
in the audience. It appears we have a coordination item here.
Dan Voyer as SRV6OPS chair: It is a good question. I agree we need to
collaborate more.
Boris Hassanov: I suggest to augment SIMAP to support RFC 9252.
Pierre Francois: There are not conflict to the SRV6OPS discussed model.
They are serving differend needs. I am not suggesting to do mapping in
ONIONS, but someone needs to tackle this. Otherwise we are getting into
possible conflicts.
Benoit Claise: It appears we have all the right people in the room. I
would fancy that you organize yourselves.
Pierre Francois: How about Mahesh helping in coordindation?
Mahesh Jethanandani: More than happy to help. From a knowledge
perspective most of the work is here. I am aware it has its applications
in SRV6OPS. I am open to support offline.
Benoit Claise: For us chairs it's important we are not getting out of
RFC 8345 sync.
Mahesh Jethanandani: Agree
Dan Voyer as SRv6OPS chair: Let's read and meet among the involved
before heading to the chairs and ADs.
Olga Havel: Why we didn't start the conversation was because we are
still identfying the gaps before we are going into model proposals.
Wherever a generic or protocol specific solution is needed.