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

["Adrian Farrel" <[e-mail]>]

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