Hi Benoit, > 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.
Well FlowSpec v1 work was done in 2007 and IPFIX IEs were published in 2013/2014. We did not have a crystal ball :(. But please note there is brand new work on FlowSpec v2 - a major new version of FlowSpec happening in IDR WG... I hope you can influence IDR WG to take on IPFIX IEs as match fields in FlowSpec v2. > 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. ISIS YANG is described in RFC9130. It does not mention "power" or "energy" words even once. IMO this draft describes a new ISIS adj type. Perhaps it could be renamed to avoid including word "power" in it to avoid overlap with https://datatracker.ietf.org/doc/draft-ietf-green-power-and-energy-yang/ Cheers, R. On Mon, Aug 24, 2026 at 10:54 PM [email protected] < [email protected]> wrote: > 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] >
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
