Subject: Shepherd review of draft-ietf-rtgwg-segment-routing-ti-lfa

From: Stewart Bryant <[email-masked]>
Date: Fri, 7 May 2021 20:21:12 +0100

I have been asked to Shepherd draft-ietf-rtgwg-segment-routing-ti-lfa and base this review on -06

I have a number of comments that I think we can usefully resolve before the WGLC process, two of which (points 1 & 5) the Chairs need to comments on.

I will start the IPR call in parallel with the process of resolution of these comments.

Overall the draft is a significant improvement on the version that I reviewed some years ago, but there are a number of issues that we need to consider in this version.

1) You have six authors when the policy as I understand it is five. Please either change one of the authors to a contributor, or provide text for inclusion in the shepherd’s report that the IESG is likely to find a satisfactory reason for agreeing to an exception.

2) In section 5.1 the text says: 

"When a direct neighbor is in P(S,X) and Q(D,x) and on the post-convergence path, the outgoing interface is set to that neighbor and the repair segment list MUST be empty."

I agree that normally the repair list would be empty, but MUST is a very strong term. I am thus wondering if the MUST is correct and whether this is not a local matter. I think that it would not break anything PHP was not enabled and the packet was sent with a label to Q. Also an implementation might I suppose create a repair segment list with Adj(Q) and PHP it. MUST is a very strong term and I am therefore concerned as to whether it is correct.

3) Again in 5.2 

"When a remote node R is in P(S,X) and Q(D,x) and on the post-convergence path, the repair list MUST be made of a single node    segment to R and the outgoing interface MUST be set to the outgoing interface used to reach R.”

Again I agree that the repair list is likely to just contain “R” but I am worried if the strong term MUST is required.

4) In section 5.3, again worried that the strong term MUST is used.

5) In 6.1.1.  The active segment is a node segment
"The active segment MUST be kept on the SR header unchanged and the  repair list MUST be inserted at the head of the list.  The active segment becomes the first segment of the inserted repair list."

This text applies to both MPLS and SRv6, but as I understand it, and I have asked one of the SPRING chairs, in network SRH modification is not yet agreed in 6man? The text says that it MUST be done as opposed to adding a layer of encapsulation. If this text remains, the document will stall until the matter is resolved in 6man.
I think we need to seek the chairs and possibly ADs position on how hard to progress this draft in the absence of a resolution of this issue.
Of course if there is an RFC that permits SRv6 header insertion, it might be useful to include a reference to stop this issue being raised again at a later stage in the publication process.
6) 6.2.1.  Protecting {F, T, D} or {S->F, T, D}
SB> I cannot see what {F, T, D} or {S->F, T, D} refers to though can glean this from later text. A more readable header would help the reader.
7) The 6.2.1 and 6.2.2 will be impenetrable to a lot of future readers who are not both SR and IPRFF specialist. I think to would be of benefit if an English text summary was provided to support the pseudo-math approach used in the draft.
8)   " 2.  Confirm that the next segment is in the SRGB of F, meaning that” - SRGB needs to be expanded on first use.
9) Point 3 on page 14
"3.  Otherwise the failure is not a midpoint failure and hence the node "S" may apply other protection techniques that are beyond the scope of this document or simply drop the packet and wait for normal protocol convergence.”
I do not understand what is happening here, so cannot judge whether this conflicts with the complete coverage claim made earlier. Please could you clarify.
10) Section 8
It is well known that multiple repairs can form loops. How are such loops avoided in the case of a double repair? Are you gleaning the original failure from the adj(R7-R8) SID? Also what is you AAH strategy when supporting multiple repairs?
11) Table 3B

Line T3, Shouldn’t “3 SIDs” be 100% in this cumulative table?

Line T8 SID should be 100.000%

However a general comment on all of the tables. Three decimal places, i.e. five places of precision seems unlikely to add value. You might consider reducing the number of decimal places. That is not a required change, but some may consider this a false precision in terms extrapolating to other network environments.
12 )Security Section

We can wait to see what the security directorate say, but I doubt that this will past muster. You probably need to at least refer to the security considerations in previous FRR RFCs and in SR-MPLS and SRv6 and assure the reader that no new security issues are introduced - assuming of course that is the case. 

13) Conclusion
Whilst common in the research literature conclusions after the boilerplate sections (Security and IANA) are rare in RFCs. I am not sure that the conclusion adds any value and I think that it could safely be removed.
14) [I-D.ietf-spring-srv6-network-programming]

ID-NITS is reporting that this is included but not called up in the text. 

Best regards

Stewart