Aijun, The behavior you are questioning is already a standard outcome of distributed bandwidth-engineered networks when ingress nodes independently apply the same path-selection policy.
For example, Junos most-fill behavior is documented in the MPLS path-selection documentation [1]: “Prefer the path with the least available bandwidth (with the minimum available bandwidth ratio) when several equal-cost candidate paths to a destination exist.” The minimum available bandwidth ratio of a path is the smallest available bandwidth ratio among the links in that path. When each ingress node independently uses this same technique, network traffic gradually polarizes onto a preferred set of resources. This is not theoretical; it is exactly how distributed TE path placement works in practice today. There is nothing especially complex here: local path-selection bias, combined with independent path resizing, causes traffic to converge onto a preferred subset of resources over time. This does not mean that distributed TE is globally optimal in all cases, but it does show that meaningful, practical network-wide steering effects are already achieved without a centralized optimization loop. I think we have reached the point where the underlying question has been addressed repeatedly, and I will leave it there. Regards, -Pavan [1] https://www.juniper.net/documentation/us/en/software/junos/cli-reference/topics/ref/statement/label-switched-path-edit-protocols-mpls.html On Thu, Sep 17, 2026 at 12:11 AM Aijun Wang <[email protected]> wrote: > Hi, Vishnu: > > > > I reviewed the document( > https://www.juniper.net/documentation/us/en/software/junos/mpls/topics/topic-map/lsp-computation.html?utm_source=chatgpt.com#id-computing-cspf-paths-offline) > from Juniper, and it states clearly: > > > > The Junos OS provides online, real-time CSPF computation only;* each > router performs CSPF calculations independent of the other routers in the > network.* These calculations are based on currently available topology > information—information that is usually recent, but not completely > accurate. *LSP placements are locally optimized*, based on current > network status. > > *To optimize links globally across the network, you can use an offline > tool* to perform the CSPF calculations and determine the paths for the > LSPs. You can create such a tool yourself, or you can modify an existing > network design tool to perform these calculations. You should run the tool > periodically (daily or weekly) and *download the results into the router*. > An offline tool should take the following into account when performing the > optimized calculations: > > · *All the LSP’s requirements* > > · *All link attributes* > > · *Complete network topology* > > > > I would like to know where is the reference document for distributed > ”network-wide polarization”? > > > > As shown by the above text, to achieve the “network-wide polarization”, we > need “all the LSP’s requirements”, “all link attributes” and “complete > network topology”, how each headend can get the first of these three > information? (“all the LSP’s requirements”)? > > > > My suggestion for this document is, REMOVE the distributed power TE part, > it is not practical. > > > > Best Regards > > > > Aijun Wang > > China Telecom > > > > > > > > *From:* [email protected] [mailto:teas-bounces= > [email protected]] *On Behalf Of *Vishnu Pavan Beeram > *Sent:* Thursday, September 17, 2026 12:28 PM > *To:* Aijun Wang <[email protected]> > *Cc:* [email protected]; Barth, Colby <jonathan.barth= > [email protected]>; Robert Raszuk <[email protected]>; John Drake > <[email protected]>; John Drake <[email protected]>; > Tony Li <[email protected]>; WG TEAS <[email protected]>; lsr < > [email protected]> > *Subject:* [Teas] Re: [Lsr] 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) > > > > Aijun, > > I’m not sure I understand what you mean by “node-wide polarization.” > > In bandwidth-engineered networks where paths are automatically resized > independently at each ingress node based on the amount of traffic being > placed on them, traffic in the network can be made to gradually become > polarized onto a preferred set of network resources. This is not > theoretical; it is already a well-established operational pattern in > distributed bandwidth-engineered networks and is supported by most vendor > implementations that use most-fill path selection. > > I would encourage you to consult with operators who run such networks and > to review vendor documentation describing most-fill path selection, in > order to understand how distributed TE path placement becomes intentionally > biased toward a subset of links without requiring a global synchronized > optimization loop. In fact, this is already a common way in which > distributed TE achieves a meaningful network-wide steering effect (maybe it > is time we published a BCP). This is a broader topic, but it is worth > keeping in mind as we discuss the scope of the draft. > > The key point is that distributed TE already has mechanisms that can > produce a meaningful network-wide steering effect. It does so in practice > today, and the same principles can be built on and extended to power-aware > TE. > > Regards, > -Pavan > > > > On Wed, Sep 16, 2026 at 8:59 PM Aijun Wang <[email protected]> > wrote: > > Hi, Vishnu: > > > > Power-aware TE requires network-wide polarize, it is more strict than > “distributed > bandwidth-engineered networks”, which is node-wide polarize. > > > > Image one simple example: > > Let’s assume the each headend synchronizes their necessary information, > and the network utilization is almost same in two links. > > To *achieve **“network-wide” polarize effect*, we need to assure each > headend calculate its CSPF computation in sequence, or there will be no > deterministic results that they will select the same sleepable link. > > > > For some more complex network, it will be more challenge to achieve such > *“network-wide” > polarize effect”.* > > > > In order to close the argument, similar with the comments from Adrian, I > think the document should provide: > > 1) Either the limited scope of distributed power-aware TE can be > applied. > > 2) Or, detail algorithm that it can apply in most of the network real > network. > > > > Given the network has enough capacity to concentric traffic. > > > > > > Best Regards > > > > Aijun Wang > > China Telecom > > > > > > *From:* [email protected] [mailto:lsr-bounces= > [email protected]] *On Behalf Of *Vishnu Pavan Beeram > *Sent:* Thursday, September 17, 2026 6:54 AM > *To:* [email protected] > *Cc:* Barth, Colby <[email protected]>; Aijun Wang < > [email protected]>; Robert Raszuk <[email protected]>; John Drake > <[email protected]>; John Drake <[email protected]>; > Tony Li <[email protected]>; WG TEAS <[email protected]>; lsr < > [email protected]> > *Subject:* [Lsr] Re: [Teas] 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 Adrian, > > I just realized that this email had not yet received a response. Thank you > for your thoughtful comments. > > Regarding applicable topologies, I believe any topology in which > distributed TE, or distributed bandwidth engineering, is deployed today > could also be relevant for distributed power-aware TE. As you noted, > distributed TE may not achieve a globally optimal network-wide outcome. > However, this has not prevented operators from deploying it successfully > across a variety of topologies and operating conditions. Mechanisms such as > most-fill tie-breakers are widely used to polarize traffic in distributed > bandwidth-engineered networks. The same principle applies to power-aware TE. > > The draft also notes that PCPPS can be applied when CSPF is performed > centrally or in a distributed manner. Nothing in the draft precludes a > centralized computation function from using the PCPPS metric and associated > power-awareness information. > > More generally, power-aware TE is most likely to be effective in networks > with sufficient spare capacity and enough path diversity or mesh > connectivity to consolidate traffic without violating bandwidth, > redundancy, or other constraints. These conditions apply to both > centralized and distributed computation, although centralized computation > can typically achieve better consolidation more quickly. > > The intent of the draft is not to claim that distributed PCPPS provides > global optimization. Rather, it extends the CSPF model by adding power > awareness, allowing the computation function, whether centralized or > distributed, to bias path placement toward appropriate resources when > topology, traffic, and capacity permit. If consolidation cannot be achieved > without compromising capacity, redundancy, or other constraints, the > relevant resources should remain active. > > Best regards, > Pavan > > > > On Tue, Sep 8, 2026 at 3:49 PM Adrian Farrel <[email protected]> wrote: > > Hello all, > > > > Colby said “TE solutions aren’t required to be globally optimal to be > effective.” > > And he is right, and this is possibly one of the messages of RFC 9522. > > > > However, the perils of non-centralised systems are also well-known. As the > network resources get more contested (i.e., as the traffic load approaches > network capacity), distributed TE is increasingly likely to cause blocked > contention. And, of course, it is always possible to derive degenerate > examples where even simple networks and loads will fail in the distributed > case, but can be solved with a centralised view. None of this is new or > shocking. > > > > Practically, if the sizes of flows are small relative to the capacity of > links, distributed TE works well until the links are almost full. In fact, > when the sizes of the flows are quite a bit smaller than the unused link > bandwidths and/or when the network is very meshy, distributed TE will be > fine. > > > > Curiously, one of the early motivations for PCE was distributed > **re**-optimisation > which tended (in the way of all things) to converge on a synchronous moment > which increased the chances of contention. > > > > But, to cut back to this conversation, it may be helpful to describe the > types of network where distributed power-aware TE is > applicable/satisfactory and contrast with the types of network where > centralisation is to be preferred. > > > > Adrian > > > > *From:* Barth, Colby <[email protected]> > *Sent:* 08 September 2026 14:08 > *To:* Aijun Wang <[email protected]>; 'Robert Raszuk' < > [email protected]> > *Cc:* 'Vishnu Pavan Beeram' <[email protected]>; 'Barth, Colby' > <[email protected]>; 'John Drake' <je_drake= > [email protected]>; 'John Drake' <[email protected]>; 'Tony Li' > <[email protected]>; 'WG TEAS' <[email protected]>; 'lsr' <[email protected]> > *Subject:* [Teas] Re: [Lsr] 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, > > > > I’ll try to repeat what Robert said in a different way. TE solutions aren > ’t required to be globally optimal to be effective. > > > > Consider BW optimization as an example; there is no debate that a > centralized computation may result in a more optimal state (at least on > paper) than a fully distributed solution but a distributed solution still > produces better BW optimization than doing nothing at all. > > > > If you are arguing that path computation MUST be centralized, that is > incorrect. Evidence by the very, very big networks out there operating > successfully using distributed TE. > > > > -- Colby > > > > *From: *Aijun Wang <[email protected]> > *Date: *Monday, September 7, 2026 at 9:28 PM > *To: *'Robert Raszuk' <[email protected]> > *Cc: *'Vishnu Pavan Beeram' <[email protected]>; 'Barth, Colby' < > [email protected]>; 'John Drake' < > [email protected]>; 'John Drake' <[email protected]>; > 'Tony Li' <[email protected]>; 'WG TEAS' <[email protected]>; 'lsr' < > [email protected]> > *Subject: *[Teas] Re: [Lsr] 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, Robert: > > > > If the network are composed by some power aware links, and also some power > unaware links, the traffic may be converged into the power unaware links, > but such effects can be achieved only under some specific network topology. > > That is to say, such solution is not one generalize solution, and can’t > get the deterministic effect. > > > > And, if the network evolved to the state that links are all power aware, > it is impossible to find some special links, penalize them at the same time > by every headend, and then move the traffic out of these Oracle-selected > links. > > > > To Tony’s example of “Nash Equilibrium”, we should know “Nash Equilibrium” > is not equal “Global Optimum”(POA=1). > > > > If you want to prove you have the mechanism to overwritten the above > conclusion, please state clearly your mechanism, and then the necessary > extension of the IGP protocol. > > > > Until now, we can still make the following conclusions: > > 1) The proposal has no deterministic global effect, that can assure > the traffic being centralized successfully on some limited links, in any > arbitrary topology. > > 2) The proposal can only apply to the 100% TE controlled network, > which is rarely in real network. > > 3) There is no detail mechanism description in the current document, > or in other references documents that can achieve the power saving goal aim. > > > > > > Best Regards > > > > Aijun Wang > > China Telecom > > > > *From:* [email protected] [mailto:[email protected] > <[email protected]>] *On Behalf Of *Robert Raszuk > *Sent:* Monday, September 7, 2026 6:29 PM > *To:* Aijun Wang <[email protected]> > *Cc:* Vishnu Pavan Beeram <[email protected]>; Barth, Colby < > [email protected]>; John Drake < > [email protected]>; John Drake <[email protected]>; > Tony Li <[email protected]>; WG TEAS <[email protected]>; lsr < > [email protected]> > *Subject:* [Lsr] Re: [Teas] 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 Ajiun, > > > > Actually if you zoom into how CSPF really works what the draft assumes > (distributed TE computation) and shifting paths onto non power saving > designated links is very much possible. > > > > To understand it just forget about all of the power stuff. Imagine you are > running a vanilla TE with ISIS extensions as described in RFC5305 > > > > So here you already have number of ways to discourage CSPF on all headends > to keep using link which you would advertise using sub-TLV 18 (Traffic > Engineering Default Metric) and apply there for example MAX_PATH_METRIC. > > > > I see no reason why this would not result in all headends running their > independent CSFP to avoid such link. I also see no oscillation affecting > the subject link. Of course when more then one ingress node will start > compete for the TE bw of some non power aware link there could be > collisions - but those are normal in TE world and most robust TE > implementations know how to handle it. > > > > Cheers, > > R. > > > > > > > > > > > > > > > > > > > > On Mon, Sep 7, 2026 at 2:45 AM Aijun Wang <[email protected]> > wrote: > > Hi, Vishnu(and also Barth, Tony, or other experts who support such > proposal) > > > > We are arguing that, even in 100% TE environment, “Distributed > Power-aware TE” is impossible, if the headend routers don’t exchange > their path calculation results. > > > > Let’s make the analogy as “the WG document adoption call”-----each expert > make the judgement based on his/her own knowledge. Even we exchange > intensely our thoughts on the mail list, there are difficulties to make the > consensus---how can you expect each headend can coordinate with each other, > or, without coordinating with each other, to make the same decision, to put > out of their own traffic out of one specific link? > > > > Some detail replies for your arguments are inline below. > > > > > > Best Regards > > > > Aijun Wang > > China Telecom > > > > > > *From:* [email protected] [mailto:[email protected]] > *On Behalf Of *Vishnu Pavan Beeram > *Sent:* Saturday, September 5, 2026 4:48 AM > *To:* Robert Raszuk <[email protected]> > *Cc:* Barth, Colby <[email protected]>; John Drake > <[email protected]>; John Drake <[email protected]>; > Aijun Wang <[email protected]>; Tony Li <[email protected]>; > WG TEAS <[email protected]>; lsr <[email protected]> > *Subject:* [Lsr] Re: [Teas] 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) > > > > {as a WG participant} > > > > The key issue here is not whether global centralized coordination is > valuable — clearly it is — but whether it is the only viable way to > achieve meaningful network-wide efficiency. The argument in favor of > distributed TE is that it can still steer traffic in a globally useful > direction without the operational cost and complexity of a centralized > optimization loop. > > [WAJ] Each headend make the decisions themselves, How can you get the > “globally > useful direction”? please explain this conclusion in detail. > > > I doubt there would be any dispute with the argument that global > centralized coordination offers the best way to maximize network-wide > efficiency. However, it is not the only viable model, and it is not always > the operationally preferred one. > > In practice, many deployments already rely on the “most-fill” local path > selection tie-breaker to bias TE path computation toward a preferred subset > of links, and this knob is available across major vendor implementations. > When such a tie-breaker is incorporated into a network-wide distributed TE > profile, the resulting path placement, computed independently by different > ingress nodes, is not arbitrary; it becomes intentionally polarized onto a > narrower set of links. Over time, as tunnel bandwidth is resized and > re-optimized, this polarization naturally converges toward the most > efficient set of links, while leaving other links unused. > > [WAJ] “Such polarized effect” is your aim, but you don’t describe how to > achieve it. This is key argument points. Would you elaborate it in more > detail? > > The mechanism proposed in draft-many-teas-power-steering is conceptually > no different. By carrying power-group information in the TED, distributed > TE path computation gains the same kind of local biasing capability: > ingress nodes can optimally place paths by taking power-group information > into account, thereby consolidating traffic and increasing the number of > links that may be eligible for power-sleep. In other words, the goal is not > to compete with global coordination, but to make distributed TE path > placement more effective overall without requiring a controller-based > optimization loop for every case. > > [WAJ] If the aim can’t be achieved, we will not evaluate whether it is > efficient or not. > > > The key point is that path selection can be made “network-aware” — and > this is where the IGP extensions come into play — even without full > centralized coordination. The effect may be more gradual than a > controller-based optimization, but it is still a real and effective > mechanism for driving traffic onto a preferred subset of links and creating > power-sleep opportunities in a scalable manner. > > [WAJ] Path selection can be made “network-aware”, but can’t achieve the “ > network-wide” effect. Because each headend determine the “network-aware” path > itself. > > It will make the traffic oscillation, not concentrated. > > > > Regards, > > -Pavan > > > > On Fri, Sep 4, 2026 at 12:13 PM Robert Raszuk <[email protected]> wrote: > > Hi Colby, > > > > I am not sure John is suggesting GCO. I think he as few other folks on > this list are simply puzzled to how your proposal works in practice. > > > > I voice my questions few time - but did not get any clear answer. Namely > my doubt comes down to the below question (maybe John and few others are > also wondering about this too) > > > > Assume there is set of links and there are network resources which would > have sufficient capacity to carry traffic from those links. Of course > assume 100% TE. > > > > The question is how would you assume that few hundreds of headends will at > their time to reoptimize LSPs act in concert that the same set of links is > being dried out ? > > > > Well I have had a nice chat with Tony on the side and he revealed one > subtle but vastly important point. The capability that given link can be > put to sleep is not really a constant capability of that link. The same > applies to Power Group. So such "capability" is advertised when some oracle > thinks it makes sense. It is not described in ISIS draft like this. > > > > I guess all we are asking here is to learn if this advertisement (via IGP > flooding) at specific time intervals of the network is what makes the hope > that even 100s of headends will notice that and will start their own > attempt to shift the traffic on links not painted as sleep capable. It may > actually work at scale it is just that current version of the draft is not > make it clear. > > > > Cheers, > > R. > > > > > > > > > > > > > > > > > > > > > > > > > > On Fri, Sep 4, 2026 at 6:03 PM Barth, Colby <jonathan.barth= > [email protected]> wrote: > > Hi John, > > > > I assume you’re making the case for Global Concurrent Optimization (once > again)? Sure, that would provide better results than distributed TE. This > is not a new argument, we already discussed it in this thread (and for many > years, for that matter). As we’ve stated many times already, if you want > a “Controller” to consume the power-group info (and all the associated > per interface, per tunnel, power telemetry streaming) and perform GCO, this > solution does not prohibit you. > > > > However, not all operators leverage a central Controller and GCO comes > with its own ‘costs’ (also already highlighted in this thread by Tony) > nor should we require it. Therefore, this proposal caters to both > centralize and distributed TE to facilitate power savings. > > > > It would be nice if we could just discuss the specific IS-IS extensions we > proposed and not continue this circular argument. > > > > Thanks, > > > > -- Colby > > > > *From: *John Drake <[email protected]> > *Date: *Friday, September 4, 2026 at 8:29 AM > *To: *Barth, Colby <[email protected]> > *Cc: *John Drake <[email protected]>; Aijun Wang < > [email protected]>; Tony Li <[email protected]>; WG TEAS < > [email protected]>; lsr <[email protected]> > *Subject: *Re: [Lsr] Re: [Teas] Re: Re: [Green] 【Distributed Power-aware > TE is Impossilbe】RE: RV: Call for adoption: > draft-many-teas-power-steering-01 (Ends 2026-09-10) > > Colby, > > > > Your statement is incorrect. > > > > Because your proposal is distributed, there is always the possibility that > links that should have been put to sleep are not, because the > re-distribution of LSPs in order to put links to sleep is not co-ordinated > in order to provide global co-ordination of that re-distribution. > > > > John > > > > Sent from my iPhone > > > > On Sep 4, 2026, at 11:07 AM, Barth, Colby <jonathan.barth= > [email protected]> wrote: > > > > John, > > > > It only results in no links being put to sleep IF there are insufficient > resources to consolidate traffic. That’s a feature, not a limitation. > > > > -- Colby > > > > *From: *John Drake <[email protected]> > *Date: *Friday, September 4, 2026 at 7:14 AM > *To: *Barth, Colby <[email protected]> > *Cc: *Aijun Wang <[email protected]>; Tony Li < > [email protected]>; WG TEAS <[email protected]>; lsr <[email protected]> > *Subject: *Re: [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) > > 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 <jonathan.barth= > [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] > <[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] > > _______________________________________________ > 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] > > _______________________________________________ > 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]
