Last Call Review of draft-ietf-spring-problem-statement-06
review-ietf-spring-problem-statement-06-opsdir-lc-chown-2016-01-25-00

Hi,

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. 

Overall this document is quite close to being ready, but I have a few comments below

for consideration by the AD / authors.

This draft is a problem statement (in the form of a number of use cases) and a set

of requirements for Source Packet Routing in Networks (SPRING) or, as it is otherwise

known, Segment Routing. It is one of a large number of active documents in the SPRING

WG, as listed at 

https://tools.ietf.org/wg/spring/

. These include forays into solution space

(e.g. the IPv6 SRH, tagged as a 6man draft) and the SPRING architecture, which can

be found at 

https://tools.ietf.org/html/draft-ietf-spring-segment-routing-07

.

There is clearly significant interest in the IETF in developing the SR architecture(s) and

solutions.

The work in SPRING is already quite advanced, and thus one might query the value of

extensive effort in nailing down the problem statement and requirements. However, I

feel it is proper that the WG should ensure that the basis for their published solutions 

has been through an appropriate consensus process, esp.  should the rationale for 

certain requirements need to be revisited in the future.

In that light, the document feels somewhat ‘note form’, in that requirements are scattered

through the discussed use cases, and many are not explained in any detail (presumably 

as the authors assume certain level knowledge from those in the WG), e.g. what is meant

by ‘shared risk constraints’? The terminology could be better explained, for a broader

audience, and to reduce any potential ambiguity.

The requirements take the form of (depending on how you count them) 32 SHOULDs,

and there are, perhaps a little surprisingly, no MUSTs. Are the authors confident that 

every SHOULD is just that, and that there are no mandatory requirements?

I might have queries over certain capabilities (implementations of requirements) in the

document, e.g. insertion / removal of IPv6 SRHs, but I think it’s better that this document 

avoids drifting into discussing potential solution spaces.

The Security Considerations section is quite light, though it does contain one SHOULD.

I assume more detailed security discussion is to be contained in the solution documents,

although I note that the Security Considerations section of the architecture document is 

also very brief. 




Tim