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 Summary: 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> SB> I think a more up to date evaluation of the ability of MPLS SB> to run in an IPv6 network is needed. SB> 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> 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> 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> 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 requirements: 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. SB> 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 environment. SB> It is unclear whether it is feeding the SR architecture (which is SB> currently in AD evaluation) or the SRv6 design. SB> 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.