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> 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
>