I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-spring-ipv6-use-cases-11
Reviewer: Stewart Bryant
Review Date: 2017-11-30
IETF LC End Date: 2017-05-04
IESG Telechat date: 2017-12-14

Summary: The document has clearly been improved by the removal of the MPLS text. It is now quite a short draft. However a number of major issues appear to remain.

Major issues: 

The homenet section calls up an enterprise related draft, but none of the homenet drafts. As I understand it homenet also supports source-destination routeing. Is the use case really the home environment? If so there really needs to be text explaining why the apparently competing solution is needed. If the use case is the Enterprise environment perhaps the section name should be changed. 

The authors did not address my question from the previous review concerning how the necessary routing information is provided given that the homenet WG are using a distance vector routing protocol. 

There seems to be an outstanding comment concerning the text 

  "Information included in the SPRING header, whether imposed by the
   end-host itself, a customer edge router, or within the access network
   of the ISP, may be of use at the far ends of the data communication
   as well.  For example, an application running on an end-host with
   application-support in a data center can utilize the SPRING header as
   a channel to include information that affects its treatment within
   the data center itself, allowing for application-level steering and
   load-balancing without relying upon implicit application
   classification techniques at the data-center edge.  Further, as more
   and more application traffic is encrypted, the ability to extract
   (and include in the SPRING header) just enough information to enable
   the network and data center to load-balance and steer traffic
   appropriately becomes more and more important."

SB> However there is a trust issue with sharing information in this way
SB> and it was a breach of trust that caused the source routing feature 
SB> to be removed from IPv6 in the first place.
SB>
SB> For this to be a valid use case I think you need to address the 
SB> trust and security issues to explain why they are no longer relevant
SB> or make it clear that they need to be addressed.

I don't thing the following question was addressed from my previous review:

   The need to setup a source-based path, going through some specific
   middle/intermediate points in the network may be related to different
   requirements:

SB> There needs to be some discussion on the trust model here and
SB> attack vectors associated with this proposal.

This remains from my previous review:

An ingress node steers a packet through
   a controlled set of instructions, called segments, by prepending the
   packet with SPRING header.  

SB> That is what I think it should do, but that is not the design direction
SB> of the current IPv6 proposal. The design of record modifies the 
SB> IPv6 header.

As I understand the design the it does not prepend (i.e. use an encapsulation
or a tunnel) it modifies the IPv6 header and then inserts a block of data
between the header and the transport header.

I do not recall seeing an answer to this question from the previous review:

   In an environment, where each single cache system can be uniquely
   identified by its own IPv6 address, a list containing a sequence of
   the caches in a hierarchy can be built.  At each node (cache) in the
   list, the presence of the requested content if checked.  If the
   requested content is found at the cache (cache hits scenario) the
   sequence ends, even if there are more nodes in the list; otherwise
   next element in the list (next node/cache) is examined.

SB> This needs some discussion on the alternative approaches:
SB> for example service function chaining and an ICN overlay.

Minor issues: None

Nits/editorial comments: None