[spring] Comments on draft-bashandy-rtgwg-segment-routing-ti-lfa

[Shraddha Hegde <[e-mail]>]

Dear Authors

I have the below comments on the draft.

1. Section 1.Introduction

   "This provides a major improvment compared to LFA
   ([RFC5286]) and remote LFA ([RFC7490]) which cannot be applicable in
   some topologies ([RFC6571])."

   Change to

   This provides a major improvement compared to LFA
   ([RFC5286]) and remote LFA ([RFC7490]) which cannot provide
   complete protection coverage in
   some topologies ([RFC6571]).



  2. I suggest to add a new section for building repair segments .
The text appears randomly and it is not very readable.
Suggest to re-arrange as below

  ---------------------------------------------------------------------------------------
  5. Building Repair lists
              The repair list consist of node segments and adjacency segments which represents the
              protection path from PLR to the destination.


   o The active adjacency segments MUST be popped and the repair-list MUST be inserted
     at the head of the list.
   o The active node segments MUST be popped and repair-list inserted as the last segment of    repair list,
              If the repair list ends with an adjacency segment terminating on the tail-end of the
               active segment, and if the active segment has been signalled with penultimate hop popping.
   o The active node segment MUST be retained as the last segment in the repair-list if the
     active node segment has been signaled with ultimate hop popping.

   o  If the SRGB at the Q node is different from the SRGB at the PLR,
      then the active segment (before the insertion of the repair list)
      MUST be updated to fit the SRGB of the Q node.


  -----------------------------------------------------------------------------------------------
  3. Protecting segments

  It is not clear what do the section 5.2.1 and 5.2.2 represent.
  Are these for link-protection cases? You don't have to look into next label for link-protection cases.
  The mid-point node failure section 5.3 addresses node as well adjacency SID cases so 5.2.1 and 5.2.2 need not talk about node protection.

  4.

  Modern routing architectures have separate control plane and data plane.
  section 5.3 language seem to suggest a lot of contol plane like processing in the forwarding plane.
The entire description has a MUST term which mandates implementing expensive
operation in forwarding plane.Suggest to add below text in section 5.3 and also change all MUST in 5.3.1 and 5.3.2
 to non-normative should.
I have copied the entire 5.3 section with suggested changes highlighted in bold

-------------------------------------------------------------------------------------------------
5.3
 Section 5.3.1 and 5.3.2 describe the processing for incoming Node and Adjacency SIDs
 when the next label in the packet is either a node/adj-sid.

The description below is intended to specify the forwarding behavior required for node protection.
The description should not be interpreted as limiting the possible implementations of this forwarding behavior.
An implementation complies with the description below as long as the externally visible forwarding behavior produced
by the implementation is the same as that described below.



  5.3.1.  Protecting {F, T, D} or {S->F, T, D}

   This section describes the protection behavior of S when all of the
   following conditions are true:

   1.  the active segment is a prefix SID for a neighbor F, or an
       adjacency segment S->F

   2.  the primary interface used to forward the packet failed


   3.  the segment following the active segment is a prefix SID (for
       node T)

   4.  node protection is active for that interface.

   In such a case, the PLR should:>>>>>>>>Change to non-normative should

   1.  apply a NEXT operation; the segment F or S->F is removed

   2.  Confirm that the next segment is in the SRGB of F, meaning that
       the next segment is a prefix segment, e.g. for node T

   3.  Retrieve the segment ID of T (as per the SRGB of F)

   4.  Apply a NEXT operation followed by a PUSH operation of T's
       segment based on the SRGB of node S.

   5.  Look up T's segment (based on the updated label value) and
       forward accordingly.

5.3.2.  Protecting {F, F->T, D} or {S->F, F->T, D}

   This section describes the protection behavior of S when all of the
   following conditions are true:

   1.  the active segment is a prefix SID for a neighbor F, or an
       adjacency segment S->F

  2.  the primary interface used to forward the packet failed

   3.  the segment following the active segment is an adjacency SID (F-
       >T)

   4.  node protection is active for that interface.

   In such a case, the PLR should:>>>>>>>>>Change to non normative "should"

   1.  Apply a NEXT operation; the segment F or S->F is removed

   2.  Confirm that the next segment is an adjacency SID of F, say F->T

   3.  Retrieve the node segment ID associated to T (as per the set of
       Adjacency Segments of F)

   4.  Apply a NEXT operation on the next segment followed by a PUSH of
       T's segment based on the SRGB of the node S.


   5.  Look up T's segment (based on the updated label value) and
       forward accordingly.

  ------------------------------------------------------------------------------------------------