Skip to main content

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 revision No specific revision (document currently at 12)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2017-05-04
Requested 2017-04-20
Authors Clarence Filsfils , Stefano Previdi , Bruno Decraene , Rob Shakir
I-D last updated 2017-05-02
Completed reviews Rtgdir Last Call review of -08 by Lou Berger (diff)
Opsdir Last Call review of -08 by Sheng Jiang (diff)
Secdir Last Call review of -11 by Dacheng Zhang (diff)
Genart Last Call review of -08 by Brian E. Carpenter (diff)
Genart Telechat review of -11 by Brian E. Carpenter (diff)
Assignment Reviewer Sheng Jiang
State Completed
Request Last Call review on draft-ietf-spring-resiliency-use-cases by Ops Directorate Assigned
Reviewed revision 08 (document currently at 12)
Result Has nits
Completed 2017-05-02
review-ietf-spring-resiliency-use-cases-08-opsdir-lc-jiang-2017-05-02-00
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