| Slot | Topic | Presenters |
| :-: :-: :-
| 13:00 - 13:10 | Agenda Bashing & Introduction & Document Status | Chairs |
| 13:10 - 13:20 | Publishing End-Site Prefix Lengths | Oliver Gasser (Remote) |
| 13:20 - 13:30 | Export of Delay Performance Metrics in IP Flow Information eXport (IPFIX) | Thomas Graf (On site) |
| 13:30 - 13:35 | IP Flow Information Export (IPFIX) Alternate-Marking Information Elements | Giuseppe Fioccola (On site) |
| 13:35 - 13:40 | Export of GTP-U Information in IP Flow Information Export (IPFIX) | Sriram Gopalakrishnan (Remote) |
| 13:40 - 13:50 | Applying COSE Signatures for YANG Data Provenance | Diego Lopez (On site) |
| 13:50 - 14:00 | A Data Manifest for Contextualized Telemetry Data | Jean Quilbeuf (Remote) |
| 14:00 - 14:15 | An Information Model for Packet Discard Reporting / Information Element for Flow Discard Classification | John Evans (Remote) |
| 14:15 - 14:20 | Export of QUIC Information in IP Flow Information Export (IPFIX) | Changwang Lin (?) |
| 14:20 - 14:25 | Export of Path Segment Identifier Information in IPFIX | Yao Liu (On site) |
| Slot | Topic | Presenters |
| :-: :-: :-
| 14:25 - 14:30 | AD Handover / Introduction of Med | Warren / Mahesh / Med |
| 14:30 - 14:45 | NEMOPS Workshop Readout | Dhruv (on site) |
| 14:45 - 14:55 | Pydantify – Generate Pydantic Models from YANG | Urs Baumann (remote) |
| 14:55 - 15:00 | Open Mic | All |
Benoit: Update on PCAP:
Benoit: Inviting Adrian to commenting on
draft-ietf-opsawg-oam-characterization.
Adrian Farrel:
Where we are - we had a WGLC on -03, issues were raised and were
resolved, posted an -04. Three more reviews came in WGLC completed
(Greg, Tim as OPS-DIR, Benoit as incoming shepherd). These raise
fundamental issues on the scope of the document. Carlos started to reply
to Tim's review and making some suggestions.
As an editor, I am unsure how to proceed when we have WG has said "good
to go", but other receivers are saying that the scope content is wrong.
There are also some outstanding editorial changes (Med): I am reluctant
to make those changes before we understand where we go with this
document.
We have notified some other WGs, by sending mails to list and Greg, as
shepherd, did the same.
This leads me with four questions that need to be resolved:
Benoit:
A difficult document because it has a lot of history.
Whenever we discussed with the chairs and the AD, the idea was to have
an OPS-DIR & a new shepherd. The plan with Mahesh was to present in all
different WGs to see if they agree (and yes, we know it's painfull)
Greg Mirsky:
Benoit: you still need to address the three reviews in a new document
revision, right?
Adrian: right.
Poll: Who thinks we should go ahead with SOME draft on this topic.
Results:
Yes: 7
No: 2
No Opinion: 8
Mahesh: Is going to IPPM enough?
Greg Mirsky: If I had to choose one WG, IPPM is probably the most
important WG tied to this terminology. RFC 7799 was published by IPPM.
So IPPM is a must, everything else is optional
Mahesh: Is this something you are willing to do?
Adrian: No. Not because I don't think it shoud be one but I am not
willing to do it.
From the survey, I see that 7 persons believe we should have a draft on
this. Anybody has the energy to help.
Thomas Graf: As I became IPPM chair, I might be able to help. Could find
out if there are people in IPPM that are interested to contribute.
Adrian: I appreciate the offer, but I don't want to spend time on this.
Thomas: What about the lightning session in IPPM.
Benoit: What if as Shepherd, I went to IPPM, if I ask the same question.
We will see whether we have the same answers to this poll question. We
will see from there.
Joe: Not sure how many people will have read this in IPPM. Out of the 7
persons who said "Who thinks we should go ahead with SOME draft on this
topic", if you are interested to contribute, let us know. We need active
participation to move this forward.
--- Regarding MUD document:
Benoit: IOTOPS is busy rechartering to include MUD. The authors would
like draft-ietf-opsawg-mud-acceptable-url to move to IOTOPS. The WG
chairs are fine for this action.
Mashesh: If the authors want to move this document to IOTOPs, that would
be fine, they may get more and better reviews.
John Levine: Draft is good. 99% ready to go. By coincidence, wrote an
almost similar draft, at the same time. For v4, at most harmless, for v6
this is definitely useful. A couple of minor nits: the way to encode
CGNAT, for security classifications ...
Joe: Thought about the DDOS. What are you next steps concerning the
"further considerations".
Oliver: These are related to the security considerations that were
added, and have already in incorporated. These are not the next steps.
Joe: John, can you put nits on the list. Oliver, is anything else
outstanding?
Oliver: Nothing from my perspective.
Joe: Once pending comments from John are addressed, this can be
considered for WGLC. Given the detailed security considerations, we
would probably get input from the SEC directorate (and an OPS
directorate as well, as mentioned in the chat)
Passed WG LC, moving forwards to the IESG.
No questions/comments.
Joe: This is another document that I think that we can move forward,
with some directorate reviews and WGLC.
Mahesh (as a contributor): Coming from NEMOPS workshop, can other
monitoring protocols such as IPFIX and BMP harmonize on the schema so
that we have a harmonized view of hte the data?
Giuseppe: it's quite separated. This is more for live monitoring, for
data plane monitoring
Benoit: This one is about data plane, while BMP is about control plane,
so not quite the same fields. The goal is about rigth to use the same
model between the 3 planes, but this would be tricky.
Benoit: Same feedback for all the IPFIX documents. We don't need IETF
drafts for IPFIX information elements, because IPFIX IANA registry is
Expert Review. However, it's not bad to have a document but it means
that the use cases must be better described. There are 4 fields but I
don't see the link between this draft and the one that Thomas just
presented. How are you going to use: for every single packet. When you
have key fields with IPFIX, how do you correlate with flowId set by
someone else. I see this document as illustrating the operational aspect
of it.
Giuseppe: There is a companion draft in IPPM. it implies that you know
about the ALT-Mark methodology. We could add more description in this
draft to make it complete, if you think that is useful. Otherwise we
just add
Benoit: not my preference. Either you have your deployment in a
different draft and just needs the IANA code points with Expert Review.
Or you extend this draft with some deployement information.
Giuseppe: Do you mean to merge this draft with the depolyment draft. The
deployement draft consider: IPFIX, YANG, and YANG-Push. We could include
the IPFIX section here.
Benoit: Let's take it offline.
Joe: We are getting lots of IPFIX docs coming through, and considering a
WG recharter. It would be good to understand how what you are defining
will be used, that is the operational use cases.
Joe: I think that we have a good path forward, do have any comments?
No comments.
Benoit: Clarifying question "Once we have an implementation
available...", you do have an implementation available?
Diego: Now we have an implementation,
Benoit: So, you asking for adoption.
Joe: Poll. 14 yes, 1 no, 5 no opinion. Would the person who says no be
willing to share their reasons.
Nobody coming to the queue.
Chairs AI: Poll for adoption on the list
Rob wilton: This is WGLC?
Joe: Yes, we had a long WGLC time, but Jean has replied since then
Rob: Had a look at it; isn't clear if this is the devices that should be
publishing this or collectors? If from devices, this data is likely
available elsewhere in the YANG schema, so this might be duplicative.
Additionally, Thomas presented a draft in NMOP that is similar to this.
How does this fit with that draft?
Benoît: This draft was created a few years ago and has similar goals as
the data mesh. In that way, it is similar to what Thomas said in NMOP.
We do have information in different places and in different formats.
Even for the YANG Catalog, we struggled how to model things like
hardware, software, features, etc. At some point we need to agree
(between opsawg and nmop) what fields we put. This also has overlap with
licensing (perhaps ivy)
Rob: This is a simpler way to pull this data and push it. Streaming this
metadata along with the device data is not ideal. This should be
integrated with a controller. Do we need both this draft and Thomas'
draft?
Benoît: There is an overlap with the goal, but how we do this yet to be
determined. I don't have a good answer now.
Thomas Graf: Here we are streaming the data along, but the NMOP document
has the metadata marking up the schema
Rob: Should we not then just have one document?
Thomas: There is a part of the NMOP document that is related to
manifest, but there is other parts of the document that marks up other
data. Ideally, we'd have one document, but it might be easier to have a
normative reference
between the NMOP document and the data manifest
Alex Huang: Some of the bits of this manifest can be reused in another
drafts. Asked Jean to create a grouping. The NMOP draft should import
the data manifest, and this would remove the overlap.
Thomas: It used to be that there wasn't a grouping. Now that it is
solved, we could use it.
Joe: Benoît and I to discuss the collab with NMOP as to how these two
documents interact
Joe:Do you have a strong preference on which approach (two drafts vs.
three)?
John: I have a stronger preference for one draft with IM/DM and one for
IPFIX
Rob: 3 choice: Put all three of them in one document.
John: I hadn't considered that choice.
Benoit: Rob's suggestion of a single document might be most pragmatic.
Joe: I prefer the suggestion on the left (two drafts), but I don't mind
combining either.
John: The downside of that is we're creating one large monolithic
document. What about we need to update a new data model? Do we have to
bis this monolith?
Benoit: How often do you change the information model?
John: If we get a new expression of the data model, we might want to add
that.
Diego: We haven't always done a formal IM in the past, but we have
included descriptions of an IM in several cases. So having an IM tied to
the DM and expressions is consistent with that.
Rob: Have some minor comments. Should look at counter64 rather than
uint64 for its extra semantics. Think carefully about defining 32-bit
counters. Don't do that for byte counters, even for errors.
Do we even need both types?
John: We had the request the other way. Given the plethora of counters,
it may not be practical for all platforms to have them and wasn't
required. Are 64-bit counters relatistic?
Rob: Some of these counters are already defined on devices (standard and
vendor-specific). Are we missing by not fixing existing definitions?
John: It's likely too painful to fix existing definitions. Something
like ifInErrors may not be a discard. So, some implementations choose
one way and some choose another. Having a central
place to report packet loss is cleaner and less effort.
Rob: I think the IM is good and the DM is okay. I'd like to fix existing
definitions and make them tighter where it's not clear.
John: I think it's a big task to fix all the places. Plus there are gaps
and new concepts would need to be added.
Rob: When it comes to certain definitions like L2 errors, please be
precise in what is considered (e.g., FCS).
Comments on second presentation:
Mahesh: We have a requriment that if a packet is discarded due a [QoS]
policy, would this be counted under flow discards, or would this need a
separate drop counter?
John: E.g., consider excess TTL discards, these would be reported in two
places, aggregated at the inteface level, but also at the flow level]
Mahesh: A policy level discard might not be tied to a particular flow.
John: So, I think you are questioning whether the policy part goes under
a flow. Basically, it should be possible to capture these drops under a
flow.
Joe: We should take this question to the list about how we take this
work forward as well as the IM/DM.
Benoit: It would help to have more information regarding whether the
long/short QUIC headers should be one or two flows. How do you combine
information between the long and short headers as they are two different
flows?
Yao: We will add more examples and use cases in the next revision.
Joe: Please read Med's comment in chat and Med, please post this to the
list.
No time for questions.
Tom Hill: Happy to see an emphasis on vendor compatibility with YANG,
and we need to treat YANG models like any other protocol when it comes
to interoperability.
Using GitHub will depend entirely on how good the maintainers are.
Wes: One workshop element was rapid turnaround. We need a conversion
mechanism so some middleware can handle the conversion. It's a hard
problem to solve.
It's as hard as how do we get all vendors to agree and support the same
models.
Wes: You're solving some of the problems I just gave a presentation
about. What percentage of feature complete are you?
Urs: 75%. We were able to run all the models from Nokia SRLinux. We did
not test some other vendors. Improvements are needed, but it is
functional.
No time left for open mic
End of Meeting