Joint OpsAWG / OpsArea

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

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 and Alternate-Marking Method 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

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