draft-ietf-spring-ipv6-use-cases-04.txt   draft-ietf-spring-ipv6-use-cases-05.txt 
Spring J. Brzozowski Spring J. Brzozowski
Internet-Draft J. Leddy Internet-Draft J. Leddy
Intended status: Informational Comcast Intended status: Informational Comcast
Expires: September 7, 2015 I. Leung Expires: March 4, 2016 I. Leung
Rogers Communications Rogers Communications
S. Previdi S. Previdi
M. Townsley M. Townsley
C. Martin C. Martin
C. Filsfils C. Filsfils
R. Maglione, Ed. R. Maglione, Ed.
Cisco Systems Cisco Systems
March 6, 2015 September 2015
IPv6 SPRING Use Cases IPv6 SPRING Use Cases
draft-ietf-spring-ipv6-use-cases-04 draft-ietf-spring-ipv6-use-cases-05
Abstract Abstract
Source Packet Routing in Networking (SPRING) architecture leverages Source Packet Routing in Networking (SPRING) architecture leverages
the source routing paradigm. A node steers a packet through a the source routing paradigm. A node steers a packet through a
controlled set of instructions, called segments, by prepending the controlled set of instructions, called segments, by prepending the
packet with SPRING header. A segment can represent any instruction, packet with SPRING header. A segment can represent any instruction,
topological or service-based. A segment can have a local semantic to topological or service-based. A segment can have a local semantic to
the SPRING node or global within the SPRING domain. SPRING allows to the SPRING node or global within the SPRING domain. SPRING allows to
enforce a flow through any topological path and service chain while enforce a flow through any topological path and service chain while
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 7, 2015. This Internet-Draft will expire on March 4, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 50 skipping to change at page 2, line 50
the source routing paradigm. An ingress node steers a packet through the source routing paradigm. An ingress node steers a packet through
a controlled set of instructions, called segments, by prepending the a controlled set of instructions, called segments, by prepending the
packet with SPRING header. A segment can represent any instruction, packet with SPRING header. A segment can represent any instruction,
topological or service-based. A segment can represent a local topological or service-based. A segment can represent a local
semantic on the SPRING node, or a global semantic within the SPRING semantic on the SPRING node, or a global semantic within the SPRING
domain. SPRING allows one to enforce a flow through any topological domain. SPRING allows one to enforce a flow through any topological
path and service chain while maintaining per-flow state only at the path and service chain while maintaining per-flow state only at the
ingress node to the SPRING domain. ingress node to the SPRING domain.
The SPRING architecture is described in The SPRING architecture is described in
[I-D.filsfils-spring-segment-routing]. The SPRING control plane is [I-D.ietf-spring-segment-routing]. The SPRING control plane is
agnostic to the dataplane, thus it can be applied to both MPLS and agnostic to the dataplane, thus it can be applied to both MPLS and
IPv6. In case of MPLS the (list of) segment identifiers are carried IPv6. In case of MPLS the (list of) segment identifiers are carried
in the MPLS label stack, while for the IPv6 dataplane, a new type of in the MPLS label stack, while for the IPv6 dataplane, a new type of
routing extension header is required. routing extension header is required.
The details of the new routing extension header are described in The details of the new routing extension header are described in
[I-D.previdi-6man-segment-routing-header] which also covers the [I-D.previdi-6man-segment-routing-header] which also covers the
security considerations and the aspects related to the deprecation of security considerations and the aspects related to the deprecation of
the IPv6 Type 0 Routing Header described in [RFC5095]. the IPv6 Type 0 Routing Header described in [RFC5095].
2. IPv6 SPRING use cases 2. IPv6 SPRING use cases
In today's networks, source routing is typically accomplished by In today's networks, source routing is typically accomplished by
encapsulating IP packets in MPLS LSPs that are signaled via RSVP-TE. encapsulating IP packets in MPLS LSPs that are signaled via RSVP-TE.
Therefore, there are scenarios where it may be possible to run IPv6 Therefore, there are scenarios where it may be possible to run IPv6
on top of MPLS, and as such, the MPLS Segment Routing architecture on top of MPLS, and as such, the MPLS Segment Routing architecture
described in [I-D.filsfils-spring-segment-routing-mpls] could be described in [I-D.ietf-spring-segment-routing-mpls] could be
leveraged to provide SPRING capabilities in an IPv6/MPLS environment. leveraged to provide SPRING capabilities in an IPv6/MPLS environment.
However, there are other cases and/or specific network segments (such However, there are other cases and/or specific network segments (such
as for example the Home Network, the Data Center, etc.) where MPLS as for example the Home Network, the Data Center, etc.) where MPLS
may not be available or deployable for lack of support on network may not be available or deployable for lack of support on network
elements or for an operator's design choice. In such scenarios a elements or for an operator's design choice. In such scenarios a
non-MPLS based solution would be preferred by the network operators non-MPLS based solution would be preferred by the network operators
of such infrastructures. of such infrastructures.
In addition there are cases where the operators could have made the In addition there are cases where the operators could have made the
skipping to change at page 7, line 21 skipping to change at page 7, line 21
the SR SID value to the target pipe. the SR SID value to the target pipe.
2.3. SPRING in the Data Center 2.3. SPRING in the Data Center
A key use case for SPRING is to cause a packet to follow a specific A key use case for SPRING is to cause a packet to follow a specific
path through the network. One can think of the service function path through the network. One can think of the service function
performed at each SPRING node to be forwarding. More complex service performed at each SPRING node to be forwarding. More complex service
functions could be applied to the packet by a SPRING node including functions could be applied to the packet by a SPRING node including
accounting, IDS, load balancing, and fire walling. accounting, IDS, load balancing, and fire walling.
The term "Service Function Chain", as defined in The term "Service Function Chain", as defined in [RFC7498], it is
[I-D.ietf-sfc-problem-statement], it is used to describe an ordered used to describe an ordered set of service functions that must be
set of service functions that must be applied to packets. applied to packets.
A service provider may choose to have these service functions A service provider may choose to have these service functions
performed external to the routing infrastructure, specifically on performed external to the routing infrastructure, specifically on
either dedicated physical servers or within VMs running on a either dedicated physical servers or within VMs running on a
virtualization platform. virtualization platform.
[I-D.ietf-sfc-dc-use-cases] describes use cases that demonstrate the [I-D.ietf-sfc-dc-use-cases] describes use cases that demonstrate the
applicability of Service Function Chaining (SFC) within a data center applicability of Service Function Chaining (SFC) within a data center
environment and provides SFC requirements for data center centric use environment and provides SFC requirements for data center centric use
cases. cases.
skipping to change at page 8, line 37 skipping to change at page 8, line 37
(cache) present in the Segment List a TCP session to port 80 is (cache) present in the Segment List a TCP session to port 80 is
established and if the requested content is found at the cache (cache established and if the requested content is found at the cache (cache
hits scenario) the sequence ends, even if there are more nodes in the hits scenario) the sequence ends, even if there are more nodes in the
list. list.
To achieve the behavior described above, in addition to the Segment To achieve the behavior described above, in addition to the Segment
List, which specifies the path to be followed to explore the List, which specifies the path to be followed to explore the
hierarchic architecture, a way to instruct the node to take a hierarchic architecture, a way to instruct the node to take a
specific action is required. The function to be performed by a specific action is required. The function to be performed by a
service node can be carried into a new header called Network Service service node can be carried into a new header called Network Service
Header (NSH) defined in [I-D.quinn-sfc-nsh]. A Network Service Header (NSH) defined in [I-D.ietf-sfc-nsh]. A Network Service Header
Header (NSH) is metadata added to a packet that is used to create a (NSH) is metadata added to a packet that is used to create a service
service plane. The service header is added by a service plane. The service header is added by a service classification
classification function that determines which packets require function that determines which packets require servicing, and
servicing, and correspondingly which service path to follow to apply correspondingly which service path to follow to apply the appropriate
the appropriate service. service.
In the above example the service to be performed by the service node In the above example the service to be performed by the service node
was to establish a TCP session to port 80, but in other scenarios was to establish a TCP session to port 80, but in other scenarios
different functions may be required. Another example of action to be different functions may be required. Another example of action to be
taken by the service node is the capability to perform taken by the service node is the capability to perform
transformations on payload data, like real-time video transcode transformations on payload data, like real-time video transcode
option (for rate and/or resolution). option (for rate and/or resolution).
The use of SPRING together with the NSH allows building flexible The use of SPRING together with the NSH allows building flexible
service chains where the topological information related to the path service chains where the topological information related to the path
skipping to change at page 10, line 40 skipping to change at page 10, line 40
valuable comments and inputs to this document. valuable comments and inputs to this document.
4. IANA Considerations 4. IANA Considerations
This document does not require any action from IANA. This document does not require any action from IANA.
5. Security Considerations 5. Security Considerations
There are a number of security concerns with source routing at the IP There are a number of security concerns with source routing at the IP
layer [RFC5095]. Security mechanisms applied to Segment Routing over layer [RFC5095]. Security mechanisms applied to Segment Routing over
IPv6 networks are detailed in IPv6 networks are detailed in section 9 of
[I-D.vyncke-6man-segment-routing-security] [I-D.previdi-6man-segment-routing-header]
6. Informative References 6. Informative References
[I-D.baker-openstack-ipv6-model] [I-D.baker-openstack-ipv6-model]
Baker, F., Marino, C., Wells, I., Agarwalla, R., Jeuk, S., Baker, F., Marino, C., Wells, I., Agarwalla, R., Jeuk, S.,
and G. Salgueiro, "A Model for IPv6 Operation in and G. Salgueiro, "A Model for IPv6 Operation in
OpenStack", draft-baker-openstack-ipv6-model-02 (work in OpenStack", draft-baker-openstack-ipv6-model-02 (work in
progress), February 2015. progress), February 2015.
[I-D.filsfils-spring-segment-routing]
Filsfils, C., Previdi, S., Bashandy, A., Decraene, B.,
Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R.,
Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe,
"Segment Routing Architecture", draft-filsfils-spring-
segment-routing-04 (work in progress), July 2014.
[I-D.filsfils-spring-segment-routing-mpls]
Filsfils, C., Previdi, S., Bashandy, A., Decraene, B.,
Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R.,
Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe,
"Segment Routing with MPLS data plane", draft-filsfils-
spring-segment-routing-mpls-03 (work in progress), August
2014.
[I-D.ietf-mif-mpvd-dhcp-support] [I-D.ietf-mif-mpvd-dhcp-support]
Krishnan, S., Korhonen, J., and S. Bhandari, "Support for Krishnan, S., Korhonen, J., and S. Bhandari, "Support for
multiple provisioning domains in DHCPv6", draft-ietf-mif- multiple provisioning domains in DHCPv6", draft-ietf-mif-
mpvd-dhcp-support-01 (work in progress), March 2015. mpvd-dhcp-support-01 (work in progress), March 2015.
[I-D.ietf-mpls-seamless-mpls] [I-D.ietf-mpls-seamless-mpls]
Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz, Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz,
M., and D. Steinberg, "Seamless MPLS Architecture", draft- M., and D. Steinberg, "Seamless MPLS Architecture", draft-
ietf-mpls-seamless-mpls-07 (work in progress), June 2014. ietf-mpls-seamless-mpls-07 (work in progress), June 2014.
[I-D.ietf-sfc-dc-use-cases] [I-D.ietf-sfc-dc-use-cases]
Surendra, S., Tufail, M., Majee, S., Captari, C., and S. Surendra, S., Tufail, M., Majee, S., Captari, C., and S.
Homma, "Service Function Chaining Use Cases In Data Homma, "Service Function Chaining Use Cases In Data
Centers", draft-ietf-sfc-dc-use-cases-02 (work in Centers", draft-ietf-sfc-dc-use-cases-03 (work in
progress), January 2015. progress), July 2015.
[I-D.ietf-sfc-problem-statement] [I-D.ietf-sfc-nsh]
Quinn, P. and T. Nadeau, "Service Function Chaining Quinn, P. and U. Elzur, "Network Service Header", draft-
Problem Statement", draft-ietf-sfc-problem-statement-13 ietf-sfc-nsh-01 (work in progress), July 2015.
(work in progress), February 2015.
[I-D.ietf-spring-problem-statement] [I-D.ietf-spring-problem-statement]
Previdi, S., Filsfils, C., Decraene, B., Litkowski, S., Previdi, S., Filsfils, C., Decraene, B., Litkowski, S.,
Horneffer, M., and R. Shakir, "SPRING Problem Statement Horneffer, M., and R. Shakir, "SPRING Problem Statement
and Requirements", draft-ietf-spring-problem-statement-03 and Requirements", draft-ietf-spring-problem-statement-04
(work in progress), October 2014. (work in progress), April 2015.
[I-D.ietf-spring-segment-routing]
Filsfils, C., Previdi, S., Decraene, B., Litkowski, S.,
and r. rjs@rob.sh, "Segment Routing Architecture", draft-
ietf-spring-segment-routing-04 (work in progress), July
2015.
[I-D.ietf-spring-segment-routing-mpls]
Filsfils, C., Previdi, S., Bashandy, A., Decraene, B.,
Litkowski, S., Horneffer, M., Shakir, R., Tantsura, J.,
and E. Crabbe, "Segment Routing with MPLS data plane",
draft-ietf-spring-segment-routing-mpls-01 (work in
progress), May 2015.
[I-D.lamparter-rtgwg-dst-src-routing] [I-D.lamparter-rtgwg-dst-src-routing]
Lamparter, D., "Destination/Source Routing", draft- Lamparter, D., "Destination/Source Routing", draft-
lamparter-rtgwg-dst-src-routing-00 (work in progress), lamparter-rtgwg-dst-src-routing-01 (work in progress),
October 2014. June 2015.
[I-D.previdi-6man-segment-routing-header] [I-D.previdi-6man-segment-routing-header]
Previdi, S., Filsfils, C., Field, B., and I. Leung, "IPv6 Previdi, S., Filsfils, C., Field, B., Leung, I., Vyncke,
Segment Routing Header (SRH)", draft-previdi-6man-segment- E., and D. Lebrun, "IPv6 Segment Routing Header (SRH)",
routing-header-05 (work in progress), January 2015. draft-previdi-6man-segment-routing-header-07 (work in
progress), July 2015.
[I-D.quinn-sfc-nsh]
Quinn, P., Guichard, J., Surendra, S., Smith, M.,
Henderickx, W., Nadeau, T., Agarwal, P., Manur, R.,
Chauhan, A., Halpern, J., Majee, S., Elzur, U., Melman,
D., Garg, P., McConnell, B., Wright, C., and K. Kevin,
"Network Service Header", draft-quinn-sfc-nsh-07 (work in
progress), February 2015.
[I-D.vyncke-6man-segment-routing-security]
Vyncke, E., Previdi, S., and D. Lebrun, "IPv6 Segment
Routing Security Considerations", draft-vyncke-6man-
segment-routing-security-02 (work in progress), February
2015.
[RFC4798] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, [RFC4798] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur,
"Connecting IPv6 Islands over IPv4 MPLS Using IPv6 "Connecting IPv6 Islands over IPv4 MPLS Using IPv6
Provider Edge Routers (6PE)", RFC 4798, February 2007. Provider Edge Routers (6PE)", RFC 4798,
DOI 10.17487/RFC4798, February 2007,
<http://www.rfc-editor.org/info/rfc4798>.
[RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation
of Type 0 Routing Headers in IPv6", RFC 5095, December of Type 0 Routing Headers in IPv6", RFC 5095,
2007. DOI 10.17487/RFC5095, December 2007,
<http://www.rfc-editor.org/info/rfc5095>.
[RFC7439] George, W. and C. Pignataro, "Gap Analysis for Operating [RFC7439] George, W., Ed. and C. Pignataro, Ed., "Gap Analysis for
IPv6-Only MPLS Networks", RFC 7439, January 2015. Operating IPv6-Only MPLS Networks", RFC 7439,
DOI 10.17487/RFC7439, January 2015,
<http://www.rfc-editor.org/info/rfc7439>.
[RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for
Service Function Chaining", RFC 7498,
DOI 10.17487/RFC7498, April 2015,
<http://www.rfc-editor.org/info/rfc7498>.
Authors' Addresses Authors' Addresses
John Brzozowski John Brzozowski
Comcast Comcast
Email: john_brzozowski@cable.comcast.com Email: john_brzozowski@cable.comcast.com
John Leddy John Leddy
Comcast Comcast
 End of changes. 18 change blocks. 
64 lines changed or deleted 58 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/