Source Packet Routing in Networking (SPRING) Problem Statement and Requirements
RFC 7855

Note: This ballot was opened for revision 06 and is now closed.

Alvaro Retana Yes

(Jari Arkko) No Objection

(Alia Atlas) No Objection

Comment (2016-01-20 for -06)
No email
send info
A terminology section and describing at all the bullets of desired functionality would
improve the readability.  This draft doesn't feel as if it will be a useful RFC in 2 years.

(Ben Campbell) No Objection

Comment (2016-02-03 for -06)
No email
send info
I'm not going to block over this, but I share the question about why this should be published as an RFC. It seems to be intended to guide other work. Once that work is done, will people still need this? This might be more appropriate for a wg wiki.

The "Requirements Language" section contains the standard RFC 2119 boilerplate. But this draft does not use the terms as defined in 2119. That talks about implementation requirements, not requirements on new IETF work. If you want to keep the 2119 keywords, please adjust the boilerplate to say what you are actually doing. (Personally, I don't think the 2119 keywords add much, and may cause confusion. (Along those lines, I share Alissa's question about the heavy use of SHOULDs).

The security considerations are inadequate. I would like to see more about the potential threats for a source-routed system. For example, is it a privacy issue if you leak routes across a domain boundary? Could an attacker modify routes to cause traffic to be routed to a tap point? (etc)

Several of the informative references define use cases that seem to be necessary to fully understand this document. Please consider making them normative.

(Benoît Claise) (was Discuss) No Objection

Comment (2016-03-01 for -07)
No email
send info
-
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"

Alissa Cooper No Objection

Comment (2016-01-20 for -06)
No email
send info
(1)
I'm surprised that almost all of the requirements in this document are SHOULDs, since they mostly apply to an architecture and not individual solutions. In general I think it would help to explain the exception cases or the rationale for uncertainty about what the architecture will or won't support.

(2)
The security considerations section here appears to borrow text from the SPRING WG charter, but then is actually less specific than the charter about the anticipated mitigations that the SPRING architecture will provide against known threats. Given the structure of this document I would have expected detailed security requirements that any SPRING solution will be required to meet.

(Stephen Farrell) (was Discuss) No Objection

Comment (2016-03-02 for -07)
No email
send info
Thanks for adding the new security considerations text.

My take-away from that is:

- The architecture needs to have a clearly defined 
  concept of domains so that you can strip source
  routes on ingress/egress, if needed.
- We know there are (as yet unstated) security issues
  with source routing. The architecture document is
  where those are promised. Which document is that?
  Is it draft-ietf-spring-segment-routing?
  So far, that doesn't seem to be there, so we should
  expect more discussion to be needed if that remains
  the case.
- You figure spring is ok-ish for MPLS, or at least no 
  worse than today, is that right?
- There is a need for a digital signature mechanism
  (or similar) for the IPv6 data plane. In which document
  would I find that? 
  Is it draft-previdi-6man-segment-routing-header?
  If so, that seems to call for pre-shared keys, which
  seems likely to be tricky, if we consider BCP107. I
  think we'll be heading for yet another discussion 
  of the need for automated key management here.

I'm ok with letting this document go ahead, but I do hope
the WG have substantive discussion of the above topics and
we don't leave that to IESG review of the documents
concerned. I'm happy to try help get that done earlier if
the WG are up for that as leaving it to IESG review is
liable to be more painful all around.

(Joel Jaeggli) No Objection

Comment (2016-02-04 for -06)
No email
send info
I find myself rather unsatisfied by 

   The SPRING architecture SHOULD leverage the existing MPLS dataplane
   without any modification and leverage IPv6 dataplane with a new IPv6
   Routing Header Type (IPv6 Routing Header is defined in [RFC2460]).

in that the prospects for use of a new routing header, and ipv6 router/extension header treatment  seem poor. and the potential consequences for chaining these for example seem worth exploring before electing that course of action.

(Terry Manderson) (was Discuss) No Objection

Comment (2016-04-06)
No email
send info
Thank you for the update in addressing my concerns in this rev, clearing my DISCUSS.

Deborah Brungard (was Discuss) Abstain

Comment (2016-04-12)
No email
send info
Thanks for addressing my Discuss and improving Section 3.3. I still find the various comparisons on using a distributed approach vs. a centralized controller as lacking in accuracy and a poor justification for SPRING. Just say simply you do not want to use a distributed control plane. This is not the first time that IETF had this requirement for one of their data planes.

I won't block publication, so my "Abstain" position.

(Brian Haberman) (was Discuss) Abstain

Comment (2016-03-01 for -07)
No email
send info
Thank you for addressing the discuss points raised...

I do not see a benefit in the publication of this document (or most problem statement documents) as a standalone document. The type of justification provided in this document could easily exist as a section within a proposed solution.

Barry Leiba Abstain

Comment (2016-02-03 for -06)
No email
send info
I agree with Alia's comment, "This draft doesn't feel as if it will be a useful RFC in 2 years."  I think this is an example of a document that should be kept within the working group and used to guide its progress, but that doesn't seem to be a good candidate for going into the RFC archival series.  I don't think my view on this should get in the way of publication, and so my "abstain" position.