Hi Robert,
> But it seems clear that those who subscribe to full TE in their network are > not that big enemies of controllers too. Some are, some aren’t. Practical engineering suggests that a network operator should choose the architecture that best fits their needs. This may or may not coincide with their vendor’s marketing. > Having a fully distributed solution is always cool, but as we discussed > offline I do have lots of hesitation that specific links or line cards could > be drained bidirectionally in a distributed CSPF computation fashion. Clearly > you have spent loads of time more than me making sure it does work so I am > not questioning that. Just expressing my hesitation. Let’s see if we can address it. Let’s imagine a network where we have three paths from point A to B. Let’s arbitrarily call them North, South, and Central. Suppose that initially traffic is evenly divided amongst them. Let’s further imagine that all head-ends understand that the goal is to consolidate traffic. Suppose that we have many different LSPs and many different head-ends doing the path computation. Further, suppose that traffic levels have dropped enough that traffic can be consolidated. Pick any head-end. It goes to optimize an LSP. What does it do? It wants to consolidate traffic. If the paths are not equivalent, then it’s obvious that it should consolidate on the least cost path. If the paths are equivalent, then it can arbitrarily pick one. Let’s say that it moves traffic from Central to North. Now, some other head-end goes to optimize a different LSP and it sees that the North path has more traffic. It then shifts its traffic to the North as well, again trying to consolidate. This continues until the path is full. Presumably the remaining traffic further consolidates and the one of the two paths can be put into power sleep. The only time that this could possibly be an issue is if two systems made simultaneous opposite and offsetting decisions, and there are no other changes going on, and they continue to remain in lock-step. Given the thousands of different LSPs in a common network, this seems exceedingly unlikely. Right up there with all of the oxygen in the room collecting in the upper northwest corner. > But my overall comment was not aimed there .. It was attempting to hint that > perhaps there are other alternatives to full mesh RSVP-TE to accomplish > traffic shifts such that nodes could start powering off single lasers or > NPUs. There’s almost always multiple ways to skin a cat. We are simply starting from where most of our customers already are. > And that real question I am asking is if we should have separate draft and > separate extensions or could that be part of the same architecture to > accommodate different alternatives of load draining from the links . If someone has a clear use case, and can articulate the mechanisms that they need, I have no objections. We are not trying to preclude people from solving their problems. Tony
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
