Subject: [spring] I-D Action: draft-ietf-spring-ipv6-use-cases-00.txt

From: [email-masked]
Date: Tue, 13 May 2014 09:36:38 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Source Packet Routing in Networking Working Group of the IETF.

        Title           : IPv6 SPRING Use Cases
        Authors         : John Brzozowski
                          John Leddy
                          Ida Leung
                          Stefano Previdi
                          Mark Townsley
                          Christian Martin
                          Clarence Filsfils
                          Roberta Maglione
	Filename        : draft-ietf-spring-ipv6-use-cases-00.txt
	Pages           : 12
	Date            : 2014-05-09

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

   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.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-spring-ipv6-use-cases/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-spring-ipv6-use-cases-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "George, Wes" <[email-masked]>
Date: Fri, 16 May 2014 08:28:06 -0400

It may be a good idea to add some mention of the fact that at least
currently, IPv6-only networks cannot fully support MPLS. While  the draft
presents the lack of MPLS as a potential hardware limitation or design
choice to avoid MPLS on networks where it is not already present, there
are some additional reasons that I think are worth discussing. The
operator could have made the design choice to disable IPv4 on their
network for ease of management and scale (return to single-stack) or due
to an address constraint, where the operator does not possess enough IPv4
address resources to provide IPv4 addressing to the endpoints and other
network elements on which they desire to run MPLS, and therefore would
require MPLS to support operation on an IPv6-only network. There is work
ongoing in the MPLS WG [draft-ietf-mpls-ipv6-only-gap] to catalog the
issues that must be addressed before IPv6-only MPLS is fully supported,
but since that is only in the gap-analysis phase, it will be some time
before IPv6-only MPLS is a reality, so in some ways, I see SPRING over
IPv6 as a way to leapfrog this work.

Further, it is worth highlighting that in a dual-stack MPLS-enabled
network, by default IPv6 traffic is natively routed, not label-switched,
and in order to use MPLS features such as RSPV-TE on IPv6 traffic flows,
the traffic must either be encapsulated in a VPN (6VPE) or forced to use
the MPLS data plane (6PE). Thus segment routing via MPLS is not a complete
solution for IPv6 traffic flows by default.

Another suggestion for section 2.5 - provisioning of guaranteed disjoint
paths for diversity.

Thanks,

Wes George

Anything below this line has been added by my company’s mail server, I
have no control over it.
-----------

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: "Roberta Maglione (robmgl)" <[email-masked]>
Date: Sat, 17 May 2014 00:35:23 +0000

Hello Wes,
Thanks for reviewing the draft and providing feedback.
You raised a good point: running MPLS in IPv6-only networks has some challenges today because of the gaps highlighted in the MPLS analysis document. This could definitely become an additional driver/motivation for deploying IPv6 SR.   

I also agree on your second point: being able to simply provision disjoint paths in IPv6-only networks is an important use case for IPv6 SR.

We are going to incorporate your suggestions in the next revision of the document.
Thanks
Best Regards
Roberta  

-----Original Message-----
From: spring [mailto:[email-masked]] On Behalf Of George, Wes
Sent: Friday, May 16, 2014 8:28 AM
To: [email-masked]
Subject: Re: [spring] I-D Action: draft-ietf-spring-ipv6-use-cases-00.txt

It may be a good idea to add some mention of the fact that at least currently, IPv6-only networks cannot fully support MPLS. While  the draft presents the lack of MPLS as a potential hardware limitation or design choice to avoid MPLS on networks where it is not already present, there are some additional reasons that I think are worth discussing. The operator could have made the design choice to disable IPv4 on their network for ease of management and scale (return to single-stack) or due to an address constraint, where the operator does not possess enough IPv4 address resources to provide IPv4 addressing to the endpoints and other network elements on which they desire to run MPLS, and therefore would require MPLS to support operation on an IPv6-only network. There is work ongoing in the MPLS WG [draft-ietf-mpls-ipv6-only-gap] to catalog the issues that must be addressed before IPv6-only MPLS is fully supported, but since that is only in the gap-analysis phase, it will be some time before IPv6-only MPLS is a reality, so in some ways, I see SPRING over
IPv6 as a way to leapfrog this work.

Further, it is worth highlighting that in a dual-stack MPLS-enabled network, by default IPv6 traffic is natively routed, not label-switched, and in order to use MPLS features such as RSPV-TE on IPv6 traffic flows, the traffic must either be encapsulated in a VPN (6VPE) or forced to use the MPLS data plane (6PE). Thus segment routing via MPLS is not a complete solution for IPv6 traffic flows by default.

Another suggestion for section 2.5 - provisioning of guaranteed disjoint paths for diversity.

Thanks,

Wes George

Anything below this line has been added by my company’s mail server, I have no control over it.
-----------

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
_______________________________________________
spring mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/spring