< draft-ietf-sfc-hierarchical-07.txt		draft-ietf-sfc-hierarchical-08.txt >
	Service Function Chaining D. Dolson		Service Function Chaining D. Dolson
	Internet-Draft		Internet-Draft Sandvine
	Intended status: Informational S. Homma		Intended status: Informational S. Homma
	Expires: August 22, 2018 NTT		Expires: October 30, 2018 NTT
	D. Lopez		D. Lopez
	Telefonica I+D		Telefonica I+D
	M. Boucadair		M. Boucadair
	Orange		Orange
	2 18, 2018		April 28, 2018
	Hierarchical Service Function Chaining (hSFC)		Hierarchical Service Function Chaining (hSFC)
	draft-ietf-sfc-hierarchical-07		draft-ietf-sfc-hierarchical-08
	Abstract		Abstract
	Hierarchical Service Function Chaining (hSFC) is a network		Hierarchical Service Function Chaining (hSFC) is a network
	architecture allowing an organization to decompose a large-scale		architecture allowing an organization to decompose a large-scale
	network into multiple domains of administration.		network into multiple domains of administration.
	The goals of hSFC are to make a large-scale network easier to reason		The goals of hSFC are to make a large-scale network easier to reason
	about, simpler to control and to support independent functional		about, simpler to control and to support independent functional
	groups within large network operators.		groups within large network operators.
	skipping to change at page 1, line 41 ¶		skipping to change at page 1, line 41 ¶
	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 https://datatracker.ietf.org/drafts/current/.		Drafts is at https://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 August 22, 2018.		This Internet-Draft will expire on October 30, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2018 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
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://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 18 ¶		skipping to change at page 2, line 18 ¶
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Hierarchical Service Function Chaining (hSFC) . . . . . . . . 4		2. Hierarchical Service Function Chaining (hSFC) . . . . . . . . 4
	2.1. Top Level . . . . . . . . . . . . . . . . . . . . . . . . 4		2.1. Top Level . . . . . . . . . . . . . . . . . . . . . . . . 4
	2.2. Lower Levels . . . . . . . . . . . . . . . . . . . . . . 6		2.2. Lower Levels . . . . . . . . . . . . . . . . . . . . . . 6
	3. Internal Boundary Node (IBN) . . . . . . . . . . . . . . . . 8		3. Internal Boundary Node (IBN) . . . . . . . . . . . . . . . . 7
	3.1. IBN Path Configuration . . . . . . . . . . . . . . . . . 8		3.1. IBN Path Configuration . . . . . . . . . . . . . . . . . 8
	3.1.1. Flow-Stateful IBN . . . . . . . . . . . . . . . . . . 9		3.1.1. Flow-Stateful IBN . . . . . . . . . . . . . . . . . . 8
	3.1.2. Encoding Upper-Level Paths in Metadata . . . . . . . 10		3.1.2. Encoding Upper-Level Paths in Metadata . . . . . . . 10
	3.1.3. Using Unique Paths per Upper-Level Path . . . . . . . 11		3.1.3. Using Unique Paths per Upper-Level Path . . . . . . . 11
	3.1.4. Nesting Upper-Level NSH within Lower-Level NSH . . . 11		3.1.4. Nesting Upper-Level NSH within Lower-Level NSH . . . 11
	3.1.5. Stateful/Metadata Hybrid . . . . . . . . . . . . . . 12		3.1.5. Stateful/Metadata Hybrid . . . . . . . . . . . . . . 12
	3.2. Gluing Levels Together . . . . . . . . . . . . . . . . . 14		3.2. Gluing Levels Together . . . . . . . . . . . . . . . . . 13
	3.3. Decrementing Service Index . . . . . . . . . . . . . . . 14		3.3. Decrementing Service Index . . . . . . . . . . . . . . . 14
	3.4. Managing TTL . . . . . . . . . . . . . . . . . . . . . . 14		3.4. Managing TTL . . . . . . . . . . . . . . . . . . . . . . 14
	4. Sub-domain Classifier . . . . . . . . . . . . . . . . . . . . 15		4. Sub-domain Classifier . . . . . . . . . . . . . . . . . . . . 15
	5. Control Plane Elements . . . . . . . . . . . . . . . . . . . 15		5. Control Plane Elements . . . . . . . . . . . . . . . . . . . 15
	6. Extension for Adapting to NSH-Unaware Service Functions . . . 16		6. Extension for Adapting to NSH-Unaware Service Functions . . . 16
	6.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 17		6.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 17
	6.2. Requirements for IBN . . . . . . . . . . . . . . . . . . 18		6.2. Requirements for IBN . . . . . . . . . . . . . . . . . . 18
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 19		9. Security Considerations . . . . . . . . . . . . . . . . . . . 19
	9.1. Control Plane . . . . . . . . . . . . . . . . . . . . . . 20		9.1. Control Plane . . . . . . . . . . . . . . . . . . . . . . 20
	9.2. Infinite Forwarding Loops . . . . . . . . . . . . . . . . 20		9.2. Infinite Forwarding Loops . . . . . . . . . . . . . . . . 20
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 20		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
	10.1. Normative References . . . . . . . . . . . . . . . . . . 20		10.1. Normative References . . . . . . . . . . . . . . . . . . 20
	10.2. Informative References . . . . . . . . . . . . . . . . . 20		10.2. Informative References . . . . . . . . . . . . . . . . . 20
	Appendix A. Examples of Hierarchical Service Function Chaining . 22		Appendix A. Examples of Hierarchical Service Function Chaining . 21
	A.1. Reducing the Number of Service Function Paths . . . . . . 22		A.1. Reducing the Number of Service Function Paths . . . . . . 21
	A.2. Managing a Distributed Data-Center Network . . . . . . . 24		A.2. Managing a Distributed Data-Center Network . . . . . . . 24
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
	1. Introduction		1. Introduction
	Service Function Chaining (SFC) is a technique for prescribing		Service Function Chaining (SFC) is a technique for prescribing
	differentiated traffic forwarding policies within an SFC-enabled		differentiated traffic forwarding policies within an SFC-enabled
	domain. The SFC architecture is described in detail in [RFC7665],		domain. The SFC architecture is described in detail in [RFC7665],
	and is not repeated here.		and is not repeated here.
	This document focuses on the difficult problem of implementing SFC		This document focuses on the difficult problem of implementing SFC
	across a large, geographically dispersed network, potentially		across a large, geographically dispersed network, potentially
	comprised of millions of hosts and thousands of network forwarding		comprised of millions of hosts and thousands of network forwarding
	elements, and which may involve multiple operational teams (with		elements, and which may involve multiple operational teams (with
	varying functional responsibilities). We recognize that some		varying functional responsibilities). We recognize that some
	stateful Service Functions (SFs) require bidirectional traffic for		stateful Service Functions (SFs) require bidirectional traffic for
	transport-layer sessions (e.g., NATs, firewalls). We assume that		transport-layer sessions (e.g., NATs, firewalls). We assume that
	some Service Function Paths (SFPs) need to be selected on the basis		some Service Function Paths (SFPs) need to be selected on the basis
	of application-specific data visible to the network, with transport-		of transport-layer coordinate (typically, the 5-tuple of source IP
	layer coordinate (typically, the 5-tuple (source IP address, source		address, source port number, destination IP address, destination port
	port number, destination IP address, destination port number,		number, and transport protocol) stickiness to specific stateful SF
	transport protocol)) stickiness to specific stateful SF instances.		instances.
	Difficult problems are often made easier by decomposing them in a		Difficult problems are often made easier by decomposing them in a
	hierarchical (nested) manner. So instead of considering a single SFC		hierarchical (nested) manner. So instead of considering a single SFC
	Control Plane ([I-D.ietf-sfc-control-plane]) that can manage (create,		Control Plane that can manage (create, withdraw, supervise, etc.)
	withdraw, supervise, etc.) complete SFPs from one end of the network		complete SFPs from one end of the network to the other, we decompose
	to the other, we decompose the network into smaller domains operated		the network into smaller domains operated by as many SFC control
	by as many SFC control plane components (under the same		plane components (under the same administrative entity).
	administrative entity). Coordination between such components is		Coordination between such components is further discussed in the
	further discussed in the document.		document.
	Each sub-domain may support a subset of the network applications or a		Each sub-domain may support a subset of the network applications or a
	subset of the users. Decomposing a network into multiple SFC-enabled		subset of the users. Decomposing a network should be done with care
	domains should permit end-to-end visibility of SFs and SFPs. Also,		to ease monitoring and troubleshooting of the network and services as
	decomposing should be done with care to ease monitoring and		a whole. The criteria for decomposing a domain into multiple SFC-
	troubleshooting of the network and services as a whole. The criteria		enabled sub-domains are beyond the scope of this document. These
	for decomposing a domain into multiple SFC-enabled sub-domains are		criteria are deployment-specific.
	beyond the scope of this document. These criteria are deployment-
	specific.
	An example of simplifying a network by using multiple SFC-enabled		An example of simplifying a network by using multiple SFC-enabled
	domains is further discussed in [I-D.ietf-sfc-dc-use-cases].		domains is further discussed in [I-D.ietf-sfc-dc-use-cases].
	We assume the SFC-aware nodes use NSH [RFC8300] or a similar		We assume the SFC-aware nodes use NSH [RFC8300] or a similar labeling
	labeling mechanism. Sample examples are described in Appendix A.		mechanism. Sample examples are described in Appendix A.
	The "domains" discussed in this document are assumed to be under the		The "domains" discussed in this document are assumed to be under the
	control of a single organization (an operator, typically), such that		control of a single organization (an operator, typically), such that
	there is a strong trust relationship between the domains. The		there is a strong trust relationship between the domains. The
	intention of creating multiple domains is to improve the ability to		intention of creating multiple domains is to improve the ability to
	operate a network. It is outside of the scope of the document to		operate a network. It is outside of the scope of the document to
	consider domains operated by different organizations or to dwell on		consider domains operated by different organizations or to dwell on
	inter-operator considerations.		inter-operator considerations.
			We introduce the concept of an Internal Boundary Node (IBN) that acts
			as a gateway between the levels of the hierarchy. We also discuss
			options for realizing this function.
	2. Hierarchical Service Function Chaining (hSFC)		2. Hierarchical Service Function Chaining (hSFC)
	A hierarchy has multiple levels: the top-most level encompasses the		A hierarchy has multiple levels: the top-most level encompasses the
	entire network domain to be managed, and lower levels encompass		entire network domain to be managed, and lower levels encompass
	portions of the network. These levels are discussed in the following		portions of the network. These levels are discussed in the following
	sub-sections.		sub-sections.
	2.1. Top Level		2.1. Top Level
	Considering the example depicted in Figure 1, a top-level network		Considering the example depicted in Figure 1, a top-level network
	skipping to change at page 5, line 31 ¶		skipping to change at page 4, line 50 ¶
	|		|
	+----+-------+		+----+-------+
	|Sub-domain#2|		|Sub-domain#2|
	| in DC2 |		| in DC2 |
	+------------+		+------------+
	Legend:		Legend:
	SC#1: Service Chain 1		SC#1: Service Chain 1
	DC: Data Center		DC: Data Center
			Figure 1: Network-wide view of top level of hierarchy
	One path is shown from edge classifier to SFF1 to Sub-domain#1		One path is shown from edge classifier to SFF1 to Sub-domain#1
	(residing in data-center1) to SFF1 to SFF2 (residing in data-center		(residing in data-center1) to SFF1 to SFF2 (residing in data-center
	2) to Sub-domain#2 to SFF2 to network egress.		2) to Sub-domain#2 to SFF2 to network egress.
	Figure 1: Network-wide view of top level of hierarchy
	For the sake of clarity, components of the underlay network are not		For the sake of clarity, components of the underlay network are not
	shown; an underlay network is assumed to provide connectivity between		shown; an underlay network is assumed to provide connectivity between
	SFC data plane components.		SFC data plane components.
	Top-level SFPs carry packets from classifiers through a set of SFFs		Top-level SFPs carry packets from classifiers through a set of SFFs
	and sub-domains, with the operations within sub-domains being opaque		and sub-domains, with the operations within sub-domains being opaque
	to the higher levels.		to the higher levels.
	We expect the system to include a top-level control plane having		We expect the system to include a top-level control plane having
	responsibility for configuring forwarding policies and traffic		responsibility for configuring forwarding policies and traffic
	classification rules (see for example, [I-D.ietf-sfc-control-plane]).		classification rules.
	The top-level Service Chaining control plane manages end-to-end		The top-level Service Chaining control plane manages end-to-end
	service chains and associated service function paths from network		service chains and associated service function paths from network
	edge points to sub-domains and configures top-level classifiers at a		edge points to sub-domains and configures top-level classifiers at a
	coarse level (e.g., based on source or destination host) to forward		coarse level (e.g., based on source or destination host) to forward
	traffic along paths that will transit across appropriate sub-domains.		traffic along paths that will transit across appropriate sub-domains.
	Figure 1 shows one possible service chain passing from edge, through		Figure 1 shows one possible service chain passing from edge, through
	two sub-domains, to network egress. The top-level control plane does		two sub-domains, to network egress. The top-level control plane does
	not configure traffic classification rules or forwarding policies		not configure traffic classification rules or forwarding policies
	skipping to change at page 20, line 20 ¶		skipping to change at page 20, line 20 ¶
	All of the systems and protocols must be secure from modification by		All of the systems and protocols must be secure from modification by
	untrusted agents.		untrusted agents.
	9.1. Control Plane		9.1. Control Plane
	Security considerations related to the control plane should be		Security considerations related to the control plane should be
	discussed in the corresponding control specification documents (e.g.,		discussed in the corresponding control specification documents (e.g.,
	[I-D.ietf-bess-nsh-bgp-control-plane],		[I-D.ietf-bess-nsh-bgp-control-plane],
	[I-D.wu-pce-traffic-steering-sfc], or [I-D.maglione-sfc-nsh-radius]).		[I-D.wu-pce-traffic-steering-sfc], or [I-D.maglione-sfc-nsh-radius]).
	Generic security considerations related to the control plane are
	discussed in [I-D.ietf-sfc-control-plane]. These considerations
	apply for both high-level and low-level domains.
	9.2. Infinite Forwarding Loops		9.2. Infinite Forwarding Loops
	Distributing policies among multiple domains may lead to forwarding		Distributing policies among multiple domains may lead to forwarding
	loops. NSH supports the ability to detect loops (Section 3.3 and		loops. NSH supports the ability to detect loops (Section 3.3 and
	Section 3.4), but means to ensure the consistency of the policies		Section 3.4), but means to ensure the consistency of the policies
	should be enabled at all levels of a domain. Within the context of		should be enabled at all levels of a domain. Within the context of
	hSFC, it is the responsibility of the Control Elements at all levels		hSFC, it is the responsibility of the Control Elements at all levels
	to prevent such (unwanted) loops.		to prevent such (unwanted) loops.
	10. References		10. References
	skipping to change at page 21, line 20 ¶		skipping to change at page 21, line 15 ¶
	[I-D.homma-sfc-forwarding-methods-analysis]		[I-D.homma-sfc-forwarding-methods-analysis]
	Homma, S., Naito, K., Lopez, D., Stiemerling, M., Dolson,		Homma, S., Naito, K., Lopez, D., Stiemerling, M., Dolson,
	D., Gorbunov, A., Leymann, N., Bottorff, P., and d.		D., Gorbunov, A., Leymann, N., Bottorff, P., and d.
	don.fedyk@hpe.com, "Analysis on Forwarding Methods for		don.fedyk@hpe.com, "Analysis on Forwarding Methods for
	Service Chaining", draft-homma-sfc-forwarding-methods-		Service Chaining", draft-homma-sfc-forwarding-methods-
	analysis-05 (work in progress), January 2016.		analysis-05 (work in progress), January 2016.
	[I-D.ietf-bess-nsh-bgp-control-plane]		[I-D.ietf-bess-nsh-bgp-control-plane]
	Farrel, A., Drake, J., Rosen, E., Uttaro, J., and L.		Farrel, A., Drake, J., Rosen, E., Uttaro, J., and L.
	Jalil, "BGP Control Plane for NSH SFC", draft-ietf-bess-		Jalil, "BGP Control Plane for NSH SFC", draft-ietf-bess-
	nsh-bgp-control-plane-02 (work in progress), October 2017.		nsh-bgp-control-plane-03 (work in progress), March 2018.
	[I-D.ietf-sfc-control-plane]
	Boucadair, M., "Service Function Chaining (SFC) Control
	Plane Components & Requirements", draft-ietf-sfc-control-
	plane-08 (work in progress), October 2016.
	[I-D.ietf-sfc-dc-use-cases]		[I-D.ietf-sfc-dc-use-cases]
	Kumar, S., Tufail, M., Majee, S., Captari, C., and S.		Kumar, 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-06 (work in		Centers", draft-ietf-sfc-dc-use-cases-06 (work in
	progress), February 2017.		progress), February 2017.
	[I-D.maglione-sfc-nsh-radius]		[I-D.maglione-sfc-nsh-radius]
	Maglione, R., Trueba, G., and C. Pignataro, "RADIUS		Maglione, R., Trueba, G., and C. Pignataro, "RADIUS
	Attributes for NSH", draft-maglione-sfc-nsh-radius-01		Attributes for NSH", draft-maglione-sfc-nsh-radius-01
	skipping to change at page 26, line 8 ¶		skipping to change at page 26, line 8 ¶
	Conversely, if using hierarchical SFC, each data center can be		Conversely, if using hierarchical SFC, each data center can be
	managed independently to significantly reduce management complexity.		managed independently to significantly reduce management complexity.
	SFPs between data centers can represent abstract notions without		SFPs between data centers can represent abstract notions without
	regard to details within data centers. Independent controllers can		regard to details within data centers. Independent controllers can
	be used for the top level (getting packets to pass the correct data		be used for the top level (getting packets to pass the correct data
	centers) and local levels (getting packets to specific SF instances).		centers) and local levels (getting packets to specific SF instances).
	Authors' Addresses		Authors' Addresses
	David Dolson		David Dolson
	Waterloo		Sandvine
			Waterloo, ON
	Canada		Canada
	Email: ddolson@golden.net		Email: ddolson@acm.org
	Shunsuke Homma		Shunsuke Homma
	NTT, Corp.		NTT, Corp.
	3-9-11, Midori-cho		3-9-11, Midori-cho
	Musashino-shi, Tokyo 180-8585		Musashino-shi, Tokyo 180-8585
	Japan		Japan
	Email: homma.shunsuke@lab.ntt.co.jp		Email: homma.shunsuke@lab.ntt.co.jp
	Diego R. Lopez		Diego R. Lopez
End of changes. 21 change blocks.
	44 lines changed or deleted		38 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/