Hi Tony, *Comment 1: *
> More precisely, we have proposed a metric modifcation in PCPPS. Ok indeed I see TEAS draft added bunch of new text about it between versions -01 & -02. I was not following up the versions. LSR draft does not mention "metric" even once. What I am quite unclear from both drafts is the relation of the PCPPS metric to normal TE metric, link attributes or bunch of other constrains used today for TE purposes ? For example those defined in RFC7810 ? Are you saying all of those do not matter any more and first link pruning should be done based on PCPPS metric $$$ saving is more important ? Or should CSPF run normally and only when there are multiple paths meeting application constrains prune those with higher PCPPS metric ? *Comment 2: * Now after thinking more about this while it looks cool on paper I am not sure if we should expose concept of Power Groups. What's wrong with staying on a per link granularity ? It may add lot's of confusion among implementations for unclear benefit. Internally within the box sure one could still support such grouping directly or indirectly in a form of interface templates. *Comment 3: * Did anyone analyze the impact of this to the transmission layer ? When light goes down on the laser the circuit alarm is raised. If we start doing random shuts of interfaces the poor transmissions guys will go crazy in their NOCs. And last time I checked the API there is email and phone. And if they start ignoring those alarms they may miss some important ones .. for example ATC fiber cuts. Cheers, Robert On Thu, Sep 24, 2026 at 5:27 PM Tony Li <[email protected]> wrote: > 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]
