Subject: [Gen-art] Genart last call review of draft-ietf-spring-ipv6-use-cases-10

From: Stewart Bryant <[email-masked]>
Date: Tue, 02 May 2017 09:57:47 -0700

Reviewer: Stewart Bryant
Review result: Not Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-spring-ipv6-use-cases-??
Reviewer: Stewart Bryant
Review Date: 2017-05-02
IETF LC End Date: 2017-05-04
IESG Telechat date: Not scheduled for a telechat

Summary:

I have a number of concerns about this draft, which I detail below.

A significant part of the justification seems to evolve around the
inability of MPLS to function in
an IPv6 only network. This is something that the MPLS WG should
provide expert input on.

Major issues:
   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.

SB> But as I show below MPLS WG either has fixed this or is very
close
SB> to fixing this, so I don't see how you can justify designing a
SB> major modification to the IPv6 dataplane on the basis of the above

SB> statement.

===============

   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.  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.  

SB> That draft was published two years ago. An RFC was published to
SB> address the LDP gap mid 2016. RFC7506 fixed the RAO in April
2015,
SB> MIBs are being replaced by YANG. I am not sure you need GMPLS,
SB> L2VPN or L3VPN in the application you cite.
SB>
SB> I think a more up to date evaluation of the ability of MPLS
SB> to run in an IPv6 network is needed.
SB>
SB> Additionally if you are talking MPLS-SR then the shortfall is 
SB> different still because you rely on the SR extensions to the IGPs
SB> and not the classic MPLS signalling protocols.

============

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

SB> It is not the lack of MPLS in a portion of the network, since you
SB> can tunnel MPLS over IP. The constraint applies when you need
SB> take an MPLS action at node that does not have MPLS forwarding
logic.
SB> I wonder how common this is in practise given that I understand
that 
SB> other work in IPv6 SR is driving towards convincing people that
SB> the number of actual SR actions on a path is tiny.

   4.  There is a need to connect millions of addressable segment
       endpoints, thus high routing scalability is a requirement. 
IPv6
       addresses are inherently summarizable: a very large operator
       could scale by summarizing IPv6 subnets at various internal
       boundaries.  This is very simple and is a basic property of IP
       routing.  MPLS node segments are not summarizable.  To reach
the
       same scale, an operator would need to introduce additional
       complexity, such as mechanisms known with the industry term
       Seamless MPLS [I-D.ietf-mpls-seamless-mpls].

SB> As far as I can see that draft has died, indeed it died in 2014.
SB> Assuming it has not be re-incarnated in another name, this calls
SB> into question the validity of the use case.
SB>
SB> I think to compare apples with apples here, we need to take a
SB> look at specific examples to verify that the scaling concern
arises.
SB> As part of that we need to consider whether the intrinsic
hierarchy
SB> MPLS, and the availability of MPLS context labels addresses the
issue.

SB> As far as I can see that draft has died, indeed it died in 2014.
SB> Assuming it has not be re-incarnated in another name, this calls
SB> into question the validity of the use case.
SB>
SB> I think to compare apples with apples here, we need to take a
SB> look at specific examples to verify that the scaling concern
arises.
SB> As part of that we need to consider whether the intrinsic
hierarchy
SB> MPLS, and the availability of MPLS context labels addresses the
issue.

   In any environment with requirements such as those listed above,
an
   IPv6 data plane 

SB> No, an IPv6 dataplane extended to include source routing
capability
SB> ... You do not get this through an off the shelf IPv6 dataplane
SB> other than perhaps MPLS/IPv6.
SB> ... and we should not belittle the difficulty of doing the
proposed
SB> SRv6 extensions, not all h/w can easily do it, and a lot of h/w
can 
SB> only introduce a tiny number of segments.

   provides a powerful combination of capabilities for a
   network operator to realize benefits in explicit routing,
protection
   and restoration, high routing scalability, traffic engineering,
   service chaining, service differentiation and application
flexibility
   via programmability.

SB> There is a bit of an (unexplained) leap from the introduction of 
SB> IPv6 to the above set of use cases.

============

   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.

SB> The second sentence reduces to the need to make MPLS work in
SB> an IPv6 environment.

==========

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

SB> So the interesting thing here is that to set up a SR you normally
SB> need to know the topology so you can plan the path, but homenet
SB> chose a distance vector protocol, which is a protocol genre that 
SB> normally does not understand the topology.

========

   Information included in the spring header, whether imposed by the
   end-host itself, a customer edge router, or within the access
network
   of the ISP, may be of use at the far ends of the data
communication
   as well.  For example, an application running on an end-host with
   application-support in a data center can utilize the spring header
as
   a channel to include information that affects its treatment within
   the data center itself, allowing for application-level steering
and
   load-balancing without relying upon implicit application
   classification techniques at the data-center edge.  Further, as
more
   and more application traffic is encrypted, the ability to extract
   (and include in the spring header) just enough information to
enable
   the network and data center to load-balance and steer traffic
   appropriately becomes more and more important.

SB> However there is a trust issue with sharing information in this
way
SB> and it was a breach of trust that caused the source routing
feature 
SB> to be removed from IPv6 in the first place.
SB>
SB> For this to be a valid use case I think you need to address the 
SB> trust and security issues to explain why they are no longer
relevant
SB> or make it clear that they need to be addressed.

========

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

SB> There needs to be some discussion on the trust model here and
SB> attack vectors associated with this proposal.

==========

   This document presents use cases to be considered by the spring
   architecture and potential IPv6 extensions.  As such, it does not
   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.

SB> It is not clear that the introduction of this technology to these
SB> applications does not introduce a solutions agnostic increase in
SB> security risk.
SB> 

Minor issues:

   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.

SB> It is unclear whether it is feeding the SR architecture (which is
SB> currently in AD evaluation) or the SRv6 design.
SB>
SB> It seems a bit late to be progressing this if it is a requirement
SB> on the architecture.

================

   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.  

SB> That is what I think it should do, but that is not the design
direction
SB> of the current IPv6 proposal. The design of record modifies the 
SB> IPv6 header.

==========

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

SB> There is an interesting question as to whether RSVP-TE is a
SB> source routing paradygm or simply an explicit routing paradygm.
SB> Source routing is more commonly associated with a route imposed
SB> on a packet rather than the identify of a route being imposed on
SB> a packet.

   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

SB> That is a SR goal, not a goal specific to IPv6

==========

   A spring enabled home provides the ability to steer traffic into a
   specific path from end-hosts in the home, or from a customer edge
   router in the home.  

SB> Where does Babel fit into this? Isn't the purpose of Babel
SB> to do this in a standard IPv6 dataplane?

=========

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

SB> I do not see how the first sentence leads to the second.

==========

   In an environment, where each single cache system can be uniquely
   identified by its own IPv6 address, a list containing a sequence
of
   the caches in a hierarchy can be built.  At each node (cache) in
the
   list, the presence of the requested content if checked.  If the
   requested content is found at the cache (cache hits scenario) the
   sequence ends, even if there are more nodes in the list; otherwise
   next element in the list (next node/cache) is examined.

SB> This needs some discussion on the alternative approaches:
SB> for example service function chaining and an ICN overlay.

Nits/editorial comments: 
   Therefore, there are scenarios where it may be possible to run
IPv6
   on top of MPLS, and as such, the MPLS Segment Routing architecture

SB> I think that is a design rather than an architecture.

=============

   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.

SB> "could" is not a particularly strong justification.

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Thu, 4 May 2017 20:20:23 +0000

On 5/2/17, 12:57 PM, "Stewart Bryant" <[email-masked]> wrote:

Stewart:

Hi!  How are you?

Thanks for the detailed review!

> inability of MPLS to function in an IPv6 only network.

It seems to me that this statement summarizes many of the concerns you listed as Major in the review.  I can see why it seems like the justification is: “because MPLS doesn’t work, then we have to do IPv6.” – but I think that even if a complete solution exists (for an MPLS deployment on an IPv6-only network), some operators would still make the design choice of preferring an IPv6-only deployment.

I think that it would be good for the authors to refocus the justification away from “because X doesn’t work”.  Would that address this part of your concerns?

Thanks!

Alvaro.

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 5 May 2017 10:52:16 +0100

> I think that it would be good for the authors to refocus the justification away from “because X doesn’t work”.  Would that address this part of your concerns?

Hi Alvaro,

That would be a step in the right direction particularly if Carlos' OPS 
comments were also addressed.

Without going back over the detail, I seem to remember I had a question 
as to how the homenet case worked given that SR needs topology info, and 
homenet has chosen a DV protocol.

I also had a concerns about the validity of the scaling justification, 
and I think there are issues of trust that need to be discussed.

Both of those may be addressable simply by providing more detail as 
Carlos suggests.

Alternatively maybe it would be better to have a single use case: 
Operators that wish to deploy SR without an MPLS control plane, although 
as I note, you don't need an MPLS control plane to make MPLS SR work.

- Stewart

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Fri, 5 May 2017 10:10:39 +0000

> On May 5, 2017, at 11:52 AM, Stewart Bryant <[email-masked]> wrote:
> 
> Alternatively maybe it would be better to have a single use case: Operators that wish to deploy SR without an MPLS control plane,

I’d agree with the above. Let’s simplify the document with, at the end, what is the simplest and most evident use case.

s.

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 5 May 2017 06:17:13 -0400

And to add one observation ..

Stewart makes a point that SR-MPLS can be deployed without mpls control
plane.

Well it sure does not require LDP however IGP or BGP extensions for SR-MPLS
signalling is also an example of mpls control plane ... even if much
simpler than traditional cases it is still required.

Cheers,
R.

On May 5, 2017 12:10 PM, "Stefano Previdi (sprevidi)" <[email-masked]>
wrote:

> Operators that wish to deploy SR without an MPLS control plane,
>
>
> I’d agree with the above. Let’s simplify the document with, at the end,
> what is the simplest and most evident use case.
>
> s.
>
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring
>

---

From: "Mark Townsley (townsley)" <[email-masked]>
Date: Fri, 5 May 2017 11:57:01 +0000

> That would be a step in the right direction particularly if Carlos' OPS comments were also addressed.
> 
> Without going back over the detail, I seem to remember I had a question as to how the homenet case worked given that SR needs topology info, and homenet has chosen a DV protocol.

HNCP performs topology discovery and prefix assignment within the home network, independent of the routing protocol being used.

- Mark

> 
> I also had a concerns about the validity of the scaling justification, and I think there are issues of trust that need to be discussed.
> 
> Both of those may be addressable simply by providing more detail as Carlos suggests.
> 
> Alternatively maybe it would be better to have a single use case: Operators that wish to deploy SR without an MPLS control plane, although as I note, you don't need an MPLS control plane to make MPLS SR work.
> 
> - Stewart
>

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 8 May 2017 11:15:46 +0100

On 05/05/2017 11:17, Robert Raszuk wrote:
> Stewart makes a point that SR-MPLS can be deployed without mpls 
> control plane.
>
> Well it sure does not require LDP however IGP or BGP extensions for 
> SR-MPLS signalling is also an example of mpls control plane ... even 
> if much simpler than traditional cases it is still required.

Yes, but those are required anyway to support SRv6. You always have to 
provide the mapping between the function, the function identifier and 
the function location.

- Stewart

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 8 May 2017 14:12:51 +0200

Hi Stewart,

> ​
Yes, but those are required anyway to support SRv6

That is incorrect.

Please watch Les's presentation during last IETF where he clearly and
correctly stated that IGP extensions for SRv6 are optional and not required
(unlike in the case of SR-MPLS where such signalling of global labels is
indeed necessary to build "global labels" based forwarding).

As a matter of fact I knew this will generate confusion in IETF and
recommended to make it very clear in the drafts. Distribution of SID
functions does not need to be carried in routing protocols. And SRv6 SID
locator function is native to IPv6 routing hence no extensions needed. Sure
they can be carried in IGPs or BGP but this is just an option not
necessity.

Best,
Robert.

On Mon, May 8, 2017 at 12:15 PM, Stewart Bryant <[email-masked]>
wrote:

>> SR-MPLS signalling is also an example of mpls control plane ... even if
>> much simpler than traditional cases it is still required.
>>
>
> ​​
> provide the mapping between the function, the function identifier and the
> function location.
>
> - Stewart
>
>

---

From: Xuxiaohu <[email-masked]>
Date: Tue, 9 May 2017 03:16:01 +0000

Hi Robert,

Except the function indicated by all zeros, it does require mappings between functions, function indications and locators. Take tenant network function as an example☺

Best regards,
Xiaohu

发件人: spring [mailto:[email-masked]] 代表 Robert Raszuk
发送时间: 2017年5月8日 20:13
收件人: Stewart Bryant
抄送: [email-masked]; IETF Discussion; [email-masked]; [email-masked]; stefano previdi; Alvaro Retana (aretana)
主题: Re: [spring] Genart last call review of draft-ietf-spring-ipv6-use-cases-10

Hi Stewart,

That is incorrect.

Please watch Les's presentation during last IETF where he clearly and correctly stated that IGP extensions for SRv6 are optional and not required (unlike in the case of SR-MPLS where such signalling of global labels is indeed necessary to build "global labels" based forwarding).

As a matter of fact I knew this will generate confusion in IETF and recommended to make it very clear in the drafts. Distribution of SID functions does not need to be carried in routing protocols. And SRv6 SID locator function is native to IPv6 routing hence no extensions needed. Sure they can be carried in IGPs or BGP but this is just an option not necessity.

Best,
Robert.

On Mon, May 8, 2017 at 12:15 PM, Stewart Bryant <[email-masked]<mailto:[email-masked]>> wrote:

Stewart makes a point that SR-MPLS can be deployed without mpls control plane.

Well it sure does not require LDP however IGP or BGP extensions for SR-MPLS signalling is also an example of mpls control plane ... even if much simpler than traditional cases it is still required.

​​
Yes, but those are required anyway to support SRv6. You always have to provide the mapping between the function, the function identifier and the function location.

- Stewart

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 9 May 2017 06:20:55 +0200

Hi,

Can you point me to any SRv6 document mandating that such mapping MUST be
done in a routing protocol ?

Thx,
R.

On May 9, 2017 05:16, "Xuxiaohu" <[email-masked]> wrote:

Hi Robert,

Except the function indicated by all zeros, it does require mappings
between functions, function indications and locators. Take tenant network
function as an exampleJ

Best regards,

Xiaohu

*发件人:* spring [mailto:[email-masked]] *代表 *Robert Raszuk
*发送时间:* 2017年5月8日 20:13
*收件人:* Stewart Bryant
*抄送:* [email-masked]; IETF Discussion; [email-masked];
[email-masked]; stefano previdi; Alvaro
Retana (aretana)
*主题:* Re: [spring] Genart last call review of draft-ietf-spring-ipv6-use-
cases-10

Hi Stewart,

That is incorrect.

Best,

Robert.

​​

- Stewart

---

From: Xuxiaohu <[email-masked]>
Date: Tue, 9 May 2017 05:06:42 +0000

Nobody said that such mapping must be distributed in a routing protocol☺   We just said that such mapping is always required no matter we use an MPLS label as function instruction or using the latter part of an IPv6 address as function instruction.

Best regards,
Xiaohu

发件人: [email-masked] [mailto:[email-masked]] 代表 Robert Raszuk
发送时间: 2017年5月9日 12:21
收件人: Xuxiaohu
抄送: stefano previdi; Stewart Bryant; Alvaro Retana (aretana); [email-masked]; [email-masked]; IETF Discussion; [email-masked]
主题: Re: [spring] 答复: Genart last call review of draft-ietf-spring-ipv6-use-cases-10

Hi,

Can you point me to any SRv6 document mandating that such mapping MUST be done in a routing protocol ?

Thx,
R.

On May 9, 2017 05:16, "Xuxiaohu" <[email-masked]<mailto:[email-masked]>> wrote:
Hi Robert,

Best regards,
Xiaohu

发件人: spring [mailto:[email-masked]<mailto:[email-masked]>] 代表 Robert Raszuk
发送时间: 2017年5月8日 20:13
收件人: Stewart Bryant
抄送: [email-masked]<mailto:[email-masked]>; IETF Discussion; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; stefano previdi; Alvaro Retana (aretana)
主题: Re: [spring] Genart last call review of draft-ietf-spring-ipv6-use-cases-10

Hi Stewart,

That is incorrect.

Best,
Robert.

​​

- Stewart

_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 9 May 2017 08:02:24 +0200

Xiaohu,

Mapping can be also well known .. for example from the RFC clearly defining
the functions. That clearly removes the need of *any* control plane to
dynamically carry the values.

Cheers,
R.

On Tue, May 9, 2017 at 7:06 AM, Xuxiaohu <[email-masked]> wrote:

> Nobody said that such mapping must be distributed in a routing protocolJ
> We just said that such mapping is always required no matter we use an MPLS
> label as function instruction or using the latter part of an IPv6 address
> as function instruction.
>
>
>
> Best regards,
>
> Xiaohu
>
>
>
>
>
> *发件人:* [email-masked] [mailto:[email-masked]] *代表 *Robert Raszuk
> *发送时间:* 2017年5月9日 12:21
> *收件人:* Xuxiaohu
> *抄送:* stefano previdi; Stewart Bryant; Alvaro Retana (aretana);
> [email-masked]; [email-masked]; IETF
> Discussion; [email-masked]
> *主题:* Re: [spring] 答复: Genart last call review of
> draft-ietf-spring-ipv6-use-cases-10
>
>
>
> Hi,
>
>
>

---

From: "Roberta Maglione (robmgl)" <[email-masked]>
Date: Thu, 11 May 2017 07:26:40 +0000

Hello Stewart,
Thanks for your review and comments.
We will update the draft and focus on the use case where the ipv6 dataplane is used without any presence of mpls. This addresses the requirements expressed by ipv6 network where, by design policy, mpls dataplane is not used.

Regards
Roberta

-----Original Message-----
From: Stewart Bryant [mailto:[email-masked]] 
Sent: Tuesday, May 2, 2017 6:58 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Genart last call review of draft-ietf-spring-ipv6-use-cases-10

Reviewer: Stewart Bryant
Review result: Not Ready

I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair.  Please treat these comments just like any other last call comments.

Summary:

A significant part of the justification seems to evolve around the inability of MPLS to function in an IPv6 only network. This is something that the MPLS WG should provide expert input on.

Major issues:
   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.

SB> But as I show below MPLS WG either has fixed this or is very
close
SB> to fixing this, so I don't see how you can justify designing a major 
SB> modification to the IPv6 dataplane on the basis of the above

SB> statement.

===============

   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.  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.  

SB> That draft was published two years ago. An RFC was published to 
SB> address the LDP gap mid 2016. RFC7506 fixed the RAO in April
2015,
SB> MIBs are being replaced by YANG. I am not sure you need GMPLS, L2VPN 
SB> or L3VPN in the application you cite.
SB>
SB> I think a more up to date evaluation of the ability of MPLS to run 
SB> in an IPv6 network is needed.
SB>
SB> Additionally if you are talking MPLS-SR then the shortfall is 
SB> different still because you rely on the SR extensions to the IGPs 
SB> and not the classic MPLS signalling protocols.

============

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

SB> It is not the lack of MPLS in a portion of the network, since you 
SB> can tunnel MPLS over IP. The constraint applies when you need take 
SB> an MPLS action at node that does not have MPLS forwarding
logic.
SB> I wonder how common this is in practise given that I understand
that 
SB> other work in IPv6 SR is driving towards convincing people that the 
SB> number of actual SR actions on a path is tiny.

       routing.  MPLS node segments are not summarizable.  To reach the

SB> As far as I can see that draft has died, indeed it died in 2014.
SB> Assuming it has not be re-incarnated in another name, this calls 
SB> into question the validity of the use case.
SB>
SB> I think to compare apples with apples here, we need to take a look 
SB> at specific examples to verify that the scaling concern
arises.
SB> As part of that we need to consider whether the intrinsic
hierarchy
SB> MPLS, and the availability of MPLS context labels addresses the
issue.

SB> As far as I can see that draft has died, indeed it died in 2014.
SB> Assuming it has not be re-incarnated in another name, this calls 
SB> into question the validity of the use case.
SB>
SB> I think to compare apples with apples here, we need to take a look 
SB> at specific examples to verify that the scaling concern
arises.
SB> As part of that we need to consider whether the intrinsic
hierarchy
SB> MPLS, and the availability of MPLS context labels addresses the
issue.

   In any environment with requirements such as those listed above, an
   IPv6 data plane 

   provides a powerful combination of capabilities for a
   network operator to realize benefits in explicit routing, protection
   and restoration, high routing scalability, traffic engineering,
   service chaining, service differentiation and application flexibility
   via programmability.

============

   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.

SB> The second sentence reduces to the need to make MPLS work in an IPv6 
SB> environment.

==========

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

========

   Information included in the spring header, whether imposed by the
   end-host itself, a customer edge router, or within the access network
   of the ISP, may be of use at the far ends of the data communication
   as well.  For example, an application running on an end-host with
   application-support in a data center can utilize the spring header as
   a channel to include information that affects its treatment within
   the data center itself, allowing for application-level steering and
   load-balancing without relying upon implicit application
   classification techniques at the data-center edge.  Further, as more
   and more application traffic is encrypted, the ability to extract
   (and include in the spring header) just enough information to enable
   the network and data center to load-balance and steer traffic
   appropriately becomes more and more important.

========

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

SB> There needs to be some discussion on the trust model here and attack 
SB> vectors associated with this proposal.

==========

   This document presents use cases to be considered by the spring
   architecture and potential IPv6 extensions.  As such, it does not
   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.

Minor issues:

   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.

SB> It is unclear whether it is feeding the SR architecture (which is 
SB> currently in AD evaluation) or the SRv6 design.
SB>
SB> It seems a bit late to be progressing this if it is a requirement on 
SB> the architecture.

================

   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.  

==========

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

SB> There is an interesting question as to whether RSVP-TE is a source 
SB> routing paradygm or simply an explicit routing paradygm.
SB> Source routing is more commonly associated with a route imposed on a 
SB> packet rather than the identify of a route being imposed on a 
SB> packet.

   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

==========

SB> Where does Babel fit into this? Isn't the purpose of Babel to do 
SB> this in a standard IPv6 dataplane?

=========

   infrastructure from IPv4 to native IPv6 only, in order to cope with

==========

   In an environment, where each single cache system can be uniquely
   identified by its own IPv6 address, a list containing a sequence of
   the caches in a hierarchy can be built.  At each node (cache) in the
   list, the presence of the requested content if checked.  If the
   requested content is found at the cache (cache hits scenario) the
   sequence ends, even if there are more nodes in the list; otherwise
   next element in the list (next node/cache) is examined.

Nits/editorial comments: 

=============

   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.