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

See inline

Ahmed

On 11/28/2017 8:04 AM, Alexander Vainshtein wrote:
> Ahmed and all,
> Two points:
> 1. From my POV your description of forwarding behavior when the link 
> S-->F fails is incomplete: the top label in the stack may be poppoed, 
> but it is not "forgotten", and the next exposed label is looked up by 
> S in the context label space that is F-specific. I.e., if S has two 
> downstream neighbors, F and G, and both links S-->F and S-->G fail, 
> lookup of the next exposed label for packets with ToS being S label 
> for F and S label for G will yield different results.
>
#Ahmed: I do not understand what is not clear. The draft says in 
sections 5.3.1 and 5.3.2 "Confirm that the next segment is in the SRGB 
of F" and "the active segment is a prefix SID for a neighbor F" and 
"Confirm that the next segment is an adjacency SID of F".

In my previous email I said 'node "S" knows the SRGB of node "F" as well 
as all adjacency SIDs of node "F"'

So it is quite clear that the checks done on the new top label is within 
the context of the next-hop "F"

> 2. From my POV draft-hegde-spring-node-protection-for-sr-te-paths 
> provides roughly equjvalent behavior, but it is much more clear when 
> it comes to describibg the DP mechanisms involved. (IMHO and FWIW 
> calling a spae by its name is greatly preferable in most cases.)
#Ahmed: thanks for pointing out that 
draft-hegde-spring-node-protection-for-sr-te-paths overlaps with 
draft-bashandy-rtgwg-segment-routing-ti-lfa :)

>
> My 2c
>
>
> Sent from Yahoo Mail on Android 
> <https://overview.mail.yahoo.com/mobile/?.src=Android>
>
>     On Tue, Nov 28, 2017 at 6:04, Ahmed Bashandy (bashandy)
>     <bashandy@cisco.com> wrote:
>     _______________________________________________
>     rtgwg mailing list
>     rtgwg@ietf.org <mailto:rtgwg@ietf.org>
>     https://www.ietf.org/mailman/listinfo/rtgwg
>