Hi,
Comments inline.
Thanks,
John
On Tuesday, September 22, 2026 at 09:08:11 AM PDT, Tony Li
<[email protected]> wrote:
Hi John,
> JD: Let me try again. As I understand the problem at hand, a service
>provider has a [source, destination] traffic matrix that varies over time and
>it > would like to re-provision its network accordingly by adjusting
>which links are powered-up as a function of time. In order to accommodate>
> unexpected traffic they provide whatever over-provisioning with which
>they are comfortable.
That’s not re-provisioning. It’s simply taking links out of service and
powering them down. Provisioning is a modification to an operators master
database of the network topology and does not reflect the real-time status of
the network.
>> JD: "W">
Typically redundancy is provisioned starting at network design time. To
preserve this in a reduced topology, we ask that operators not configure their
minimally redundant topology as power-save capable. Since this subset of the
topology cannot be powered down, the network should always have connectivity
and a means of recovery. Further, if the operator has a complex redundancy
policy (e.g., they prefer to be tri-connected), this is still supported.
Periodic reoptimization then pushes traffic away from power-save-capable
components, allowing them to be powered off.
>>: JD: Thanks, this is great>
Correct, and now we are adding power considerations to the optimization.
> JD: I'm not so sure that this is a good idea. The teas draft indicates
>that the power management component can power-up any link in the network in >
> response to any individual path computation. (How it does this is
>undefined.) I think this is a really bad idea.
Since you cannot articulate your rationale, we will give your opinion all of
the consideration it deserves.
>> JD: Very gracious. I assume the 'we' is imperial?>
> 3) As has already been established, ' optimization' when used in the
>context of any distributed solution is a stretch. The technical term is>
> "re-run the experiment and hope for a better result" where 'better' is
>ill-defined
Optimization is any process that causes the overall objective function to
follow the gradient towards a higher value. “Better” is quite well defined.
For a pure TE solution, all LSPs must meet constraints and minimize their
metric. For a TE solution that considers power, LSPs minimize their PCPPS.
> JD: From wikipedia: "Optimization is the process of finding the best
>possible solution or outcome from a set of available alternatives, usually by
>> maximizing or minimizing a specific metric. [1, 2]"
Your choice of dictionary is lacking. Mirriam-Webster defines optimization as
"an act, process, or methodology of making something (such as a design, system,
or decision) as fully perfect, functional, or effective as possible”.
>>: JD: I'm sure it's me, but I didn't see any difference.>
Please note that we long ago stipulated that we are not attempting to provide
the globally optimal solution. That’s much more computationally complex and
very fleeting given the dynamic nature of the demand matrix.
>> JD: 'fleeting' seems a bit of a stretch>
> I'm not sure that there is universal agreement that your definition
>of 'better' is correct.
That is the definition that TEAS has been using for 30 years, with repeated
enhancements to give operators flexibility to utilize a variety of metrics.
>> JD: Debatable. Maybe better if you replace 'TEAS' with 'Juniper'>
> JD: There are a lot of claims about what the current solution is or is not
>doing but I personally find these claims to be a moving target and have yet >
>to see them enumerated anywhere
The parts that are relevant to standardization are in the PCPPS draft.
.>> JD: Debatable>
> JD: A non-exhaustive list of items which could usefully be included in the
>current proposal is the following:> > Non-TE traffic
This does not require standardization. No new mechanisms are introduced.
>> JD: Power management is new, when messages are sent is new>
> Preemption
This does not require standardization. No new mechanisms are introduced.
>> JD: See above>
> Link re-powering up
This will be covered in a subsequent draft.
>> JD: Excellent>
> Power management information advertisement
This is covered in the LSR draft.
>> JD: Where?>
> Receipt of an LSP activation request for a link which is powered-off
This duplicates the item above.
>> JD: It's not. IGP advertisement versus LSP processing>
> Incremental deployment, in which not all nodes support the current
>proposal
This is already covered in the existing drafts.
>> JD: Where?>
> For each item there should be a description of what messages are sent
>for a given set of conditions
The existing drafts already explain their utilization.
>> JD: Where?>
Regards,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]
