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

["Darren Dukes (ddukes)" <[e-mail]>]

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" <[e-mail] on behalf of [e-mail]> 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
   [e-mail]
   https://www.ietf.org/mailman/listinfo/spring