Hi Robert,
> > If you (and also other authors) can’t provide the detail algorithm to > > achieve the “network-wide bias” > > By the nature of TE all TE metrics are network-wide. > > And this entrie solution to the best of my understanding does not define any > algorithm extensions. The vanilla CSPF is proposed to be used in section 4 of > draft-many-teas-power-steering just with new constraint. More precisely, we have proposed a metric modifcation in PCPPS. > And yes as discussed already the solution could work equally well by > adjusting the value of already defined constraints. Yet authors decided that > defining a new one is a better choice hence they defined a set of new TLVs. Yes, that was an intentional design choice. You COULD ask operators to go around and manually modify metrics periodically. You COULD ask operators to compute how much power is consumed by the various parts of their hardware architectures and modify the metrics accordingly. We felt that this was inelegant and inappropriate. Our existing TE mechanisms have been designed around a very straightforward architecture: nodes advertise information about how they operate. This includes adjacencies, adminstrative groups, SRLG, metrics, etc. Headends learn this information and do their path computation. We have chosen a path of following the existing architecture rather than asking operators to kludge their operations. > It is also pretty obvious that if ingress nodes will not understand the new > extensions they will not act on it. Indeed. Nodes that do not support power groups will continue to advertise legacy information. Headends that do not understand the enhancements will compute legacy paths. Nothing changes. Cheers, Tony
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
