Hi Colby,

“Ok.. Note I would not do it that way, but I see what you mean. Changing
> paths of an RSVP-TE given LSP is really not a make-before-break operation.
> At least last time I checked into this space. “
>
>
>
> <cb> More often than not LSP path change is make-before-break.  And
> especially in this scenario, care can be taken to ensure MBB.
>

Yes if you signal new path and make it setup before the old path times out
- sure. Or are you saying some implementations can send for a given LSP
RSVP-Path messages over more then single path ? I have not see that.

More over new LSP is setup and policy switchover happens to put all
traffic which was traversing old LSP onto a new LSP.

In any case you would end up in some situations with two LSPs having
identical paths. Not sure what is the benefit of it.

> Consider a TE policy that aims to satisfy a BW demand(s) where the best
path is the fewest number of
> pwr-grps and the pwr-grp power value is a representation of power
efficiency for the group.

Well BW demands really work well when you have 100% of TE in the network
and all traffic can be accounted for.

- - -

In any case by putting to sleep some network elements, yes you are saving
some power, but you are at the same time making the network more fragile to
handle various failures.

I presume your operational consideration section will discuss the
consequences like triggering recomputation of all TI-LFA or MLA on each
power optimization in the network.

I view this power saving effort comparable to parallel moving pathways ..

* Your suggestion is to shut one pathway when there is no enough people
which would occupy all pathways

* The alternative which is seen and deployed in practice is to slow down
any pathway to 5-10% of the power until someone walks into it - then it
auto-resumes at full speed.

Needless to say I am in favor of building more intelligent forwarding
engines which could reduce their power consumption when load is reduced.

Regards,
R.

>
_______________________________________________
Lsr mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to