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