Re: [Gen-art] Genart telechat review of draft-ietf-spring-ipv6-use-cases-11

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 <stewart.bryant@gmail.com> 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
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art