draft-ietf-opsawg-teas-common-ac-05.txt		draft-ietf-opsawg-teas-common-ac-06.txt
	OPSAWG M. Boucadair, Ed.		OPSAWG M. Boucadair, Ed.
	Internet-Draft Orange		Internet-Draft Orange
	Intended status: Standards Track R. Roberts, Ed.		Intended status: Standards Track R. Roberts, Ed.
	Expires: 12 August 2024 Juniper		Expires: 22 September 2024 Juniper
	O. G. D. Dios		O. G. D. Dios
	Telefonica		Telefonica
	S. B. Giraldo		S. B. Giraldo
	Nokia		Nokia
	B. Wu		B. Wu
	Huawei Technologies		Huawei Technologies
	9 February 2024		21 March 2024
	A Common YANG Data Model for Attachment Circuits		A Common YANG Data Model for Attachment Circuits
	draft-ietf-opsawg-teas-common-ac-05		draft-ietf-opsawg-teas-common-ac-06
	Abstract		Abstract
	The document specifies a common Attachment Circuits (ACs) YANG		The document specifies a common Attachment Circuits (ACs) YANG
	module, which is designed with the intent to be reusable by other		module, which is designed with the intent to be reusable by other
	models. For example, this common model can be reused by service		models. For example, this common model can be reused by service
	models to expose ACs as a service, service models that require		models to expose ACs as a service, service models that require
	binding a service to a set of ACs, network and device models to		binding a service to a set of ACs, network and device models to
	provision ACs, etc.		provision ACs, etc.
	skipping to change at page 2, line 10 ¶		skipping to change at page 2, line 10 ¶
	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 12 August 2024.		This Internet-Draft will expire on 22 September 2024.
	Copyright Notice		Copyright Notice
	Copyright (c) 2024 IETF Trust and the persons identified as the		Copyright (c) 2024 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 (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	skipping to change at page 2, line 46 ¶		skipping to change at page 2, line 46 ¶
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 47		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 47
	7.1. Normative References . . . . . . . . . . . . . . . . . . 47		7.1. Normative References . . . . . . . . . . . . . . . . . . 47
	7.2. Informative References . . . . . . . . . . . . . . . . . 50		7.2. Informative References . . . . . . . . . . . . . . . . . 50
	Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 52		Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 52
	Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 52		Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 52
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 53		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 53
	1. Introduction		1. Introduction
	Connectivity services are provided by networks to customers via		Connectivity services are provided by networks to customers via
	dedicated terminating points (e.g., service functions, Customer		dedicated terminating points (e.g., Service Functions (SFs), Customer
	Premises Equipment (CPEs), Autonomous System Border Routers (ASBRs),		Premises Equipment (CPEs), Autonomous System Border Routers (ASBRs),
	data centers gateways, Internet Exchange Points). A connectivity		data centers gateways, or Internet Exchange Points). A connectivity
	service is basically about ensuring data transfer received from (or		service is basically about ensuring data transfer received from (or
	destined to) a given terminating point to (or from) other terminating		destined to) a given terminating point to (or from) other terminating
	points that belong to the same customer/service, an interconnection		points that belong to the same customer/service, an interconnection
	node, or an ancillary node. A set of objectives for the connectivity		node, or an ancillary node. A set of objectives for the connectivity
	service may eventually be negotiated and agreed upon between a		service may eventually be negotiated and agreed upon between a
	customer a network provider. For that data transfer to take place		customer a network provider. For that data transfer to take place
	within the provider network, it is assumed that adequate setup is		within the provider network, it is assumed that adequate setup is
	provisioned over the links that connect customer terminating points		provisioned over the links that connect customer terminating points
	and a provider network so that data can be successfully exchanged		and a provider network (a Provider Edge (PE), typically) so that data
	over these links. The required setup is referred to in this document		can be successfully exchanged over these links. The required setup
	as Attachment Circuits (ACs), while the underlying link is referred		is referred to in this document as Attachment Circuits (ACs), while
	to as "bearer".		the underlying link is referred to as "bearer".
	This document adheres to the definition of an attachment circuit as		This document adheres to the definition of an attachment circuit as
	provided in Section 1.2 of [RFC4364], especially:		provided in Section 1.2 of [RFC4364], especially:
	Routers can be attached to each other, or to end systems, in a		Routers can be attached to each other, or to end systems, in a
	variety of different ways: PPP connections, ATM Virtual Circuits		variety of different ways: PPP connections, ATM Virtual Circuits
	(VCs), Frame Relay VCs, ethernet interfaces, Virtual Local Area		(VCs), Frame Relay VCs, ethernet interfaces, Virtual Local Area
	Networks (VLANs) on ethernet interfaces, GRE tunnels, Layer 2		Networks (VLANs) on ethernet interfaces, GRE tunnels, Layer 2
	Tunneling Protocol (L2TP) tunnels, IPsec tunnels, etc. We will		Tunneling Protocol (L2TP) tunnels, IPsec tunnels, etc. We will
	use the term "attachment circuit" to refer generally to some such		use the term "attachment circuit" to refer generally to some such
	skipping to change at page 3, line 38 ¶		skipping to change at page 3, line 38 ¶
	When a customer requests a new value-added service, the service can		When a customer requests a new value-added service, the service can
	be bound to existing attachment circuits or trigger the instantiation		be bound to existing attachment circuits or trigger the instantiation
	of new attachment circuits. Whether these attachment circuits are		of new attachment circuits. Whether these attachment circuits are
	specific to a given service or be shared to deliver a variety of		specific to a given service or be shared to deliver a variety of
	services is deployment-specific.		services is deployment-specific.
	An example of attachment circuits is depicted in Figure 1. A		An example of attachment circuits is depicted in Figure 1. A
	Customer Edge (CE) may be a physical node or a logical entity. A CE		Customer Edge (CE) may be a physical node or a logical entity. A CE
	is seen by the network as a peer Service Attachment Point (SAP)		is seen by the network as a peer Service Attachment Point (SAP)
	[RFC9408]. CEs may be dedicated to one single service (e.g., Layer 3		[RFC9408]. CEs may be dedicated to one single service (e.g., Layer 3
	Virtual Private Network (VPN), Layer 2 VPN) or host multiple services		Virtual Private Network (VPN) or Layer 2 VPN) or host multiple
	(e.g., Service Functions [RFC7665]). A single AC (as seen by a		services (e.g., Service Functions [RFC7665]). A single AC (as seen
	network provider) may be bound to one or multiple peer SAPs (e.g.,		by a network provider) may be bound to one or multiple peer SAPs
	CE#1 and CE#2). For example, and as discussed in [RFC4364], multiple		(e.g., "CE#1" and "CE#2"). For example, and as discussed in
	CEs can be attached to a PE over the same attachment circuit. This		[RFC4364], multiple CEs can be attached to a PE over the same
	is typically implemented if the Layer 2 infrastructure between the CE		attachment circuit. This is typically implemented if the Layer 2
	and the network provides a multipoint service. The same CE may		infrastructure between the CE and the network provides a multipoint
	terminate multiple ACs. These ACs may be over the same or distinct		service. The same CE may terminate multiple ACs. These ACs may be
	bearers.		over the same or distinct bearers.
	.-------. .--------------------. .-------.		.-------. .--------------------. .-------.
	│ +------. | +---AC----+ |		| +------. | +---AC----+ |
	│ CE#1 │ | | +---AC----+ CE#3 |		| CE#1 | | | +---AC----+ CE#3 |
	'-------' | | | '-------'		'-------' | | | '-------'
	+---AC----+ Network |		+---AC----+ Network |
	.-------. | | |		.-------. | | |
	| | | | | .-------.		| | | | | .-------.
	| CE#2 +------' | +---AC----+ CE#4 |		| CE#2 +------' | +---AC----+ CE#4 |
	'-------' | | '----+--'		'-------' | | '----+--'
	'-----------+--------' |		'-----------+--------' |
	| |		| |
	'-----------AC----------'		'-----------AC----------'
	skipping to change at page 5, line 38 ¶		skipping to change at page 5, line 38 ¶
	with the customer of a network service.		with the customer of a network service.
	A service orchestrator is typically responsible for the attachment		A service orchestrator is typically responsible for the attachment
	circuits, the Provider Edge (PE) selection, and requesting the		circuits, the Provider Edge (PE) selection, and requesting the
	activation of the requested services to a network controller.		activation of the requested services to a network controller.
	A service orchestrator may interact with one or more network		A service orchestrator may interact with one or more network
	controllers.		controllers.
	Service provider network: A network that is able to provide network		Service provider network: A network that is able to provide network
	services (e.g., L2VPN, L3VPN, or Network Slice Services).		services (e.g., L2VPN, L3VPN, or Network Slice Services
			[RFC9543]).
	Service provider: A service provider that offers network services		Service provider: A service provider that offers network services
	(e.g., L2VPN, L3VPN, or Network Slice Services).		(e.g., L2VPN, L3VPN, or Network Slice Services).
	3. Description of the AC Common YANG Module		3. Description of the AC Common YANG Module
	The full tree diagram of the module can be generated using the		The full tree diagram of the module can be generated using the
	"pyang" tool [PYANG] with "-f tree --tree-print-groupings" command-		"pyang" tool [PYANG] with "-f tree --tree-print-groupings" command-
	line parameters. That tree is not included here because it is too		line parameters. That tree is not included here because it is too
	long (Section 3.3 of [RFC8340]). Instead, subtrees are provided for		long (Section 3.3 of [RFC8340]). Instead, subtrees are provided for
	skipping to change at page 7, line 25 ¶		skipping to change at page 7, line 25 ¶
	+-- requested-stop? yang:date-and-time		+-- requested-stop? yang:date-and-time
	+--ro actual-start? yang:date-and-time		+--ro actual-start? yang:date-and-time
	+--ro actual-stop? yang:date-and-time		+--ro actual-stop? yang:date-and-time
	Figure 2: Operational Instructions Grouping		Figure 2: Operational Instructions Grouping
	Layer 2 encapsulations (Figure 3): Groupings for the following		Layer 2 encapsulations (Figure 3): Groupings for the following
	encapsulation schemes are supported: dot1Q, QinQ, and priority-		encapsulation schemes are supported: dot1Q, QinQ, and priority-
	tagged.		tagged.
	Layer 2 tunnel services (Figure 3): These grouping are used to		Layer 2 tunnel services (Figure 3): These groupings are used to
	define Layer 2 tunnel services that may be needed for the		define Layer 2 tunnel services that may be needed for the
	activation of an AC. Examples of supported Layer 2 servers are		activation of an AC. Examples of supported Layer 2 services are
	the pseudowire (Section 6.1 of [RFC8077]), VPLS, or VXLAN		the pseudowire (Section 6.1 of [RFC8077]), VPLS, or VXLAN
	[RFC7348].		[RFC7348].
	grouping dot1q:		grouping dot1q:
	+-- tag-type? identityref		+-- tag-type? identityref
	+-- cvlan-id? uint16		+-- cvlan-id? uint16
	grouping priority-tagged:		grouping priority-tagged:
	+-- tag-type? identityref		+-- tag-type? identityref
	grouping qinq:		grouping qinq:
	+-- tag-type? identityref		+-- tag-type? identityref
	skipping to change at page 46, line 37 ¶		skipping to change at page 46, line 37 ¶
	uses bandwidth-parameters;		uses bandwidth-parameters;
	}		}
	}		}
	}		}
	}		}
	}		}
	<CODE ENDS>		<CODE ENDS>
	5. Security Considerations		5. Security Considerations
			This section uses the template described in Section 3.7 of
			[I-D.ietf-netmod-rfc8407bis].
	The YANG module specified in this document defines schema for data		The YANG module specified in this document defines schema for data
	that is designed to be accessed via network management protocols such		that is designed to be accessed via network management protocols such
	as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer		as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer
	is the secure transport layer, and the mandatory-to-implement secure		is the secure transport layer, and the mandatory-to-implement secure
	transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer		transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer
	is HTTPS, and the mandatory-to-implement secure transport is TLS		is HTTPS, and the mandatory-to-implement secure transport is TLS
	[RFC8446].		[RFC8446].
	The Network Configuration Access Control Model (NACM) [RFC8341]		The Network Configuration Access Control Model (NACM) [RFC8341]
	provides the means to restrict access for particular NETCONF or		provides the means to restrict access for particular NETCONF or
	skipping to change at page 50, line 37 ¶		skipping to change at page 50, line 37 ¶
	2022, <https://www.rfc-editor.org/rfc/rfc9181>.		2022, <https://www.rfc-editor.org/rfc/rfc9181>.
	7.2. Informative References		7.2. Informative References
	[AC-Common-Tree]		[AC-Common-Tree]
	"Full Common Attachment Circuit Tree Structure", 2023,		"Full Common Attachment Circuit Tree Structure", 2023,
	<https://github.com/boucadair/attachment-circuit-		<https://github.com/boucadair/attachment-circuit-
	model/blob/main/yang/full-trees/ac-common-with-		model/blob/main/yang/full-trees/ac-common-with-
	groupings.txt>.		groupings.txt>.
			[I-D.ietf-netmod-rfc8407bis]
			Bierman, A., Boucadair, M., and Q. Wu, "Guidelines for
			Authors and Reviewers of Documents Containing YANG Data
			Models", Work in Progress, Internet-Draft, draft-ietf-
			netmod-rfc8407bis-09, 28 February 2024,
			<https://datatracker.ietf.org/doc/html/draft-ietf-netmod-
			rfc8407bis-09>.
	[I-D.ietf-opsawg-ntw-attachment-circuit]		[I-D.ietf-opsawg-ntw-attachment-circuit]
	Boucadair, M., Roberts, R., de Dios, O. G., Barguil, S.,		Boucadair, M., Roberts, R., de Dios, O. G., Barguil, S.,
	and B. Wu, "A Network YANG Data Model for Attachment		and B. Wu, "A Network YANG Data Model for Attachment
	Circuits", Work in Progress, Internet-Draft, draft-ietf-		Circuits", Work in Progress, Internet-Draft, draft-ietf-
	opsawg-ntw-attachment-circuit-04, 14 December 2023,		opsawg-ntw-attachment-circuit-05, 9 February 2024,
	<https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-		<https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-
	ntw-attachment-circuit-04>.		ntw-attachment-circuit-05>.
	[I-D.ietf-opsawg-teas-attachment-circuit]		[I-D.ietf-opsawg-teas-attachment-circuit]
	Boucadair, M., Roberts, R., de Dios, O. G., Barguil, S.,		Boucadair, M., Roberts, R., de Dios, O. G., Barguil, S.,
	and B. Wu, "YANG Data Models for Bearers and 'Attachment		and B. Wu, "YANG Data Models for Bearers and 'Attachment
	Circuits'-as-a-Service (ACaaS)", Work in Progress,		Circuits'-as-a-Service (ACaaS)", Work in Progress,
	Internet-Draft, draft-ietf-opsawg-teas-attachment-circuit-		Internet-Draft, draft-ietf-opsawg-teas-attachment-circuit-
	05, 22 January 2024,		08, 16 March 2024, <https://datatracker.ietf.org/doc/html/
	<https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-		draft-ietf-opsawg-teas-attachment-circuit-08>.
	teas-attachment-circuit-05>.
	[I-D.ietf-teas-ietf-network-slice-nbi-yang]		[I-D.ietf-teas-ietf-network-slice-nbi-yang]
	Wu, B., Dhody, D., Rokui, R., Saad, T., and J. Mullooly,		Wu, B., Dhody, D., Rokui, R., Saad, T., and J. Mullooly,
	"A YANG Data Model for the IETF Network Slice Service",		"A YANG Data Model for the RFC 9543 Network Slice
	Work in Progress, Internet-Draft, draft-ietf-teas-ietf-		Service", Work in Progress, Internet-Draft, draft-ietf-
	network-slice-nbi-yang-08, 23 October 2023,		teas-ietf-network-slice-nbi-yang-10, 16 March 2024,
	<https://datatracker.ietf.org/doc/html/draft-ietf-teas-		<https://datatracker.ietf.org/doc/html/draft-ietf-teas-
	ietf-network-slice-nbi-yang-08>.		ietf-network-slice-nbi-yang-10>.
	[PYANG] "pyang", 2023, <https://github.com/mbj4668/pyang>.		[PYANG] "pyang", 2023, <https://github.com/mbj4668/pyang>.
	[RFC2918] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918,		[RFC2918] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918,
	DOI 10.17487/RFC2918, September 2000,		DOI 10.17487/RFC2918, September 2000,
	<https://www.rfc-editor.org/rfc/rfc2918>.		<https://www.rfc-editor.org/rfc/rfc2918>.
	[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private		[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
	Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February		Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
	2006, <https://www.rfc-editor.org/rfc/rfc4364>.		2006, <https://www.rfc-editor.org/rfc/rfc4364>.
	skipping to change at page 52, line 25 ¶		skipping to change at page 52, line 34 ¶
	[RFC9182] Barguil, S., Gonzalez de Dios, O., Ed., Boucadair, M.,		[RFC9182] Barguil, S., Gonzalez de Dios, O., Ed., Boucadair, M.,
	Ed., Munoz, L., and A. Aguado, "A YANG Network Data Model		Ed., Munoz, L., and A. Aguado, "A YANG Network Data Model
	for Layer 3 VPNs", RFC 9182, DOI 10.17487/RFC9182,		for Layer 3 VPNs", RFC 9182, DOI 10.17487/RFC9182,
	February 2022, <https://www.rfc-editor.org/rfc/rfc9182>.		February 2022, <https://www.rfc-editor.org/rfc/rfc9182>.
	[RFC9408] Boucadair, M., Ed., Gonzalez de Dios, O., Barguil, S., Wu,		[RFC9408] Boucadair, M., Ed., Gonzalez de Dios, O., Barguil, S., Wu,
	Q., and V. Lopez, "A YANG Network Data Model for Service		Q., and V. Lopez, "A YANG Network Data Model for Service
	Attachment Points (SAPs)", RFC 9408, DOI 10.17487/RFC9408,		Attachment Points (SAPs)", RFC 9408, DOI 10.17487/RFC9408,
	June 2023, <https://www.rfc-editor.org/rfc/rfc9408>.		June 2023, <https://www.rfc-editor.org/rfc/rfc9408>.
			[RFC9543] Farrel, A., Ed., Drake, J., Ed., Rokui, R., Homma, S.,
			Makhijani, K., Contreras, L., and J. Tantsura, "A
			Framework for Network Slices in Networks Built from IETF
			Technologies", RFC 9543, DOI 10.17487/RFC9543, March 2024,
			<https://www.rfc-editor.org/rfc/rfc9543>.
	Acknowledgments		Acknowledgments
	The document reuses many of the structures that were defined in		The document reuses many of the structures that were defined in
	[RFC9181] and [RFC9182].		[RFC9181] and [RFC9182].
	Thanks to Ebben Aries for the YANG Doctors review.		Thanks to Ebben Aries for the YANG Doctors review and Andy Smith for
			the rtg-dir review.
	Contributors		Contributors
	Victor Lopez		Victor Lopez
	Nokia		Nokia
	Email: victor.lopez@nokia.com		Email: victor.lopez@nokia.com
	Ivan Bykov		Ivan Bykov
	Ribbon Communications		Ribbon Communications
	Email: Ivan.Bykov@rbbn.com		Email: Ivan.Bykov@rbbn.com
	Qin Wu		Qin Wu
	Huawei		Huawei
	Email: bill.wu@huawei.com		Email: bill.wu@huawei.com
	Kenichi Ogaki		Kenichi Ogaki
	KDDI		KDDI
End of changes. 22 change blocks.
	35 lines changed or deleted		52 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/