| Slot | Topic | Presenters |
| :-: :-: :-
| 17:00 - 17:10 | Introduction & Document Status & Agenda Bashing | Chairs (On site) |
| 17:10 - 17:25 | Guidelines for Characterizing “OAM” | Tal Mizrahi (Remote) |
| 17:25 - 17:35 | Applying COSE Signatures for YANG Data Provenance | Diego Lopez (On site) |
| 17:35 - 17:45 | Information and Data Models for Packet Discard Reporting | John Evans (On site) |
| 17:45 - 17:50 | A YANG Data Model for Network Diagnosis using Scheduled Sequences of OAM Tests | Victor Lopez (On site) |
| 17:50 - 17:55 | IPFIX Alternate Marking | Giuseppe Fioccola (On site) |
| 17:55 - 18:00 | Export of SRv6 Path Segment Identifier Information in IPFIX | Yao Liu (On site) |
| 18:00 - 18:10 | Export of Gigabit Passive Optical Network Encapsulation Mode in IP Flow Information Export (IPFIX) | Thomas Graf (On site) |
| 18:10 - 18:20 | ACaaS on orbit : Outernet Council Interconnect API | Erik Kline (On site) |
| 18:20 - 18:30 | YANG deVELpment PrOCEss & maintenance (VELOCE) | Med and/or Mahesh (On site) |
| 18:30 - 19:00 | Open Discussion | All |
Joe：All of the in flight MUD-related work is sent over to IOTOPS WG. We
are moving a lot of work through OPSAWG.
On the WG Last Call front: the historic version of the PCAPng is still
to be a working group item，but its historic version is now in working
group last call, the chairs extended that for 3 weeks into early
august，reading the PCAP draft and providing feedback on the list is
encouraged.
Finally, note that the OPSWAG has been recharted.
Benoit：Authors are encouraged to find people to review their documents.
Greg Mirsky: We had a very good discussion with Adrian and Tal, where we
clarified many points and we agreed on points forward.
One point: I agree that active OAM methods, and ICMP is one of them, are
not natively guaranteed to be a path-congruent and receive the same
forwarding treatment. But, at the same time, we cannot characterize them
as inherently non topologically congruent following the same path and
not inherently receiving the same forwarding treatment. So, it all
depends. Saying that any active methods, by its design, can not follow
the same topology and can receive the same treatment ... that a big
mis-statement.
Tal Mizrahi: I get your point. Designing active methods that are path
congruent would be possible, albeit not general.
Greg Mirsky: For the sake of this document, for people who wants to
understand OAM. We have to be careful with this statement, given the
intended audience of this document.
Benoit: Do we have the sentence in the draft that says that basically
any active method, we cannot guarantee because it's past congruence and
equal forwarding. that's why you qualify it as non path-congruent.
Tal Mizrahi: I'm not sure that I agree with the statement that every
active method is necessary non path congruent. We can define active
method that is path congruent and equal forwarding treatment. An example
is mentioned in the draft.
Med Boucadair: I understand that any revision is coming. Big thank you
to Tal, and to all.
Thomas Graf: Clarification on path congruency, does it mean it follows
exactly the same ECMP path treatment? Did I understand correctly that. I
assume that refers to ECMP and ECMP hashing. That the active OAM uses
the same 5-tuple, transport identification, as the user packets.
Therefore following the same ECMP path.
Tal Mizrahi: Correct! But ECMP by definition, doesn't have the same
5-tuple as TCP traffic or QUIC traffic. Therefore ECMP won’t share the
same 5-tuple then the user packets.
Thomas Graf: I applaud how you integrated into the YANG-Push envelope
extension header . And you were just mentioning before, about so we have
at a NMOP network telemetry message schema
((https://datatracker.ietf.org/meeting/123/materials/slides-123-nmop-sessa-extensible-yang-model-for-network-telemetry-notifications))
where we were using the (from OPSAWG WG) the platform manifest which
basically got two groupings. One is for the YANG-push publisher and the
other one is for the YANG-push receiver. And basically, since we are
augmenting information on the data collection, so adding additional
information, it would be amazing to have that data as well.
Diego Lopez: the platform manifest is the origin of all this because it
comes from discussions with Jan and others about how you establish the
when one may remember about these and that some sense that for sure,
this is something that, as I said, we were asked about that time. We
thought that it was an exotic requirement, but it's not exotic at all.
So we need to thanks a lot.
Joe: Do you have a clear scope for the draft? We would not like to see a
requirement creep here...
Diego Lopez: No, what we have in the draft is the type and the enclosing
method. Once we address the formal YANG issues and have a clear way to
deal with multiple signatories, the draft can be considered ready.
Benoit: It was also somehow my question about three applications. You
mentioned that you focus on the first one. For the second one and third
one, there is nothing to be changed, it's just another usecase.
Diego Lopez：Exactly. The only thing is that we plan to bring these
scenarios to show them at the Hackathons.
Chat Window
Reshad Rahman:
@Diego, very basic question on the provenance document (which I haven't
followed closely): is the signature needed only because there's no
security for stored telemetry data ("at rest")?
Diego Lopez:
In the case of data at rest yes
Diego Lopez:
In other cases, it allows to make verification beyond the transport
protocol
Mahesh (as a contributor): Thank you for this work because we have had
our own customers come to us asking for clarification on trying to
figure out where in the system, do we report a particular kind of data
being discarded? So I was going through the tree diagram and I was
trying to figure out the particular case, where in QoS, because of
policing, the packet is dropped. And I was trying to figure out where in
the model it kind of fits, I know you don't have the tree diagram handy.
But base, if the idea is that the packet is discarded because there was
some policing policy that was set for that particular interface.
John Evans: Yes. under policy, there is a specific branch.
Benoit: This is actually an important document because we take for the
first time, an information model in YANG, which we convert, which we use
as a data model. It was a very important one. Now I was waiting until we
would have the IPFIX data model and I wanted to review all of them at
the same time. You're asking for help on IPFIX, but what is your plan?
Last time I looked at the IPFIX one, it was not ready yet.
John Evans: I think we could decouple them. I think the question on
IPFIX is how you represent the information model in IPFIX, not in a
change to the information model for the discard reporting. So I think
it's more the translation. Two things: if there's more feedback on the
YANG model draft, it would be great to receive it, but the IPFIX
document needs more work. If there's a contributor on that, be very
much.
Benoit: We understand you prefer to complete this draft (YANG IM + DM)
and then the IPFIX DM draft as a follow up.
Med (contributor)： I want to understand the rational or the motivation
why you think that we need to delay the informational about the IPFIX.
Benoit： It's not about delay, but to me what is important, we speak
about knowledge graph everywhere. Knowledge graph is about linking
information. The point was tha, if we had devices who have your private
implementation or this YANG implementation or receiving with IPFIX, I
was thinking that it would be very nice is that I would be able to show
an IPFIX. This is how you design your flow with key and non-key. This is
review I need to do. To me there are three part: information model, data
model one, data model two. I was waiting to get all of these three to
start reviewing, but now I understand that IPFIX is like phase two or
companion.
Med (contributor): if there is feedback on the IPFIX one, this is great,
but I don't see a need to postpone the Information Model one.
Benoit: there are two parts in IPFIX. First you have the IPFIX
Information Elements, and you can say "job done". But there is also how
to define your Metering Process.
Jeff Haas: That's exactly the point that I came up here for. What we're
looking at is how do we actually take a leaf that is an information
model and canonically represented inside of the IPFIX schema，the version
that's in the draft right now，it does have some level of ambiguity. We
talked about that a little bit and have some thoughts on it. Certainly
an easy option is to pick something like the CBOR style of allocated tag
to each leaf and that brings us to interesting dependency question of do
we want to tag this into the data models way of doing that？I know we've
had that conversation for CBOR.
Other options might be things we haven't talked about yet. If there's
been work at IPFIX to actually do some sort of equivalent like of ASN
one path that is very similar for Xpath type stuff that would be worth
considering as well. If we're defining new ground，let's not try to
define too much new ground.
Holger Keller: My ask question is regarding QoS drops, and if I got it
right by policy，right？ If I look into the model under policy, there's no
QoS leaf mentioned.
John Evans: We need to define what we mean by QoS, there are buffer
discards. So if we're talking about queuing， they're defined, then we
have congestive loss rather than an explicit policy from the police. So
they're in the separate parts of the tree.
Benoit: You might want to request an early young doctor review, is there
anything to tell to YANG-doctors that this is an information model in
YANG？Is there anything special about it in the way they should be
reviewing it？
John Evans: There was a YANG-doctor's review of the information model
prior to the data model and we incorporated those comments in the
updated information model. There hasn't been any review of the data
model.
Joe： To be clear. An information model in YANG is new. I wanted to
understand like what did the YANG§doctors think about this？ There was
some feedback given.
John Evans：I think that was at the point of we were， in fact I don't
know..
Benoit: you want a YANG doctors review?
John Evans: We would need one more revision before going for YANG Doctor
review.
Benoit: Include a reference to the draft addressing OAM definition (and
review it).
Reshad Rahman: Pleased with the LIME references. Are you considering to
follow templates, as being defined in NETMOD? I can imagine you got
hundreds，thousands of nodes. You want to have stuff depending on rule,
depending on where the devices are in the network.
Victor Lopez: Essentially the discussion and what we are not agreeing
even among the authors is either if we should use a scheme mount to
expose to the northbound interface dynamically the configurations that
we want to use or the other option it will be to go for templates. I was
talking with Rob the other day. And it could be applicable to use the
templates and they can be what we can have is essentially the
calendaring，the status of the test and a template that you want to send
to the network. So we are debating about the two approaches and this is
the part that we are struggling to really make it happen. Something that
maybe we can do is if we keep not agreeing among the three of us， what
we can do is to set it in the list and get the feedback from all of you.
Joe (chair/contribuor): I wonder what it would do from a dependency
standpoint and what that would do to the planning of the work. If
templates were used，would it REQUIRED MUST use or would it be would it
be something you could do in addition to other reference points or have
this work stand alone.
Victor Lopez: so I think part of this work requires a solution to have
aa target configuration. The templates can be a way to express this
target configuration that the operator is willing to send in this
context. It will be for the creation of an OAM test. If there will be a
dependency with the template work， but if this is the best this is a
technical approach，we can wait for it to we conclude it and later we can
reopen it.
Joe： Do you have another revision or plan before working group last
call？
Giuseppe Fioccola： It depends also if we receive other feedback. In
terms of the document to look stable，so I don't know if additional
clarification is needed or not. So it's up to the working group to
decide.
Joe: No document shepherd at this point. Another way to participate is
sign up to be a shepherd. And then we'll see what the working group says
before taking it to last call
Thomas Graf: this is very usefull. When testing compress SID, we have
the SID container and IPv6 Destination Address.
Poll: who thinks this is interesting work to adopt?
yes: 10, no: 0, no opinion: 11
Joe: we'll consider it for adoption, on the list
Diego Lopez： This doesn't impact the architecture. I don't see why ITU-T
... because we're not adding anything or changing anything just.
Thomas: Exactly. So what I understood is on liaison, they are liaisons
like kind of an information. You could just send an information out and
say，hey， we do the IPFIX part.
Diego Lopez: I'm not sure because i'm not so familiar with that，but
there is another group that is called the broadband forum，the BBF. Yeah，
and I know that they are doing things like monitoring and remote
management of this kind of GPON so might be that they could be
interested or even that they have some are thinking about or
implementing another solution that could be.
Thomas: That's correct. I'm actually part of the broadband forum, that's
the global BNDC WT508. And my intent is also to bring that to the open
forum.
Benoit： Good point. I've got one question for the room. I don't remember
if whenever we've been defining IPFIX information elements that are from
a different SDO if you actually did a liaison，does someone recall if we
ever did defining IPFIX information elements that are somehow more
different SDO.
Joe： So same poll if you've read it and you think this is worth
adopting. Seems like this is another one Benoit was showing you from a
timeline perspective. This is very similar to the other SRv6 document.
It looks like it could be fairly straightforward for adoption. If the
working if we think we can get the reviews.
Benoit： Med. There was like the IPFIX on GTP didn't we have a liaison to
the 3GPP just for that？
Conclusion: ITU liaison statement? Yes to be polite, like we did for GTP
IPFIX to 3GPP
David Sinicrope, channeling Scott Mansfield (ITU-T liaison manager):
yes, to SG15
Poll: who thinks this is interesting work to adopt?
yes: 8, no: 0, no opinion: 7
Joe：I don't have a satellite constellation yet. However, did you find
anything in the work that you feel like if we start to rev this, some of
the attachment circuit work? Was there anything that you thought could
be different better that you would have needed would have been ideal?
Eric Kline：The main difficulty here is the coordination of the possible
connectivity elements. So the things that would be necessary to even
like establish a bearer. I found all of the bearer stuff and the
attachment stuff to be useful and comprehensible and mostly they want to
request our customers. We want to request like an layer 2 service or an
layer 3 service. There's no peering. Nobody has the idea that they're
going to exchange a bunch of routes for a 2 minutes contact window and
then try to move things around. That's not the expectation. There are
some YANG models for PHY layer things. There's even a YANG model for
location and for motion. I think I haven't looked at assembling all of
those things together. But if there was something that was missing, I
would definitely bring it up.
Benoit: Keep in mind the ONION potential work future working group, just
for all these network and services young model and how they work
together.
Balazs Lengyel: There's one more strong use case for moving the models
out of the RFCs. When YANG models in the RFC has a problem, it is very
difficult to update that model. The errata is not so well known and also
which revision date of that model will be valid. Where to display the
updated model?
Rob Wilton: I think it's great to try and get the YANG out of the RFCs.
It's a good thing to do. If you then put the tree diagrams back into the
drafts, every time you update the YANG model, you have to go back and
update the draft. In that case, you might as well put the YANG module
back in the draft. You haven't really gained anything. So I think you
need the tree diagrams to also be separate. Proposal: The draft
describes the model in a quite abstract way, everything else is in the
YANG model. For YANG tree, there is some tooling that generates
somewhere on a web page or github. So decouple the model from the draft.
Mahesh：I'll just put some context around that statement that I made
about tree diagram. I was not referring to the entire tree diagram. It's
usually parts of the tree diagram that you want to use to explain what
the model is trying to do. If you're going to really change the model
enough to require that tree diagram to be updated in the draft. Then I
would suggest that that would be done whether you're doing it for the
purposes of having an updated tree diagram or it could be because you
want to update the pros in the document.
Thomas Graf: We should avoid duplication as much as possible. In YANG
models, we have descriptions and we should not do that description in
the draft itself again. So the draft should only give a high level
description on the module. But each leaf descriptions should be within
the model.
Mahesh: description of the model could be in the draft but, to your
point, description statement should be in the YANG model.
Jeff Haas: Involved in the BFD model, which took years to change a few
lines, because of a bug. Editor of a 255 pages draft containing YANG
modules. One of the things that is worth pointing out from that exercise
is that some of the reason there's a level of success is that we have a
toolset that lets us actually build the modules, build the draft within
a git repository checkout, where the models are maintained separately,
where the text is maintained separately and the thing stitches it all
together. So there is a path forward where the actual model and the text
that generates the draft can live in the same repo. And through a CI/CD
style process, generate artifacts that can be fed back into the process.
Github is not something that everybody is going to use. So we have to
figure out what the desired workflow is to let the rest of IETF see the
sausage being made out of this mess. This is doable but it's going to
change rather what we do.
James Cummings: echo the comment that having the YANG models outside the
draft is beneficial. Can be moved back in a document in an automated
manner. There are some benefits in a level of stability in the YANG
model and the draft. Work in progress should be separated from an
approved final model.
Joe (contributor): I support this work. There is going to need to be a
lot of education in place to make people comfortable with doing this.
Extracting YANG modules from text is not an easy task. I applaud this I
would say consider some kind of markup in draft format in the xmlrfc the
RFC standard that hints that this is a YANG module, because then it will
be easy for tools like YANG catalog to centralize all these YANG modules
like it's doing today so that people can download one repository, get
all the modules and test them more easily than having to go to hundreds
of different repositories.
Benoit: yes to the YANG module outside of the RFC, as extraction is a
pain. YANG descriptions inside the YANG modules were initially a few
lines, then started to have more content (with some operational
information, btw, duplicating the draft content). What about we put the
YANG tree + explanation in YANG description. This avoids the mapping
issue (between draft and YANG revision) mentioned by Rob. What's left
for the draft? The use cases and some extra text, but we don't have the
mapping discussion.
Benoit: I would have liked to have that session in the OPSAREA meeting,
2 hours ago.
Rudieger Volk: From experience developing. The code and the comments
should be integrated, and managed in an appropriate way. ... It's worth
some considerations.
Thomas Graf: +1 to what Benoit just said. The YANG module being the
draft.
Ahmed Elhassany: We should consider the early adopters, with early
implementations. The tooling that takes the YANG module separately,
should accomondate that the diffs on github and datatracker are kept in
sync automatically so that different user groups, software developer
working with github vs. IETF community working with datatracker, can
collaborate easily.
Jeff Haas: go ahead and browse one of those repo's that we work on (with
Mahesh); we're doing some awk & markup language in there that's doing
all of the includes and the validation.
If one were to take the html output that we get at our RFCs these days
in picture a little bit of modern rapper on things we're allowed to
actually have controls inside of our html you could actually collapse
the models down from one of those includes you could even have a html
javascript enabled YANG browser that you could actually do stuff in
there. If we just simply take the drafts that we have: you can the YANG
diagram, the actual module... and you can collapse and expand those. All
of these extraction things go away if we take the markup that we're
already doing and just simply expose it to the tooling. There is a short
path from what we are currently doing to something that keeps the
current format, if you want it, pulls it out, if you want it ,and makes
it a lot easier to use.
Balazs Lengyel: two problems, the main problem is not during the RFC
development (If you want to improve it, you are welcome). The main
problem is that you cannot update the model without revising the RFC and
RFC development is very slow. So that's one reason why we are aiming for
perfection because we are afraid that updating it later will be very
difficult because the RFC process is slow. And also we can't correct
errors because you would need up to update RFC and the RFC process is
slow.
Mashesh (AD hat on): worry about the leadership. Try to minimize the
disruption to the IETF publication process.
Rob Wilton: I'm more and keen of trying to break the IETF process here
and trying to do something quite different. Openconfig does a better job
at updating the YANG modules. We need to instead to decouple the
lightweight evolution of the YANG entirely outside of RFCs，they don't
get published as part of RFCs. And then when you get to a stable
version, then you publish that. I’d like to go even further: move these
definitions and publications outside of RFCs entirely. The RFC would
simply describe what the YANG package contains, while the actual modules
exist as code with soft references - no hard versioning, just module
names and their locations. The key realization is that the IETF needs to
publish more than just documents - it should manage code as code, not as
text within RFCs.
Balazs Lengyel: you Mahesh and I have been navigating a similar path in
ETSI and 3GPP. We could learn from there. Central repository and
predictable tags to provide permanent links
Rob Wills: an IETF document is defined a RFC or IETF draft. Is
intellectual property considerations around that?
Mahesh: the YANG module have the copyright statement. Don't think it's a
problem.
Chat:
Holger Keller: so, i got this right, revisioning is in the yang-model.
if i have implemented an older revision of the yang-model, am i still
supporting the RFC?
Joe Clarke: As a contributor, I'd say it's more valuable to say you're
implementing ietf-foo version 1.2.3 than the RFC per se.
Ebben Aries: If we look at other bodies of work out there (e.g.
openconfig) what we generally see is an inverse issue where we have
models without complementing documents where there needs to be in
various cases.... where there are complementing documents we also see
the need for alignment between versioning.... ime even in internal
development the same issues exist... maybe what we need here is
something in the middle in which development, validation, review, etc...
all takes place in SCM but still couples it to the complementing doc (+1
to mahesh's comment now as i was typing)
Balázs Lengyel: I think the main problem is not during rfc development.
For me the main problem is that the model cannot be updated without
reving the RFC. RFC update is slowwww.
Ebben Aries: at a min to start what id like to see is experimenting w/
SCM based reviews for all model development within IETF - manual line #
commentary and collaboration is difficult and cumbersome
No time for Open Discussion.