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 [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]
