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? > > 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. > > 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: 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. > > 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. Tony
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
