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

["Ahmed Bashandy (bashandy)" <[e-mail]>]

Thanks for the feedback

See inline

Ahmed

On 11/28/2017 8:54 AM, Muthu Arul Mozhi Perumal wrote:
> On Tue, Nov 28, 2017 at 5:34 PM, Ahmed Bashandy (bashandy) 
> <[e-mail] <mailto:[e-mail]>>wrote:
>
>     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
>
>
> ​ What if the new top label is a BSID assigned from the SRLB of node F 
> or a BGP-LU or a VPN label assigned by node F?​
#Ahmed: I just replied to Robert. Let me put it here
The node "S" knows the SRGB and the adj-SIDs of the  neighboring node 
"F". Hence if the new top label is not within these two sets, then the 
node "S" will always be able to know that the node that failed is NOT a 
midpoint.
I will add a statement in the document to explain how a node can 
determine that a failure is a midpoint failure. I will also add a 
statement to indicate that if the node determines that the failure is 
not a midpoint failure then it may apply other protection techniques 
that are beyond the scope of this document or simply drop the packet and 
wait for normal protocol conversion.

>     - 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"
>
>
> ​ What does "it" stand for in "it can now compare"?
"Ahmed: "It" refers to the node "S"
>
> ​ For the control plane to be able to compare it also needs to be 
> imposing the SR policy as I said earlier.
#Ahmed: There is no control plane comparison.
>
> Or is the MPLS data plane expected to do such a comparison on the fly?
#Ahmed: data plane is expected to do such comparison. It is not that 
difficult. Just make sure you have a good forwarding ASIC :)
>
>     - 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
>
>
> ​ How is the MPLS data plane in a transit node expected to be 
> programmed to make this work?
#Ahmed: Implementation details that should become big problems for good 
forwarding ASICs :)
>
> Regards,
> Muthu ​
>
>     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
>>     <[e-mail] <mailto:[e-mail]>> 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
>>             <[e-mail] <mailto:[e-mail]>> 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
>>             [e-mail] <mailto:[e-mail]>
>>             https://www.ietf.org/mailman/listinfo/rtgwg
>>             <https://www.ietf.org/mailman/listinfo/rtgwg>
>>
>>
>>
>>
>>     _______________________________________________
>>     rtgwg mailing list
>>     [e-mail]  <mailto:[e-mail]>
>>     https://www.ietf.org/mailman/listinfo/rtgwg  <https://www.ietf.org/mailman/listinfo/rtgwg>
>
>