Hi Joel, > They continue to observe and react to the state.
Actually, reaction to the new state is what makes Ajiun's point actually stronger :) It seems however that to address his concern (in addition to what Tony already said) is to indicate that the sleeping capability constraints would have a bit higher significance in CSPF then currently available reservable bw. But here we are I think entering the area on how to efficiently implement CSFP which seems to be the crux of his concern and I am not sure how much IETF should be for defining it. Thx, R. On Tue, Sep 22, 2026 at 4:58 AM Joel Halpern <[email protected]> wrote: > Your question seems to assume that the two head ends ignore the changes in > the state of the network once they have made their decisions. That isn't > the way it works. They continue to observe and react to the state. > > Yours, > > Joel > On 9/21/2026 9:49 PM, Aijun Wang wrote: > > Hi, Tony: > > > > Let me state the logic more clear: > > > > 1) One headend(headend A) use the “most-fill” strategy to move the > traffic out of a set of links, let’s call it “Set A” > > 2) Another headend(headend B) use also its “most-fill” strategy to > move the traffic out of a set of links, let’s call it “Set B”. > > 3) According to the previous discussions, we can know there is no > theoretical guardedness that can assure the “Set A” is equal to “Set B” , > Right? > > > > If luckily, “Set A” is equal “Set B”, the set of these links are idle now, > how can you assure there will be no other headend(headend C) will allocate > its LSP on such sets of the links later? > > If you can’t assure, when will the nodes that connects these idle links > power off the these links then? > > If you can’t power off the links, even they are idle for a long time, > where is the cost saved? Where is the benefits of applying the distributed > power-save TE? > > > > > > Best Regards > > > > Aijun Wang > > China Telecom > > > > > > *From:* [email protected] [mailto:[email protected] > <[email protected]>] *On Behalf Of *Tony Li > *Sent:* Monday, September 21, 2026 2:13 PM > *To:* Aijun Wang <[email protected]> <[email protected]> > *Cc:* Vishnu Pavan Beeram <[email protected]> <[email protected]>; > Vishnu Pavan Beeram <[email protected]> > <[email protected]>; Adrian Farrel <[email protected]> > <[email protected]>; Barth, Colby > <[email protected]> > <[email protected]>; Robert Raszuk > <[email protected]> <[email protected]>; John Drake > <[email protected]> > <[email protected]>; John Drake <[email protected]> > <[email protected]>; WG TEAS <[email protected]> <[email protected]>; lsr > <[email protected]> <[email protected]> > *Subject:* Re: [Lsr] [Teas] Re: Re: Re: Re: Re: Re: Re: Re: [Green] > 【Distributed > Power-aware TE is Impossilbe】RE: RV: Call for adoption: > draft-many-teas-power-steering-01 (Ends 2026-09-10) > > > > > > Hi Aijun, > > > > Let’s give you one another example that demonstrates that *bandwidth > management* is different from the *power-aware TE*: > > > > > > Power-aware TE is part of bandwidth management. It is an optional portion > used to also save power under low bandwidth utilization. > > > > > > Image the hotel booking scenario, if you book one room(similar with > bandwidth usage is full), no other guest will book again. > > But if the room isn’t reserved (no traffic via it), the manager will not > take the room out of their website.------Because he can’t assure there > will be no other guest to book this vacant room in future. > > > > > > I’m sorry, I can’t parse this. > > > > > > Back to our scenario, if fortunately, the traffic on some links are > cleared, the nodes connecting these links shouldn’t still make these idle > links sleep, because these nodes don’t know the LSP requirements from > other headend. > > > > > > If a link is idle, then there are no LSPs assigned to that link. By > definition, for the link to be idle all LSPs must be assigned to other > acceptable paths. > > > > > > If the headend doesn’t know when to sleep the idle links, how to save > costs (“millions of dollar?”)? > > > > > > The headend is not responsible for sleeping idle links. It is only > responsible for placing LSPs on other links. The nodes that are the link > endpoints are responsible for putting the link to sleep. > > > > > > And, we should be aware, as the operator, to keep the service > uninterrupted is the first aim. > > > > > > That is very much the primary goal. > > > > Tony > > > > _______________________________________________ > Lsr mailing list -- [email protected] > To unsubscribe send an email to [email protected] > > _______________________________________________ > Teas mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
