Last Call Review of draft-ietf-spring-resiliency-use-cases-08
review-ietf-spring-resiliency-use-cases-08-opsdir-lc-jiang-2017-05-02-00

Request Review of draft-ietf-spring-resiliency-use-cases
Requested rev. no specific revision (document currently at 11)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2017-05-04
Requested 2017-04-20
Other Reviews Rtgdir Last Call review of -08 by Lou Berger (diff)
Secdir Last Call review of -11 by Dacheng Zhang
Genart Last Call review of -08 by Brian Carpenter (diff)
Genart Telechat review of -11 by Brian Carpenter
Review State Completed
Reviewer Sheng Jiang
Review review-ietf-spring-resiliency-use-cases-08-opsdir-lc-jiang-2017-05-02
Posted at https://www.ietf.org/mail-archive/web/ops-dir/current/msg02625.html
Reviewed rev. 08 (document currently at 11)
Review result Has Nits
Draft last updated 2017-05-02
Review completed: 2017-05-02

Review
review-ietf-spring-resiliency-use-cases-08-opsdir-lc-jiang-2017-05-02

Hi, OPS-DIR, Authors,

 

I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments.

 

This Informational document identifies and describes the requirements for a set of use cases related to network resiliency on Segment Routing (SPRING) networks. This document is well written. It is ready with minor issues.

 

Major issue: no.

 

Minor issue:

 

In section 5, “The SPRING architecture SHOULD provide solutions to prevent the occurrence of microloops during convergence following a change in the network state.” It looks for me that “SHOULD” is not strong enough. Any loops means packet lose. If it cannot be resolved quickly. It means unreachable for some source/des pair. It should be replaced by a “MUST”.

 

One more question, which may not be an issue, but personal curious: in section 2, “As a requirement, the two paths MUST be disjoint in their links, nodes or shared risk link groups (SRLGs).” Where does this requirement come from? The “disjoint” looks for me a very strong requirement, and “MUST” is very strong, too. The partially joint paths could be back-up path with certain prerequisite, for example, path A-B-C-D-E could have backup path A-B-C-F-E to protect risk from C-D-E and A-G-J-D-E to protect risk from A-B-C-D. I know this kind of backup path selection may make the solution or algorithm becomes very complicated. But at least, it is workable in theory. So, it could be design choice to leave them out. But it needs some analysis and explanation for such design choice and such design choice should just be a “SHOULD” (MUST means no alternative for me). If this requirement has been analyzed by another document, a quota would be great.

 

Best regards,

 

Sheng