Hi, comments inline.
On Friday, September 18, 2026 at 07:59:46 AM PDT, Tony Li <[email protected]>
wrote:
Hi Aijun,
Then, from the operator’s side, why will they deploy such non-deterministic
(network-wide polarization) solution in their network?
It can save them millions of dollars.
>> As you wrote in a recent email, it's a feature of the current bandwidth
>>management proposal that it is not guaranteed to provide any power>
>>management savings, so it won't necessarily save them any money but it will
>>cost them the expense of installing it.>
It should also be noted that basic distributed bandwidth-engineering is already
non-deterministic: path selection is a function of previous path placements.
Since bandwidth management is a vital benefit for operators, they are very
happy to make use of it and have been doing so for 30 years.
>> This is completely irrelevant to the discussion of the current proposal.>
Perhaps the key insight here is that systems need not be deterministic to be
useful.
>> ", if they solve the problem at hand." This is not a key insight of the
>>current proposal. It's been known ... like forever.>
And we should aware that “put the interface into sleep state” is more strict
requirement than the “bandwidth adjustment”: You should make sure all the
services from each headend are not passing the sleeping links, and WILL NOT the
passing the sleeping links, or else there will be service disrupt during the
sleeping procedures.
Sorry, I cannot parse this. Again, we do not seek an absolute solution that
forces all traffic away from power-save capable links unconditionally. That’s
not the point. We seek to consolidate traffic within TE constraints, and then
if components are vacated, place them in power-sleep.
>> You are fashioning the requirements from the characteristics of the current
>>proposal.>
Without coordination of the LSPs requirements on each headend, when will you
end the “network-wide polarization” process and begin the sleeping management
procedures, which is the integral part of the overall proposal, but the authors
avoid touching it?
LSP optimization is an ongoing periodic process. It does not end. Sleep
management is an ongoing periodic process. It does begin or end. Ron has
already described sleep management.
>> Since traffic patterns vary on a reasonably fixed schedule, why is the
>>above behavior, even if it works (which is only guaranteed by emphatic >
>>assertion), particularly useful?>> There are defined mechanisms for
>>steering traffic away from links that are to be taken out of service. Viz,
>>RFC 8379 for non-TE traffic in OSPF> networks (and presumably its IS-IS
>>equivalent), and RFC 5817 for TE traffic. The problem with the current
>>proposal is that there is no way to use > these mechanisms to allow a
>>service provider to dynamically alter the topology of its network in response
>>to changes in traffic patterns.>
Regards,Tony
_______________________________________________
Teas 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]
