Re: [RTG-DIR] RtgDir Review draft-ietf-spring-ipv6-use-cases-10
"Adrian Farrel" <adrian@olddog.co.uk> Sat, 26 August 2017 09:41 UTC
Return-Path: <adrian@olddog.co.uk>
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82F00132D02; Sat, 26 Aug 2017 02:41:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Level:
X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bkkFsojgyw85; Sat, 26 Aug 2017 02:41:54 -0700 (PDT)
Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E5A51321ED; Sat, 26 Aug 2017 02:41:50 -0700 (PDT)
Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id v7Q9fmAc021512; Sat, 26 Aug 2017 10:41:48 +0100
Received: from 950129200 (196.252.114.87.dyn.plus.net [87.114.252.196]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id v7Q9flC0021497 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 26 Aug 2017 10:41:47 +0100
Reply-To: adrian@olddog.co.uk
From: Adrian Farrel <adrian@olddog.co.uk>
To: rtg-ads@ietf.org
Cc: rtg-dir@ietf.org, spring@ietf.org, draft-ietf-spring-ipv6-use-cases@ietf.org
References: <0faf01d2e07a$72046bd0$560d4370$@olddog.co.uk>
In-Reply-To: <0faf01d2e07a$72046bd0$560d4370$@olddog.co.uk>
Date: Sat, 26 Aug 2017 10:41:38 +0100
Message-ID: <088101d31e4f$84882180$8d986480$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJV7Bkei/ZqSZu4tzpmz34tt0M85aGQxZBw
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-23282.006
X-TM-AS-Result: No--15.634-10.0-31-10
X-imss-scan-details: No--15.634-10.0-31-10
X-TMASE-MatchedRID: yebcs53SkkDSw3nP8ewgPKfXIl6Cf6Vrbv16+gil4jfKrGbGSA7+bT8q tc3Zp2f48p796sClznJtZliel/sLZVhrm8WNG8lC5gCHftmwEMK3dp6DuD+6wC62hjZS0WoY+YG jv0sHPzctNRqOBaz1mN6Mgp6awywNsaYKl6IqtEFu4W5gEinK6UDwlkRNC6PCyL0CMroLynVY7a a4/f753MJN1A4Xsa0XZ+YEU9eAbuVR6DT7jy4uvZMSBMTQNiSACAruoteJOhw6lp5/AQWW6oKM0 fljwGtVqVyIJogXqWdfd6LtPrs94+w8rrYji/741N5tiqLHMgspWss5kPUFdH4+AxzmIwY4Q74m Z61P8ps/8uFnLFtcsw0q7qx0Uti5S3NL9oZSa3P87vS8PQu3wDNzwULQwTBPMKZRiezcUtMCgiI aveBs0+LaOPhGKLVRQwmcaF4dD7kLK4dUlqy0pAXysW33GYMp6WNmYQcB5Ex9wRuXoX0dYRdBTl rT3i2i9s6zcm8kfaPfglOsiCnbLU+JxPPMj1PByqVHp2cvsp7cbNJY9S/K70ENV4Lwnu7Bgy7mJ xoEjXnBCNSSwytTaYEUqaUuM6hYJef8M2gKwRDcWo5Vvs8MQhkqnRJng/51/69r3NqBht6MW09z +C2iaENUxDSmLonTlDuDGeAwwU58XbDftE7IsxafLXbshfogQa2sDHLkQ07Z7ve0lygT2I2PN62 7X5nNpFfUrAT4zKDdQCMNC3B2JT6QPiRv82UQ51R1wVM1b2QxXH/dlhvLv2jGtN39AzybS3rCfI MyHrGcRlHlyu49h9a2DjHPVO5iI8jQZDyTiAWeAiCmPx4NwFkMvWAuahr8+gD2vYtOFhgqtq5d3 cxkNevkniXtUAR8IZXruvdBhnLrFOsADI0gjD475t3myRzW78vStd8KKPM=
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/bwTSuNRV9eL-R-5IIFAKYA5yEKA>
Subject: Re: [RTG-DIR] RtgDir Review draft-ietf-spring-ipv6-use-cases-10
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 26 Aug 2017 09:41:57 -0000
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-bounces@ietf.org] On Behalf Of Adrian Farrel > Sent: 08 June 2017 18:13 > To: rtg-ads@ietf.org > Cc: rtg-dir@ietf.org; spring@ietf.org; draft-ietf-spring-ipv6-use-cases@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
- [RTG-DIR] RtgDir Review draft-ietf-spring-ipv6-us… Adrian Farrel
- Re: [RTG-DIR] RtgDir Review draft-ietf-spring-ipv… Roberta Maglione (robmgl)
- Re: [RTG-DIR] RtgDir Review draft-ietf-spring-ipv… Adrian Farrel
- Re: [RTG-DIR] RtgDir Review draft-ietf-spring-ipv… Alvaro Retana (aretana)
- Re: [RTG-DIR] RtgDir Review draft-ietf-spring-ipv… Roberta Maglione (robmgl)