[Lsr] Re: [Green] Re: Adoption of draft-many-lsr-power-group

["[e-mail]" <[e-mail]>]

Hi Robert,

On 25/08/2026 00:06, Robert Raszuk wrote:
> 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 :(.
Some small corrections:
- The IPFIX WG started in 2001.
- RFC 3954, Cisco Systems NetFlow Services Export Version 9, was 
published in 2004 (it contains the initial list of IPFIX IEs)
- IPFIX IANA registry was created in June 2007
- RFC 5101/5102 IPFIX Proto and Information Models published in Jan 2008

I am not here to redo history. Personally, I was not aware of the BGP 
flowspec work around the IPFIX standardization process. Probably my 
fault, BUT I had wished someone with both views of mgmt & routing (the 
IESG?) had made the connections and the requirements to interoperate. 
And this is my high level message here.
>
> 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 believe the train left the station (at least for me). Feel free to 
pick up the fight.

Regards, Benoit
>
> > 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 [e-mail] 
> <[e-mail]> 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 -- [e-mail]
>     To unsubscribe send an email to [e-mail]
>