Drafts allow a B-Flag to be attached to the Adj-SID, which says that the adjacency is “eligible for protection”. Such an adjacency may perhaps also be interpreted as ineligible for SR policies that are particular that only the selected adjacency must be used to reach the protected node. This prevents packets from going down the (TI-LFA) repair path, but of course does not offer a solution with regard to mapping Adj-SID/BSID to a non-TI-LFA backup. Perhaps more flags and signaling would be needed for the latter.
Thx Sikhi From: rtgwg [mailto:[email protected]] On Behalf Of Stewart Bryant Sent: 29 November 2017 01:36 To: [email protected]; Ahmed Bashandy (bashandy) <[email protected]>; Muthu Arul Mozhi Perumal <[email protected]>; [email protected] Cc: [email protected] Subject: Re: Protecting SR policy midpoints (draft-bashandy-rtgwg-segment-routing-ti-lfa) 2. looks to be similar to 1+1 backup from the headend, which would be the normal default, but you have to prevent the packet going down the repair. What would be nice would be to install a tailored backup hence: 3. Install a purpose built backup and somehow map to it on failure. Both of these are analogous to the RSVP solutions. Maybe to do 3 you use an SPL followed by a policy identifier so that the FRR node knows to abandon the repair or to pick a particular path such as a particular binding SID. - Stewart On 28/11/2017 16:12, Alexander Vainshtein wrote: 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<https://overview.mail.yahoo.com/mobile/?.src=Android> On Tue, Nov 28, 2017 at 9:15, Stewart Bryant <[email protected]><mailto:[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]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/rtgwg
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
