Hello Adrian Your comments were addressed and integrated in version-11 published on June 13 Please let us know if you have additional comments or if you find anything missing Thanks Roberta
Inviato da iPhone > Il giorno 26 ago 2017, alle ore 02:42, Adrian Farrel <adr...@olddog.co.uk> ha > scritto: > > 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
