Hi, Comment inline.
Sent from my iPhone > On Sep 4, 2026, at 10:23 AM, John Drake <[email protected]> wrote: > > Tony, > > Lower traffic levels than that for which a given network is provisioned is > the only reason we are considering this topic. However, this proposal does > not deterministically put to sleep all of the links that could be put be > sleep. JD: I think it’s fair to make the above statement about any distributed proposal. > > John > > Sent from my iPhone > >>> On Sep 4, 2026, at 10:14 AM, Tony Li <[email protected]> wrote: >>> >> >> >> John, >> >> If traffic levels are high, then yes, no links may be put to sleep. Our >> proposal does NOT claim that links will always be put to sleep. Traffic >> levels must be low enough and traffic must be able to be consolidated. >> >> Tony >> >> >>> On Sep 4, 2026, at 7:10 AM, John Drake <[email protected]> wrote: >>> >>> Colby, >>> >>> Path placement in this proposal is indeed deterministic. However, its >>> effects are not; i.e., even though it may be possible to put some links >>> to sleep, this proposal will not do that deterministically. In >>> particular, this proposal may not put any links to sleep. >>> >>> I don’t think that’s acceptable. >>> >>> John >>> Sent from my iPhone >>> >>>>> On Sep 4, 2026, at 9:47 AM, Barth, Colby >>>>> <[email protected]> wrote: >>>>> >>>> >>>> Aijin, >>>> >>>> Distributed TE path placement is deterministic. Tony’s example is about >>>> placing TE tunnels on paths with sufficient resources. >>>> >>>> You are criticizing many other solutions with your example. The PCE >>>> architecture follows the same model. >>>> >>>> -- Colby >>>> >>>> From: Aijun Wang <[email protected]> >>>> Date: Thursday, September 3, 2026 at 6:23 PM >>>> To: 'Tony Li' <[email protected]> >>>> Cc: 'TEAS WG' <[email protected]>; 'lsr' <[email protected]> >>>> Subject: [Teas] Re: [Lsr] Re: [Green] 【Distributed Power-aware TE is >>>> Impossilbe】RE: RV: Call for adoption: draft-many-teas-power-steering-01 >>>> (Ends 2026-09-10) >>>> >>>> Hi, Tony: >>>> >>>> Then, there will be no deterministic effect for the distributed >>>> power-aware TE, Right? >>>> Why the operator will deploy such proposal that has the unknown >>>> probability of success? >>>> >>>> And, for the power group related information, since they are static, and >>>> will almost never to be changed, even the controller based approaches need >>>> them, it is not the IGP's role to flooding them. >>>> >>>> Let's image the possible scenario: >>>> NMS configure the power group information on each device---->IGP flood >>>> such information among all the nodes---->BGP-LS collect such information >>>> to the Controller >>>> Why don’t we let the NMS synchronize such information to the Controller? >>>> In most of the real deployment, NMS is almost the same, or collocate with >>>> SDN controller. >>>> >>>> So, what's the usage of the distributed power-aware TE proposal? >>>> >>>> Best Regards >>>> >>>> Aijun Wang >>>> China Telecom >>>> >>>> -----Original Message----- >>>> From: [email protected] [mailto:[email protected]] >>>> On Behalf Of Tony Li >>>> Sent: Friday, September 4, 2026 3:18 AM >>>> To: Aijun Wang <[email protected]> >>>> Cc: TEAS WG <[email protected]>; lsr <[email protected]> >>>> Subject: [Lsr] Re: [Teas] [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 trim the discussions within TEAS only. >>>> >>>> >>>> No, let’s not. >>>> >>>> >>>> > "the relevant nodes can then detect that the link is idle and can put it >>>> > into power-sleep." via the "reserved bandwidth"? >>>> > Then the proposal depends solely on RSVP style TE. >>>> >>>> >>>> No. Other proposals are free to use the information as well. If you have >>>> a controller-based approach and want PSP information on the network, >>>> here’s one way. >>>> >>>> >>>> > Even so, how you assure all the ingress node will select to avoid the >>>> > same link along the e2e path that is determined by its own? Only behave >>>> > in such manner, can you move out of the traffic from one link step by >>>> > step. >>>> >>>> >>>> There is no guarantee that all headends will be able to consolidate >>>> traffic. If the traffic levels are sufficiently low and the relevant >>>> headends compute paths that do consolidate traffic, then links can >>>> transition to power-sleep. If traffic levels are not sufficiently low and >>>> one headend cannot find a path that avoids the link, well, the the link >>>> cannot be put into power sleep. This is not a bug, this is a feature. >>>> >>>> >>>> > Changing the link metric can get the effect of " in the middle of a >>>> > flock of birds and clap your hands, they will fly away ". >>>> > But for the distributed TE proposal, the effect will be the birds fly >>>> > from east to west, and then from north to south, or, fly around within >>>> > the forest, because every edge router direct them to avoid some >>>> > different tree. >>>> >>>> >>>> We are not changing the link metric. We are adding a penalty to the path >>>> for the link in question. There may be many links on a path that are >>>> capable of power-sleep, so there may be many penalties. Those penalties >>>> do not have to be the same from LSP to LSP, nor from head-end to head-end, >>>> nor from link to link to have an effect on path computation. As long as >>>> each headend finds a path with sufficient capacity, then the network is in >>>> an acceptable state. >>>> >>>> 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] >>>> _______________________________________________ >>>> 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]
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
