Hello Adrian, Thanks for your review and comments. Please see answers inline [RM] We are going to integrate your comments in the next version we plan to post soon. Regards Roberta
-----Original Message----- From: Adrian Farrel [mailto:adr...@olddog.co.uk] Sent: Thursday, June 8, 2017 7:13 PM To: rtg-...@ietf.org Cc: rtg-...@ietf.org; draft-ietf-spring-ipv6-use-ca...@ietf.org; spring@ietf.org Subject: RtgDir Review draft-ietf-spring-ipv6-use-cases-10 Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Apologies that this review comes well after the end of IETF last call, however, I have only recently received the request for review. Adrian ==== Document: draft-ietf-spring-ipv6-use-cases-10.txt Reviewer: Adrian Farrel Review Date: 8th June 2017 IETF LC End Date: 4th May 2017 Intended Status: Informational Summary: I have some minor concerns about this document that I think should be resolved before publication. Comments: This document supplies primary use cases for SRv6 in a variety of environments. While originally intended to help motivate the SR architecture, this document now provides a set of use cases that explain how the technology might be used. The document is easy to read and should be published as a helpful explanation of how SRv6 could be used. ==== Major Issues: None found. ==== Minor Issues: While I think this document is useful and should be published, the motivation given in the Abstract suggests that the Architecture is dependent on this draft. That is clearly not the case (since that I-D has already progressed through IETF last call and only makes Informative reference to this document). That shouldn't be an issue of any significance but probably some rewording is needed, such as... The Source Packet Routing in Networking (SPRING) architecture describes how Segment Routing can be used to steer packets through an IPv6 or MPLS network using the source routing paradigm. This document illustrates some use cases for Segment Routing in an IPv6 environment. [RM] Thanks for the suggestion, we can rephrase it. --- Terminology... The document mixes "SPRING" and "spring". I think it should always be upper case. [RM] ok, I'll change it But I also think that the balance between "SPRING" and "Segment Routing" may reflect the age of the document. That maybe doesn't need to be fixed, but the document might align better with other documents if it was. Finally, there is some confusion about what a "segment" is. I think we previously had this conversation with regard to draft-ietf-idr-bgp-prefix-sid and concluded that: A segment represents either a topological instruction such as "go to prefix P following shortest path" or a service instruction (e.g.: "pass through deep packet inspection"). A segment is identified through a Segment Identifier (SID). --- I fully believe in the value of running SR in an IPv6 network, but I think that some of the motivation provided in the Introduction is dubious. The text reads... 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. 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. This point does not motivate SRv6 since today's IPv6-only networks are also not fully capable of supporting SRv6. 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. RFC 7439 is now over two years old. Work on filling the gaps identified began when draft-mpls-ipv6-only-gap was first published in 2013. In the time since then a number of RFCs have been published to fill the gaps and implementations have been upgraded. 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. My conclusion is that this document is trying to oversell the use of SR in an IPv6 network where no such sale needs to be made. The result is that it appears to disparage MPLS where it should be enough to say that a choice can be made, and then lay out the use cases where that choice is made and explain how the network works when the choice is made. I would suggest simply removing these paragraphs with the result of a stronger statement of use rather than an arguable statement of motivation. [RM] we received similar comments from other reviewers and the authors agreed to focus the document on IPv6 only environment, hence also removing the sentences you mentioned. --- Section 1 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 I think this is a little confused. Obviously, you still have routing state in the nodes within the network for everything other than adjacency SIDs. I think that what you are removing from the network is path state (or control plane signaling state). How about... 3. There is a need or desire to remove as much state as possible from the nodes in the network such that the source is the only node that knows the path a packet will take through the network. --- Section 1 I'm not really convinced by the fourth bullet. It's true that IP addresses can be aggregated so that one advertisement can carry a prefix but this also applies to address advertisements that carry MPLS SIDs. I think you are probably making a point about how an end-to-end SID can be routed across a network without the need for a SID stack, but it is a bit hard to extract from the text. [RM] This will be taking in care as part of the cleanup/re-focusing of the document. --- The start of Section 2 has the same issue as the Abstract. I suggest... OLD This section will describe some scenarios where MPLS may not be present and it will highlight the need for the spring architecture to take them into account. 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. NEW This section describes some scenarios where segment routing is applicable in an IPv6 environment. 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 could 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. [RM] ok ==== Nits: You'll need to expand some abbreviations like QAM and DOCSIS. You can check https://www.rfc-editor.org/materials/abbrev.expansion.txt [RM] ok --- Section 2.3 OLD In such scenario Segment Routing NEW In such scenarios, Segment Routing END [RM] ok --- OLD 2.4. SPRING in the Content Delivery Networks NEW 2.4. SPRING in Content Delivery Networks END [RM] ok --- OLD 2.5. SPRING in the Core networks NEW 2.5. SPRING in Core Networks END [RM] ok _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
