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

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

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 <[e-mail]> 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:[e-mail]] On Behalf Of Adrian Farrel
>> Sent: 08 June 2017 18:13
>> To: [e-mail]
>> Cc: [e-mail]; [e-mail]; [e-mail]
>> 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
>