Green BoF requirements collections

6.1. Inventory and Discovery

Based on the framework discussed during the BoF, the architectural requirements for the "GREEN" Framework:¶

From a network inventory [network-inventory] point of view, when discussing Energy Efficiency metrics, also known as GREEN metrics, it is important to distinguish between static and dynamic attributes:¶

"Static" attributes refer to those that do not change based on the state of the network infrastructure. The following examples are all static attributes that we can relate to the inventory, implemented in the network devices or as part of external sources:¶

• Serial number¶

• Product name¶

• Part number¶

• Vendor¶

• Device family¶

• Sensor(s)¶

Static attributes also include benchmarking information related to energy consumption by design and test conditions, normally associated to PSU's, line-cards, etc.:¶

• Idle power¶

• Max power¶

• Typical power¶

• Accuracy rate¶

• PSU efficiency (80+)¶

• Power allocation¶

• Etc.¶

These attributes might be collected from the device/component itself or they might be parameters as part of external sources, i.e., databases owned by the hardware or software providers, where API access will be preferred.¶

Normally, the "Discovery" process will be updating static attributes that represent the up-to-date inventory of the network. The Discovery process relates primarily to the static attributes, where will consider if a device or component has been replaced or is out of service. The "Operation" process will be updating the so-called dynamic attributes.¶

Dynamic attributes are those that are subject to change due to the running operations, including configuration and state changes, and they will need to be collected regularly.¶

They will be updated as part of the regular operations. Dynamic attributes might be related to sensors(environmental), traffic, state, etc. They will include attributes like:¶

• Temperature¶

• Current¶

• Voltage¶

• Power¶

• Input and output traffic¶

The data collection frequency might need to be adjusted based on the specific attributes. For example, the discovery of linecards installed on network devices will not change every hour, whereas temperature and power sensor information changes will need to be closer to real-time.¶

Even though sensors normally are embedded in the network device/component, there are external sensors meant to measure temperature and energy consumption. The network controller will need to collect and correlate information to compose the right GREEN metric for the network device/component.¶

!!! <<TBD>> GAP?? Definition for "Discovery" @ IETF references has not been found.¶

6.2. GREEN Metrics

Based on the work initiated under [I-D.draft-cx-opsawg-green-metrics-02], it might be required to prioritise the definition and data models for the metrics relevant to the components and network elements, as they will be the ones influencing the most to the metrics related to flows, path and network.¶

6.3. Monitor and Performance

Monitor and Performance will include the guidelines for the association of the different attributes that defined the GREEN metrics to compose and aggregate the data collection to formed the reporting¶

The architecture could define a prefer interface, based in YANG as the preferred data model, but should allow enough freedom in the implementation, where any kind of quantity can be measured, any kind of collection protocol and mechanism employed, and the telemetry data flows aggregated using any kind of operation.¶

6.4. Control Energy Saving

Control will consider how to improve GREEN metrics with the final goal to automate the monitoring, performance and remediation in case of a fault or deviation of the performance defined for the metrics.¶