Diff: draft-ietf-teas-actn-requirements-07.txt - draft-ietf-teas-actn-requirements-08.txt

	draft-ietf-teas-actn-requirements-07.txt	draft-ietf-teas-actn-requirements-08.txt
	TEAS Working Group Young Lee (Editor)	TEAS Working Group Young Lee (Editor)

	Dhruv Dhody
	Internet Draft Huawei	Internet Draft Huawei

		Intended status: Informational
	Intended status: Informational Sergio Belotti
	Nokia
	Expires: April 27, 2018
	Khuzema Pithewan
	Infinera

	Daniele Ceccarelli	Daniele Ceccarelli

	Ericsson	Expires July 25, 2018. Ericsson

	Takuya Miyasaka	Takuya Miyasaka
	KDDI	KDDI

	Jong Yoon Shin	Jong Yoon Shin
	SKT	SKT

	Kwang-koog Lee	Kwang-koog Lee
	KT	KT


	October 27, 2017	January 25, 2018

	Requirements for Abstraction and Control of TE Networks	Requirements for Abstraction and Control of TE Networks


	draft-ietf-teas-actn-requirements-07.txt	draft-ietf-teas-actn-requirements-08.txt

	Abstract	Abstract

	This document provides a set of requirements for abstraction and	This document provides a set of requirements for abstraction and
	control of Traffic Engineering networks to facilitate virtual	control of Traffic Engineering networks to facilitate virtual
	network operation via the creation of a single virtualized network	network operation via the creation of a single virtualized network
	or a seamless service. This supports operators in viewing and	or a seamless service. This supports operators in viewing and
	controlling different domains (at any dimension: applied technology,	controlling different domains (at any dimension: applied technology,
	administrative zones, or vendor-specific technology islands) as a	administrative zones, or vendor-specific technology islands) as a
	single virtualized network.	single virtualized network.

	skipping to change at page 2, line 21 ¶	skipping to change at page 2, line 16 ¶
	months and may be updated, replaced, or obsoleted by other documents	months and may be updated, replaced, or obsoleted by other documents
	at any time. It is inappropriate to use Internet-Drafts as	at any time. It is inappropriate to use Internet-Drafts as
	reference material or to cite them other than as "work in progress."	reference material or to cite them other than as "work in progress."

	The list of current Internet-Drafts can be accessed at	The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt	http://www.ietf.org/ietf/1id-abstracts.txt

	The list of Internet-Draft Shadow Directories can be accessed at	The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.	http://www.ietf.org/shadow.html.


	This Internet-Draft will expire on April 27, 2018.	This Internet-Draft will expire on July 25, 2018.

	Copyright Notice	Copyright Notice


	Copyright (c) 2017 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
	(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
	carefully, as they describe your rights and restrictions with	carefully, as they describe your rights and restrictions with
	respect to this document. Code Components extracted from this	respect to this document. Code Components extracted from this
	document must include Simplified BSD License text as described in	document must include Simplified BSD License text as described in
	Section 4.e of the Trust Legal Provisions and are provided without	Section 4.e of the Trust Legal Provisions and are provided without
	warranty as described in the Simplified BSD License.	warranty as described in the Simplified BSD License.

	Table of Contents	Table of Contents


	1. Introduction...................................................3	1. Introduction...................................................2
	2. High-level ACTN requirements...................................4	2. High-level ACTN requirements...................................4
	2.1. Service-Specific Requirements.............................4	2.1. Service-Specific Requirements.............................4
	2.2. Network-Related Requirements..............................7	2.2. Network-Related Requirements..............................7
	3. References.....................................................9	3. References.....................................................9
	3.1. Normative References......................................9	3.1. Normative References......................................9
	3.2. Informative References....................................9	3.2. Informative References....................................9
	4. Contributors..................................................10	4. Contributors..................................................10
	Authors' Addresses...............................................11	Authors' Addresses...............................................11

	1. Introduction	1. Introduction

	This document provides a set of requirements for Abstraction and	This document provides a set of requirements for Abstraction and
	Control of Traffic Engineering (TE) Networks (ACTN) identified in	Control of Traffic Engineering (TE) Networks (ACTN) identified in

	various use-cases specified by the operators. [ACTN-frame] defines	various use-cases specified by the operators. [ACTN-Frame] defines
	the base reference architecture and terminology.	the base reference architecture and terminology.

	ACTN refers to the set of virtual network service operations needed	ACTN refers to the set of virtual network service operations needed
	to orchestrate, control and manage large-scale multi-domain TE	to orchestrate, control and manage large-scale multi-domain TE
	networks so as to facilitate network programmability, automation,	networks so as to facilitate network programmability, automation,
	efficient resource sharing, and end-to-end virtual service aware	efficient resource sharing, and end-to-end virtual service aware
	connectivity.	connectivity.

	These operations are summarized as follows:	These operations are summarized as follows:


	skipping to change at page 4, line 12 ¶	skipping to change at page 4, line 10 ¶
	- Provision via a data model of a computation scheme and virtual	- Provision via a data model of a computation scheme and virtual
	control capability to customers who request virtual network	control capability to customers who request virtual network
	services. Note that these customers could, themselves, be	services. Note that these customers could, themselves, be
	service providers.	service providers.

	ACTN solutions will build on, and extend, existing TE constructs and	ACTN solutions will build on, and extend, existing TE constructs and
	TE mechanisms wherever possible and appropriate. Support for	TE mechanisms wherever possible and appropriate. Support for
	controller-based approaches is specifically included in the possible	controller-based approaches is specifically included in the possible
	solution set.	solution set.


		1.1. Requirements Language

		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
		"OPTIONAL" in this document are to be interpreted as described in
		BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
		capitals, as shown here.

	2. High-level ACTN requirements	2. High-level ACTN requirements

	This section provides a summary of use-cases in terms of two	This section provides a summary of use-cases in terms of two
	categories: (i) service-specific requirements; (ii) network-related	categories: (i) service-specific requirements; (ii) network-related
	requirements. All these requirements are specified by operators that	requirements. All these requirements are specified by operators that
	are interested in implementing ACTN.	are interested in implementing ACTN.

	Service-specific requirements listed below are uniquely applied to	Service-specific requirements listed below are uniquely applied to
	the work scope of ACTN. Service-specific requirements are related to	the work scope of ACTN. Service-specific requirements are related to
	the virtual service coordination function. These requirements are	the virtual service coordination function. These requirements are

	related to customer's VNs in terms of service policy associated with	related to customer's Virtual Networks (VN) in terms of service
	VNs such as service performance objectives, VN endpoint location	policy associated with VNs such as service performance objectives,
	information for certain required service specific functions (e.g.,	VN endpoint location information for certain required service
	security and others), VN survivability requirement, or dynamic	specific functions (e.g., security and others), VN survivability
	service control policy, etc.	requirement, or dynamic service control policy, etc.

	Network-related requirements are related to and necessary for	Network-related requirements are related to and necessary for
	coherent/seamless for the virtual network operation function. These	coherent/seamless for the virtual network operation function. These
	requirements are related to multi-domain and multi-layer signaling,	requirements are related to multi-domain and multi-layer signaling,
	routing, protection/restoration and re-optimization/re-grooming,	routing, protection/restoration and re-optimization/re-grooming,
	etc.	etc.

	Each requirement specified in Sections 2.1 and 2.2 is derived from	Each requirement specified in Sections 2.1 and 2.2 is derived from
	ACTN use-cases: [CHENG], [DHODY], [FANG], [KLEE], [KUMAKI], [LOPEZ],	ACTN use-cases: [CHENG], [DHODY], [FANG], [KLEE], [KUMAKI], [LOPEZ],
	[SHIN], [XU], [XU2], and [SUZUKI].	[SHIN], [XU], [XU2], and [SUZUKI].

	skipping to change at page 5, line 18 ¶	skipping to change at page 5, line 22 ¶
	virtual links, etc.). The customer MUST be able to express VNS	virtual links, etc.). The customer MUST be able to express VNS
	policy that captures Service Level Agreements (SLA) associated with	policy that captures Service Level Agreements (SLA) associated with
	virtual network service (e.g., Endpoint selection policy, routing	virtual network service (e.g., Endpoint selection policy, routing
	policy, time-related policy, etc.)	policy, time-related policy, etc.)

	Reference: [KLEE], [LOPEZ], [SHIN], [DHODY], [FANG].	Reference: [KLEE], [LOPEZ], [SHIN], [DHODY], [FANG].

	2. Requirement 2: Virtual Network Service Query	2. Requirement 2: Virtual Network Service Query

	Customer SHOULD be able to request VNS Query ("Can you give me these	Customer SHOULD be able to request VNS Query ("Can you give me these

	VN(s)?") that includes the following parameters:	VN(s)?") that include the following parameters:

	- VN type: various VN types defined by the customer (e.g.,	- VN type: various VN types defined by the customer (e.g.,
	path, graph, etc.)	path, graph, etc.)
	- VN end-points (Customer Edge interface information)	- VN end-points (Customer Edge interface information)
	- VN Topology Service-specific Objective Functions (e.g.,	- VN Topology Service-specific Objective Functions (e.g.,
	maximum bandwidth, minimum latency, minimum hops, etc. and	maximum bandwidth, minimum latency, minimum hops, etc. and
	any combination of them).	any combination of them).
	- VN constraints requirement (e.g., Maximum Latency threshold,	- VN constraints requirement (e.g., Maximum Latency threshold,
	Minimum Bandwidth, etc.)	Minimum Bandwidth, etc.)


	skipping to change at page 6, line 27 ¶	skipping to change at page 6, line 29 ¶
	parameters during the lifecycle of the instantiated VNS.	parameters during the lifecycle of the instantiated VNS.

	Reference: [FANG], [KUMAKI], [LOPEZ], [DHODY], [FANG], [KLEE].	Reference: [FANG], [KUMAKI], [LOPEZ], [DHODY], [FANG], [KLEE].

	5. Requirement 5: VNS Isolation	5. Requirement 5: VNS Isolation

	Customer's VN should be able to use arbitrary network topology,	Customer's VN should be able to use arbitrary network topology,
	routing, or forwarding functions as well as customized control	routing, or forwarding functions as well as customized control
	mechanisms independent of the underlying physical network and of	mechanisms independent of the underlying physical network and of
	other coexisting virtual networks. Other customers' VNS operation	other coexisting virtual networks. Other customers' VNS operation

	MUST not impact a particular customer's VNS network operation.	MUST NOT impact a particular customer's VNS network operation.

	Reference: [KUMAKI], [FANG], [LOPEZ]	Reference: [KUMAKI], [FANG], [LOPEZ]

	6. Requirement 6: Multi-Destination Coordination	6. Requirement 6: Multi-Destination Coordination

	Customer MUST be able to define and convey service/preference	Customer MUST be able to define and convey service/preference
	requirements for multi-destination applications (e.g., set of	requirements for multi-destination applications (e.g., set of
	candidate sources/destinations, thresholds for load balancing,	candidate sources/destinations, thresholds for load balancing,
	disaster recovery policy, etc.)	disaster recovery policy, etc.)


	skipping to change at page 7, line 34 ¶	skipping to change at page 7, line 34 ¶

	Reference: [KUMAKI], [FANG], [LOPEZ]	Reference: [KUMAKI], [FANG], [LOPEZ]

	2.2. Network-Related Requirements	2.2. Network-Related Requirements

	1. Requirement 1: Virtual Network Service Coordination	1. Requirement 1: Virtual Network Service Coordination

	Network MUST be able to support the following VNS operations:	Network MUST be able to support the following VNS operations:

	- VNS Delete: Upon customer's VNS deletion request, network	- VNS Delete: Upon customer's VNS deletion request, network

	MUST be able to delete VNS.	MUST be able to delete VNS.
	- VNS Modify: Upon customer's VNS modification request,	- VNS Modify: Upon customer's VNS modification request,

	network MUST be able to modify VNS related parameters during	network MUST be able to modify VNS related parameters during
	the lifecycle of the instantiated VNS.	the lifecycle of the instantiated VNS.
	- VNS Update: Upon customer's VNS performance monitoring	- VNS Monitor: Upon customer's VNS performance monitoring
	setup, the network MUST be able to support VNS level	setup, the network MUST be able to support VNS level
	Operations, Administration and Management (OAM) Monitoring	Operations, Administration and Management (OAM) Monitoring
	under policy agreement.	under policy agreement.

	Reference: [FANG], [KUMAKI], [LOPEZ], [DHODY], [FANG], [KLEE].	Reference: [FANG], [KUMAKI], [LOPEZ], [DHODY], [FANG], [KLEE].

	2. Requirement 2: Topology Abstraction Capability	2. Requirement 2: Topology Abstraction Capability

	The network MUST be capable of managing its networks based on the	The network MUST be capable of managing its networks based on the
	principle of topology abstraction to be able to scale multi-layer,	principle of topology abstraction to be able to scale multi-layer,
	multi-domain networks.	multi-domain networks.

	Reference: [KLEE], [LOPEZ], [DHODY], [CHENG].	Reference: [KLEE], [LOPEZ], [DHODY], [CHENG].

	skipping to change at page 9, line 11 ¶	skipping to change at page 9, line 11 ¶
	- Fast convergence of abstracted topologies upon changes due	- Fast convergence of abstracted topologies upon changes due
	to failure or reconfiguration across the network domain	to failure or reconfiguration across the network domain
	view, the multi-domain network view and the customer view.	view, the multi-domain network view and the customer view.

	- Large-scale VNS operation (e.g., the ability to query tens	- Large-scale VNS operation (e.g., the ability to query tens
	of thousands of nodes, and to examine tens of thousands of	of thousands of nodes, and to examine tens of thousands of
	connectivity requests) for time-sensitive applications.	connectivity requests) for time-sensitive applications.

	Reference: [SHIN], [XU], [XU2], [KLEE], [KUMAKI], [SUZUKI].	Reference: [SHIN], [XU], [XU2], [KLEE], [KUMAKI], [SUZUKI].


	3. References	3. Security Considerations


	3.1. Normative References	The ACTN requirements described in this document do not directly
		bear specific security concerns. When these requirements are
		implemented in specific interfaces, securing the request and control
		of resources, confidentially of the information, and availability of
		function, should all be critical security considerations.

		4. IANA Considerations

		This document has no actions for IANA.

		5. References

		5.1. Normative References

	[ACTN-Frame] D. Ceccarelli, et al., "Framework for Abstraction and	[ACTN-Frame] D. Ceccarelli, et al., "Framework for Abstraction and
	Control of Transport Networks", draft-ietf-teas-actn-	Control of Transport Networks", draft-ietf-teas-actn-
	framework, work in progress.	framework, work in progress.


	3.2. Informative References	5.2. Informative References

		[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
		Requirement Levels", RFC 2119, March 1997.

		[RFC8174] B. Leiba, "Ambiguity of Uppercase vs Lowercase in RFC 2119
		Key Words", RFC 8174, May 2017.

	[CHENG] W. Cheng, et. al., "ACTN Use-cases for Packet Transport	[CHENG] W. Cheng, et. al., "ACTN Use-cases for Packet Transport
	Networks in Mobile Backhaul Networks", draft-cheng-actn-	Networks in Mobile Backhaul Networks", draft-cheng-actn-

	ptn-requirements, work in progress.	ptn-requirements-00, July 21, 2014.

	[DHODY] D. Dhody, et. al., "Packet Optical Integration (POI) Use	[DHODY] D. Dhody, et. al., "Packet Optical Integration (POI) Use
	Cases for Abstraction and Control of Transport Networks	Cases for Abstraction and Control of Transport Networks

	(ACTN)", draft-dhody-actn-poi-use-case, work in progress.	(ACTN)", draft-dhody-actn-poi-use-case-07, October 28,
		2016.

	[FANG] L. Fang, "ACTN Use Case for Multi-domain Data Center	[FANG] L. Fang, "ACTN Use Case for Multi-domain Data Center

	Interconnect", draft-fang-actn-multidomain-dci, work in	Interconnect", draft-fang-actn-multidomain-dci-01,
	progress.	September 29, 2014.

	[KLEE] K. Lee, H. Lee, R. Vilata, V. Lopez, "ACTN Use-case for E2E	[KLEE] K. Lee, H. Lee, R. Vilata, V. Lopez, "ACTN Use-case for E2E
	Network Services in Multiple Vendor Domain Transport	Network Services in Multiple Vendor Domain Transport

	Networks", draft-klee-teas-actn-connectivity-multi-domain,	Networks", draft-klee-teas-actn-connectivity-multi-domain-
	work-in-progress.	03, July 31, 2017.

	[KUMAKI] K. Kumaki, T. Miyasaka, "ACTN : Use case for Multi Tenant	[KUMAKI] K. Kumaki, T. Miyasaka, "ACTN : Use case for Multi Tenant

	VNO", draft-kumaki-teas-actn-multitenant-vno, work in	VNO", draft-kumaki-teas-actn-multitenant-vno-00, May 29,
	progress.	2014.

	[LOPEZ] D. Lopez (Ed), "ACTN Use-case for Virtual Network Operation	[LOPEZ] D. Lopez (Ed), "ACTN Use-case for Virtual Network Operation
	for Multiple Domains in a Single Operator Network", draft-	for Multiple Domains in a Single Operator Network", draft-

	lopez-actn-vno-multidomains, work in progress.	lopez-actn-vno-multidomains-01, October 27, 2014.

	[SHIN] J. Shin, R. Hwang, J. Lee, "ACTN Use-case for Mobile Virtual	[SHIN] J. Shin, R. Hwang, J. Lee, "ACTN Use-case for Mobile Virtual
	Network Operation for Multiple Domains in a Single	Network Operation for Multiple Domains in a Single

	Operator Network", draft-shin-actn-mvno-multi-domain, work	Operator Network", draft-shin-actn-mvno-multi-domain-00,
	in progress.	June 30, 2014.

	[XU] Y. Xu, et. al., "Use Cases and Requirements of Dynamic Service	[XU] Y. Xu, et. al., "Use Cases and Requirements of Dynamic Service
	Control based on Performance Monitoring in ACTN	Control based on Performance Monitoring in ACTN

	Architecture", draft-xu-actn-perf-dynamic-service-control,	Architecture", draft-xu-actn-perf-dynamic-service-control-
	work in progress.	03, April 23, 2015.

	[XU2] Y. Xu, et. al., "Requirements of Abstract Alarm Report in ACTN	[XU2] Y. Xu, et. al., "Requirements of Abstract Alarm Report in ACTN

	architecture", draft-xu-teas-actn-abstract-alarm-report,	architecture", draft-xu-teas-actn-abstract-alarm-report-
	work-in-progress.	00, July 6, 2015.

	[SUZUKI] T. Suzuki, et. al., "Use-case and Requirements for Multi-	[SUZUKI] T. Suzuki, et. al., "Use-case and Requirements for Multi-
	domain Operation Plane Change", draft-suzuki-teas-actn-	domain Operation Plane Change", draft-suzuki-teas-actn-

	multidomain-opc, work-in-progress.	multidomain-opc-00, July 6, 2015.

	4. Contributors


		6. Contributors
	Yunbin Xu	Yunbin Xu
	CATR	CATR
	Email: xuyunbin@ritt.cn	Email: xuyunbin@ritt.cn

	Toshiaki Suzuki	Toshiaki Suzuki
	Hitachi	Hitachi
	Email: toshiaki.suzuki.cs@hitachi.com	Email: toshiaki.suzuki.cs@hitachi.com

	Haomian Zheng	Haomian Zheng
	Huawei	Huawei

	skipping to change at page 11, line 14 ¶	skipping to change at page 11, line 25 ¶

	Authors' Addresses	Authors' Addresses

	Young Lee (Editor)	Young Lee (Editor)
	Huawei Technologies	Huawei Technologies
	5340 Legacy Drive	5340 Legacy Drive
	Plano, TX 75023, USA	Plano, TX 75023, USA
	Phone: (469)277-5838	Phone: (469)277-5838
	Email: leeyoung@huawei.com	Email: leeyoung@huawei.com


	Dhruv Dhody
	Huawei Technologies
	Email: dhruv.ietf@gmail.com

	Sergio Belotti
	Nokia
	Via Trento, 30
	Vimercate, Italy
	Email: sergio.belotti@nokia.com

	Khuzema Pithewan
	Infinera
	Email: kpithewan@infinera.com

	Daniele Ceccarelli	Daniele Ceccarelli
	Ericsson	Ericsson
	Torshamnsgatan,48	Torshamnsgatan,48
	Stockholm, Sweden	Stockholm, Sweden
	Email: daniele.ceccarelli@ericsson.com	Email: daniele.ceccarelli@ericsson.com

	Takuya Miyasaka	Takuya Miyasaka
	KDDI	KDDI
	Email: ta-miyasaka@kddi.com	Email: ta-miyasaka@kddi.com

	Jong Yoon Shin	Jong Yoon Shin
	SKT	SKT
	Email: jongyoon.shin@sk.com	Email: jongyoon.shin@sk.com

	Kwang-koog Lee	Kwang-koog Lee
	KT	KT
	Email: kwangkoog.lee@kt.com	Email: kwangkoog.lee@kt.com


		Dhruv Dhody
		Huawei Technologies
		Email: dhruv.ietf@gmail.com

		Sergio Belotti
		Nokia
		Via Trento, 30
		Vimercate, Italy
		Email: sergio.belotti@nokia.com

		Khuzema Pithewan
		Peloton Technology
		Email: khuzemap@gmail.com

End of changes. 31 change blocks.
	64 lines changed or deleted	69 lines changed or added
This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/