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 September 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 73 skipping to change at line 73
1. Introduction 1. Introduction
1.1. Scope and Intended Use 1.1. Scope and Intended Use
1.2. Positioning ACaaS vs. Other Data Models 1.2. Positioning ACaaS vs. Other Data Models
1.2.1. Why Not Use the L2SM as a Reference Data Model for 1.2.1. Why Not Use the L2SM as a Reference Data Model for
ACaaS? ACaaS?
1.2.2. Why Not Use the L3SM as a Reference Data Model for 1.2.2. Why Not Use the L3SM as a Reference Data Model for
ACaaS? ACaaS?
2. Conventions and Definitions 2. Conventions and Definitions
3. Relationship to Other AC Data Models 3. Relationship to Other AC Data Models
4. Sample Uses of the Data Models 4. Sample Uses of the Data Models
4.1. ACs Terminated by One or Multiple Customer Edges (CEs) 4.1. ACs Terminated by One or Multiple CEs
4.2. Separate AC Provisioning vs. Actual Service Provisioning 4.2. Separate AC Provisioning vs. Actual Service Provisioning
4.3. Sample Deployment Models 4.3. Sample Deployment Models
5. Description of the Data Models 5. Description of the Data Models
5.1. The Bearer Service ("ietf-bearer-svc") YANG Module 5.1. The Bearer Service ("ietf-bearer-svc") YANG Module
5.2. The Attachment Circuit Service ("ietf-ac-svc") YANG Module 5.2. The Attachment Circuit Service ("ietf-ac-svc") YANG Module
5.2.1. Overall Structure 5.2.1. Overall Structure
5.2.2. Service Profiles 5.2.2. Service Profiles
5.2.3. Attachment Circuits Profiles 5.2.3. Attachment Circuits Profiles
5.2.4. AC Placement Constraints 5.2.4. AC Placement Constraints
5.2.5. Attachment Circuits 5.2.5. Attachment Circuits
skipping to change at line 139 skipping to change at line 139
service can be negotiated and agreed upon between the customer and service can be negotiated and agreed upon between the customer and
the network provider. To facilitate data transfer within the the network provider. To facilitate data transfer within the
provider network, it is assumed that the appropriate setup is provider network, it is assumed that the 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 (usually via a Provider Edge (PE)), allowing and a provider network (usually via a Provider Edge (PE)), allowing
data to be successfully exchanged over these links. The required data to be successfully exchanged over these links. The required
setup is referred to in this document as an attachment circuit (AC), setup is referred to in this document as an attachment circuit (AC),
while the underlying link is referred to as a "bearer". while the underlying link is referred to as a "bearer".
When a customer requests a new service, the service can be bound to When a customer requests a new service, the service can be bound to
existing attachment circuits or trigger the instantiation of new existing ACs or trigger the instantiation of new ACs. The
attachment circuits. The provisioning of a service should, thus, provisioning of a service should, thus, accommodate both deployments.
accommodate both deployments.
Also, because the instantiation of an attachment circuit requires Also, because the instantiation of an AC requires coordinating the
coordinating the provisioning of endpoints that might not belong to provisioning of endpoints that might not belong to the same
the same administrative entity (customer vs. provider or distinct administrative entity (customer vs. provider or distinct operational
operational teams within the same provider, etc.), providing teams within the same provider, etc.), providing programmatic means
programmatic means to expose 'Attachment Circuits'-as-a-Service to expose Attachment Circuits as a Service (ACaaS) greatly simplifies
(ACaaS) greatly simplifies the provisioning of services delivered the provisioning of services delivered over an AC. For example,
over an attachment circuit. For example, management systems of management systems of adjacent domains that need to connect via an AC
adjacent domains that need to connect via an AC will use such means will use such means to agree upon the resources that are required for
to agree upon the resources that are required for the activation of the activation of both sides of an AC (e.g., Layer 2 tags, IP address
both sides of an AC (e.g., Layer 2 tags, IP address family, or IP 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 ACs that are exposed by a network to its customers, such as
customers, such as an enterprise site, an SF, a hosting an enterprise site, an SF, a hosting infrastructure, or a peer
infrastructure, or a peer network provider. The model can be used network provider. The model can be used for the provisioning of ACs
for the provisioning of ACs prior to or during advanced service prior to or during advanced service provisioning (e.g., RFC 9543
provisioning (e.g., IETF Network Slice Service defined in "A Network Slice Service defined in "A Framework for Network Slices in
Framework for Network Slices in Networks Built from IETF 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 ACs
attachment circuits associated with the service reuses structures associated with the service reuses structures defined in the "ietf-
defined in the "ietf-ac-svc" or simply includes an AC reference (that ac-svc" or simply includes an AC reference (that was communicated
was communicated during AC service instantiation) is a design choice during AC service instantiation) is a design choice of these service
of these service models. Relying upon the AC service model to manage models. Relying upon the AC service model to manage ACs over which
ACs over which services are delivered has the merit of decorrelating services are delivered has the merit of decorrelating the management
the management of the (core) service from the ACs. This allows of the (core) service from the ACs. This allows upgrades (to reflect
upgrades (to reflect recent AC technologies or new features such as recent AC technologies or new features such as new encryption schemes
new encryption schemes or additional routing protocols) to be done in or additional routing protocols) to be done in just one place rather
just one place rather than in each (core) service model. This than in each (core) service model. This document favors the approach
document favors the approach of completely relying upon the AC of completely relying upon the AC service model instead of
service model instead of duplicating data nodes into specific modules duplicating data nodes into specific modules of advanced services
of advanced services that are delivered over an attachment circuit. that are delivered over an AC.
Since the provisioning of an AC requires a bearer to be in place, Since the provisioning of an AC requires a bearer to be in place,
this document introduces a new module called "ietf-bearer-svc", which this document introduces a new module called "ietf-bearer-svc", which
enables customers to manage their bearers (Section 6.1). The enables customers to manage their bearers (Section 6.1). The
customers can then retrieve a provider-assigned bearer reference that customers can then retrieve a provider-assigned bearer reference that
they will include in their AC service requests. Likewise, a customer they will include in their AC service requests. Likewise, a customer
may retrieve whether their bearers support a synchronization may learn whether their bearers support a synchronization mechanism
mechanism such as Sync Ethernet (SyncE) [ITU-T-G.781]. An example of such as Sync Ethernet (SyncE) [ITU-T-G.781]. An example of
retrieving a bearer reference is provided in Appendix A.1. retrieving a bearer reference is provided in Appendix A.1.
An AC service request can provide a reference to a bearer or a set of An AC service request can provide a reference to a bearer or a set of
peer Service Attachment Points (SAPs) specified in "A YANG Network peer Service Attachment Points (SAPs) specified in "A YANG Network
Data Model for Service Attachment Points (SAPs)" [RFC9408]. Both Data Model for Service Attachment Points (SAPs)" [RFC9408]. Both
schemes are supported in the AC service model. When several bearers schemes are supported in the AC service model. When several bearers
are available, the AC service request may filter them based on the are available, the AC service request may filter them based on the
bearer type, synchronization support, etc. bearer type, synchronization support, etc.
Each AC is identified with a unique identifier within a provider Each AC is identified with a unique identifier within a provider
skipping to change at line 212 skipping to change at line 209
details about the (node-specific) attachment interfaces are not details about the (node-specific) attachment interfaces are not
exposed in the AC service model. However, these details are exposed exposed in the AC service model. However, these details are exposed
at the network model per "A Network YANG Data Model for Attachment at the network model per "A Network YANG Data Model for Attachment
Circuits" [RFC9835]. "A YANG Data Model for Augmenting VPN Service Circuits" [RFC9835]. "A YANG Data Model for Augmenting VPN Service
and Network Models with Attachment Circuits" [RFC9836] specifies and Network Models with Attachment Circuits" [RFC9836] specifies
augmentations to the L2VPN Service Model (L2SM) [RFC8466] and the augmentations to the L2VPN Service Model (L2SM) [RFC8466] and the
L3VPN Service Model (L3SM) [RFC8299] to bind LxVPN services to ACs. L3VPN Service Model (L3SM) [RFC8299] to bind LxVPN services to ACs.
The AC service model does not make any assumptions about the internal The AC service model does not make any assumptions about the internal
structure or even the nature of the services that will be delivered structure or even the nature of the services that will be delivered
over an attachment circuit or a set of attachment circuits. over an AC or a set of ACs. Customers do not have access to that
Customers do not have access to that network view other than the ACs network view other than the ACs that they ordered. For example, the
that they ordered. For example, the AC service model can be used to AC service model can be used to provision a set of ACs to connect
provision a set of ACs to connect multiple sites (Site1, Site2, ..., multiple sites (Site1, Site2, ..., SiteX) for a customer who also
SiteX) for a customer who also requested VPN services. If the requested VPN services. If the provisioning of these services
provisioning of these services requires specific configuration on requires specific configuration on ASBR nodes, such configuration is
ASBR nodes, such configuration is handled at the network level and is handled at the network level and is not exposed to the customer at
not exposed to the customer at the service level. However, the the service level. However, the network controller will have access
network controller will have access to such a view, as the service to such a view, as the service points in these ASBRs will be exposed
points in these ASBRs will be exposed as SAPs with 'role' set to as SAPs with 'role' set to 'ietf-sap-ntw:nni' [RFC9408].
'ietf-sap-ntw:nni' [RFC9408].
The AC service model can be used in a variety of contexts, such as The AC service model can be used in a variety of contexts, such as
(but not limited to) those provided in Appendix A: (but not limited to) those provided in Appendix A:
* Create an AC over an existing bearer (Appendix A.2). * Create an AC over an existing bearer (Appendix A.2).
* Request an attachment circuit for a known peer SAP (Appendix A.3). * Request an AC for a known peer SAP (Appendix A.3).
* Instantiate multiple attachment circuits over the same bearer * Instantiate multiple ACs over the same bearer (Appendix A.4).
(Appendix A.4).
* Control the precedence over multiple attachment circuits * Control the precedence over multiple ACs (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). ACs (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 321 skipping to change at line 315
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
The meanings of the symbols in the YANG tree diagrams are defined in The meanings of the symbols in the YANG tree diagrams are defined in
"YANG Tree Diagrams" [RFC8340]. "YANG Tree Diagrams" [RFC8340].
LxSM refers to both the L2SM and the L3SM. LxSM refers to both the L2SM and the L3SM.
LxVPN refers to both Layer 2 VPN (L2VPN) and Layer 3 VPN (L3VPN).
LxNM refers to both the L2VPN Network Model (L2NM) and the L3VPN LxNM refers to both the L2VPN Network Model (L2NM) and the L3VPN
Network Model (L3NM). Network Model (L3NM).
LxVPN refers to both Layer 2 VPN (L2VPN) and Layer 3 VPN (L3VPN).
This document uses the following terms: This document uses the following terms:
Bearer: A physical or logical link that connects a customer node (or Bearer: A physical or logical link that connects a customer node (or
site) to a provider network. site) to a provider network.
A bearer can be a wireless or wired link. One or multiple A bearer can be a wireless or wired link. One or multiple
technologies can be used to build a bearer (e.g., Link Aggregation technologies can be used to build a bearer (e.g., Link Aggregation
Group (LAG) [IEEE802.1AX]). The bearer type can be specified by a Group (LAG) [IEEE802.1AX]). The bearer type can be specified by a
customer. customer.
The operator allocates a unique bearer reference to identify a The operator allocates a unique bearer reference to identify a
bearer within its network (e.g., customer line identifier). Such bearer within its network (e.g., customer line identifier). Such
a reference can be retrieved by a customer and used in subsequent a reference can be retrieved by a customer and used in subsequent
service placement requests to unambiguously identify where a service placement requests to unambiguously identify where a
service is to be bound. service is to be bound.
The concept of a bearer can be generalized to refer to the The concept of a bearer can be generalized to refer to the
required underlying connection for the provisioning of an required underlying connection for the provisioning of an AC.
attachment circuit.
One or multiple attachment circuits may be hosted over the same One or multiple ACs may be hosted over the same bearer (e.g.,
bearer (e.g., multiple VLANs on the same bearer that is provided multiple VLANs on the same bearer that is provided by a physical
by a physical link). link).
Customer Edge (CE): Equipment that is dedicated to a customer and is Customer Edge (CE): Equipment that is dedicated to a customer and is
connected to one or more PEs via ACs. connected to one or more PEs via ACs.
A CE can be a router, a bridge, a switch, etc. A CE can be a router, a bridge, a switch, etc.
Provider Edge (PE): Equipment owned and managed by the service Provider Edge (PE): Equipment owned and managed by the service
provider that can support multiple services for different provider that can support multiple services for different
customers. customers.
Per "Provider Provisioned Virtual Private Network (VPN) Per "Provider Provisioned Virtual Private Network (VPN)
Terminology" (Section 5.2 of [RFC4026]), a PE is a device located Terminology" (Section 5.2 of [RFC4026]), a PE is a device located
at the edge of the service network with the functionality that is at the edge of the service network with the functionality that is
needed to interface with the customer. needed to interface with the customer.
A PE is connected to one or more CEs via ACs. A PE is connected to one or more CEs via ACs.
Network controller: Denotes a functional entity responsible for the Network controller: Denotes a functional entity responsible for the
management of the service provider network. management of the service provider network. One or multiple
network controllers can be deployed in a service provider network.
Network Function (NF): Used to refer to the same concept as Service Network Function (NF): Used to refer to the same concept as SF
Function (SF) (Section 1.4 of [RFC7665]). (Section 1.4 of [RFC7665]).
NF is also used in this document, as this term is widely used NF is also used in this document, as this term is widely used
outside the IETF. outside the IETF.
NF and SF are used interchangeably. NF and SF are used interchangeably.
Parent Bearer: Refers to a bearer (e.g., LAG) that is used to build Parent Bearer: Refers to a bearer (e.g., LAG) that is used to build
other bearers. These bearers (called child bearers) inherit the other bearers. These bearers (called child bearers) inherit the
parent bearer properties. parent bearer properties.
Parent AC: Refers to an AC that is used to build other ACs. These Parent AC: Refers to an AC that is used to build other ACs. These
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 ACs, the
circuits, the PE selection, and requesting the activation of the PE selection, and requesting the activation of the requested
requested service to a network controller. service to a network controller.
A service orchestrator may interact with one or more network
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., Layer 2 VPN (L2VPN), Layer 3 VPN (L3VPN), or services (e.g., LxVPN or RFC 9543 Network Slice Services).
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). LxVPN 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 456 skipping to change at line 452
Figure 1: AC Data Models Figure 1: AC Data Models
The "ietf-ac-common" module is imported by the "ietf-bearer-svc", The "ietf-ac-common" module is imported by the "ietf-bearer-svc",
"ietf-ac-svc", and "ietf-ac-ntw" modules. Bearers managed using the "ietf-ac-svc", and "ietf-ac-ntw" modules. Bearers managed using the
"ietf-bearer-svc" module may be referenced by service ACs managed "ietf-bearer-svc" module may be referenced by service ACs managed
using the "ietf-ac-svc" module. Similarly, a bearer managed using using the "ietf-ac-svc" module. Similarly, a bearer managed using
the "ietf-bearer-svc" module may list the set of ACs that use that the "ietf-bearer-svc" module may list the set of ACs that use that
bearer. To facilitate correlation between an AC service request and bearer. To facilitate correlation between an AC service request and
the actual AC provisioned in the network, "ietf-ac-ntw" leverages the the actual AC provisioned in the network, "ietf-ac-ntw" leverages the
AC references exposed by the "ietf-ac-svc" module. Furthermore, to AC references exposed by the "ietf-ac-svc" module. Furthermore, to
bind Layer 2 VPN or Layer 3 VPN services with ACs, the "ietf-ac-glue" bind L2VPN or L3VPN services with ACs, the "ietf-ac-glue" module
module augments the LxSM and LxNM with AC service references exposed augments the LxSM and LxNM with AC service references exposed by the
by the "ietf-ac-svc" module and AC network references exposed by the "ietf-ac-svc" module and AC network references exposed by the "ietf-
"ietf-ac-ntw" module. ac-ntw" module.
4. Sample Uses of the Data Models 4. Sample Uses of the Data Models
4.1. ACs Terminated by One or Multiple Customer Edges (CEs) 4.1. ACs Terminated by One or Multiple CEs
Figure 2 depicts two target topology flavors that involve ACs. These Figure 2 depicts two target topology flavors that involve ACs. These
topologies have the following characteristics: topologies have the following characteristics:
* A CE can be either a physical device or a logical entity. Such * A CE can be either a physical device or a logical entity. Such
logical entity is typically a software component (e.g., a virtual logical entity is typically a software component (e.g., a virtual
Service Function that is hosted within the provider's network or a SF that is hosted within the provider's network or a third-party
third-party infrastructure). A CE is seen by the network as a infrastructure). A CE is seen by the network as a peer SAP.
peer SAP.
* An AC service request may include one or multiple ACs, which may * An AC service request may include one or multiple ACs, which may
be associated to a single CE or multiple CEs. be associated to a single CE or multiple CEs.
* CEs may be either dedicated to one single connectivity service or * CEs may be either dedicated to one single connectivity service or
host multiple connectivity services (e.g., CEs with roles of SFs host multiple connectivity services (e.g., CEs with roles of SFs
[RFC7665]). [RFC7665]).
* A network provider may bind a single AC to one or multiple peer * A network provider may bind a single AC to one or multiple peer
SAPs (e.g., CE1 and CE2 are tagged as peer SAPs for the same AC). SAPs (e.g., CE1 and CE2 are tagged as peer SAPs for the same AC).
For example, and as discussed in [RFC4364], multiple CEs can be For example, and as discussed in [RFC4364], multiple CEs can be
attached to a PE over the same attachment circuit. This scenario attached to a PE over the same AC. This scenario is typically
is typically implemented when the Layer 2 infrastructure between implemented when the Layer 2 infrastructure between the CE and the
the CE and the network is a multipoint service. network is a multipoint service.
* A single CE may terminate multiple ACs, which can be associated * A single CE may terminate multiple ACs, which can be associated
with the same bearer or distinct bearers. with the same bearer or distinct bearers.
* Customers may request protection schemes in which the ACs * Customers may request protection schemes in which the ACs
associated with their endpoints are terminated by the same PE associated with their endpoints are terminated by the same PE
(e.g., CE3), distinct PEs (e.g., CE4), etc. The network provider (e.g., CE3), distinct PEs (e.g., CE4), etc. The network provider
uses this request to decide where to terminate the AC in the uses this request to decide where to terminate the AC in the
provider network (i.e., select which PE(s) to use) and also provider network (i.e., select which PE(s) to use) and also
whether to enable specific capabilities (e.g., Virtual Router whether to enable specific capabilities (e.g., Virtual Router
skipping to change at line 526 skipping to change at line 521
'-----------AC----------' '-----------AC----------'
(bx) = bearer Id x (bx) = bearer Id x
Figure 2: Examples of ACs Figure 2: Examples of ACs
4.2. Separate AC Provisioning vs. Actual Service Provisioning 4.2. Separate AC Provisioning vs. Actual Service Provisioning
The procedure to provision a service in a service provider network The procedure to provision a service in a service provider network
may depend on the practices adopted by a service provider. This may depend on the practices adopted by a service provider. This
includes the workflow put in place for the provisioning of network includes the workflow put in place for the provisioning of network
services and how they are bound to an attachment circuit. For services and how they are bound to an AC. For example, a single AC
example, a single attachment circuit may be used to host multiple may be used to host multiple connectivity services. In order to
connectivity services. In order to avoid service interference and avoid service interference and redundant information in various
redundant information in various locations, a service provider may locations, a service provider may expose an interface to manage ACs
expose an interface to manage ACs network-wide. Customers can then network-wide. Customers can then request a bearer or an AC to be put
request a bearer or an attachment circuit to be put in place and then in place and then refer to that bearer or AC when requesting services
refer to that bearer or AC when requesting services that are bound to that are bound to the bearer or AC. [RFC9836] specifies
the bearer or AC. [RFC9836] specifies augmentations to the L2SM and augmentations to the L2SM and the L3SM to bind LxVPN services to ACs.
the L3SM to bind LxVPN services to ACs.
4.3. Sample Deployment Models 4.3. Sample Deployment Models
Figure 3 illustrates an example of how the bearer/AC service models Figure 3 illustrates an example of how the bearer/AC service models
can be used between a customer and a provider. Internals to the can be used between a customer and a provider. Internals to the
provider orchestration domain (or customer orchestration domain) are provider orchestration domain (or customer orchestration domain) are
hidden to the customer (or provider). hidden to the customer (or provider).
Resources that are needed to activate an AC (e.g., Layer 2 or Layer 3 Resources that are needed to activate an AC (e.g., Layer 2 or Layer 3
identifiers) are typically imposed by the provider. However, the identifiers) are typically imposed by the provider. However, the
skipping to change at line 626 skipping to change at line 620
Models | | | Models | | |
.---+---. | | .---+---. | |
| Config | | | | Config | | |
| Manager | | | | Manager | | |
'---+---' | | '---+---' | |
| | | | | |
NETCONF/CLI....................... NETCONF/CLI.......................
| | | | | |
.--------------------------------. .--------------------------------.
.---. Bearer | | Bearer .---. .---. Bearer | | Bearer .---.
|CE#1+--------+ Network +--------+CE#2| |CE1 +--------+ Network +--------+ CE2|
'---' | | '---' '---' | | '---'
'--------------------------------' '--------------------------------'
Site A Site B Site A Site B
Figure 5: An Example of AC Model Usage (Focus on the Provider's Figure 5: An Example of AC Model Usage (Focus on the Provider's
Internals) Internals)
In order to ease the mapping between the service model and underlying In order to ease the mapping between the service model and underlying
network models (e.g., the L3VPN Network Model (L3NM) and SAP), the network models (e.g., the L3VPN Network Model (L3NM) and SAP), the
name conventions used in existing network data models are reused as name conventions used in existing network data models are reused as
skipping to change at line 777 skipping to change at line 771
protocols (e.g., Link Layer Discovery Protocol (LLDP) protocols (e.g., Link Layer Discovery Protocol (LLDP)
[IEEE802.1AB]) to automatically discover and connect to available [IEEE802.1AB]) to automatically discover and connect to available
network resources. A network controller can use such reported network resources. A network controller can use such reported
information to expose discovered bearers from the network using information to expose discovered bearers from the network using
the same bearer data model structure. the same bearer data model structure.
A request to create a bearer may include a set of constraints A request to create a bearer may include a set of constraints
('placement-constraints') that are used by a controller to decide the ('placement-constraints') that are used by a controller to decide the
network terminating side of a bearer (e.g., PE selection, PE network terminating side of a bearer (e.g., PE selection, PE
redundancy, or PoP selection). Future placement criteria redundancy, or PoP selection). Future placement criteria
('constraint-type') may be defined in the future to accommodate ('constraint-type') may be defined to accommodate specific deployment
specific deployment contexts. A request may also include some timing contexts. A request may also include some timing constraints
constraints ('requested-start', 'requested-stop') that are applicable ('requested-start', 'requested-stop') that are applicable for a set
for a set of bearers. The timing constraints can be adjusted at the of bearers. The timing constraints can be adjusted at the 'bearer'
'bearer' level. These adjusted values take precedence over the level. These adjusted values take precedence over the global values.
global values.
The descriptions of the bearer data nodes are as follows: The descriptions of the bearer data nodes are as follows:
'name': Used to uniquely identify a bearer. This name is typically 'name': Used to uniquely identify a bearer. This name is typically
selected by the client when requesting a bearer. selected by the client when requesting a bearer.
'customer-name': Indicates the name of the customer who ordered the 'customer-name': Indicates the name of the customer who ordered the
bearer. bearer.
'description': Includes a textual description of the bearer. 'description': Includes a textual description of the bearer.
skipping to change at line 823 skipping to change at line 816
set to 'true'. set to 'true'.
'sync-phy-type': Specifies the Sync PHY mechanism (e.g., SyncE 'sync-phy-type': Specifies the Sync PHY mechanism (e.g., SyncE
[ITU-T-G.781]) enabled for the bearer. [ITU-T-G.781]) enabled for the bearer.
'provider-location-reference': Indicates a location identified by a 'provider-location-reference': Indicates a location identified by a
provider-assigned reference. provider-assigned reference.
'customer-point': Specifies the customer termination point for the 'customer-point': Specifies the customer termination point for the
bearer. A bearer request can indicate a device, a site, a bearer. A bearer request can indicate a device, a site, a
combination thereof, or custom information when requesting a combination thereof, or custom information. All these schemes are
bearer. All these schemes are supported in the model. supported in the model.
'type': Specifies the bearer type (Ethernet, wireless, LAG, etc.). 'type': Specifies the bearer type (Ethernet, wireless, LAG, etc.).
'test-only': Indicates that a request is only for test validation 'test-only': Indicates that a request is only for test validation
and not for enforcement, even if there are no errors. This is and not for enforcement, even if there are no errors. This is
used for feasibility checks. This data node is applicable only used for feasibility checks. This data node is applicable only
when the data model is used with protocols that do not natively when the data model is used with protocols that do not have built-
support such option. For example, this data node is redundant in support of such option. For example, this data node is
with the "test-only" value of the <test-option> parameter in the redundant with the "test-only" value of the <test-option>
NETCONF <edit-config> operation (Section 7.2 of [RFC6241]). parameter in the NETCONF <edit-config> operation (Section 7.2 of
[RFC6241]).
'bearer-reference': Returns an internal reference for the service 'bearer-reference': Returns an internal reference for the service
provider to uniquely identify the bearer. This reference can be provider to uniquely identify the bearer. This reference can be
used when requesting services. Appendix A.1 provides an example used when requesting services. Appendix A.1 provides an example
about how this reference can be retrieved by a customer. about how this reference can be retrieved by a customer.
Whether the 'bearer-reference' mirrors the content of the 'name' Whether the 'bearer-reference' mirrors the content of the 'name'
is deployment-specific. The module does not assume nor preclude is deployment-specific. The module does not assume nor preclude
such schemes. such schemes.
'ac-svc-ref': Specifies the set of attachment circuits that are 'ac-svc-ref': Specifies the set of ACs that are bound to the bearer.
bound to the bearer.
'requested-start': Specifies the requested date and time when the 'requested-start': Specifies the requested date and time when the
bearer is expected to be active. bearer is expected to be active.
'requested-stop': Specifies the requested date and time when the 'requested-stop': Specifies the requested date and time when the
bearer is expected to be disabled. bearer is expected to be disabled.
'actual-start': Reports the actual date and time when the bearer 'actual-start': Reports the actual date and time when the bearer was
actually was enabled. enabled.
'actual-stop': Reports the actual date and time when the bearer 'actual-stop': Reports the actual date and time when the bearer was
actually was disabled. disabled.
'status': Used to track the overall status of a given bearer. Both 'status': Used to track the overall status of a given bearer. Both
the operational and administrative status are maintained together the operational and administrative status are maintained together
with a timestamp. with a timestamp.
The 'admin-status' attribute is typically configured by a network The 'admin-status' attribute is typically configured by a network
operator to indicate whether the service is enabled, disabled, or operator to indicate whether the service is enabled, disabled, or
subjected to additional testing or pre-deployment checks. These subjected to additional testing or pre-deployment checks. These
additional options, such as 'admin-testing' and 'admin-pre- additional options, such as 'admin-testing' and 'admin-pre-
deployment', provide the operators the flexibility to conduct deployment', provide the operators the flexibility to conduct
skipping to change at line 1048 skipping to change at line 1041
'forwarding-profile-identifier': Refers to the policies that apply 'forwarding-profile-identifier': Refers to the policies that apply
to the forwarding of packets conveyed within an AC. Such policies to the forwarding of packets conveyed within an AC. Such policies
may consist, for example, of applying Access Control Lists (ACLs). may consist, for example, of applying Access Control Lists (ACLs).
'routing-profile-identifier': Refers to a set of routing policies 'routing-profile-identifier': Refers to a set of routing policies
that will be invoked (e.g., BGP policies) when building an AC. that will be invoked (e.g., BGP policies) when building an AC.
5.2.2.2. Referencing Service/Specific Profiles 5.2.2.2. Referencing Service/Specific Profiles
All the above mentioned profiles are uniquely identified by the All the above mentioned profiles are uniquely identified by the
provider server by an identifier. To ease referencing these profiles provider server. To ease referencing these profiles by other data
by other data models, specific typedefs are defined for each of these models, specific typedefs are defined for each of these profiles.
profiles. Likewise, an attachment circuit reference typedef is Likewise, an AC reference typedef is defined when referencing a
defined when referencing a (global) attachment circuit by its name is (global) AC by its name is required. These typedefs SHOULD be used
required. These typedefs SHOULD be used when other modules need a when other modules need a reference to one of these profiles or ACs.
reference to one of these profiles or attachment circuits.
5.2.3. Attachment Circuits Profiles 5.2.3. Attachment Circuits Profiles
The 'ac-group-profile' defines reusable parameters for a set of ACs. The 'ac-group-profile' defines reusable parameters for a set of ACs.
Each profile is identified by 'name'. Some of the data nodes can be Each profile is identified by 'name'. Some of the data nodes can be
adjusted at the 'ac' level. These adjusted values take precedence adjusted at the 'ac' level. These adjusted values take precedence
over the global values. The structure of 'ac-group-profile' is over the global values. The structure of 'ac-group-profile' is
similar to the one used to model each 'ac' (Figure 10). similar to the one used to model each 'ac' (Figure 10).
5.2.4. AC Placement Constraints 5.2.4. AC Placement Constraints
skipping to change at line 1171 skipping to change at line 1163
AC or a set of ACs. AC or a set of ACs.
'description': Includes a textual description of the AC. 'description': Includes a textual description of the AC.
'test-only': Indicates that a request is only for a validation test 'test-only': Indicates that a request is only for a validation test
and not for enforcement, even if there are no errors. This is and not for enforcement, even if there are no errors. This is
used for feasibility checks. This data node is applicable only used for feasibility checks. This data node is applicable only
when the data model is used with protocols that do not have built- when the data model is used with protocols that do not have built-
in support of such option. in support of such option.
'requested-start': Specifies the requested date and time when the 'requested-start': Specifies the requested date and time when the AC
attachment circuit is expected to be active. is expected to be active.
'requested-stop': Specifies the requested date and time when the 'requested-stop': Specifies the requested date and time when the AC
attachment circuit is expected to be disabled. is expected to be disabled.
'actual-start': Reports the actual date and time when the attachment 'actual-start': Reports the actual date and time when the AC was
circuit actually was enabled. enabled.
'actual-stop': Reports the actual date and time when the attachment 'actual-stop': Reports the actual date and time when the AC was
circuit actually was disabled. disabled.
'role': Specifies whether an AC is used, e.g., as User-to-Network 'role': Specifies whether an AC is used, e.g., as User-to-Network
Interface (UNI) or Network-to-Network Interface (NNI). Interface (UNI) or Network-to-Network Interface (NNI).
'peer-sap-id': Includes references to the remote endpoints of an 'peer-sap-id': Includes references to the remote endpoints of an AC
attachment circuit [RFC9408]. 'peer' is drawn here from the [RFC9408]. 'peer' is drawn here from the perspective of the
perspective of the provider network. That is, a 'peer-sap' will provider network. That is, a 'peer-sap' will refer to a customer
refer to a customer node. node.
'group-profile-ref': Indicates references to one or more profiles 'group-profile-ref': Indicates references to one or more profiles
that are defined in Section 5.2.3. that are defined in Section 5.2.3.
'parent-ref': Specifies an AC that is inherited by an attachment 'parent-ref': Specifies an AC that is inherited by an AC.
circuit.
In contexts where dynamic termination points are managed for a In contexts where dynamic termination points are managed for a
given AC, a parent AC can be defined with a set of stable and given AC, a Parent AC can be defined with a set of stable and
common information, while "child" ACs are defined to track dynamic common information, while Child ACs are defined to track dynamic
information. These "child" ACs are bound to the parent AC, which information. These Child ACs are bound to the Parent AC, which is
is exposed to services (as a stable reference). exposed to services (as a stable reference).
Whenever a parent AC is deleted, all its "child" ACs MUST be Whenever a Parent AC is deleted, all its Child ACs MUST be
deleted. deleted.
A "child" AC MAY rely upon more than one parent AC (e.g., parent A Child AC MAY rely upon more than one Parent AC (e.g., parent
Layer 2 AC and parent Layer 3 AC). In such cases, these ACs MUST Layer 2 AC and parent Layer 3 AC). In such cases, these ACs MUST
NOT be overlapping. An example to illustrate the use of multiple NOT be overlapping. An example to illustrate the use of multiple
parent ACs is provided in Appendix A.12. Parent ACs is provided in Appendix A.12.
'child-ref': Lists one or more references of child ACs that rely 'child-ref': Lists one or more references of Child ACs that rely
upon this attachment circuit as a parent AC. upon this AC as a Parent AC.
'group': Lists the groups to which an AC belongs [RFC9181]. For 'group': Lists the groups to which an AC belongs [RFC9181]. For
example, the 'group-id' is used to associate redundancy or example, the 'group-id' is used to associate redundancy or
protection constraints of ACs. An example is provided in protection constraints of ACs. An example is provided in
Appendix A.5. Appendix A.5.
'service-ref': Reports the set of services that are bound to the 'service-ref': Reports the set of services that are bound to the AC.
attachment circuit. The services are indexed by their type. The services are indexed by their type.
'server-reference': Reports the internal reference that is assigned 'server-reference': Reports the internal reference that is assigned
by the provider for this AC. This reference is used to by the provider for this AC. This reference is used to
accommodate deployment contexts (e.g., Section 9.1.2 of [RFC8921]) accommodate deployment contexts (e.g., Section 9.1.2 of [RFC8921])
where an identifier is generated by the provider to identify a where an identifier is generated by the provider to identify a
service order locally. service order locally.
'name': Associates a name that uniquely identifies an AC within a 'name': Associates a name that uniquely identifies an AC within a
service provider network. service provider network.
skipping to change at line 1577 skipping to change at line 1568
'failure-detection-profile': Indicates a failure detection profile 'failure-detection-profile': Indicates a failure detection profile
(e.g., BFD) that applies for this entry. (e.g., BFD) that applies for this entry.
'status': Used to convey the status of a static route entry. This 'status': Used to convey the status of a static route entry. This
data node can also be used to control the (de)activation of data node can also be used to control the (de)activation of
individual static route entries. individual static route entries.
5.2.5.3.2. BGP 5.2.5.3.2. BGP
An AC service activation with BGP routing SHOULD include at least the An AC service activation with BGP routing [RFC4271] SHOULD include at
customer's AS Number (ASN) and the provider's ASN. Additional least the customer's AS Number (ASN) and the provider's ASN.
information can be supplied by a customer in a request or exposed by Additional information can be supplied by a customer in a request or
a provider in a response to a query request in order to ease the exposed by a provider in a response to a query request in order to
process of automating the provisioning of BGP sessions (the customer ease the process of automating the provisioning of BGP sessions (the
does not use the primary IP address to establish the underlying BGP customer does not use the primary IP address to establish the
session, communicate the provider's IP address used to establish the underlying BGP session, communicate the provider's IP address used to
BGP session, share authentication parameters, bind the session to a establish the BGP session, share authentication parameters, bind the
forwarding protection profile, etc.). session to a forwarding protection profile, etc.).
The BGP tree structure is shown in Figure 16. The BGP tree structure is shown in Figure 16.
| ... | ...
+--rw routing-protocols +--rw routing-protocols
| +--rw routing-protocol* [id] | +--rw routing-protocol* [id]
| +--rw id string | +--rw id string
| +--rw type? identityref | +--rw type? identityref
| +--rw routing-profiles* [id] | +--rw routing-profiles* [id]
| | +--rw id routing-profile-reference | | +--rw id routing-profile-reference
skipping to change at line 1750 skipping to change at line 1741
establish this BGP session. If not present, this means that the establish this BGP session. If not present, this means that the
primary customer IP address is used as the remote IP address. primary customer IP address is used as the remote IP address.
'requested-start': Specifies the requested date and time when the 'requested-start': Specifies the requested date and time when the
BGP session is expected to be active. BGP session is expected to be active.
'requested-stop': Specifies the requested date and time when the BGP 'requested-stop': Specifies the requested date and time when the BGP
session is expected to be disabled. session is expected to be disabled.
'actual-start': Reports the actual date and time when the BGP 'actual-start': Reports the actual date and time when the BGP
session actually was enabled. session was enabled.
'actual-stop': Reports the actual date and time when the BGP session 'actual-stop': Reports the actual date and time when the BGP session
actually was disabled. was disabled.
'status': Indicates the status of the BGP routing instance. 'status': Indicates the status of the BGP routing instance.
'peer-group': Specifies a name of a peer group. 'peer-group': Specifies a name of a peer group.
Parameters that are provided at the 'neighbor' level take Parameters that are provided at the 'neighbor' level take
precedence over the ones provided in the peer group. precedence over the ones provided in the peer group.
This is an optional parameter. This is an optional parameter.
skipping to change at line 2237 skipping to change at line 2228
VPNs"; VPNs";
} }
import ietf-ac-common { import ietf-ac-common {
prefix ac-common; prefix ac-common;
reference reference
"RFC 9833: A Common YANG Data Model for Attachment Circuits"; "RFC 9833: A Common YANG Data Model for Attachment Circuits";
} }
import ietf-ac-svc { import ietf-ac-svc {
prefix ac-svc; prefix ac-svc;
reference reference
"RFC 9834: YANG Data Models for Bearers and 'Attachment "RFC 9834: YANG Data Models for Bearers and Attachment
Circuits'-as-a-Service (ACaaS)"; Circuits as a Service (ACaaS)";
} }
organization organization
"IETF OPSAWG (Operations and Management Area Working Group)"; "IETF OPSAWG (Operations and Management Area Working Group)";
contact contact
"WG Web: <https://datatracker.ietf.org/wg/opsawg/> "WG Web: <https://datatracker.ietf.org/wg/opsawg/>
WG List: <mailto:opsawg@ietf.org> WG List: <mailto:opsawg@ietf.org>
Editor: Mohamed Boucadair Editor: Mohamed Boucadair
<mailto:mohamed.boucadair@orange.com> <mailto:mohamed.boucadair@orange.com>
Author: Richard Roberts Editor: Richard Roberts
<mailto:rroberts@juniper.net> <mailto:rroberts@juniper.net>
Author: Oscar Gonzalez de Dios Author: Oscar Gonzalez de Dios
<mailto:oscar.gonzalezdedios@telefonica.com> <mailto:oscar.gonzalezdedios@telefonica.com>
Author: Samier Barguil Author: Samier Barguil
<mailto:ssamier.barguil_giraldo@nokia.com> <mailto:ssamier.barguil_giraldo@nokia.com>
Author: Bo Wu Author: Bo Wu
<mailto:lana.wubo@huawei.com>"; <mailto:lana.wubo@huawei.com>";
description description
"This YANG module defines a generic YANG module for exposing "This YANG module defines a generic YANG module for exposing
network bearers as a service. network bearers as a service.
skipping to change at line 2278 skipping to change at line 2269
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 xxx; see the This version of this YANG module is part of RFC xxx; see the
RFC itself for full legal notices."; RFC itself for full legal notices.";
revision 2025-08-11 { revision 2025-08-11 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC 9834: YANG Data Models for Bearers and 'Attachment "RFC 9834: YANG Data Models for Bearers and Attachment
Circuits'-as-a-Service (ACaaS)"; Circuits as a Service (ACaaS)";
} }
// Identities // Identities
identity identification-type { identity identification-type {
description description
"Base identity for identification of bearers."; "Base identity for identification of bearers.";
} }
identity device-id { identity device-id {
skipping to change at line 2733 skipping to change at line 2724
} }
organization organization
"IETF OPSAWG (Operations and Management Area Working Group)"; "IETF OPSAWG (Operations and Management Area Working Group)";
contact contact
"WG Web: <https://datatracker.ietf.org/wg/opsawg/> "WG Web: <https://datatracker.ietf.org/wg/opsawg/>
WG List: <mailto:opsawg@ietf.org> WG List: <mailto:opsawg@ietf.org>
Editor: Mohamed Boucadair Editor: Mohamed Boucadair
<mailto:mohamed.boucadair@orange.com> <mailto:mohamed.boucadair@orange.com>
Author: Richard Roberts Editor: Richard Roberts
<mailto:rroberts@juniper.net> <mailto:rroberts@juniper.net>
Author: Oscar Gonzalez de Dios Author: Oscar Gonzalez de Dios
<mailto:oscar.gonzalezdedios@telefonica.com> <mailto:oscar.gonzalezdedios@telefonica.com>
Author: Samier Barguil Author: Samier Barguil
<mailto:ssamier.barguil_giraldo@nokia.com> <mailto:ssamier.barguil_giraldo@nokia.com>
Author: Bo Wu Author: Bo Wu
<mailto:lana.wubo@huawei.com>"; <mailto:lana.wubo@huawei.com>";
description description
"This YANG module defines a YANG module for exposing "This YANG module defines a YANG module for exposing
'Attachment Circuits'-as-a-Service (ACaaS). Attachment Circuits as a Service (ACaaS).
Copyright (c) 2025 IETF Trust and the persons identified as Copyright (c) 2025 IETF Trust and the persons identified as
authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject without modification, is permitted pursuant to, and subject
to the license terms contained in, the Revised BSD License to the license terms contained in, the Revised BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions set 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 9834; see the This version of this YANG module is part of RFC 9834; see the
RFC itself for full legal notices."; RFC itself for full legal notices.";
revision 2025-08-11 { revision 2025-08-11 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC 9834: YANG Data Models for Bearers and 'Attachment "RFC 9834: YANG Data Models for Bearers and Attachment
Circuits'-as-a-Service (ACaaS)"; Circuits as a Service (ACaaS)";
} }
/* A set of typedefs to ease referencing cross-modules */ /* A set of typedefs to ease referencing cross-modules */
typedef attachment-circuit-reference { typedef attachment-circuit-reference {
type leafref { type leafref {
path "/ac-svc:attachment-circuits/ac-svc:ac/ac-svc:name"; path "/ac-svc:attachment-circuits/ac-svc:ac/ac-svc:name";
} }
description description
"Defines a reference to an attachment circuit that can be used "Defines a reference to an AC that can be used by other
by other modules."; modules.";
} }
typedef ac-group-reference { typedef ac-group-reference {
type leafref { type leafref {
path "/ac-svc:attachment-circuits/ac-svc:ac-group-profile" path "/ac-svc:attachment-circuits/ac-svc:ac-group-profile"
+ "/ac-svc:name"; + "/ac-svc:name";
} }
description description
"Defines a reference to an attachment circuit profile."; "Defines a reference to an AC profile.";
} }
typedef encryption-profile-reference { typedef encryption-profile-reference {
type leafref { type leafref {
path "/ac-svc:specific-provisioning-profiles" path "/ac-svc:specific-provisioning-profiles"
+ "/ac-svc:valid-provider-identifiers" + "/ac-svc:valid-provider-identifiers"
+ "/ac-svc:encryption-profile-identifier/ac-svc:id"; + "/ac-svc:encryption-profile-identifier/ac-svc:id";
} }
description description
"Defines a reference to an encryption profile."; "Defines a reference to an encryption profile.";
skipping to change at line 3606 skipping to change at line 3597
bandwidth of the AC or upload bandwidth from bandwidth of the AC or upload bandwidth from
the CE to the PE."; the CE to the PE.";
uses ac-common:bandwidth-per-type; uses ac-common:bandwidth-per-type;
} }
} }
// Basic AC parameters // Basic AC parameters
grouping ac-basic { grouping ac-basic {
description description
"Grouping for basic parameters for an attachment circuit."; "Grouping for basic parameters for an AC.";
leaf name { leaf name {
type string; type string;
description description
"A name that uniquely identifies the AC."; "A name that uniquely identifies the AC.";
} }
container l2-connection { container l2-connection {
if-feature "ac-common:layer2-ac"; if-feature "ac-common:layer2-ac";
description description
"Defines Layer 2 protocols and parameters that are required "Defines Layer 2 protocols and parameters that are required
to enable AC connectivity."; to enable AC connectivity.";
skipping to change at line 3663 skipping to change at line 3654
"Layer 2 MTU."; "Layer 2 MTU.";
} }
uses bandwidth; uses bandwidth;
} }
} }
// Full AC parameters // Full AC parameters
grouping ac { grouping ac {
description description
"Grouping for an attachment circuit."; "Grouping for an AC.";
leaf name { leaf name {
type string; type string;
description description
"A name of the AC. Data models that need to reference "A name of the AC. Data models that need to reference
an AC should use 'attachment-circuit-reference'."; an AC should use 'attachment-circuit-reference'.";
} }
leaf-list service-profile { leaf-list service-profile {
type service-profile-reference; type service-profile-reference;
description description
"A reference to a service profile."; "A reference to a service profile.";
skipping to change at line 3795 skipping to change at line 3786
} }
} }
} }
} }
} }
// Parent and Child ACs // Parent and Child ACs
grouping ac-hierarchy { grouping ac-hierarchy {
description description
"Container for parent and child AC references."; "Container for parent and Child AC references.";
leaf-list parent-ref { leaf-list parent-ref {
type ac-svc:attachment-circuit-reference; type ac-svc:attachment-circuit-reference;
description description
"Specifies a parent AC that is inherited by an AC. "Specifies a Parent AC that is inherited by an AC.
In contexts where dynamic termination points are In contexts where dynamic termination points are
bound to the same AC, a parent AC with stable bound to the same AC, a Parent AC with stable
information is created with a set of child ACs information is created with a set of Child ACs
to track dynamic AC information."; to track dynamic AC information.";
} }
leaf-list child-ref { leaf-list child-ref {
type ac-svc:attachment-circuit-reference; type ac-svc:attachment-circuit-reference;
config false; config false;
description description
"Specifies a child AC that relies upon a parent AC."; "Specifies a Child AC that relies upon a Parent AC.";
} }
} }
/******************** Main AC containers ********************/ /******************** Main AC containers ********************/
container specific-provisioning-profiles { container specific-provisioning-profiles {
description description
"Contains a set of valid profiles to reference for an AC."; "Contains a set of valid profiles to reference for an AC.";
uses ac-common:ac-profile-cfg; uses ac-common:ac-profile-cfg;
} }
skipping to change at line 3839 skipping to change at line 3830
description description
"Identification of the service profile to be used. "Identification of the service profile to be used.
The profile only has significance within the service The profile only has significance within the service
provider's administrative domain."; provider's administrative domain.";
} }
} }
nacm:default-deny-write; nacm:default-deny-write;
} }
container attachment-circuits { container attachment-circuits {
description description
"Main container for the attachment circuits. "Main container for the ACs.
The timing constraints indicated at the 'ac' level take The timing constraints indicated at the 'ac' level take
precedence over the values indicated at the precedence over the values indicated at the
'attachment-circuits' level."; 'attachment-circuits' level.";
list ac-group-profile { list ac-group-profile {
key "name"; key "name";
description description
"Maintains a list of profiles that are shared among "Maintains a list of profiles that are shared among
a set of ACs."; a set of ACs.";
uses ac; uses ac;
} }
skipping to change at line 3865 skipping to change at line 3856
leaf customer-name { leaf customer-name {
type string; type string;
description description
"Indicates the name of the customer that requested these "Indicates the name of the customer that requested these
ACs."; ACs.";
} }
uses ac-common:op-instructions; uses ac-common:op-instructions;
list ac { list ac {
key "name"; key "name";
description description
"Provisioning of an attachment circuit."; "Provisioning of an AC.";
leaf customer-name { leaf customer-name {
type string; type string;
description description
"Indicates the name of the customer that requested this "Indicates the name of the customer that requested this
AC."; AC.";
} }
leaf description { leaf description {
type string; type string;
description description
"Associates a description with an AC."; "Associates a description with an AC.";
skipping to change at line 3914 skipping to change at line 3905
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 3934
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 This section is modeled after the template described in Section 3.7.1
of [YANG-GUIDELINES]. 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
skipping to change at line 4032 skipping to change at line 4023
'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.
There are no particularly sensitive RPC or action operations.
Several data nodes ('bgp', 'ospf', 'isis', 'rip', and 'customer-key- Several data nodes ('bgp', 'ospf', 'isis', 'rip', and 'customer-key-
chain') rely upon [RFC8177] for authentication purposes. As such, chain') rely upon the key chains described in [RFC8177] for
the AC service module inherits the security considerations discussed authentication purposes. As such, the AC service module inherits the
in Section 5 of [RFC8177]. Also, these data nodes support supplying security considerations discussed in Section 5 of [RFC8177]. Also,
explicit keys as strings in ASCII format. The use of keys in these data nodes support supplying explicit keys as strings in ASCII
hexadecimal string format would afford greater key entropy with the format. The use of keys in hexadecimal string format would afford
same number of key-string octets. However, such a format is not greater key entropy with the same number of key-string octets.
included in this version of the AC service model because it is not However, such a format is not included in this version of the AC
supported by the underlying device modules (e.g., [RFC8695]). 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 Section 5.2.5.5 specifies a set of encryption-related parameters that
can be applied to traffic for a given AC. 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
skipping to change at line 4087 skipping to change at line 4081
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004, DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>. <https://www.rfc-editor.org/info/rfc3688>.
[RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Authentication Protocol", RFC 4252, DOI 10.17487/RFC4252, Border Gateway Protocol 4 (BGP-4)", RFC 4271,
January 2006, <https://www.rfc-editor.org/info/rfc4252>. DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/info/rfc4271>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
2006, <https://www.rfc-editor.org/info/rfc4364>. 2006, <https://www.rfc-editor.org/info/rfc4364>.
[RFC4577] Rosen, E., Psenak, P., and P. Pillay-Esnault, "OSPF as the [RFC4577] Rosen, E., Psenak, P., and P. Pillay-Esnault, "OSPF as the
Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Provider/Customer Edge Protocol for BGP/MPLS IP Virtual
Private Networks (VPNs)", RFC 4577, DOI 10.17487/RFC4577, Private Networks (VPNs)", RFC 4577, DOI 10.17487/RFC4577,
June 2006, <https://www.rfc-editor.org/info/rfc4577>. June 2006, <https://www.rfc-editor.org/info/rfc4577>.
skipping to change at line 4114 skipping to change at line 4109
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
<https://www.rfc-editor.org/info/rfc5880>. <https://www.rfc-editor.org/info/rfc5880>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020, the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010, DOI 10.17487/RFC6020, October 2010,
<https://www.rfc-editor.org/info/rfc6020>. <https://www.rfc-editor.org/info/rfc6020>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>.
[RFC6565] Pillay-Esnault, P., Moyer, P., Doyle, J., Ertekin, E., and [RFC6565] Pillay-Esnault, P., Moyer, P., Doyle, J., Ertekin, E., and
M. Lundberg, "OSPFv3 as a Provider Edge to Customer Edge M. Lundberg, "OSPFv3 as a Provider Edge to Customer Edge
(PE-CE) Routing Protocol", RFC 6565, DOI 10.17487/RFC6565, (PE-CE) Routing Protocol", RFC 6565, DOI 10.17487/RFC6565,
June 2012, <https://www.rfc-editor.org/info/rfc6565>. June 2012, <https://www.rfc-editor.org/info/rfc6565>.
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
RFC 6991, DOI 10.17487/RFC6991, July 2013, RFC 6991, DOI 10.17487/RFC6991, July 2013,
<https://www.rfc-editor.org/info/rfc6991>. <https://www.rfc-editor.org/info/rfc6991>.
[RFC7166] Bhatia, M., Manral, V., and A. Lindem, "Supporting [RFC7166] Bhatia, M., Manral, V., and A. Lindem, "Supporting
Authentication Trailer for OSPFv3", RFC 7166, Authentication Trailer for OSPFv3", RFC 7166,
DOI 10.17487/RFC7166, March 2014, DOI 10.17487/RFC7166, March 2014,
<https://www.rfc-editor.org/info/rfc7166>. <https://www.rfc-editor.org/info/rfc7166>.
[RFC7474] Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, Ed., [RFC7474] Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, Ed.,
"Security Extension for OSPFv2 When Using Manual Key "Security Extension for OSPFv2 When Using Manual Key
Management", RFC 7474, DOI 10.17487/RFC7474, April 2015, Management", RFC 7474, DOI 10.17487/RFC7474, April 2015,
<https://www.rfc-editor.org/info/rfc7474>. <https://www.rfc-editor.org/info/rfc7474>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8177] Lindem, A., Ed., Qu, Y., Yeung, D., Chen, I., and J. [RFC8177] Lindem, A., Ed., Qu, Y., Yeung, D., Chen, I., and J.
Zhang, "YANG Data Model for Key Chains", RFC 8177, Zhang, "YANG Data Model for Key Chains", RFC 8177,
DOI 10.17487/RFC8177, June 2017, DOI 10.17487/RFC8177, June 2017,
<https://www.rfc-editor.org/info/rfc8177>. <https://www.rfc-editor.org/info/rfc8177>.
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
Access Control Model", STD 91, RFC 8341, Access Control Model", STD 91, RFC 8341,
DOI 10.17487/RFC8341, March 2018, DOI 10.17487/RFC8341, March 2018,
<https://www.rfc-editor.org/info/rfc8341>. <https://www.rfc-editor.org/info/rfc8341>.
[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
and R. Wilton, "Network Management Datastore Architecture and R. Wilton, "Network Management Datastore Architecture
(NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,
<https://www.rfc-editor.org/info/rfc8342>. <https://www.rfc-editor.org/info/rfc8342>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu, [RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu,
"Handling Long Lines in Content of Internet-Drafts and "Handling Long Lines in Content of Internet-Drafts and
RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020, RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020,
<https://www.rfc-editor.org/info/rfc8792>. <https://www.rfc-editor.org/info/rfc8792>.
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/info/rfc9000>.
[RFC9181] Barguil, S., Gonzalez de Dios, O., Ed., Boucadair, M., [RFC9181] Barguil, S., Gonzalez de Dios, O., Ed., Boucadair, M.,
Ed., and Q. Wu, "A Common YANG Data Model for Layer 2 and Ed., and Q. Wu, "A Common YANG Data Model for Layer 2 and
Layer 3 VPNs", RFC 9181, DOI 10.17487/RFC9181, February Layer 3 VPNs", RFC 9181, DOI 10.17487/RFC9181, February
2022, <https://www.rfc-editor.org/info/rfc9181>. 2022, <https://www.rfc-editor.org/info/rfc9181>.
[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/info/rfc9182>. February 2022, <https://www.rfc-editor.org/info/rfc9182>.
skipping to change at line 4201 skipping to change at line 4178
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, September 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 4277 skipping to change at line 4253
[RFC3644] Snir, Y., Ramberg, Y., Strassner, J., Cohen, R., and B. [RFC3644] Snir, Y., Ramberg, Y., Strassner, J., Cohen, R., and B.
Moore, "Policy Quality of Service (QoS) Information Moore, "Policy Quality of Service (QoS) Information
Model", RFC 3644, DOI 10.17487/RFC3644, November 2003, Model", RFC 3644, DOI 10.17487/RFC3644, November 2003,
<https://www.rfc-editor.org/info/rfc3644>. <https://www.rfc-editor.org/info/rfc3644>.
[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>.
[RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Authentication Protocol", RFC 4252, DOI 10.17487/RFC4252,
January 2006, <https://www.rfc-editor.org/info/rfc4252>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007, DOI 10.17487/RFC4861, September 2007,
<https://www.rfc-editor.org/info/rfc4861>. <https://www.rfc-editor.org/info/rfc4861>.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", RFC 5925, DOI 10.17487/RFC5925, Authentication Option", RFC 5925, DOI 10.17487/RFC5925,
June 2010, <https://www.rfc-editor.org/info/rfc5925>. June 2010, <https://www.rfc-editor.org/info/rfc5925>.
[RFC6151] Turner, S. and L. Chen, "Updated Security Considerations [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations
for the MD5 Message-Digest and the HMAC-MD5 Algorithms", for the MD5 Message-Digest and the HMAC-MD5 Algorithms",
RFC 6151, DOI 10.17487/RFC6151, March 2011, RFC 6151, DOI 10.17487/RFC6151, March 2011,
<https://www.rfc-editor.org/info/rfc6151>. <https://www.rfc-editor.org/info/rfc6151>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>.
[RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of
BGP, LDP, PCEP, and MSDP Issues According to the Keying BGP, LDP, PCEP, and MSDP Issues According to the Keying
and Authentication for Routing Protocols (KARP) Design and Authentication for Routing Protocols (KARP) Design
Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013,
<https://www.rfc-editor.org/info/rfc6952>. <https://www.rfc-editor.org/info/rfc6952>.
[RFC7607] Kumari, W., Bush, R., Schiller, H., and K. Patel, [RFC7607] Kumari, W., Bush, R., Schiller, H., and K. Patel,
"Codification of AS 0 Processing", RFC 7607, "Codification of AS 0 Processing", RFC 7607,
DOI 10.17487/RFC7607, August 2015, DOI 10.17487/RFC7607, August 2015,
<https://www.rfc-editor.org/info/rfc7607>. <https://www.rfc-editor.org/info/rfc7607>.
[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
Chaining (SFC) Architecture", RFC 7665, Chaining (SFC) Architecture", RFC 7665,
DOI 10.17487/RFC7665, October 2015, DOI 10.17487/RFC7665, October 2015,
<https://www.rfc-editor.org/info/rfc7665>. <https://www.rfc-editor.org/info/rfc7665>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>.
[RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, [RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki,
"YANG Data Model for L3VPN Service Delivery", RFC 8299, "YANG Data Model for L3VPN Service Delivery", RFC 8299,
DOI 10.17487/RFC8299, January 2018, DOI 10.17487/RFC8299, January 2018,
<https://www.rfc-editor.org/info/rfc8299>. <https://www.rfc-editor.org/info/rfc8299>.
[RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models
Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018,
<https://www.rfc-editor.org/info/rfc8309>. <https://www.rfc-editor.org/info/rfc8309>.
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
<https://www.rfc-editor.org/info/rfc8340>. <https://www.rfc-editor.org/info/rfc8340>.
[RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for [RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for
Routing Management (NMDA Version)", RFC 8349, Routing Management (NMDA Version)", RFC 8349,
DOI 10.17487/RFC8349, March 2018, DOI 10.17487/RFC8349, March 2018,
<https://www.rfc-editor.org/info/rfc8349>. <https://www.rfc-editor.org/info/rfc8349>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[RFC8466] Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG [RFC8466] Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG
Data Model for Layer 2 Virtual Private Network (L2VPN) Data Model for Layer 2 Virtual Private Network (L2VPN)
Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October
2018, <https://www.rfc-editor.org/info/rfc8466>. 2018, <https://www.rfc-editor.org/info/rfc8466>.
[RFC8695] Liu, X., Sarda, P., and V. Choudhary, "A YANG Data Model [RFC8695] Liu, X., Sarda, P., and V. Choudhary, "A YANG Data Model
for the Routing Information Protocol (RIP)", RFC 8695, for the Routing Information Protocol (RIP)", RFC 8695,
DOI 10.17487/RFC8695, February 2020, DOI 10.17487/RFC8695, February 2020,
<https://www.rfc-editor.org/info/rfc8695>. <https://www.rfc-editor.org/info/rfc8695>.
skipping to change at line 4346 skipping to change at line 4339
Georgatsos, "Dynamic Service Negotiation: The Connectivity Georgatsos, "Dynamic Service Negotiation: The Connectivity
Provisioning Negotiation Protocol (CPNP)", RFC 8921, Provisioning Negotiation Protocol (CPNP)", RFC 8921,
DOI 10.17487/RFC8921, October 2020, DOI 10.17487/RFC8921, October 2020,
<https://www.rfc-editor.org/info/rfc8921>. <https://www.rfc-editor.org/info/rfc8921>.
[RFC8969] Wu, Q., Ed., Boucadair, M., Ed., Lopez, D., Xie, C., and [RFC8969] Wu, Q., Ed., Boucadair, M., Ed., Lopez, D., Xie, C., and
L. Geng, "A Framework for Automating Service and Network L. Geng, "A Framework for Automating Service and Network
Management with YANG", RFC 8969, DOI 10.17487/RFC8969, Management with YANG", RFC 8969, DOI 10.17487/RFC8969,
January 2021, <https://www.rfc-editor.org/info/rfc8969>. January 2021, <https://www.rfc-editor.org/info/rfc8969>.
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/info/rfc9000>.
[RFC9234] Azimov, A., Bogomazov, E., Bush, R., Patel, K., and K. [RFC9234] Azimov, A., Bogomazov, E., Bush, R., Patel, K., and K.
Sriram, "Route Leak Prevention and Detection Using Roles Sriram, "Route Leak Prevention and Detection Using Roles
in UPDATE and OPEN Messages", RFC 9234, in UPDATE and OPEN Messages", RFC 9234,
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>. September 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, September 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,
<https://datatracker.ietf.org/doc/html/draft-ietf-netmod- <https://datatracker.ietf.org/doc/html/draft-ietf-netmod-
rfc8407bis-28>. rfc8407bis-28>.
skipping to change at line 4498 skipping to change at line 4496
} }
}, },
"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 5011
} }
} }
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 5282
] ]
} }
} }
] ]
} }
} }
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 Network 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 5324
"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 5413 skipping to change at line 5412
Physical Connection 1234-56789 is delivered and Physical Connection 1234-56789 is delivered and
connected to PE1 connected to PE1
Network Inventory Updated with: Network Inventory Updated with:
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 item 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 5475 skipping to change at line 5474
} }
Figure 46: Message Body of a Request to Create the ACs for Figure 46: Message Body of a Request to Create the ACs for
Connecting to the Cloud Provider Connecting to the Cloud Provider
Figure 47 shows the message body of the response received from the Figure 47 shows the message body of the response received from the
provider as a response to a query message. Note that this Cloud provider as a response to a query message. Note that this Cloud
Provider mandates the use of MD5 authentication for establishing BGP Provider mandates the use of MD5 authentication for establishing BGP
connections. connections.
The module supports MD5 to basically accommodate the installed BGP | The module supports MD5 to basically accommodate the installed
base (including by some Cloud Providers). Note that MD5 suffers | BGP base (including by some Cloud Providers). Note that MD5
from the security weaknesses discussed in Section 2 of [RFC6151] | suffers from the security weaknesses discussed in Section 2 of
and Section 2.1 of [RFC6952]. | [RFC6151] and Section 2.1 of [RFC6952].
=============== NOTE: '\' line wrapping per RFC 8792 ================ =============== NOTE: '\' line wrapping per RFC 8792 ================
{ {
"ietf-ac-svc:attachment-circuits": { "ietf-ac-svc:attachment-circuits": {
"ac": [ "ac": [
{ {
"name": "ac--BXT-DC-customer-VPC-foo", "name": "ac--BXT-DC-customer-VPC-foo",
"description": "Connection to Cloud Provider BXT on \ "description": "Connection to Cloud Provider BXT on \
connection 1234-56789", connection 1234-56789",
skipping to change at line 5577 skipping to change at line 5576
| . | | . |
| . | | . |
| . | | . |
| .------------. | | .------------. |
| | PEm(VRFmn) | | | | PEm(VRFmn) | |
| '------------' | | '------------' |
'------------------------' '------------------------'
Figure 48: Illustration of Provider Network Scenario Figure 48: Illustration of Provider Network Scenario
The attachment circuit in this case uses a SAP identifier to refer to The AC in this case uses a SAP identifier to refer to the physical
the physical interface used for the connection between the PE and the interface used for the connection between the PE and the CE. The AC
CE. The attachment circuit includes all the additional logical includes all the additional logical attributes to describe the
attributes to describe the connection between the two ends, including connection between the two ends, including VLAN information and IP
VLAN information and IP addressing. Also, the configuration details addressing. Also, the configuration details of the BGP session make
of the BGP session make use of peer group details instead of defining use of peer group details instead of defining the entire
the entire configuration inside the 'neighbor' data node. configuration inside the 'neighbor' data node.
{ {
"ietf-ac-svc:attachment-circuits": { "ietf-ac-svc:attachment-circuits": {
"ac": [ "ac": [
{ {
"name": "CE-PE-AC", "name": "CE-PE-AC",
"customer-name": "Customer-4875", "customer-name": "Customer-4875",
"description": "An AC between a CP and a PE", "description": "An AC between a CP and a PE",
"peer-sap-id": [ "peer-sap-id": [
"sap#113" "sap#113"
skipping to change at line 5711 skipping to change at line 5710
between two networks without involving an IXP. between two networks without involving an IXP.
A.10.1. Retrieve Interconnection Locations A.10.1. Retrieve Interconnection Locations
Figure 51 shows an example message body of a request to retrieve a Figure 51 shows an example message body of a request to retrieve a
list of interconnection locations. The request includes a customer list of interconnection locations. The request includes a customer
name and an ASN to filter out the locations. name and an ASN to filter out the locations.
{ {
"ietf-bearer-svc:locations": { "ietf-bearer-svc:locations": {
"filtered-by": "ietf-bearer-svc:customer-name",
"customer": [ "customer": [
{ {
"name": "a future peer", "name": "a future peer",
"peer-as": 65536 "peer-as": 65536
} }
] ]
} }
} }
Figure 51: Message Body of a Request to Retrieve Interconnection Figure 51: Message Body of a Request to Retrieve Interconnection
Locations Locations
Figure 52 provides an example of a response to a query received from Figure 52 provides an example of a response to a query received from
the server with a list of available interconnection locations. the server with a list of available interconnection locations.
{ {
"ietf-bearer-svc:locations": { "ietf-bearer-svc:locations": {
"filtered-by": "ietf-bearer-svc:customer-name",
"customer": [ "customer": [
{ {
"name": "a future peer", "name": "a future peer",
"peer-as": 65536, "peer-as": 65536,
"location": [ "location": [
{ {
"name": "Location-X", "name": "Location-X",
"_comment": "other location attributes" "_comment": "other location attributes"
}, },
{ {
skipping to change at line 6101 skipping to change at line 6098
Figure 60: Message Body of a Response to Report All Active BGP Figure 60: Message Body of a Response to Report All Active BGP
Sessions over an AC Sessions over an AC
A.11. Connectivity of Cloud Network Functions A.11. Connectivity of Cloud Network Functions
A.11.1. Scope A.11.1. Scope
This section demonstrates how the AC service model permits managing This section demonstrates how the AC service model permits managing
connectivity requirements for complex Network Functions (NFs) -- connectivity requirements for complex Network Functions (NFs) --
containerized or virtualized -- that are typically deployed in telco containerized or virtualized -- that are typically deployed in telco
networks. This integration leverages the concept of "parent AC" to networks. This integration leverages the concept of "Parent AC" to
decouple physical and logical connectivity so that several ACs can decouple physical and logical connectivity so that several ACs can
share Layer 2 and Layer 3 resources. This approach provides share Layer 2 and Layer 3 resources. This approach provides
flexibility, scalability, and API stability. flexibility, scalability, and API stability.
The NFs have the following characteristics: The NFs have the following characteristics:
* The NF is distributed on a set of compute nodes with scaled-out * The NF is distributed on a set of compute nodes with scaled-out
and redundant instances. and redundant instances.
* The NF has two distinct type of instances: user plane ("nf-up") * The NF has two distinct type of instances: user plane ("nf-up")
skipping to change at line 6134 skipping to change at line 6131
separate ACs. From a realization standpoint, the NF interface separate ACs. From a realization standpoint, the NF interface
connectivity is generally provided thanks to MacVLAN or Single connectivity is generally provided thanks to MacVLAN or Single
Root I/O Virtualization (SR-IOV). For the sake of simplicity, Root I/O Virtualization (SR-IOV). For the sake of simplicity,
only two VLANs are presented in this example; additional VLANs are only two VLANs are presented in this example; additional VLANs are
configured following a similar logic. configured following a similar logic.
A.11.2. Physical Infrastructure A.11.2. Physical Infrastructure
Figure 61 describes the physical infrastructure. The compute nodes Figure 61 describes the physical infrastructure. The compute nodes
(customer) are attached to the provider infrastructure thanks to a (customer) are attached to the provider infrastructure thanks to a
set of physical links on which attachment circuits are provisioned set of physical links on which ACs are provisioned (i.e., "compute-
(i.e., "compute-XX-nicY"). The provider infrastructure can be XX-nicY"). The provider infrastructure can be realized in multiple
realized in multiple ways, such as IP Fabric and Layer 2/3 Edge ways, such as IP Fabric and Layer 2/3 Edge Routers. This document
Routers. This document does not intend to detail these aspects. does not intend to detail these aspects.
.---------------------------. .---------------------------.
.------------. bearer = | .--------. | .------------. bearer = | .--------. |
| | compute-01-nic1 | | | | | | compute-01-nic1 | | | |
| compute-01 |------------------------| '--------' | | compute-01 |------------------------| '--------' |
| | | | | | | |
'------------' | .--------. .--------. | '------------' | .--------. .--------. |
| | | | | | | | | | | |
| '--------' '--------' | | '--------' '--------' |
.------------. bearer = | | .------------. bearer = | |
skipping to change at line 6168 skipping to change at line 6165
| | | Infrastructure | | | | Infrastructure |
'------------' |(IP Fabric, Gateways, etc.)| '------------' |(IP Fabric, Gateways, etc.)|
'---------------------------' '---------------------------'
Figure 61: Example Physical Topology for Cloud Deployment Figure 61: Example Physical Topology for Cloud Deployment
A.11.3. NFs Deployment A.11.3. NFs Deployment
The NFs are deployed on this infrastructure in the following way: The NFs are deployed on this infrastructure in the following way:
* Configuration of a parent AC as a centralized attachment for "vlan * Configuration of a Parent AC as a centralized attachment for "vlan
100". The parent AC captures Layer 2 and Layer 3 properties for 100". The Parent AC captures Layer 2 and Layer 3 properties for
this VLAN: vlan-id, IP default gateway and subnet, IP address pool this VLAN: vlan-id, IP default gateway and subnet, IP address pool
for NFs endpoints, static routes with BFD to user plane, and BGP for NFs endpoints, static routes with BFD to user plane, and BGP
configuration to control plane NFs. In addition, the IP addresses configuration to control plane NFs. In addition, the IP addresses
of the user plane ("nf-up") instances are protected using BFD. of the user plane ("nf-up") instances are protected using BFD.
* Configuration of a parent AC as a centralized attachment for "vlan * Configuration of a Parent AC as a centralized attachment for "vlan
200". This VLAN is for Layer 2 connectivity between NFs (no IP 200". This VLAN is for Layer 2 connectivity between NFs (no IP
configuration in the provider network). configuration in the provider network).
* "Child ACs" binding bearers to parent ACs for "vlan 100" and "vlan * Child ACs binding bearers to Parent ACs for "vlan 100" and "vlan
200". 200".
* The deployment of the network service to all compute nodes * The deployment of the network service to all compute nodes
("compute-01" to "compute-10"), even though the NF is not ("compute-01" to "compute-10"), even though the NF is not
instantiated on "compute-07"/"compute-08". This approach permits instantiated on "compute-07"/"compute-08". This approach permits
handling compute failures and scale-out scenarios in a reactive handling compute failures and scale-out scenarios in a reactive
and flexible fashion thanks to a pre-provisioned networking logic. and flexible fashion thanks to a pre-provisioned networking logic.
.-------------------------------------. .-------------------------------------.
|VLAN 100: | |VLAN 100: |
skipping to change at line 6594 skipping to change at line 6591
| .----. |.7 < - BFD - > | compute-08 | | .----. |.7 < - BFD - > | compute-08 |
| |nf-up7| |---------vlan-100-------------| created for | | |nf-up7| |---------vlan-100-------------| created for |
| | | |---------vlan-200-------------| scale-out | | | | |---------vlan-200-------------| scale-out |
| '----' | | | | '----' | | |
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 6636 skipping to change at line 6633
Each CE has a BFD session to each gateway for redundancy: Each CE has a BFD session to each gateway for redundancy:
.-------. .-------.
| CEx | .x <---BFD---> .252 | CEx | .x <---BFD---> .252
'-------' <---BFD---> .253 '-------' <---BFD---> .253
Figure 65: Example of Static Addressing with BFD Figure 65: Example of Static Addressing with BFD
Figure 66 shows the message body of the ACaaS configuration to enable Figure 66 shows the message body of the ACaaS configuration to enable
the target architecture shown in Figure 65. This example uses an AC the target architecture shown in Figure 65. This example uses an AC
group profile to factorize common data between all involved ACs. It group profile to factorize common data between all involved ACs. It
also uses child ACs that inherit the properties of two parent ACs, also uses Child ACs that inherit the properties of two Parent ACs,
each terminating in a separate gateway in the provider network. each terminating in a separate gateway in the provider network.
=============== NOTE: '\' line wrapping per RFC 8792 ================ =============== NOTE: '\' line wrapping per RFC 8792 ================
{ {
"ietf-ac-svc:specific-provisioning-profiles": { "ietf-ac-svc:specific-provisioning-profiles": {
"valid-provider-identifiers": { "valid-provider-identifiers": {
"failure-detection-profile-identifier": [ "failure-detection-profile-identifier": [
{ {
"id": "single-hop-bfd" "id": "single-hop-bfd"
skipping to change at line 7641 skipping to change at line 7638
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. 106 change blocks. 
260 lines changed or deleted 257 lines changed or added

This html diff was produced by rfcdiff 1.48.