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. 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. > 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. >> > 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 > > <https://en.wikipedia.org/wiki/Mathematical_optimization>, 2 > > <https://www.britannica.com/science/optimization>]" 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”. 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. > > 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: 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: 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. > > Preemption This does not require standardization. No new mechanisms are introduced. > > Link re-powering up This will be covered in a subsequent draft. > > Power management information advertisement This is covered in the LSR draft. > > Receipt of an LSP activation request for a link which is powered-off > > This duplicates the item above. > > Incremental deployment, in which not all nodes support the current > > proposal This is already covered in the existing drafts. > > 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. Regards, Tony
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
