Re: [OPSAWG] [E-impact] Review of Green Networking Metrics, draft-cx-opsawg-green-metrics

[Alexander L Clemm]

Hello Jari,

many thanks for your review comments, much appreciated!  I just posted
an updated revision -02 which takes  your comments into account, here:
https://datatracker.ietf.org/doc/html/draft-cx-opsawg-green-metrics-02.
Some quick inline replies below.  I am cc'ing opsawg, since this is the
WG that will hopefully serve as a landing spot.

--- Alex

On 2/15/2024 6:11 AM, Jari Arkko wrote:

Hi,

I gave a quick read to
https://datatracker.ietf.org/doc/html/draft-cx-opsawg-green-metrics-01 and
had some questions and comments:

Overall, an interesting and useful document.

We furthermore distinguish between primary metrics which are
directly measured, and derived metrics which are computed from
multiple factors.


Question: is there also ”stated” metrics vs. measured metrics, e.g.,
per the manufacturer’s declaration, the (idle) power consumption of
this device is X kWh? Later in S3.1.1 you talk about energy ratings
and data sheets for instance.

 This is already alluded to by the discussion of certification. 
We expanded that paragraph to make it clearer.  ("It should be noted
that just because a metric is stated does not necessarily mean in all
cases that it is accurate or true.  Where this can be a concern, they
should ideally be certified.") 


implementation of packet classification of Ternary
Content-Addressable Memory (TCAM) and the size of TCAM


These seem a bit specific. In another device it might be something
totally different that’s central to the power consumption, e.g., on
wireless the radios.

 True, but it was meant as an example.  Expanded on this to
mention the wireless radio.  ("Depending on the type of device, there
may also be other factors,  such as radios in case of equipment
supporting wireless transmission.") 


Generally, the cost of the first bit could be considered very
high, as it requires powering up a device, port, etc.


Perhaps this is a bit too broad statement, given that the costs are
actually dependent also on the speed at which things can be powered up
or down. Entire devices… often takes long. Some link types… can take
long. Others, maybe less so. Some CPUs and other architectures also
have very dynamic sleep state models that can react at a quick pace.

 As a general statement, I do think this is true - but you are
correct that there are many dependencies and specifics depend on the
particular case.  Expanded the discussion to mention that.  ("Of course,
precise  numbers vary greatly between different devices and device 
architectures, some of which may support dynamic sleep state models 
that are able to transition quickly with limited overhead, thus
mitigating some of those effects.") 


Current power consumption / kB (or gB)

Some consideration should be given for different tasks and classes of
devices. A Bluetooth transmission != 100-km fiber transmission != WAN
radio to a mobile device.

 Sure, but even where the actual values may differ greatly, the
metric itself remains the same.  The possibility that you can perform
further differentiation by device component is already discussed in
section 3.1.1.  I am not sure what other textual update we would need
here? 


An important aspect concerns the device's power source.


Yes. Maybe you could have some discussion of where this information
resides, e.g., it could be that some local information distribution
could make the device aware of this, or is this something that is fed
from separate backend systems to the network management algorithms?

 I think there is a risk here of getting sidetracked into a
discussion of technical solutions, as opposed to the metrics
themselves.  That being said, I added some text to take your comment
into account: "Even in cases where a power source does not independently
provide such data, it is conceivable to  use controllers and/or
management systems to provision certain devices with it to make those
device and the network aware of it to allow network-embedded algorithms
to take such information into account."


3.1.3. Virtualization Considerations


Nice! Liked in particular the CPU power proportionality observation.

3.2. Green Metrics related to Flows


Some discussion related to usefulness of measurements vs. effort and
power consumption needed for a measurement might be in order here. I
guess sampling _some_ flows and not all will be a way to go, but
perhaps that should be stated? Thoughts?

 I don't think we need to get into how we would conduct the actual
measurement.  However, you are correct that of course the benefit of an
accurate reading of a metric must outweigh the cost of obtaining it. 
For this particular item, I think the text does imply that we would not
measure things on a packet-by-packet basis but can be obtained
differently (compute the proportion of flow traffic to overall traffic,
multiple this with the total energy consumption incurred by the device
during that time), hence I don't think the sampling consideration

Re: [OPSAWG] [Inventory-yang] Getting rid of network-hardware-inventory container for straightfoward model alignment that satisfies both hardware inventory needs and generalization/extensibility goals

[Alexander L Clemm]

Hello Bo, all,

to your question:  With the two inventory models, I was referring to the 
two models in the two drafts as per the poll, i.e.:


(1) draft-ietf-ccamp-network-inventory-yang-02 
(ietf-network-hardware-inventory)


 (2) draft-wzwb-opsawg-network-inventory-management-03 
(ietf-network-inventory)


To recap the point I was trying to made:  I think both models are closer 
than it may initially appear.  The main obstacle to aligning is the 
top-level container in ietf-network-hardware-inventory, 
"network-hardware-inventory". This object seems to serve no particular 
purpose, so could be easily removed.  In doing so, "equipment-rooms" and 
"network-elements" would become top level objects, separable into 
separate modules (both of which can be specified in the same draft, of 
course).  It will make sense for equipment-rooms to stand on its own 
anway since this contains _location_ information - this information can 
of course be referenced by items in the inventory, but the rooms by 
themselves are not part of the network-hardware-inventory (as the 
current model seems to suggest) and locations other than rooms are 
conceivable in some cases.  So, not only will removing the top-level 
container make ietf-network-hardware-inventory facilitate alignment, but 
it will also arguably result in a "better" model.


Looking forward to continued discussions

--- Alex

On 9/11/2023 2:19 AM, Wubo (lana) wrote:


Hi Alex, all,

It seems to me you mentioned two IVY models, one is the BASE inventory 
model with minimum inventory attributes, and the other seems to be the 
CORE inventory model, which is the major requirements as charter B. 
Hardware/Software components including licenses. Am I correct?


In addition, you also mentioned that the CCAMP 
"network-hardware-inventory"may develop independently, as the 
requirements seems different from the IVY core model, since the 
equipment room is only for the indoor RACK location, not for the 
outdoor location.


I also have the same doubts. Is the goal of CCAMP inventory same as 
IVY CORE inventory model? Last Wednesday CCAMP inventory weekly call, 
I explained the following use cases from 
draft-wzwb-opsawg-network-inventory-managementand proposed the merged 
network inventory model :


1. Virtual devices, such as vCPE, vPE, vBNG, etc.

2. Software components, including device platform software, software 
patch, boot-rom, bootloader, etc.


3. Site as a location option

4. License list

5. Terms of network inventory, including network inventory, network 
element, and components


6. The merged network inventory model

Here is some feedback and summary got on the call:

1.Some authors say virtual device, and software components are not 
considered, as the purpose of CCAMP inventory is to meet ACTN Packet 
Optical integration (POI) requirements for optical and IP multi-domain 
TE cases etc, 
https://datatracker.ietf.org/doc/html/draft-ietf-teas-actn-poi-applicability#section-4.


2. Some author shared the inventory information of Cisco vPE, 
indicating that virtual devices share the same inventory attributes 
just as physical devices:


RP/0/RP0/CPU0:ron-srpce-791#show inventory all Wed Sep 6 14:50:04.239 UTC

NAME: "0/0", DESCR: "Cisco IOS-XRv 9000 Centralized Line Card"

PID: R-IOSXRV9000-LC-C, VID: V01, SN: B3BC8301B42 NAME: "0/0/0", 
DESCR: "N/A"


PID: PORT-1G-NIC, VID: N/A, SN: N/A NAME: "0/0/1", DESCR: "N/A"

PID: PORT-1G-NIC, VID: N/A, SN: N/A NAME: "0/0/2", DESCR: "N/A"

PID: PORT-1G-NIC, VID: N/A,SN: N/A NAME: "0/0/3", DESCR: "N/A"

PID: PORT-1G-NIC, VID: N/A, SN: N/A NAME: "0/0/4", DESCR: "N/A"

PID: PORT-1G-NIC, VID: N/A, SN: N/A NAME: "0/0/5", DESCR: "N/A"

PID: PORT-1G-NIC, VID: N/A, SN: N/A NAME: "0/0/6", DESCR: "N/A"

PID: PORT-1G-NIC, VID: N/A, SN: N/A

NAME: "0/RP0", DESCR: "Cisco IOS-XRv 9000 Centralized Route Processor"

PID: R-IOSXRV9000-RP-C, VID: V01, SN: 59D4943FFB2 NAME: "Rack 0", 
DESCR: "Cisco IOS-XRv 9000 Centralized Virtual Router"


PID: R-IOSXRV9000-CC, VID: V01, SN: 76E77892EA1

3. The author has previously discussed the extension of sites and 
licenses.


4. The authors and contributors took a quick look at the merged model, 
and we plan to continue the discussion on this week.


Thanks,

Bo Wu

*From:*OPSAWG  *On Behalf Of *Alexander L Clemm
*Sent:* Thursday, September 7, 2023 4:59 AM
*To:* maqiufang (A) ; 
inventory-y...@ietf.org

*Cc:* ivy-cha...@ietf.org; opsawg ; cc...@ietf.org
*Subject:* [OPSAWG] Getting rid of network-hardware-inventory 
container for straightfoward model alignment that satisfies both 
hardware inventory needs and generalization/extensibility goals (was: 
Re: [inventory-yang] poll for network inventory base model)


Hi all,

I have been looking at both of th

[OPSAWG] Getting rid of network-hardware-inventory container for straightfoward model alignment that satisfies both hardware inventory needs and generalization/extensibility goals (was: Re: [inventory

[Alexander L Clemm]

Hi all,

I have been looking at both of the inventory models that have been 
proposed and think that they are actually closer than it might seem and 
that it should be relatively straightforward to align them.


The main obstacle seems to the top container object 
"network-hardware-inventory" in 
draft-ietf-ccamp-network-inventory-yang.  Is this data node really 
important?  It seems to serve not particular function, other than 
serving as a container for equipment room  and network-elements. 
However, both could easily stand on their own; there does not seem to be 
a compelling reason that instances would need to be prefixed with 
"network-hardware-inventory/".


By removing this object, we get in effect two separate modules - one for 
equipment-room, the other for network-elements.  This makes sense 
anyway, as only network-elements are items subject to inventorying and 
equipment-room can stand on its own, providing auxiliary information 
independent of actual inventory (plus allowing for network elements to 
be housed also outside equipment rooms  (Plus, depending on use case, 
not every network element may not be located in an equipment room with 
racks/rows/columns, but possibly in other locations eg roadside etc).


The structure of network-elements now very much resembles the same 
structure as we have in draft-wzwb-opsawg-network-inventory-management.  
Yes, the list is defined in the model, instead of reusing / augmenting 
the list of nodes, but this is a detail - the main thing is the 
structures are aligned.


The main difference from this point out concerns the actual parameters 
that are actually included.  Both models have a set of parameters in 
common.  draft-ietf-ccamp-network-inventory-yang includes a couple of 
additional hardware parameters, while 
draft-wzwb-opsawg-network-inventory-management includes additional 
subtrees for licenses etc.  It would seem that it would be 
straightforward to define the common set of parameters as part of the 
base model, then define additional augmentations to incorporate other 
aspects of inventory as needed.  Hardware inventory models would make 
the start, of course, as this has the most pressing need of being 
defined; at the same time the  model structure provides the hooks and 
implies a design pattern that will allow other aspects of inventory 
(virtual network elements, licenses, etc) to be added in an integrated 
fashion as needed.


As a broad sketch, the resulting model structure would then be composed 
of base inventory model (defining the network-elements list with very 
few very basic data nodes, perhaps just name and asset tag) , augmented 
with a hardware inventory model which adds augmentations for  the 
hardware parameters and components hierarchy and a separate equipment 
room model.  This covers everything that we have in 
draft-ietf-ccamp-network-inventory-yang.  Then, IVY can add a model for 
virtual network element inventory (augmented in per the same pattern as 
the hardware model), license inventory, and anything else, per the 
additional stuff that we have in 
draft-wzwb-opsawg-network-inventory-management.


So, in that sense I don't think we have to make a hard choice between 1 
and 2, but merge and in the course make some alignments to both.  For 
example, one could start with draft-ietf-ccamp-network-inventory-yang, 
modifying it to remove the network-hardware-inventory container and 
splitting the remaining module in two (for equipment-room and 
network-elements, both of which will now be top-level containers).  
Remaining modifications can be made from there.  I guess this makes me a 
proponent of option 3, but with the caveat that this would not need to 
restart from scratch - really an option 4 that says merge (for overall 
structure and common parts, which in this case is possible) and split 
the remaining difference.


--- Alex

On 8/27/2023 11:21 PM, maqiufang (A) wrote:


Hi Working Group,

It’s now time to start considering how to move forward with the 
inventory base model. We have two different documents that could be 
used as a starting point for our work or, in case the working group 
believes none of them is “good enough”, we can start a brand new ID.


In case the latter option is chosen, Daniele and I will write a -00 
version including just the table of content and what we’d like to be 
covered in each section. The document will then be handed over to a 
pool of authors which will bring it till the WG adoption.


Hence, we will have a 3 weeks polling starting today. We decided to 
make it a bit longer than usual because this time the working group is 
requested to review two drafts instead of one.


This mail starts a 3 weeks polling, terminating on September 15^th , 
 where we would like the working group to express your preference among:


 1. Adopt draft-ietf-ccamp-network-inventory-yang-02 in IVY and evolve
it to become the network inventory base model
 2. Adopt 

Re: [OPSAWG] [inventory-yang] poll for network inventory base model

[Alexander L Clemm]

I think that options 1 and 2 are closer than we think and can be aligned 
if we can agree on getting rid of the network-hardware-inventory 
container object that is defined in draft-ietf-ccamp-network-inventory.  
This will allow us to move forward quickly with a model for network 
hardware inventory, as required by ccamp, while preserving the option 
for a model that can be generalized and extended to incorporate other 
types of inventory, as desired by ivy.  I'll describe a bit more details 
in a separate email in order to not distract from the poll.


I guess this makes me a proponent of option 3, but with the caveat that 
this would not need to restart from scratch.  Instead it can be derived 
in very straighforward manner from the existing models with these slight 
alignments as described.  I am also sure that a lot of the existing text 
can be salvaged.


--- Alex

On 8/27/2023 11:21 PM, maqiufang (A) wrote:


Hi Working Group,

It’s now time to start considering how to move forward with the 
inventory base model. We have two different documents that could be 
used as a starting point for our work or, in case the working group 
believes none of them is “good enough”, we can start a brand new ID.


In case the latter option is chosen, Daniele and I will write a -00 
version including just the table of content and what we’d like to be 
covered in each section. The document will then be handed over to a 
pool of authors which will bring it till the WG adoption.


Hence, we will have a 3 weeks polling starting today. We decided to 
make it a bit longer than usual because this time the working group is 
requested to review two drafts instead of one.


This mail starts a 3 weeks polling, terminating on September 15^th , 
 where we would like the working group to express your preference among:


 1. Adopt draft-ietf-ccamp-network-inventory-yang-02 in IVY and evolve
it to become the network inventory base model
 2. Adopt draft-wzwb-opsawg-network-inventory-management-03 in IVY and
evolve it to become the network inventory base model
 3. Start a brand new document from scratch as described above

In the week after the closure of the polling (between September 18 and 
25) we will have an IVY interim meeting to discuss the issues/concerns 
raised during the polling ( A separate mail will be sent).


Thank you,

Qiufang and Daniele


___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Some thoughts on Green Networking Metrics

[Alexander L Clemm]

I think the purpose of what the network inventory is supposed to be used 
for needs to be clarified more generally, which will also answer the 
question here.


I believe that fundamentally “inventory” is just that: an inventory of 
what is there, or supposed to be there.  Generally something that you 
could attach an “asset tag” to, either physical or virtual.  That is, 
basically it constitutes “static” information.  (Of course it can still 
change over time, but changes will occur on slower time scales (e.g. 
minutes to days, not subseconds) and it does not include dynamic state 
of the assets themselves.)  So, with inventory being understood that 
way, dynamic information (such as current consumption) is simply not a 
part of it.  That being said, static aspects that describe properties of 
the assets in the inventory might be – information such as equipment 
type, which could be tied also to data sheet stuff such as power ratings.


That being said, there may also be a need for a holistic view of the 
network, providing a view of current status etc.  To organize this 
information, utilizing a network inventory model is a natural 
candidate.  However, the needs for this type of use are different from 
those of a traditional inventory. Crucially, this data would not be 
“owned” e.g. by a controller having a network view, but by the 
individual devices in question, where it would also be retrieved from or 
subscribed to.  This means that you would need to organize this not as 
part of a network inventory, but as part of the data provided by the 
device.  (In the past, this would be broadly referred to as the device’s 
Management Information Base, or MIB – not to be confused with MIBs in 
the narrower SNMP sense).


From that perspective, dynamic metrics such as the current power 
consumption do not belong in the network inventory as currently 
defined.  If we wanted to put it there, the next question would be why 
stop there?  Why not put other operational data there as well, why not 
configuration data? Arguably you could organize any type of management 
data into a network inventory, which would however not take into the 
account the fact that in general, you will access most management data 
from the device directly.


--- Alex

On 8/21/2023 7:22 AM, Tianran Zhou wrote:

Hi Daniele,

Thanks for the clarification.
Now I understand what you want to include is static value.

Best,
Tianran



Sent from WeLink
*发件人： *Daniele Ceccarelli
*收件人： *Tianran Zhou
*抄送： *Alexander L Clemm;opsawg
*主题： *Re: [OPSAWG] Some thoughts on Green Networking Metrics
*时间： *2023-08-21 20:33:57

HI Tianran, Alex,

the power consumed at a given time is highly changing over time, but 
parameters like e.g. power consumption of a card at 50%, 75% and 100% 
of the load don't.
I don't disagree with Alex when saying that this is not directly 
inventory, but it's strictly related to it and should probably be an 
augmentation of the device inventory.


BR
Daniele

On Fri, Aug 18, 2023 at 3:20 AM Tianran Zhou 
 wrote:


I am not quite clear about the applicability of the inventory.

What’s the difference with hardware model or entity model.

I see energy work was related to entity mib in eman before:

https://datatracker.ietf.org/wg/eman/documents/

It seems inventory should be something static from the name. But
IMO, the energy metrics are dynamic, can will change all the time.

Best,

Tianran

*From:*OPSAWG [mailto:opsawg-boun...@ietf.org] *On Behalf Of
*Alexander L Clemm
*Sent:* Friday, August 18, 2023 7:05 AM
*To:* opsawg@ietf.org
*Subject:* Re: [OPSAWG] Some thoughts on Green Networking Metrics

Hi Daniele,

apologies for the late reply.

I think inventory is somewhat orthogonal to this, but of course
devices and equipment (including chassis, line cards, equipment
holders etc) will be considered part of inventory.   Therefore via
transitive closure it is certainly conceivable to make power
consumption data accessible via inventory.  This could make sense
as part of a consolidated controller view of a network.  However,
on a network element itself, the network inventory aspect would
not apply but the metrics should still be available so the
device/equipment level category still applies.  As to whether
device level data should be replicated as part of network
inventory data  would presumably depend on the use case.

--- Alex

On 7/26/2023 6:35 PM, Daniele Ceccarelli (dceccare) wrote:

Hi Alex, all,

Just following up on the comment I did ad the mic earlier today.

The drafts speaks about metrics at: device/equipment level,
flow level, path level, network level.

The  device/equipment level covers power consumption per
chassis, line card and port at different loads of traffic,
hence IMO should fall

Re: [OPSAWG] Some thoughts on Green Networking Metrics

[Alexander L Clemm]

Hi Daniele,

apologies for the late reply.

I think inventory is somewhat orthogonal to this, but of course devices 
and equipment (including chassis, line cards, equipment holders etc) 
will be considered part of inventory.   Therefore via transitive closure 
it is certainly conceivable to make power consumption data accessible 
via inventory.  This could make sense as part of a consolidated 
controller view of a network.  However, on a network element itself, the 
network inventory aspect would not apply but the metrics should still be 
available so the device/equipment level category still applies.  As to 
whether device level data should be replicated as part of network 
inventory data  would presumably depend on the use case.


--- Alex

On 7/26/2023 6:35 PM, Daniele Ceccarelli (dceccare) wrote:


Hi Alex, all,

Just following up on the comment I did ad the mic earlier today.

The drafts speaks about metrics at: device/equipment level, flow 
level, path level, network level.


The  device/equipment level covers power consumption per chassis, line 
card and port at different loads of traffic, hence IMO should fall 
into the inventory category.


Would you agree?

Cheers,
Daniele


___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

[OPSAWG] Green Networking Metrics - new draft revision

[Alexander L Clemm]

Hi,

FYI, we have just posted an update to the draft "Green Networking 
Metrics", renamed draft-cs-opsawg-green-metrics to reflect the fact that 
we consider OPSAWG to be the appropriate landing spot, per earlier 
discussions after presentation of predecessor versions at previous 
IETFs.  The draft can be found here: 
https://datatracker.ietf.org/doc/draft-cx-opsawg-green-metrics/


We have made a number of updates from the previous revision. These 
include a new section 4.6 on related metrics defined elsewhere, notably 
ETSI, and a new section 5 on controversies, discussing pitfalls and 
caveats related to the use and interpretation of metrics in isolation 
(taking into account a longer discussion thread on the e-impact mailing 
list).   The new draft also provides a better distinction between the 
concepts of energy efficiency and carbon footprint and strengthens the 
distinction between "primary" (directly measured) and "derived" 
(computed on the basis of other metrics) metrics.  Furthermore, it calls 
out specific uses for certain metrics, in addition to various other 
editorial updates and additional references.


Comments and suggestion are very welcome!

--- Alex (on behalf of coauthors)

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] [nmrg] New revision of "Green Networking Metrics" (draft-cx-green-metrics)

[Alexander L Clemm]

Hi Haoyu,

thank you for your comments.  A couple of quick replies:

Re: 1) Clearly normalization is important and the challenge there is to 
come up with metrics which are both useful and straightforward to 
implement.  IMHO the starting point will include the "raw" metrics; 
applying any formulas or factors should be done as part of second-order 
metrics.  As for separating out how much carbon footprint should be 
attributed to a computation task versus a networking task for devices 
that perform in-networking computing, I am not sure this will always be 
practical.  However, you could in fact use the metrics that are proposed 
in the draft to account for that at the networking level.   Here you 
look at the overall energy consumption or the network as a whole, not 
just the sum of individual devices.  This will allow you to account for 
"hidden" polluters etc, and use that to apply some factor or "tax" to 
come up with the true holistic picture.  In cases where you have 
networking devices that have a large carbon footprint, but that obviate 
the need for separate devices that would otherwise not be accounted for, 
this factor will be a lot smaller than would otherwise be the case.


Re: 2) The intent here is to focus on the "what" not on the "how". That 
being said I think there are a number of things that can be done to 
measure or at least estimate these.  A simple example would, for 
example, determine what fraction of a device's traffic volume can be 
attributed to a particular flow (this is straightforward), then apply 
that fraction to the carbon footprint of the device overall to determine 
the flow's share of it.


Re: 3) Of course if you send many bits you divide the share among them.  
What is meant here is the incremental cost of sending a bit.  If you 
sent just a single bit, that would involve a high incremental cost 
(which will be incurred even if you send no further bit); if you were to 
send a second bit immediately after that, that one would involve a very 
low incremental cost.


Cheers

--- Alex


On 3/9/2023 11:29 AM, Haoyu Song wrote:

Hi Alex,

This is an interesting read. Here I provide some comments and observations.
1. I think the energy consumption metrics on equipment is more meaningful when 
it's normalized to the device's capacity and capability. For example, energy 
per bit can be used to compare which is greener between two devices if they 
offer the same function. On the other hand, if a device does more processing 
(e.g., in network computing), it's likely it will consume more energy, but it 
also makes the overall solution more efficient, so it's still greener in this 
sense.
2. The flow and path energy metrics is interesting but I wonder how it can be 
measured in reality? If this is doable, then perhaps application/job level 
energy consumption metrics should also be included (e.g., in HPC DCNs, a job 
may involves multiple flows and multiple paths). This level of granularity may 
be more preferred in evaluating  different solution architectures.
3. In section 3.1.1, it seems unfair to attribute the cost to only the first 
bit. It's meaningless to send only one bit anyway so the cost should be shared 
by all the bits.:)

Best regards,
Haoyu

-Original Message-
From: OPSAWG  On Behalf Of Alexander L Clemm
Sent: Wednesday, March 8, 2023 5:35 PM
To: opsawg@ietf.org; n...@irtf.org
Cc: draft-cx-green-metr...@ietf.org
Subject: [OPSAWG] New revision of "Green Networking Metrics" 
(draft-cx-green-metrics)

Hi,

we just posted an updated revision of "Green Networking Metrics"
(https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-cx-green-metrics%2F=05%7C01%7Chaoyu.song%40futurewei.com%7C2643e0c419c1408dad4a08db203e9a42%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638139225483790907%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=USheN9sfG%2FwDm8Yy9aTy20SacMv%2B1Zd6hbiiPP63iHg%3D=0),
 including various editorial improvements and incorporating highly useful feedback and suggestions 
from a number of people including Eve Schooler, Alexandru Petrescu, and Michael Welzl.  The draft 
defines a set of "green" networking metrics that will be useful as basis for management and 
control applications that aim to reduce carbon footprint and hence require visibility into such 
metrics.

We believe that in terms of scope, this draft falls into the intersection of 
opsawg and nmrg interest and we hope to have the opportunity to present at IETF 
116 in Yokohama, hence we are crossposting to both groups.  Personally I 
believe that opsawg may be the most suitable landing spot as the draft can be 
easily operationalized and is not as much concerned with open-ended research 
questions, but that is of course where we would appreciate feedback from the 
groups.  Once a decision is made for the pr

[OPSAWG] New revision of "Green Networking Metrics" (draft-cx-green-metrics)

[Alexander L Clemm]

Hi,

we just posted an updated revision of "Green Networking Metrics" 
(https://datatracker.ietf.org/doc/draft-cx-green-metrics/), including 
various editorial improvements and incorporating highly useful feedback 
and suggestions from a number of people including Eve Schooler, 
Alexandru Petrescu, and Michael Welzl.  The draft defines a set of 
"green" networking metrics that will be useful as basis for management 
and control applications that aim to reduce carbon footprint and hence 
require visibility into such metrics.


We believe that in terms of scope, this draft falls into the 
intersection of opsawg and nmrg interest and we hope to have the 
opportunity to present at IETF 116 in Yokohama, hence we are 
crossposting to both groups.  Personally I believe that opsawg may be 
the most suitable landing spot as the draft can be easily 
operationalized and is not as much concerned with open-ended research 
questions, but that is of course where we would appreciate feedback from 
the groups.  Once a decision is made for the proper landing spot, 
hopefully immediately following IETF 116, we will post a new revision 
under the respective working group.


FYI, here is the abstract of the draft:
This document explains the need for network instrumentation that allows 
to assess the power consumption, energy efficiency, and carbon footprint 
associated with a network, its equipment, and the services that are 
provided over it.  It also suggests a set of related metrics that, when 
provided visibility into, can help to optimize a network's energy 
efficiency and "greenness".


On behalf of the coauthors
--- Alex

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] [recipe] And another new draft revision: Green Networking Metrics

[Alexander L Clemm]

Hello Eve,

thank you for your great feedback!  And apologies for the long delay in 
responding.  Please find my responses inline, below.  We will also be 
posting an update to the draft momentarily with your feedback 
incorporated (hence crossposting to opsawg)


Best

--- Alex

On 11/29/2022 11:53 PM, Schooler, Eve M wrote:

Hi Alex and co-authors,
Thanks for a very interesting read 
(https://datatracker.ietf.org/doc/draft-cx-green-metrics/)!
Here is some informal feedback on the latest version of the draft document.
Best regards,
Eve

Eve M. Schooler, PhD
Principal Engineer & Director
Intel | CSO & NEX | Emerging IoT Networks
2200 Mission College Blvd., Santa Clara, CA, USA  95054
+1 650.868.7369
-

Abstract:
In the abstract there is reference to "power consumption, energy efficiency and carbon 
footprint", for both network equipment and services provided over it - would be great to 
describe the relationship between these three attributes somewhere. In the Intro, language is also 
used re "environmental sustainability of networks", which may go beyond energy-related 
metrics.

Section 1. Intro
- Why cite the Telefonica Consolidated annual report vs Sustainability report?
 The consolidated report includes an extensive section on 
sustainability along with the data.  I am not aware of a separate 
sustainability report (although I am sure it must exist). 


Section 2. Definitions and Acronyms
- Include kWh

We have added it (and a few more) 

Section 3. Energy Metrics
- For each bullet, give examples of existing metrics.
- 3rd bullet references energy intensity. Is this a term commonly used? Does it 
need specific definition
- Either way, contrast this with carbon intensity.
 The term "energy intensity" has been removed.   We have also added 
further explanation on the relationship between carbon footprint, energy 
consumption, etc 


3.1.1 Energy consumption Metrics
- Any thoughts/precedent on how to separate the carbon footprint of a device 
from the networking aspects of the device?
 I am not sure what you mean here exactly.  Do you mean devices 
performing both compute and networking?  I think in general those would 
be difficult to separate.  I think if we can do a breakdown of the 
device to the component level (cards and ports), that may already be 
plenty. 

- Are we only gaging router power consumption, or other network HW elements? 
What about SW? Different parts of the stack?
 The focus is on network HW elements (section 3.1 "Metrics related 
to [networking] equipment").  It is probably difficult to attribute to 
software in itself, although section 3.1.3 talks about the attribution 
to functions realized as software ("Virtualization Considerations").  We 
also added discussion in section 3.1.2 regarding additional factors such 
as ""taxation" for unattributed energy use, for taking into account 
sustainability of energy sources (energy-aware vs pollution-aware), for 
potentially transposing those into CO2 emission factors, etc. 

- Love the reference to ATIS, which makes me wonder about certification of the 
numbers associated with the various device elements and the devices overall?
 I totally agree that certification is super important and we 
expanded on that aspect.  

- Re "The second set of metrics reflects the actual power being drawn during 
operation." What about embodied carbon, which for smaller devices such as phones is 
a dominating factor?
 This is an important point and discussion of this added in the 
section on "Holistic Perspective".  However, due to the myriads of 
factors at play here, we did not add specific metrics, just mention that 
corresponding metrics and discount factors (or pollution factors, 
depending on perspective) could be defined. 

- Odd to see the terms "kilooctet" and "gigaoctet"; why not simply kB or gB? 
Yes to pico Joules.

 Fixed it. 


3.1.2 Other Metrics
- A common sustainability rating of the power source is carbon intensity. A 
good publication to read, where carbon intensity is considered, but so is a 
waste metric to capture environmental impact beyond energy and carbon:
 + Hossain, Md. Mohaimenul, Georges, Jean-Phillippe, Rondeau, Eric, Divoux, 
Thierry. Energy, carbon and renewable energy: Candidate metrics for green-aware 
routing? Sensors, 19(13), Feb 2019.
- "It may be possible to obtain such a rating from the energy operation"
 + I really like that the document includes such a statement. It would be 
helpful for each of the metrics discussions to include: from whom the 
measurements for the metric might originate
- If deployment of the device is outside a Data Center (DC) and actually is in 
the wild, e.g., an RSU (road side unit), should the device be charged an energy 
tax for releasing its heat into the atmosphere?
 Thank you for the reference, indeed a great one!  We added some 
related discussion in Section 3.1.2 ("Green Metrics Beyond Energy 
Consumption").  However, we decided to not add the discussion about 
where 

Re: [OPSAWG] CALL FOR ADOPTION: An Update to the tcpControlBits IP Flow Information Export (IPFIX) Information Element

[Alexander L Clemm]

Clearly we need to keep the registries up to date.  I support the 
adoption as well, including the other draft as mentioned by Thomas.


As a side note, for future reference it would be good to have some 
guideline when the registry can simply be updated versus when a separate 
draft is required to update or introduce a new Information Element.  
(Perhaps this has been discussed and someone has a pointer they can share.)


--- Alex

On 1/21/2023 7:20 AM, thomas.g...@swisscom.com wrote:


Dear opsawg,

I support the adoption and think draft-boucla-opsawg-ipfix-fixes 
should follow the adoption call next as well. Both are very valuable 
to keep the IPFIX registry up to date.


I agree with the author that IE6 tcpControlBits should mirror the TCP 
header flags registry 
(https://www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml#tcp-header-flags). 



With this update network operators understand when packets are being 
observed with bit 7 set which application in the network should be 
upgraded to reflect the change being introduced with RFC 8311.


I suggest in the introduction to take the angle of correct 
observability vs. TCP protocol interoperability to describe the 
motivation.


Best wishes

Thomas

*From:*OPSAWG  *On Behalf Of *Joe Clarke 
(jclarke)

*Sent:* Tuesday, January 17, 2023 5:25 PM
*To:* opsawg@ietf.org
*Subject:* [OPSAWG] CALL FOR ADOPTION: An Update to the tcpControlBits 
IP Flow Information Export (IPFIX) Information Element


Happy new year, all.  One of the AIs that slipped through the cracks 
coming out of 115 was a call for adoption for 
draft-boucadair-opsawg-rfc7125-update.   One of the asks of Med at 115 
was to look at what else might need to be done from an IE registry 
standpoint.  He replied on-list to that a while ago:


“Yes, I had a discussion with Benoît during the IETF meeting to see 
how to handle this. We agreed to proceed with at least two documents:


  * draft-boucadair-opsawg-rfc7125-update to update the TCP IPFIX RFC.
  * Edit a second draft to “clean” other entries in registry. This
document is intended to include only simple fixes and which do not
require updating existing RFCs. The candidate list of these
proposed fixes can be seen

athttps://boucadair.github.io/simple-ipfix-fixes/draft-boucla-opsawg-ipfix-fixes.html

.
New IEs, if needed, will be moved to a separate document.
simple-ipfix-fixes may or may not be published as an RFC.”

So, let this serve as a two-week call for adoption for the existing 
draft-boucadair-opsawg-rfc7125-update document.  Please reply on-list 
with your comments, support, or dissent by January 31, 2023.


Thanks.

Joe


___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] IPR Poll for draft-opsawg-ntf

[Alexander L Clemm]

I am not aware of any IPR (responding as contributor).

Thanks

--- Alex

On 9/23/2020 8:41 PM, Pedro Martinez-Julia wrote:
> Dear Tianran,
>
> I am one of the authors of the document and I am not aware of any IPR
> that applies to it.
>
> Regards,
> Pedro
>
> On Thu, Sep 24, 2020 at 02:58:51AM +, Tianran Zhou wrote:
>> Hi Authors,
>>
>>
>>
>> Accompany with the WG LC, this mail starts the IPR poll.
>>
>>
>>
>> Are you aware of any IPR that applies to draft-opsawg-ntf-04?
>>
>>
>>
>> If you own or are aware of any IPR that applies to draft-opsawg-ntf-04, 
>> please clarify whether this IPR been disclosed in compliance with IETF IPR 
>> rules (see RFCs 3979, 4879, 3669 and 5378 for more details).
>>
>>
>>
>> If you are listed as a document author or contributor please respond to this 
>> email in OPSAWG mailing list regardless of whether or not you are aware of 
>> any relevant IPR. The document will not advance to the next stage until a 
>> response has been received from each author and contributor.
>>
>>
>>
>> If you are not listed as an author or contributor but are on OPSAWG mailing 
>> list, then please explicitly respond if you are aware of any IPR that has 
>> not yet been disclosed in conformance with IETF rules.
>>
>>
>>
>> Thanks,
>>
>> Tianran

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

[OPSAWG] Comments on draft-song-opsawg-ifit-framework-09

[Alexander L Clemm]

Hi Haoyu, Draft Authors,

after reading draft-song-ifit-framework-09, whose adoption I support, 
FWIW I have a few comments that I think should be addressed in future 
revisions of the draft:


Section 1, 2nd paragraph: line of argumentation why "radical rethinking 
of existing methods" needs to be strengthened.  While reasoning is given 
that the importance of monitoring and troubleshooting continues to grow, 
I don't think there are convincing arguments given why rethinking and 
new methods would be required, and the framework itself does not really 
propose such methods.


Section 1, C2: It should be mentioned that the growing OAM data can also 
negatively affect service levels.  For example, if telemetry data keeps 
getting added at each hop, not only does the packet grow but also its 
serialization delay, which could be detrimental in some cases.  
(Possibly this could even be listed as additional challenge C.2.5)


Section 3, in particular Figure 1: (I consider this my most important 
comment):  I don't think the Figure and the introductory text that 
surrounds it does a framework justice.  What is being depicted in the 
figure seems to be a fairly generic monitoring/telemetry collection 
architecture, not a new framework, and made me even question why we 
would produce a document just for that?  Importantly, the key components 
of iFIT which are listed in section 4 are not depicted in the Figure, 
nor are they mentioned as part of the framework in section 3.  I do 
think that those key components are important and their integration with 
the framework crucial.  A framework that explains how things like smart 
data export, smart flow selection, a choice of different probing 
techniques, etc complement each other and work in concert makes a lot of 
sense.  I think section 3 needs to be updated to make sure that it does 
not sell iFIT short.


Section 4 (or 3?):  The document should explain better why iFIT is 
called iFIT, not iPIT.  In other words, that it does not limit itself to 
packet telemetry, but indeed flow telemetry (which includes, for 
example, the aspects of probing and smart flow selection, which aim at 
getting a picture of flows in their entirety.  This aspect is important 
but easily lost on the reader.


Section 4.2 cannot be addressed by iFIT as it is currently stated, as it 
is missing an aggregation function.  I suggest that such a function is 
added and explicitly listed as a key component at the onset of section 4.


Section 4.5 likewise does not make it clear how its topic (on-demand 
technique selection and integration) gets addressed using the 
framework.  I think what section 4.5 is super important but some editing 
will be needed to make clear how these important aspects are being 
accomplished using the framework and its component.  As is, the 
framework and some of these aspects stand too much side-by-side.


Kind regards

--- Alex

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg