Hi Tony,
Thanks for engaging.
See inline.
On 24/08/2026 22:00, Tony Li wrote:
Hi Benoit,
How does the Power Group Identifier ("which has node-local
significance") refers to a specific Power State in
https://datatracker.ietf.org/doc/draft-ietf-green-power-and-energy-yang/,
basically on/off/sleep (see YANG identities power-state-on,
power-state-off, and power-state-sleep)?
The power state is is not reflected in the Power Group Identifier
(PGI). The PGI is just associated with a power group, which is an
abstraction of some pieces of hardware in the hierarchy. The physical
interfaces are the leaves in this hierarchy and the power state for
the interfaces is reflected in the IS-IS adjacencies. Interfaces that
have an adjacency are (obviously) in power-state-on. Interfaces with
a sleeping adjacency are in power-state-sleep.
There is no tracking of interfaces in power-state-off, nor of
interfaces that are power-state-on but have not formed an adjacency.
There is no tracking of power state of higher levels of hardware.
Presumably when all relevant interfaces are sleeping, the platform
can put higher level hardware to sleep. Once again, we are not trying
to perform management plane functions, only control plane traffic
engineering.
You know, this is exactly my point. And I have seen this pattern in the
past. "It's just routing, not mgmt, so we don't care"
Think of BGP flowspec and IPFIX. Looking at the fields at
https://www.rfc-editor.org/info/rfc5575/#section-4, this is such a
missed opportunity not to have reused the IPFIX IEs.
Operators don't manage the control plane or the management plane (or the
data plance) independently..
They look at all planes (mgmt, control, data) for troubleshooting,
anomaly detection, and assurance. See the NMOP "sharing your incidents"
sessions.
And yes, we could map, as an example, a BGP Flowspect Type 1 -
Destination Prefix
<https://www.rfc-editor.org/info/rfc8955/#name-type-1-destination-prefix> to
destinationIPv4Prefix ... oh wait, maybe this is destinationIPv6Prefix?
Explained differntly, here is the issue we face in operations: "Network
Automation: the costly Data Models Integration and Mediation
<https://www.claise.be/network-automation-and-the-costly-data-model-integration-mediation/>"
I really would like to understand (see described somewhere) how an
operator would use the LSR power groups, optimize routing, and use the
YANG module power state at the same time. To me, this would be a
prerequisite before adopting.
Btw, a specific operator told me: config management is so complex, with
many frozen windows, that I will not allow energy-related configuration
independently.
Regards, Benoit
Cheers,
Tony
_______________________________________________
Lsr mailing list -- [email protected]
To unsubscribe send an email to [email protected]
