Hi Acee,
On 9/29/15, 5:17 PM, "Acee Lindem (acee)" <[email protected]> wrote: >You still didn’t answer my question. Why would the action for TE LSPs not >always be to divert the traffic when the TE metric on one of the component >links is 0xfffffffe. You still have not convinced me that the additional >link attribute provides any value add beyond setting the metric to 0xffff >and TE Metric to 0xfffffffe. [Pushpasis] Couple of reasons why I feel Link overload is better. 1. Logically I feel flag is better than a meaning associated with a special value of a attribute which does not indicate the same exact condition. 2. There is already a 'node-overload' mechanism for taking out a router for maintenance. And so using a ‘link-overhead’ seemed more logical approach. 3. Finally, a metric is applicable in one direction only. This means, while taking out a link for maintenance the operator needs to manually set the metric (with special value) on both sides of the link. However with this proposal operator needs to set the overload on one side of the link and the other-side of the link will automatically put the link on overload and that will take both-side transient traffic off the link. 4. Additionally, the overload attribute can help the controller distinguish between a link that has been intentionally taken out of service versus a link that whose metric has degraded due to other reasons (e.g. a link may metric may dynamically degraded due to some change in S/N ratio etc). Thanks -Pushpasis > _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
