Last Call Review of draft-ietf-spring-ipv6-use-cases-10
review-ietf-spring-ipv6-use-cases-10-rtgdir-lc-farrel-2017-06-08-00

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