Use Cases for IPv6 Source Packet Routing in Networking (SPRING)
draft-ietf-spring-ipv6-use-cases-12

[Ballot comment]
Minor question regarding SPRING in Core networks (section 2.5): Why is SR here bettter than MPLS (which I guess is used today for this use case)? In general it would probably have been nice to also talk a bit about how this is better/different than existing technologies.

[Ballot comment]
I share the Gen-ART reviewer's concerns about the trust model that underlies SRv6. But it seems the source of those concerns is that actual spec (draft-ietf-6man-segment-routing-header), not this use case document.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has reviewed draft-ietf-spring-ipv6-use-cases-10.txt, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
IANA Services Specialist
PTI

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Requested status is "Informational" as indicated in the title page header.
This is appropriate for a document describing use cases.


(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: 

Technical Summary:

This document illustrates some use cases that need to be taken into account by the Source Packet Routing in Networking (SPRING) architecture in the context of an IPv6 environment.
 

Working Group Summary:

The uses cases are factual and diverse.

Document Quality:

Document is clear and has been reviewed by both the SPRING and 6MAN WG.


Personnel:

Bruno Decraene is the Document Shepherd.
Alvaro Retana is the Responsible Area Director.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

I've read all related emails on the SPRING mailing list.
I've reviewed -07 and sent comments on the authors and the mailing list. https://mailarchive.ietf.org/arch/msg/spring/pbPqN80dlMovtyZ1AZBVDe67EIM
Authors have addressed all those comments in -08 and 09.


(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No. Many reviews have been done during WG adoption.
I wish there had been more recent reviews:
- Post WG adoption, review and updates on this document has been limited, but this may be related to the nature of this document as use cases are generally stable and do not require everyone to support all use cases.
- During WG Last Call, comments were "support" which does not indicate how detailed were the reviews.


(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

Document describes SPRING use cases for the IPv6 data plane. No additional review needed.
WG last call has forwarded to the 6MAN WG for information and additional review.


(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No specific concern.


(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

All authors have replied to the IPR poll.


(8) Has an IPR disclosure been filed that references this document?

No IPR disclosure have been filed.


(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

WG as a whole understand it.
During WG adoption, there as been many review and discussion.
There has been no opposition during last call.
The use cases are solid as indicated by the multiple implementations of the IPv6 SR data plane.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent?

No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

Nits found have been addressed in -08

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

No formal review needed.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No. There is one normative reference to an RFC.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No downward normative references.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

Publication of this document will not change the status of any existing RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).

No IANA consideration. This is consistent with the nature of the document (use cases).

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

No new IANA registry.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

The document has no text using formal language.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC: spring@ietf.org, draft-ietf-spring-ipv6-use-cases@ietf.org, Bruno Decraene , spring-chairs@ietf.org, bruno.decraene@orange.com, aretana@cisco.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (IPv6 SPRING Use Cases) to Informational RFC


The IESG has received a request from the Source Packet Routing in
Networking WG (spring) to consider the following document:
- 'IPv6 SPRING Use Cases'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2017-05-04. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  The objective of this document is to illustrate some use cases that
  need to be taken into account by the Source Packet Routing in
  Networking (SPRING) architecture in the context of an IPv6
  environment.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-spring-ipv6-use-cases/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-spring-ipv6-use-cases/ballot/


No IPR declarations have been submitted directly on this I-D.

=== AD Review of draft-ietf-spring-ipv6-use-cases-09 ===

Dear authors:

Thank you for a well written and clear document!

The Abstract says that “the objective of this document is to illustrate some use cases that need to be taken into account by the Source Packet Routing in Networking (SPRING) architecture.”  As such, this document should then present use cases that will help in the definition of the spring architecture – which means that the details of such architecture or solution should not be pre-supposed.  My comments below are based on this interpretation – where I will ask you to please take out any assumption/reference to the architecture/solution.

I realize that the spring architecture has already been defined, and that implementations are available, making it harder to ignore what is already out there.  However, from a procedure point of view, this document should have ideally been developed *before* any work was done on the architecture/solution.  It is not necessary to justify publication, or even talk about the current WG charter (which includes documents like this one) – as you will see below, the changes required are minimum.

In this case, it seemed easier to include the document text and interleave comments.  Please see below.

I will start the IETF Last Call once the comments have been addressed and a new version has been published.  As discussed before, I will progress all the use case documents at the same time to the IESG.

Thanks!!

Alvaro.




2      Spring                                                    J. Brzozowski
3      Internet-Draft                                                  J. Leddy
4      Intended status: Informational                                  Comcast
5      Expires: August 14, 2017                                    C.  Filsfils
6                                                              R. Maglione, Ed.
7                                                                    M. Townsley
8                                                                  Cisco Systems
9                                                              February 10, 2017

11                              IPv6 SPRING Use Cases
12                        draft-ietf-spring-ipv6-use-cases-09

14      Abstract

16        Source Packet Routing in Networking (SPRING) architecture leverages
17        the source routing paradigm.  A node steers a packet through a
18        controlled set of instructions, called segments, by prepending the
19        packet with SPRING header.  A segment can represent any instruction,
20        topological or service-based.  A segment can have a local semantic to
21        the SPRING node or global within the SPRING domain.  SPRING allows to
22        enforce a flow through any topological path and service chain while
23        maintaining per-flow state only at the ingress node to the SPRING
24        domain.

This first paragraph describes the spring architecture and is not needed.

26        The objective of this document is to illustrate some use cases that
27        need to be taken into account by the Source Packet Routing in
28        Networking (SPRING) architecture.

30      Status of This Memo

32        This Internet-Draft is submitted in full conformance with the
33        provisions of BCP 78 and BCP 79.

35        Internet-Drafts are working documents of the Internet Engineering
36        Task Force (IETF).  Note that other groups may also distribute
37        working documents as Internet-Drafts.  The list of current Internet-
38        Drafts is at http://datatracker.ietf.org/drafts/current/.

40        Internet-Drafts are draft documents valid for a maximum of six months
41        and may be updated, replaced, or obsoleted by other documents at any
42        time.  It is inappropriate to use Internet-Drafts as reference
43        material or to cite them other than as "work in progress."

45        This Internet-Draft will expire on August 14, 2017.

47      Copyright Notice

49        Copyright (c) 2017 IETF Trust and the persons identified as the
50        document authors.  All rights reserved.

52        This document is subject to BCP 78 and the IETF Trust's Legal
53        Provisions Relating to IETF Documents
54        (http://trustee.ietf.org/license-info) in effect on the date of
55        publication of this document.  Please review these documents
56        carefully, as they describe your rights and restrictions with respect
57        to this document.  Code Components extracted from this document must
58        include Simplified BSD License text as described in Section 4.e of
59        the Trust Legal Provisions and are provided without warranty as
60        described in the Simplified BSD License.

62      Table of Contents

64        1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .  2
65        2.  IPv6 SPRING use cases . . . . . . . . . . . . . . . . . . . .  3
66          2.1.  SPRING in the Home Network  . . . . . . . . . . . . . . .  5
67          2.2.  SPRING in the Access Network  . . . . . . . . . . . . . .  6
68          2.3.  SPRING in the Data Center . . . . . . . . . . . . . . . .  7
69          2.4.  SPRING in the Content Delivery Networks . . . . . . . . .  7
70          2.5.  SPRING in the Core networks . . . . . . . . . . . . . . .  8
71        3.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  9
72        4.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  10
73        5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
74        6.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
75        7.  Informative References  . . . . . . . . . . . . . . . . . . .  10
76        Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

78      1.  Introduction

80        Source Packet Routing in Networking (SPRING) architecture leverages
81        the source routing paradigm.  An ingress node steers a packet through
82        a controlled set of instructions, called segments, by prepending the
83        packet with SPRING header.  A segment can represent any instruction,
84        topological or service-based.  A segment can represent a local
85        semantic on the SPRING node, or a global semantic within the SPRING
86        domain.  SPRING allows one to enforce a flow through any topological
87        path and service chain while maintaining per-flow state only at the
88        ingress node to the SPRING domain.

90        The SPRING architecture is described in
91        [I-D.ietf-spring-segment-routing].  The SPRING control plane is
92        agnostic to the dataplane, thus it can be applied to both MPLS and
93        IPv6.  In case of MPLS the (list of) segment identifiers are carried
94        in the MPLS label stack, while for the IPv6 dataplane, a new type of
95        routing extension header is required.

97        The details of the new routing extension header are described in
98        [I-D.ietf-6man-segment-routing-header] which also covers the security
99        considerations and the aspects related to the deprecation of the IPv6
100        Type 0 Routing Header described in [RFC5095].

The whole introduction talks about and points to the architecture and solutions.  Please include some text relevant to use cases.  I think that the text in Section 2 would make for a fine Introduction.

102    2.  IPv6 SPRING use cases

104        In today's networks, source routing is typically accomplished by
105        encapsulating IP packets in MPLS LSPs that are signaled via RSVP-TE.

For completeness, references to IPv6 (possibly in the Introduction), MPLS LSPs and RSVP-TE would be nice.

106        Therefore, there are scenarios where it may be possible to run IPv6
107        on top of MPLS, and as such, the MPLS Segment Routing architecture
108        described in [I-D.ietf-spring-segment-routing-mpls] could be
109        leveraged to provide SPRING capabilities in an IPv6/MPLS environment.

This second part of the paragraph points at the solution.  Given that the first sentence talked about how source routing is done in MPLS (pre-spring), cutting the sentence should be feasible: “Therefore, there are scenarios where it may be possible to run IPv6 on top of MPLS.”


111        However, there are other cases and/or specific network segments (such
112        as for example the Home Network, the Data Center, etc.) where MPLS
113        may not be available or deployable for lack of support on network
114        elements or for an operator's design choice.  In such scenarios a
115        non-MPLS based solution would be preferred by the network operators
116        of such infrastructures.

118        In addition there are cases where the operators could have made the
119        design choice to disable IPv4, for ease of management and scale
120        (return to single-stack) or due to an address constraint, for example
121        because they do not possess enough IPv4 addresses resources to number
122        all the endpoints and other network elements on which they desire to
123        run MPLS.

125        In such scenario the support for MPLS operations on an IPv6-only
126        network would be required.  However today's IPv6-only networks are
127        not fully capable of supporting MPLS.  There is ongoing work in the
128        MPLS Working Group, described in [RFC7439] to identify gaps that must
129        be addressed in order to allow MPLS-related protocols and
130        applications to be used with IPv6-only networks.  This is an another
131        example of scenario where a solution relying on IPv6 without
132        requiring the use of MPLS could represent a valid option to solve the
133        problem and meet operators' requirements.

135        It is important to clarify that today, it is possible to run IPv6 on
136        top of an IPv4 MPLS network by using the mechanism called 6PE,
137        described in [RFC4798].  However this approach does not fulfill the
138        requirement of removing the need of IPv4 addresses in the network, as
139        requested in the above use case.  Another way to run IPv6 on top of
140        an MPLS network is to use Segment Routing MPLS which provides the
141        support for the IPv6 FEC.  Obviously such approach is applicable only
142        for scenarios and network segments where MPLS is present.

The last 2 sentences fell back to mentioning solutions.

144        In addition it is worth to note that in today's MPLS dual-stack
145        networks IPv4 traffic is labeled while IPv6 traffic is usually
146        natively routed, not label-switched.  Therefore in order to be able
147        to provide Traffic Engineering "like" capabilities for IPv6 traffic
148        additional/alternative encapsulation mechanisms would be required.

150        In summary there is a class of use cases that motivate an IPv6 data
151        plane.  The authors identify some fundamental scenarios that, when
152        recognized in conjunction, strongly indicate an IPv6 data plane:

s/The authors/This document

154        1.  There is a need or desire to impose source-routing semantics
155            within an application or at the edge of a network (for example, a
156            CPE or home gateway)

158      2.  There is a strict lack of an MPLS dataplane in a portion of the
159            end to end path

161        3.  There is a need or desire to remove routing state from any node
162            other than the source, such that the source is the only node that
163            knows and will know the path a packet will take, a priori

165        4.  There is a need to connect millions of addressable segment
166            endpoints, thus high routing scalability is a requirement.  IPv6
167            addresses are inherently summarizable: a very large operator
168            could scale by summarizing IPv6 subnets at various internal
169            boundaries.  This is very simple and is a basic property of IP
170            routing.  MPLS node segments are not summarizable.  To reach the
171            same scale, an operator would need to introduce additional
172            complexity, such as mechanisms known with the industry term
173            Seamless MPLS.

Please add an Informative reference to draft-ietf-mpls-seamless-mpls.  Yes, I know that draft is expired, but it at least provides context.

175        In any environment with requirements such as those listed above, an
176        IPv6 data plane provides a powerful combination of capabilities for a
177        network operator to realize benefits in explicit routing, protection
178        and restoration, high routing scalability, traffic engineering,
179        service chaining, service differentiation and application flexibility
180        via programmability.

182        This section will describe some scenarios where MPLS may not be
183        present and it will highlight how the SPRING architecture could be
184        used to address such use cases.

s//…highlight the need for the spring architecture to take them into account.

186        The use cases described in the section do not constitute an
187        exhaustive list of all the possible scenarios; this section only
188        includes some of the most common envisioned deployment models for
189        IPv6 Segment Routing.  In addition to the use cases described in this
190        document the SPRING architecture can be applied to all the use cases
191        described in [RFC7855] for the SPRING MPLS data plane, when an IPv6
192        data plane is present.

s//spring architecture should be able to be applied…


194    2.1.  SPRING in the Home Network

196        An IPv6-enabled home network provides ample globally routed IP
197        addresses for all devices in the home.  An IPv6 home network with
198        multiple egress points and associated provider-assigned prefixes
199        will, in turn, provide multiple IPv6 addresses to hosts.  A homenet
200        performing Source and Destination Routing
201        ([I-D.ietf-rtgwg-dst-src-routing]) will ensure that packets exit the
202        home at the appropriate egress based on the associated delegated
203        prefix for that link.

rtgwg is currently running with draft-ietf-rtgwg-enterprise-pa-multihoming (and not I-D.ietf-rtgwg-dst-src-routing).  Please update the reference.

205        A SPRING enabled home provides the possibility for imposition of a
206        Segment List by end-hosts in the home, or a customer edge router in
207        the home.  If the Segment List is enabled at the customer edge
208        router, that router is responsible for classifying traffic and
209        inserting the appropriate Segment List.  If hosts in the home have
210        explicit source selection rules, classification can be based on
211        source address or associated network egress point, avoiding the need
212        for DPI-based implicit classification techniques.  If the Segment
213        List is inserted by the host itself, it is important to know which
214        networks can interpret the SPRING header.  This information can be
215        provided as part of host configuration as a property of the
216        configured IP address.

This paragraph mentions several elements of a solution: segment list, spring header…  Please focus the text on the desired function; maybe “source routed path” (or something like that) instead of segment list – “interpretation of the spring header” is really the “ability to act on the source routing information” …. or as you say below “the ability to steer traffic”.

There are other places in the text that use “segment list”.  Please address those as well.

218        The ability to steer traffic to an appropriate egress or utilize a
219        specific type of media (e.g., low-power, WIFI, wired, femto-cell,
220        bluetooth, MOCA, HomePlug, etc.) within the home itself are obvious
221        cases which may be of interest to an application running within a
222        home network.

224        Steering to a specific egress point may be useful for a number of
225        reasons, including:

227        o  Regulatory

229        o  Performance of a particular service associated with a particular
230          link

232        o  Cost imposed due to data-caps or per-byte charges

234        o  Home vs. work traffic in homes with one or more teleworkers, etc.

236        o  Specific services provided by one ISP vs. another
237        Information included in the Segment List, whether imposed by the end-
238        host itself, a customer edge router, or within the access network of
239        the ISP, may be of use at the far ends of the data communication as
240        well.  For example, an application running on an end-host with
241        application-support in a data center can utilize the Segment List as
242        a channel to include information that affects its treatment within
243        the data center itself, allowing for application-level steering and
244        load-balancing without relying upon implicit application
245        classification techniques at the data-center edge.  Further, as more
246        and more application traffic is encrypted, the ability to extract
247        (and include in the Segment List) just enough information to enable
248        the network and data center to load-balance and steer traffic
249        appropriately becomes more and more important.

251    2.2.  SPRING in the Access Network

253        Access networks deliver a variety of types of traffic from the
254        service provider's network to the home environment and from the home
255        towards the service provider's network.

257        For bandwidth management or related purposes, the service provider
258        may want to associate certain types of traffic to specific physical
259        or logical downstream capacity pipes.

261        This mapping is not the same thing as classification and scheduling.
262        In the Cable access network, each of these pipes are represented at
263        the DOCSIS layer as different service flows, which are better
264        identified as differing data links.  As such, creating this
265        separation allows an operator to differentiate between different
266        types of content and perform a variety of differing functions on
267        these pipes, such as byte capping, regulatory compliance functions,
268        and billing.

270        In a cable operator's environment, these downstream pipes could be a
271        specific QAM, a DOCSIS service flow or a service group.

Informative references to QAM and DOCSIS would be nice.


273        Similarly, the operator may want to map traffic from the home sent
274        towards the service provider's network to specific upstream capacity
275        pipes.  Information carried in a packet's SPRING header could provide
276        the target pipe for this specific packet.  The access device would
277        not need to know specific details about the packet to perform this
278        mapping; instead the access device would only need to know how to map
279        the SR SID value to the target pipe.

…spring header…SR SID…  Please focus on the function (not the specific solution).

281    2.3.  SPRING in the Data Center

283        Some Data Center operators are transitioning their Data Center
284        infrastructure from IPv4 to native IPv6 only, in order to cope with
285        IPv4 address depletion and to achieve larger scale.  In such
286        environment, source routing (through Segment Routing IPv6) can be
287        used to steer traffic across specific paths.

289        Another use case for SPRING in the datacenter is to cause a packet to
290        follow a specific path through the network.  The specific path may
291        also include a given function one or more nodes in the path are
292        requested to perform.  In such scenario Segment Routing can be used
293        to steer the packet across a specific list of nodes, tenants and
294        functions.  Each node, tenant and function will be identified by a
295        Segment Routing Identifier (SID), thus the list of SID's will specify
296        how the traffic will have to traverse a specific path.

Even if obvious, using an SID is part of the solution.  The function in this case seems to be the ability to identify specific nodes, tenants, functions….


298        One of the fundamental requirements for Data Center architecture is
299        to provide scalable, isolated tenant networks.  The transition to
300        IPv6 and the introduction of Segment Routing IPv6 open up the
301        possibility to achieve tenant's isolation without additional headers.

This last paragraph sounds like a marketing pitch – please reword to state the isolation requirement.


303    2.4.  SPRING in the Content Delivery Networks

305        The rise of online video applications and new, video-capable IP
306        devices has led to an explosion of video traffic traversing network
307        operator infrastructures.  In the drive to reduce the capital and
308        operational impact of the massive influx of online video traffic, as
309        well as to extend traditional TV services to new devices and screens,
310        network operators are increasingly turning to Content Delivery
311        Networks (CDNs).

313        Several studies showed the benefits of connecting caches in a
314        hierarchical structure following the hierarchical nature of the
315        Internet.  In a cache hierarchy one cache establishes peering
316        relationships with its neighbor caches.  There are two types of
317        relationship: parent and sibling.  A parent cache is essentially one
318        level up in a cache hierarchy.  A sibling cache is on the same level.
319        Multiple levels of hierarchy are commonly used in order to build
320        efficient caches architecture.

322        In an environment, where each single cache system can be uniquely
323        identified by its own IPv6 address, a Segment List containing a
324        sequence of the caches in a hierarchy can be built.  At each node
325        (cache) present in the Segment List a TCP session to port 80 is
326        established and if the requested content is found at the cache (cache
327        hits scenario) the sequence ends, even if there are more nodes in the
328        list.

This last paragraph mentions a segment list and provides some hints of a solution (use port 80, etc.).  Please explain what the functional need is.


330    2.5.  SPRING in the Core networks

332        MPLS is a well-known technology widely deployed in many IP core
333        networks.  However there are some operators that do not run MPLS
334        everywhere in their core network today, thus moving forward they
335        would prefer to have an IPv6 native infrastructure for the core
336        network.

338        While the overall amount of traffic offered to the network continues
339        to grow and considering that multiple types of traffic with different
340        characteristics and requirements are quickly converging over single
341        network architecture, the network operators are starting to face new
342        challenges.

344        Some operators are looking at the possibility to setup an explicit
345        path based on the IPv6 source address for specific types of traffic
346        in order to efficiently use their network infrastructure.  In case of
347        IPv6 some operators are currently assigning or plan to assign IPv6
348        prefix(es) to their IPv6 customers based on regions/geography, thus
349        the subscriber's IPv6 prefix could be used to identify the region
350        where the customer is located.  In such environment the IPv6 source
351        address could be used by the Edge nodes of the network to steer
352        traffic and forward it through a specific path other than the optimal
353        path.

355        The need to setup a source-based path, going through some specific
356        middle/intermediate points in the network may be related to different
357        requirements:

359        o  The operator may want to be able to use some high bandwidth links
360          for specific type of traffic (like video) avoiding the need for
361          over-dimensioning all the links of the network;

363        o  The operator may want to be able to setup a specific path for
364          delay sensitive applications;

366        o  The operator may have the need to be able to select one (or
367          multiple) specific exit point(s) at peering points when different
368          peering points are available;

370        o  The operator may have the need to be able to setup a source based
371          path for specific services in order to be able to reach some
372          servers hosted in some facilities not always reachable through the
373          optimal path;

375        o  The operator may have the need to be able to provision guaranteed
376          disjoint paths (so-called dual-plane network) for diversity
377          purposes

379        All these scenarios would require a form of traffic engineering
380        capabilities in IP core networks not running MPLS and not willing to
381        run it.

383        IPv4 protocol does not provide such functionalities today and it is
384        not the intent of this document to address the IPv4 scenario, both
385        because this may create a lot of backward compatibility issues with
386        currently deployed networks and for the security issues that may
387        raise.

Nit: this paragraph about IPv4 is not needed.

389        The described use cases could be addressed with the SPRING
390        architecture by having the Edge nodes of network to impose a Segment
391        List on specific traffic flows, based on certain classification
392        criteria that would include source IPv6 address.

Again, please focus on the required function, not the solution.

394    3.  Contributors

396        Many people contributed to this document.  The authors of this
397        document would like to thank and recognize them and their
398        contributions.  These contributors provided invaluable concepts and
399        content for this document's creation.

401          Ida Leung
402          Rogers Communications
403          8200 Dixie Road
404          Brampton, ON  L6T 0C1
405          CANADA

407          Email: Ida.Leung@rci.rogers.com

409          Stefano Previdi
410          Cisco Systems
411          Via Del Serafico, 200
412          Rome  00142
413          Italy

415          Email: sprevidi@cisco.com

417          Christian Martin
418          Cisco Systems

420          Email: martincj@cisco.com

422    4.  Acknowledgements

424        The authors would like to thank Brian Field, Robert Raszuk, Wes
425        George, Eric Vyncke, Fred Baker, John G.  Scudder and Yakov Rekhter
426        for their valuable comments and inputs to this document.

428    5.  IANA Considerations

430        This document does not require any action from IANA.

432    6.  Security Considerations

434        There are a number of security concerns with source routing at the IP
435        layer [RFC5095].  Security mechanisms applied to Segment Routing over
436        IPv6 networks are detailed in section 9 of
437        [I-D.ietf-6man-segment-routing-header]

Please avoid pointing at solutions.  A better approach might be something like this:

This document presents use cases to be considered by the spring architecture and potential IPv6 extensions.  As such, it doesn’t introduce any security considerations.  However, there are a number of security concerns with source routing at the IP layer [RFC5095].  It is expected that any solution that addresses these use cases to also address any security concerns.


439    7.  Informative References

Of these references, I think that the one to RFC7855 should be made Normative.

441        [I-D.ietf-6man-segment-routing-header]
442                  Previdi, S., Filsfils, C., Field, B., Leung, I., Linkova,
443                  J., Aries, E., Kosugi, T., Vyncke, E., and D. Lebrun,
444                  "IPv6 Segment Routing Header (SRH)", draft-ietf-6man-
445                  segment-routing-header-05 (work in progress), February
446                  2017.

448        [I-D.ietf-rtgwg-dst-src-routing]
449                  Lamparter, D. and A. Smirnov, "Destination/Source
450                  Routing", draft-ietf-rtgwg-dst-src-routing-03 (work in
451                  progress), November 2016.

453        [I-D.ietf-spring-segment-routing]
454                  Filsfils, C., Previdi, S., Decraene, B., Litkowski, S.,
455                  and R. Shakir, "Segment Routing Architecture", draft-ietf-
456                  spring-segment-routing-10 (work in progress), November
457                  2016.

459        [I-D.ietf-spring-segment-routing-mpls]
460                  Filsfils, C., Previdi, S., Bashandy, A., Decraene, B.,
461                  Litkowski, S., Horneffer, M., Shakir, R.,
462                  jefftant@gmail.com, j., and E. Crabbe, "Segment Routing
463                  with MPLS data plane", draft-ietf-spring-segment-routing-
464                  mpls-07 (work in progress), February 2017.

466        [RFC4798]  De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur,
467                  "Connecting IPv6 Islands over IPv4 MPLS Using IPv6
468                  Provider Edge Routers (6PE)", RFC 4798,
469                  DOI 10.17487/RFC4798, February 2007,
470                  .

472        [RFC5095]  Abley, J., Savola, P., and G. Neville-Neil, "Deprecation
473                  of Type 0 Routing Headers in IPv6", RFC 5095,
474                  DOI 10.17487/RFC5095, December 2007,
475                  .

477        [RFC7439]  George, W., Ed. and C. Pignataro, Ed., "Gap Analysis for
478                  Operating IPv6-Only MPLS Networks", RFC 7439,
479                  DOI 10.17487/RFC7439, January 2015,
480                  .

482        [RFC7855]  Previdi, S., Ed., Filsfils, C., Ed., Decraene, B.,
483                  Litkowski, S., Horneffer, M., and R. Shakir, "Source
484                  Packet Routing in Networking (SPRING) Problem Statement
485                  and Requirements", RFC 7855, DOI 10.17487/RFC7855, May
486                  2016, .

488    Authors' Addresses

490        John Brzozowski
491        Comcast

493        Email: john_brzozowski@cable.comcast.com

495        John Leddy
496        Comcast

498        Email: John_Leddy@cable.comcast.com

500        Clarence Filsfils
501        Cisco Systems
502        Brussels
503        BE

505        Email: cfilsfil@cisco.com
506        Roberta Maglione (editor)
507        Cisco Systems
508        Via Torri Bianche 8
509        Vimercate  20871
510        Italy

512        Email: robmgl@cisco.com

514        Mark Townsley
515        Cisco Systems

517        Email: townsley@cisco.com

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Requested status is "Informational" as indicated in the title page header.
This is appropriate for a document describing use cases.


(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: 

Technical Summary:

Source Packet Routing in Networking (SPRING) architecture leverages the source routing paradigm.  An ingress node steers a packet through a controlled set of instructions, called segments, by prepending the packet with SPRING header.
The SPRING architecture is applicable to both the MPLS and IPv6 dataplane. For MPLS, the list of segment identifiers are carried in the MPLS label stack, with no change in the dataplane. For IPv6, a new type of routing extension header is required to carry the list of segments identifiers. (draft-ietf-6man-segment-routing-header).
This draft documents the use cases motivating this IPv6 extension and describes the context of some of its usages.
 

Working Group Summary:

The uses cases and the impact on the IPv6 data plane, in particular for silicon based forwarding plane, has been extensively discussed at the time of WG adoption. Since WG adoption, there has been no controversy on this document.


Document Quality:

There are multiple implementations of the IPv6 SPRING data plane, including two open source implementations: Linux, VPP (fd.io Vector Packet Processing).


Personnel:

Bruno Decraene is the Document Shepherd.
Alvaro Retana is the Responsible Area Director.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

I've read all related emails on the SPRING mailing list.
I've reviewed -07 and sent comments on the authors and the mailing list. https://mailarchive.ietf.org/arch/msg/spring/pbPqN80dlMovtyZ1AZBVDe67EIM
Authors have addressed all those comments in -08 and 09.


(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No: many reviews have been done during WG adoption.
I wish there had been more recent reviews:
- Post WG adoption, review and updates on this document has been limited, but this may be related to the nature of this document as use cases are generally stable and do not require everyone to support all use cases.
- During WG Last Call, replies were "support" which does not indicate how detailed were the reviews.


(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

Document describe SPRING use cases for the IPv6 data plane. No additional review needed.
WG last call has forwarded to the 6MAN WG for information.


(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No specific concern.


(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

All authors have replied to the IPR poll.


(8) Has an IPR disclosure been filed that references this document?

No IPR disclosure have been filed.


(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

WG as a whole understand it as during WG adoption, there as been many review and discussion.
There has been no opposition during last call.
The use cases are solid as indicated by the multiple implementations of the IPv6 SR data plane.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent?

No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

Nits found have been addressed in -08

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

No formal review needed.

(13) Have all references within this document been identified as either normative or informative?

Yes. All references are informative.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

There are no normative references. Hence no dependencies on normative reference.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No downward normative references.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

Publication of this document will not change the status of any existing RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).

No IANA consideration. This is consistent with the nature of the document (use cases).

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

No new IANA registry.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

The document has not text using formal language.