Last Call Review of draft-ietf-spring-ipv6-use-cases-10

Request Review of draft-ietf-spring-ipv6-use-cases
Requested rev. no specific revision (document currently at 12)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2017-05-04
Requested 2017-04-20
Authors John Brzozowski, John Leddy, Clarence Filsfils, Roberta Maglione, Mark Townsley
Draft last updated 2017-05-02
Completed reviews Rtgdir Last Call review of -10 by Adrian Farrel (diff)
Opsdir Last Call review of -10 by Carlos Martínez (diff)
Secdir Last Call review of -10 by Derek Atkins (diff)
Genart Last Call review of -10 by Stewart Bryant (diff)
Genart Telechat review of -11 by Stewart Bryant (diff)
Assignment Reviewer Stewart Bryant
State Completed
Review review-ietf-spring-ipv6-use-cases-10-genart-lc-bryant-2017-05-02
Reviewed rev. 10 (document currently at 12)
Review result Not Ready
Review completed: 2017-05-02


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 treat these comments just
like any other last call comments.

For more information, please see the FAQ at


Document: draft-ietf-spring-ipv6-use-cases-??
Reviewer: Stewart Bryant
Review Date: 2017-05-02
IETF LC End Date: 2017-05-04
IESG Telechat date: Not scheduled for a telechat


I have a number of concerns about this draft, which I detail below.

A significant part of the justification seems to evolve around the inability of MPLS to function in
an IPv6 only network. This is something that the MPLS WG should provide expert input on.

Major issues:
   In addition there are cases where the operators could have made the
   design choice to disable IPv4, for ease of management and scale
   (return to single-stack) or due to an address constraint, for example
   because they do not possess enough IPv4 addresses resources to number
   all the endpoints and other network elements on which they desire to
   run MPLS.

SB> But as I show below MPLS WG either has fixed this or is very close
SB> to fixing this, so I don't see how you can justify designing a
SB> major modification to the IPv6 dataplane on the basis of the above 
SB> statement.


   In such scenario the support for MPLS operations on an IPv6-only
   network would be required.  However today's IPv6-only networks are
   not fully capable of supporting MPLS.  There is ongoing work in the
   MPLS Working Group, described in [RFC7439] to identify gaps that must
   be addressed in order to allow MPLS-related protocols and
   applications to be used with IPv6-only networks.  

SB> That draft was published two years ago. An RFC was published to
SB> address the LDP gap mid 2016. RFC7506 fixed the RAO in April 2015,
SB> MIBs are being replaced by YANG. I am not sure you need GMPLS,
SB> L2VPN or L3VPN in the application you cite.
SB> I think a more up to date evaluation of the ability of MPLS
SB> to run in an IPv6 network is needed.
SB> Additionally if you are talking MPLS-SR then the shortfall is 
SB> different still because you rely on the SR extensions to the IGPs
SB> and not the classic MPLS signalling protocols.


   2.  There is a strict lack of an MPLS dataplane in a portion of the
       end to end path

SB> It is not the lack of MPLS in a portion of the network, since you
SB> can tunnel MPLS over IP. The constraint applies when you need
SB> take an MPLS action at node that does not have MPLS forwarding logic.
SB> I wonder how common this is in practise given that I understand that 
SB> other work in IPv6 SR is driving towards convincing people that
SB> the number of actual SR actions on a path is tiny.

   4.  There is a need to connect millions of addressable segment
       endpoints, thus high routing scalability is a requirement.  IPv6
       addresses are inherently summarizable: a very large operator
       could scale by summarizing IPv6 subnets at various internal
       boundaries.  This is very simple and is a basic property of IP
       routing.  MPLS node segments are not summarizable.  To reach the
       same scale, an operator would need to introduce additional
       complexity, such as mechanisms known with the industry term
       Seamless MPLS [I-D.ietf-mpls-seamless-mpls].

SB> As far as I can see that draft has died, indeed it died in 2014.
SB> Assuming it has not be re-incarnated in another name, this calls
SB> into question the validity of the use case.
SB> I think to compare apples with apples here, we need to take a
SB> look at specific examples to verify that the scaling concern arises.
SB> As part of that we need to consider whether the intrinsic hierarchy
SB> MPLS, and the availability of MPLS context labels addresses the issue.

SB> As far as I can see that draft has died, indeed it died in 2014.
SB> Assuming it has not be re-incarnated in another name, this calls
SB> into question the validity of the use case.
SB> I think to compare apples with apples here, we need to take a
SB> look at specific examples to verify that the scaling concern arises.
SB> As part of that we need to consider whether the intrinsic hierarchy
SB> MPLS, and the availability of MPLS context labels addresses the issue.

   In any environment with requirements such as those listed above, an
   IPv6 data plane 

SB> No, an IPv6 dataplane extended to include source routing capability
SB> ... You do not get this through an off the shelf IPv6 dataplane
SB> other than perhaps MPLS/IPv6.
SB> ... and we should not belittle the difficulty of doing the proposed
SB> SRv6 extensions, not all h/w can easily do it, and a lot of h/w can 
SB> only introduce a tiny number of segments.

   provides a powerful combination of capabilities for a
   network operator to realize benefits in explicit routing, protection
   and restoration, high routing scalability, traffic engineering,
   service chaining, service differentiation and application flexibility
   via programmability.

SB> There is a bit of an (unexplained) leap from the introduction of 
SB> IPv6 to the above set of use cases.


   The use cases described in the section do not constitute an
   exhaustive list of all the possible scenarios; this section only
   includes some of the most common envisioned deployment models for
   IPv6 Segment Routing.  In addition to the use cases described in this
   document the spring architecture should be able to be applied to all
   the use cases described in [RFC7855] for the spring MPLS data plane,
   when an IPv6 data plane is present.

SB> The second sentence reduces to the need to make MPLS work in
SB> an IPv6 environment.


   The ability to steer traffic to an appropriate egress or utilize a
   specific type of media (e.g., low-power, WIFI, wired, femto-cell,
   bluetooth, MOCA, HomePlug, etc.) within the home itself are obvious
   cases which may be of interest to an application running within a
   home network.

SB> So the interesting thing here is that to set up a SR you normally
SB> need to know the topology so you can plan the path, but homenet
SB> chose a distance vector protocol, which is a protocol genre that 
SB> normally does not understand the topology.


   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> 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.


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

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


   This document presents use cases to be considered by the spring
   architecture and potential IPv6 extensions.  As such, it does not
   introduce any security considerations.  However, there are a number
   of security concerns with source routing at the IP layer [RFC5095].
   It is expected that any solution that addresses these use cases to
   also address any security concerns.

SB> It is not clear that the introduction of this technology to these
SB> applications does not introduce a solutions agnostic increase in
SB> security risk.

Minor issues:

   The objective of this document is to illustrate some use cases that
   need to be taken into account by the Source Packet Routing in
   Networking (SPRING) architecture in the context of an IPv6

SB> It is unclear whether it is feeding the SR architecture (which is
SB> currently in AD evaluation) or the SRv6 design.
SB> It seems a bit late to be progressing this if it is a requirement
SB> on the architecture.


   Source Packet Routing in Networking (SPRING) architecture leverages
   the source routing paradigm.  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.


   In today's networks, source routing is typically accomplished by
   encapsulating IP packets in MPLS LSPs that are signaled via RSVP-TE.

SB> There is an interesting question as to whether RSVP-TE is a
SB> source routing paradygm or simply an explicit routing paradygm.
SB> Source routing is more commonly associated with a route imposed
SB> on a packet rather than the identify of a route being imposed on
SB> a packet.

   3.  There is a need or desire to remove routing state from any node
       other than the source, such that the source is the only node that
       knows and will know the path a packet will take, a priori

SB> That is a SR goal, not a goal specific to IPv6


   A spring enabled home provides the ability to steer traffic into a
   specific path from end-hosts in the home, or from a customer edge
   router in the home.  

SB> Where does Babel fit into this? Isn't the purpose of Babel
SB> to do this in a standard IPv6 dataplane?


   Some Data Center operators are transitioning their Data Center
   infrastructure from IPv4 to native IPv6 only, in order to cope with
   IPv4 address depletion and to achieve larger scale.  In such
   environment, source routing (through Segment Routing IPv6) can be
   used to steer traffic across specific paths through the network. 

SB> I do not see how the first sentence leads to the second.


   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.

Nits/editorial comments: 
   Therefore, there are scenarios where it may be possible to run IPv6
   on top of MPLS, and as such, the MPLS Segment Routing architecture

SB> I think that is a design rather than an architecture.


   This is an another
   example of scenario where a solution relying on IPv6 without
   requiring the use of MPLS could represent a valid option to solve the
   problem and meet operators' requirements.

SB> "could" is not a particularly strong justification.