rfc9835v2.txt | rfc9835.txt | |||
---|---|---|---|---|
skipping to change at line 18 ¶ | skipping to change at line 18 ¶ | |||
S. Barguil | 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, RFC 9543 Network Slice | during service provisioning (e.g., VPN, RFC 9543 Network Slice | |||
Service). A companion service model is specified in "YANG Data | Service). A companion service model is specified in "YANG Data | |||
Models for Bearers and 'Attachment Circuits'-as-a-Service (ACaaS)" | Models for Bearers and 'Attachment Circuits'-as-a-Service (ACaaS)" | |||
(RFC9834). | (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 64 ¶ | 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 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 RFC 9543 Network | (L3VPN), or RFC 9543 Network Slice Service [RFC9543]). In order to | |||
Slice 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 230 ¶ | 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 RFC 9543 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 RFC 9543 Network Slice Services). | LxVPN or RFC 9543 Network Slice Services). | |||
skipping to change at line 331 ¶ | 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 401 ¶ | 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 444 ¶ | 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 642 ¶ | 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 2239 ¶ | 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 2368 ¶ | 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 4068 ¶ | 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 4111 ¶ | 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."; | |||
End of changes. 25 change blocks. | ||||
64 lines changed or deleted | 56 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. |