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)
<[email protected]> wrote:
_______________________________________________
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
