RE: Protecting SR policy midpoints (draft-bashandy-rtgwg-segment-routing-ti-lfa)

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:rtgwg-bounces@ietf.org] On Behalf Of Stewart Bryant
Sent: 29 November 2017 01:36
To: sasha@axerra.com; Ahmed Bashandy (bashandy) <bashandy@cisco.com>; Muthu Arul Mozhi Perumal <muthu.arul@gmail.com>; vinesasha@yahoo.com
Cc: rtgwg@ietf.org
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
<stewart.bryant@gmail.com><mailto:stewart.bryant@gmail.com> 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
rtgwg@ietf.org<mailto:rtgwg@ietf.org>
https://www.ietf.org/mailman/listinfo/rtgwg