Peter, The whole argument with post-convergence path is that the post-convergence path is expected to have Sufficient capacity. I agree that backup paths may differ from actual post-convergence path for TI-LFA when SRLG is used for computation. My point is that an operator is expected to take care of this difference and ensure sufficient capacity is planned when there is single failure or multiple failures due to SRLG failure.
Rgds Shraddha Juniper Business Use Only -----Original Message----- From: Peter Psenak <[email protected]> Sent: Tuesday, July 27, 2021 1:57 AM To: Shraddha Hegde <[email protected]>; [email protected] Subject: Re: [spring] draft-hu-spring-segment-routing-proxy-forwarding-14: Post convergence path [External Email. Be cautious of content] Hi Shraddha, On 26/07/2021 22:16, Shraddha Hegde wrote: > WG, > > Regarding Peter’s comment on the mic that TI-LFA can divert from post > convergence path when SRLG is used for computation I would like to > clarify > that an operator is expected to do planning for the post > convergence path accounting for the SRLG failures. TI-LFA does not always guarantee that backup path follows the post-convergence path. It depends on what is the type of the backup computed and what is the actual failure. When the two do not match, we can not guarantee the backup path being equal to post convergence one. An example is when you are calculating a node protecting backup, but the actual failure is a link failure, your backup path may not be the same as the post convergence one. thanks, Peter > > draft-hu-spring-segment-routing-proxy-forwarding-14 is proposing a > mechanism which will > > divert the traffic based on nodes being upgraded to support the > protection. The paths > > could be quite divergent from post-convergence path and an operator > would be expected > > to do planning to ensure these paths have sufficient bandwidth to take > on traffic. > > Rgds > > Shraddha > > > Juniper Business Use Only > _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
