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

["Roberta Maglione (robmgl)" <[e-mail]>]

Hello Adrian,
Thanks for your review and comments.
Please see answers inline [RM]
We are going to integrate your comments in the next version we plan to post soon.
Regards
Roberta




-----Original Message-----
From: Adrian Farrel [mailto:[e-mail]] 
Sent: Thursday, June 8, 2017 7:13 PM
To: [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: 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.


[RM] Thanks for the suggestion, we can rephrase it.

---

Terminology...

The document mixes "SPRING" and "spring". I think it should always be upper case.

[RM] ok, I'll change it

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.

[RM] we received similar comments from other reviewers and the authors agreed to focus the document on IPv6 only environment, hence also removing the sentences you mentioned. 

---

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.


[RM] This will be taking in care as part of the cleanup/re-focusing of the document.
---

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.


[RM] ok
====

Nits: 

You'll need to expand some abbreviations like QAM and DOCSIS. 
You can check https://www.rfc-editor.org/materials/abbrev.expansion.txt


[RM] ok
---

Section 2.3

OLD
   In such scenario Segment Routing
NEW
   In such scenarios, Segment Routing
END

[RM] ok
---

OLD
2.4.  SPRING in the Content Delivery Networks NEW 2.4.  SPRING in Content Delivery Networks END

[RM] ok
---

OLD
2.5.  SPRING in the Core networks
NEW
2.5.  SPRING in Core Networks
END

[RM] ok