Hi Tony,

1. Do we really see that carrying power consumption for the power groups is
something that belongs in link state protocol and flooded to all nodes vs
something that should be done with streaming telemetry to power optimizing
controller ?

2. Why does the subject draft consider only RSVP-TE when reporting
"Sleeping Bandwidth" ? Besides wouldn't allocated by RSVP-TE link bandwidth
simply time out after 15 sec when refresh is not seen on the "sleeping
link" ?

3. To accomplish your overall objective I see authors lean towards path
computation as the only way. How about a completely different approach
based on demand vs capacity (possibly with queuing)  monitoring and
graceful link, line card draining and natural link/line card bypass via SPF
without any necessity of CSPF ?

Thx,
R.


On Sat, Aug 2, 2025 at 12:57 AM Tony Li <[email protected]> wrote:

>
> Hi Acee,
>
> The Green WG does not have path computation as one of their use cases.
> They are focused on YANG modeling for a variety of other purposes.
>
> Tony
>
>
> > On Aug 1, 2025, at 3:11 PM, Acee Lindem - acee.ietf at gmail.com <
> [email protected]> wrote:
> >
> > All,
> >
> > It would be better if we got our use cases from the Green WG and the
> attendant metrics were derived from these use cases.
> >
> > I don't think we want a variety of point solutions - at least, we don't
> want to start from there.
> >
> > Thanks,
> > Acee
> >
> >> On Aug 1, 2025, at 3:53 PM, Tony Li <[email protected]> wrote:
> >>
> >>
> >> Hi Raul,
> >>
> >>> Yes, sorry, I had in mind the reverse approximation to the problem.
> Indicating current power, power-save capability and current power-save
> status (including interfaces) the resulting power-group hierarchy has
> enough information and you don’t need calculations for the sleeping bw but
> maybe I’m missing something obvious.
> >>
> >>
> >> Please note that we are NOT trying to do full modeling in the IGP.
> That’s over in the GREEN WG.  Our goal is simpler: path computation.
> >>
> >> T
> >>
> >>
> >> _______________________________________________
> >> 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]
>
_______________________________________________
Lsr mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to