# Joint OpsAWG / OpsArea   {#joint-opsawg--opsarea}

When: 10:00-12:00, Friday Session I, July 29, 2022  
Where: Independence A/B

## OpsAWG Section   {#opsawg-section}

1.  Administrivia - scribes, minutes, etc.  
    Tianran / Joe / Henk

Henk giving status update:

*   2 docs submitted to IESG
    *   Clarified that one is going to the IESG very soon.

*   2 docs due to go soon.

Comments from Med on chat:

*   SAIN work is pending a formal WG LC conclusion and there are
    outstanding comments being addressed by authors (and YANG doctors)

Joe:

*   Recent liaison statement from ITU-T
*   Please read

1.  Manufacturer Usage Description (MUD) (D)TLS Profiles for IoT Devices
    
    Tirumaleswar Reddy  
    https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud-tls/

Tirumaleswar presenting:

*   Authors think that the draft is ready for WG LC

Comment on chat:

*   Should DNR be cited for this part of the draft "A network-designated
    DoH/DoT server is necessary to allow MUD policy enforcement on the
    local network"

Tirumaleswar: Yes (I think)

=== End Adopted Work Section ===

1.  IPFIX Extensions  
    Thomas Graf  
    https://datatracker.ietf.org/doc/draft-tgraf-opsawg-ipfix-inband-telemetry/
    
    https://datatracker.ietf.org/doc/draft-tgraf-opsawg-ipfix-srv6-srh/

draft-tgraf-opsawg-ipfix-srv6-srh presentation:

Thomas presenting:

*   Addressed all open issues and checked with IANA
*   Any questions?

Henk: We should be able to call for adoption after this week.  
Joe: Extra reviews on the IPFIX YANG draft would be helpful.  
Thomas: Yes, I would be able to help review.

draft-tgraf-opsawg-ipfix-inband-telemetry presentation:

On slide 3:  
Greg Mirsky: What does inband signify? Does inband signify that there is
some outband telemetry?  
Thomas: This terminology is related to docs discussed in IPPM  
Greg: IOAM agreed as inband, but that was misleading. Mixes Active and
Passive so classified as hybrid.   
Greg: Suggest the name "on-path telemetry"  
Greg: [IOAM direct exports][1] and [Alternate-Marking Method][2] allows
exports on aggregated metrics. So comment on aggregated is not accurate.

Thomas: Not happening on the node.  
Greg: Why? The header allows the direct export header option. This is an
aggregation?  
Thomas: Can't do aggregation on the node itself.  
Greg: Direct export doesn't specify how the data is exported or the
local policy for processing the data. Aggregation can be done. Direct
export allows for better path delay measurement. Secondary metrics can
be calculated and exported.  
Thomas: Lets discuss on the list.  
Benoit Claise: Do you see there is a problem or not?  
Greg: No, just concerned about one statement on the slide that there is
no aggregation.  
Benoit: I agree about clarifying terminolgy. In the draft, we use the
IOAM terminology  
Greg: Can use IOAM and refer to them as on-path telemetry.

On slide 7:  
 clarification that update will be to -02 version of the draft.

Henk: Any further questions?  
No questions.  
Henk: Reviews are welcome. Authors, work on the integrating the
terminology   
Med (on chat): "This is useful work. Thanks Thomas"

1.  A Data Manifest for Contextualized Telemetry Data  
    Benoit Claise  
    https://datatracker.ietf.org/doc/draft-claise-opsawg-collected-data-manifest/

Joe Clarke: Why would need to stream this metadata all the time?
Wouldn't it greatly increase the amount data.  
Benoit: Will answer in a minute.

Benoit presenting questions:

*   Agree that streaming lots of meta data might not be the right way,
    but having a pointer to the data might be a right way.
*   Lots of ways of getting the YANG modules supported by a server.
*   Does it make sense?

Dean Bogdanovic: I can see how this would be useful for IOT controllers.
Physical devices connected to the controller can have different
behaviours. Hence, this model is very useful tool to be added to it.  
Greg: Telemetry information corrolation is very important. Other methods
of collecting telemetry are available, which happens out of band. I
think that this is very useful, and code be done either nodes that are
exporting directly or after is has been agreed.  
Benoit: It is all about corelating data.  
Thomas: Should we include the encoding 3 possibilites:

*   Do it in YANG Push
*   Do it in the notification header.
*   Could do it in the data manifest.
*   Makes most sense to do in the transport of notification layer.

Benoit: I would agree that the encoding should not be in the data
manifest, as we don't want it to become a capability manifest   
Benoit: Identified some improvements:

*   Source of data
*   Data integrity
*   Want to keep it simple.
*   SNMP/IPFIX: Don't want this to become too big, perhaps better to
    focus on a single task.

Benoit: Want feedback from the group? Is this the right place to do
this.  
Dean: I think that this is a valid problem. Supports adoption.  
Alex Clemm: I recognise the problem, but not convinced of the solution.
Why not take your YANG model with the context on the device and
subscribe to that?  
Benoit: What happens when the router is upgraded, the manigest changes?
So we need anyway to keep the information outside of the router  
Alex: If it is outside observer the same thing applies.  
Diego Lopez: Does this data have to be pushed every time? What do you do
with this data set? I just care about the data set, because it solves a
problem  
Med (from chat): "I support this work."  
Chairs ran a poll: 21 hands in support of the work (interest in this
work) no hands NOT raised  
Benoit: I don't care about the mechanism, I care about the data set.  
Chairs: there is interest, if we see some of reviews (from the 21 hands
who agreed to review) on the list, that would qualify for WG adoption in
the future

1.  Green Networking  
    Alex Clemm  
    https://datatracker.ietf.org/doc/html/draft-cx-green-ps-00  
    https://datatracker.ietf.org/doc/html/draft-cx-green-metrics-00

Dean: Lots of

*   Area is too big, need to define what we need to solve.
*   What are the requirements that the operators are facing.
*   Not all energy is the same, can be a surplus of energy in the
    system.
*   We should first find the requires on what operators are being asked
    to meet.
*   A big mess that we have no visibility or semenatics on what the
    energy is.
*   Are you trying to define new semantic routing protocols
*   This is much of a mix of everything.
*   Lots of stuff that is good for the media, but hard to see the
    concrete data.

Alex:

*   Agree it is a large problem space.
*   Agree that we need to identify specific aspects.
*   Don't want to boil the ocean.
*   Not necessary about routing, this is about starting with metrics.

Dean:

*   Radio and optical use the most energy in networks.
*   Also have the question about reliability.

Alex:

*   Hard to quantify what these things are.

Anthony Somerset:

*   Very important to measure.
*   Need to start somewhere.
*   The data that we have today is very crude
*   Hard to understand how to measure power usage of flows and paths but
    curious to see what comes out of that.

Jan:

*   We are interested in this problem and would like to connect to you
    on this.

Warren:

*   What are the power companies doing?
*   Something about
*   Not all operators have radios/optics as their biggest draw.
*   Need to speak to people in other areas.

Henk:

*   Continue on the list.

Chat:

George Michaelson: "We are not energy economics experts and I think we
should discount comments to national energy policy and focus on
information on energy use, and patterns which reduce energy budget. on
that basis, I support work in this space. It's important. Metrics drafts
are helpful."

Tianran: "no matter the carbon footprint, at least energy saving is
useful."

Adrian Farrel: "The sort of thing we can work on, is models for
recording and reporting energy use. But, not sure we correctly
understand what information to collect and report. A lot of the work I
have seen so far does not seem to understand how a router consumes power
differently depending on a number of factors (not limited to congestion,
load, buffer usage, complexity of packet processing)"

Med: "We do already have eman as a starting point, Adrian."

Med: "As recorded in draft-eckert-ietf-and-energy-overview, a concrete
action would be " There are currently no YANG equivalent modules. Such
modules would not only be designed to echo the EMAN MIBs but would also
allow to control dedicated power optimization engines instead of relying
upon static and frozen vendor-specific optimization."

Simon Hicks: "Yep, let's start somewhere. Or do we just say we can't do
anything? We can understand the problem, and understand the hardware
standards that the protocol is carried through. Can we change the
protocol in ways that give less energy consumption in the hardware? Are
there ways in which the hardware could be changed so we could make
protocols more energy efficient?"

Warren Kumari: "Yes, but we also clearly shouldn't not just solve the
"green" problem without more clearly defining what we mean/are talking
about. If we try boil the ocean in the interests of virtue-signalling...
well, boiling an ocean takes lots of energy..."

6\.What has the IETF ever done for Energy  
Toerless Eckert  
https://datatracker.ietf.org/doc/draft-eckert-ietf-and-energy-overview/

Rob Wilton:

*   It would be interesting to see the energy impact from increasing use
    of encryption.
*   Data centers and CDNs are very likely to reduce the amount of energy
    but might have other negative effects on the health of the internet.
*   Comment on both energy related presentations:
*   IAB is planning on a workshop on this topic in 2023.
*   OPS and RTG ADs discussed whether there is potential work in this
    area, but need to avoid boiling the ocean and work out if there is
    work that could be in scope for the IETF.

1.  Intra-Network eXposure analyzer Utility Specification  
    Savyo Morais  
    https://datatracker.ietf.org/doc/draft-morais-iotops-inxu/

Anthony:

*   We have some experience of this pain point.
*   How are you planning on dealing with communications between CPE and
    controller.

Savyo:

*   Missed response.

Anthony:

*   Worth looking at Broadband Forum TR-069
*   Home gateway might be underpowered (not enough power to do both the
    internet and this filtering/protection)

Anthony:

*   Want to clarify if this for the home uCPE then the computer power of
    those devices is not great. And if there is a

Savyo:

*   As we look to implement this, we will get some operational
    experience to see how well this can work with the given compute
    power.

Rob Wilton:

*   Have you looked at the DOTS working group? Worth collaborating with
    them.

Savyo:

*   Want to present and get comments from them but have not received
    many.

## Ops-Area Section   {#ops-area-section}

1.  Administrivia - scribes, minutes, etc.  
    Warren / Rob

Warren:

*   I'm going to run again as OPS AD, but encourage other to also apply.

Dean:

*   IETF likes an AD to have 2 terms, but will do a third term if
    necessary.
*   IETF encourages WG chairs to step up as being ADs.
*   Can nominate yourself or nominate someone else.

Warren:

*   Trying to appoint third chairs.

1.  ALTO Introduction  
    Qin Wu  
    https://datatracker.ietf.org/doc/draft-ietf-alto-oam-yang/

2.  Open Mic



[1]: https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-direct-export
[2]: https://datatracker.ietf.org/doc/html/draft-ietf-ippm-rfc8321bis