Stewart, thank you for the review. I’m speaking for several of the authors, please see my responses inline (DD>) Thanks Darren On 2017-11-30, 5:48 PM, "spring on behalf of Stewart Bryant" <spring-bounces@xxxxxxxx on behalf of stewart.bryant@xxxxxxxxx> wrote: Reviewer: Stewart Bryant Review result: Not Ready 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. DD> We will rename homenet to "small office or home network". The use case DD> is applicable to either and not specific to the home-net working group effort. 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. DD> As mentioned by Alissa, the authors prefer the security related concerns DD> be addressed in the standard track documents for SRv6 vs this one. 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. DD> Same as above (standard track documents) 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. DD> This use case document does not discuss insertion of a SPRING Header DD> vs Encapsulation in the remainder of its text. Let’s modify this sentence DD> to the following and avoid use of prepend vs insert. DD> *** An ingress node steers a packet by including a controlled set of DD> ***instructions, called segments, in the SPRING 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. DD> This document does not propose use cases for other technologies, DD> headers or types or encapsulations, so covering other solutions to DD> these use case does not contribute to the SPRING ipv6 usecases topic. Minor issues: None Nits/editorial comments: None _______________________________________________ spring mailing list spring@xxxxxxxx https://www.ietf.org/mailman/listinfo/spring