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