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 September 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 107 skipping to change at line 108
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 attachment circuit (AC). For
example, the same attachment circuit may host multiple services example, the same AC may host multiple services (e.g., Layer 2 VPN
(e.g., Layer 2 VPN (L2VPN), Layer 3 VPN (L3VPN), or Network Slice (L2VPN), Layer 3 VPN (L3VPN), or RFC 9543 Network Slice Service
Service [RFC9543]). In order to avoid service interference and [RFC9543]). In order to avoid service interference and redundant
redundant information in various locations, a service provider may information in various locations, a service provider may expose an
expose an interface to manage ACs network-wide. Customers can then interface to manage ACs network-wide. Customers can then request a
request a standalone attachment circuit to be put in place and refer standalone AC to be put in place and refer to that AC when requesting
to that attachment circuit when requesting services to be bound to services to be bound to that AC. [RFC9834] specifies a data model
that AC. [RFC9834] specifies a data model for managing Attachment 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 Service Attachment Point (SAP) model
[RFC9408]. An attachment circuit can be bound to a single or [RFC9408]. An AC can be bound to a single or multiple SAPs.
multiple SAPs. Likewise, the model is designed to accommodate Likewise, the model is designed to accommodate deployments where a
deployments where a SAP can be bound to one or multiple ACs (e.g., a SAP can be bound to one or multiple ACs (e.g., a Parent AC and its
parent AC and its child ACs). Child ACs).
.--. .--.
|CE6| |CE6|
'-+' '-+'
ac | .--. .--. ac | .--. .--.
| |CE5+------+------+CE2| | |CE5+------+------+CE2|
.-----+-----. '--' | '--' .-----+-----. '--' | '--'
| | |ac | | |ac
| | | | | |
.+. .+. .+. .+. .+. .+.
.-+sap+-------+sap+-. .-+sap+-------------. .-+sap+-------+sap+-. .-+sap+-------------.
| '-' '-' | | '-' | | '-' '-' | | '-' |
| PE1 | | PE2 | | PE1 | | PE2 |
.--. .+. | | | .--. .+. | | |
|CE1+--+sap| | | | |CE1+--+sap| | | |
'--' ac '+' | | | '--' ac '+' | | |
'-------------------' '-------------------' '-------------------' '-------------------'
.-------------------. .-------------------. .-------------------. .-------------------.
| | | .+. ac .--. | | | .+. ac .--.
| PE3 | | PE4 |sap+--+CE5| | PE3 | | PE4 |sap+--+CE7|
| | | '-' '--' | | | '-' '--'
| | | | | | | |
| .-. | | .-. .-. .-. | | .-. | | .-. .-. .-. |
'-------------+sap+-' '-+sap+-+sap+-+sap+-' '-------------+sap+-' '-+sap+-+sap+-+sap+-'
'+' '+' '+' '+' '+' '+' '+' '+'
|ac | |ac |ac |ac | |ac |ac
.+-. | .+-. | .+-. | .+-. |
|CE3+-----ac-----' |CE4+---' |CE3+-----ac-----' |CE4+---'
'--' '--' '--' '--'
skipping to change at line 195 skipping to change at line 194
The reader should be familiar with the terms defined in Section 2 of The reader should be familiar with the terms defined in Section 2 of
[RFC9408]. [RFC9408].
This document uses the term "network model" as defined in Section 2.1 This document uses the term "network model" as defined in Section 2.1
of [RFC8969]. of [RFC8969].
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
[RFC8340]. [RFC8340].
LxSM refers to both the Layer 2 Service Model (L2SM) [RFC8466] and LxSM refers to both the L2VPN Service Model (L2SM) [RFC8466] and the
the Layer 3 Service Model (L3SM) [RFC8299]. L3VPN Service Model (L3SM) [RFC8299].
LxNM refers to both the L2VPN Network Model (L2NM) [RFC9291] and the LxNM refers to both the L2VPN Network Model (L2NM) [RFC9291] and the
L3VPN Network Model (L3NM) [RFC9182]. L3VPN Network Model (L3NM) [RFC9182].
LxVPN refers to both L2VPN and L3VPN. LxVPN refers to both L2VPN and L3VPN.
The following are used in the module prefixes: The following are used in the module prefixes:
ac: Attachment circuit ac: Attachment circuit
skipping to change at line 229 skipping to change at line 228
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 Provider Edge (PE) selection, and requesting the activation of the
activation of the requested services to a network controller. requested services to a network controller.
A service orchestrator may interact with one or more network A service orchestrator may interact with one or more network
controllers. controllers.
Service provider network: A network that is able to provide network Service provider network: A network that is able to provide network
services (e.g., 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 6.2 of [RFC9834] |
+-------------+---------------------+--------------------------+ +-------------+---------------------+--------------------------+
| dot1q-types | ieee802-dot1q-types | [IEEE802.1Qcp] | | dot1q-types | ieee802-dot1q-types | [IEEE802.1Qcp] |
+-------------+---------------------+--------------------------+ +-------------+---------------------+--------------------------+
| if | ietf-interfaces | [RFC8343] | | if | ietf-interfaces | [RFC8343] |
+-------------+---------------------+--------------------------+ +-------------+---------------------+--------------------------+
| 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] |
+-------------+---------------------+--------------------------+ +-------------+---------------------+--------------------------+
| nacm | ietf-netconf-acm | [RFC8341] | | nacm | ietf-netconf-acm | [RFC8341] |
skipping to change at line 330 skipping to change at line 328
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 398
(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 440
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 573 skipping to change at line 570
ACs, a set of profiles (Section 5.3) can be defined at the network ACs, a set of profiles (Section 5.3) can be defined at the network
level and then called under the node level. The information level and then called under the node level. The information
contained in a profile is thus inherited, unless the corresponding contained in a profile is thus inherited, unless the corresponding
data node is refined at the AC level. In such a case, the value data node is refined at the AC level. In such a case, the value
provided at the AC level takes precedence over the global one. provided at the AC level takes precedence over the global one.
In contexts where the same AC is terminated by multiple peer SAPs In contexts where the same AC is terminated by multiple peer SAPs
(e.g., an AC with multiple CEs) but a subset of them have specific (e.g., an AC with multiple CEs) but a subset of them have specific
information, the module allows operators to: information, the module allows operators to:
* Define a parent AC that may list all these CEs as peer SAPs. * Define a Parent AC that may list all these CEs as peer SAPs.
* Create individual ACs that are bound to the parent AC using * Create individual ACs that are bound to the Parent AC using
'parent-ref'. 'parent-ref'.
* Indicate for each individual AC one or a subset of the CEs as peer * Indicate for each individual AC one or a subset of the CEs as peer
SAPs. All these individual ACs will inherit the properties of the SAPs. All these individual ACs will inherit the properties of the
parent AC. Parent AC.
Whenever a parent AC is deleted, then all child ACs of that AC MUST Whenever a Parent AC is deleted, then all Child ACs of that AC MUST
be deleted. Child ACs are referenced using 'child-ref'. be deleted. Child ACs are referenced using 'child-ref'.
An AC may belong to one or multiple groups [RFC9181]. For example, An AC may belong to one or multiple groups [RFC9181]. For example,
the 'group-id' is used to associate redundancy or protection the 'group-id' is used to associate redundancy or protection
constraints with ACs. constraints with ACs.
The status of an AC can be tracked using 'status'. Both operational The status of an AC can be tracked using 'status'. Both operational
status and administrative status are maintained. A mismatch between status and administrative status are maintained. A mismatch between
the administrative status vs. the operational status can be used as a the administrative status vs. the operational status can be used as a
trigger to detect anomalies. trigger to detect anomalies.
skipping to change at line 641 skipping to change at line 638
+-- 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 1437
'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 2233
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 2317 skipping to change at line 2312
Points (SAPs)"; Points (SAPs)";
} }
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>
skipping to change at line 2367 skipping to change at line 2362
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 3085
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 4061
} }
} }
} }
} }
} }
// 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 4088 skipping to change at line 4083
"Container for BFD."; "Container for BFD.";
uses bfd; uses bfd;
} }
} }
} }
// 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.";
container parent-ref { container parent-ref {
description description
"Specifies the parent AC that is inherited by an AC. "Specifies the Parent AC that is inherited by an AC.
Parent ACs are used, e.g., in contexts where multiple Parent ACs are used, e.g., in contexts where multiple
CEs are terminating the same AC, but some specific CEs are terminating the same AC, but some specific
information is required for each peer SAP."; information is required for each peer SAP.";
uses ac-ntw:attachment-circuit-reference; uses ac-ntw:attachment-circuit-reference;
} }
container child-ref { container child-ref {
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.";
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 4268
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 This section is modeled after the template described in Section 3.7.1
of [YANG-GUIDELINES]. 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
skipping to change at line 4332 skipping to change at line 4327
'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.
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 network module inherits the security considerations discussed authentication purposes. As such, the AC network 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 network 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]). 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 Section 5.8 specifies the encryption to be applied to traffic for a
given AC. 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
skipping to change at line 4392 skipping to change at line 4390
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, [RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453,
DOI 10.17487/RFC2453, November 1998, DOI 10.17487/RFC2453, November 1998,
<https://www.rfc-editor.org/info/rfc2453>. <https://www.rfc-editor.org/info/rfc2453>.
[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)
Authentication Protocol", RFC 4252, DOI 10.17487/RFC4252,
January 2006, <https://www.rfc-editor.org/info/rfc4252>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271, Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006, DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/info/rfc4271>. <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
skipping to change at line 4432 skipping to change at line 4426
[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>.
[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
skipping to change at line 4460 skipping to change at line 4449
[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>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016, RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>. <https://www.rfc-editor.org/info/rfc7950>.
[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>.
[RFC8077] Martini, L., Ed. and G. Heron, Ed., "Pseudowire Setup and [RFC8077] Martini, L., Ed. and G. Heron, Ed., "Pseudowire Setup and
Maintenance Using the Label Distribution Protocol (LDP)", Maintenance Using the Label Distribution Protocol (LDP)",
STD 84, RFC 8077, DOI 10.17487/RFC8077, February 2017, STD 84, RFC 8077, DOI 10.17487/RFC8077, February 2017,
<https://www.rfc-editor.org/info/rfc8077>. <https://www.rfc-editor.org/info/rfc8077>.
[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.
skipping to change at line 4502 skipping to change at line 4487
[RFC8343] Bjorklund, M., "A YANG Data Model for Interface [RFC8343] Bjorklund, M., "A YANG Data Model for Interface
Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, Management", RFC 8343, DOI 10.17487/RFC8343, March 2018,
<https://www.rfc-editor.org/info/rfc8343>. <https://www.rfc-editor.org/info/rfc8343>.
[RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N.,
Ananthakrishnan, H., and X. Liu, "A YANG Data Model for Ananthakrishnan, H., and X. Liu, "A YANG Data Model for
Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March
2018, <https://www.rfc-editor.org/info/rfc8345>. 2018, <https://www.rfc-editor.org/info/rfc8345>.
[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>.
[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>.
[RFC9067] Qu, Y., Tantsura, J., Lindem, A., and X. Liu, "A YANG Data [RFC9067] Qu, Y., Tantsura, J., Lindem, A., and X. Liu, "A YANG Data
Model for Routing Policy", RFC 9067, DOI 10.17487/RFC9067, Model for Routing Policy", RFC 9067, DOI 10.17487/RFC9067,
October 2021, <https://www.rfc-editor.org/info/rfc9067>. October 2021, <https://www.rfc-editor.org/info/rfc9067>.
[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.,
skipping to change at line 4541 skipping to change at line 4517
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>.
[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, September 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.
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>.
[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>.
[RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality
for OSPFv3", RFC 4552, DOI 10.17487/RFC4552, June 2006, for OSPFv3", RFC 4552, DOI 10.17487/RFC4552, June 2006,
<https://www.rfc-editor.org/info/rfc4552>. <https://www.rfc-editor.org/info/rfc4552>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, Address Autoconfiguration", RFC 4862,
DOI 10.17487/RFC4862, September 2007, DOI 10.17487/RFC4862, September 2007,
<https://www.rfc-editor.org/info/rfc4862>. <https://www.rfc-editor.org/info/rfc4862>.
[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>.
[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>.
[RFC7880] Pignataro, C., Ward, D., Akiya, N., Bhatia, M., and S. [RFC7880] Pignataro, C., Ward, D., Akiya, N., Bhatia, M., and S.
Pallagatti, "Seamless Bidirectional Forwarding Detection Pallagatti, "Seamless Bidirectional Forwarding Detection
(S-BFD)", RFC 7880, DOI 10.17487/RFC7880, July 2016, (S-BFD)", RFC 7880, DOI 10.17487/RFC7880, July 2016,
<https://www.rfc-editor.org/info/rfc7880>. <https://www.rfc-editor.org/info/rfc7880>.
[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>.
[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>.
[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>.
[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>.
[RFC9127] Rahman, R., Ed., Zheng, L., Ed., Jethanandani, M., Ed., [RFC9127] Rahman, R., Ed., Zheng, L., Ed., Jethanandani, M., Ed.,
Pallagatti, S., and G. Mirsky, "YANG Data Model for Pallagatti, S., and G. Mirsky, "YANG Data Model for
Bidirectional Forwarding Detection (BFD)", RFC 9127, Bidirectional Forwarding Detection (BFD)", RFC 9127,
DOI 10.17487/RFC9127, October 2021, DOI 10.17487/RFC9127, October 2021,
<https://www.rfc-editor.org/info/rfc9127>. <https://www.rfc-editor.org/info/rfc9127>.
[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,
skipping to change at line 4623 skipping to change at line 4620
[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>.
[RFC9836] Boucadair, M., Ed., Roberts, R., Barguil, S., and O. [RFC9836] Boucadair, M., Ed., Roberts, R., Barguil, S., and 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://www.rfc-editor.org/info/rfc9836>. <https://www.rfc-editor.org/info/rfc9836>.
[YANG-GUIDELINES] [YANG-GUIDELINES]
Bierman, A., Boucadair, M., and Q. Wu, "Guidelines for Bierman, A., Boucadair, M., and Q. Wu, "Guidelines for
Authors and Reviewers of Documents Containing YANG Data Authors and Reviewers of Documents Containing YANG Data
Models", Work in Progress, Internet-Draft, draft-ietf- Models", Work in Progress, Internet-Draft, draft-ietf-
netmod-rfc8407bis-28, 5 June 2025, 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 4846 skipping to change at line 4843
} }
Figure 24: Example of AC Network Response to Retrieve the SAP Figure 24: Example of AC Network Response to Retrieve the SAP
(Message Body) (Message Body)
A.2. Parent AC A.2. Parent AC
In reference to the topology depicted in Figure 1, PE2 has a SAP that In reference to the topology depicted in Figure 1, PE2 has a SAP that
terminates an AC with two peer SAPs (CE2 and CE5). In order to terminates an AC with two peer SAPs (CE2 and CE5). In order to
control data that is specific to each of these peer SAPs over the control data that is specific to each of these peer SAPs over the
same AC, child ACs can be instantiated as depicted in Figure 25. same AC, Child ACs can be instantiated as depicted in Figure 25.
{ {
"ietf-ac-ntw:ac":[ "ietf-ac-ntw:ac":[
{ {
"name":"ac-1", "name":"ac-1",
"peer-sap-id":[ "peer-sap-id":[
"CE2", "CE2",
"CE5" "CE5"
], ],
"status":{ "status":{
skipping to change at line 4902 skipping to change at line 4899
}, },
"peer-sap-id":[ "peer-sap-id":[
"CE5" "CE5"
] ]
} }
] ]
} }
Figure 25: Example of Child ACs Figure 25: Example of Child ACs
Figure 26 shows how to bind the parent AC to a SAP. Figure 26 shows how to bind the Parent AC to a SAP.
{ {
"ietf-sap-ntw:service":[ "ietf-sap-ntw:service":[
{ {
"service-type":"ietf-vpn-common:l3vpn", "service-type":"ietf-vpn-common:l3vpn",
"sap":[ "sap":[
{ {
"sap-id":"sap#14587", "sap-id":"sap#14587",
"description":"A SAP", "description":"A SAP",
"parent-termination-point":"GE0/6/4", "parent-termination-point":"GE0/6/4",
skipping to change at line 5604 skipping to change at line 5601
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. 60 change blocks. 
127 lines changed or deleted 124 lines changed or added

This html diff was produced by rfcdiff 1.48.