Hi,
The behavior described in section 5.3 is clear:
- 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 the link from node "S" to node "F" is up, then the normal behavior
for node "S" is to apply penultimate hop popping (PHP). HEnce node "S"
*pops* the top label and sends the packet to node "F"
- But if the link (S,F) is down and "S" is configured to do node
protection, then node "S" will still pop the top label. This will
promote the label right underneath the incoming label to become the
*top* label. Hence there is no need to peek into the label stack
- In a link-state envirnoment, node "S" knows the SRGB of node "F" as
well as all adjacency SIDs of node "F". Hence it can now compare the new
top label against the SRGB or the list of adj-SIDs of the node "F"
- If the new top label is within the SRGB of node "F" or an adj-SID of
node "F", then node "S" applies the behavior described in section 5.3.1
or section 5.3.2, respectively
The bottom line is that there is no need for any peeking into the label
stack. Just inspect the new top label
Thanks
Ahmed
On 11/23/2017 5:04 AM, Muthu Arul Mozhi Perumal wrote:
My understanding is that draft wants to provide a solution for the
problem where the active segment is a prefix/adjacency segment of the
neighbor and the neighbor fails. A solution to this is possible only
at a node that is enforcing the SR policy (consisting of the segment
list). For a transit node, its data plane would have to peek into the
label stack and determine the type of the segment/label following the
active segment and act accordingly, which is not inline with the SR
architecture which requires SR to work 'as is' on traditional MPLS
data plane
Muthu
On Wed, Nov 22, 2017 at 8:22 PM, Alexander Vainshtein
<[email protected] <mailto:[email protected]>> wrote:
Muthu and all,
I do not see how the draft in quesrion us related to "SR Policy".
From my POV its scope is a SR LSP comprised of multiple Node SIDs
within a single IGP domain, and it provides local fast protection
against failure of a node that terminates one of the segments
comprising this LSP. Pritection action is performed by the
penultimate node.
My 2c.
Sent from Yahoo Mail on Android
<https://overview.mail.yahoo.com/mobile/?.src=Android>
On Wed, Nov 22, 2017 at 3:27, Muthu Arul Mozhi Perumal
<[email protected] <mailto:[email protected]>> wrote:
Section 5.3 of draft-bashandy-rtgwg-segment-routing-ti-lfa
describes protecting SR policy midpoints against node failure
for the case where the active segment is the prefix or
adjacency segment of a neighbor.
I believe the steps described in the procedure is applicable
only for a node steering packets into the SR policy. This
could be an ingress PE steering IP packets into a SR-TE tunnel
or an intermediate node steering labeled packets received with
a BSID into a SR-TE tunnel identified by that BSID.
A transit node that has no idea about the SR policy itself is
not expected to perform the procedure described in that section.
Is my understanding correct?
Regards,
Muthu
_______________________________________________
rtgwg mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/rtgwg
<https://www.ietf.org/mailman/listinfo/rtgwg>
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
