RE: Comments on draft-bashandy-rtgwg-segment-routing-ti-lfa

[<[e-mail]>]

Hi Shraddha,

Thanks for your comments. The document is under RTGWG, then I'm adding rtgwg list.
Please find some replies inline


From: Shraddha Hegde [mailto:[e-mail]]
Sent: Monday, July 22, 2019 22:50
To: [e-mail]; SPRING WG List
Subject: Comments on draft-bashandy-rtgwg-segment-routing-ti-lfa

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]).

[SLI] Agree, will fix it


  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.

[SLI] §5.2 represents a link protection case , I agree that we don't have to look at the next segment and the text does not require it. However the current structure could make think that we need.
I will propose a new text to address this.


  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.

[SLI] The goal is to provide an expected result and not how the implementation is done. Your text proposal looks reasonable and I will have a look on how to provide a better wording for the text 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.

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



_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.