draft-ietf-opsawg-model-automation-framework-04.txt		draft-ietf-opsawg-model-automation-framework-05.txt
	OPSAWG Q. Wu, Ed.		OPSAWG Q. Wu, Ed.
	Internet-Draft Huawei		Internet-Draft Huawei
	Intended status: Informational M. Boucadair, Ed.		Intended status: Informational M. Boucadair, Ed.
	Expires: December 16, 2020 Orange		Expires: March 12, 2021 Orange
	D. Lopez		D. Lopez
	Telefonica I+D		Telefonica I+D
	C. Xie		C. Xie
	China Telecom		China Telecom
	L. Geng		L. Geng
	China Mobile		China Mobile
	June 14, 2020		September 8, 2020
	A Framework for Automating Service and Network Management with YANG		A Framework for Automating Service and Network Management with YANG
	draft-ietf-opsawg-model-automation-framework-04		draft-ietf-opsawg-model-automation-framework-05
	Abstract		Abstract
	Data models provide a programmatic approach to represent services and		Data models provide a programmatic approach to represent services and
	networks. Concretely, they can be used to derive configuration		networks. Concretely, they can be used to derive configuration
	information for network and service components, and state information		information for network and service components, and state information
	that will be monitored and tracked. Data models can be used during		that will be monitored and tracked. Data models can be used during
	the service and network management life cycle, such as service		the service and network management life cycle, such as service
	instantiation, provisioning, optimization, monitoring, diagnostic,		instantiation, provisioning, optimization, monitoring, diagnostic,
	and assurance. Data models are also instrumental in the automation		and assurance. Data models are also instrumental in the automation
	skipping to change at page 2, line 7 ¶		skipping to change at page 2, line 7 ¶
	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 December 16, 2020.		This Internet-Draft will expire on March 12, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2020 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 29 ¶		skipping to change at page 2, line 29 ¶
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	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 . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology and Acronyms . . . . . . . . . . . . . . . . . . 5		2. Terminology and Acronyms . . . . . . . . . . . . . . . . . . 5
	2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5		2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
	2.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 5		2.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 6
	3. Architectural Concepts and Goals . . . . . . . . . . . . . . 6		3. Architectural Concepts and Goals . . . . . . . . . . . . . . 6
	3.1. Data Models: Layering and Representation . . . . . . . . 6		3.1. Data Models: Layering and Representation . . . . . . . . 6
	3.2. Automation of Service Delivery Procedures . . . . . . . . 9		3.2. Automation of Service Delivery Procedures . . . . . . . . 10
	3.3. Service Fullfillment Automation . . . . . . . . . . . . . 10		3.3. Service Fullfillment Automation . . . . . . . . . . . . . 10
	3.4. YANG Modules Integration . . . . . . . . . . . . . . . . 10		3.4. YANG Modules Integration . . . . . . . . . . . . . . . . 11
	4. Functional Bocks and Interactions . . . . . . . . . . . . . . 11		4. Functional Blocks and Interactions . . . . . . . . . . . . . 11
	4.1. Service Lifecycle Management Procedure . . . . . . . . . 12		4.1. Service Lifecycle Management Procedure . . . . . . . . . 12
	4.1.1. Service Exposure . . . . . . . . . . . . . . . . . . 13		4.1.1. Service Exposure . . . . . . . . . . . . . . . . . . 13
	4.1.2. Service Creation/Modification . . . . . . . . . . . . 13		4.1.2. Service Creation/Modification . . . . . . . . . . . . 13
	4.1.3. Service Optimization . . . . . . . . . . . . . . . . 13		4.1.3. Service Optimization . . . . . . . . . . . . . . . . 13
	4.1.4. Service Diagnosis . . . . . . . . . . . . . . . . . . 14		4.1.4. Service Diagnosis . . . . . . . . . . . . . . . . . . 14
	4.1.5. Service Decommission . . . . . . . . . . . . . . . . 14		4.1.5. Service Decommission . . . . . . . . . . . . . . . . 14
	4.2. Service Fullfillment Management Procedure . . . . . . . . 14		4.2. Service Fullfillment Management Procedure . . . . . . . . 14
	4.2.1. Intended Configuration Provision . . . . . . . . . . 15		4.2.1. Intended Configuration Provision . . . . . . . . . . 15
	4.2.2. Configuration Validation . . . . . . . . . . . . . . 15		4.2.2. Configuration Validation . . . . . . . . . . . . . . 15
	4.2.3. Performance Monitoring/Model-driven Telemetry . . . . 16		4.2.3. Performance Monitoring/Model-driven Telemetry . . . . 16
	skipping to change at page 3, line 14 ¶		skipping to change at page 3, line 14 ¶
	5.3. Event-based Telemetry in the Device Self Management . . . 20		5.3. Event-based Telemetry in the Device Self Management . . . 20
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 21		6. Security Considerations . . . . . . . . . . . . . . . . . . . 21
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
	9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 22		9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 22
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 23		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
	10.1. Normative References . . . . . . . . . . . . . . . . . . 23		10.1. Normative References . . . . . . . . . . . . . . . . . . 23
	10.2. Informative References . . . . . . . . . . . . . . . . . 24		10.2. Informative References . . . . . . . . . . . . . . . . . 24
	Appendix A. Layered YANG Modules Examples Overview . . . . . . . 32		Appendix A. Layered YANG Modules Examples Overview . . . . . . . 32
	A.1. Service Models: Definition and Samples . . . . . . . . . 32		A.1. Service Models: Definition and Samples . . . . . . . . . 32
	A.2. Network Models: Samples . . . . . . . . . . . . . . . . . 32		A.2. Network Models: Samples . . . . . . . . . . . . . . . . . 33
	A.3. Device Models: Samples . . . . . . . . . . . . . . . . . 35		A.3. Device Models: Samples . . . . . . . . . . . . . . . . . 35
	A.3.1. Model Composition . . . . . . . . . . . . . . . . . . 37		A.3.1. Model Composition . . . . . . . . . . . . . . . . . . 37
	A.3.2. Device Models: Samples . . . . . . . . . . . . . . . 37		A.3.2. Device Models: Samples . . . . . . . . . . . . . . . 37
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40
	1. Introduction		1. Introduction
	Service management systems usually comprise service activation/		Service management systems usually comprise service activation/
	provision and service operation. Current service delivery		provision and service operation. Current service delivery
	procedures, from the processing of customer's requirements and orders		procedures, from the processing of customer's requirements and orders
	skipping to change at page 4, line 28 ¶		skipping to change at page 4, line 28 ¶
	Models are key for each of the aforementioned four technical items.		Models are key for each of the aforementioned four technical items.
	Service and network management automation is an important step to		Service and network management automation is an important step to
	improve the agility of network operations. Models are also important		improve the agility of network operations. Models are also important
	to ease integrating multi-vendor solutions.		to ease integrating multi-vendor solutions.
	YANG [RFC7950] module developers have taken both top-down and bottom-		YANG [RFC7950] module developers have taken both top-down and bottom-
	up approaches to develop modules [RFC8199] and to establish a mapping		up approaches to develop modules [RFC8199] and to establish a mapping
	between a network technology and customer requirements at the top or		between a network technology and customer requirements at the top or
	abstracting common constructs from various network technologies at		abstracting common constructs from various network technologies at
	the bottom. At the time of writing this document (2020), there are		the bottom. At the time of writing this document (2020), there are
	many data models including configuration and service models that have		many YANG data models including configuration and service models that
	been specified or are being specified by the IETF. They cover many		have been specified or are being specified by the IETF. They cover
	of the networking protocols and techniques. However, how these		many of the networking protocols and techniques. However, how these
	models work together to configure a device, manage a set of devices		models work together to configure a device, manage a set of devices
	involved in a service, or provide a service is something that is not		involved in a service, or provide a service is something that is not
	currently documented either within the IETF or other Standards		currently documented either within the IETF or other Standards
	Development Organizations (SDOs).		Development Organizations (SDOs).
	This document describes an architectural framework for service and		This document describes an architectural framework for service and
	network management automation (Section 3) that takes advantage of		network management automation (Section 3) that takes advantage of
	YANG modeling technologies and investigates how different layer YANG		YANG modeling technologies and investigates how different layer YANG
	data models interact with each other (e.g., service mapping, model		data models interact with each other (e.g., service mapping, model
	composing) in the context of service delivery and fulfillment		composing) in the context of service delivery and fulfillment
	skipping to change at page 5, line 45 ¶		skipping to change at page 5, line 45 ¶
	Model.		Model.
	Device Model: Refers to the Network Element YANG data model		Device Model: Refers to the Network Element YANG data model
	described in [RFC8199] or the Device Configuration Model discussed		described in [RFC8199] or the Device Configuration Model discussed
	in [RFC8309].		in [RFC8309].
	Device Models are also used to refer to model a function embedded		Device Models are also used to refer to model a function embedded
	in a device (e.g., Network Address Translation (NAT) [RFC8512],		in a device (e.g., Network Address Translation (NAT) [RFC8512],
	Access Control Lists (ACLs) [RFC8519]).		Access Control Lists (ACLs) [RFC8519]).
			Pipe: Refers to a communication scope where only one-to-one (1:1)
			communications are allowed. The scope can be identified between
			ingress and egress nodes, two service sites, etc.
			Hose: Refers to a communication scope where one-to-many (1:N)
			communications are allowed (e.g., one site to multiple sites).
			Funnel: Refers to a communication scope where many-to-one (N:1)
			communications are allowed.
	2.2. Acronyms		2.2. Acronyms
	The following acronyms are used in the document:		The following acronyms are used in the document:
	ACL Access Control List		ACL Access Control List
	CE Customer Edge		CE Customer Edge
	ECA Event Condition Action		ECA Event Condition Action
	L2VPN Layer 2 Virtual Private Network		L2VPN Layer 2 Virtual Private Network
	L3VPN Layer 3 Virtual Private Network		L3VPN Layer 3 Virtual Private Network
	NAT Network Address Translation		NAT Network Address Translation
	skipping to change at page 9, line 43 ¶		skipping to change at page 9, line 43 ¶
	| +-----------------------+ |		| +-----------------------+ |
	| | Device | Device Model |		| | Device | Device Model |
	| |+--------------------+ | |		| |+--------------------+ | |
	| || Device Modeling | | Interface add, BGP Peer, |		| || Device Modeling | | Interface add, BGP Peer, |
	| |+--------------------+ | Tunnel ID, QoS/TE, ... |		| |+--------------------+ | Tunnel ID, QoS/TE, ... |
	| +-----------------------+ |		| +-----------------------+ |
	+-----------------------------------------------------------------+		+-----------------------------------------------------------------+
	Figure 3: Layering and Representation		Figure 3: Layering and Representation
			The layering model depicted in Figure 3 does not make any assumption
			about the location of the various entities (e.g., controller,
			orchestrator) within the network. As such, the architecture does not
			preclude deployments where, for example, the controller is embedded
			on a device that hosts other functions that are controlled via YANG
			modules.
			In order to ease the mapping between layers and data reuse, this
			document focuses on service models that are modelled using YANG.
			Nevertheless, fully compliant with Section 3 of [RFC8309], Figure 3
			does not preclude service models to be modelled using other data
			modelling languages than YANG.
	3.2. Automation of Service Delivery Procedures		3.2. Automation of Service Delivery Procedures
	Service Models can be used by a Network Operator to expose its		Service Models can be used by a Network Operator to expose its
	services to its customers. Exposing such models allows to automate		services to its customers. Exposing such models allows to automate
	the activation of service orders and thus the service delivery. One		the activation of service orders and thus the service delivery. One
	or more monolithic Service Models can be used in the context of a		or more monolithic Service Models can be used in the context of a
	composite service activation request (e.g., delivery of a caching		composite service activation request (e.g., delivery of a caching
	infrastructure over a VPN). Such models are used to feed a decision-		infrastructure over a VPN). Such models are used to feed a decision-
	making intelligence to adequately accommodate customer's needs.		making intelligence to adequately accommodate customer's needs.
	Also, such models may be used jointly with services that require		Also, such models may be used jointly with services that require
	dynamic invocation. An example is provided by the service modules		dynamic invocation. An example is provided by the service modules
	defined by the DOTS WG to dynamically trigger requests to handle		defined by the DOTS WG to dynamically trigger requests to handle
	Distributed Denial-of-Service (DDoS) attacks [RFC8783].		Distributed Denial-of-Service (DDoS) attacks [RFC8783]. The service
			filtering request modelled using [RFC8783] will be translated into
			device-specific filtering (e.g., ACLs defined in [RFC8519]) that to
			fulfil the service request.
	Network Models can be derived from Service Models and used to		Network Models can be derived from Service Models and used to
	provision, monitor, instantiate the service, and provide lifecycle		provision, monitor, instantiate the service, and provide lifecycle
	management of network resources. Doing so is meant to:		management of network resources. Doing so is meant to:
	o expose network resources to customers (including other Network		o expose network resources to customers (including other Network
	Operators) to provide service fulfillment and assurance		Operators) to provide service fulfillment and assurance.
	o allow customers (or Network Operators) to dynamically adjust the		o allow customers (or Network Operators) to dynamically adjust the
	network resources based on service requirements as described in		network resources based on service requirements as described in
	Service Models (e.g., Figure 2) and the current network		Service Models (e.g., Figure 2) and the current network
	performance information described in the telemetry modules.		performance information described in the telemetry modules.
	3.3. Service Fullfillment Automation		3.3. Service Fullfillment Automation
	To operate a service, the settings of the parameters in the Device		To operate a service, the settings of the parameters in the Device
	Models are derived from Service Models and/or Network Models and are		Models are derived from Service Models and/or Network Models and are
	skipping to change at page 11, line 29 ¶		skipping to change at page 11, line 46 ¶
	depicted in Figure 2). Device Models will be tweaked accordingly to		depicted in Figure 2). Device Models will be tweaked accordingly to
	provide policy-based management. Policies can also be used for		provide policy-based management. Policies can also be used for
	telemetry automation, e.g., policies that contain conditions can		telemetry automation, e.g., policies that contain conditions can
	trigger the generation and pushing of new telemetry data.		trigger the generation and pushing of new telemetry data.
	Performance measurement telemetry can be used to provide service		Performance measurement telemetry can be used to provide service
	assurance at Service and/or Network levels. Performance measurement		assurance at Service and/or Network levels. Performance measurement
	telemetry model can tie with Service or Network Models to monitor		telemetry model can tie with Service or Network Models to monitor
	network performance or Service Level Agreement.		network performance or Service Level Agreement.
	4. Functional Bocks and Interactions		4. Functional Blocks and Interactions
	The architectural considerations described in Section 3 lead to the		The architectural considerations described in Section 3 lead to the
	architecture described in this section and illustrated in Figure 4.		architecture described in this section and illustrated in Figure 4.
	+------------------+		+------------------+
	................. | |		................. | |
	Service level | |		Service level | |
	V |		V |
	E2E E2E E2E E2E		E2E E2E E2E E2E
	Service --> Service ---------> Service -----> Service -----+		Service --> Service ---------> Service -----> Service -----+
	skipping to change at page 17, line 18 ¶		skipping to change at page 17, line 18 ¶
	Service Decomposing allows to decompose service model at the service		Service Decomposing allows to decompose service model at the service
	level or network model at the network level into a set of device/		level or network model at the network level into a set of device/
	function models at the device level. These Device Models may be tied		function models at the device level. These Device Models may be tied
	to specific device types or classified into a collection of related		to specific device types or classified into a collection of related
	YANG modules based on service types and features offered, and load at		YANG modules based on service types and features offered, and load at
	the implementation time before configuration is loaded and validated.		the implementation time before configuration is loaded and validated.
	5. YANG Data Model Integration Examples		5. YANG Data Model Integration Examples
	The following subsections provides some data models integration		The following subsections provides some YANG data models integration
	examples.		examples.
	5.1. L2VPN/L3VPN Service Delivery		5.1. L2VPN/L3VPN Service Delivery
	In reference to Figure 5, the following steps are performed to		In reference to Figure 5, the following steps are performed to
	deliver the L3VPN service within the network management automation		deliver the L3VPN service within the network management automation
	architecture defined in this document:		architecture defined in this document:
	1. The Customer requests to create two sites (as per service		1. The Customer requests to create two sites (as per service
	creation operation in Section 4.2.1) relying upon a L3SM Service		creation operation in Section 4.2.1) relying upon a L3SM Service
	skipping to change at page 19, line 39 ¶		skipping to change at page 19, line 39 ¶
	| | IP | |		| | IP | |
	+--+--+ +--+--+ +--+--+ +--+--+		+--+--+ +--+--+ +--+--+ +--+--+
	| CE1 +-------+ PE1 | | PE2 +---------+ CE2 |		| CE1 +-------+ PE1 | | PE2 +---------+ CE2 |
	+-----+ +-----+ +-----+ +-----+		+-----+ +-----+ +-----+ +-----+
	Figure 6: L3VPN Service Delivery Example (Target)		Figure 6: L3VPN Service Delivery Example (Target)
	Note that a similar analysis can be performed for Layer 2 VPNs		Note that a similar analysis can be performed for Layer 2 VPNs
	(L2VPNs). A L2VPN Service Model (L2SM) is defined in [RFC8466],		(L2VPNs). A L2VPN Service Model (L2SM) is defined in [RFC8466],
	while the L2VPN Network YANG Model (L2NM) is specified in		while the L2VPN Network YANG Model (L2NM) is specified in
	[I-D.barguil-opsawg-l2sm-l2nm].		[I-D.ietf-opsawg-l2nm].
	5.2. VN Lifecycle Management		5.2. VN Lifecycle Management
	In reference to Figure 7, the following steps are performed to		In reference to Figure 7, the following steps are performed to
	deliver the VN service within the network management automation		deliver the VN service within the network management automation
	architecture defined in this document:		architecture defined in this document:
	1. Customer requests (service exposure operation in Section 4.1.1)		1. Customer requests (service exposure operation in Section 4.1.1)
	to create 'VN' based on Access point, association between VN and		to create 'VN' based on Access point, association between VN and
	Access point, VN member defined in the VN YANG module.		Access point, VN member defined in the VN YANG module.
	skipping to change at page 22, line 37 ¶		skipping to change at page 22, line 37 ¶
	7. IANA Considerations		7. IANA Considerations
	There are no IANA requests or assignments included in this document.		There are no IANA requests or assignments included in this document.
	8. Acknowledgements		8. Acknowledgements
	Thanks to Joe Clark, Greg Mirsky, Shunsuke Homma, Brian Carpenter,		Thanks to Joe Clark, Greg Mirsky, Shunsuke Homma, Brian Carpenter,
	and Adrian Farrel for the review.		and Adrian Farrel for the review.
			Many thanks to Robert Wilton for the detailed AD review.
	9. Contributors		9. Contributors
	Christian Jacquenet		Christian Jacquenet
	Orange		Orange
	Rennes, 35000		Rennes, 35000
	France		France
	Email: Christian.jacquenet@orange.com		Email: Christian.jacquenet@orange.com
	Luis Miguel Contreras Murillo		Luis Miguel Contreras Murillo
	Telifonica		Telifonica
	skipping to change at page 24, line 16 ¶		skipping to change at page 24, line 16 ¶
	Access Control Model", STD 91, RFC 8341,		Access Control Model", STD 91, RFC 8341,
	DOI 10.17487/RFC8341, March 2018,		DOI 10.17487/RFC8341, March 2018,
	<https://www.rfc-editor.org/info/rfc8341>.		<https://www.rfc-editor.org/info/rfc8341>.
	[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol		[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
	Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,		Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
	<https://www.rfc-editor.org/info/rfc8446>.		<https://www.rfc-editor.org/info/rfc8446>.
	10.2. Informative References		10.2. Informative References
	[I-D.barguil-opsawg-l2sm-l2nm]		[I-D.clacla-netmod-model-catalog]
	Barguil, S., Dios, O., Boucadair, M., Munoz, L., Jalil,		Clarke, J. and B. Claise, "YANG module for
	L., and J. Ma, "A Layer 2 VPN Network YANG Model", draft-		yangcatalog.org", draft-clacla-netmod-model-catalog-03
	barguil-opsawg-l2sm-l2nm-02 (work in progress), May 2020.		(work in progress), April 2018.
	[I-D.ietf-bess-evpn-yang]		[I-D.ietf-bess-evpn-yang]
	Brissette, P., Shah, H., Hussain, I., Tiruveedhula, K.,		Brissette, P., Shah, H., Hussain, I., Tiruveedhula, K.,
	and J. Rabadan, "Yang Data Model for EVPN", draft-ietf-		and J. Rabadan, "Yang Data Model for EVPN", draft-ietf-
	bess-evpn-yang-07 (work in progress), March 2019.		bess-evpn-yang-07 (work in progress), March 2019.
	[I-D.ietf-bess-l2vpn-yang]		[I-D.ietf-bess-l2vpn-yang]
	Shah, H., Brissette, P., Chen, I., Hussain, I., Wen, B.,		Shah, H., Brissette, P., Chen, I., Hussain, I., Wen, B.,
	and K. Tiruveedhula, "YANG Data Model for MPLS-based		and K. Tiruveedhula, "YANG Data Model for MPLS-based
	L2VPN", draft-ietf-bess-l2vpn-yang-10 (work in progress),		L2VPN", draft-ietf-bess-l2vpn-yang-10 (work in progress),
	skipping to change at page 24, line 41 ¶		skipping to change at page 24, line 41 ¶
	[I-D.ietf-bess-l3vpn-yang]		[I-D.ietf-bess-l3vpn-yang]
	Jain, D., Patel, K., Brissette, P., Li, Z., Zhuang, S.,		Jain, D., Patel, K., Brissette, P., Li, Z., Zhuang, S.,
	Liu, X., Haas, J., Esale, S., and B. Wen, "Yang Data Model		Liu, X., Haas, J., Esale, S., and B. Wen, "Yang Data Model
	for BGP/MPLS L3 VPNs", draft-ietf-bess-l3vpn-yang-04 (work		for BGP/MPLS L3 VPNs", draft-ietf-bess-l3vpn-yang-04 (work
	in progress), October 2018.		in progress), October 2018.
	[I-D.ietf-bess-mvpn-yang]		[I-D.ietf-bess-mvpn-yang]
	Liu, Y., Guo, F., Litkowski, S., Liu, X., Kebler, R., and		Liu, Y., Guo, F., Litkowski, S., Liu, X., Kebler, R., and
	M. Sivakumar, "Yang Data Model for Multicast in MPLS/BGP		M. Sivakumar, "Yang Data Model for Multicast in MPLS/BGP
	IP VPNs", draft-ietf-bess-mvpn-yang-02 (work in progress),		IP VPNs", draft-ietf-bess-mvpn-yang-04 (work in progress),
	December 2019.		June 2020.
	[I-D.ietf-bfd-yang]		[I-D.ietf-bfd-yang]
	Rahman, R., Zheng, L., Jethanandani, M., Pallagatti, S.,		Rahman, R., Zheng, L., Jethanandani, M., Pallagatti, S.,
	and G. Mirsky, "YANG Data Model for Bidirectional		and G. Mirsky, "YANG Data Model for Bidirectional
	Forwarding Detection (BFD)", draft-ietf-bfd-yang-17 (work		Forwarding Detection (BFD)", draft-ietf-bfd-yang-17 (work
	in progress), August 2018.		in progress), August 2018.
	[I-D.ietf-i2rs-yang-l2-network-topology]		[I-D.ietf-i2rs-yang-l2-network-topology]
	Dong, J., Wei, X., WU, Q., Boucadair, M., and A. Liu, "A		Dong, J., Wei, X., WU, Q., Boucadair, M., and A. Liu, "A
	YANG Data Model for Layer-2 Network Topologies", draft-		YANG Data Model for Layer 2 Network Topologies", draft-
	ietf-i2rs-yang-l2-network-topology-13 (work in progress),		ietf-i2rs-yang-l2-network-topology-17 (work in progress),
	March 2020.		August 2020.
	[I-D.ietf-idr-bgp-model]		[I-D.ietf-idr-bgp-model]
	Jethanandani, M., Patel, K., Hares, S., and J. Haas, "BGP		Jethanandani, M., Patel, K., Hares, S., and J. Haas, "BGP
	YANG Model for Service Provider Networks", draft-ietf-idr-		YANG Model for Service Provider Networks", draft-ietf-idr-
	bgp-model-08 (work in progress), February 2020.		bgp-model-09 (work in progress), June 2020.
	[I-D.ietf-ippm-capacity-metric-method]		[I-D.ietf-ippm-capacity-metric-method]
	Morton, A., Geib, R., and L. Ciavattone, "Metrics and		Morton, A., Geib, R., and L. Ciavattone, "Metrics and
	Methods for IP Capacity", draft-ietf-ippm-capacity-metric-		Methods for IP Capacity", draft-ietf-ippm-capacity-metric-
	method-01 (work in progress), March 2020.		method-03 (work in progress), August 2020.
	[I-D.ietf-ippm-stamp-yang]		[I-D.ietf-ippm-stamp-yang]
	Mirsky, G., Xiao, M., and W. Luo, "Simple Two-way Active		Mirsky, G., Xiao, M., and W. Luo, "Simple Two-way Active
	Measurement Protocol (STAMP) Data Model", draft-ietf-ippm-		Measurement Protocol (STAMP) Data Model", draft-ietf-ippm-
	stamp-yang-05 (work in progress), October 2019.		stamp-yang-05 (work in progress), October 2019.
	[I-D.ietf-ippm-twamp-yang]		[I-D.ietf-ippm-twamp-yang]
	Civil, R., Morton, A., Rahman, R., Jethanandani, M., and		Civil, R., Morton, A., Rahman, R., Jethanandani, M., and
	K. Pentikousis, "Two-Way Active Measurement Protocol		K. Pentikousis, "Two-Way Active Measurement Protocol
	(TWAMP) Data Model", draft-ietf-ippm-twamp-yang-13 (work		(TWAMP) Data Model", draft-ietf-ippm-twamp-yang-13 (work
	in progress), July 2018.		in progress), July 2018.
	[I-D.ietf-mpls-base-yang]		[I-D.ietf-mpls-base-yang]
	Saad, T., Raza, K., Gandhi, R., Liu, X., and V. Beeram, "A		Saad, T., Raza, K., Gandhi, R., Liu, X., and V. Beeram, "A
	YANG Data Model for MPLS Base", draft-ietf-mpls-base-		YANG Data Model for MPLS Base", draft-ietf-mpls-base-
	yang-14 (work in progress), March 2020.		yang-15 (work in progress), August 2020.
			[I-D.ietf-netmod-module-tags]
			Hopps, C., Berger, L., and D. Bogdanovic, "YANG Module
			Tags", draft-ietf-netmod-module-tags-10 (work in
			progress), February 2020.
			[I-D.ietf-opsawg-l2nm]
			barguil, s., Dios, O., Boucadair, M., Munoz, L., Jalil,
			L., and J. Ma, "A Layer 2 VPN Network YANG Model", draft-
			ietf-opsawg-l2nm-00 (work in progress), July 2020.
	[I-D.ietf-opsawg-l3sm-l3nm]		[I-D.ietf-opsawg-l3sm-l3nm]
	Barguil, S., Dios, O., Boucadair, M., Munoz, L., and A.		barguil, s., Dios, O., Boucadair, M., Munoz, L., and A.
	Aguado, "A Layer 3 VPN Network YANG Model", draft-ietf-		Aguado, "A Layer 3 VPN Network YANG Model", draft-ietf-
	opsawg-l3sm-l3nm-03 (work in progress), April 2020.		opsawg-l3sm-l3nm-03 (work in progress), April 2020.
	[I-D.ietf-pim-igmp-mld-snooping-yang]		[I-D.ietf-pim-igmp-mld-snooping-yang]
	Zhao, H., Liu, X., Liu, Y., Sivakumar, M., and A. Peter,		Zhao, H., Liu, X., Liu, Y., Sivakumar, M., and A. Peter,
	"A Yang Data Model for IGMP and MLD Snooping", draft-ietf-		"A Yang Data Model for IGMP and MLD Snooping", draft-ietf-
	pim-igmp-mld-snooping-yang-12 (work in progress), May		pim-igmp-mld-snooping-yang-18 (work in progress), August
	2020.		2020.
	[I-D.ietf-pim-yang]		[I-D.ietf-pim-yang]
	Liu, X., McAllister, P., Peter, A., Sivakumar, M., Liu,		Liu, X., McAllister, P., Peter, A., Sivakumar, M., Liu,
	Y., and f. hu, "A YANG Data Model for Protocol Independent		Y., and f. hu, "A YANG Data Model for Protocol Independent
	Multicast (PIM)", draft-ietf-pim-yang-17 (work in		Multicast (PIM)", draft-ietf-pim-yang-17 (work in
	progress), May 2018.		progress), May 2018.
	[I-D.ietf-rtgwg-device-model]
	Lindem, A., Berger, L., Bogdanovic, D., and C. Hopps,
	"Network Device YANG Logical Organization", draft-ietf-
	rtgwg-device-model-02 (work in progress), March 2017.
	[I-D.ietf-rtgwg-policy-model]		[I-D.ietf-rtgwg-policy-model]
	Qu, Y., Tantsura, J., Lindem, A., and X. Liu, "A YANG Data		Qu, Y., Tantsura, J., Lindem, A., and X. Liu, "A YANG Data
	Model for Routing Policy Management", draft-ietf-rtgwg-		Model for Routing Policy Management", draft-ietf-rtgwg-
	policy-model-15 (work in progress), June 2020.		policy-model-21 (work in progress), September 2020.
	[I-D.ietf-rtgwg-qos-model]		[I-D.ietf-rtgwg-qos-model]
	Choudhary, A., Jethanandani, M., Strahle, N., Aries, E.,		Choudhary, A., Jethanandani, M., Strahle, N., Aries, E.,
	and I. Chen, "YANG Model for QoS", draft-ietf-rtgwg-qos-		and I. Chen, "YANG Model for QoS", draft-ietf-rtgwg-qos-
	model-01 (work in progress), April 2020.		model-02 (work in progress), July 2020.
	[I-D.ietf-spring-sr-yang]		[I-D.ietf-spring-sr-yang]
	Litkowski, S., Qu, Y., Lindem, A., Sarkar, P., and J.		Litkowski, S., Qu, Y., Lindem, A., Sarkar, P., and J.
	Tantsura, "YANG Data Model for Segment Routing", draft-		Tantsura, "YANG Data Model for Segment Routing", draft-
	ietf-spring-sr-yang-15 (work in progress), January 2020.		ietf-spring-sr-yang-22 (work in progress), August 2020.
	[I-D.ietf-supa-generic-policy-data-model]
	Halpern, J. and J. Strassner, "Generic Policy Data Model
	for Simplified Use of Policy Abstractions (SUPA)", draft-
	ietf-supa-generic-policy-data-model-04 (work in progress),
	June 2017.
	[I-D.ietf-teas-actn-pm-telemetry-autonomics]		[I-D.ietf-teas-actn-pm-telemetry-autonomics]
	Lee, Y., Dhody, D., Karunanithi, S., Vilata, R., King, D.,		Lee, Y., Dhody, D., Karunanithi, S., Vilata, R., King, D.,
	and D. Ceccarelli, "YANG models for VN/TE Performance		and D. Ceccarelli, "YANG models for VN/TE Performance
	Monitoring Telemetry and Scaling Intent Autonomics",		Monitoring Telemetry and Scaling Intent Autonomics",
	draft-ietf-teas-actn-pm-telemetry-autonomics-02 (work in		draft-ietf-teas-actn-pm-telemetry-autonomics-03 (work in
	progress), March 2020.		progress), July 2020.
	[I-D.ietf-teas-actn-vn-yang]		[I-D.ietf-teas-actn-vn-yang]
	Lee, Y., Dhody, D., Ceccarelli, D., Bryskin, I., and B.		Lee, Y., Dhody, D., Ceccarelli, D., Bryskin, I., and B.
	Yoon, "A Yang Data Model for VN Operation", draft-ietf-		Yoon, "A YANG Data Model for VN Operation", draft-ietf-
	teas-actn-vn-yang-08 (work in progress), March 2020.		teas-actn-vn-yang-09 (work in progress), July 2020.
	[I-D.ietf-teas-yang-path-computation]		[I-D.ietf-teas-yang-path-computation]
	Busi, I., Belotti, S., Lopezalvarez, V., Sharma, A., and		Busi, I., Belotti, S., Lopezalvarez, V., Sharma, A., and
	Y. Shi, "Yang model for requesting Path Computation",		Y. Shi, "Yang model for requesting Path Computation",
	draft-ietf-teas-yang-path-computation-09 (work in		draft-ietf-teas-yang-path-computation-10 (work in
	progress), June 2020.		progress), July 2020.
	[I-D.ietf-teas-yang-rsvp-te]		[I-D.ietf-teas-yang-rsvp-te]
	Beeram, V., Saad, T., Gandhi, R., Liu, X., Bryskin, I.,		Beeram, V., Saad, T., Gandhi, R., Liu, X., Bryskin, I.,
	and H. Shah, "A YANG Data Model for RSVP-TE Protocol",		and H. Shah, "A YANG Data Model for RSVP-TE Protocol",
	draft-ietf-teas-yang-rsvp-te-08 (work in progress), March		draft-ietf-teas-yang-rsvp-te-08 (work in progress), March
	2020.		2020.
	[I-D.ietf-teas-yang-te]		[I-D.ietf-teas-yang-te]
	Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin,		Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin,
	"A YANG Data Model for Traffic Engineering Tunnels and		"A YANG Data Model for Traffic Engineering Tunnels, Label
	Interfaces", draft-ietf-teas-yang-te-23 (work in		Switched Paths and Interfaces", draft-ietf-teas-yang-te-25
	progress), March 2020.		(work in progress), July 2020.
	[I-D.ietf-teas-yang-te-topo]
	Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and
	O. Dios, "YANG Data Model for Traffic Engineering (TE)
	Topologies", draft-ietf-teas-yang-te-topo-22 (work in
	progress), June 2019.
	[I-D.ietf-trill-yang-oam]		[I-D.ietf-trill-yang-oam]
	Kumar, D., Senevirathne, T., Finn, N., Salam, S., Xia, L.,		Kumar, D., Senevirathne, T., Finn, N., Salam, S., Xia, L.,
	and H. Weiguo, "YANG Data Model for TRILL Operations,		and H. Weiguo, "YANG Data Model for TRILL Operations,
	Administration, and Maintenance (OAM)", draft-ietf-trill-		Administration, and Maintenance (OAM)", draft-ietf-trill-
	yang-oam-05 (work in progress), March 2017.		yang-oam-05 (work in progress), March 2017.
	[I-D.ogondio-opsawg-uni-topology]		[I-D.ogondio-opsawg-uni-topology]
	Dios, O., Barguil, S., WU, Q., and M. Boucadair, "A YANG		Dios, O., barguil, s., WU, Q., and M. Boucadair, "A YANG
	Model for User-Network Interface (UNI) Topologies", draft-		Model for User-Network Interface (UNI) Topologies", draft-
	ogondio-opsawg-uni-topology-01 (work in progress), April		ogondio-opsawg-uni-topology-01 (work in progress), April
	2020.		2020.
	[I-D.www-bess-yang-vpn-service-pm]		[I-D.www-bess-yang-vpn-service-pm]
	WU, Q., Boucadair, M., Dios, O., Wen, B., Liu, C., and H.		WU, Q., Boucadair, M., Dios, O., Wen, B., Liu, C., and H.
	Xu, "A YANG Model for Network and VPN Service Performance		Xu, "A YANG Model for Network and VPN Service Performance
	Monitoring", draft-www-bess-yang-vpn-service-pm-06 (work		Monitoring", draft-www-bess-yang-vpn-service-pm-06 (work
	in progress), April 2020.		in progress), April 2020.
	[I-D.wwx-netmod-event-yang]		[I-D.wwx-netmod-event-yang]
	Birkholz, H., WU, Q., Bryskin, I., Liu, X., and B. Claise,		Bierman, A., WU, Q., Bryskin, I., Birkholz, H., Liu, X.,
	"A YANG Data model for ECA Policy Management", draft-wwx-		and B. Claise, "A YANG Data model for ECA Policy
	netmod-event-yang-07 (work in progress), May 2020.		Management", draft-wwx-netmod-event-yang-09 (work in
			progress), July 2020.
	[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private		[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
	Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February		Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
	2006, <https://www.rfc-editor.org/info/rfc4364>.		2006, <https://www.rfc-editor.org/info/rfc4364>.
	[RFC4664] Andersson, L., Ed. and E. Rosen, Ed., "Framework for Layer		[RFC4664] Andersson, L., Ed. and E. Rosen, Ed., "Framework for Layer
	2 Virtual Private Networks (L2VPNs)", RFC 4664,		2 Virtual Private Networks (L2VPNs)", RFC 4664,
	DOI 10.17487/RFC4664, September 2006,		DOI 10.17487/RFC4664, September 2006,
	<https://www.rfc-editor.org/info/rfc4664>.		<https://www.rfc-editor.org/info/rfc4664>.
	skipping to change at page 28, line 43 ¶		skipping to change at page 28, line 38 ¶
	[RFC6406] Malas, D., Ed. and J. Livingood, Ed., "Session PEERing for		[RFC6406] Malas, D., Ed. and J. Livingood, Ed., "Session PEERing for
	Multimedia INTerconnect (SPEERMINT) Architecture",		Multimedia INTerconnect (SPEERMINT) Architecture",
	RFC 6406, DOI 10.17487/RFC6406, November 2011,		RFC 6406, DOI 10.17487/RFC6406, November 2011,
	<https://www.rfc-editor.org/info/rfc6406>.		<https://www.rfc-editor.org/info/rfc6406>.
	[RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined		[RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined
	Networking: A Perspective from within a Service Provider		Networking: A Perspective from within a Service Provider
	Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014,		Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014,
	<https://www.rfc-editor.org/info/rfc7149>.		<https://www.rfc-editor.org/info/rfc7149>.
			[RFC7224] Bjorklund, M., "IANA Interface Type YANG Module",
			RFC 7224, DOI 10.17487/RFC7224, May 2014,
			<https://www.rfc-editor.org/info/rfc7224>.
	[RFC7276] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y.		[RFC7276] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y.
	Weingarten, "An Overview of Operations, Administration,		Weingarten, "An Overview of Operations, Administration,
	and Maintenance (OAM) Tools", RFC 7276,		and Maintenance (OAM) Tools", RFC 7276,
	DOI 10.17487/RFC7276, June 2014,		DOI 10.17487/RFC7276, June 2014,
	<https://www.rfc-editor.org/info/rfc7276>.		<https://www.rfc-editor.org/info/rfc7276>.
	[RFC7297] Boucadair, M., Jacquenet, C., and N. Wang, "IP		[RFC7297] Boucadair, M., Jacquenet, C., and N. Wang, "IP
	Connectivity Provisioning Profile (CPP)", RFC 7297,		Connectivity Provisioning Profile (CPP)", RFC 7297,
	DOI 10.17487/RFC7297, July 2014,		DOI 10.17487/RFC7297, July 2014,
	<https://www.rfc-editor.org/info/rfc7297>.		<https://www.rfc-editor.org/info/rfc7297>.
	skipping to change at page 29, line 43 ¶		skipping to change at page 29, line 43 ¶
	[RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki,		[RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki,
	"YANG Data Model for L3VPN Service Delivery", RFC 8299,		"YANG Data Model for L3VPN Service Delivery", RFC 8299,
	DOI 10.17487/RFC8299, January 2018,		DOI 10.17487/RFC8299, January 2018,
	<https://www.rfc-editor.org/info/rfc8299>.		<https://www.rfc-editor.org/info/rfc8299>.
	[RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models		[RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models
	Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018,		Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018,
	<https://www.rfc-editor.org/info/rfc8309>.		<https://www.rfc-editor.org/info/rfc8309>.
	[RFC8328] Liu, W., Xie, C., Strassner, J., Karagiannis, G., Klyus,
	M., Bi, J., Cheng, Y., and D. Zhang, "Policy-Based
	Management Framework for the Simplified Use of Policy
	Abstractions (SUPA)", RFC 8328, DOI 10.17487/RFC8328,
	March 2018, <https://www.rfc-editor.org/info/rfc8328>.
	[RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N.,		[RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N.,
	Ananthakrishnan, H., and X. Liu, "A YANG Data Model for		Ananthakrishnan, H., and X. Liu, "A YANG Data Model for
	Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March		Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March
	2018, <https://www.rfc-editor.org/info/rfc8345>.		2018, <https://www.rfc-editor.org/info/rfc8345>.
	[RFC8346] Clemm, A., Medved, J., Varga, R., Liu, X.,		[RFC8346] Clemm, A., Medved, J., Varga, R., Liu, X.,
	Ananthakrishnan, H., and N. Bahadur, "A YANG Data Model		Ananthakrishnan, H., and N. Bahadur, "A YANG Data Model
	for Layer 3 Topologies", RFC 8346, DOI 10.17487/RFC8346,		for Layer 3 Topologies", RFC 8346, DOI 10.17487/RFC8346,
	March 2018, <https://www.rfc-editor.org/info/rfc8346>.		March 2018, <https://www.rfc-editor.org/info/rfc8346>.
	skipping to change at page 32, line 5 ¶		skipping to change at page 31, line 44 ¶
	[RFC8676] Farrer, I., Ed. and M. Boucadair, Ed., "YANG Modules for		[RFC8676] Farrer, I., Ed. and M. Boucadair, Ed., "YANG Modules for
	IPv4-in-IPv6 Address plus Port (A+P) Softwires", RFC 8676,		IPv4-in-IPv6 Address plus Port (A+P) Softwires", RFC 8676,
	DOI 10.17487/RFC8676, November 2019,		DOI 10.17487/RFC8676, November 2019,
	<https://www.rfc-editor.org/info/rfc8676>.		<https://www.rfc-editor.org/info/rfc8676>.
	[RFC8783] Boucadair, M., Ed. and T. Reddy.K, Ed., "Distributed		[RFC8783] Boucadair, M., Ed. and T. Reddy.K, Ed., "Distributed
	Denial-of-Service Open Threat Signaling (DOTS) Data		Denial-of-Service Open Threat Signaling (DOTS) Data
	Channel Specification", RFC 8783, DOI 10.17487/RFC8783,		Channel Specification", RFC 8783, DOI 10.17487/RFC8783,
	May 2020, <https://www.rfc-editor.org/info/rfc8783>.		May 2020, <https://www.rfc-editor.org/info/rfc8783>.
			[RFC8795] Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and
			O. Gonzalez de Dios, "YANG Data Model for Traffic
			Engineering (TE) Topologies", RFC 8795,
			DOI 10.17487/RFC8795, August 2020,
			<https://www.rfc-editor.org/info/rfc8795>.
	Appendix A. Layered YANG Modules Examples Overview		Appendix A. Layered YANG Modules Examples Overview
	This appendix lists a set of data models that can be used for the		This appendix lists a set of YANG data models that can be used for
	delivery of connectivity services. These models can be classified as		the delivery of connectivity services. These models can be
	Service, Network, or Device Models.		classified as Service, Network, or Device Models.
	It is not the intent of this appendix to provide an inventory of		It is not the intent of this appendix to provide an inventory of
	tools and mechanisms used in specific network and service management		tools and mechanisms used in specific network and service management
	domains; such inventory can be found in documents such as [RFC7276].		domains; such inventory can be found in documents such as [RFC7276].
			The reader may refer to the YANG Catalog
			(<https://www.yangcatalog.org>) or the public Github YANG repository
			(<https://github.com/YangModels/yang>) to query existing YANG models.
			The YANG Catalog includes some metadata to indicate the module type
			('module-classification') [I-D.clacla-netmod-model-catalog]. Note
			that the mechanism defined in [I-D.ietf-netmod-module-tags] allows to
			associate tags with YANG modules in order to help classifying the
			modules.
	A.1. Service Models: Definition and Samples		A.1. Service Models: Definition and Samples
	As described in [RFC8309], the service is "some form of connectivity		As described in [RFC8309], the service is "some form of connectivity
	between customer sites and the Internet and/or between customer sites		between customer sites and the Internet and/or between customer sites
	across the Network Operator's network and across the Internet". More		across the Network Operator's network and across the Internet". More
	concretely, an IP connectivity service can be defined as the IP		concretely, an IP connectivity service can be defined as the IP
	transfer capability characterized by a (Source Nets, Destination		transfer capability characterized by a (Source Nets, Destination
	Nets, Guarantees, Scope) tuple where "Source Nets" is a group of		Nets, Guarantees, Scope) tuple where "Source Nets" is a group of
	unicast IP addresses, "Destination Nets" is a group of IP unicast		unicast IP addresses, "Destination Nets" is a group of IP unicast
	and/or multicast addresses, and "Guarantees" reflects the guarantees		and/or multicast addresses, and "Guarantees" reflects the guarantees
	skipping to change at page 32, line 44 ¶		skipping to change at page 33, line 7 ¶
	o The L2SM model [RFC8466] defines the L2VPN service ordered by a		o The L2SM model [RFC8466] defines the L2VPN service ordered by a
	customer from a Network Operator.		customer from a Network Operator.
	o The Virtual Network (VN) model [I-D.ietf-teas-actn-vn-yang]		o The Virtual Network (VN) model [I-D.ietf-teas-actn-vn-yang]
	provides a YANG data model applicable to any mode of VN operation.		provides a YANG data model applicable to any mode of VN operation.
	L2SM and L3SM are customer service models as per [RFC8309].		L2SM and L3SM are customer service models as per [RFC8309].
	A.2. Network Models: Samples		A.2. Network Models: Samples
	L2NM [I-D.barguil-opsawg-l2sm-l2nm] and L3NM		L2NM [I-D.ietf-opsawg-l2nm] and L3NM [I-D.ietf-opsawg-l3sm-l3nm] are
	[I-D.ietf-opsawg-l3sm-l3nm] are examples of YANG Network Models.		examples of YANG Network Models.
	Figure 9 depicts a set of additional Network Models such as topology		Figure 9 depicts a set of additional Network Models such as topology
	and tunnel models:		and tunnel models:
	+-------------------------------+-------------------------------+		+-------------------------------+-------------------------------+
	| Topology YANG modules | Tunnel YANG modules |		| Topology YANG modules | Tunnel YANG modules |
	+-------------------------------+-------------------------------+		+-------------------------------+-------------------------------+
	| +------------+ | |		| +------------+ | |
	| |Network Topo| | +------+ +-----------+ |		| |Network Topo| | +------+ +-----------+ |
	| | Model | | |Other | | TE Tunnel | |		| | Model | | |Other | | TE Tunnel | |
	skipping to change at page 33, line 38 ¶		skipping to change at page 33, line 46 ¶
	Svc: Service		Svc: Service
	Figure 9: Sample Resource Facing Network Models		Figure 9: Sample Resource Facing Network Models
	Examples of topology YANG modules are listed below:		Examples of topology YANG modules are listed below:
	o Network Topology Models: [RFC8345] defines a base model for		o Network Topology Models: [RFC8345] defines a base model for
	network topology and inventories. Network topology data include		network topology and inventories. Network topology data include
	link resource, node resource, and terminate-point resources.		link resource, node resource, and terminate-point resources.
	o TE Topology Models: [I-D.ietf-teas-yang-te-topo] defines a data		o TE Topology Models: [RFC8795] defines a YANG data model for
	model for representing and manipulating TE topologies.		representing and manipulating TE topologies.
	This module is extended from network topology model defined in		This module is extended from network topology model defined in
	[RFC8345] with TE topologies specifics. This model contains		[RFC8345] with TE topologies specifics. This model contains
	technology-agnostic TE Topology building blocks that can be		technology-agnostic TE Topology building blocks that can be
	augmented and used by other technology-specific TE topology		augmented and used by other technology-specific TE topology
	models.		models.
	o Layer 3 Topology Models:		o Layer 3 Topology Models:
	[RFC8346] defines a data model for representing and manipulating		[RFC8346] defines a YANG data model for representing and
	Layer 3 topologies. This model is extended from the network		manipulating Layer 3 topologies. This model is extended from the
	topology model defined in [RFC8345] with Layer 3 topologies		network topology model defined in [RFC8345] with Layer 3
	specifics.		topologies specifics.
	o Layer 2 Topology Models:		o Layer 2 Topology Models:
	[I-D.ietf-i2rs-yang-l2-network-topology] defines a data model for		[I-D.ietf-i2rs-yang-l2-network-topology] defines a YANG data model
	representing and manipulating Layer 2 topologies. This model is		for representing and manipulating Layer 2 topologies. This model
	extended from the network topology model defined in [RFC8345] with		is extended from the network topology model defined in [RFC8345]
	Layer 2 topologies specifics.		with Layer 2 topologies specifics.
	Examples of tunnel YANG modules are provided below:		Examples of tunnel YANG modules are provided below:
	o Tunnel identities to ease manipulating extensions to specific		o Tunnel identities: [RFC8675] defines a collection of YANG
	tunnels [RFC8675].		identities used as interface types for tunnel interfaces.
	o TE Tunnel Model:		o TE Tunnel Model:
	[I-D.ietf-teas-yang-te] defines a YANG module for the		[I-D.ietf-teas-yang-te] defines a YANG module for the
	configuration and management of TE interfaces, tunnels, and LSPs.		configuration and management of TE interfaces, tunnels, and LSPs.
	o Segment Routing (SR) Traffic Engineering (TE) Tunnel Model:		o Segment Routing (SR) Traffic Engineering (TE) Tunnel Model:
	[I-D.ietf-teas-yang-te] augments the TE generic and MPLS-TE		[I-D.ietf-teas-yang-te] augments the TE generic and MPLS-TE
	model(s) and defines a YANG module for SR-TE specific data.		model(s) and defines a YANG module for SR-TE specific data.
	skipping to change at page 35, line 14 ¶		skipping to change at page 35, line 25 ¶
	protocols. [RFC8531] defines a base YANG module for connection		protocols. [RFC8531] defines a base YANG module for connection
	oriented OAM protocols. These three models are intended to		oriented OAM protocols. These three models are intended to
	provide consistent reporting, configuration, and representation		provide consistent reporting, configuration, and representation
	for connection-less OAM and Connection oriented OAM separately.		for connection-less OAM and Connection oriented OAM separately.
	Alarm monitoring is a fundamental part of monitoring the network.		Alarm monitoring is a fundamental part of monitoring the network.
	Raw alarms from devices do not always tell the status of the		Raw alarms from devices do not always tell the status of the
	network services or necessarily point to the root cause.		network services or necessarily point to the root cause.
	[RFC8632] defines a YANG module for alarm management.		[RFC8632] defines a YANG module for alarm management.
	o Generic Policy Model:
	The Simplified Use of Policy Abstractions (SUPA) policy-based
	management framework [RFC8328] defines base YANG modules
	[I-D.ietf-supa-generic-policy-data-model] to encode policy. These
	models point to other device-, technology-, and service-specific
	YANG modules. Policy rules within an operator's environment can
	be used to express high-level, possibly network-wide, policies to
	a network management function (within a controller, an
	orchestrator, or a network element). The network management
	function can then control the configuration and/or monitoring of
	network elements and services. This document describes the SUPA
	basic framework, its elements, and interfaces.
	A.3. Device Models: Samples		A.3. Device Models: Samples
	Network Element models (Figure 10) are used to describe how a service		Network Element models (Figure 10) are used to describe how a service
	can be implemented by activating and tweaking a set of functions		can be implemented by activating and tweaking a set of functions
	(enabled in one or multiple devices, or hosted in cloud		(enabled in one or multiple devices, or hosted in cloud
	infrastructures) that are involved in the service delivery.		infrastructures) that are involved in the service delivery.
	Figure 10 uses IETF-defined models as an example.		Figure 10 uses IETF-defined data models as an example.
	+------------------------+		+------------------------+
	+-+ Device Model |		+-+ Device Model |
	| +------------------------+		| +------------------------+
	| +------------------------+		| +------------------------+
	+---------------+ | | Logical Network |		+---------------+ | | Logical Network |
	| | +-+ Element Model |		| | +-+ Element Model |
	| Architecture | | +------------------------+		| Architecture | | +------------------------+
	| | | +------------------------+		| | | +------------------------+
	+-------+-------+ +-+ Network Instance Model |		+-------+-------+ +-+ Network Instance Model |
	skipping to change at page 37, line 7 ¶		skipping to change at page 37, line 7 ¶
	+-+ISIS-SR|		+-+ISIS-SR|
	| +-------+		| +-------+
	| +-------+		| +-------+
	+-+OSPF-SR|		+-+OSPF-SR|
	+-------+		+-------+
	Figure 10: Network Element Modules Overview		Figure 10: Network Element Modules Overview
	A.3.1. Model Composition		A.3.1. Model Composition
	o Device Model
	[I-D.ietf-rtgwg-device-model] presents an approach for organizing
	YANG modules in a comprehensive logical structure that may be used
	to configure and operate network devices. The structure is itself
	represented as an example YANG module, with all of the related
	component models logically organized in a way that is
	operationally intuitive, but this model is not expected to be
	implemented.
	o Logical Network Element Model		o Logical Network Element Model
	[RFC8530] defines a logical network element module which can be		[RFC8530] defines a logical network element module which can be
	used to manage the logical resource partitioning that may be		used to manage the logical resource partitioning that may be
	present on a network device. Examples of common industry terms		present on a network device. Examples of common industry terms
	for logical resource partitioning are Logical Systems or Logical		for logical resource partitioning are Logical Systems or Logical
	Routers.		Routers.
	o Network Instance Model		o Network Instance Model
	skipping to change at page 37, line 44 ¶		skipping to change at page 37, line 34 ¶
	Modularity and extensibility were among the leading design principles		Modularity and extensibility were among the leading design principles
	of the YANG data modeling language. As a result, the same YANG		of the YANG data modeling language. As a result, the same YANG
	module can be combined with various sets of other modules and thus		module can be combined with various sets of other modules and thus
	form a data model that is tailored to meet the requirements of a		form a data model that is tailored to meet the requirements of a
	specific use case. [RFC8528] defines a mechanism, denoted schema		specific use case. [RFC8528] defines a mechanism, denoted schema
	mount, that allows for mounting one data model consisting of any		mount, that allows for mounting one data model consisting of any
	number of YANG modules at a specified location of another (parent)		number of YANG modules at a specified location of another (parent)
	schema.		schema.
	That capability does not cover design time.
	A.3.2. Device Models: Samples		A.3.2. Device Models: Samples
	The following provides an overview of some Device Models that can be		The following provides an overview of some Device Models that can be
	used within a network. This list is not comprehensive.		used within a network. This list is not comprehensive.
			Interface: [RFC7224] defines a YANG module for interface type
			definitions.
	BGP: [I-D.ietf-idr-bgp-model] defines a YANG module for		BGP: [I-D.ietf-idr-bgp-model] defines a YANG module for
	configuring and managing BGP, including protocol, policy,		configuring and managing BGP, including protocol, policy,
	and operational aspects based on data center, carrier, and		and operational aspects based on data center, carrier, and
	content provider operational requirements.		content provider operational requirements.
	MPLS: [I-D.ietf-mpls-base-yang] defines a base model for MPLS		MPLS: [I-D.ietf-mpls-base-yang] defines a base model for MPLS
	which serves as a base framework for configuring and		which serves as a base framework for configuring and
	managing an MPLS switching subsystem. It is expected that		managing an MPLS switching subsystem. It is expected that
	other MPLS technology YANG modules (e.g., MPLS LSP Static,		other MPLS technology YANG modules (e.g., MPLS LSP Static,
	LDP, or RSVP-TE models) will augment the MPLS base YANG		LDP, or RSVP-TE models) will augment the MPLS base YANG
	module.		module.
	QoS: [I-D.ietf-rtgwg-qos-model] describes a YANG module of		QoS: [I-D.ietf-rtgwg-qos-model] describes a YANG module of
	Differentiated Services for configuration and operations.		Differentiated Services for configuration and operations.
	ACL: Access Control List (ACL) is one of the basic elements		ACL: Access Control List (ACL) is one of the basic elements
	used to configure device forwarding behavior. It is used		used to configure device forwarding behavior. It is used
	in many networking technologies such as Policy Based		in many networking technologies such as Policy Based
	Routing, Firewalls, etc. [RFC8519] describes a data model		Routing, Firewalls, etc. [RFC8519] describes a YANG data
	of ACL basic building blocks.		model of ACL basic building blocks.
	NAT: For the sake of network automation and the need for		NAT: For the sake of network automation and the need for
	programming Network Address Translation (NAT) function in		programming Network Address Translation (NAT) function in
	particular, a data model for configuring and managing the		particular, a YANG data model for configuring and managing
	NAT is essential.		the NAT is essential.
	[RFC8512] defines a YANG module for the NAT function		[RFC8512] defines a YANG module for the NAT function
	covering a variety of NAT flavors such as Network Address		covering a variety of NAT flavors such as Network Address
	Translation from IPv4 to IPv4 (NAT44), Network Address and		Translation from IPv4 to IPv4 (NAT44), Network Address and
	Protocol Translation from IPv6 Clients to IPv4 Servers		Protocol Translation from IPv6 Clients to IPv4 Servers
	(NAT64), customer-side translator (CLAT), Stateless IP/		(NAT64), customer-side translator (CLAT), Stateless IP/
	ICMP Translation (SIIT), Explicit Address Mappings (EAM)		ICMP Translation (SIIT), Explicit Address Mappings (EAM)
	for SIIT, IPv6-to-IPv6 Network Prefix Translation (NPTv6),		for SIIT, IPv6-to-IPv6 Network Prefix Translation (NPTv6),
	and Destination NAT.		and Destination NAT.
	skipping to change at page 39, line 48 ¶		skipping to change at page 39, line 39 ¶
	BFD: Bidirectional Forwarding Detection (BFD) [RFC5880] is a		BFD: Bidirectional Forwarding Detection (BFD) [RFC5880] is a
	network protocol which is used for liveness detection of		network protocol which is used for liveness detection of
	arbitrary paths between systems. [I-D.ietf-bfd-yang]		arbitrary paths between systems. [I-D.ietf-bfd-yang]
	defines a YANG module that can be used to configure and		defines a YANG module that can be used to configure and
	manage BFD.		manage BFD.
	SR/SRv6: [I-D.ietf-spring-sr-yang] a YANG module for segment		SR/SRv6: [I-D.ietf-spring-sr-yang] a YANG module for segment
	routing configuration and operation.		routing configuration and operation.
	Core Routing: [RFC8349] defines the core routing data model, which		Core Routing: [RFC8349] defines the core routing YANG data model,
	is intended as a basis for future data model development		which is intended as a basis for future data model
	covering more-sophisticated routing systems. It is		development covering more-sophisticated routing systems.
	expected that other Routing technology YANG modules (e.g.,		It is expected that other Routing technology YANG modules
	VRRP, RIP, ISIS, OSPF models) will augment the Core		(e.g., VRRP, RIP, ISIS, OSPF models) will augment the Core
	Routing base YANG module.		Routing base YANG module.
	PM: [I-D.ietf-ippm-twamp-yang] defines a data model for client		PM: [I-D.ietf-ippm-twamp-yang] defines a YANG data model for
	and server implementations of the Two-Way Active		client and server implementations of the Two-Way Active
	Measurement Protocol (TWAMP).		Measurement Protocol (TWAMP).
	[I-D.ietf-ippm-stamp-yang] defines the data model for		[I-D.ietf-ippm-stamp-yang] defines the data model for
	implementations of Session-Sender and Session-Reflector		implementations of Session-Sender and Session-Reflector
	for Simple Two-way Active Measurement Protocol (STAMP)		for Simple Two-way Active Measurement Protocol (STAMP)
	mode using YANG.		mode using YANG.
	[RFC8194] defines a data model for Large-Scale Measurement		[RFC8194] defines a YANG data model for Large-Scale
	Platforms (LMAPs).		Measurement Platforms (LMAPs).
	Authors' Addresses		Authors' Addresses
	Qin Wu (editor)		Qin Wu (editor)
	Huawei		Huawei
	101 Software Avenue, Yuhua District		101 Software Avenue, Yuhua District
	Nanjing, Jiangsu 210012		Nanjing, Jiangsu 210012
	China		China
	Email: bill.wu@huawei.com		Email: bill.wu@huawei.com
End of changes. 55 change blocks.
	127 lines changed or deleted		139 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/