Hi Colby, Ok so *all* headends need to be smart and apply rule of traffic aggregation > (180 degrees to one of traditional uses of TE which is traffic > spreading over available topology). > > <cb> An operator has the choice to deploy such a solution if power savings > is important to them. >
So let's zoom on this for a second ... How would an operator enable this ? Clearly all headends in the network (at those which are used for SLA sensitive traffic) need to be upgraded and enabled. But how do you enable this ? Are you saying that now traffic spread by TE across links is no longer important and power savings becomes prime citizen ? Or are you saying that this optimization would be enabled between 1:00 AM and 6:00 AM ? Well for Tier-1 or even some Tier-2 backbones there is never night everywhere. In fact there always daylight in some part of the world. So here we are now talking about properly designed networks with areas/levels corresponding to traffic patterns. <cb> The draft defines a power-save capability for a link, section 7.3.4. > Resilient topologies can be designed or calculated (periodically, on > demand, …) such that resilience is not compromised. Links just need to be > marked as not-available-for-power-sleep. > The point I am highlighting is that FRR protection is fully distributed in the network and is beyond control of the headend. PLRs can not guess which links will be shut in the future unless you mark all as "not-available-for-power-sleep". To come back to Tony's example if North link is marked as "not-available-for-power-sleep" and we put to sleep Central and South some PLRs may no longer have a repair path available. Moreover that knowledge is not readily available on each headend as they can not predict the future how other headends will behavie in time T+N. <cb> FRR tunnels can be moved apriori or after-the-fact but either way, > there would be a resilient topo available for FRR tunnel placement. > Very topology dependent assumption and clearly and significantly reducing the space for savings. Thx, Robert
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
