[spring] Benoit Claise's Discuss on draft-ietf-spring-problem-statement-06: (with DISCUSS and COMMENT)

["Benoit Claise" <[e-mail]>]

Benoit Claise has entered the following ballot position for
draft-ietf-spring-problem-statement-06: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-spring-problem-statement/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I would like to discuss this point with the responsible area director
during the telechat. No action from the authors is required on this point
at this point. The manageability considerations section is a direct
cut/paste from a charter (i.e. minimal effort) + two informative
references to drafts, not even WG docs. What are we suppose to conclude
from this, in terms of manageability requirements?


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

-
It seems to me that, when speaking of SPRING, people speaks of Segment
Routing.
The section title 3.3.1.2.2. is "SDN/SR use-case" btw.
Why not mention it somewhere in the doc, for this first SPRING document?
"SPRING is also known as Segment Routing"

-
   The SPRING architecture SHOULD support traffic engineering,
   including:

To be consistent with the two previous use cases, I guess you want:

   The SPRING architecture SHOULD support the following traffic
engineering,
   requirements:

Otherwise, it seems that TE is an optional use case, which somehow
contradicts: 

   In this context, Source Packet Routing in Networking (SPRING)
   architecture is being defined in order to address the use cases and
   requirements described in this document.

===============================================================
Now updated with Tim Chown's OPS DIR review:

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.