GREEN has a single 2hr session: Mon 16th June, 14:00-16:00 UTC.
draft-belmq-green-framework-03
Slides
Rob: We will cover some of these questions later in the discussion.
Rob: In terms of reporting energy for other devices, it would be good if
we can hide the complexity in the mainline case. Also does this issue
apply both at the device level and also at the controller level?
Benoit: Yes, but the question is about where the problem is solved.
E.g., is this done at the controller level? For example, for the
monitoring use case (how much is my network consuming), avoiding double
accounting is absolutely key. Agree that we should hide the complexity
when presenting the data to the end user/consumer, but someone/somewhere
(the controller?) should have this relationship knowledge.
Diego: I assume there is an implicit recursion here. A controller can be
an energy object for a higher-level controller
Benoit: I make a distinction between the control on a component (and
then the component optimizes itself), such as fan speed or optic
optimizations ... and the control on a different component, such as a
port switch shut down a PoE camera. And there would be models of
recursion as well.
Diego: We raised the issue of aggregation as part of the open questions.
Benoit: there is a 3rd relationship in this version of the framework: An
Aggregation Relationship. A sensor may be aggregating for a number of
different energy objects.
Jan: Need to be auditable. Won't always want to know about the whole
network, need to be able to break it down by customers, or functions.
A Common YANG Data Model for Energy Efficiency Network Management
A Network Inventory Data Model for Energy Efficiency Management
A Network Topology Data Model for Energy Efficiency Management
Slides
Rob: Adoption seems somehow premature, as there is a need of a wider
consensus on open questions, as I will present. We believe a design team
would be required to address this open questions and provide a suitable
common model
Q1.
Benoit: Don't do in sequence. Some things that we have to agree early
one. Need to agree on using the same UUID. Doesn't need to be in
sequence, but if we get wrong building blocks it will be difficult.
Jan: I agree with Benoit. We should also support existing devices. For
devices that want to contribute well there are fundamental concepts.
Basic support no, higher level support concepts need to be aligned.
Emile: We need capabilities to be described in different documents. With
regard to monitoring and control.
Diego: Would those not be part of the common model? How to identify
those capabilities
Q2.
Luis: We need to define some kind of service model, it would help to
identify energy consumption acrros domains, and show customers the
impact of what they are requesting
Rob: Also need to consider ONIONs, e.g., could do using open AI, making
a decision to use YANG Data models.
Diego: We should be considering 3 or 4 different levels. "Inventory" and
"topology", as proposed before, may be misleading. We need to consider
local (per device or component) and aggregated statistics, e.g., either
different topologies or collections of devices. And the information
capabilties.
So we'd have four levels: inventory (the capabilities required by
Emile), local (what is provided by a component or device), aggregated
(for a particular segment, topology, group of devices...) and service
(providing the service view required by Luis)
Jan: Good start to work. Maybe Q3 should be the first one to be
addressed
Q3:
Rob:
Benoit: Talking about energy states without SLA isn't useful. E.g., do
you best if the linecard will come back in one second, or limit the
dataplane capacity to 50%. Not a single way. I think that it is all
relative. Always linked to an SLA.
Rob: I struggle to understand if we can make generic energy states, as
they would not mean the same for different technologies
Benoit: You are making my point.
Emile: I don't know what you mean by SLA, is it an agreed SLA, or IP
SLA.
Benoit: What does it mean, do your best. This is the SLA for the network
service.
Emile: For the power view, we want to optimize the best way. The
component must reduce power consumption.
Benoit: You are right if you take my PC, if on battery, I want you to
last as long as possible. Important to know this.
Rob: If you have a traffic engieering appluied when on backup power, it
may depend on how much time you expect to be on that backup power, for
example.
Emile: I think that there are many use cases, there are different
policies. If it is RAN you may not want to do this. Something that we
must clearly reflect in the data model.
Diego: The Design Team could identify a few (no more than six or eight)
typical power states, corresponding to archetypal power/SLA combinations
(optimal traffic, optimal power consumption, minimal power for a
particular bandwidth, on-batteries...) to be augmented and/or described
by device vendors.
Emile: Can we try and agree on that? Is the redundancy a state related
to the power component? If the device has a shortage of power, does it
make sense for it to tell components.
Robert: Good question to consider battery powered devices. Not only
about the reduction.
Q7. How/where does the data get aggregated?
Benoit: Comes back to topology? Network topology and aggregation
topology. Power consuption for the linecard but also include the power
consumption of each port. If you don't know that the power is the sum on
the linecard for each port then you would get double accounting.
Rob: Is this done in a generic data model, or do you customize is.
Benoit: Alternative is to use UUIDs for each component. If this
relateable.
Benoit: How do we audit this? We only have the YANG object description,
you have first to trust that, and then the device must complex. Yes,
those relationships add complexity. In the issue in GREEN is that there
different topologies: physical, power, control, metering, and
aggregation. The key, as Jan mentioned, is that we must be able to audit
this.
Diego: This needs to be audited separately. E.g., check that your
measurements off the device matches. I.e., a certification process.
Marisol: It would be good to have a design team. There have been several
attempts. I was involved in Poweff that is a good base. Everyone has
been going through some thoughts.
Benoit: Thinking how we can an efficient design team. If we only have
the people who have strong opinions. When I look at the questions, they
are pretty good. If we can address some of those. To answer those
questions, we will need consensus for the entire WG. We would have to
resolve some of those questions.
Rob:
Benoit: Just having a design team discussing those questions, not sure
it will be successful. It might be best for the entire WG to bring
resolution to some of questions raised today. From there, the design
team job will be targeted and hence successful
Diego: Tha's why Rob and I were thinking about keeping a pace of DT
meetings with other interims in which the DT would share their agreed
replies to the open questions, so we align DT work and group consensus
SoH: Should the chairs try and arrange a design team (either now or in a
few months time)?
Y: 9
N: 2
A: 1
SoH: Should we try and arrange more frequent interim meetings (every 2
weeks)?
Y: 7
N: 1
A: 0
Reshad: Every two weeks would be overkill. Maybe monthly would sound
more reasonable
SoH: Should the chairs try and drive discussion/closer on specific key
questions on the list?
Y: 5
N: 0
A: 6