Hi,
Comments inline.
John
On Monday, September 21, 2026 at 04:28:39 PM PDT, Tony Li <[email protected]>
wrote:
Hi John,
Comments inline. I didn't see any responses to my first few comments, so
presumably you agreed with them?
No, they just didn’t seem like they needed a reply.
Because traffic patterns are not absolute. They are a prediction, but Murphy
never cooperates and things sometimes vary from the expected prediction.
Periodic optimization allows us to deal with reality.
>> A couple of points:> > 1) Service Providers always allow for this when
>>they provision OR re-provision their networks, so I don't understand your
>>point
No, they don’t have that granularity of control. They provision what bandwidth
is affordable and available and then use TE to drive the demand matrix onto the
topology. As demand fluctuates, LSP optimization adapts. You know this quite
well, why are you arguing?
>> 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.>
> 2) The re-optimization to which you refer would occur would be performed
>regardless of the network topology
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.
> 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]">> I'm
>>not sure that there is universal agreement that your definition of 'better'
>>is correct.>
> 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
We are not enumerating things that do not need to be standardizes as they are
local operations.
>> JD: A non-exhaustive list of items which could usefully be included in the
>>current proposal is the following:> > Non-TE traffic>
>>Preemption> Link re-powering up> Power management information
>>advertisement> Receipt of an LSP activation request for a link which
>>is powered-off > Incremental deployment, in which not all nodes
>>support the current proposal> > For each item there should be a
>>description of what messages are sent for a given set of conditions>
> This includes the basics such as whether non-TE traffic is supported
As we’ve discussed non-TE traffic can be redirected using the max-metric or
similar tools.
> I guess I'm old fashioned but I would prefer a Theory of Operations which
>explains how the current proposal is supposed to work, rather than trying >
>to infer this from a couple of puzzle pieces. Particularly since absent a
>Theory of Operations it is difficult to decide whether these couple of puzzle
>> pieces are needed or even correct
We are precluded from that as then we would be standardizing local
implementation choices. We have explained the functionality repeatedly. The
professed incomprehension of these explanations would extend to any
architecture document as well.
>> JD: The list I provided above does not require a discussion of
>>implementation choices.>
Tony
_______________________________________________
Lsr mailing list -- [email protected]
To unsubscribe send an email to [email protected]
