draft-ietf-ccamp-transport-nbi-use-cases-00.txt		draft-ietf-ccamp-transport-nbi-use-cases-01.txt
	CCAMP Working Group I. Busi (Ed.)		CCAMP Working Group I. Busi (Ed.)
	Internet Draft Huawei		Internet Draft Huawei
	Intended status: Informational D. King		Intended status: Informational D. King
	Expires: April 2018 Lancaster University		Lancaster University
	October 09, 2017
			Expires: April 2018 October 30, 2017
	Transport Northbound Interface Applicability Statement and Use Cases		Transport Northbound Interface Applicability Statement and Use Cases
	draft-ietf-ccamp-transport-nbi-use-cases-00		draft-ietf-ccamp-transport-nbi-use-cases-01
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	skipping to change at page 1, line 32 ¶		skipping to change at page 1, line 33 ¶
	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 Aoril 10, 2018.		This Internet-Draft will expire on April 30, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2017 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		(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
	carefully, as they describe your rights and restrictions with		carefully, as they describe your rights and restrictions with respect
	respect to this document. Code Components extracted from this		to this document. Code Components extracted from this document must
	document must include Simplified BSD License text as described in		include Simplified BSD License text as described in Section 4.e of
	Section 4.e of the Trust Legal Provisions and are provided without		the Trust Legal Provisions and are provided without warranty as
	warranty as described in the Simplified BSD License.		described in the Simplified BSD License.
	Abstract		Abstract
	Transport network domains, including Optical Transport Network (OTN)		Transport network domains, including Optical Transport Network (OTN)
	and Wavelength Division Multiplexing (WDM) networks, are typically		and Wavelength Division Multiplexing (WDM) networks, are typically
	deployed based on a single vendor or technology platforms. They are		deployed based on a single vendor or technology platforms. They are
	often managed using proprietary interfaces to dedicated Element		often managed using proprietary interfaces to dedicated Element
	Management Systems (EMS), Network Management Systems (NMS) and		Management Systems (EMS), Network Management Systems (NMS) and
	increasingly Software Defined Network (SDN) controllers.		increasingly Software Defined Network (SDN) controllers.
	A well-defined open interface to each domain management system or		A well-defined open interface to each domain management system or
	controller is required for network operators to facilitate control		controller is required for network operators to facilitate control
	automation and orchestrate end-to-end services across multi-domain		automation and orchestrate end-to-end services across multi-domain
	networks. These functions may be enabled using standardized data		networks. These functions may be enabled using standardized data
	models (e.g. YANG), and appropriate protocol (e.g., RESTCONF).		models (e.g. YANG), and appropriate protocol (e.g., RESTCONF).
	This document describes the key use cases and requirements for		This document describes the key use cases and requirements to be
	transport network control and management. It reviews proposed and		used as the basis for applicability statements analyzing how IETF
	existing IETF transport network data models, their applicability,		data models can be used for transport network control and
	and highlights gaps and requirements.		management.
	Table of Contents		Table of Contents
	1. Introduction ................................................3		1. Introduction ................................................ 3
	1.1. Scope of this document .................................4		1.1. Scope of this document 4
	2. Terminology .................................................4		2. Terminology ................................................. 4
	3. Conventions used in this document............................4		3. Conventions used in this document 4
	3.1. Topology and traffic flow processing ...................4		3.1. Topology and traffic flow processing ................... 4
	4. Use Case 1: Single-domain with single-layer .................5		4. Use Case 1: Single-domain with single-layer ................. 5
	4.1. Reference Network ......................................5		4.1. Reference Network ...................................... 5
	4.1.1. Single Transport Domain - OTN Network .............5		4.1.1. Single Transport Domain - OTN Network ............. 5
	4.2. Topology Abstractions ..................................8		4.2. Topology Abstractions .................................. 8
	4.3. Service Configuration ..................................9		4.3. Service Configuration .................................. 9
	4.3.1. ODU Transit .......................................9		4.3.1. ODU Transit ....................................... 9
	4.3.2. EPL over ODU ......................................10		4.3.2. EPL over ODU ..................................... 10
	4.3.3. Other OTN Client Services .........................10		4.3.3. Other OTN Client Services ........................ 10
	4.3.4. EVPL over ODU .....................................11		4.3.4. EVPL over ODU .................................... 11
	4.3.5. EVPLAN and EVPTree Services .......................12		4.3.5. EVPLAN and EVPTree Services ...................... 12
	4.4. Multi-functional Access Links ..........................13		4.4. Multi-functional Access Links ......................... 13
	4.5. Protection Requirements ................................14		4.5. Protection Requirements ............................... 14
	4.5.1. Linear Protection .................................15		4.5.1. Linear Protection ................................ 15
	5. Use Case 2: Single-domain with multi-layer ..................15		5. Use Case 2: Single-domain with multi-layer ................. 15
	5.1. Reference Network ......................................15		5.1. Reference Network ..................................... 15
	5.2. Topology Abstractions ..................................16		5.2. Topology Abstractions ................................. 16
	5.3. Service Configuration ..................................16		5.3. Service Configuration ................................. 16
	6. Use Case 3: Multi-domain with single-layer ..................16		6. Use Case 3: Multi-domain with single-layer ................. 16
	6.1. Reference Network ......................................16		6.1. Reference Network ..................................... 16
	6.2. Topology Abstractions ..................................19		6.2. Topology Abstractions ................................. 19
	6.3. Service Configuration ..................................19		6.3. Service Configuration ................................. 19
	6.3.1. ODU Transit .......................................20		6.3.1. ODU Transit ...................................... 20
	6.3.2. EPL over ODU ......................................20		6.3.2. EPL over ODU ..................................... 20
	6.3.3. Other OTN Client Services .........................21		6.3.3. Other OTN Client Services ........................ 21
	6.3.4. EVPL over ODU .....................................21		6.3.4. EVPL over ODU .................................... 21
	6.3.5. EVPLAN and EVPTree Services .......................21		6.3.5. EVPLAN and EVPTree Services ...................... 21
	6.4. Multi-functional Access Links ..........................22		6.4. Multi-functional Access Links ......................... 22
	6.5. Protection Scenarios ...................................22		6.5. Protection Scenarios .................................. 22
	6.5.1. Linear Protection (end-to-end) ....................23		6.5.1. Linear Protection (end-to-end) ................... 23
	6.5.2. Segmented Protection ..............................23		6.5.2. Segmented Protection ............................. 23
	7. Use Case 4: Multi-domain and multi-layer ....................24		7. Use Case 4: Multi-domain and multi-layer ................... 24
	7.1. Reference Network ......................................24		7.1. Reference Network ..................................... 24
	7.2. Topology Abstractions ..................................25		7.2. Topology Abstractions ................................. 25
	7.3. Service Configuration ..................................25		7.3. Service Configuration ................................. 25
	8. Security Considerations .....................................25		8. Security Considerations .................................... 25
	9. IANA Considerations .........................................26		9. IANA Considerations ........................................ 26
	10. References .................................................26		10. References ................................................ 26
	10.1. Normative References ..................................26		10.1. Normative References ................................. 26
	10.2. Informative References ................................26		10.2. Informative References ............................... 26
	11. Acknowledgments ............................................27		11. Acknowledgments ........................................... 27
	1. Introduction		1. Introduction
	Transport of packet services are critical for a wide-range of		Transport of packet services are critical for a wide-range of
	applications and services, including: data center and LAN		applications and services, including: data center and LAN
	interconnects, Internet service backhauling, mobile backhaul and		interconnects, Internet service backhauling, mobile backhaul and
	enterprise Carrier Ethernet Services. These services are typically		enterprise Carrier Ethernet Services. These services are typically
	setup using stovepipe NMS and EMS platforms, often requiring		setup using stovepipe NMS and EMS platforms, often requiring
	propriety management platforms and legacy management interfaces. A		propriety management platforms and legacy management interfaces. A
	clear goal of operators will be to automate setup of transport		clear goal of operators will be to automate setup of transport
	services across multiple transport technology domains.		services across multiple transport technology domains.
	A common open interface (API) to each domain controller and or		A common open interface (API) to each domain controller and or
	management system is pre-requisite for network operators to control		management system is pre-requisite for network operators to control
	multi-vendor and multi-domain networks and enable also service		multi-vendor and multi-domain networks and enable also service
	provisioning coordination/automation. This can be achieved by using		provisioning coordination/automation. This can be achieved by using
	standardized YANG models, used together with an appropriate protocol		standardized YANG models, used together with an appropriate protocol
	(e.g., [RESTCONF]).		(e.g., [RESTCONF]).
	This document describes key use cases for analyzing the		This document describes key use cases for analyzing the
	applicability of the existing models defined by the IETF for		applicability of the models defined by the IETF for transport
	transport networks. The intention of this document is to become an		networks. The intention of this document is to provide the base
	applicability statement that provides detailed descriptions of how		reference scenarios for applicability statements that will describe
	IETF transport models are applied to solve the described use cases		in details how IETF transport models are applied to solve the
	and requirements.		described use cases and requirements.
	1.1. Scope of this document		1.1. Scope of this document
	This document assumes a reference architecture, including		This document assumes a reference architecture, including
	interfaces, based on the Abstraction and Control of Traffic-		interfaces, based on the Abstraction and Control of Traffic-
	Engineered Networks (ACTN), defined in [ACTN-Frame]		Engineered Networks (ACTN), defined in [ACTN-Frame]
	The focus of this document is on the MPI (interface between the		The focus of this document is on the MPI (interface between the
	Multi Domain Service Coordinator (MDSC) and a Physical Network		Multi Domain Service Coordinator (MDSC) and a Physical Network
	Controller (PNC), controlling a transport network domain).		Controller (PNC), controlling a transport network domain).
	skipping to change at page 4, line 47 ¶		skipping to change at page 4, line 47 ¶
	OTN: Optical Transport Network		OTN: Optical Transport Network
	3. Conventions used in this document		3. Conventions used in this document
	3.1. Topology and traffic flow processing		3.1. Topology and traffic flow processing
	The traffic flow between different nodes is specified as an ordered		The traffic flow between different nodes is specified as an ordered
	list of nodes, separated with commas, indicating within the brackets		list of nodes, separated with commas, indicating within the brackets
	the processing within each node:		the processing within each node:
	<node> (<processing>){, <node> (<processing>)}		<node> (<processing>) {, <node> (<processing>)}
	The order represents the order of traffic flow being forwarded		The order represents the order of traffic flow being forwarded
	through the network.		through the network.
	The processing can be either an adaptation of a client layer into a		The processing can be either an adaptation of a client layer into a
	server layer "(client -> server)" or switching at a given layer		server layer "(client -> server)" or switching at a given layer
	"([switching])". Multi-layer switching is indicated by two layer		"([switching])". Multi-layer switching is indicated by two layer
	switching with client/server adaptation: "([client] -> [server])".		switching with client/server adaptation: "([client] -> [server])".
	For example, the following traffic flow:		For example, the following traffic flow:
	C-R1 (|PKT| -> ODU2), S3 (|ODU2|), S5 (|ODU2|), S6 (|ODU2|),		C-R1 ([PKT] -> ODU2), S3 ([ODU2]), S5 ([ODU2]), S6 ([ODU2]),
	C-R3 (ODU2 -> |PKT|)		C-R3 (ODU2 -> [PKT])
	Node C-R1 is switching at the packet (PKT) layer and mapping packets		Node C-R1 is switching at the packet (PKT) layer and mapping packets
	into a ODU2 before transmission to node S3. Nodes S3, S5 and S6 are		into a ODU2 before transmission to node S3. Nodes S3, S5 and S6 are
	switching at the ODU2 layer: S3 sends the ODU2 traffic to S5 which		switching at the ODU2 layer: S3 sends the ODU2 traffic to S5 which
	then sends it to S6 which finally sends to C-R3. Node C-R3		then sends it to S6 which finally sends to C-R3. Node C-R3
	terminates the ODU2 from S6 before switching at the packet (PKT)		terminates the ODU2 from S6 before switching at the packet (PKT)
	layer.		layer.
	The paths of working and protection transport entities are specified		The paths of working and protection transport entities are specified
	as an ordered list of nodes, separated with commas:		as an ordered list of nodes, separated with commas:
	skipping to change at page 10, line 5 ¶		skipping to change at page 10, line 5 ¶
	routers and the transport network are OTN links. The		routers and the transport network are OTN links. The
	physical/optical interconnection below the ODU layer is supposed to		physical/optical interconnection below the ODU layer is supposed to
	be pre-configured and not exposed at the MPI to the MDSC.		be pre-configured and not exposed at the MPI to the MDSC.
	To setup a 10Gb IP link between C-R1 to C-R3, an ODU2 end-to-end		To setup a 10Gb IP link between C-R1 to C-R3, an ODU2 end-to-end
	data plane connection needs to be created between C-R1 and C-R3,		data plane connection needs to be created between C-R1 and C-R3,
	crossing transport nodes S3, S5, and S6.		crossing transport nodes S3, S5, and S6.
	The traffic flow between C-R1 and C-R3 can be summarized as:		The traffic flow between C-R1 and C-R3 can be summarized as:
	C-R1 (|PKT| -> ODU2), S3 (|ODU2|), S5 (|ODU2|), S6 (|ODU2|),		C-R1 ([PKT] -> ODU2), S3 ([ODU2]), S5 ([ODU2]), S6 ([ODU2]),
	C-R3 (ODU2 -> |PKT|)		C-R3 (ODU2 -> [PKT])
	The MDSC should be capable via the MPI to request the setup of an		The MDSC should be capable via the MPI to request the setup of an
	ODU2 transit service with enough information that enable the		ODU2 transit service with enough information that enable the
	transport PNC to instantiate and control the ODU2 data plane		transport PNC to instantiate and control the ODU2 data plane
	connection segment through nodes S3, S5, S6.		connection segment through nodes S3, S5, S6.
	4.3.2. EPL over ODU		4.3.2. EPL over ODU
	This use case assumes that the physical links interconnecting the IP		This use case assumes that the physical links interconnecting the IP
	routers and the transport network are Ethernet links.		routers and the transport network are Ethernet links.
	In order to setup a 10Gb IP link between C-R1 to C-R3, an EPL		In order to setup a 10Gb IP link between C-R1 to C-R3, an EPL
	service needs to be created between C-R1 and C-R3, supported by an		service needs to be created between C-R1 and C-R3, supported by an
	ODU2 end-to-end connection between S3 and S6, crossing transport		ODU2 end-to-end connection between S3 and S6, crossing transport
	node S5.		node S5.
	The traffic flow between C-R1 and C-R3 can be summarized as:		The traffic flow between C-R1 and C-R3 can be summarized as:
	C-R1 (|PKT| -> ETH), S3 (ETH -> |ODU2|), S5 (|ODU2|),		C-R1 ([PKT] -> ETH), S3 (ETH -> [ODU2]), S5 ([ODU2]),
	S6 (|ODU2| -> ETH), C-R3 (ETH-> |PKT|)		S6 ([ODU2] -> ETH), C-R3 (ETH-> [PKT])
	The MDSC should be capable via the MPI to request the setup of an		The MDSC should be capable via the MPI to request the setup of an
	EPL service with enough information that can permit the transport		EPL service with enough information that can permit the transport
	PNC to instantiate and control the ODU2 end-to-end data plane		PNC to instantiate and control the ODU2 end-to-end data plane
	connection through nodes S3, S5, S6, as well as the adaptation		connection through nodes S3, S5, S6, as well as the adaptation
	functions inside S3 and S6: S3&S6 (ETH -> ODU2) and S9&S6 (ODU2 ->		functions inside S3 and S6: S3&S6 (ETH -> ODU2) and S9&S6 (ODU2 ->
	ETH).		ETH).
	4.3.3. Other OTN Client Services		4.3.3. Other OTN Client Services
	skipping to change at page 11, line 7 ¶		skipping to change at page 11, line 7 ¶
	options.		options.
	In order to setup a 10Gb IP link between C-R1 to C-R3 using, for		In order to setup a 10Gb IP link between C-R1 to C-R3 using, for
	example STM-64 physical links between the IP routers and the		example STM-64 physical links between the IP routers and the
	transport network, an STM-64 Private Line service needs to be		transport network, an STM-64 Private Line service needs to be
	created between C-R1 and C-R3, supported by an ODU2 end-to-end data		created between C-R1 and C-R3, supported by an ODU2 end-to-end data
	plane connection between S3 and S6, crossing transport node S5.		plane connection between S3 and S6, crossing transport node S5.
	The traffic flow between C-R1 and C-R3 can be summarized as:		The traffic flow between C-R1 and C-R3 can be summarized as:
	C-R1 (|PKT| -> STM-64), S3 (STM-64 -> |ODU2|), S5 (|ODU2|),		C-R1 ([PKT] -> STM-64), S3 (STM-64 -> [ODU2]), S5 ([ODU2]),
	S6 (|ODU2| -> STM-64), C-R3 (STM-64 -> |PKT|)		S6 ([ODU2] -> STM-64), C-R3 (STM-64 -> [PKT])
	The MDSC should be capable via the MPI to request the setup of an		The MDSC should be capable via the MPI to request the setup of an
	STM-64 Private Line service with enough information that can permit		STM-64 Private Line service with enough information that can permit
	the transport PNC to instantiate and control the ODU2 end-to-end		the transport PNC to instantiate and control the ODU2 end-to-end
	connection through nodes S3, S5, S6, as well as the adaptation		connection through nodes S3, S5, S6, as well as the adaptation
	functions inside S3 and S6: S3&S6 (STM-64 -> ODU2) and S9&S3 (STM-64		functions inside S3 and S6: S3&S6 (STM-64 -> ODU2) and S9&S3 (STM-64
	-> PKT).		-> PKT).
	4.3.4. EVPL over ODU		4.3.4. EVPL over ODU
	skipping to change at page 11, line 37 ¶		skipping to change at page 11, line 37 ¶
	crossing transport node S5, and between S3 and S2, crossing		crossing transport node S5, and between S3 and S2, crossing
	transport node S1.		transport node S1.
	Since the two EVPL services are sharing the same Ethernet physical		Since the two EVPL services are sharing the same Ethernet physical
	link between C-R1 and S3, different VLAN IDs are associated with		link between C-R1 and S3, different VLAN IDs are associated with
	different EVPL services: for example VLAN IDs 10 and 20		different EVPL services: for example VLAN IDs 10 and 20
	respectively.		respectively.
	The traffic flow between C-R1 and C-R3 can be summarized as:		The traffic flow between C-R1 and C-R3 can be summarized as:
	C-R1 (|PKT| -> VLAN), S3 (VLAN -> |ODU0|), S5 (|ODU0|),		C-R1 ([PKT] -> VLAN), S3 (VLAN -> [ODU0]), S5 ([ODU0]),
	S6 (|ODU0| -> VLAN), C-R3 (VLAN -> |PKT|)		S6 ([ODU0] -> VLAN), C-R3 (VLAN -> [PKT])
	The traffic flow between C-R1 and C-R4 can be summarized as:		The traffic flow between C-R1 and C-R4 can be summarized as:
	C-R1 (|PKT| -> VLAN), S3 (VLAN -> |ODU0|), S1 (|ODU0|),		C-R1 ([PKT] -> VLAN), S3 (VLAN -> [ODU0]), S1 ([ODU0]),
	S2 (|ODU0| -> VLAN), C-R4 (VLAN -> |PKT|)		S2 ([ODU0] -> VLAN), C-R4 (VLAN -> [PKT])
	The MDSC should be capable via the MPI to request the setup of these		The MDSC should be capable via the MPI to request the setup of these
	EVPL services with enough information that can permit the transport		EVPL services with enough information that can permit the transport
	PNC to instantiate and control the ODU0 end-to-end data plane		PNC to instantiate and control the ODU0 end-to-end data plane
	connections as well as the adaptation functions on the boundary		connections as well as the adaptation functions on the boundary
	nodes: S3&S2&S6 (VLAN -> ODU0) and S3&S2&S6 (ODU0 -> VLAN).		nodes: S3&S2&S6 (VLAN -> ODU0) and S3&S2&S6 (ODU0 -> VLAN).
	Internet-Draft Transport NBI Use Cases October 201
	4.3.5. EVPLAN and EVPTree Services		4.3.5. EVPLAN and EVPTree Services
	This use case assumes that the physical links interconnecting the IP		This use case assumes that the physical links interconnecting the IP
	routers and the transport network are Ethernet links and that		routers and the transport network are Ethernet links and that
	different Ethernet services (e.g, EVPL, EVPLAN and EVPTree) can		different Ethernet services (e.g., EVPL, EVPLAN and EVPTree) can
	share the same physical link using different VLANs.		share the same physical link using different VLANs.
	Note - it is assumed that EPLAN and EPTree services can be supported		Note - it is assumed that EPLAN and EPTree services can be supported
	by configuring EVPLAN and EVPTree with port mapping.		by configuring EVPLAN and EVPTree with port mapping.
	In order to setup an IP subnet between C-R1, C-R2, C-R3 and C-R4, an		In order to setup an IP subnet between C-R1, C-R2, C-R3 and C-R4, an
	EVPLAN/EVPTree service needs to be created, supported by two ODUflex		EVPLAN/EVPTree service needs to be created, supported by two ODUflex
	end-to-end connections respectively between S3 and S6, crossing		end-to-end connections respectively between S3 and S6, crossing
	transport node S5, and between S3 and S2, crossing transport node		transport node S5, and between S3 and S2, crossing transport node
	S1.		S1.
	skipping to change at page 12, line 51 ¶		skipping to change at page 12, line 49 ¶
	The MAC bridging function in node S6 is needed to select, based on		The MAC bridging function in node S6 is needed to select, based on
	the MAC Destination Address, whether the Ethernet frames received		the MAC Destination Address, whether the Ethernet frames received
	from the ODUflex should be set to C-R2 or C-R3, as well as whether		from the ODUflex should be set to C-R2 or C-R3, as well as whether
	the Ethernet frames received from C-R2 (or C-R3) should be sent to		the Ethernet frames received from C-R2 (or C-R3) should be sent to
	C-R3 (or C-R2) or to the ODUflex.		C-R3 (or C-R2) or to the ODUflex.
	For example, the traffic flow between C-R1 and C-R3 can be		For example, the traffic flow between C-R1 and C-R3 can be
	summarized as:		summarized as:
	C-R1 (|PKT| -> VLAN), S3 (VLAN -> |MAC| -> |ODUflex|),		C-R1 ([PKT] -> VLAN), S3 (VLAN -> [MAC] -> [ODUflex]),
	S5 (|ODUflex|), S6 (|ODUflex| -> |MAC| -> VLAN),		S5 ([ODUflex]), S6 ([ODUflex] -> [MAC] -> VLAN),
	C-R3 (VLAN -> |PKT|)		C-R3 (VLAN -> [PKT])
	The MAC bridging function in node S3 is also needed to select, based		The MAC bridging function in node S3 is also needed to select, based
	on the MAC Destination Address, whether the Ethernet frames one		on the MAC Destination Address, whether the Ethernet frames one
	ODUflex should be sent to C-R1 or to the other ODUflex.		ODUflex should be sent to C-R1 or to the other ODUflex.
	For example, the traffic flow between C-R3 and C-R4 can be		For example, the traffic flow between C-R3 and C-R4 can be
	summarized as:		summarized as:
	C-R3 (|PKT| -> VLAN), S6 (VLAN -> |MAC| -> |ODUflex|),		C-R3 ([PKT] -> VLAN), S6 (VLAN -> [MAC] -> [ODUflex]),
	S5 (|ODUflex|), S3 (|ODUflex| -> |MAC| -> |ODUflex|),		S5 ([ODUflex]), S3 ([ODUflex] -> [MAC] -> [ODUflex]),
	S1 (|ODUflex|), S2 (|ODUflex| -> VLAN), C-R4 (VLAN -> |PKT|)		S1 ([ODUflex]), S2 ([ODUflex] -> VLAN), C-R4 (VLAN -> [PKT])
	In node S2 there is no need for any MAC bridging function since all		In node S2 there is no need for any MAC bridging function since all
	the Ethernet frames received from C-R4 should be sent to the ODUflex		the Ethernet frames received from C-R4 should be sent to the ODUflex
	toward S3 and viceversa.		toward S3 and viceversa.
	The traffic flow between C-R1 and C-R4 can be summarized as:		The traffic flow between C-R1 and C-R4 can be summarized as:
	C-R1 (|PKT| -> VLAN), S3 (VLAN -> |MAC| -> |ODUflex|),		C-R1 ([PKT] -> VLAN), S3 (VLAN -> [MAC] -> [ODUflex]),
	S1 (|ODUflex|), S2 (|ODUflex| -> VLAN), C-R4 (VLAN -> |PKT|)		S1 ([ODUflex]), S2 ([ODUflex] -> VLAN), C-R4 (VLAN -> [PKT])
	The MDSC should be capable via the MPI to request the setup of this		The MDSC should be capable via the MPI to request the setup of this
	EVPLAN/EVPTree services with enough information that can permit the		EVPLAN/EVPTree services with enough information that can permit the
	transport PNC to instantiate and control the ODUflex end-to-end data		transport PNC to instantiate and control the ODUflex end-to-end data
	plane connections as well as the Ethernet Bridging and adaptation		plane connections as well as the Ethernet Bridging and adaptation
	functions on the boundary nodes: S3&S6 (VLAN -> MAC -> ODU2), S3&S6		functions on the boundary nodes: S3&S6 (VLAN -> MAC -> ODU2), S3&S6
	(ODU2 -> ETH -> VLAN), S2 (VLAN -> ODU2) and S2 (ODU2 -> VLAN).		(ODU2 -> ETH -> VLAN), S2 (VLAN -> ODU2) and S2 (ODU2 -> VLAN).
	4.4. Multi-functional Access Links		4.4. Multi-functional Access Links
	skipping to change at page 14, line 9 ¶		skipping to change at page 14, line 9 ¶
	For example, if the physical link between C-R1 and S3 is a multi-		For example, if the physical link between C-R1 and S3 is a multi-
	functional access link while the physical links between C-R3 and S6		functional access link while the physical links between C-R3 and S6
	and between C-R4 and S2 are STM-64 and 10GE physical links		and between C-R4 and S2 are STM-64 and 10GE physical links
	respectively, it is possible at the MPI to configure either an STM-		respectively, it is possible at the MPI to configure either an STM-
	64 Private Line service between C-R1 and C-R3 or an EPL service		64 Private Line service between C-R1 and C-R3 or an EPL service
	between C-R1 and C-R4.		between C-R1 and C-R4.
	The traffic flow between C-R1 and C-R3 can be summarized as:		The traffic flow between C-R1 and C-R3 can be summarized as:
	C-R1 (|PKT| -> STM-64), S3 (STM-64 -> |ODU2|), S5 (|ODU2|),		C-R1 ([PKT] -> STM-64), S3 (STM-64 -> [ODU2]), S5 ([ODU2]),
	S6 (|ODU2| -> STM-64), C-R3 (STM-64 -> |PKT|)		S6 ([ODU2] -> STM-64), C-R3 (STM-64 -> [PKT])
	The traffic flow between C-R1 and C-R4 can be summarized as:		The traffic flow between C-R1 and C-R4 can be summarized as:
	C-R1 (|PKT| -> ETH), S3 (ETH -> |ODU2|), S1 (|ODU2|),		C-R1 ([PKT] -> ETH), S3 (ETH -> [ODU2]), S1 ([ODU2]),
	S2 (|ODU2| -> ETH), C-R4 (ETH-> |PKT|)		S2 ([ODU2] -> ETH), C-R4 (ETH-> [PKT])
	The MDSC should be capable via the MPI to request the setup of		The MDSC should be capable via the MPI to request the setup of
	either service with enough information that can permit the transport		either service with enough information that can permit the transport
	PNC to instantiate and control the ODU2 end-to-end data plane		PNC to instantiate and control the ODU2 end-to-end data plane
	connection as well as the adaptation functions inside S3 and S2 or		connection as well as the adaptation functions inside S3 and S2 or
	S6.		S6.
	4.5. Protection Requirements		4.5. Protection Requirements
	Protection switching provides a pre-allocated survivability		Protection switching provides a pre-allocated survivability
	skipping to change at page 20, line 30 ¶		skipping to change at page 20, line 30 ¶
	6.3.1. ODU Transit		6.3.1. ODU Transit
	In order to setup a 10Gb IP link between C-R1 and C-R5, an ODU2 end-		In order to setup a 10Gb IP link between C-R1 and C-R5, an ODU2 end-
	to-end data plane connection needs be created between C-R1 and C-R5,		to-end data plane connection needs be created between C-R1 and C-R5,
	crossing transport nodes S3, S1, S2, S31, S33, S34, S15 and S18		crossing transport nodes S3, S1, S2, S31, S33, S34, S15 and S18
	which belong to different PNC domains.		which belong to different PNC domains.
	The traffic flow between C-R1 and C-R5 can be summarized as:		The traffic flow between C-R1 and C-R5 can be summarized as:
	C-R1 (|PKT| -> ODU2), S3 (|ODU2|), S1 (|ODU2|), S2 (|ODU2|),		C-R1 ([PKT] -> ODU2), S3 ([ODU2]), S1 ([ODU2]), S2 ([ODU2]),
	S31 (|ODU2|), S33 (|ODU2|), S34 (|ODU2|),		S31 ([ODU2]), S33 ([ODU2]), S34 ([ODU2]),
	S15 (|ODU2|), S18 (|ODU2|), C-R5 (ODU2 -> |PKT|)		S15 ([ODU2]), S18 ([ODU2]), C-R5 (ODU2 -> [PKT])
	6.3.2. EPL over ODU		6.3.2. EPL over ODU
	In order to setup a 10Gb IP link between C-R1 and C-R5, an EPL		In order to setup a 10Gb IP link between C-R1 and C-R5, an EPL
	service needs to be created between C-R1 and C-R5, supported by an		service needs to be created between C-R1 and C-R5, supported by an
	ODU2 end-to-end data plane connection between transport nodes S3 and		ODU2 end-to-end data plane connection between transport nodes S3 and
	S18, crossing transport nodes S1, S2, S31, S33, S34 and S15 which		S18, crossing transport nodes S1, S2, S31, S33, S34 and S15 which
	belong to different PNC domains.		belong to different PNC domains.
	The traffic flow between C-R1 and C-R5 can be summarized as:		The traffic flow between C-R1 and C-R5 can be summarized as:
	C-R1 (|PKT| -> ETH), S3 (ETH -> |ODU2|), S1 (|ODU2|),		C-R1 ([PKT] -> ETH), S3 (ETH -> [ODU2]), S1 ([ODU2]),
	S2 (|ODU2|), S31 (|ODU2|), S33 (|ODU2|), S34 (|ODU2|),		S2 ([ODU2]), S31 ([ODU2]), S33 ([ODU2]), S34 ([ODU2]),
	S15 (|ODU2|), S18 (|ODU2| -> ETH), C-R5 (ETH -> |PKT|)		S15 ([ODU2]), S18 ([ODU2] -> ETH), C-R5 (ETH -> [PKT])
	6.3.3. Other OTN Client Services		6.3.3. Other OTN Client Services
	In order to setup a 10Gb IP link between C-R1 and C-R5 using, for		In order to setup a 10Gb IP link between C-R1 and C-R5 using, for
	example SDH physical links between the IP routers and the transport		example SDH physical links between the IP routers and the transport
	network, an STM-64 Private Line service needs to be created between		network, an STM-64 Private Line service needs to be created between
	C-R1 and C-R5, supported by ODU2 end-to-end data plane connection		C-R1 and C-R5, supported by ODU2 end-to-end data plane connection
	between transport nodes S3 and S18, crossing transport nodes S1, S2,		between transport nodes S3 and S18, crossing transport nodes S1, S2,
	S31, S33, S34 and S15 which belong to different PNC domains.		S31, S33, S34 and S15 which belong to different PNC domains.
	The traffic flow between C-R1 and C-R5 can be summarized as:		The traffic flow between C-R1 and C-R5 can be summarized as:
	C-R1 (|PKT| -> STM-64), S3 (STM-64 -> |ODU2|), S1 (|ODU2|),		C-R1 ([PKT] -> STM-64), S3 (STM-64 -> [ODU2]), S1 ([ODU2]),
	S2 (|ODU2|), S31 (|ODU2|), S33 (|ODU2|), S34 (|ODU2|),		S2 ([ODU2]), S31 ([ODU2]), S33 ([ODU2]), S34 ([ODU2]),
	S15 (|ODU2|), S18 (|ODU2| -> STM-64), C-R5 (STM-64 -> |PKT|)		S15 ([ODU2]), S18 ([ODU2] -> STM-64), C-R5 (STM-64 -> [PKT])
	6.3.4. EVPL over ODU		6.3.4. EVPL over ODU
	In order to setup two 1Gb IP links between C-R1 to C-R3 and between		In order to setup two 1Gb IP links between C-R1 to C-R3 and between
	C-R1 and C-R5, two EVPL services need to be created, supported by		C-R1 and C-R5, two EVPL services need to be created, supported by
	two ODU0 end-to-end connections respectively between S3 and S6,		two ODU0 end-to-end connections respectively between S3 and S6,
	crossing transport node S5, and between S3 and S18, crossing		crossing transport node S5, and between S3 and S18, crossing
	transport nodes S1, S2, S31, S33, S34 and S15 which belong to		transport nodes S1, S2, S31, S33, S34 and S15 which belong to
	different PNC domains.		different PNC domains.
	The VLAN configuration on the access links is the same as described		The VLAN configuration on the access links is the same as described
	in section 4.3.4.		in section 4.3.4.
	The traffic flow between C-R1 and C-R3 is the same as described in		The traffic flow between C-R1 and C-R3 is the same as described in
	section 4.3.4.		section 4.3.4.
	The traffic flow between C-R1 and C-R5 can be summarized as:		The traffic flow between C-R1 and C-R5 can be summarized as:
	C-R1 (|PKT| -> VLAN), S3 (VLAN -> |ODU2|), S1 (|ODU2|),		C-R1 ([PKT] -> VLAN), S3 (VLAN -> [ODU2]), S1 ([ODU2]),
	S2 (|ODU2|), S31 (|ODU2|), S33 (|ODU2|), S34 (|ODU2|),		S2 ([ODU2]), S31 ([ODU2]), S33 ([ODU2]), S34 ([ODU2]),
	S15 (|ODU2|), S18 (|ODU2| -> VLAN), C-R5 (VLAN -> |PKT|)		S15 ([ODU2]), S18 ([ODU2] -> VLAN), C-R5 (VLAN -> [PKT])
	6.3.5. EVPLAN and EVPTree Services		6.3.5. EVPLAN and EVPTree Services
	In order to setup an IP subnet between C-R1, C-R2, C-R3 and C-R7, an		In order to setup an IP subnet between C-R1, C-R2, C-R3 and C-R7, an
	EVPLAN/EVPTree service needs to be created, supported by two ODUflex		EVPLAN/EVPTree service needs to be created, supported by two ODUflex
	end-to-end connections respectively between S3 and S6, crossing		end-to-end connections respectively between S3 and S6, crossing
	transport node S5, and between S3 and S18, crossing transport nodes		transport node S5, and between S3 and S18, crossing transport nodes
	S1, S2, S31, S33, S34 and S15 which belong to different PNC domains.		S1, S2, S31, S33, S34 and S15 which belong to different PNC domains.
	The VLAN configuration on the access links is the same as described		The VLAN configuration on the access links is the same as described
	skipping to change at page 22, line 15 ¶		skipping to change at page 22, line 15 ¶
	The configuration of the Ethernet Bridging capabilities on nodes S3		The configuration of the Ethernet Bridging capabilities on nodes S3
	and S6 is the same as described in section 4.3.5 while the		and S6 is the same as described in section 4.3.5 while the
	configuration on node S18 similar to the configuration of node S2		configuration on node S18 similar to the configuration of node S2
	described in section 4.3.5.		described in section 4.3.5.
	The traffic flow between C-R1 and C-R3 is the same as described in		The traffic flow between C-R1 and C-R3 is the same as described in
	section 4.3.5.		section 4.3.5.
	The traffic flow between C-R1 and C-R5 can be summarized as:		The traffic flow between C-R1 and C-R5 can be summarized as:
	C-R1 (|PKT| -> VLAN), S3 (VLAN -> |MAC| -> |ODUflex|),		C-R1 ([PKT] -> VLAN), S3 (VLAN -> [MAC] -> [ODUflex]),
	S1 (|ODUflex|), S2 (|ODUflex|), S31 (|ODUflex|),		S1 ([ODUflex]), S2 ([ODUflex]), S31 ([ODUflex]),
	S33 (|ODUflex|), S34 (|ODUflex|),		S33 ([ODUflex]), S34 ([ODUflex]),
	S15 (|ODUflex|), S18 (|ODUflex| -> VLAN), C-R5 (VLAN -> |PKT|)		S15 ([ODUflex]), S18 ([ODUflex] -> VLAN), C-R5 (VLAN -> [PKT])
	6.4. Multi-functional Access Links		6.4. Multi-functional Access Links
	The same considerations of section 4.4 apply with the only		The same considerations of section 4.4 apply with the only
	difference that the ODU data plane connections could be setup across		difference that the ODU data plane connections could be setup across
	multiple PNC domains.		multiple PNC domains.
	For example, if the physical link between C-R1 and S3 is a multi-		For example, if the physical link between C-R1 and S3 is a multi-
	functional access link while the physical links between C-R7 and S31		functional access link while the physical links between C-R7 and S31
	and between C-R5 and S18 are STM-64 and 10GE physical links		and between C-R5 and S18 are STM-64 and 10GE physical links
	respectively, it is possible to configure either an STM-64 Private		respectively, it is possible to configure either an STM-64 Private
	Line service between C-R1 and C-R7 or an EPL service between C-R1		Line service between C-R1 and C-R7 or an EPL service between C-R1
	and C-R5.		and C-R5.
	The traffic flow between C-R1 and C-R7 can be summarized as:		The traffic flow between C-R1 and C-R7 can be summarized as:
	C-R1 (|PKT| -> STM-64), S3 (STM-64 -> |ODU2|), S1 (|ODU2|),		C-R1 ([PKT] -> STM-64), S3 (STM-64 -> [ODU2]), S1 ([ODU2]),
	S2 (|ODU2|), S31 (|ODU2| -> STM-64), C-R3 (STM-64 -> |PKT|)		S2 ([ODU2]), S31 ([ODU2] -> STM-64), C-R3 (STM-64 -> [PKT])
	The traffic flow between C-R1 and C-R5 can be summarized as:		The traffic flow between C-R1 and C-R5 can be summarized as:
	C-R1 (|PKT| -> ETH), S3 (ETH -> |ODU2|), S1 (|ODU2|),		C-R1 ([PKT] -> ETH), S3 (ETH -> [ODU2]), S1 ([ODU2]),
	S2 (|ODU2|), S31 (|ODU2|), S33 (|ODU2|), S34 (|ODU2|),		S2 ([ODU2]), S31 ([ODU2]), S33 ([ODU2]), S34 ([ODU2]),
	S15 (|ODU2|), S18 (|ODU2| -> ETH), C-R5 (ETH -> |PKT|)		S15 ([ODU2]), S18 ([ODU2] -> ETH), C-R5 (ETH -> [PKT])
	6.5. Protection Scenarios		6.5. Protection Scenarios
	The MDSC needs to be capable to coordinate different PNCs to		The MDSC needs to be capable to coordinate different PNCs to
	configure protection switching when requesting the setup of the		configure protection switching when requesting the setup of the
	connectivity services described in section 6.3.		connectivity services described in section 6.3.
	Since in this use case it is assumed that switching within the		Since in this use case it is assumed that switching within the
	transport network domain is performed only in one layer, also		transport network domain is performed only in one layer, also
	protection switching within the transport network domain can only be		protection switching within the transport network domain can only be
	skipping to change at page 26, line 22 ¶		skipping to change at page 26, line 22 ¶
	10. References		10. References
	10.1. Normative References		10.1. Normative References
	[RFC7926] Farrel, A. et al., "Problem Statement and Architecture for		[RFC7926] Farrel, A. et al., "Problem Statement and Architecture for
	Information Exchange between Interconnected Traffic-		Information Exchange between Interconnected Traffic-
	Engineered Networks", BCP 206, RFC 7926, July 2016.		Engineered Networks", BCP 206, RFC 7926, July 2016.
	[RFC4427] Mannie, E., Papadimitriou, D., "Recovery (Protection and		[RFC4427] Mannie, E., Papadimitriou, D., "Recovery (Protection and
	Restoration) Terminology for Generalized Multi-Protocol		Restoration) Terminology for Generalized Multi-Protocol
	Label Switching (GMPLS)", RFC 4427, April 2006.		Label Switching (GMPLS)", RFC 4427, March 2006.
	[ACTN-Frame] Ceccarelli, D., Lee, Y. et al., "Framework for		[ACTN-Frame] Ceccarelli, D., Lee, Y. et al., "Framework for
	Abstraction and Control of Transport Networks", draft-		Abstraction and Control of Transport Networks", draft-
	ietf-teas-actn-framework, work in progress.		ietf-teas-actn-framework, work in progress.
	[ITU-T G.709-2016] ITU-T Recommendation G.709 (06/16), "Interfaces		[ITU-T G.709-2016] ITU-T Recommendation G.709 (06/16), "Interfaces
	for the optical transport network", June 2016.		for the optical transport network", June 2016.
	[ITU-T G.808.1-2014] ITU-T Recommendation G.808.1 (05/14), "Generic		[ITU-T G.808.1-2014] ITU-T Recommendation G.808.1 (05/14), "Generic
	protection switching - Linear trail and subnetwork		protection switching - Linear trail and subnetwork
	skipping to change at page 27, line 5 ¶		skipping to change at page 27, line 5 ¶
	draft-ietf-teas-yang-te-topo, work in progress.		draft-ietf-teas-yang-te-topo, work in progress.
	[ACTN-YANG] Zhang, X. et al., "Applicability of YANG models for		[ACTN-YANG] Zhang, X. et al., "Applicability of YANG models for
	Abstraction and Control of Traffic Engineered Networks",		Abstraction and Control of Traffic Engineered Networks",
	draft-zhang-teas-actn-yang, work in progress.		draft-zhang-teas-actn-yang, work in progress.
	[Path-Compute] Busi, I., Belotti, S. et al., " Yang model for		[Path-Compute] Busi, I., Belotti, S. et al., " Yang model for
	requesting Path Computation", draft-busibel-teas-yang-		requesting Path Computation", draft-busibel-teas-yang-
	path-computation, work in progress.		path-computation, work in progress.
	[RESTCONF] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
	Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
	<http://www.rfc-editor.org/info/rfc8040>.
	[ONF TR-527] ONF Technical Recommendation TR-527, "Functional		[ONF TR-527] ONF Technical Recommendation TR-527, "Functional
	Requirements for Transport API", June 2016.		Requirements for Transport API", June 2016.
	[ONF GitHub] ONF Open Transport (SNOWMASS)		[ONF GitHub] ONF Open Transport (SNOWMASS)
	https://github.com/OpenNetworkingFoundation/Snowmass-		https://github.com/OpenNetworkingFoundation/Snowmass-
	ONFOpenTransport		ONFOpenTransport
	11. Acknowledgments		11. Acknowledgments
	The authors would like to thank all members of the Transport NBI		The authors would like to thank all members of the Transport NBI
End of changes. 31 change blocks.
	120 lines changed or deleted		115 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/