(Notes : Rob Wilton, Rob Wills, Jean Quilbeuf, Adrian Farrel)
No agenda bash
Mahesh: To Benoit's point, generally we don't spend too much time on
info models and work on standardise data models. Interested that you
have defined direction as identity ref, which would imply you can
specify only one direction. Are you not wanting to capture discards in
either direction? If so, don't you need it as a key?
John: We do want to do that, but we also want to maintain commonality
across interface stats (?). And some of those don't have direction. A
standardised data model would address that.
Rob W: An info model is a poor man's data model. I encourage you to just
define the data model and provide guidance on how to use the data model
as an informational model. I understand the IPFIX case is a little
tricky but it's good to have commonalities. Openconfig has the concept
of reporting hardware error counters, which you may or may not want to
include.
Jeff: Addressing your point "why are we doing an information model & why
is this IANA". Long term goal is that if we're going to be doing many
manifestations of this behavior (YANG, IPFIX, model on line cards, etc),
there will be a desire to keep the information similar (same structure).
Challenge within IETF process is "how do we do this initial coorfination
effort?". Step 1: information model allows us to decide what kind of
data we want to have, relationships, etc. Step 2: how do we manifest as
data models?
Long term question for the group is: for information modeling, if we
want to have a long life , how are going to do that? When we have the
right structure with the information model, are we ready to kick out
data models for the various manifestations? If information model are
desirable thing to accomplish as a long term maintainable thing (as
there will be likely multiple manifestations of this), what does that
looks like in IETF?
Chair (Joe): Keep it going on the list. There's clearly interest.
Joe: Informative reference to SIMAP. That could take a long time to
complete. You only saying "Could be used a way to do platform ID.""
Jean: Yes. We are saying that specifying this platform ID is outside the
scope of this draft. So we are just listing the possibilities that
exist, and whenever we implement it, we must ensure that the id matches
the inventory of the given system.
Joe: I would like to get some feedback on that point, but I think that
we can bring it to last-call.
Joe: We can put this forward. Always looking for doc shepherds
Joe: Wanna poll to find out who wants to work on it? You using
scheduling work from NetMod?
Victor: Yes, actually asked authors to split the module so that we can
use the scheduling part as a standalone module.
Poll: Is there interest in adopting this work? Yes: 16, No: 0, No
Opinion: 18
Poll: Is this a good basis for scheduling OAM test? Yes: 14, No: 0, No
Opinion: 14
Joe: no strong objection, we can put this forward and see how the list
responds.
Tobias: Overlaps with the assignment and registration principles of the
RIRs. Is the solution by RIRs better, otherwise does this seem
redundant. About happens if the device publishing this data just lies?
It will reduce its usefulness.
John: Important to do this for v6. Large email providers need prefix
granularity to do reputations. Encourage you to go ahead with the prefix
len stuff, and don't have an opinion on whether to generalise it.
Joe: What do you want from OPSAWG, what operationnally are looking for
in this working group?
Mingzhe: Also discussing with ADs and . So, they recommended that we
present here to get feedback.
Benoit: Thank you for coming to the IETF. You want to standardize an
architecture. You went to SAVENET, SEC DISPATCH, (maybe go to NMRG), and
are coming here. But you need to build a community of interested people
who want to work on this.
Mahesh: Similar to Joe. Seems like informational preso in this WG. Seems
NMRG would be right place. Talk to me about where this work should go
ahead.
Joe: Would be interested in seeing if the WG finds it similar to MUD? I
haven't seen much on the list yet, and would like to see more before
making a determination.
Joe: like the bottom-up approach. If there is interest in CATS, would
there be interest in OPSAWG to take the work there? Seem to be in the
charter of CATS?
Haomian: Thanks for doc. Didn't read doc. Could you clarify the scope of
this document or work. Is it closer for compute for network, or network
for compute.
Jordi: Little bit of both, ranges from edge computing to cloud
computing.
Haomian: Closed to network for compute. Differentiate terms, they could
be confusing.
Benoit: Interesting topic, this needs to be solved somewhere. Do you
have other metrics to be standardized. I couldn't find any. Said that it
would be done in CATS, which is about steering. If the answer is no,
then perhaps taking the work to CATS, but if yes, then maybe there is
something to be brought here.
Jordi: Needs to be able to scale. Architecture is very generic, nothing
to do with steering, and hence can apply to a broader set of use cases.
Benoit: Whatever do you do in CATS will remain in CATS, but depends on
the architecture defined here?
Adrian (CATS co-chair): In CATS, in order to do traffic steering you
need to know what compute the metrics are. Metrics weren't available, so
cats jumped in to do it. If there is a requirement to generalize and put
in an other WG, that would be fine. Today, bulk of the work is being
done in CATS. I heard that this draft is going to turn into a more
generic framework, not restricted to compute metrics used for traffic
steering.
Benoit: What are you asking for OPSAWG to do?
Adrian: Please come to CATS, please review, please help shape them.
Benoit: Would it be useful to present at each OPSAWG meeting?
Adrian: This is not a CATS document. Up to OPSAWG to decide whether it
would be further discussed. If you would like CATS to give a status on a
period basis, then we would be happy.
Benoit: If this was adopted in a year's time, just trying to figure out
how this would work.
Adrian: Clearly we need to keep talking to each other.
Joe: Presentation helped me with what you’re asking. Initially was
request of a new WG, now you would like some feedback from OPSAWG?
Mahesh: Wish I could provide clarity, confused at this point.
Jaehoon: Main business is to standardize these 2 drafts in OPSAWG.
Joe: let’s see what happen on the list
Michael had discussions with IANA to reformat the doc in stanzas. IANA
was okay with this, and mcr will work to do this and submit a new draft.
Joe: IANA is ok. If IANA wants it that way, we can progress. Would be
great to get people reviews.
Mahesh: When they (the customers) talk about "tooling", what does it
mean? We need to understand what kind of tools these operators are
looking for.
Warren: People don’t necessarily know what is under the hood. For
instance they might use SNMP because it comes with NAGIOS and fits their
use case.
Benoit: LACNOG operators are using mainly open-source. They install
cacti and it works.
Mahesh: Need packaging of the open-source tools such that it can be
deployed out of the box??
Benoit: Out of the box. Let them play with YANG and NETCONF. They see
the journey, but they are missing the first three steps.
Wim: Nanog. Wasn't really a discussion on the device interface. But as
you go up, there is huge tooling that isn't build on YANG at all. The
question, that you need to ask in that workshop, is what is IETF going
to do with that. IETF says that YANG is the way that you do data
modelling, but that isn't the reality in more general data modelling.
What is IETF going to do with that. 2. When it comes to tooling. Need to
build good language bindings to make it easier to consume the data.
E.g., there are tools that generate OpenAPI from a data model. We need
to layer that up in the whole stack. Need to geenrate Information
models, and consuming Information models.
Warren: Really hard to find the models and put them together when they
work. Python is great, but if it doesn't handle the Python migration, or
stops being supported then that is worse.
Benoit: Need to look at how we do, and also need to look to the future.