rfc9835v1.txt   rfc9835.txt 
Internet Engineering Task Force (IETF) M. Boucadair, Ed. Internet Engineering Task Force (IETF) M. Boucadair, Ed.
Request for Comments: 9835 Orange Request for Comments: 9835 Orange
Category: Standards Track R. Roberts Category: Standards Track R. Roberts
ISSN: 2070-1721 Juniper ISSN: 2070-1721 Juniper
O. Gonzalez de Dios O. Gonzalez de Dios
Telefonica Telefonica
S. Barguil Giraldo S. Barguil
Nokia Nokia
B. Wu B. Wu
Huawei Technologies Huawei Technologies
August 2025 August 2025
A Network YANG Data Model for Attachment Circuits A Network YANG Data Model for Attachment Circuits
Abstract Abstract
This document specifies a network model for attachment circuits. The This document specifies a network model for attachment circuits
model can be used for the provisioning of attachment circuits prior (ACs). The model can be used for the provisioning of ACs prior to or
to or during service provisioning (e.g., VPN, Network Slice Service). during service provisioning (e.g., VPN, RFC 9543 Network Slice
A companion service model is specified in "YANG Data Models for Service). A companion service model is specified in "YANG Data
Bearers and 'Attachment Circuits'-as-a-Service (ACaaS)" (RFC9834). Models for Bearers and 'Attachment Circuits'-as-a-Service (ACaaS)"
(RFC9834).
The module augments the base network ('ietf-network') and the Service The module augments the base network ('ietf-network') and the Service
Attachment Point (SAP) models with the detailed information for the Attachment Point (SAP) models with the detailed information for the
provisioning of attachment circuits in Provider Edges (PEs). provisioning of ACs in Provider Edges (PEs).
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
received public review and has been approved for publication by the received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841. Internet Standards is available in Section 2 of RFC 7841.
skipping to change at line 63 skipping to change at line 64
include Revised BSD License text as described in Section 4.e of the include Revised BSD License text as described in Section 4.e of the
Trust Legal Provisions and are provided without warranty as described Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License. in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction 1. Introduction
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 Attachment Circuit Data Models 4. Sample Uses of the Attachment Circuit Data Models
4.1. ACs Terminated by One or Multiple Customer Edges (CEs) 4.1. ACs Terminated by One or Multiple CEs
4.2. Positioning the AC Network Model in the Overall Service 4.2. Positioning the AC Network Model in the Overall Service
Delivery Process Delivery Process
5. Description of the Attachment Circuit YANG Module 5. Description of the Attachment Circuit YANG Module
5.1. Overall Structure of the Module 5.1. Overall Structure of the Module
5.2. References 5.2. References
5.3. Provisioning Profiles 5.3. Provisioning Profiles
5.4. L2 Connection 5.4. L2 Connection
5.5. IP Connection 5.5. IP Connection
5.6. Routing 5.6. Routing
5.6.1. Static Routing 5.6.1. Static Routing
skipping to change at line 106 skipping to change at line 107
1. Introduction 1. Introduction
Connectivity services are provided by networks to customers via Connectivity services are provided by networks to customers via
dedicated terminating points, such as Service Functions [RFC7665], dedicated terminating points, such as Service Functions [RFC7665],
Customer Edges (CEs), peer Autonomous System Border Routers (ASBRs), Customer Edges (CEs), peer Autonomous System Border Routers (ASBRs),
data center gateways, or Internet Exchange Points. data center gateways, or Internet Exchange Points.
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, including may depend on the practices adopted by a service provider, including
the flow put in place for the provisioning of advanced network the flow put in place for the provisioning of advanced network
services and how they are bound to an attachment circuit (AC). For services and how they are bound to an AC. For example, the same AC
example, the same attachment circuit may host multiple services may host multiple services (e.g., Layer 2 VPN (L2VPN), Layer 3 VPN
(e.g., Layer 2 VPN (L2VPN), Layer 3 VPN (L3VPN), or Network Slice (L3VPN), or RFC 9543 Network Slice Service [RFC9543]). In order to
Service [RFC9543]). 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 standalone AC to be put
request a standalone attachment circuit to be put in place and refer in place and refer to that AC when requesting services to be bound to
to that attachment circuit when requesting services to be bound to
that AC. [RFC9834] specifies a data model for managing Attachment that AC. [RFC9834] specifies a data model for managing Attachment
Circuits as a Service (ACaaS). Circuits as a Service (ACaaS).
Section 6 specifies a network model for attachment circuits ("ietf- Section 6 specifies a network model for ACs ("ietf-ac-ntw"). The
ac-ntw"). The model can be used for the provisioning of ACs in a model can be used for the provisioning of ACs in a provider network
provider network prior to or during service provisioning. For prior to or during service provisioning. For example, [RFC9836]
example, [RFC9836] specifies augmentations to the L2VPN Network Model specifies augmentations to the L2VPN Network Model (L2NM) [RFC9291]
(L2NM) [RFC9291] and the L3VPN Network Model (L3NM) [RFC9182] to bind and the L3VPN Network Model (L3NM) [RFC9182] to bind LxVPNs to ACs
LxVPNs to ACs that are provisioned using the procedure defined in that are provisioned using the procedure defined in this document.
this document.
This document leverages [RFC9182] and [RFC9291] by adopting an AC This document leverages [RFC9182] and [RFC9291] by adopting an AC
provisioning structure that uses data nodes that are defined in those provisioning structure that uses data nodes that are defined in those
RFCs. Some refinements were introduced to cover not only RFCs. Some refinements were introduced to cover not only
conventional service provider networks but also specifics of other conventional service provider networks but also specifics of other
target deployments (e.g., cloud network). target deployments (e.g., cloud network).
The AC network model is designed as augmentations of both the 'ietf- The AC network model is designed as augmentations of both the 'ietf-
network' model [RFC8345] and the Service Attachment Point (SAP) model network' model [RFC8345] and the SAP model [RFC9408]. An AC can be
[RFC9408]. An attachment circuit can be bound to a single or bound to a single or multiple SAPs. Likewise, the model is designed
multiple SAPs. Likewise, the model is designed to accommodate to accommodate deployments where a SAP can be bound to one or
deployments where a SAP can be bound to one or multiple ACs (e.g., a multiple ACs (e.g., a parent AC and its child ACs).
parent AC and its child ACs).
.--. .--.
|CE6| |CE6|
'-+' '-+'
ac | .--. .--. ac | .--. .--.
| |CE5+------+------+CE2| | |CE5+------+------+CE2|
.-----+-----. '--' | '--' .-----+-----. '--' | '--'
| | |ac | | |ac
| | | | | |
.+. .+. .+. .+. .+. .+.
skipping to change at line 229 skipping to change at line 227
technologies can be used to build a bearer. The bearer type can technologies can be used to build a bearer. The bearer type can
be specified by a customer. be specified by a 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 then used in a reference can be retrieved by a customer and then used in
subsequent service placement requests to unambiguously identify subsequent service placement requests to unambiguously identify
where a service is to be bound. where a 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 Virtual Local Area Networks (VLANs) on the multiple Virtual Local Area Networks (VLANs) on the same bearer
same bearer that is provided by a physical link). that is provided by a physical link).
Network controller: Denotes a functional entity responsible for the Network controller: Denotes a functional entity responsible for the
management of the service provider network. One or multiple management of the service provider network. One or multiple
network controllers can be deployed in a service provider network. network controllers can be deployed in a service provider network.
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 Provider Edge (PE) selection, and requesting the PE selection, and requesting the activation of the requested
activation of the requested services to a network controller. services to a network controller.
A service orchestrator may interact with one or more network A service orchestrator may interact with one or more network
controllers. controllers.
Service provider network: A network that is able to provide network Service provider network: A network that is able to provide network
services (e.g., LxVPN or Network Slice Services). services (e.g., LxVPN or RFC 9543 Network Slice Services).
Service provider: An entity that offers network services (e.g., Service provider: An entity that offers network services (e.g.,
LxVPN 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 |
+=============+=====================+==========================+ +=============+=====================+==========================+
| ac-common | ietf-ac-common | [RFC9833] | | ac-common | ietf-ac-common | [RFC9833] |
+-------------+---------------------+--------------------------+ +-------------+---------------------+--------------------------+
| ac-svc | ietf-ac-svc | Section 5.2 of [RFC9834] | | ac-svc | ietf-ac-svc | Section 5.2 of [RFC9834] |
skipping to change at line 330 skipping to change at line 327
Figure 2: AC Data Models Figure 2: 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 Attachment Circuit Data Models 4. Sample Uses of the Attachment Circuit Data Models
4.1. ACs Terminated by One or Multiple Customer Edges (CEs) 4.1. ACs Terminated by One or Multiple CEs
Figure 3 depicts a sample target topology that involve ACs: Figure 3 depicts a sample target topology that involve ACs:
* ACs are terminated by a SAP at the network side. See Figure 1 for * ACs are terminated by a SAP at the network side. See Figure 1 for
an example of SAPs within a PE. an example of SAPs within a PE.
* A CE can be either a physical device or a logical entity. Such a * A CE can be either a physical device or a logical entity. Such a
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 Service Function that is hosted within the provider's network or a
third-party infrastructure). A CE is seen by the network as a third-party infrastructure). A CE is seen by the network as a
peer SAP [RFC9408]. peer SAP [RFC9408].
* 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 host multiple connectivity services (e.g., CEs with roles of
Service Functions [RFC7665]). Service Functions [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 (e.g., CE4). with the same bearer or distinct bearers (e.g., CE4).
* 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
service provider network and also whether to enable specific service provider network and also whether to enable specific
capabilities (e.g., Virtual Router Redundancy Protocol (VRRP)). capabilities (e.g., Virtual Router Redundancy Protocol (VRRP)).
skipping to change at line 400 skipping to change at line 397
(bx) = bearer Id x (bx) = bearer Id x
Figure 3: Examples of ACs Figure 3: Examples of ACs
4.2. Positioning the AC Network Model in the Overall Service Delivery 4.2. Positioning the AC Network Model in the Overall Service Delivery
Process Process
Figure 4 shows the positioning of the AC network model in the overall Figure 4 shows the positioning of the AC network model in the overall
service delivery process. The "ietf-ac-ntw" module is a network service delivery process. The "ietf-ac-ntw" module is a network
model that augments the SAP with a comprehensive set of parameters to model that augments the SAP with a comprehensive set of parameters to
reflect the attachment circuits that are in place in a network. The reflect the ACs that are in place in a network. The model also
model also maintains the mapping with the service references that are maintains the mapping with the service references that are used to
used to expose those ACs to customers using the "ietf-ac-svc" module expose those ACs to customers using the "ietf-ac-svc" module defined
defined in [RFC9834]. Whether the same naming conventions to in [RFC9834]. Whether the same naming conventions to reference an AC
reference an AC are used in the service and network layers is are used in the service and network layers is deployment-specific.
deployment-specific.
.-------------. .-------------.
| Customer | | Customer |
'------+------' '------+------'
Customer Service Models | Customer Service Models |
ietf-l2vpn-svc, ietf-l3vpn-svc, | ietf-network-slice-service, ietf-l2vpn-svc, ietf-l3vpn-svc, | ietf-network-slice-service,
ietf-ac-svc, ietf-ac-glue, | and ietf-bearer-svc ietf-ac-svc, ietf-ac-glue, | and ietf-bearer-svc
.------+------. .------+------.
| Service | | Service |
| Orchestration | | Orchestration |
skipping to change at line 443 skipping to change at line 439
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 4: An Example of the Network AC Model Usage Figure 4: An Example of the Network AC Model Usage
Similar to [RFC9408], the "ietf-ac-ntw" module can be used for both Similar to [RFC9408], the "ietf-ac-ntw" module can be used for both
User-to-Network Interface (UNI) and Network-to-Network Interface User-to-Network Interface (UNI) and Network-to-Network Interface
(NNI). For example, all the ACs shown in Figure 5 have a 'role' set (NNI). For example, all the ACs shown in Figure 5 have a 'role' set
to 'ietf-sap-ntw:nni'. Typically, ASBRs of each network are directly to 'ietf-sap-ntw:nni'. Typically, ASBRs of each network are directly
skipping to change at line 641 skipping to change at line 637
+-- network-ref? -> /nw:networks/network/network-id +-- network-ref? -> /nw:networks/network/network-id
grouping routing-profile-reference: grouping routing-profile-reference:
+-- routing-profile-ref? leafref +-- routing-profile-ref? leafref
+-- network-ref? -> /nw:networks/network/network-id +-- network-ref? -> /nw:networks/network/network-id
Figure 7: References Groupings Figure 7: References Groupings
The groupings shown in Figure 7 contain the information necessary to The groupings shown in Figure 7 contain the information necessary to
reference: reference:
* an attachment circuit that is terminated by a specific node in a * an AC that is terminated by a specific node in a given network,
given network,
* an attachment circuit profile of a specific network (Section 5.3), * an AC profile of a specific network (Section 5.3), and
and
* specific provisioning profiles that are bound to a specific * specific provisioning profiles that are bound to a specific
network (Section 5.3). network (Section 5.3).
5.3. Provisioning Profiles 5.3. Provisioning Profiles
The AC and specific provisioning profiles tree structure is shown in The AC and specific provisioning profiles tree structure is shown in
Figure 8. Figure 8.
augment /nw:networks/nw:network: augment /nw:networks/nw:network:
skipping to change at line 1442 skipping to change at line 1436
'name': Defines a name for the peer group. 'name': Defines a name for the peer group.
'local-address': Specifies an address or a reference to an interface 'local-address': Specifies an address or a reference to an interface
to use when establishing the BGP transport session. to use when establishing the BGP transport session.
'description': Includes a description of the peer group. 'description': Includes a description of the peer group.
'apply-policy': Lists a set of import/export policies [RFC9067] to 'apply-policy': Lists a set of import/export policies [RFC9067] to
apply for this group. apply for this group.
'local-as': Indicates a local AS Number (ASN). 'local-as': Indicates a local Autonomous System Number (ASN).
'peer-as': Indicates the peer's ASN. 'peer-as': Indicates the peer's ASN.
'address-family': Indicates the address family of the peer. It can 'address-family': Indicates the address family of the peer. It can
be set to 'ipv4', 'ipv6', or 'dual-stack'. be set to 'ipv4', 'ipv6', or 'dual-stack'.
This address family might be used together with the service type This address family might be used together with the service type
that uses an AC (e.g., 'vpn-type' [RFC9182]) to derive the that uses an AC (e.g., 'vpn-type' [RFC9182]) to derive the
appropriate Address Family Identifiers (AFIs) / Subsequent Address appropriate Address Family Identifiers (AFIs) / Subsequent Address
Family Identifiers (SAFIs) that will be part of the derived device Family Identifiers (SAFIs) that will be part of the derived device
skipping to change at line 2238 skipping to change at line 2232
Peak Burst Size (PBS). CIR, EIR, and PIR are expressed in bps, Peak Burst Size (PBS). CIR, EIR, and PIR are expressed in bps,
while CBS, EBS, and PBS are expressed in bytes. while CBS, EBS, and PBS are expressed in bytes.
The following types, defined in [RFC9181], can be used to indicate The following types, defined in [RFC9181], can be used to indicate
the bandwidth type: the bandwidth type:
'bw-per-cos': The bandwidth is per Class of Service (CoS). 'bw-per-cos': The bandwidth is per Class of Service (CoS).
'bw-per-port': The bandwidth is per port. 'bw-per-port': The bandwidth is per port.
'bw-per-site': The bandwidth is to all peer SAPs that belong to 'bw-per-site': The bandwidth is for all peer SAPs that belong to
the same site. the same site.
'bw-per-service': The bandwidth is per service instance that is 'bw-per-service': The bandwidth is per service instance that is
bound to an AC. bound to an AC.
'qos': Specifies a list of QoS profiles to apply for this AC. 'qos': Specifies a list of QoS profiles to apply for this AC.
'access-control-list': Specifies a list of ACL profiles to apply for 'access-control-list': Specifies a list of ACL profiles to apply for
this AC. this AC.
skipping to change at line 2367 skipping to change at line 2361
reference reference
"RFC 9835: A YANG Network Data Model for Attachment Circuits"; "RFC 9835: A YANG Network Data Model for Attachment Circuits";
} }
// References // References
/* A set of groupings to ease referencing cross-modules */ /* A set of groupings to ease referencing cross-modules */
grouping attachment-circuit-reference { grouping attachment-circuit-reference {
description description
"This grouping can be used to reference an attachment circuit "This grouping can be used to reference an AC in a specific
in a specific node."; node.";
leaf ac-ref { leaf ac-ref {
type leafref { type leafref {
path "/nw:networks/nw:network[nw:network-id=current()/../" path "/nw:networks/nw:network[nw:network-id=current()/../"
+ "network-ref]/nw:node[nw:node-id=current()/../" + "network-ref]/nw:node[nw:node-id=current()/../"
+ "node-ref]/ac-ntw:ac/ac-ntw:name"; + "node-ref]/ac-ntw:ac/ac-ntw:name";
require-instance false; require-instance false;
} }
description description
"An absolute reference to an attachment circuit."; "An absolute reference to an AC.";
} }
uses nw:node-ref; uses nw:node-ref;
} }
grouping attachment-circuit-references { grouping attachment-circuit-references {
description description
"This grouping can be used to reference a list of attachment "This grouping can be used to reference a list of ACs in a
circuits in a specific node."; specific node.";
leaf-list ac-ref { leaf-list ac-ref {
type leafref { type leafref {
path "/nw:networks/nw:network[nw:network-id=current()/../" path "/nw:networks/nw:network[nw:network-id=current()/../"
+ "network-ref]/nw:node[nw:node-id=current()/../" + "network-ref]/nw:node[nw:node-id=current()/../"
+ "node-ref]/ac-ntw:ac/ac-ntw:name"; + "node-ref]/ac-ntw:ac/ac-ntw:name";
require-instance false; require-instance false;
} }
description description
"An absolute reference to an attachment circuit."; "An absolute reference to an AC.";
} }
uses nw:node-ref; uses nw:node-ref;
} }
grouping ac-profile-reference { grouping ac-profile-reference {
description description
"This grouping can be used to reference an attachment circuit "This grouping can be used to reference an AC profile.";
profile.";
leaf ac-profile-ref { leaf ac-profile-ref {
type leafref { type leafref {
path "/nw:networks/nw:network[nw:network-id=current()/../" path "/nw:networks/nw:network[nw:network-id=current()/../"
+ "network-ref]/ac-ntw:ac-profile/ac-ntw:name"; + "network-ref]/ac-ntw:ac-profile/ac-ntw:name";
require-instance false; require-instance false;
} }
description description
"An absolute reference to an attachment circuit."; "An absolute reference to an AC.";
} }
uses nw:network-ref; uses nw:network-ref;
} }
grouping encryption-profile-reference { grouping encryption-profile-reference {
description description
"This grouping can be used to reference an encryption "This grouping can be used to reference an encryption
profile."; profile.";
leaf encryption-profile-ref { leaf encryption-profile-ref {
type leafref { type leafref {
skipping to change at line 3091 skipping to change at line 3084
type string; type string;
description description
"Includes a description of the BGP session. This description "Includes a description of the BGP session. This description
is meant to be used for diagnostic purposes. The semantics is meant to be used for diagnostic purposes. The semantics
of the description are local to an implementation."; of the description are local to an implementation.";
} }
uses rt-pol:apply-policy-group; uses rt-pol:apply-policy-group;
leaf local-as { leaf local-as {
type inet:as-number; type inet:as-number;
description description
"Indicates a local AS Number (ASN), if an ASN distinct from "Indicates a local Autonomous System Number (ASN), if an ASN
the ASN configured at the AC level is needed."; distinct from the ASN configured at the AC level is
needed.";
} }
leaf peer-as { leaf peer-as {
type inet:as-number; type inet:as-number;
mandatory true; mandatory true;
description description
"Indicates the customer's ASN when the customer requests BGP "Indicates the customer's ASN when the customer requests BGP
routing."; routing.";
} }
leaf address-family { leaf address-family {
type identityref { type identityref {
skipping to change at line 4066 skipping to change at line 4060
} }
} }
} }
} }
} }
// AC profile // AC profile
grouping ac-profile { grouping ac-profile {
description description
"Grouping for attachment circuit profiles."; "Grouping for AC profiles.";
container routing-protocols { container routing-protocols {
description description
"Defines routing protocols."; "Defines routing protocols.";
uses routing-profile; uses routing-profile;
} }
container oam { container oam {
description description
"Defines the OAM mechanisms used for the AC profile."; "Defines the OAM mechanisms used for the AC profile.";
container bfd { container bfd {
if-feature "vpn-common:bfd"; if-feature "vpn-common:bfd";
skipping to change at line 4109 skipping to change at line 4103
description description
"Specifies a child AC that relies upon a parent AC."; "Specifies a child AC that relies upon a parent AC.";
uses ac-ntw:attachment-circuit-references; uses ac-ntw:attachment-circuit-references;
} }
} }
// AC network provisioning // AC network provisioning
grouping ac { grouping ac {
description description
"Grouping for attachment circuits."; "Grouping for ACs.";
leaf description { leaf description {
type string; type string;
description description
"Associates a description with an AC."; "Associates a description with an 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 4273 skipping to change at line 4267
description description
"Specifies the ACs that are terminated by the SAP."; "Specifies the ACs that are terminated by the SAP.";
uses ac-ntw:attachment-circuit-reference; uses ac-ntw:attachment-circuit-reference;
} }
} }
} }
<CODE ENDS> <CODE ENDS>
7. Security Considerations 7. Security Considerations
This section is modeled after the template described in Section 3.7 Several data nodes ('bgp', 'ospf', 'isis', 'rip', and 'customer-key-
of [YANG-GUIDELINES]. chain') rely upon [RFC8177] for authentication purposes. As such,
the AC network module inherits the security considerations discussed
in Section 5 of [RFC8177]. Also, these data nodes support supplying
explicit keys as strings in ASCII format. The use of keys in
hexadecimal string format would afford greater key entropy with the
same number of key-string octets. However, such a format is not
included in this version of the AC network model, because it is not
supported by the underlying device modules (e.g., [RFC8695]).
Section 5.8 specifies the encryption to be applied to traffic for a
given AC.
The remainder of this section is modeled after the template described
in Section 3.7.1 of [YANG-GUIDELINES].
The "ietf-ac-ntw" YANG module defines a data model that is designed The "ietf-ac-ntw" YANG module defines a data model that is designed
to be accessed via YANG-based management protocols, such as NETCONF to be accessed via YANG-based management protocols, such as NETCONF
[RFC6241] and RESTCONF [RFC8040]. These protocols have to use a [RFC6241] and RESTCONF [RFC8040]. These protocols have to use a
secure transport layer (e.g., SSH [RFC4252], TLS [RFC8446], and QUIC secure transport layer (e.g., SSH [RFC4252], TLS [RFC8446], and QUIC
[RFC9000]) and have to use mutual authentication. [RFC9000]) and have to use mutual authentication.
The Network Configuration Access Control Model (NACM) [RFC8341] The Network Configuration Access Control Model (NACM) [RFC8341]
provides the means to restrict access for particular NETCONF or provides the means to restrict access for particular NETCONF or
RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or
skipping to change at line 4332 skipping to change at line 4339
'l2-connection' and 'ip-connection': An attacker can retrieve 'l2-connection' and 'ip-connection': An attacker can retrieve
privacy-related information, which can be used to track a privacy-related information, which can be used to track a
customer. Disclosing such information may be considered 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' and 'customer-key-chain': An attacker can retrieve 'keying-material' and 'customer-key-chain': An attacker can retrieve
the cryptographic keys protecting an AC (routing, in particular). the cryptographic keys protecting an AC (routing, in particular).
These keys could be used to inject spoofed routing advertisements. These keys could be used to inject spoofed routing advertisements.
Several data nodes ('bgp', 'ospf', 'isis', 'rip', and 'customer-key- There are no particularly sensitive RPC or action operations.
chain') rely upon [RFC8177] for authentication purposes. As such,
the AC network module inherits the security considerations discussed
in Section 5 of [RFC8177]. Also, these data nodes support supplying
explicit keys as strings in ASCII format. The use of keys in
hexadecimal string format would afford greater key entropy with the
same number of key-string octets. However, such a format is not
included in this version of the AC network model, because it is not
supported by the underlying device modules (e.g., [RFC8695]).
Section 5.8 specifies the encryption to be applied to traffic for a
given AC.
8. IANA Considerations 8. IANA Considerations
IANA has registered the following URI in the "ns" subregistry within IANA has registered the following URI in the "ns" subregistry within
the "IETF XML Registry" [RFC3688]: the "IETF XML Registry" [RFC3688]:
URI: urn:ietf:params:xml:ns:yang:ietf-ac-ntw URI: urn:ietf:params:xml:ns:yang:ietf-ac-ntw
Registrant Contact: The IESG. Registrant Contact: The IESG.
XML: N/A; the requested URI is an XML namespace. XML: N/A; the requested URI is an XML namespace.
skipping to change at line 4541 skipping to change at line 4537
Q., and V. Lopez, "A YANG Network Data Model for Service Q., and V. Lopez, "A YANG Network Data Model for Service
Attachment Points (SAPs)", RFC 9408, DOI 10.17487/RFC9408, Attachment Points (SAPs)", RFC 9408, DOI 10.17487/RFC9408,
June 2023, <https://www.rfc-editor.org/info/rfc9408>. June 2023, <https://www.rfc-editor.org/info/rfc9408>.
[RFC9568] Lindem, A. and A. Dogra, "Virtual Router Redundancy [RFC9568] Lindem, A. and A. Dogra, "Virtual Router Redundancy
Protocol (VRRP) Version 3 for IPv4 and IPv6", RFC 9568, Protocol (VRRP) Version 3 for IPv4 and IPv6", RFC 9568,
DOI 10.17487/RFC9568, April 2024, DOI 10.17487/RFC9568, April 2024,
<https://www.rfc-editor.org/info/rfc9568>. <https://www.rfc-editor.org/info/rfc9568>.
[RFC9833] Boucadair, M., Ed., Roberts, R., Ed., Gonzalez de Dios, [RFC9833] Boucadair, M., Ed., Roberts, R., Ed., Gonzalez de Dios,
O., Barguil Giraldo, S., and B. Wu, "A Common YANG Data O., Barguil, S., and B. Wu, "A Common YANG Data Model for
Model for Attachment Circuits", RFC 9833, Attachment Circuits", RFC 9833, DOI 10.17487/RFC9833,
DOI 10.17487/RFC9833, August 2025, August 2025, <https://www.rfc-editor.org/info/rfc9833>.
<https://www.rfc-editor.org/info/rfc9833>.
[RFC9834] Boucadair, M., Ed., Roberts, R., Ed., Gonzalez de Dios, [RFC9834] Boucadair, M., Ed., Roberts, R., Ed., Gonzalez de Dios,
O., Barguil, S., and B. Wu, "YANG Data Models for Bearers O., Barguil, S., and B. Wu, "YANG Data Models for Bearers
and 'Attachment Circuits'-as-a-Service (ACaaS)", RFC 9834, and 'Attachment Circuits'-as-a-Service (ACaaS)", RFC 9834,
DOI 10.17487/RFC9834, August 2025, DOI 10.17487/RFC9834, August 2025,
<https://www.rfc-editor.org/info/rfc9834>. <https://www.rfc-editor.org/info/rfc9834>.
9.2. Informative References 9.2. Informative References
[RFC3644] Snir, Y., Ramberg, Y., Strassner, J., Cohen, R., and B. [RFC3644] Snir, Y., Ramberg, Y., Strassner, J., Cohen, R., and B.
skipping to change at line 5604 skipping to change at line 5599
Email: mohamed.boucadair@orange.com Email: mohamed.boucadair@orange.com
Richard Roberts Richard Roberts
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. 34 change blocks. 
91 lines changed or deleted 86 lines changed or added

This html diff was produced by rfcdiff 1.48.