[RTG-DIR] RtgDir Review draft-ietf-spring-ipv6-use-cases-10

"Adrian Farrel" <adrian@olddog.co.uk> Thu, 08 June 2017 17:12 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 64B8B129666; Thu, 8 Jun 2017 10:12:52 -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 WJ7pqZn4w9AM; Thu, 8 Jun 2017 10:12:49 -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 1D53B12EB04; Thu, 8 Jun 2017 10:12:47 -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 v58HCkqO016266; Thu, 8 Jun 2017 18:12:46 +0100
Received: from 950129200 (xeams.riffcube.co.uk [188.246.205.89]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id v58HCiDv016245 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Jun 2017 18:12:45 +0100
Reply-To: adrian@olddog.co.uk
From: Adrian Farrel <adrian@olddog.co.uk>
To: rtg-ads@ietf.org
Cc: rtg-dir@ietf.org, draft-ietf-spring-ipv6-use-cases@ietf.org, spring@ietf.org
Date: Thu, 08 Jun 2017 18:12:44 +0100
Message-ID: <0faf01d2e07a$72046bd0$560d4370$@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
Content-Language: en-gb
Thread-Index: AdLgele/v5PbrueZT72LZpEyNayhtw==
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-23120.000
X-TM-AS-Result: No--11.158-10.0-31-10
X-imss-scan-details: No--11.158-10.0-31-10
X-TMASE-MatchedRID: ezojVD7Bo79tcr/uuDMv3m7hbmASKcrpQPCWRE0Lo8LIvQIyugvKdVjt prj9/vncRTpdHYygurQZwn7DIQtGC+4dcT3ZaToc+L2GsArAgtofXzVgO0hVqjdnd59Af7CPcUP QjSOUQN03BbIcVNqAhWn/JXTQ1ZHVOg4q4lJPNt/TzWmGCXkX+dRmti/O6j0C30xSgZEFQrKn/M sI/iHGg9H4xMvq7+ANNkz7jSHm0hVNqX9o0l8HXYzb2GR6Ttd3XEjKf9fhKadz5c0A3BjWTGlF7 OhYLlcty7ua+27un4iwAS7xtqjorKX2s5Nec6ilH0JEjBcBuKKiX0I+Ea/UUBxUkJPe1WBqejdT 9nu61Qdq3b03EFzVDYtg4WcukjQ2/38J9QLgtkrIOn6NK8S1a7Q0n3DEfu2TzhY2/o0jwSTG1zZ qIziYsOqCRyazFwQBZ2XCWrJDsnbuctPaL5Jk/Ug5Iem1vm3Hf7rvXBvEkWm1FeFXyekgdNJfzV 9w5vXuSLZYGytM40CXlSuRSjjgAdEQrO9Lrj6hCFaAixm5eU9mEl4mTr2JjzC21gWX+JHJ510L0 3CA1Aqp500lE1xL01YKZ34+ZtO3lvnH+pxJKEqd4hCa7xSZodIv4RV84lHTNcOnkwRgDu+0P6hm Z6xHlIcW3rOHl1LmjSDuMB0SYVfHO8eAxCOj9s1GzI6JnJjKvhf/zJ92tsN94c+e7fWIcC1Kxih PE+JMRxfRxCqIXX/YDYPY26NdkpcLewwAa76fnVTWWiNp+v9BldmDYjwlprgqSDn2azAXWRsIx2 HZId/nzlXMYw4XMD3Al4zalJpFIAcCikR3vq+zjLApzS35tObz9UskOp44jtHMro81m7CKezwT6 4KloVBBlBA57Wum
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/mXOj0_FSjR7wpGaNjbIPUjcWqfo>
Subject: [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: Thu, 08 Jun 2017 17:12:52 -0000

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