rfc9834v1.txt		rfc9834.txt
	Internet Engineering Task Force (IETF) M. Boucadair, Ed.		Internet Engineering Task Force (IETF) M. Boucadair, Ed.
	Request for Comments: 9834 Orange		Request for Comments: 9834 Orange
	Category: Standards Track R. Roberts, Ed.		Category: Standards Track R. Roberts, Ed.
	ISSN: 2070-1721 Juniper		ISSN: 2070-1721 Juniper
	O. Gonzalez de Dios		O. Gonzalez de Dios
	Telefonica		Telefonica
	S. Barguil Giraldo		S. Barguil
	Nokia		Nokia
	B. Wu		B. Wu
	Huawei Technologies		Huawei Technologies
	August 2025		August 2025
	YANG Data Models for Bearers and 'Attachment Circuits'-as-a-Service		YANG Data Models for Bearers and 'Attachment Circuits'-as-a-Service
	(ACaaS)		(ACaaS)
	Abstract		Abstract
	Delivery of network services assumes that appropriate setup is		Delivery of network services assumes that appropriate setup is
	provisioned over the links that connect customer termination points		provisioned over the links that connect customer termination points
	and a provider network. The required setup to allow successful data		and a provider network. The required setup to allow successful data
	exchange over these links is referred to as an attachment circuit		exchange over these links is referred to as an attachment circuit
	(AC), while the underlying link is referred to as a "bearer".		(AC), while the underlying link is referred to as a "bearer".
	This document specifies a YANG service data model for ACs. This		This document specifies a YANG service data model for ACs. This
	model can be used for the provisioning of ACs before or during		model can be used for the provisioning of ACs before or during
	service provisioning (e.g., Network Slice Service).		service provisioning (e.g., RFC 9543 Network Slice Service).
	The document also specifies a YANG service data model for managing		The document also specifies a YANG service data model for managing
	bearers over which ACs are established.		bearers over which ACs are established.
	Status of This Memo		Status of This Memo
	This is an Internet Standards Track document.		This is an Internet Standards Track document.
	This document is a product of the Internet Engineering Task Force		This document is a product of the Internet Engineering Task Force
	(IETF). It represents the consensus of the IETF community. It has		(IETF). It represents the consensus of the IETF community. It has
	skipping to change at line 160 ¶		skipping to change at line 160 ¶
	adjacent domains that need to connect via an AC will use such means		adjacent domains that need to connect via an AC will use such means
	to agree upon the resources that are required for the activation of		to agree upon the resources that are required for the activation of
	both sides of an AC (e.g., Layer 2 tags, IP address family, or IP		both sides of an AC (e.g., Layer 2 tags, IP address family, or IP
	subnets).		subnets).
	This document specifies a YANG service data model ("ietf-ac-svc") for		This document specifies a YANG service data model ("ietf-ac-svc") for
	managing attachment circuits that are exposed by a network to its		managing attachment circuits that are exposed by a network to its
	customers, such as an enterprise site, an SF, a hosting		customers, such as an enterprise site, an SF, a hosting
	infrastructure, or a peer network provider. The model can be used		infrastructure, or a peer network provider. The model can be used
	for the provisioning of ACs prior to or during advanced service		for the provisioning of ACs prior to or during advanced service
	provisioning (e.g., IETF Network Slice Service defined in "A		provisioning (e.g., RFC 9543 Network Slice Service defined in "A
	Framework for Network Slices in Networks Built from IETF		Framework for Network Slices in Networks Built from IETF
	Technologies" [RFC9543]).		Technologies" [RFC9543]).
	The "ietf-ac-svc" module (Section 6.2) includes a set of reusable		The "ietf-ac-svc" module (Section 6.2) includes a set of reusable
	groupings. Whether a service model that wants to describe the		groupings. Whether a service model that wants to describe the
	attachment circuits associated with the service reuses structures		attachment circuits associated with the service reuses structures
	defined in the "ietf-ac-svc" or simply includes an AC reference (that		defined in the "ietf-ac-svc" or simply includes an AC reference (that
	was communicated during AC service instantiation) is a design choice		was communicated during AC service instantiation) is a design choice
	of these service models. Relying upon the AC service model to manage		of these service models. Relying upon the AC service model to manage
	ACs over which services are delivered has the merit of decorrelating		ACs over which services are delivered has the merit of decorrelating
	skipping to change at line 239 ¶		skipping to change at line 239 ¶
	* Request an attachment circuit for a known peer SAP (Appendix A.3).		* Request an attachment circuit for a known peer SAP (Appendix A.3).
	* Instantiate multiple attachment circuits over the same bearer		* Instantiate multiple attachment circuits over the same bearer
	(Appendix A.4).		(Appendix A.4).
	* Control the precedence over multiple attachment circuits		* Control the precedence over multiple attachment circuits
	(Appendix A.5).		(Appendix A.5).
	* Create multiple ACs bound to multiple CEs (Appendix A.6).		* Create multiple ACs bound to multiple CEs (Appendix A.6).
	* Bind a Slice Service to a set of pre-provisioned attachment		* Bind an RFC 9543 Network Slice Service to a set of pre-provisioned
	circuits (Appendix A.7).		attachment circuits (Appendix A.7).
	* Connect an enterprise network to a provider network using BGP		* Connect an enterprise network to a provider network using BGP
	(Appendix A.9).		(Appendix A.9).
	* Connect a Cloud Infrastructure to a service provider network		* Connect a Cloud Infrastructure to a service provider network
	(Appendix A.8).		(Appendix A.8).
	* Interconnect provider networks (e.g., [RFC8921] or [PEERING-API]).		* Interconnect provider networks (e.g., [RFC8921] or [PEERING-API]).
	Such ACs are identified with a 'role' set to 'ac-common:nni' or		Such ACs are identified with a 'role' set to 'ac-common:nni' or
	'ac-common:public-nni'. See Appendix A.10 to illustrate the use		'ac-common:public-nni'. See Appendix A.10 to illustrate the use
	skipping to change at line 392 ¶		skipping to change at line 392 ¶
	ACs (called child ACs) inherit the parent AC properties.		ACs (called child ACs) inherit the parent AC properties.
	Service orchestrator: Refers to a functional entity that interacts		Service orchestrator: Refers to a functional entity that interacts
	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 PE selection, and requesting the activation of the		circuits, the PE selection, and requesting the activation of the
	requested service to a network controller.		requested service to a network controller.
	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., Layer 2 VPN (L2VPN), Layer 3 VPN (L3VPN), or		services (e.g., Layer 2 VPN (L2VPN), Layer 3 VPN (L3VPN), or RFC
	Network Slice Services).		9543 Network Slice Services).
	Service provider: An entity that offers network services (e.g.,		Service provider: An entity that offers network services (e.g.,
	Layer 2 VPN, Layer 3 VPN, or Network Slice Services).		Layer 2 VPN, Layer 3 VPN, or RFC 9543 Network Slice Services).
	The names of data nodes are prefixed using the prefix associated with		The names of data nodes are prefixed using the prefix associated with
	the corresponding imported YANG module as shown in Table 1:		the corresponding imported YANG module as shown in Table 1:
	+============+==================+========================+		+============+==================+========================+
	| Prefix | Module | Reference |		| Prefix | Module | Reference |
	+============+==================+========================+		+============+==================+========================+
	| inet | ietf-inet-types | Section 4 of [RFC6991] |		| inet | ietf-inet-types | Section 4 of [RFC6991] |
	+------------+------------------+------------------------+		+------------+------------------+------------------------+
	| key-chain | ietf-key-chain | [RFC8177] |		| key-chain | ietf-key-chain | [RFC8177] |
	skipping to change at line 3914 ¶		skipping to change at line 3914 ¶
	list service-ref {		list service-ref {
	key "service-type service-id";		key "service-type service-id";
	config false;		config false;
	description		description
	"Reports the set of services that are bound to the AC.";		"Reports the set of services that are bound to the AC.";
	leaf service-type {		leaf service-type {
	type identityref {		type identityref {
	base vpn-common:service-type;		base vpn-common:service-type;
	}		}
	description		description
	"Indicates the service type (e.g., L3VPN or Network Slice		"Indicates the service type (e.g., L3VPN or RFC 9543
	Service).";		Network Slice Service).";
	reference		reference
	"RFC 9408: A YANG Network Data Model for Service		"RFC 9408: A YANG Network Data Model for Service
	Attachment Points (SAPs), Section 5";		Attachment Points (SAPs), Section 5";
	}		}
	leaf service-id {		leaf service-id {
	type string;		type string;
	description		description
	"Indicates an identifier of a service instance		"Indicates an identifier of a service instance
	of a given type that uses the AC.";		of a given type that uses the AC.";
	}		}
	skipping to change at line 3943 ¶		skipping to change at line 3943 ¶
	to identify the AC.";		to identify the AC.";
	}		}
	uses ac;		uses ac;
	}		}
	}		}
	}		}
	<CODE ENDS>		<CODE ENDS>
	7. Security Considerations		7. Security Considerations
	This section is modeled after the template described in Section 3.7		Several data nodes ('bgp', 'ospf', 'isis', 'rip', and 'customer-key-
	of [YANG-GUIDELINES].		chain') rely upon [RFC8177] for authentication purposes. As such,
			the AC service module inherits the security considerations discussed
			in Section 5 of [RFC8177]. Also, these data nodes support supplying
			explicit keys as strings in ASCII format. The use of keys in
			hexadecimal string format would afford greater key entropy with the
			same number of key-string octets. However, such a format is not
			included in this version of the AC service model because it is not
			supported by the underlying device modules (e.g., [RFC8695]).
			Section 5.2.5.5 specifies a set of encryption-related parameters that
			can be applied to traffic for a given AC.
			The remainder of this section is modeled after the template described
			in Section 3.7.1 of [YANG-GUIDELINES].
	The "ietf-bearer-svc" and "ietf-ac-svc" YANG modules define data		The "ietf-bearer-svc" and "ietf-ac-svc" YANG modules define data
	models that are designed to be accessed via YANG-based management		models that are designed to be accessed via YANG-based management
	protocols, such as NETCONF [RFC6241] and RESTCONF [RFC8040]. These		protocols, such as NETCONF [RFC6241] and RESTCONF [RFC8040]. These
	protocols have to use a secure transport layer (e.g., SSH [RFC4252],		protocols have to use a secure transport layer (e.g., SSH [RFC4252],
	TLS [RFC8446], and QUIC [RFC9000]) and have to use mutual		TLS [RFC8446], and QUIC [RFC9000]) and have to use mutual
	authentication.		authentication.
	Servers MUST verify that requesting clients are entitled to access		Servers MUST verify that requesting clients are entitled to access
	and manipulate a given bearer or AC. For example, a given customer		and manipulate a given bearer or AC. For example, a given customer
	skipping to change at line 4032 ¶		skipping to change at line 4045 ¶
	'customer-name', 'l2-connection', and 'ip-connection': An attacker		'customer-name', 'l2-connection', and 'ip-connection': An attacker
	can retrieve privacy-related information, which can be used to		can retrieve privacy-related information, which can be used to
	track a customer. Disclosing such information may be considered a		track a customer. Disclosing such information may be considered a
	violation of the customer-provider trust relationship.		violation of the customer-provider trust relationship.
	'keying-material': An attacker can retrieve the cryptographic keys		'keying-material': An attacker can retrieve the cryptographic keys
	protecting the underlying connectivity services (routing, in		protecting the underlying connectivity services (routing, in
	particular). These keys could be used to inject spoofed routing		particular). These keys could be used to inject spoofed routing
	advertisements.		advertisements.
	Several data nodes ('bgp', 'ospf', 'isis', 'rip', and 'customer-key-		There are no particularly sensitive RPC or action operations.
	chain') rely upon [RFC8177] for authentication purposes. As such,
	the AC service module inherits the security considerations discussed
	in Section 5 of [RFC8177]. Also, these data nodes support supplying
	explicit keys as strings in ASCII format. The use of keys in
	hexadecimal string format would afford greater key entropy with the
	same number of key-string octets. However, such a format is not
	included in this version of the AC service model because it is not
	supported by the underlying device modules (e.g., [RFC8695]).
	Section 5.2.5.5 specifies a set of encryption-related parameters that
	can be applied to traffic for a given AC.
	8. IANA Considerations		8. IANA Considerations
	IANA has registered the following URIs in the "ns" subregistry within		IANA has registered the following URIs in the "ns" subregistry within
	the "IETF XML Registry" [RFC3688]:		the "IETF XML Registry" [RFC3688]:
	URI: urn:ietf:params:xml:ns:yang:ietf-bearer-svc		URI: urn:ietf:params:xml:ns:yang:ietf-bearer-svc
	Registrant Contact: The IESG.		Registrant Contact: The IESG.
	XML: N/A; the requested URI is an XML namespace.		XML: N/A; the requested URI is an XML namespace.
	skipping to change at line 4201 ¶		skipping to change at line 4203 ¶
	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/info/rfc9408>.		June 2023, <https://www.rfc-editor.org/info/rfc9408>.
	[RFC9568] Lindem, A. and A. Dogra, "Virtual Router Redundancy		[RFC9568] Lindem, A. and A. Dogra, "Virtual Router Redundancy
	Protocol (VRRP) Version 3 for IPv4 and IPv6", RFC 9568,		Protocol (VRRP) Version 3 for IPv4 and IPv6", RFC 9568,
	DOI 10.17487/RFC9568, April 2024,		DOI 10.17487/RFC9568, April 2024,
	<https://www.rfc-editor.org/info/rfc9568>.		<https://www.rfc-editor.org/info/rfc9568>.
	[RFC9833] Boucadair, M., Ed., Roberts, R., Ed., Gonzalez de Dios,		[RFC9833] Boucadair, M., Ed., Roberts, R., Ed., Gonzalez de Dios,
	O., Barguil Giraldo, S., and B. Wu, "A Common YANG Data		O., Barguil, S., and B. Wu, "A Common YANG Data Model for
	Model for Attachment Circuits", RFC 9833,		Attachment Circuits", RFC 9833, DOI 10.17487/RFC9833,
	DOI 10.17487/RFC9833, August 2025,		August 2025, <https://www.rfc-editor.org/info/rfc9833>.
	<https://www.rfc-editor.org/info/rfc9833>.
	9.2. Informative References		9.2. Informative References
	[BGP4-YANG]		[BGP4-YANG]
	Jethanandani, M., Patel, K., Hares, S., and J. Haas, "YANG		Jethanandani, M., Patel, K., Hares, S., and J. Haas, "YANG
	Model for Border Gateway Protocol (BGP-4)", Work in		Model for Border Gateway Protocol (BGP-4)", Work in
	Progress, Internet-Draft, draft-ietf-idr-bgp-model-18, 21		Progress, Internet-Draft, draft-ietf-idr-bgp-model-18, 21
	October 2024, <https://datatracker.ietf.org/doc/html/		October 2024, <https://datatracker.ietf.org/doc/html/
	draft-ietf-idr-bgp-model-18>.		draft-ietf-idr-bgp-model-18>.
	skipping to change at line 4359 ¶		skipping to change at line 4360 ¶
	DOI 10.17487/RFC9234, May 2022,		DOI 10.17487/RFC9234, May 2022,
	<https://www.rfc-editor.org/info/rfc9234>.		<https://www.rfc-editor.org/info/rfc9234>.
	[RFC9543] Farrel, A., Ed., Drake, J., Ed., Rokui, R., Homma, S.,		[RFC9543] Farrel, A., Ed., Drake, J., Ed., Rokui, R., Homma, S.,
	Makhijani, K., Contreras, L., and J. Tantsura, "A		Makhijani, K., Contreras, L., and J. Tantsura, "A
	Framework for Network Slices in Networks Built from IETF		Framework for Network Slices in Networks Built from IETF
	Technologies", RFC 9543, DOI 10.17487/RFC9543, March 2024,		Technologies", RFC 9543, DOI 10.17487/RFC9543, March 2024,
	<https://www.rfc-editor.org/info/rfc9543>.		<https://www.rfc-editor.org/info/rfc9543>.
	[RFC9835] Boucadair, M., Ed., Roberts, R., Gonzalez de Dios, O.,		[RFC9835] Boucadair, M., Ed., Roberts, R., Gonzalez de Dios, O.,
	Barguil Giraldo, S., and B. Wu, "A Network YANG Data Model		Barguil, S., and B. Wu, "A Network YANG Data Model for
	for Attachment Circuits", RFC 9835, DOI 10.17487/RFC9835,		Attachment Circuits", RFC 9835, DOI 10.17487/RFC9835,
	August 2025, <https://www.rfc-editor.org/info/rfc9835>.		August 2025, <https://www.rfc-editor.org/info/rfc9835>.
	[RFC9836] Boucadair, M., Ed., Roberts, R., Barguil Giraldo, S., and		[RFC9836] Boucadair, M., Ed., Roberts, R., Barguil, S., and O.
	O. Gonzalez de Dios, "A YANG Data Model for Augmenting VPN		Gonzalez de Dios, "A YANG Data Model for Augmenting VPN
	Service and Network Models with Attachment Circuits",		Service and Network Models with Attachment Circuits",
	RFC 9836, DOI 10.17487/RFC9836, August 2025,		RFC 9836, DOI 10.17487/RFC9836, August 2025,
	<https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-		<https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-
	ac-lxsm-lxnm-glue-14>.		ac-lxsm-lxnm-glue-14>.
	[YANG-GUIDELINES]		[YANG-GUIDELINES]
	Bierman, A., Boucadair, M., Ed., and Q. Wu, "Guidelines		Bierman, A., Boucadair, M., Ed., and Q. Wu, "Guidelines
	for Authors and Reviewers of Documents Containing YANG		for Authors and Reviewers of Documents Containing YANG
	Data Models", Work in Progress, Internet-Draft, draft-		Data Models", Work in Progress, Internet-Draft, draft-
	ietf-netmod-rfc8407bis-28, 5 June 2025,		ietf-netmod-rfc8407bis-28, 5 June 2025,
	skipping to change at line 4498 ¶		skipping to change at line 4499 ¶
	}		}
	},		},
	"bearer-reference": "line-156"		"bearer-reference": "line-156"
	}		}
	}		}
	]		]
	}		}
	}		}
	Figure 27: Example of a Message Body of a Response to Assign a		Figure 27: Example of a Message Body of a Response to Assign a
	Customer VLAN (CVLAN) ID		Customer VLAN (C-VLAN) ID
	A.3. Create an AC for a Known Peer SAP		A.3. Create an AC for a Known Peer SAP
	An example of a request to create a simple AC, when the peer SAP is		An example of a request to create a simple AC, when the peer SAP is
	known, is shown in Figure 28. In this example, the peer SAP		known, is shown in Figure 28. In this example, the peer SAP
	identifier points to an identifier of an SF. The (topological)		identifier points to an identifier of an SF. The (topological)
	location of that SF is assumed to be known to the network controller.		location of that SF is assumed to be known to the network controller.
	For example, this can be determined as part of an on-demand procedure		For example, this can be determined as part of an on-demand procedure
	to instantiate an SF in a cloud. That instantiated SF can be granted		to instantiate an SF in a cloud. That instantiated SF can be granted
	a connectivity service via the provider network.		a connectivity service via the provider network.
	skipping to change at line 5013 ¶		skipping to change at line 5014 ¶
	}		}
	}		}
	Figure 38: Example of a Message Body of a Request to Create		Figure 38: Example of a Message Body of a Request to Create
	Multiple ACs Bound to Multiple CEs		Multiple ACs Bound to Multiple CEs
	A.7. Binding Attachment Circuits to an IETF Network Slice		A.7. Binding Attachment Circuits to an IETF Network Slice
	This example shows how the AC service model complements the model		This example shows how the AC service model complements the model
	defined in "A YANG Data Model for the RFC 9543 Network Slice Service"		defined in "A YANG Data Model for the RFC 9543 Network Slice Service"
	[NSSM] to connect a site to a Slice Service.		[NSSM] to connect a site to an RFC 9543 Network Slice Service.
	First, Figure 39 describes the end-to-end network topology as well as		First, Figure 39 describes the end-to-end network topology as well as
	the orchestration scopes:		the orchestration scopes:
	* The topology is made up of two sites ("site1" and "site2"),		* The topology is made up of two sites ("site1" and "site2"),
	interconnected via a Transport Network (e.g., IP/MPLS network).		interconnected via a Transport Network (e.g., IP/MPLS network).
	An SF is deployed within each site in a dedicated IP subnet.		An SF is deployed within each site in a dedicated IP subnet.
	* A 5G Service Management and Orchestration (SMO) is responsible for		* A 5G Service Management and Orchestration (SMO) is responsible for
	the deployment of SFs and the indirect management of a local		the deployment of SFs and the indirect management of a local
	skipping to change at line 5284 ¶		skipping to change at line 5285 ¶
	]		]
	}		}
	}		}
	]		]
	}		}
	}		}
	Figure 42: Example of a Message Body of a Response Indicating the		Figure 42: Example of a Message Body of a Response Indicating the
	Creation of the ACs		Creation of the ACs
	Figure 43 shows the message body of the request to create a Slice		Figure 43 shows the message body of the request to create an RFC 9543
	Service bound to the ACs created using Figure 41. Only references to		Netowrk Slice Service bound to the ACs created using Figure 41. Only
	these ACs are included in the Slice Service request.		references to these ACs are included in the RFC 9543 Network Slice
			Service request.
	{		{
	"ietf-network-slice-service:network-slice-services": {		"ietf-network-slice-service:network-slice-services": {
	"slo-sle-templates": {		"slo-sle-templates": {
	"slo-sle-template": [		"slo-sle-template": [
	{		{
	"id": "low-latency-template",		"id": "low-latency-template",
	"description": "Lowest latency forwarding behavior"		"description": "Lowest latency forwarding behavior"
	}		}
	]		]
	skipping to change at line 5325 ¶		skipping to change at line 5327 ¶
	"ac2"		"ac2"
	]		]
	}		}
	]		]
	}		}
	}		}
	]		]
	}		}
	}		}
	Figure 43: Message Body of a Request to Create a Slice Service		Figure 43: Message Body of a Request to Create an RFC 9543
	Referring to the ACs		Network Slice Service Referring to the ACs
	A.8. Connecting a Virtualized Environment Running in a Cloud Provider		A.8. Connecting a Virtualized Environment Running in a Cloud Provider
	This example (Figure 44) shows how the AC service model can be used		This example (Figure 44) shows how the AC service model can be used
	to connect a Cloud Infrastructure to a service provider network.		to connect a Cloud Infrastructure to a service provider network.
	This example makes the following assumptions:		This example makes the following assumptions:
	1. A customer (e.g., Mobile Network Team or partner) has a		1. A customer (e.g., Mobile Network Team or partner) has a
	virtualized infrastructure running in a Cloud Provider. A		virtualized infrastructure running in a Cloud Provider. A
	simplistic deployment is represented here with a set of Virtual		simplistic deployment is represented here with a set of Virtual
	skipping to change at line 5417 ¶		skipping to change at line 5419 ¶
	bearer-reference: 1234-56789 for PE1/Interface "If-A"		bearer-reference: 1234-56789 for PE1/Interface "If-A"
	Figure 45: Illustration of Pre-Provisioning		Figure 45: Illustration of Pre-Provisioning
	Next, API workflows can be initiated by:		Next, API workflows can be initiated by:
	* The Cloud Provider for the configuration per Step (3) above.		* The Cloud Provider for the configuration per Step (3) above.
	* The service provider network via the ACaaS model. This request		* The service provider network via the ACaaS model. This request
	can be used in conjunction with additional requests based on the		can be used in conjunction with additional requests based on the
	L3SM (VPN provisioning) or Network Slice Service model (5G hybrid		L3SM (VPN provisioning) or RFC 9543 Network Slice Service model
	cloud deployment).		(5G hybrid cloud deployment).
	Figure 46 shows the message body of the request to create the		Figure 46 shows the message body of the request to create the
	required ACs to connect the virtualized Cloud Provider (VM) using the		required ACs to connect the virtualized Cloud Provider (VM) using the
	ACaaS module.		ACaaS module.
	=============== NOTE: '\' line wrapping per RFC 8792 ================		=============== NOTE: '\' line wrapping per RFC 8792 ================
	{		{
	"ietf-ac-svc:attachment-circuits": {		"ietf-ac-svc:attachment-circuits": {
	"ac": [		"ac": [
	skipping to change at line 6597 ¶		skipping to change at line 6599 ¶
	| '----' | | |		| '----' | | |
	compute-08 '-----------------------'		compute-08 '-----------------------'
	Figure 64: Example of Compute Failure and Scale-Out		Figure 64: Example of Compute Failure and Scale-Out
	Finally, the addition or deletion of compute nodes in the deployment		Finally, the addition or deletion of compute nodes in the deployment
	("compute-11", "compute-12", etc.) involves merely changes on Child		("compute-11", "compute-12", etc.) involves merely changes on Child
	ACs and possible routing on the parent AC. In any case, the parent		ACs and possible routing on the parent AC. In any case, the parent
	AC is a stable identifier, which can be consumed as a reference by		AC is a stable identifier, which can be consumed as a reference by
	end-to-end service models for VPN configuration such as AC Glue		end-to-end service models for VPN configuration such as AC Glue
	[RFC9836], Slice Service [NSSM], etc. This decoupling to a stable		[RFC9836], RFC 9543 Network Slice Service [NSSM], etc. This
	identifier provides great benefits in terms of scalability and		decoupling to a stable identifier provides great benefits in terms of
	flexibility since once the reference with the parent AC is		scalability and flexibility since once the reference with the parent
	implemented, no API call involving the VPN model is needed for any		AC is implemented, no API call involving the VPN model is needed for
	modification in the cloud.		any modification in the cloud.
	A.12. BFD and Static Addressing		A.12. BFD and Static Addressing
	Figure 65 shows a topology example of a set of CEs connected to a		Figure 65 shows a topology example of a set of CEs connected to a
	provider network via dedicated bearers. Each of these CEs maintains		provider network via dedicated bearers. Each of these CEs maintains
	two BFD sessions with the provider network.		two BFD sessions with the provider network.
	+----------------------------+		+----------------------------+
	.-------. .1 | |		.-------. .1 | |
	| CE1 |------------|------+ |		| CE1 |------------|------+ |
	skipping to change at line 7641 ¶		skipping to change at line 7643 ¶
	Email: mohamed.boucadair@orange.com		Email: mohamed.boucadair@orange.com
	Richard Roberts (editor)		Richard Roberts (editor)
	Juniper		Juniper
	Email: rroberts@juniper.net		Email: rroberts@juniper.net
	Oscar Gonzalez de Dios		Oscar Gonzalez de Dios
	Telefonica		Telefonica
	Email: oscar.gonzalezdedios@telefonica.com		Email: oscar.gonzalezdedios@telefonica.com
	Samier Barguil Giraldo		Samier Barguil
	Nokia		Nokia
	Email: samier.barguil_giraldo@nokia.com		Email: samier.barguil_giraldo@nokia.com
	Bo Wu		Bo Wu
	Huawei Technologies		Huawei Technologies
	Email: lana.wubo@huawei.com		Email: lana.wubo@huawei.com
End of changes. 19 change blocks.
	47 lines changed or deleted		49 lines changed or added
This html diff was produced by rfcdiff 1.48.