Stewart,Lots of thanks for a prompt response.From my POV "normal" FRR (based on LFA or RLFA) can be employed safely to protect against the"middle of a segment" link and/or node failure without any impact on the policy. And it would not respond to failure of the nodes (or links) that are part of the policy unless the mechanism defined in draft-hegde or in Section 5.3 of this draft (hich are the same mechanism under different names) were enabled. My definituon of (2) explicitly states that main abd backup policues should not have any common SIDs. So I do not see much difference between (2) and (3). What did I miss? Sent from Yahoo Mail on Android On Tue, Nov 28, 2017 at 14:06, Stewart Bryant<stewart.bry...@gmail.com> wrote:
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 On Tue, Nov 28, 2017 at 9:15, Stewart Bryant <stewart.bry...@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 https://www.ietf.org/mailman/listinfo/rtgwg
_______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg
