All, I reviewed this draft just over 11 weeks ago, but have not heard anything back.
As I said in my review, I think this document is useful and should be published. So I am concerned that there is no progress. I hope it isn't my review that is slowing things down. What are the plans for this document? Thanks, Adrian > -----Original Message----- > From: rtg-dir [mailto:rtg-dir-boun...@ietf.org] On Behalf Of Adrian Farrel > Sent: 08 June 2017 18:13 > To: rtg-...@ietf.org > Cc: rtg-...@ietf.org; spring@ietf.org; > draft-ietf-spring-ipv6-use-ca...@ietf.org > Subject: [RTG-DIR] 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. > > --- > > Terminology... > > The document mixes "SPRING" and "spring". I think it should always be > upper case. > > 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. > > --- > > 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. > > --- > > 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. > > ==== > > Nits: > > You'll need to expand some abbreviations like QAM and DOCSIS. > You can check https://www.rfc-editor.org/materials/abbrev.expansion.txt > > --- > > Section 2.3 > > OLD > In such scenario Segment Routing > NEW > In such scenarios, Segment Routing > END > > --- > > OLD > 2.4. SPRING in the Content Delivery Networks > NEW > 2.4. SPRING in Content Delivery Networks > END > > --- > > OLD > 2.5. SPRING in the Core networks > NEW > 2.5. SPRING in Core Networks > END _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
