Stewart,I understand your concern. However, as I see it, the alternatives to local protection of a failed pinned node of a SR-TE LSP are somewhat limited: 1. You can wait (with no traffic) until failure of the pinned node is recognized (e.g., fillowing IGP cobversion) and a new policy(that does not inckude the failed node) is recomputed and installed. 2. You can pre-compute and pre-install a backup policy that does not have any common pinned nodes with the original ones and, once the origibal policy fails, switch ti the backup one end-to-end. My 2c.
Sent from Yahoo Mail on Android On Tue, Nov 28, 2017 at 9:15, Stewart Bryant<[email protected]> wrote: On 28/11/2017 12:04, Ahmed Bashandy (bashandy) wrote: > > - The top label of incoming packet to node "S" is either a prefix SID > owned by node "F" or an adjacency SID for (S,F) If it is an adjacency SID for (S,F) then you are violating the original intent of the ingress PE which was to send the packet along the path S->F. I really don't think you can blindly repair such a packet since to do so violates the policy applied to the packet. You have to do a policy check, and you have to make sure that the packet is not subject to ECMP along the repair path since ECMP avoidance might have been the intent of using the SR Adjacency in the first place. - Stewart _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
