draft-ietf-opsawg-l3sm-l3nm-02.txt		draft-ietf-opsawg-l3sm-l3nm-03.txt
	OPSAWG S. Barguil		OPSAWG S. Barguil
	Internet-Draft O. Gonzalez de Dios, Ed.		Internet-Draft O. Gonzalez de Dios, Ed.
	Intended status: Standards Track Telefonica		Intended status: Standards Track Telefonica
	Expires: September 10, 2020 M. Boucadair		Expires: October 5, 2020 M. Boucadair
	Orange		Orange
	L. Munoz		L. Munoz
	Vodafone		Vodafone
	A. Aguado		A. Aguado
	Nokia		Nokia
	March 09, 2020		April 03, 2020
	A Layer 3 VPN Network YANG Model		A Layer 3 VPN Network YANG Model
	draft-ietf-opsawg-l3sm-l3nm-02		draft-ietf-opsawg-l3sm-l3nm-03
	Abstract		Abstract
	This document defines a L3 VPN Network YANG Data model, called L3NM		This document defines a L3VPN Network YANG Model (L3NM) that can be
	that can be used to manage the provisioning of Layer 3 VPN services		used to manage the provisioning of Layer 3 Virtual Private Network
	within a Service Provider Network. The module is meant to be used by		(VPN) services within a Service Provider's network. The model
	a Network Controller to derive the configuration information that		provides a network-centric view of L3VPN services.
	will be sent to relevant network devices.
	The L3VPN Network YANG Model (L3NM) can also facilitates the		L3NM is meant to be used by a Network Controller to derive the
	communication between a service orchestrator and a network		configuration information that will be sent to relevant network
	controller/orchestrator. The model provides a network-centric view		devices. The model can also facilitate the communication between a
	of the L3VPN services.		service orchestrator and a network controller/orchestrator.
	The L3NM YANG module is aimed at managing BGP PE-based Layer 3 VPNs		L3NM focuses on BGP PE-based Layer 3 VPNs as described in RFCs 4026,
	as described in RFCs 4026, 4110 and 4364 and Multicast VPNs as		4110 and 4364 and Multicast VPNs as described in RFCs 6037, 6513 and
	described in RFCs 6037, 6513 and 7988.		7988.
	Editorial Note (To be removed by RFC Editor)		Editorial Note (To be removed by RFC Editor)
	Please update these statements within the document with the RFC		Please update these statements within the document with the RFC
	number to be assigned to this document:		number to be assigned to this document:
	o "This version of this YANG module is part of RFC XXXX;"		o "This version of this YANG module is part of RFC XXXX;"
	o "RFC XXXX: Layer 3 VPN Network Model";		o "RFC XXXX: Layer 3 VPN Network Model";
	skipping to change at page 2, line 20 ¶		skipping to change at page 2, line 20 ¶
	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 September 10, 2020.		This Internet-Draft will expire on October 5, 2020.
	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 50 ¶		skipping to change at page 2, line 50 ¶
	2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4		2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
	3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	4. Reference Architecture . . . . . . . . . . . . . . . . . . . 6		4. Reference Architecture . . . . . . . . . . . . . . . . . . . 6
	5. Relation with other YANG Models . . . . . . . . . . . . . . . 8		5. Relation with other YANG Models . . . . . . . . . . . . . . . 8
	6. Description of the L3NM YANG Module . . . . . . . . . . . . . 10		6. Description of the L3NM YANG Module . . . . . . . . . . . . . 10
	6.1. Overall Structure of the Module . . . . . . . . . . . . . 10		6.1. Overall Structure of the Module . . . . . . . . . . . . . 10
	6.2. VPN Profiles . . . . . . . . . . . . . . . . . . . . . . 10		6.2. VPN Profiles . . . . . . . . . . . . . . . . . . . . . . 10
	6.3. Modeling a Layer 3 VPN Service . . . . . . . . . . . . . 11		6.3. Modeling a Layer 3 VPN Service . . . . . . . . . . . . . 11
	6.3.1. Service Status . . . . . . . . . . . . . . . . . . . 12		6.3.1. Service Status . . . . . . . . . . . . . . . . . . . 12
	6.3.2. VPN Node . . . . . . . . . . . . . . . . . . . . . . 13		6.3.2. VPN Node . . . . . . . . . . . . . . . . . . . . . . 13
	6.3.2.1. Node Status . . . . . . . . . . . . . . . . . . . 15		6.3.2.1. Node Status . . . . . . . . . . . . . . . . . . . 16
	6.3.2.2. VPN Network Access . . . . . . . . . . . . . . . 15		6.3.2.2. RT/RD Assignment/auto-assignment . . . . . . . . 16
	6.3.2.2.1. Connection . . . . . . . . . . . . . . . . . 17		6.3.2.3. VPN Network Access . . . . . . . . . . . . . . . 17
	6.3.2.2.2. IP Connections . . . . . . . . . . . . . . . 20		6.3.2.3.1. Connection . . . . . . . . . . . . . . . . . 18
	6.3.2.2.3. CE PE Routing Protocols . . . . . . . . . . . 22		6.3.2.3.2. IP Connections . . . . . . . . . . . . . . . 22
	6.3.2.3. Multicast . . . . . . . . . . . . . . . . . . . . 26		6.3.2.3.3. Security . . . . . . . . . . . . . . . . . . 24
	6.3.3. Concept of Import/Export Profiles . . . . . . . . . . 28		6.3.2.3.4. CE PE Routing Protocols . . . . . . . . . . . 25
	6.3.4. Underlay Transport . . . . . . . . . . . . . . . . . 28		6.3.2.3.5. Services . . . . . . . . . . . . . . . . . . 29
	7. L3NM Module Tree Structure . . . . . . . . . . . . . . . . . 28		6.3.2.4. Multicast . . . . . . . . . . . . . . . . . . . . 31
	8. Sample Uses of the L3NM Data Model . . . . . . . . . . . . . 39		6.3.3. Concept of Import/Export Profiles . . . . . . . . . . 33
	8.1. Enterprise L3 VPN Services . . . . . . . . . . . . . . . 39		6.3.4. Underlay Transport . . . . . . . . . . . . . . . . . 33
	8.2. Multi-Domain Resource Management . . . . . . . . . . . . 39		7. L3NM Module Tree Structure . . . . . . . . . . . . . . . . . 33
	8.3. Management of Multicast services . . . . . . . . . . . . 39		8. Sample Uses of the L3NM Data Model . . . . . . . . . . . . . 43
	9. L3VPN Examples . . . . . . . . . . . . . . . . . . . . . . . 40		8.1. Enterprise L3 VPN Services . . . . . . . . . . . . . . . 43
	9.1. 4G VPN Provissioning Example . . . . . . . . . . . . . . 40		8.2. Multi-Domain Resource Management . . . . . . . . . . . . 43
	9.2. Multicast VPN Provisioning Example . . . . . . . . . . . 44		8.3. Management of Multicast services . . . . . . . . . . . . 44
	10. L3NM YANG Module . . . . . . . . . . . . . . . . . . . . . . 46		9. L3VPN Examples . . . . . . . . . . . . . . . . . . . . . . . 44
	11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 108		9.1. 4G VPN Provisioning Example . . . . . . . . . . . . . . . 44
	12. Security Considerations . . . . . . . . . . . . . . . . . . . 109		9.2. Multicast VPN Provisioning Example . . . . . . . . . . . 48
	13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 110		10. L3NM YANG Module . . . . . . . . . . . . . . . . . . . . . . 50
	14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 110		11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 110
	15. References . . . . . . . . . . . . . . . . . . . . . . . . . 111		12. Security Considerations . . . . . . . . . . . . . . . . . . . 110
	15.1. Normative References . . . . . . . . . . . . . . . . . . 111		13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 112
	15.2. Informative References . . . . . . . . . . . . . . . . . 112		14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 112
	Appendix A. Implementation Status . . . . . . . . . . . . . . . 113		15. References . . . . . . . . . . . . . . . . . . . . . . . . . 113
	A.1. Nokia Implementation . . . . . . . . . . . . . . . . . . 113		15.1. Normative References . . . . . . . . . . . . . . . . . . 113
	A.2. Huawei Implementation . . . . . . . . . . . . . . . . . . 114		15.2. Informative References . . . . . . . . . . . . . . . . . 114
	A.3. Infinera Implementation . . . . . . . . . . . . . . . . . 118		Appendix A. Implementation Status . . . . . . . . . . . . . . . 115
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 118		A.1. Nokia Implementation . . . . . . . . . . . . . . . . . . 115
			A.2. Huawei Implementation . . . . . . . . . . . . . . . . . . 116
			A.3. Infinera Implementation . . . . . . . . . . . . . . . . . 119
			A.4. Ribbon-ECI Implementation . . . . . . . . . . . . . . . . 120
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 122
	1. Introduction		1. Introduction
	[RFC8299] defines an L3VPN Service YANG data Model (L3SM) that can be		[RFC8299] defines an L3VPN Service YANG data Model (L3SM) that can be
	used for communication between customers and network operators. Such		used for communication between customers and network operators. Such
	model is focused on describing the customer view of the VPN services,		model is focused on describing the customer view of the VPN services,
	and provides an abstracted view of the customer's requested services.		and provides an abstracted view of the customer's requested services.
	That approach limits the usage of the L3SM module to the role of a		That approach limits the usage of the L3SM module to the role of a
	Customer Service Model, according to the terminology defined in		Customer Service Model, according to the terminology defined in
	[RFC8309].		[RFC8309].
	skipping to change at page 9, line 45 ¶		skipping to change at page 9, line 45 ¶
	activation and provisioning of the VPN service will involve a		activation and provisioning of the VPN service will involve a
	variety of device modules to tweak the required functions for the		variety of device modules to tweak the required functions for the
	delivery of the service. These functions are supported by the VPN		delivery of the service. These functions are supported by the VPN
	nodes and can be managed using device YANG modules. A non-		nodes and can be managed using device YANG modules. A non-
	comprehensive list of such device YANG modules is provided below:		comprehensive list of such device YANG modules is provided below:
	* Routing management ([RFC8349])		* Routing management ([RFC8349])
	* BGP ([I-D.ietf-idr-bgp-model])		* BGP ([I-D.ietf-idr-bgp-model])
	* PIM ([I-D.liu-pim-yang])		* PIM ([I-D.ietf-pim-yang])
	* NAT management ([RFC8512])		* NAT management ([RFC8512])
	* QoS management ([I-D.ietf-rtgwg-qos-model])		* QoS management ([I-D.ietf-rtgwg-qos-model])
	* ACL ([RFC8519])		* ACL ([RFC8519])
	How L3NM is used to derive device-specific actions is		How L3NM is used to derive device-specific actions is
	implementation-specific.		implementation-specific.
	6. Description of the L3NM YANG Module		6. Description of the L3NM YANG Module
	The L3NM module ('ietf-l3vpn-ntw') is meant to manage L3 VPNs in a		The L3NM module ('ietf-l3vpn-ntw') is meant to manage L3 VPNs in a
	service provider network. In particular, the 'ietf-l3vpn-ntw' module		service provider network. In particular, the 'ietf-l3vpn-ntw' module
	can be used to create, modify, and retrieve L3VPN Services of a		can be used to create, modify, and retrieve L3VPN Services of a
	network.		network.
	The detailed tree structure is provided in Figure 15.		The detailed tree structure is provided in Figure 17.
	6.1. Overall Structure of the Module		6.1. Overall Structure of the Module
	The 'ietf-l3vpn-ntw' module uses two main containers: 'vpn-services'		The 'ietf-l3vpn-ntw' module uses two main containers: 'vpn-services'
	and 'vpn-profiles' (see Figure 3).		and 'vpn-profiles' (see Figure 3).
	The 'vpn-services' container maintains the set of VPN services		The 'vpn-services' container maintains the set of VPN services
	managed within the service provider's network. 'vpn-service' is the		managed within the service provider's network. 'vpn-service' is the
	data structure that abstracts a VPN service (Section 6.3).		data structure that abstracts a VPN service (Section 6.3).
	skipping to change at page 11, line 36 ¶		skipping to change at page 11, line 36 ¶
	The 'vpn-service' is the data structure that abstracts a VPN Service		The 'vpn-service' is the data structure that abstracts a VPN Service
	in the Service Provider Network. Each 'vpn-service' is uniquely		in the Service Provider Network. Each 'vpn-service' is uniquely
	identified by an identifier: 'vpn-id'. Such 'vpn-id' is only		identified by an identifier: 'vpn-id'. Such 'vpn-id' is only
	meaningful locally within the Network controller.		meaningful locally within the Network controller.
	In order to facilitate the identification of the service, 'customer-		In order to facilitate the identification of the service, 'customer-
	name' and 'description' attributes may be provided.		name' and 'description' attributes may be provided.
	The 'vpn-service' parameters are:		The 'vpn-service' parameters are:
	o service-status: Allows the control of the operative and		o 'service-status': Allows the control of the operative and
	administrative status of the service as a whole.		administrative status of the service as a whole.
	o vpn-id: Unique identifier of the L3VPN Service within L3NM scope.		o 'vpn-id': Is an identifier that is used to uniquely identify the
			L3VPN Service within L3NM scope.
	o l3sm-vpn-id: Refers to the L3SNM Id of this service. This		o 'l3sm-vpn-id': Refers to an identifier of L3SM service. This
	identifier allows to easily correlate the service as built in the		identifier allows to easily correlate the (network) service as
	network with a service request.		built in the network with a service order.
	o vpn-service-topology: Typical network topologies are supported.		o 'vpn-service-topology': Indicates the network topology for the
	Hub-Spoke, Any-to-Any, and Custom. Real deployment on the network		service: Hub-Spoke, Any-to-Any, and Custom. The deployment on the
	is defined by the correct usage of import and export profiles		network is defined by the correct usage of import and export
			profiles
	o ie-profiles: Define reusable import/export policies for the same		o 'ie-profiles': Defines reusable import/export policies for the
	VPN-Service. Described in detail in Section 6.3.3		same 'vpn-service'. More details are provided in Section 6.3.3
	o Underlay-Transport: Describes the preference for the transport		o 'underlay-transport': Describes the preference for the transport
	technology to carry the traffic of the VPN-Service.		technology to carry the traffic of the VPN service.
	A VPN service is typically built by adding instances of 'vpn-node' to		A VPN service is typically built by adding instances of 'vpn-node' to
	the 'vpn-nodes' container. The 'vpn-node' is an abstraction that		the 'vpn-nodes' container. The 'vpn-node' is an abstraction that
	represents a set of policies applied to a network node and that		represents a set of policies applied to a network node and that
	belong to a single 'vpn-service'.		belong to a single 'vpn-service'.
	A 'vpn-node' contains 'vpn-network-accesses', which are the		A 'vpn-node' contains 'vpn-network-accesses', which are the
	interfaces attached to the VPN by which the customer traffic is		interfaces attached to the VPN by which the customer traffic is
	received. Therefore, the customer sites are connected to the 'vpn-		received. Therefore, the customer sites are connected to the 'vpn-
	network-accesses'. Note that, as this is a network data model, the		network-accesses'. Note that, as this is a network data model, the
	skipping to change at page 13, line 25 ¶		skipping to change at page 13, line 25 ¶
	| +--ro status? operational-type		| +--ro status? operational-type
	| +--ro timestamp? yang:date-and-time		| +--ro timestamp? yang:date-and-time
	...		...
	Figure 6: VPN Service Status Tree Structure		Figure 6: VPN Service Status Tree Structure
	6.3.2. VPN Node		6.3.2. VPN Node
	The 'vpn-node' is an abstraction that represents a set of common		The 'vpn-node' is an abstraction that represents a set of common
	policies applied on a given network node (tipcally, a PE) and belong		policies applied on a given network node (tipcally, a PE) and belong
	to one L3 VPN Service. In order to indicate the network node where		to one L3 VPN service. In order to indicate the network nodes where
	the 'vpn-node' applies the 'ne-id' must be indicated. The 'vpn-node'		the 'vpn-node' applies, the 'ne-id' must be indicated. The 'vpn-
	includes a parameter to indicate in which network node it is applied.		node' includes a parameter to indicate the network node on which it
	In the case that the 'ne-id' points to a specific PE, the 'vpn-node'		is applied. In the case that the 'ne-id' points to a specific PE,
	will likely be mapped into a VRF in the node. However, the model		the 'vpn-node' will likely be mapped into a VRF in the node.
	also allows to point to an abstract node. In this case, the network		However, the model also allows to point to an abstract node. In this
	controller will decide how to split the 'vpn-node' into VRFs.		case, the network controller will decide how to split the 'vpn-node'
	Additionally the 'vpn-node' parameters are:		into VRFs. Soem 'vpn-node' parameters are listed below:
	o status: Allows the control of the operative and administrative
	status of the 'vpn-node'.
	o local-autonomous-system: Autonomous system of locally configured		o local-autonomous-system: Refers to the autonomous system number
	in the instance. It can be overwritten for specific purposes in		that is locally configured in the instance. It can be overwritten
	the CE-PE BGP session.		for specific purposes in the CE-PE BGP session.
	o maximum-routes: Max-number of prefixes allowed in the vpn-node		o maximum-routes: Set the maximum number of prefixes allowed in the
	instance.		'vpn-node' instance. This value is typically set in the service
			request.
	o rd and vpn-targets: For the cases the logical resources are		o 'rd' and 'vpn-targets': For the cases the logical resources are
	managed outside the network controller, the model allows to		managed outside the network controller, the model allows to
	explicitely indicate the logical resources such as Route targets		explicitely indicate the logical resources such as Route targets
	(RTs) and Route Distinguishers (RDs) (RT,RD).		(RTs) and Route Distinguishers (RDs) (RT,RD).
	o Multicast: Enable multicast traffic inside the vpn. Detailed		o Multicast: Enable multicast traffic inside the VPN. Refer to
	description in Section 6.3.2.3		Section 6.3.2.4.
	Under the VPN Node ('vpn-node') container, VPN Network Acesses ('vpn-		Under the VPN Node ('vpn-node') container, VPN Network Acesses ('vpn-
	network-access') can be created. The VPN Network Acess represents		network-access') can be created. The VPN Network Acess represents
	the point to which sites are connected. Note that, unlike in L3SM,		the point to which sites are connected. Note that, unlike in L3SM,
	the L3NM does not need to model the customer site, only the points		the L3NM does not need to model the customer site, only the points
	where the traffic from the site are received. Hence, the VPN Network		where the traffic from the site are received. Hence, the VPN Network
	access contains the connectivity information between the provider's		access contains the connectivity information between the provider's
	network and the customer premises. The VPN profiles ('vpn-profiles')		network and the customer premises. The VPN profiles ('vpn-profiles')
	have a set of routing policies than can be applied during the service		have a set of routing policies than can be applied during the service
	creation.		creation.
	skipping to change at page 14, line 33 ¶		skipping to change at page 15, line 23 ¶
	+--rw vpn-nodes		+--rw vpn-nodes
	+--rw vpn-node* [ne-id]		+--rw vpn-node* [ne-id]
	+--rw vpn-node-id? union		+--rw vpn-node-id? union
	+--rw local-autonomous-system? inet:as-number		+--rw local-autonomous-system? inet:as-number
	+--rw description? string		+--rw description? string
	+--rw ne-id string		+--rw ne-id string
	+--rw router-id? inet:ip-address		+--rw router-id? inet:ip-address
	+--rw address-family?		+--rw address-family?
	| l3vpn-svc:address-family		| l3vpn-svc:address-family
	+--rw node-role? identityref		+--rw node-role? identityref
	+--rw rd?		+--rw rw rd? union
	| rt-types:route-distinguisher
	+--rw vpn-targets		+--rw vpn-targets
	| +--rw vpn-target* [id]		| +--rw vpn-target* [id]
	| | +--rw id int8		| | +--rw id int8
	| | +--rw route-targets* [route-target]		| | +--rw route-targets* [route-target]
	| | | +--rw route-target		| | | +--rw route-target
	| | | rt-types:route-target		| | | rt-types:route-target
	| | +--rw route-target-type		| | +--rw route-target-type
	| | rt-types:route-target-type		| | rt-types:route-target-type
	| +--rw vpn-policies		| +--rw vpn-policies
	| +--rw import-policy? leafref		| +--rw import-policy? leafref
	skipping to change at page 15, line 41 ¶		skipping to change at page 16, line 30 ¶
	+--rw vpn-nodes		+--rw vpn-nodes
	| +--rw vpn-node* [ne-id]		| +--rw vpn-node* [ne-id]
	| +--rw ne-id string		| +--rw ne-id string
	| ...		| ...
	| +--rw status		| +--rw status
	| | +--rw admin-enabled? boolean		| | +--rw admin-enabled? boolean
	| | +--ro oper-status? operational-type		| | +--ro oper-status? operational-type
	Figure 8: Node Status Tree Structure		Figure 8: Node Status Tree Structure
	6.3.2.2. VPN Network Access		6.3.2.2. RT/RD Assignment/auto-assignment
			For the cases the logical resources are managed outside the network
			controller, the model allows to explicitely indicate the logical
			resources such as Route targets (RTs) and Route Distinguishers (RDs)
			(RT,RD).
			Three possible behaviors are needed to fulfil the identified use
			cases:
			o The network controller auto-assigns logical resources (RTs, RDs).
			This can apply for new services deployment.
			o The Network Operator/Service orchestrator assigns explicitly the
			RTs and RDs. This case will fit with a brownfield scenario where
			some existing services needs to be updated by the network
			operators.
			o The Network Operator/Service orchestrator explicitly wants NO RT/
			RD to be assigned. This case will fit in VRF-Lite scenarios, CE
			testing inside the Network or just for troubleshooting pruposes.
			Thus a union between two yang data types are included in order to
			support this scenarios. So, if the leaf is not created in the Yang
			the expected behavior is the auto-assigns. If the Leaf is created
			with a valid rd value it will be explicitly assign in the VPN Node
			and if the leaf is created with an empty value, the RD value will not
			be deployed in the VPN node.
			6.3.2.3. VPN Network Access
	A 'vpn-network-access' represents an entry point to a VPN service		A 'vpn-network-access' represents an entry point to a VPN service
	(Figure 9). In other words, this container encloses the parameters		(Figure 9). In other words, this container encloses the parameters
	that describe the access information for the traffic that belongs to		that describe the access information for the traffic that belongs to
	a particular L3VPN. As such, every 'vpn-network-access' MUST belong		a particular L3VPN. As such, every 'vpn-network-access' MUST belong
	to one and only one 'vpn-node'.		to one and only one 'vpn-node'.
	A 'vpn-network-access' includes information such as the connection on		A 'vpn-network-access' includes information such as the connection on
	which the access is defined (see Section 6.3.2.2.1), the		which the access is defined (see Section 6.3.2.3.1), the
	encapsulation of the traffic, policies that are applied on the		encapsulation of the traffic, policies that are applied on the
	access, etc.		access, etc.
	A provisioning Network Controller (PNC) [RFC8453] will accept VPN		A provisioning Network Controller (PNC) [RFC8453] will accept VPN
	requests containing this construct, using the enclosed data to:		requests containing this construct, using the enclosed data to:
	configure the router's interface to include the parameters described		configure the router's interface to include the parameters described
	at the 'vpn-network-access', include the given interface into a VRF,		at the 'vpn-network-access', include the given interface into a VRF,
	configuring policies or schedulers for processing the incoming		configuring policies or schedulers for processing the incoming
	traffic, etc.		traffic, etc.
	skipping to change at page 17, line 5 ¶		skipping to change at page 18, line 43 ¶
	| +--rw security		| +--rw security
	| | ...		| | ...
	| +--rw routing-protocols		| +--rw routing-protocols
	| | ...		| | ...
	| +--rw service		| +--rw service
	| ...		| ...
	| ...		| ...
	Figure 9: VPN Network Access Tree Structure		Figure 9: VPN Network Access Tree Structure
	6.3.2.2.1. Connection		6.3.2.3.1. Connection
	The definition of a L3VPN is commonly specified not only at the IP		The definition of a L3VPN is commonly specified not only at the IP
	layer, but also requires to identify parameters at the Ethernet		layer, but also requires to identify parameters at the Ethernet
	layer, such as encapsulation type (e.g., VLAN, QinQ, QinAny, VxLAN,		layer, such as encapsulation type (e.g., VLAN, QinQ, QinAny, VxLAN,
	etc.). The 'connection' container represents and groups the set of		etc.). The 'connection' container represents and groups the set of
	L2 connectivity from where the traffic of the L3VPN in a particular		L2 connectivity from where the traffic of the L3VPN in a particular
	VPN Network access is coming.		VPN Network access is coming.
	Additionally, the bearer-reference and the pseudowire termination are		Additionally, the bearer-reference and the pseudowire termination are
	supported.		supported.
	skipping to change at page 20, line 5 ¶		skipping to change at page 22, line 5 ¶
	A site, as per [RFC4176] represents a VPN customer's location that is		A site, as per [RFC4176] represents a VPN customer's location that is
	connected to the Service Provider network via a CE-PE link, which can		connected to the Service Provider network via a CE-PE link, which can
	access at least one VPN. The connection from the site to the Service		access at least one VPN. The connection from the site to the Service
	Provider network is the bearer. Every site is associated with a list		Provider network is the bearer. Every site is associated with a list
	of bearers. A bearer is the layer two connections with the site. In		of bearers. A bearer is the layer two connections with the site. In
	the module it is assumed that the bearer has been allocated by the		the module it is assumed that the bearer has been allocated by the
	Service Provider at the service orchestration step. The bearer is		Service Provider at the service orchestration step. The bearer is
	associated to a network element and a port. Hence, a bearer is just		associated to a network element and a port. Hence, a bearer is just
	a bearer-reference to allow the translation between L3SM and L3NM.		a bearer-reference to allow the translation between L3SM and L3NM.
	6.3.2.2.2. IP Connections		6.3.2.3.2. IP Connections
	IP connection container (Figure 12) has the parameters of the 'vpn-		IP connection container (Figure 12) has the parameters of the 'vpn-
	network-access' addressing information. The address allocated in		network-access' addressing information. The address allocated in
	this container would represent the PE interface address		this container would represent the PE interface address
	configuration. The IP connection container is designed to support		configuration. The IP connection container is designed to support
	both IPv4 and IPv6. It also supports three options for IP address		both IPv4 and IPv6. It also supports three options for IP address
	assignment: Provider DHCP, DHCP relay, and static addressing.		assignment: Provider DHCP, DHCP relay, and static addressing.
	In the case of the static addressing, the model supports the		In the case of the static addressing, the model supports the
	assignment of several IP addresses in the same 'vpn-network-access'.		assignment of several IP addresses in the same 'vpn-network-access'.
	skipping to change at page 22, line 39 ¶		skipping to change at page 24, line 39 ¶
	| | +--rw profile-name? leafref		| | +--rw profile-name? leafref
	| +--rw security		| +--rw security
	| | ...		| | ...
	| +--rw routing-protocols		| +--rw routing-protocols
	| | ...		| | ...
	| +--rw service		| +--rw service
	| ...		| ...
	Figure 12: IP Connection Tree Structure		Figure 12: IP Connection Tree Structure
	6.3.2.2.3. CE PE Routing Protocols		6.3.2.3.3. Security
			The 'security' container specifies the authentication and the
			encryption to be applied for a given VPN network access (Figure 13).
			module: ietf-l3vpn-ntw
			+--rw l3vpn-ntw
			+--rw vpn-profiles
			| ...
			+--rw vpn-services
			+--rw vpn-service* [vpn-id]
			+--rw vpn-id l3vpn-svc:svc-id
			+ ...
			+--rw vpn-node* [ne-id]
			+--rw ne-id string
			+ ...
			+--rw vpn-network-accesses
			| +--rw vpn-network-access* [id]
			| +--rw id
			| | l3vpn-svc:svc-id
			| + ...
			| +--rw connection
			| | ...
			| +--rw ip-connection
			| | ...
			| +--rw security
			| | +--rw authentication
			| | +--rw encryption {l3vpn-svc:encryption}?
			| | | +--rw enabled? boolean
			| | | +--rw layer? enumeration
			| | +--rw encryption-profile
			| | +--rw (profile)?
			| | | +--:(provider-profile)
			| | | | +--rw profile-name? leafref
			| | | +--:(customer-profile)
			| | | +--rw algorithm? string
			| | +--rw (key-type)?
			| | +--:(psk)
			| | +--rw preshared-key? string
			| +--rw routing-protocols
			| | ...
			| +--rw service
			| ...
			| ...
			Figure 13: Security Tree Structure
			6.3.2.3.4. CE PE Routing Protocols
	The model allows the Provider to configure one or more routing		The model allows the Provider to configure one or more routing
	protocols associated with a particular 'vpn-network-access'		protocols associated with a particular 'vpn-network-access'
	(Figure 13). This protocol will run between the PE and the CE. A		(Figure 14). This protocol will run between the PE and the CE. A
	routing protocol instance MUST have a type (e.g., bgp, ospf) and an		routing protocol instance MUST have a type (e.g., bgp, ospf) and an
	identifier. The identifier is necessary when multiple instances of		identifier. The identifier is necessary when multiple instances of
	the same protocol have to be configured.		the same protocol have to be configured.
	When configuring multiple instances of the same routing protocol,		When configuring multiple instances of the same routing protocol,
	this does not automatically imply that, from a device configuration		this does not automatically imply that, from a device configuration
	perspective, there will be parallel instances (multiple processes)		perspective, there will be parallel instances (multiple processes)
	running. It will be up to the implementation to use the most		running. It will be up to the implementation to use the most
	appropriate deployment model. As an example, when multiple BGP peers		appropriate deployment model. As an example, when multiple BGP peers
	need to be implemented, multiple instances of BGP must be configured		need to be implemented, multiple instances of BGP must be configured
	skipping to change at page 26, line 21 ¶		skipping to change at page 29, line 28 ¶
	| | | inet:ipv6-address		| | | inet:ipv6-address
	| | +--rw rip {l3vpn-svc:rtg-rip}?		| | +--rw rip {l3vpn-svc:rtg-rip}?
	| | | +--rw address-family*		| | | +--rw address-family*
	| | | l3vpn-svc:address-family		| | | l3vpn-svc:address-family
	| | +--rw vrrp {l3vpn-svc:rtg-vrrp}?		| | +--rw vrrp {l3vpn-svc:rtg-vrrp}?
	| | +--rw address-family*		| | +--rw address-family*
	| | l3vpn-svc:address-family		| | l3vpn-svc:address-family
	| +--rw service		| +--rw service
	| ...		| ...
	Figure 13: Routing Tree Structure		Figure 14: Routing Tree Structure
	6.3.2.3. Multicast		6.3.2.3.5. Services
			The 'services' container specifies the service parameter to apply for
			a give VPN network access (Figure 15). The following attributes are
			defined:
			o TBC
			module: ietf-l3vpn-ntw
			+--rw l3vpn-ntw
			+--rw vpn-profiles
			| ...
			+--rw vpn-services
			+--rw vpn-service* [vpn-id]
			+--rw vpn-id l3vpn-svc:svc-id
			+ ...
			+--rw vpn-node* [ne-id]
			+--rw ne-id string
			+ ...
			+--rw vpn-network-accesses
			| +--rw vpn-network-access* [id]
			| +--rw id
			| | l3vpn-svc:svc-id
			| + ...
			| +--rw connection
			| | ...
			| +--rw ip-connection
			| | ...
			| +--rw security
			| | ...
			| +--rw routing-protocols
			| | ...
			| +--rw service
			| +--rw svc-input-bandwidth uint64
			| +--rw svc-output-bandwidth uint64
			| +--rw svc-mtu uint16
			| +--rw qos {l3vpn-svc:qos}?
			| | +--rw qos-classification-policy
			| | | +--rw rule* [id]
			| | | +--rw id
			| | | | string
			| | | +--rw (match-type)?
			| | | | +--:(match-flow)
			| | | | | +--rw (l3)?
			| | | | | | +--:(ipv4)
			| | | | | | | ...
			| | | | | | +--:(ipv6)
			| | | | | | ...
			| | | | | +--rw (l4)?
			| | | | | +--:(tcp)
			| | | | | | ...
			| | | | | +--:(udp)
			| | | | | ...
			| | | | +--:(match-application)
			| | | | +--rw match-application?
			| | | | identityref
			| | | +--rw target-class-id?
			| | | string
			| | +--rw qos-profile
			| | +--rw (qos-profile)?
			| | +--:(standard)
			| | | +--rw profile? leafref
			| | | +--rw direction? identityref
			| | +--:(custom)
			| | ...
			| +--rw carrierscarrier
			| | {l3vpn-svc:carrierscarrier}?
			| | +--rw signalling-type? enumeration
			| +--rw multicast {l3vpn-svc:multicast}?
			| +--rw site-type? enumeration
			| +--rw address-family
			| | +--rw ipv4? boolean
			| | | {l3vpn-svc:ipv4}?
			| | +--rw ipv6? boolean
			| | {l3vpn-svc:ipv6}?
			| +--rw protocol-type? enumeration
			| +--rw remote-source? boolean
			| ...
			Figure 15: Services Tree Structure
			6.3.2.4. Multicast
	Multicast MAY be enabled for a particular vpn-network-node (see		Multicast MAY be enabled for a particular vpn-network-node (see
	Figure 14).		Figure 16).
	The model supports a single type of tree (Any-Source Multicast (ASM),		The model supports a single type of tree (Any-Source Multicast (ASM),
	Source-Specific Multicast (SSM), or bidirectional).		Source-Specific Multicast (SSM), or bidirectional).
	When ASM is used, the model supports the configuration of rendez-vous		When ASM is used, the model supports the configuration of rendez-vous
	points (RPs). RP discovery may be 'static', 'bsr-rp', or 'auto-rp'.		points (RPs). RP discovery may be 'static', 'bsr-rp', or 'auto-rp'.
	When set to 'static', RP to multicast grouping mapping MUST be		When set to 'static', RP to multicast grouping mapping MUST be
	configured as part of the 'rp-group-mappings' container. The RP MAY		configured as part of the 'rp-group-mappings' container. The RP MAY
	be a provider node or a customer node. When the RP is a customer		be a provider node or a customer node. When the RP is a customer
	node, the RP address must be configured using the 'rp-address' leaf		node, the RP address must be configured using the 'rp-address' leaf
	skipping to change at page 28, line 19 ¶		skipping to change at page 33, line 11 ¶
	| | +--rw rp-discovery-type? identityref		| | +--rw rp-discovery-type? identityref
	| | +--rw bsr-candidates		| | +--rw bsr-candidates
	| | +--rw bsr-candidate-address*		| | +--rw bsr-candidate-address*
	| | inet:ip-address		| | inet:ip-address
	| +--rw msdp {msdp}?		| +--rw msdp {msdp}?
	| +--rw enabled? boolean		| +--rw enabled? boolean
	| +--rw peer? inet:ip-address		| +--rw peer? inet:ip-address
	| +--rw local-address? inet:ip-address		| +--rw local-address? inet:ip-address
	+ ...		+ ...
	Figure 14: Multicast Tree Structure		Figure 16: Multicast Tree Structure
	6.3.3. Concept of Import/Export Profiles		6.3.3. Concept of Import/Export Profiles
	The import and export profiles construct contains a list with		The import and export profiles construct contains a list with
	information related with route target and distinguishers (RTs and		information related with route target and distinguishers (RTs and
	RDs), grouped and identified by ie-profile-id. The identifier is		RDs), grouped and identified by ie-profile-id. The identifier is
	then referenced in one or multiple vpn-nodes, so the PNC can identify		then referenced in one or multiple vpn-nodes, so the PNC can identify
	RTs and RDs to be configured in the VRF.		RTs and RDs to be configured in the VRF.
	6.3.4. Underlay Transport		6.3.4. Underlay Transport
	skipping to change at page 28, line 45 ¶		skipping to change at page 33, line 37 ¶
	TE as possible underlay transport.		TE as possible underlay transport.
	Other profiles can be defined in the future.		Other profiles can be defined in the future.
	This document does not make any assumption about the exact definition		This document does not make any assumption about the exact definition
	of these profiles. How such profiles are defined is deployment-		of these profiles. How such profiles are defined is deployment-
	specific.		specific.
	7. L3NM Module Tree Structure		7. L3NM Module Tree Structure
	The L3NM Module Tree Structure is depicted in Figure 15.		The L3NM Module Tree Structure is depicted in Figure 17.
	module: ietf-l3vpn-ntw		module: ietf-l3vpn-ntw
	+--rw l3vpn-ntw		+--rw l3vpn-ntw
	+--rw vpn-profiles		+--rw vpn-profiles
	| +--rw valid-provider-identifiers		| +--rw valid-provider-identifiers
	| +--rw cloud-identifier* [id] {l3vpn-svc:cloud-access}?		| +--rw cloud-identifier* [id] {l3vpn-svc:cloud-access}?
	| | +--rw id string		| | +--rw id string
	| +--rw encryption-profile-identifier* [id]		| +--rw encryption-profile-identifier* [id]
	| | +--rw id string		| | +--rw id string
	| +--rw qos-profile-identifier* [id]		| +--rw qos-profile-identifier* [id]
	skipping to change at page 29, line 43 ¶		skipping to change at page 34, line 35 ¶
	| | +--rw id int8		| | +--rw id int8
	| | +--rw route-targets* [route-target]		| | +--rw route-targets* [route-target]
	| | | +--rw route-target		| | | +--rw route-target
	| | | rt-types:route-target		| | | rt-types:route-target
	| | +--rw route-target-type		| | +--rw route-target-type
	| | rt-types:route-target-type		| | rt-types:route-target-type
	| +--rw vpn-policies		| +--rw vpn-policies
	| +--rw import-policy? leafref		| +--rw import-policy? leafref
	| +--rw export-policy? leafref		| +--rw export-policy? leafref
	+--rw underlay-transport		+--rw underlay-transport
	| +--rw type? protocols-type		| +--rw type* protocol-type
	+--rw vpn-nodes		+--rw vpn-nodes
	+--rw vpn-node* [ne-id]		+--rw vpn-node* [ne-id]
	+--rw vpn-node-id? union		+--rw vpn-node-id? union
	+--rw local-autonomous-system? inet:as-number		+--rw local-autonomous-system? inet:as-number
	+--rw description? string		+--rw description? string
	+--rw ne-id string		+--rw ne-id string
	+--rw router-id? inet:ip-address		+--rw router-id? inet:ip-address
	+--rw address-family?		+--rw address-family?
	| l3vpn-svc:address-family		| l3vpn-svc:address-family
	+--rw node-role? identityref		+--rw node-role? identityref
	+--rw rd?		+--rw rd? union
	| rt-types:route-distinguisher
	+--rw vpn-targets		+--rw vpn-targets
	| +--rw vpn-target* [id]		| +--rw vpn-target* [id]
	| | +--rw id int8		| | +--rw id int8
	| | +--rw route-targets* [route-target]		| | +--rw route-targets* [route-target]
	| | | +--rw route-target		| | | +--rw route-target
	| | | rt-types:route-target		| | | rt-types:route-target
	| | +--rw route-target-type		| | +--rw route-target-type
	| | rt-types:route-target-type		| | rt-types:route-target-type
	| +--rw vpn-policies		| +--rw vpn-policies
	| +--rw import-policy? leafref		| +--rw import-policy? leafref
	skipping to change at page 37, line 5 ¶		skipping to change at page 41, line 44 ¶
	| | | | | +--rw (source-port)?		| | | | | +--rw (source-port)?
	| | | | | | ...		| | | | | | ...
	| | | | | +--rw (destination-port)?		| | | | | +--rw (destination-port)?
	| | | | | | ...		| | | | | | ...
	| | | | +--:(match-application)		| | | | +--:(match-application)
	| | | | +--rw match-application?		| | | | +--rw match-application?
	| | | | identityref		| | | | identityref
	| | | +--rw target-class-id?		| | | +--rw target-class-id?
	| | | string		| | | string
	| | +--rw qos-profile		| | +--rw qos-profile
	| | +--rw (qos-profile)?		| | +--rw qos-profile* [profile]
	| | +--:(standard)		| | +--rw profile -> /l3vpn-ntw/...
	| | | +--rw profile? leafref		| | +--rw direction? identityref
	| | | +--rw direction? identityref
	| | +--:(custom)
	| | +--rw classes
	| | {l3vpn-svc:qos-custom}?
	| | +--rw class* [class-id]
	| | +--rw class-id
	| | | string
	| | +--rw direction?
	| | | identityref
	| | +--rw rate-limit?
	| | | decimal64
	| | +--rw latency
	| | | +--rw (flavor)?
	| | | +--:(lowest)
	| | | | +--rw use-lowest-latency?
	| | | | empty
	| | | +--:(boundary)
	| | | +--rw jitter-boundary?
	| | | uint16
	| | +--rw jitter
	| | | +--rw (flavor)?
	| | | +--:(lowest)
	| | | | +--rw use-lowest-jitter?
	| | | | empty
	| | | +--:(boundary)
	| | | +--rw latency-boundary?
	| | | uint32
	| | +--rw bandwidth
	| | +--rw guaranteed-bw-percent
	| | | decimal64
	| | +--rw end-to-end?
	| | empty
	| +--rw carrierscarrier		| +--rw carrierscarrier
	| | {l3vpn-svc:carrierscarrier}?		| | {l3vpn-svc:carrierscarrier}?
	| | +--rw signalling-type? enumeration		| | +--rw signalling-type? enumeration
	| +--rw multicast {l3vpn-svc:multicast}?		| +--rw multicast {l3vpn-svc:multicast}?
	| +--rw site-type? enumeration		| +--rw site-type? enumeration
	| +--rw address-family		| +--rw address-family
	| | +--rw ipv4? boolean		| | +--rw ipv4? boolean
	| | | {l3vpn-svc:ipv4}?		| | | {l3vpn-svc:ipv4}?
	| | +--rw ipv6? boolean		| | +--rw ipv6? boolean
	| | {l3vpn-svc:ipv6}?		| | {l3vpn-svc:ipv6}?
	skipping to change at page 39, line 6 ¶		skipping to change at page 43, line 13 ¶
	| | +--rw rp-discovery-type? identityref		| | +--rw rp-discovery-type? identityref
	| | +--rw bsr-candidates		| | +--rw bsr-candidates
	| | +--rw bsr-candidate-address*		| | +--rw bsr-candidate-address*
	| | inet:ip-address		| | inet:ip-address
	| +--rw msdp {msdp}?		| +--rw msdp {msdp}?
	| +--rw enabled? boolean		| +--rw enabled? boolean
	| +--rw peer? inet:ip-address		| +--rw peer? inet:ip-address
	| +--rw local-address? inet:ip-address		| +--rw local-address? inet:ip-address
	+--rw node-ie-profile? leafref		+--rw node-ie-profile? leafref
	Figure 15		Figure 17
	8. Sample Uses of the L3NM Data Model		8. Sample Uses of the L3NM Data Model
	8.1. Enterprise L3 VPN Services		8.1. Enterprise L3 VPN Services
	Enterprise L3VPNs are one of the most demanded services for carriers,		Enterprise L3VPNs are one of the most demanded services for carriers,
	and therefore, L3NM can be useful to automate the tasks of		and therefore, L3NM can be useful to automate the tasks of
	provisioning and maintenance of these VPNs. Templates and batch		provisioning and maintenance of these VPNs. Templates and batch
	processes can be built, and as a result many parameters are needed		processes can be built, and as a result many parameters are needed
	for the creation from scratch of a VPN that can be abstracted to the		for the creation from scratch of a VPN that can be abstracted to the
	skipping to change at page 40, line 23 ¶		skipping to change at page 44, line 32 ¶
	backbone. Because of this, ng-MNPN is the architectural model that		backbone. Because of this, ng-MNPN is the architectural model that
	has been taken as the base for implementing multicast service on		has been taken as the base for implementing multicast service on
	L3VPN. In this scenario, BGP auto discovery is used to discover MVPN		L3VPN. In this scenario, BGP auto discovery is used to discover MVPN
	PE members and the customer PIM signaling is sent across provider		PE members and the customer PIM signaling is sent across provider
	core through MP-BGP. The multicast traffic is transported on MPLS		core through MP-BGP. The multicast traffic is transported on MPLS
	P2MP LSPs. All of the previous information is carried in the MCAST-		P2MP LSPs. All of the previous information is carried in the MCAST-
	VPN BGP NRLI.		VPN BGP NRLI.
	9. L3VPN Examples		9. L3VPN Examples
	9.1. 4G VPN Provissioning Example		9.1. 4G VPN Provisioning Example
	L3VPNs are widely used to deploy 3G/4G, fixed, and enterprise		L3VPNs are widely used to deploy 3G/4G, fixed, and enterprise
	services mainly because several traffic discrimination policies can		services mainly because several traffic discrimination policies can
	be applied within the network to deliver to the mobile customers a		be applied within the network to deliver to the mobile customers a
	service that meets the SLA requiremets.		service that meets the SLA requirements.
	As it is shown in the Figure 16, typically, an eNodeB (CE) is		As it is shown in the Figure 18, typically, an eNodeB (CE) is
	directly connected to the access routers of the mobile backhaul and		directly connected to the access routers of the mobile backhaul and
	their logical interfaces (one or many according to the Service type)		their logical interfaces (one or many according to the Service type)
	are configured in a VPN that transports the packets to the mobile		are configured in a VPN that transports the packets to the mobile
	core platforms. In this example, a 'vpn-node' is created with two		core platforms. In this example, a 'vpn-node' is created with two
	'vpn-network-accesses'.		'vpn-network-accesses'.
	+-------------+ +------------------+		+-------------+ +------------------+
	| | | PE |		| | | PE |
	| | 192.168.0.2 | 10.0.0.1 |		| | 192.168.0.2 | 10.0.0.1 |
	| eNodeB |>--------/------->|........... |		| eNodeB |>--------/------->|........... |
	| | Vlan 1 | | |		| | Vlan 1 | | |
	| |>--------/------->|...... | |		| |>--------/------->|...... | |
	| | Vlan 2 | | | |		| | Vlan 2 | | | |
	| | Direct | +-------------+ |		| | Direct | +-------------+ |
	+-------------+ Routing | | vpn-node-id | |		+-------------+ Routing | | vpn-node-id | |
	| | 44 | |		| | 44 | |
	| +-------------+ |		| +-------------+ |
	| |		| |
	+------------------+		+------------------+
	Figure 16: Mobile Backhaul Example		Figure 18: Mobile Backhaul Example
	To create a L3VPN service using the L3NM model, the followng sample		To create a L3VPN service using the L3NM model, the following sample
	steps can be followed:		steps can be followed:
	First: Create the 4G VPN Service (Figure 17).		First: Create the 4G VPN Service (Figure 19).
	POST: /restconf/data/ietf-l3vpn-ntw:l3vpn-ntw/vpn-services		POST: /restconf/data/ietf-l3vpn-ntw:l3vpn-ntw/vpn-services
	Host: example.com		Host: example.com
	Content-Type: application/yang-data+json		Content-Type: application/yang-data+json
	{		{
	"ietf-l3vpn-ntw:vpn-services": {		"ietf-l3vpn-ntw:vpn-services": {
	"vpn-service": [		"vpn-service": [
	"vpn-id": "4G",		"vpn-id": "4G",
	"customer-name": "mycustomer",		"customer-name": "mycustomer",
	"vpn-service-topology": "custom",		"vpn-service-topology": "custom",
	"description": "VPN to deploy 4G services"		"description": "VPN to deploy 4G services"
	]		]
	}		}
	}		}
	Figure 17: Create VPN Service		Figure 19: Create VPN Service
	Second: Create a VPN Node as depicted in Figure 18. In this type of		Second: Create a VPN Node as depicted in Figure 20. In this type of
	service, the VPN Node is equivalent to the VRF configured in the		service, the VPN Node is equivalent to the VRF configured in the
	physical device ('ne-id'=10.0.0.1).		physical device ('ne-id'=10.0.0.1).
	POST: /restconf/data/ietf-l3vpn-ntw:l3vpn-ntw/\		POST: /restconf/data/ietf-l3vpn-ntw:l3vpn-ntw/\
	vpn-services/vpn-service=4G		vpn-services/vpn-service=4G
	Host: example.com		Host: example.com
	Content-Type: application/yang-data+json		Content-Type: application/yang-data+json
	{		{
	"ietf-l3vpn-ntw:vpn-nodes": {		"ietf-l3vpn-ntw:vpn-nodes": {
	skipping to change at page 42, line 28 ¶		skipping to change at page 46, line 28 ¶
	"vpn-target": [		"vpn-target": [
	"id": "1",		"id": "1",
	"route-targets": ["route-target": "0:65550:1"],		"route-targets": ["route-target": "0:65550:1"],
	"route-target-type": "both"		"route-target-type": "both"
	}		}
	}		}
	]		]
	}		}
	}		}
	Figure 18: Create VPN Node		Figure 20: Create VPN Node
	Finally, two VPN Network Accesses are created using the same physical		Finally, two VPN Network Accesses are created using the same physical
	port ('port-id'=1/1/1). Each 'vpn-network-access' has a particular		port ('port-id'=1/1/1). Each 'vpn-network-access' has a particular
	VLAN (1,2) to differentiante the traffic between: Sync and data		VLAN (1,2) to differentiate the traffic between: Sync and data
	(Figure 19).		(Figure 21).
	POST: /restconf/data/ietf-l3vpn-ntw:l3vpn-ntw/\		POST: /restconf/data/ietf-l3vpn-ntw:l3vpn-ntw/\
	vpn-services/vpn-service=4G/vpn-nodes/vpn-node=44		vpn-services/vpn-service=4G/vpn-nodes/vpn-node=44
	content-type: application/yang-data+json		content-type: application/yang-data+json
	{		{
	"ietf-l3vpn-ntw:vpn-network-accesses": {		"ietf-l3vpn-ntw:vpn-network-accesses": {
	"vpn-network-access": [		"vpn-network-access": [
	{		{
	"vpn-network-access-id": "1/1/1.1",		"vpn-network-access-id": "1/1/1.1",
	"port-id": "1/1/1",		"port-id": "1/1/1",
	"description": "Interface SYNC to eNODE-B",		"description": "Interface SYNC to eNODE-B",
	"status": {"admin-enabled": "true"},		"status": {"admin-enabled": "true"},
	"vpn-network-access-type": "l3vpn-svc:point-to-point",		"vpn-network-access-type": "l3vpn-svc:point-to-point",
	"ip-connection": {		"ip-connection": {
	skipping to change at page 43, line 48 ¶		skipping to change at page 47, line 49 ¶
	"routing-protocol": [		"routing-protocol": [
	"id": "1",		"id": "1",
	"type": "l3vpn-svc:direct"		"type": "l3vpn-svc:direct"
	]		]
	}		}
	}		}
	]		]
	}		}
	}		}
	Figure 19: Create VPN Network Access		Figure 21: Create VPN Network Access
	9.2. Multicast VPN Provisioning Example		9.2. Multicast VPN Provisioning Example
	IPTV is mainly distributed through multicast over the LANs. In the		IPTV is mainly distributed through multicast over the LANs. In the
	following example, PIM-SM is enabled and functional between the PE		following example, PIM-SM is enabled and functional between the PE
	and the CE. The PE receives multicast traffic from a CE that is		and the CE. The PE receives multicast traffic from a CE that is
	directly connected to the multicast source. The signaling between PE		directly connected to the multicast source. The signaling between PE
	and CE is achieved using BGP. Also, RP is statically configured for		and CE is achieved using BGP. Also, RP is statically configured for
	a multicast group.		a multicast group.
	+-----------+ +------+ +------+ +-----------+		+-----------+ +------+ +------+ +-----------+
	| Multicast |---| CE |--/--| PE |----| Backbone |		| Multicast |---| CE |--/--| PE |----| Backbone |
	| source | +------+ +------+ | IP/MPLS |		| source | +------+ +------+ | IP/MPLS |
	+-----------+ +-----------+		+-----------+ +-----------+
	Figure 20: Multicast L3VPN Service Example		Figure 22: Multicast L3VPN Service Example
	To configure a Multicast L3VPN service using the L3NM model the		To configure a Multicast L3VPN service using the L3NM model the
	procedure and the JSON with the data structure is the following:		procedure and the JSON with the data structure is the following:
	First, the multicast service is created (see the excerpt of the		First, the multicast service is created (see the excerpt of the
	request message body shown in Figure 21)		request message body shown in Figure 23)
	"vpn-services": {		"vpn-services": {
	"vpn-service": {		"vpn-service": {
	"vpn-id": "Multicast_IPTV",		"vpn-id": "Multicast_IPTV",
	"customer-name": "310",		"customer-name": "310",
	"vpn-service-topology": "hub-spoke",		"vpn-service-topology": "hub-spoke",
	"description": "Multicast IPTV VPN service"		"description": "Multicast IPTV VPN service"
	}		}
	}		}
	Figure 21: Create Multicast VPN Service (Excerpt of the Message		Figure 23: Create Multicast VPN Service (Excerpt of the Message
	Request Body)		Request Body)
	Then, the VPN nodes are created (see the excerpt of the request		Then, the VPN nodes are created (see the excerpt of the request
	message body shown in Figure 22). In this example, the VPN Node will		message body shown in Figure 24). In this example, the VPN Node will
	represent VRF configured in the physical device.		represent VRF configured in the physical device.
	"vpn-node": [		"vpn-node": [
	"vpn-node-id": "500003105",		"vpn-node-id": "500003105",
	"ne-id": "10.250.2.202",		"ne-id": "10.250.2.202",
	"autonomous-system": "3816",		"autonomous-system": "3816",
	"description": "VRF_IPTV_MULTICAST",		"description": "VRF_IPTV_MULTICAST",
	"router-id": "10.250.2.202",		"router-id": "10.250.2.202",
	"address-family": "ipv4",		"address-family": "ipv4",
	"node-role": {		"node-role": {
	skipping to change at page 45, line 40 ¶		skipping to change at page 49, line 40 ¶
	},		},
	"rp-discovery": {		"rp-discovery": {
	"rp-discovery-type": {		"rp-discovery-type": {
	"l3vpn-svc:static-rp"		"l3vpn-svc:static-rp"
	}		}
	}		}
	}		}
	}		}
	]		]
	Figure 22: Create Multicast VPN Node (Excerpt of the Message Request		Figure 24: Create Multicast VPN Node (Excerpt of the Message Request
	Body)		Body)
	Finally, create the VPN Network Access with Multicast enabled (see		Finally, create the VPN Network Access with Multicast enabled (see
	the excerpt of the request message body shown in Figure 23)		the excerpt of the request message body shown in Figure 25)
	"vpn-network-access": {		"vpn-network-access": {
	"vpn-network-access-id": "1/1/1",		"vpn-network-access-id": "1/1/1",
	"description": "Connected_to_source",		"description": "Connected_to_source",
	"status": { "admin-enabled": "true" },		"status": { "admin-enabled": "true" },
	"vpn-network-access-type": {		"vpn-network-access-type": {
	"l3vpn-svc:point-to-point"		"l3vpn-svc:point-to-point"
	},		},
	"ip-connection": {		"ip-connection": {
	"ipv4": {		"ipv4": {
	skipping to change at page 46, line 43 ¶		skipping to change at page 50, line 43 ¶
	},		},
	"service": {		"service": {
	"multicast": {		"multicast": {
	"multicast-site-type": "source-only",		"multicast-site-type": "source-only",
	"multicast-address-family": { "ipv4": "true" },		"multicast-address-family": { "ipv4": "true" },
	"protocol-type": "router"		"protocol-type": "router"
	}		}
	}		}
	}		}
	Figure 23: Create VPN Network Access (Excerpt of the Message Request		Figure 25: Create VPN Network Access (Excerpt of the Message Request
	Body)		Body)
	10. L3NM YANG Module		10. L3NM YANG Module
	<CODE BEGINS> file "ietf-l3vpn-ntw@2020-03.09.yang"		<CODE BEGINS> file "ietf-l3vpn-ntw@2020-03.09.yang"
	module ietf-l3vpn-ntw {		module ietf-l3vpn-ntw {
	yang-version 1.1;		yang-version 1.1;
	namespace "urn:ietf:params:xml:ns:yang:ietf-l3vpn-ntw";		namespace "urn:ietf:params:xml:ns:yang:ietf-l3vpn-ntw";
	prefix l3vpn-ntw;		prefix l3vpn-ntw;
	skipping to change at page 48, line 25 ¶		skipping to change at page 52, line 25 ¶
	without modification, is permitted pursuant to, and subject to		without modification, is permitted pursuant to, and subject to
	the license terms contained in, the Simplified BSD License set		the license terms contained in, the Simplified BSD License set
	forth in Section 4.c of the IETF Trust's Legal Provisions		forth in Section 4.c of the IETF Trust's Legal Provisions
	Relating to IETF Documents		Relating to IETF Documents
	(https://trustee.ietf.org/license-info).		(https://trustee.ietf.org/license-info).
	This version of this YANG module is part of RFC XXXX		This version of this YANG module is part of RFC XXXX
	(https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself		(https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself
	for full legal notices.";		for full legal notices.";
	revision 2020-03-09 {		revision 2020-04-03 {
	description		description
	"Initial revision.";		"Initial revision.";
	reference		reference
	"RFC XXXX: A Layer 3 VPN Network YANG Model";		"RFC XXXX: A Layer 3 VPN Network YANG Model";
			// RFC Ed.: replace XXXX with actual RFC number and remove
			// this note
	}		}
	/* Features */		/* Features */
	feature msdp {		feature msdp {
	description		description
	"This feature indicates that msdp capabilities		"This feature indicates that msdp capabilities
	are supported by the VPN.";		are supported by the VPN.";
	}		}
	skipping to change at page 49, line 34 ¶		skipping to change at page 53, line 36 ¶
	}		}
	feature vxlan {		feature vxlan {
	description		description
	"This feature indicates the support of		"This feature indicates the support of
	the 'vxlan' encapsulation.";		the 'vxlan' encapsulation.";
	}		}
	/* Typedefs */		/* Typedefs */
	typedef protocols-type {		typedef protocol-type {
	type enumeration {		type enumeration {
	enum GRE {		enum GRE {
	value 0;		value 0;
	description		description
	"Transport based on GRE.";		"Transport based on GRE.";
	}		}
	enum LDP {		enum LDP {
	value 1;		value 1;
	description		description
	"Transport based on LDP.";		"Transport based on LDP.";
	skipping to change at page 56, line 24 ¶		skipping to change at page 60, line 27 ¶
	}		}
	identity bw-type {		identity bw-type {
	description		description
	"Identity of the bandwidth type.";		"Identity of the bandwidth type.";
	}		}
	identity bw-per-cos {		identity bw-per-cos {
	base bw-type;		base bw-type;
	description		description
	"Bandwidth is per Class of Service (CoS).";		"Bandwidth is per CoS.";
	}		}
	identity bw-per-port {		identity bw-per-port {
	base bw-type;		base bw-type;
	description		description
	"Bandwidth is per site network access.";		"Bandwidth is per site network access.";
	}		}
	identity bw-per-site {		identity bw-per-site {
	base bw-type;		base bw-type;
	skipping to change at page 56, line 50 ¶		skipping to change at page 61, line 5 ¶
	identity bw-per-svc {		identity bw-per-svc {
	base bw-type;		base bw-type;
	description		description
	"Bandwidth is per VPN service.";		"Bandwidth is per VPN service.";
	}		}
	/* Groupings */		/* Groupings */
	grouping svc-transport-encapsulation {		grouping svc-transport-encapsulation {
	container underlay-transport {		container underlay-transport {
	leaf type {		leaf-list type {
	type protocols-type;		type protocol-type;
			ordered-by user;
	description		description
	"Protocols used to deliver an L3VPN service.";		"Protocols used to deliver an L3VPN service.";
	}		}
	description		description
	"";		"Container for the Transport Underlay.";
	}		}
	description		description
	"";		"This grouping defines the type of underlay transport
			for VPN service.";
	}		}
	grouping multicast-rp-group-cfg {		grouping multicast-rp-group-cfg {
	choice group-format {		choice group-format {
	mandatory true;		mandatory true;
	case group-prefix {		case group-prefix {
	leaf group-address {		leaf group-address {
	type inet:ip-prefix;		type inet:ip-prefix;
	description		description
	"A single multicast group prefix.";		"A single multicast group prefix.";
	skipping to change at page 60, line 23 ¶		skipping to change at page 64, line 28 ¶
	leaf rp-discovery-type {		leaf rp-discovery-type {
	type identityref {		type identityref {
	base l3vpn-svc:multicast-rp-discovery-type;		base l3vpn-svc:multicast-rp-discovery-type;
	}		}
	default "l3vpn-svc:static-rp";		default "l3vpn-svc:static-rp";
	description		description
	"Type of RP discovery used.";		"Type of RP discovery used.";
	}		}
	container bsr-candidates {		container bsr-candidates {
	when "derived-from-or-self(../rp-discovery-type, "		when "derived-from-or-self(../rp-discovery-type, "
	+ "'l3vpn-ntw:bsr-rp')" {		+ "'l3vpn-svc:bsr-rp')" {
	description		description
	"Only applicable if discovery type		"Only applicable if discovery type
	is BSR-RP.";		is BSR-RP.";
	}		}
	leaf-list bsr-candidate-address {		leaf-list bsr-candidate-address {
	type inet:ip-address;		type inet:ip-address;
	description		description
	"Address of candidate Bootstrap Router (BSR).";		"Address of candidate Bootstrap Router (BSR).";
	}		}
	description		description
	skipping to change at page 66, line 41 ¶		skipping to change at page 70, line 44 ¶
	"Identification of the class of service.		"Identification of the class of service.
	This identifier is internal to the administration.";		This identifier is internal to the administration.";
	}		}
	description		description
	"List of marking rules.";		"List of marking rules.";
	}		}
	description		description
	"Configuration of the traffic classification policy.";		"Configuration of the traffic classification policy.";
	}		}
	container qos-profile {		container qos-profile {
	choice qos-profile {		list qos-profile {
			key profile;
	description		description
	"Choice for QoS profile.		"QoS profile.
	Can be standard profile or customized profile.";		Can be standard profile or customized profile.";
	case standard {
	description
	"Standard QoS profile.";
	leaf profile {		leaf profile {
	type leafref {		type leafref {
	path "/l3vpn-ntw/vpn-profiles/"		path "/l3vpn-ntw/vpn-profiles/"
	+ "valid-provider-identifiers"		+ "valid-provider-identifiers"
	+ "/qos-profile-identifier/id";		+ "/qos-profile-identifier/id";
	}		}
	description		description
	"QoS profile to be used.";		"QoS profile to be used.";
	}		}
	leaf direction {		leaf direction {
	type identityref {		type identityref {
	base l3vpn-svc:qos-profile-direction;		base l3vpn-svc:qos-profile-direction;
	}		}
	default "l3vpn-svc:both";		default "l3vpn-svc:both";
	description		description
	"The direction to which the QoS profile		"The direction to which the QoS profile
	is applied.";		is applied.";
	}		}
	}
	case custom {
	description
	"Customized QoS profile.";
	container classes {
	if-feature "l3vpn-svc:qos-custom";
	list class {
	key "class-id";
	leaf class-id {
	type string;
	description
	"Identification of the class of service.
	This identifier is internal to the
	administration.";
	}
	leaf direction {
	type identityref {
	base l3vpn-svc:qos-profile-direction;
	}
	default "l3vpn-svc:both";
	description
	"The direction to which the QoS profile
	is applied.";
	}
	leaf rate-limit {
	type decimal64 {
	fraction-digits 5;
	range "0..100";
	}
	units "percent";
	description
	"To be used if the class must be rate-limited.
	Expressed as percentage of the service
	bandwidth.";
	}
	container latency {
	choice flavor {
	case lowest {
	leaf use-lowest-latency {
	type empty;
	description
	"The traffic class should
	use the path with the
	lowest latency.";
	}
	}
	case boundary {
	leaf jitter-boundary {
	type uint16;
	units "msec";
	default "400";
	description
	"The traffic class
	should use a path with a
	defined maximum latency.";
	}
	}
	description
	"Latency constraint
	on the traffic class.";
	}
	description
	"Latency constraint
	on the traffic class.";
	}
	container jitter {
	choice flavor {
	case lowest {
	leaf use-lowest-jitter {
	type empty;
	description
	"The traffic class
	should use the path with the
	lowest jitter.";
	}
	}
	case boundary {
	leaf latency-boundary {
	type uint32;
	units "usec";
	default "40000";
	description
	"The traffic class
	should use a path with a
	defined maximum jitter.";
	}
	}
	description
	"Jitter constraint on the traffic class.";
	}
	description
	"Jitter constraint on the traffic class.";
	}
	container bandwidth {
	leaf guaranteed-bw-percent {
	type decimal64 {
	fraction-digits 5;
	range "0..100";
	}
	units "percent";
	mandatory true;
	description
	"To be used to define the guaranteed bandwidth
	as a percentage of the available service
	bandwidth.";
	}
	leaf end-to-end {
	type empty;
	description
	"Used if the bandwidth reservation
	must be done on the MPLS network too.";
	}
	description
	"Bandwidth constraint on the traffic class.";
	}
	description
	"List of classes of services.";
	}
	description
	"Container for list of classes of services.";
	}
	}
	}		}
	description		description
	"QoS profile configuration.";		"QoS profile configuration.";
	}		}
	description		description
	"QoS configuration.";		"QoS configuration.";
	}		}
	description		description
	"This grouping defines QoS parameters for a site.";		"This grouping defines QoS parameters for a site.";
	}		}
	skipping to change at page 70, line 49 ¶		skipping to change at page 72, line 24 ¶
	description		description
	"Encryption will occur at Layer 3.		"Encryption will occur at Layer 3.
	For example, IPsec may be used when		For example, IPsec may be used when
	a customer requests Layer 3 encryption.";		a customer requests Layer 3 encryption.";
	}		}
	}		}
	description		description
	"Layer on which encryption is applied.";		"Layer on which encryption is applied.";
	}		}
	description		description
	"";		"Container for CE-PE security encryption.";
	}		}
	container encryption-profile {		container encryption-profile {
	choice profile {		choice profile {
	case provider-profile {		case provider-profile {
	leaf profile-name {		leaf profile-name {
	type leafref {		type leafref {
	path "/l3vpn-ntw/vpn-profiles/"		path "/l3vpn-ntw/vpn-profiles/"
	+ "valid-provider-identifiers"		+ "valid-provider-identifiers"
	+ "/encryption-profile-identifier/id";		+ "/encryption-profile-identifier/id";
	}		}
	skipping to change at page 71, line 24 ¶		skipping to change at page 72, line 47 ¶
	}		}
	}		}
	case customer-profile {		case customer-profile {
	leaf algorithm {		leaf algorithm {
	type string;		type string;
	description		description
	"Encryption algorithm to be used.";		"Encryption algorithm to be used.";
	}		}
	}		}
	description		description
	"";		"Choice for encryption profile.";
	}		}
	choice key-type {		choice key-type {
	default "psk";		default "psk";
	case psk {		case psk {
	leaf preshared-key {		leaf preshared-key {
	type string;		type string;
	description		description
	"Pre-Shared Key (PSK) coming from the customer.";		"Pre-Shared Key (PSK) coming from the customer.";
	}		}
	}		}
	description		description
	"Choice of encryption profile.		"Choice of encryption profile.
	The encryption profile can be the provider profile		The encryption profile can be the provider profile
	or customer profile.";		or customer profile.";
	}		}
	description		description
	"This grouping defines encryption parameters for		"Container for encryption profile.";
	a site.";
	}		}
	description		description
	"";		"This grouping defines encryption parameters for
			a site.";
	}		}
	grouping site-routing {		grouping site-routing {
	container routing-protocols {		container routing-protocols {
	list routing-protocol {		list routing-protocol {
	key "id";		key "id";
	leaf id {		leaf id {
	type string;		type string;
	description		description
	"";		"Unique identifier for routing protocol.";
	}		}
	leaf type {		leaf type {
	type identityref {		type identityref {
	base l3vpn-svc:routing-protocol-type;		base l3vpn-svc:routing-protocol-type;
	}		}
	description		description
	"Type of routing protocol.";		"Type of routing protocol.";
	}		}
	list routing-profiles {		list routing-profiles {
	key "id";		key "id";
	skipping to change at page 72, line 36 ¶		skipping to change at page 74, line 11 ¶
	}		}
	leaf type {		leaf type {
	type ie-type;		type ie-type;
	description		description
	"Import, export or both.";		"Import, export or both.";
	}		}
	description		description
	"Import or Export profile reference";		"Import or Export profile reference";
	}		}
	container ospf {		container ospf {
	when "derived-from-or-self(../type, 'l3vpn-ntw:ospf')" {		when "derived-from-or-self(../type, 'l3vpn-svc:ospf')" {
	description		description
	"Only applies when protocol is OSPF.";		"Only applies when protocol is OSPF.";
	}		}
	if-feature "l3vpn-svc:rtg-ospf";		if-feature "l3vpn-svc:rtg-ospf";
	leaf-list address-family {		leaf-list address-family {
	type l3vpn-svc:address-family;		type l3vpn-svc:address-family;
	min-elements 1;		min-elements 1;
	description		description
	"If OSPF is used on this site, this node		"If OSPF is used on this site, this node
	contains a configured value. This node		contains a configured value. This node
	skipping to change at page 74, line 11 ¶		skipping to change at page 75, line 34 ¶
	description		description
	"Creates a sham link with another site.";		"Creates a sham link with another site.";
	}		}
	description		description
	"List of sham links.";		"List of sham links.";
	}		}
	description		description
	"OSPF-specific configuration.";		"OSPF-specific configuration.";
	}		}
	container bgp {		container bgp {
	when "derived-from-or-self(../type, 'l3vpn-ntw:bgp')" {		when "derived-from-or-self(../type, 'l3vpn-svc:bgp')" {
	description		description
	"Only applies when protocol is BGP.";		"Only applies when protocol is BGP.";
	}		}
	if-feature "l3vpn-svc:rtg-bgp";		if-feature "l3vpn-svc:rtg-bgp";
	leaf peer-autonomous-system {		leaf peer-autonomous-system {
	type inet:as-number;		type inet:as-number;
	mandatory true;		mandatory true;
	description		description
	"Customer AS number in case the customer		"Customer AS number in case the customer
	requests BGP routing.";		requests BGP routing.";
	skipping to change at page 76, line 30 ¶		skipping to change at page 78, line 5 ¶
	}		}
	default "active";		default "active";
	description		description
	"ISIS interface mode type.";		"ISIS interface mode type.";
	}		}
	uses status-params;		uses status-params;
	description		description
	"ISIS-specific configuration.";		"ISIS-specific configuration.";
	}		}
	container static {		container static {
	when "derived-from-or-self(../type, 'l3vpn-ntw:static')" {		when "derived-from-or-self(../type, 'l3vpn-svc:static')" {
	description		description
	"Only applies when protocol is static.		"Only applies when protocol is static.
	BGP activation requires the SP to know		BGP activation requires the SP to know
	the address of the customer peer. When		the address of the customer peer. When
	BGP is enabled, the 'static-address'		BGP is enabled, the 'static-address'
	allocation type for the IP connection		allocation type for the IP connection
	MUST be used.";		MUST be used.";
	}		}
	container cascaded-lan-prefixes {		container cascaded-lan-prefixes {
	list ipv4-lan-prefixes {		list ipv4-lan-prefixes {
	skipping to change at page 77, line 42 ¶		skipping to change at page 79, line 16 ¶
	description		description
	"List of LAN prefixes for the site.";		"List of LAN prefixes for the site.";
	}		}
	description		description
	"LAN prefixes from the customer.";		"LAN prefixes from the customer.";
	}		}
	description		description
	"Configuration specific to static routing.";		"Configuration specific to static routing.";
	}		}
	container rip {		container rip {
	when "derived-from-or-self(../type, 'l3vpn-ntw:rip')" {		when "derived-from-or-self(../type, 'l3vpn-svc:rip')" {
	description		description
	"Only applies when the protocol is RIP. For IPv4,		"Only applies when the protocol is RIP. For IPv4,
	the model assumes that RIP version 2 is used.";		the model assumes that RIP version 2 is used.";
	}		}
	if-feature "l3vpn-svc:rtg-rip";		if-feature "l3vpn-svc:rtg-rip";
	leaf-list address-family {		leaf-list address-family {
	type l3vpn-svc:address-family;		type l3vpn-svc:address-family;
	min-elements 1;		min-elements 1;
	description		description
	"If RIP is used on this site, this node		"If RIP is used on this site, this node
	contains a configured value. This node		contains a configured value. This node
	contains at least one address family		contains at least one address family
	to be activated.";		to be activated.";
	}		}
	description		description
	"Configuration specific to RIP routing.";		"Configuration specific to RIP routing.";
	}		}
	container vrrp {		container vrrp {
	when "derived-from-or-self(../type, 'l3vpn-ntw:vrrp')" {		when "derived-from-or-self(../type, 'l3vpn-svc:vrrp')" {
	description		description
	"Only applies when protocol is VRRP.";		"Only applies when protocol is VRRP.";
	}		}
	if-feature "l3vpn-svc:rtg-vrrp";		if-feature "l3vpn-svc:rtg-vrrp";
	leaf-list address-family {		leaf-list address-family {
	type l3vpn-svc:address-family;		type l3vpn-svc:address-family;
	min-elements 1;		min-elements 1;
	description		description
	"If VRRP is used on this site, this node		"If VRRP is used on this site, this node
	contains a configured value. This node contains		contains a configured value. This node contains
	skipping to change at page 78, line 47 ¶		skipping to change at page 80, line 22 ¶
	}		}
	grouping site-attachment-ip-connection {		grouping site-attachment-ip-connection {
	container ip-connection {		container ip-connection {
	container ipv4 {		container ipv4 {
	if-feature "l3vpn-svc:ipv4";		if-feature "l3vpn-svc:ipv4";
	leaf address-allocation-type {		leaf address-allocation-type {
	type identityref {		type identityref {
	base l3vpn-svc:address-allocation-type;		base l3vpn-svc:address-allocation-type;
	}		}
	must "not(derived-from-or-self(current(), 'l3vpn-ntw:slaac')"		must "not(derived-from-or-self(current(), 'l3vpn-svc:slaac')"
	+ " or derived-from-or-self(current(), "		+ " or derived-from-or-self(current(), "
	+ "'l3vpn-ntw:provider-dhcp-slaac'))" {		+ "'l3vpn-svc:provider-dhcp-slaac'))" {
	error-message "SLAAC is only applicable to IPv6";		error-message "SLAAC is only applicable to IPv6";
	}		}
	description		description
	"Defines how addresses are allocated.		"Defines how addresses are allocated.
	If there is no value for the address		If there is no value for the address
	allocation type, then IPv4 is not enabled.";		allocation type, then IPv4 is not enabled.";
	}		}
	container provider-dhcp {		container provider-dhcp {
	when "derived-from-or-self(../address-allocation-type, "		when "derived-from-or-self(../address-allocation-type, "
	+ "'l3vpn-ntw:provider-dhcp')" {		+ "'l3vpn-svc:provider-dhcp')" {
	description		description
	"Only applies when addresses are allocated by DHCP.";		"Only applies when addresses are allocated by DHCP.";
	}		}
	leaf provider-address {		leaf provider-address {
	type inet:ipv4-address;		type inet:ipv4-address;
	description		description
	"Address of provider side. If provider-address is not		"Address of provider side. If provider-address is not
	specified, then prefix length should not be specified		specified, then prefix length should not be specified
	either. It also implies provider-dhcp allocation is		either. It also implies provider-dhcp allocation is
	not enabled. If provider-address is specified, then		not enabled. If provider-address is specified, then
	skipping to change at page 80, line 48 ¶		skipping to change at page 82, line 23 ¶
	}		}
	}		}
	description		description
	"Choice for the way to assign addresses.";		"Choice for the way to assign addresses.";
	}		}
	description		description
	"DHCP allocated addresses related parameters.";		"DHCP allocated addresses related parameters.";
	}		}
	container dhcp-relay {		container dhcp-relay {
	when "derived-from-or-self(../address-allocation-type, "		when "derived-from-or-self(../address-allocation-type, "
	+ "'l3vpn-ntw:provider-dhcp-relay')" {		+ "'l3vpn-svc:provider-dhcp-relay')" {
	description		description
	"Only applies when provider is required to implement		"Only applies when provider is required to implement
	DHCP relay function.";		DHCP relay function.";
	}		}
	leaf provider-address {		leaf provider-address {
	type inet:ipv4-address;		type inet:ipv4-address;
	description		description
	"Address of provider side. If provider-address is not		"Address of provider side. If provider-address is not
	specified, then prefix length should not be specified		specified, then prefix length should not be specified
	either. It also implies provider-dhcp allocation is		either. It also implies provider-dhcp allocation is
	skipping to change at page 81, line 45 ¶		skipping to change at page 83, line 20 ¶
	"IP address of customer DHCP server.";		"IP address of customer DHCP server.";
	}		}
	description		description
	"Container for list of customer DHCP servers.";		"Container for list of customer DHCP servers.";
	}		}
	description		description
	"DHCP relay provided by operator.";		"DHCP relay provided by operator.";
	}		}
	container static-addresses {		container static-addresses {
	when "derived-from-or-self(../address-allocation-type, "		when "derived-from-or-self(../address-allocation-type, "
	+ "'l3vpn-ntw:static-address')" {		+ "'l3vpn-svc:static-address')" {
	description		description
	"Only applies when protocol allocation type is static.";		"Only applies when protocol allocation type is static.";
	}		}
	leaf primary-address {		leaf primary-address {
	type leafref {		type leafref {
	path "/l3vpn-ntw/vpn-services/vpn-service/vpn-nodes/"		path "/l3vpn-ntw/vpn-services/vpn-service/vpn-nodes/"
	+ "vpn-node/vpn-network-accesses/vpn-network-access/"		+ "vpn-node/vpn-network-accesses/vpn-network-access/"
	+ "ip-connection/ipv4/static-addresses/address/"		+ "ip-connection/ipv4/static-addresses/address/"
	+ "address-id";		+ "address-id";
	}		}
	skipping to change at page 83, line 14 ¶		skipping to change at page 84, line 38 ¶
	base l3vpn-svc:address-allocation-type;		base l3vpn-svc:address-allocation-type;
	}		}
	description		description
	"Defines how addresses are allocated.		"Defines how addresses are allocated.
	If there is no value for the address		If there is no value for the address
	allocation type, then IPv6 is		allocation type, then IPv6 is
	not enabled.";		not enabled.";
	}		}
	container provider-dhcp {		container provider-dhcp {
	when "derived-from-or-self(../address-allocation-type, "		when "derived-from-or-self(../address-allocation-type, "
	+ "'l3vpn-ntw:provider-dhcp') "		+ "'l3vpn-svc:provider-dhcp') "
	+ "or derived-from-or-self(../address-allocation-type, "		+ "or derived-from-or-self(../address-allocation-type, "
	+ "'l3vpn-ntw:provider-dhcp-slaac')" {		+ "'l3vpn-svc:provider-dhcp-slaac')" {
	description		description
	"Only applies when addresses are allocated by DHCP.";		"Only applies when addresses are allocated by DHCP.";
	}		}
	leaf provider-address {		leaf provider-address {
	type inet:ipv6-address;		type inet:ipv6-address;
	description		description
	"Address of the provider side. If provider-address		"Address of the provider side. If provider-address
	is not specified, then prefix length should not be		is not specified, then prefix length should not be
	specified either. It also implies provider-dhcp		specified either. It also implies provider-dhcp
	allocation is not enabled. If provider-address is		allocation is not enabled. If provider-address is
	skipping to change at page 85, line 4 ¶		skipping to change at page 86, line 27 ¶
	description		description
	"Container for customer addresses allocated		"Container for customer addresses allocated
	by DHCP.";		by DHCP.";
	}		}
	}		}
	description		description
	"Choice for the way to assign addresses.";		"Choice for the way to assign addresses.";
	}		}
	description		description
	"DHCP allocated addresses related parameters.";		"DHCP allocated addresses related parameters.";
	}		}
	container dhcp-relay {		container dhcp-relay {
	when "derived-from-or-self(../address-allocation-type, "		when "derived-from-or-self(../address-allocation-type, "
	+ "'l3vpn-ntw:provider-dhcp-relay')" {		+ "'l3vpn-svc:provider-dhcp-relay')" {
	description		description
	"Only applies when the provider is required		"Only applies when the provider is required
	to implement DHCP relay function.";		to implement DHCP relay function.";
	}		}
	leaf provider-address {		leaf provider-address {
	type inet:ipv6-address;		type inet:ipv6-address;
	description		description
	"Address of the provider side. If provider-address		"Address of the provider side. If provider-address
	is not specified, then prefix length should not be		is not specified, then prefix length should not be
	specified either. It also implies provider-dhcp		specified either. It also implies provider-dhcp
	skipping to change at page 86, line 4 ¶		skipping to change at page 87, line 27 ¶
	type inet:ipv6-address;		type inet:ipv6-address;
	description		description
	"This node contains the IP address of		"This node contains the IP address of
	the customer DHCP server. If the DHCP relay		the customer DHCP server. If the DHCP relay
	function is implemented by the		function is implemented by the
	provider, this node contains the		provider, this node contains the
	configured value.";		configured value.";
	}		}
	description		description
	"Container for list of customer DHCP servers.";		"Container for list of customer DHCP servers.";
	}		}
	description		description
	"DHCP relay provided by operator.";		"DHCP relay provided by operator.";
	}		}
	container static-addresses {		container static-addresses {
	when "derived-from-or-self(../address-allocation-type, "		when "derived-from-or-self(../address-allocation-type, "
	+ "'l3vpn-ntw:static-address')" {		+ "'l3vpn-svc:static-address')" {
	description		description
	"Only applies when protocol allocation type is static.";		"Only applies when protocol allocation type is static.";
	}		}
	leaf primary-address {		leaf primary-address {
	type leafref {		type leafref {
	path "/l3vpn-ntw/vpn-services/vpn-service/vpn-nodes/"		path "/l3vpn-ntw/vpn-services/vpn-service/vpn-nodes/"
	+ "vpn-node/vpn-network-accesses/vpn-network-access/"		+ "vpn-node/vpn-network-accesses/vpn-network-access/"
	+ "ip-connection/ipv6/static-addresses/address/"		+ "ip-connection/ipv6/static-addresses/address/"
	+ "address-id";		+ "address-id";
	}		}
	skipping to change at page 87, line 29 ¶		skipping to change at page 89, line 4 ¶
	description		description
	"If true, BFD activation is required.";		"If true, BFD activation is required.";
	}		}
	choice holdtime {		choice holdtime {
	default "fixed";		default "fixed";
	case fixed {		case fixed {
	leaf fixed-value {		leaf fixed-value {
	type uint32;		type uint32;
	units "msec";		units "msec";
	description		description
	"Expected BFD holdtime expressed in msec. The customer		"Expected BFD holdtime expressed in msec. The customer
	may impose some fixed values for the holdtime period		may impose some fixed values for the holdtime period
	if the provider allows the customer use this function.		if the provider allows the customer use this function.
	If the provider doesn't allow the customer to use this		If the provider doesn't allow the customer to use this
	function, the fixed-value will not be set.";		function, the fixed-value will not be set.";
	}		}
	}		}
	case profile {		case profile {
	leaf profile-name {		leaf profile-name {
	type leafref {		type leafref {
	path "/l3vpn-ntw/vpn-profiles/valid-provider-identifiers/"		path "/l3vpn-ntw/vpn-profiles/"
			+ "valid-provider-identifiers/"
	+ "bfd-profile-identifier/id";		+ "bfd-profile-identifier/id";
	}		}
	description		description
	"Well-known SP profile name. The provider can propose		"Well-known SP profile name. The provider can propose
	some profiles to the customer, depending on the service		some profiles to the customer, depending on the
	level the customer wants to achieve. Profile names		service level the customer wants to achieve.
	must be communicated to the customer.";		Profile names must be communicated to the customer.";
	}		}
	description		description
	"Well-known SP profile.";		"Well-known SP profile.";
	}		}
	description		description
	"Choice for holdtime flavor.";		"Choice for holdtime flavor.";
	}		}
	description		description
	"Container for BFD.";		"Container for BFD.";
	}		}
	skipping to change at page 91, line 24 ¶		skipping to change at page 92, line 47 ¶
	type l3vpn-svc:svc-id;		type l3vpn-svc:svc-id;
	description		description
	"Identifies the target VPN the local VPN want to access.";		"Identifies the target VPN the local VPN want to access.";
	}		}
	leaf local-sites-role {		leaf local-sites-role {
	type identityref {		type identityref {
	base l3vpn-svc:site-role;		base l3vpn-svc:site-role;
	}		}
	default "l3vpn-svc:any-to-any-role";		default "l3vpn-svc:any-to-any-role";
	description		description
	"This describes the role of the		"This describes the role of the
	local sites in the target VPN topology. In the any-to-any VPN		local sites in the target VPN topology.
	service topology, the local sites must have the same role, which		In the any-to-any VPN service topology,
	will be 'any-to-any-role'. In the Hub-and-Spoke VPN service		the local sites must have the same role, which
	topology or the Hub-and-Spoke disjoint VPN service topology,		will be 'any-to-any-role'. In the Hub-and-Spoke
	the local sites must have a Hub role or a Spoke role.";		VPN service topology or the Hub-and-Spoke
			disjoint VPN service topology,
			the local sites must have a Hub role or a Spoke role.";
	}		}
	description		description
	"List of extranet VPNs or target VPNs the local VPN is		"List of extranet VPNs or target VPNs the local VPN is
	attached to.";		attached to.";
	}		}
	description		description
	"Container for extranet VPN configuration.";		"Container for extranet VPN configuration.";
	}		}
	description		description
	"Grouping for extranet VPN configuration.		"Grouping for extranet VPN configuration.
	skipping to change at page 92, line 51 ¶		skipping to change at page 94, line 29 ¶
	"List for BFD Profile identifiers.";		"List for BFD Profile identifiers.";
	}		}
	list routing-profile-identifier {		list routing-profile-identifier {
	key "id";		key "id";
	leaf id {		leaf id {
	type string;		type string;
	description		description
	"Identification of the routing Profile to be used		"Identification of the routing Profile to be used
	by the routing-protocols within sites, vpn-		by the routing-protocols within sites, vpn-
	network-accesses or vpn-nodes for refering		network-accesses or vpn-nodes for refering
	vrf-import/export policies.		vrf-import/export policies.
	This identifier has a local meaning.";		This identifier has a local meaning.";
	}		}
	description		description
	"List for Routing Profile Identifiers.";		"List for Routing Profile Identifiers.";
	}		}
	nacm:default-deny-write;		nacm:default-deny-write;
	description		description
	"Container for Valid Provider Identifies.";		"Container for Valid Provider Identifies.";
	}		}
	description		description
	"Grouping for VPN Profile configuration.";		"Grouping for VPN Profile configuration.";
	}		}
	grouping vpn-svc-cfg {		grouping vpn-svc-cfg {
	leaf vpn-id {		leaf vpn-id {
	type l3vpn-svc:svc-id;		type l3vpn-svc:svc-id;
	description		description
	"VPN identifier.		"VPN identifier.
	This identifier has a local meaning.";		This identifier has a local meaning.";
	}		}
	leaf l3sm-vpn-id {		leaf l3sm-vpn-id {
	type l3vpn-svc:svc-id;		type l3vpn-svc:svc-id;
	description		description
	"Pointer to the L3SM service.";		"Pointer to the L3SM service.";
	}		}
	leaf customer-name {		leaf customer-name {
	type string;		type string;
	description		description
	"Name of the customer that actually uses the VPN service.		"Name of the customer that actually uses the VPN service.
	In the case that any intermediary (e.g., Tier-2 provider		In the case that any intermediary (e.g., Tier-2 provider
	or partner) sells the VPN service to their end user		or partner) sells the VPN service to their end user
	on behalf of the original service provider (e.g., Tier-1		on behalf of the original service provider (e.g., Tier-1
	provider), the original service provider may require the		provider), the original service provider may require the
	customer name to provide smooth activation/commissioning		customer name to provide smooth activation/commissioning
	and operation for the service.";		and operation for the service.";
	}		}
	leaf vpn-service-topology {		leaf vpn-service-topology {
	type identityref {		type identityref {
	base vpn-topology;		base vpn-topology;
	}		}
	default "any-to-any";		default "any-to-any";
	description		description
	"VPN service topology.";		"VPN service topology.";
	}		}
	leaf description {		leaf description {
	skipping to change at page 98, line 24 ¶		skipping to change at page 99, line 49 ¶
	description		description
	"Administrative Status UP/DOWN";		"Administrative Status UP/DOWN";
	}		}
	leaf oper-status {		leaf oper-status {
	type operational-type;		type operational-type;
	config false;		config false;
	description		description
	"Operations status";		"Operations status";
	}		}
	description		description
	"";		"Container for status parameters.";
	}		}
	description		description
	"Grouping used to join operational and administrative status		"Grouping used to join operational and administrative status
	is re used in the Site Network Acess and in the VPN-Node";		is re used in the Site Network Acess and in the VPN-Node";
	}		}
	/* Parameters related to vpn-nodes (VRF config.) */		/* Parameters related to vpn-nodes (VRF config.) */
	grouping vpn-nodes-params {		grouping vpn-nodes-params {
	container vpn-nodes {		container vpn-nodes {
	description		description
	"";		"Container for VPN nodes.";
	list vpn-node {		list vpn-node {
	key "ne-id";		key "ne-id";
	leaf vpn-node-id {		leaf vpn-node-id {
	type union {		type union {
	type l3vpn-svc:svc-id;		type l3vpn-svc:svc-id;
	type uint32;		type uint32;
	}		}
	description		description
	"Type STRING or NUMBER Serivice-Id";		"Type STRING or NUMBER Serivice-Id";
	}		}
	leaf local-autonomous-system {		leaf local-autonomous-system {
	type inet:as-number;		type inet:as-number;
	description		description
	"Provider AS number in case the customer		"Provider AS number in case the customer
	requests BGP routing.";		requests BGP routing.";
	}		}
	leaf description {		leaf description {
	type string;		type string;
	description		description
	"Textual description of a VPN node.";		"Textual description of the VPN node.";
	}		}
	leaf ne-id {		leaf ne-id {
	type string;		type string;
	description		description
	"";		"Unique identifier of the network element
			where the vpn-node is deployed.";
	}		}
	leaf router-id {		leaf router-id {
	type inet:ip-address;		type inet:ip-address;
	description		description
	"router-id information can be ipv4/6 addresses";		"router-id information can be ipv4/6 addresses";
	}		}
	leaf address-family {		leaf address-family {
	type l3vpn-svc:address-family;		type l3vpn-svc:address-family;
	description		description
	"Address family used for router-id information.";		"Address family used for router-id information.";
	skipping to change at page 99, line 43 ¶		skipping to change at page 101, line 21 ¶
	uses status-params;		uses status-params;
	uses net-acc;		uses net-acc;
	uses site-maximum-routes;		uses site-maximum-routes;
	uses vpn-service-multicast;		uses vpn-service-multicast;
	leaf node-ie-profile {		leaf node-ie-profile {
	type leafref {		type leafref {
	path "/l3vpn-ntw/vpn-services/"		path "/l3vpn-ntw/vpn-services/"
	+ "vpn-service/ie-profiles/ie-profile/ie-profile-id";		+ "vpn-service/ie-profiles/ie-profile/ie-profile-id";
	}		}
	description		description
	"";		"node Import/Export profile.";
	}		}
	description		description
	"";		"List for VPN node.";
	}		}
	}		}
	description		description
	"Grouping to define VRF-specific configuration.";		"Grouping to define VRF-specific configuration.";
	}		}
	/* Parameters related to import and export profiles (RTs RDs.) */		/* Parameters related to import and export profiles (RTs RDs.) */
	grouping ie-profiles-params {		grouping ie-profiles-params {
	container ie-profiles {		container ie-profiles {
	list ie-profile {		list ie-profile {
	key "ie-profile-id";		key "ie-profile-id";
	leaf ie-profile-id {		leaf ie-profile-id {
	type string;		type string;
	description		description
	"";		"IE profile id.";
	}		}
	uses rt-rd;		uses rt-rd;
	description		description
	"";		"List for Imort/Export profile.";
	}		}
	description		description
	"";		"Container for Import/Export profiles.";
	}		}
	description		description
	"Grouping to specify rules for route import and export";		"Grouping to specify rules for route import and export";
	}		}
	grouping pseudowire-params {		grouping pseudowire-params {
	container pseudowire {		container pseudowire {
	/*leaf far-end {*/		/*leaf far-end {*/
	/* description "IP of the remote peer of the pseudowire.";*/		/* description "IP of the remote peer of the pseudowire.";*/
	/* type inet:ip-address;*/		/* type inet:ip-address;*/
	/*}*/		/*}*/
	leaf vcid {		leaf vcid {
	type uint32;		type uint32;
	description		description
	"PW or VC identifier.";		"PW or VC identifier.";
	skipping to change at page 102, line 4 ¶		skipping to change at page 103, line 30 ¶
	grouping ethernet-params {		grouping ethernet-params {
	container connection {		container connection {
	leaf encapsulation-type {		leaf encapsulation-type {
	type identityref {		type identityref {
	base encapsulation-type;		base encapsulation-type;
	}		}
	default "untagged-int";		default "untagged-int";
	description		description
	"Encapsulation type. By default, the		"Encapsulation type. By default, the
	encapsulation type is set to 'untagged'.";		encapsulation type is set to 'untagged'.";
	}		}
	container logical-interface {		container logical-interface {
	leaf peer-reference {		leaf peer-reference {
	type uint32;		type uint32;
	description		description
	"Specify the associated logical peer interface.";		"Specify the associated logical peer
			interface";
	}		}
	description		description
	"Reference of a logical interface type.";		"Reference of a logical interface type.";
	}		}
	container tagged-interface {		container tagged-interface {
	leaf type {		leaf type {
	type identityref {		type identityref {
	base tagged-inf-type;		base tagged-inf-type;
	}		}
	default "priority-tagged";		default "priority-tagged";
	skipping to change at page 105, line 42 ¶		skipping to change at page 107, line 21 ¶
	}		}
	description		description
	"Encapsulation types";		"Encapsulation types";
	}		}
	description		description
	"Grouping to define encapsulation types";		"Grouping to define encapsulation types";
	}		}
	grouping rt-rd {		grouping rt-rd {
	leaf rd {		leaf rd {
			type union {
	type rt-types:route-distinguisher;		type rt-types:route-distinguisher;
			type empty;
			}
	description		description
	"";		"Route distinguisher value. If this leaf has not been
			configured, the server will auto-assign a route
			distinguisher value and use that value operationally.
			This calculated value is available in the operational
			state. Use the empty type to indicate rd has no value
			and is not to be aouto-assigned";
	}		}
	container vpn-targets {		container vpn-targets {
	description		description
	"Set of route-targets to match for import and export routes		"Set of route-targets to match for import and export routes
	to/from VRF";		to/from VRF";
	//uses rt-types:vpn-route-targets;		//uses rt-types:vpn-route-targets;
	uses vpn-route-targets;		uses vpn-route-targets;
	}		}
	description		description
	"";		"Grouping for RT and RD.";
	}		}
	grouping vpn-route-targets {		grouping vpn-route-targets {
	description		description
	"A grouping that specifies Route Target import-export rules		"A grouping that specifies Route Target import-export rules
	used in a BGP-enabled VPN.";		used in a BGP-enabled VPN.";
	list vpn-target {		list vpn-target {
	key "id";		key "id";
	leaf id {		leaf id {
	type int8;		type int8;
	skipping to change at page 108, line 18 ¶		skipping to change at page 110, line 4 ¶
	container vpn-services {		container vpn-services {
	list vpn-service {		list vpn-service {
	key "vpn-id";		key "vpn-id";
	uses service-status;		uses service-status;
	uses vpn-svc-cfg;		uses vpn-svc-cfg;
	description		description
	"List of VPN services.";		"List of VPN services.";
	}		}
	description		description
	"Top-level container for the VPN services.";		"Top-level container for the VPN services.";
	}		}
	description		description
	"Main container for L3VPN service configuration.";		"Main container for L3VPN services management.";
	}		}
	}		}
	<CODE ENDS>		<CODE ENDS>
	Figure 24		Figure 26
	11. IANA Considerations		11. IANA Considerations
	This document requests IANA to register the following URI in the "ns"		This document requests IANA to register the following URI in the "ns"
	subregistry within the "IETF XML Registry" [RFC3688]:		subregistry within the "IETF XML Registry" [RFC3688]:
	URI: urn:ietf:params:xml:ns:yang:ietf-l3vpn-ntw		URI: urn:ietf:params:xml:ns:yang:ietf-l3vpn-ntw
	Registrant Contact: The IESG.		Registrant Contact: The IESG.
	skipping to change at page 112, line 31 ¶		skipping to change at page 114, line 17 ¶
	[I-D.evenwu-opsawg-yang-composed-vpn]		[I-D.evenwu-opsawg-yang-composed-vpn]
	Even, R., Bo, W., Wu, Q., and Y. Cheng, "YANG Data Model		Even, R., Bo, W., Wu, Q., and Y. Cheng, "YANG Data Model
	for Composed VPN Service Delivery", draft-evenwu-opsawg-		for Composed VPN Service Delivery", draft-evenwu-opsawg-
	yang-composed-vpn-03 (work in progress), March 2019.		yang-composed-vpn-03 (work in progress), March 2019.
	[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-08 (work in progress), February 2020.
			[I-D.ietf-pim-yang]
			Liu, X., McAllister, P., Peter, A., Sivakumar, M., Liu,
			Y., and f. hu, "A YANG Data Model for Protocol Independent
			Multicast (PIM)", draft-ietf-pim-yang-17 (work in
			progress), May 2018.
	[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-00 (work in progress), October 2019.		model-00 (work in progress), October 2019.
	[I-D.liu-pim-yang]
	Liu, Y., Guo, F., and M. Sivakumar, "YANG Data Model for
	PIM", draft-liu-pim-yang-01 (work in progress), March
	2015.
	[RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual		[RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual
	Private Network (VPN) Terminology", RFC 4026,		Private Network (VPN) Terminology", RFC 4026,
	DOI 10.17487/RFC4026, March 2005,		DOI 10.17487/RFC4026, March 2005,
	<https://www.rfc-editor.org/info/rfc4026>.		<https://www.rfc-editor.org/info/rfc4026>.
	[RFC4176] El Mghazli, Y., Ed., Nadeau, T., Boucadair, M., Chan, K.,		[RFC4176] El Mghazli, Y., Ed., Nadeau, T., Boucadair, M., Chan, K.,
	and A. Gonguet, "Framework for Layer 3 Virtual Private		and A. Gonguet, "Framework for Layer 3 Virtual Private
	Networks (L3VPN) Operations and Management", RFC 4176,		Networks (L3VPN) Operations and Management", RFC 4176,
	DOI 10.17487/RFC4176, October 2005,		DOI 10.17487/RFC4176, October 2005,
	<https://www.rfc-editor.org/info/rfc4176>.		<https://www.rfc-editor.org/info/rfc4176>.
	skipping to change at page 117, line 15 ¶		skipping to change at page 119, line 4 ¶
	| | +--rw auth-key? string		| | +--rw auth-key? string
	| +--rw static		| +--rw static
	| | +--rw cascaded-lan-prefixes		| | +--rw cascaded-lan-prefixes
	| | +--rw ipv4-lan-prefixes* {ipv4}?		| | +--rw ipv4-lan-prefixes* {ipv4}?
	| | | +--rw lan inet:ipv4-prefix		| | | +--rw lan inet:ipv4-prefix
	| | | +--rw lan-tag? string		| | | +--rw lan-tag? string
	| | | +--rw next-hop inet:ipv4-address		| | | +--rw next-hop inet:ipv4-address
	+--rw node-id? leafreaf		+--rw node-id? leafreaf
	+--rw service-id? leafreaf		+--rw service-id? leafreaf
	+--rw access-group-id? yang:uuid		+--rw access-group-id? yang:uuid
			Figure 27
	Figure 25
	Use Cases we have implemented include:		Use Cases we have implemented include:
	(a).Create VPN		(a).Create VPN
	(b).Create Site		(b).Create Site
	(c).Create/add bearers to an existing Site		(c).Create/add bearers to an existing Site
	(d).Create/Include Site Network Access into VPN nodes.		(d).Create/Include Site Network Access into VPN nodes.
	skipping to change at page 118, line 33 ¶		skipping to change at page 120, line 20 ¶
	of the model are supported.		of the model are supported.
	The current implementation is proprietary, so under no terms the		The current implementation is proprietary, so under no terms the
	current implementation can be used.		current implementation can be used.
	Contact information: Janne Karvonen (JKarvonen@infinera.com)		Contact information: Janne Karvonen (JKarvonen@infinera.com)
	26 October is the date when information about this particular		26 October is the date when information about this particular
	implementation was last updated.		implementation was last updated.
			A.4. Ribbon-ECI Implementation
			Ribbon-ECI Controller (Muse) has multilayer provisioning abilities
			from the optical layer up to the IP layer. With respect to ATCN
			hierarchy model, Ribbon-ECI controller can be placed in at the level
			of MDSC and serve as a service orchestrator or at the level of PNC as
			a SDN controller. Additional information can be found at
			https://www.ecitele.com/muse-network-service-apps/ The L3VPN
			Fulfillment component, which is currently in beta maturity level, is
			designed to support L3SM (RFC8299) for L3VPN service creation and
			activation, is implemented with a data model similar to the L3NM and
			translates it to the device model (ietf-routing-instance and ietf-
			interfaces).
			In addition, the L3VPN Fulfillment component interface include REST
			API with the following methods:
			o Create service
			o Edit service
			o Get service details
			o Delete service
			o Notification (registration based)
			L3NM model coverage (several augmentations and deviations applied):
			o vpn-service
			o vpn-id
			o uuid
			o vpn-service-topology
			o customer-name
			o description
			o slice-id
			o service-status
			o vpn-nodes
			o ne-id
			o vpn-node-id
			o uuid
			o autonomous-system
			o rd
			o vpn-targets
			o vpn-network-accesses
			o tunnel-policy
			o export-policy
			o routing protocol
			o bgp
			o static
			o vpn-network-access
			o vpn-network-access-id
			o uuid
			o statu
			o connection
			o tagged-interface
			o cvlan-id
			o ip-connection
			o dhcp-relay
			o static-addresses
			o service
			o qos-profile
			o bw-profile
	Authors' Addresses		Authors' Addresses
	Samier Barguil		Samier Barguil
	Telefonica		Telefonica
	Madrid		Madrid
	ES		ES
	Email: samier.barguilgiraldo.ext@telefonica.com		Email: samier.barguilgiraldo.ext@telefonica.com
	Oscar Gonzalez de Dios (editor)		Oscar Gonzalez de Dios (editor)
	skipping to change at page 119, line 4 ¶		skipping to change at page 122, line 35 ¶
	ES		ES
	Email: samier.barguilgiraldo.ext@telefonica.com		Email: samier.barguilgiraldo.ext@telefonica.com
	Oscar Gonzalez de Dios (editor)		Oscar Gonzalez de Dios (editor)
	Telefonica		Telefonica
	Madrid		Madrid
	ES		ES
	Email: oscar.gonzalezdedios@telefonica.com		Email: oscar.gonzalezdedios@telefonica.com
	Mohamed Boucadair		Mohamed Boucadair
	Orange		Orange
	FR		France
	Email: "mohamed.boucadair@orange.com		Email: "mohamed.boucadair@orange.com
	Luis Angel Munoz		Luis Angel Munoz
	Vodafone		Vodafone
	ES		ES
	Email: luis-angel.munoz@vodafone.com		Email: luis-angel.munoz@vodafone.com
	Alejandro Aguado		Alejandro Aguado
	Nokia		Nokia
	Madrid		Madrid
	ES		ES
	Email: alejandro.aguado_martin@nokia.com		Email: alejandro.aguado_martin@nokia.com
End of changes. 124 change blocks.
	359 lines changed or deleted		469 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/