Stewart, thanks for your review. I agree with your concerns around the trust model, but I think the underlying issue is with the standards-track specifications (architecture and the v6 header definition), not with this use case document.
I did see a response from Mark on your question about homenet. I would encourage the authors to take a look at the remainder of your comments to see if there are associated changes to be made to the document. Thanks, Alissa > On Nov 30, 2017, at 5:47 PM, Stewart Bryant <[email protected]> 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. > > 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 > > > _______________________________________________ > Gen-art mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/gen-art _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
