| Internet-Draft | L3NM YANG Model | September 2021 |
| Barguil, et al. | Expires 31 March 2022 | [Page] |
As a complement to the Layer 3 Virtual Private Network Service YANG data Model (L3SM), used for communication between customers and service providers, this document defines an L3VPN Network YANG Model (L3NM) that can be used for the provisioning of Layer 3 Virtual Private Network (VPN) services within a service provider network. The model provides a network-centric view of L3VPN services.¶
L3NM is meant to be used by a network controller to derive the configuration information that will be sent to relevant network devices. The model can also facilitate the communication between a service orchestrator and a network controller/orchestrator.¶
Please update these statements within the document with the RFC number to be assigned to this document:¶
Please update "RFC UUUU" to the RFC number to be assigned to I-D.ietf-opsawg-vpn-common.¶
Also, please update the "revision" date of the YANG module.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 31 March 2022.¶
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.¶
[RFC8299] defines a Layer 3 Virtual Private Network Service YANG data Model (L3SM) that can be used for communication between customers and service providers. Such a model focuses on describing the customer view of the Virtual Private Network (VPN) services and provides an abstracted view of the customer's requested services. That approach limits the usage of the L3SM to the role of a customer service model (as per [RFC8309]).¶
This document defines a YANG module called L3VPN Network Model (L3NM). The L3NM is aimed at providing a network-centric view of Layer 3 (L3) VPN services. This data model can be used to facilitate communication between the service orchestrator and the network controller/orchestrator by allowing for more network-centric information to be included. It enables further capabilities such as resource management or serves as a multi-domain orchestration interface, where logical resources (such as route targets or route distinguishers) must be coordinated.¶
This document uses the common VPN YANG module defined in [I-D.ietf-opsawg-vpn-common].¶
This document does not obsolete [RFC8299]. These two modules are used for similar objectives but with different scopes and views.¶
The L3NM YANG module was initially built with a prune and extend approach, taking as a starting points the YANG module described in [RFC8299]. Nevertheless, the L3NM is not defined as an augment to L3SM because a specific structure is required to meet network-oriented L3 needs.¶
Some information captured in the L3SM can be passed by the orchestrator in the L3NM (e.g., customer) or be used to feed some L3NM attributes (e.g., actual forwarding policies). Also, some information captured in the L3SM may be maintained locally within the orchestrator; which is in charge of maintaining the correlation between a customer view and its network instantiation. Likewise, some information captured and exposed using the L3NM can feed the service layer (e.g., capabilities) to drive VPN service order handling, and thus the L3SM.¶
Section 5.1 of [RFC8969] illustrates how the L3NM can be used within the network management automation architecture.¶
The L3NM does not attempt to address all deployment cases, especially those where the L3VPN connectivity is supported through the coordination of different VPNs in different underlying networks. More complex deployment scenarios involving the coordination of different VPN instances and different technologies to provide an end-to-end VPN connectivity are addressed by complementary YANG modules, e.g., [I-D.evenwu-opsawg-yang-composed-vpn].¶
The L3NM focuses on BGP Provider Edge (PE) based Layer 3 VPNs as described in [RFC4026][RFC4110][RFC4364] and Multicast VPNs as described in [RFC6037][RFC6513].¶
The YANG data model in this document conforms to the Network Management Datastore Architecture (NMDA) defined in [RFC8342].¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
This document assumes that the reader is familiar with the contents of [RFC6241], [RFC7950], [RFC8299], [RFC8309], and [RFC8453] and uses the terminology defined in those documents.¶
This document uses the term "network model" defined in Section 2.1 of [RFC8969].¶
The meaning of the symbols in the tree diagrams is defined in [RFC8340].¶
This document makes use of the following terms:¶
The document is aimed at modeling BGP PE-based VPNs in a service provider network, so the terms defined in [RFC4026] and [RFC4176] are used.¶
The following acronyms are used in the document:¶
Figure 1 depicts the reference architecture for the L3NM. The figure is an expansion of the architecture presented in Section 5 of [RFC8299]; it decomposes the box marked "orchestration" in that section into three separate functional components: Service Orchestration, Network Orchestration, and Domain Orchestration.¶
Although some deployments may choose to construct a monolithic orchestration component (covering both service and network matters), this document advocates for a clear separation between service and network orchestration components for the sake of better flexibility. Such design adheres to the L3VPN reference architecture defined in Section 1.3 of [RFC4176]. This separation relies upon a dedicated communication interface between these components and appropriate YANG modules that reflect network-related information. Such information is hidden to customers.¶
The intelligence for translating customer-facing information into network-centric one (and vice versa) is implementation specific.¶
The terminology from [RFC8309] is introduced to show the distinction between the customer service model, the service delivery model, the network configuration model, and the device configuration model. In that context, the "Domain Orchestration" and "Config Manager" roles may be performed by "Controllers".¶
+---------------+
| Customer |
+-------+-------+
Customer Service Model |
e.g., l3vpn-svc |
+-------+-------+
| Service |
| Orchestration |
+-------+-------+
Service Delivery Model |
l3vpn-ntw |
+-------+-------+
| Network |
| Orchestration |
+-------+-------+
Network Configuration Model |
+-----------+-----------+
| |
+--------+------+ +--------+------+
| Domain | | Domain |
| Orchestration | | Orchestration |
+---+-----------+ +--------+------+
Device | | |
Configuration | | |
Model | | |
+----+----+ | |
| Config | | |
| Manager | | |
+----+----+ | |
| | |
| NETCONF/CLI..................
| | |
+------------------------------------------------+
Network
The customer may use a variety of means to request a service that may trigger the instantiation of an L3NM. The customer may use the L3SM or more abstract models to request a service that relies upon an L3VPN service. For example, the customer may supply an IP Connectivity Provisioning Profile (CPP) that characterizes the requested service [RFC7297], an enhanced VPN (VPN+) service [I-D.ietf-teas-enhanced-vpn], or an IETF network slice service [I-D.ietf-teas-ietf-network-slices].¶
Note also that both the L3SM and the L3NM may be used in the context of the Abstraction and Control of TE Networks (ACTN) Framework [RFC8453]. Figure 2 shows the Customer Network Controller (CNC), the Multi-Domain Service Coordinator (MDSC), and the Provisioning Network Controller (PNC) components and the interfaces where L3SM/L3NM are used.¶
+----------------------------------+
| Customer |
| +-----------------------------+ |
| | CNC | |
| +-----------------------------+ |
+----+-----------------------+-----+
| |
| L3SM | L3SM
| |
+---------+---------+ +---------+---------+
| MDSC | | MDSC |
| +---------------+ | | (parent) |
| | Service | | +---------+---------+
| | Orchestration | | |
| +-------+-------+ | | L3NM
| | | |
| | L3NM | +---------+---------+
| | | | MDSC |
| +-------+-------+ | | (child) |
| | Network | | +---------+---------+
| | Orchestration | | |
| +---------------+ | |
+---------+---------+ |
| |
| Network Configuration |
| |
+------------+-------+ +---------+------------+
| Domain | | Domain |
| Controller | | Controller |
| +---------+ | | +---------+ |
| | PNC | | | | PNC | |
| +---------+ | | +---------+ |
+------------+-------+ +---------+------------+
| |
| Device Configuration |
| |
+----+---+ +----+---+
| Device | | Device |
+--------+ +--------+
The "ietf-vpn-common" module [I-D.ietf-opsawg-vpn-common] includes a set of identities, types, and groupings that are meant to be reused by VPN-related YANG modules independently of the layer (e.g., Layer 2, Layer 3) and the type of the module (e.g., network model, service model) including future revisions of existing models (e.g., [RFC8299] or [RFC8466]). The L3NM reuses these common types and groupings.¶
In order to avoid data duplication and to ease passing data between layers when required (service layer to network layer and vice versa), early versions of the L3NM reused many of the data nodes that are defined in [RFC8299]. Nevertheless, that approach was abandoned in favor of the "ietf-vpn-common" module because that initial design was interpreted as if the deployment of L3NM depends on L3SM, while this is not the case. For example, a service provider may decide to use the L3NM to build its L3VPN services without exposing the L3SM.¶
As discussed in Section 4, the L3NM is meant to manage L3VPN services within a service provider network. The module provides a network view of the service. Such a view is only visible within the service provider and is not exposed outside (to customers, for example). The following discusses how L3NM interfaces with other YANG modules:¶
L3NM is not a customer service model.¶
The internal view of the service (i.e., L3NM) may be mapped to an external view which is visible to customers: L3VPN Service YANG data Model (L3SM) [RFC8299].¶
The L3NM can be fed with inputs that are requested by customers, typically, relying upon an L3SM template. Concretely, some parts of the L3SM module can be directly mapped into L3NM while other parts are generated as a function of the requested service and local guidelines. Some other parts are local to the service provider and do not map directly to L3SM.¶
Note that the use of L3NM within a service provider does not assume nor preclude exposing the VPN service via the L3SM. This is deployment-specific. Nevertheless, the design of L3NM tries to align as much as possible with the features supported by the L3SM to ease grafting both L3NM and L3SM for the sake of highly automated VPN service provisioning and delivery.¶
L3NM is not a device model.¶
Once a global VPN service is captured by means of L3NM, the actual activation and provisioning of the VPN service will involve a variety of device modules to tweak the required functions for the delivery of the service. These functions are supported by the VPN nodes and can be managed using device YANG modules. A non-comprehensive list of such device YANG modules is provided below:¶
How L3NM is used to derive device-specific actions is implementation-specific.¶
This section provides a non-exhaustive list of examples to illustrate contexts where the L3NM can be used.¶
Enterprise L3VPNs are one of the most demanded services for carriers, and therefore, L3NM can be useful to automate the provisioning and maintenance of these VPNs. Templates and batch processes can be built, and as a result many parameters are needed for the creation from scratch of a VPN that can be abstracted to the upper Software-Defined Networking (SDN) [RFC7149][RFC7426] layer, but some manual intervention will still be required.¶
A common function that is supported by VPNs is the addition or removal of VPN nodes. Workflows can use the L3NM in these scenarios to add or prune nodes from the network data model as required.¶
The implementation of L3VPN services which span across administratively separated domains (i.e., that are under the administration of different management systems or controllers) requires some network resources to be synchronized between systems. Particularly, resources must be adequately managed in each domain to avoid broken configuration.¶
For example, route targets (RTs) shall be synchronized between PEs. When all PEs are controlled by the same management system, RT allocation can be performed by that management system. In cases where the service spans across multiple management systems, the task of allocating RTs has to be aligned across the domains, therefore, the network model must provide a way to specify RTs. In addition, route distinguishers (RDs) must also be synchronized to avoid collisions in RD allocation between separate management systems. An incorrect allocation might lead to the same RD and IP prefixes being exported by different PEs.¶
Multicast services over L3VPN can be implemented using dual PIM MVPNs (also known as, Draft Rosen model) [RFC6037] or Multiprotocol BGP (MP-BGP)-based MVPNs [RFC6513][RFC6514]. Both methods are supported and equally effective, but the main difference is that MBGP-based MVPN does not require multicast configuration on the service provider network. MBGP MVPNs employ the intra-autonomous system BGP control plane and PIM sparse mode as the data plane. The PIM state information is maintained between PEs using the same architecture that is used for unicast VPNs.¶
On the other hand, [RFC6037] has limitations such as reduced options for transport, control plane scalability, availability, operational inconsistency, and the need of maintaining state in the backbone. Because of these limitations, MBGP MVPN is the architectural model that has been taken as the base for implementing multicast service in L3VPNs. In this scenario, BGP is used to auto-discover MVPN PE members and the customer PIM signaling is sent across the provider's core through MP-BGP. The multicast traffic is transported on MPLS P2MP LSPs.¶
The L3NM ('ietf-l3vpn-ntw') is defined to manage L3VPNs in a service provider network. In particular, the 'ietf-l3vpn-ntw' module can be used to create, modify, and retrieve L3VPN services of a network.¶
The full tree diagram of the module can be generated using the "pyang" tool [PYANG]. That tree is not included here because it is too long (Section 3.3 of [RFC8340]). Instead, subtrees are provided for the reader's convenience.¶
The 'ietf-l3vpn-ntw' module uses two main containers: 'vpn-services' and 'vpn-profiles' (see Figure 3).¶
The 'vpn-profiles' container is used by the provider to maintain a set of common VPN profiles that apply to one or several VPN services (Section 7.2).¶
The 'vpn-services' container maintains the set of VPN services managed within the service provider network. 'vpn-service' is the data structure that abstracts a VPN service (Section 7.3).¶
module: ietf-l3vpn-ntw
+--rw l3vpn-ntw
+--rw vpn-profiles
| ...
+--rw vpn-services
+--rw vpn-service* [vpn-id]
...
+--rw vpn-nodes
+--rw vpn-node* [vpn-node-id]
...
+--rw vpn-network-accesses
+--rw vpn-network-access* [id]
...
Some of the data nodes are keyed by the address-family. For the sake of data representation compactness, It is RECOMMENDED to use the dual-stack address-family for data nodes that have the same value for both IPv4 and IPv6. If, for some reasons, a data node is present for both dual-stack and IPv4 (or IPv6), the value that is indicated under dual-stack takes precedence over the one that is indicated under IPv4 (or IPv6).¶
The 'vpn-profiles' container (Figure 4) allows the VPN service provider to define and maintain a set of VPN profiles [I-D.ietf-opsawg-vpn-common] that apply to one or several VPN services.¶
+--rw l3vpn-ntw
+--rw vpn-profiles
| +--rw valid-provider-identifiers
| +--rw external-connectivity-identifier* [id]
| | {external-connectivity}?
| | +--rw id string
| +--rw encryption-profile-identifier* [id]
| | +--rw id string
| +--rw qos-profile-identifier* [id]
| | +--rw id string
| +--rw bfd-profile-identifier* [id]
| | +--rw id string
| +--rw forwarding-profile-identifier* [id]
| | +--rw id string
| +--rw routing-profile-identifier* [id]
| +--rw id string
+--rw vpn-services
...
This document does not make any assumption about the exact definition of these profiles. The exact definition of the profiles is local to each VPN service provider. The model only includes an identifier to these profiles in order to facilitate identifying and binding local policies when building a VPN service. As shown in Figure 4, the following identifiers can be included:¶
The 'vpn-service' is the data structure that abstracts a VPN service in the service provider network. Each 'vpn-service' is uniquely identified by an identifier: 'vpn-id'. Such 'vpn-id' is only meaningful locally (e.g., the network controller). The subtree of the 'vpn-services' is shown in Figure 5.¶
+--rw l3vpn-ntw
+--rw vpn-profiles
| ...
+--rw vpn-services
+--rw vpn-service* [vpn-id]
+--rw vpn-id vpn-common:vpn-id
+--rw vpn-name? string
+--rw vpn-description? string
+--rw customer-name? string
+--rw parent-service-id? vpn-common:vpn-id
+--rw vpn-type? identityref
+--rw vpn-service-topology? identityref
+--rw status
| +--rw admin-status
| | +--rw status? identityref
| | +--rw last-change? yang:date-and-time
| +--ro oper-status
| +--ro status? identityref
| +--ro last-change? yang:date-and-time
+--rw vpn-instance-profiles
| ...
+--rw underlay-transport
| +-- (type)?
| +--:(abstract)
| | +-- transport-instance-id? string
| +--:(protocol)
| +-- protocol* identityref
+--rw external-connectivity
| {external-connectivity}
| +--rw (profile)?
| +--:(profile)
| +--rw profile-name? leafref
+--rw vpn-nodes
...
The description of the VPN service data nodes that are depicted in Figure 5 are as follows:¶
Includes a textual description of the service.¶
The internal structure of a VPN description is local to each VPN service provider.¶
Is used to track the service status of a given VPN service. Both operational and administrative status are maintained together with a timestamp. For example, a service can be created, but not put into effect.¶
Administrative and operational status can be used as a trigger to detect service anomalies. For example, a service that is declared at the service layer as being active but still inactive at the network layer may be an indication that network provision actions are needed to align the observed service status with the expected service status.¶
Defines reusable parameters for the same 'vpn-service'.¶
More details are provided in Section 7.4.¶
Describes the preference for the transport technology to carry the traffic of the VPN service. This preference is especially useful in networks with multiple domains and Network-to-Network Interface (NNI) types. The underlay transport can be expressed as an abstract transport instance (e.g., an identifier of a VPN+ instance, a virtual network identifier, or a network slice name) or as an ordered list of the actual protocols to be enabled in the network.¶
A rich set of protocol identifiers that can be used to refer to an underlay transport are defined in [I-D.ietf-opsawg-vpn-common].¶
Indicates whether/how external connectivity is provided to the VPN service. For example, a service provider may provide an external connectivity to a VPN customer (e.g., to a public cloud). Such service may involve tweaking both filtering and NAT rules (e.g., bind a Virtual Routing and Forwarding (VRF) interface with a NAT instance as discussed in Section 2.10 of [RFC8512]). These added value features may be bound to all or a subset of network accesses. Some of these added value features may be implemented in a PE or in other nodes than PEs (e.g., a P node or even a dedicated node that hosts the NAT function).¶
Only a pointer to a local profile that defines the external connectivity feature is supported in this document.¶
Is an abstraction that represents a set of policies applied to a network node and that belong to a single 'vpn-service'. A VPN service is typically built by adding instances of 'vpn-node' to the 'vpn-nodes' container.¶
A 'vpn-node' contains 'vpn-network-accesses', which are the interfaces attached to the VPN by which the customer traffic is received. Therefore, the customer sites are connected to the 'vpn-network-accesses'.¶
Note that, as this is a network data model, the information about customers sites is not required in the model. Such information is rather relevant in the L3SM. Whether that information is included in the L3NM, e.g., to populate the various 'description' data node is implementation specific.¶
More details are provided in Section 7.5.¶
VPN instance profiles are meant to factorize data nodes that are used at many levels of the model. Generic VPN instance profiles are defined at the VPN service level and then called at the VPN node and VPN network access levels. Each VPN instance profile is identified by 'profile-id'. This identifier is then referenced for one or multiple VPN nodes (Section 7.5) so that the controller can identify generic resources (e.g., RTs and RDs) to be configured for a given VRF.¶
The subtree of 'vpn-instance-profile' is shown in Figure 6.¶
+--rw l3vpn-ntw
+--rw vpn-profiles
| ...
+--rw vpn-services
+--rw vpn-service* [vpn-id]
+--rw vpn-id vpn-common:vpn-id
...
+--rw vpn-instance-profiles
| +--rw vpn-instance-profile* [profile-id]
| +--rw profile-id string
| +--rw role? identityref
| +--rw local-as? inet:as-number
| | {vpn-common:rtg-bgp}?
| +--rw (rd-choice)?
| | +--:(directly-assigned)
| | | +--rw rd?
| | | rt-types:route-distinguisher
| | +--:(directly-assigned-suffix)
| | | +--rw rd-suffix? uint16
| | +--:(auto-assigned)
| | | +--rw rd-auto
| | | +--rw (auto-mode)?
| | | | +--:(from-pool)
| | | | | +--rw rd-pool-name? string
| | | | +--:(full-auto)
| | | | +--rw auto? empty
| | | +--ro auto-assigned-rd?
| | | rt-types:route-distinguisher
| | +--:(auto-assigned-suffix)
| | | +--rw rd-auto-suffix
| | | +--rw (auto-mode)?
| | | | +--:(from-pool)
| | | | | +--rw rd-pool-name? string
| | | | +--:(full-auto)
| | | | +--rw auto? empty
| | | +--ro auto-assigned-rd-suffix? uint16
| | +--:(no-rd)
| | +--rw no-rd? empty
| +--rw address-family* [address-family]
| | +--rw address-family identityref
| | +--rw vpn-targets
| | | +--rw vpn-target* [id]
| | | | +--rw id int8
| | | | +--rw route-targets* [route-target]
| | | | | +--rw route-target
| | | | | rt-types:route-target
| | | | +--rw route-target-type
| | | | rt-types:route-target-type
| | | +--rw vpn-policies
| | | +--rw import-policy? string
| | | +--rw export-policy? string
| | +--rw maximum-routes* [protocol]
| | +--rw protocol identityref
| | +--rw maximum-routes? uint32
| +--rw multicast {vpn-common:multicast}?
| ...
The description of the listed data nodes is as follows:¶
As defined in [I-D.ietf-opsawg-vpn-common], the following RD assignment modes are supported: direct assignment, automatic assignment from a given pool, automatic assignment, and no assignment. For illustration purposes, the following modes can be used in the deployment cases:¶
Also, the module accommodates deployments where only the Assigned Number subfield of RDs (Section 4.2 of [RFC4364]) is assigned from a pool while the Administrator subfield is set to, e.g., the Router ID that is assigned to a VPN node. The module supports these modes for managing the Assigned Number subfield: explicit assignment, auto-assignment from a pool, and full auto-assignment.¶
Includes a set of per-address family data nodes:¶
The 'vpn-node' is an abstraction that represents a set of common policies applied on a given network node (typically, a PE) and belong to one L3VPN service. The 'vpn-node' includes a parameter to indicate the network node on which it is applied. In the case that the 'ne-id' points to a specific PE, the 'vpn-node' will likely be mapped into a VRF in the node. However, the model also allows pointing to an abstract node. In this case, the network controller will decide how to split the 'vpn-node' into VRFs.¶
+--rw l3vpn-ntw
+--rw vpn-profiles
| ...
+--rw vpn-services
+--rw vpn-service* [vpn-id]
...
+--rw vpn-nodes
+--rw vpn-node* [vpn-node-id]
+--rw vpn-node-id vpn-common:vpn-id
+--rw description? string
+--rw ne-id? string
+--rw local-as? inet:as-number
| {vpn-common:rtg-bgp}?
+--rw router-id? rt-types:router-id
+--rw active-vpn-instance-profiles
| +--rw vpn-instance-profile* [profile-id]
| +--rw profile-id leafref
| +--rw router-id* [address-family]
| | +--rw address-family identityref
| | +--rw router-id? inet:ip-address
| +--rw local-as? inet:as-number
| | {vpn-common:rtg-bgp}?
| +--rw (rd-choice)?
| | ....
| +--rw address-family* [address-family]
| | +--rw address-family identityref
| | | ...
| | +--rw vpn-targets
| | | ...
| | +--rw maximum-routes* [protocol]
| | ...
| +--rw multicast {vpn-common:multicast}?
| ...
+--rw msdp {msdp}?
| +--rw peer? inet:ipv4-address
| +--rw local-address? inet:ipv4-address
| +--rw status
| +--rw admin-status
| | +--rw status? identityref
| | +--rw last-change? yang:date-and-time
| +--ro oper-status
| +--ro status? identityref
| +--ro last-change? yang:date-and-time
+--rw groups
| +--rw group* [group-id]
| +--rw group-id string
+--rw status
| +--rw admin-status
| | +--rw status? identityref
| | +--rw last-change? yang:date-and-time
| +--ro oper-status
| +--ro status? identityref
| +--ro last-change? yang:date-and-time
+--rw vpn-network-accesses
...
In reference to the subtree shown in Figure 7, the description of VPN node data nodes is as follows:¶
Lists the set of active VPN instance profiles for this VPN node. Concretely, one or more VPN instance profiles that are defined at the VPN service level can be enabled at the VPN node level; each of these profiles is uniquely identified by means of 'profile-id'. The structure of 'active-vpn-instance-profiles' is the same as the one discussed in Section 7.4 except 'router-id'. The value of 'router-id' indicated under 'active-vpn-instance-profiles' takes precedence over the 'router-id' under the 'vpn-node' for the indicated address family. For example, Router IDs can be configured per address family. This capability can be used, for example, to configure an IPv6 address as a Router ID when such capability is supported by involved routers.¶
Values defined in 'active-vpn-instance-profiles' overrides the ones defined in the VPN service level. An example is shown in Appendix A.3.¶
Represents the point to which sites are connected.¶
Note that, unlike in the L3SM, the L3NM does not need to model the customer site, only the points where the traffic from the site are received (i.e., the PE side of PE-CE connections). Hence, the VPN network access contains the connectivity information between the provider's network and the customer premises. The VPN profiles ('vpn-profiles') have a set of routing policies that can be applied during the service creation.¶
See Section 7.6 for more details.¶
The 'vpn-network-access' includes a set of data nodes that describe the access information for the traffic that belongs to a particular L3VPN (Figure 8).¶
...
+--rw vpn-nodes
+--rw vpn-node* [vpn-node-id]
...
+--rw vpn-network-accesses
+--rw vpn-network-access* [id]
+--rw id vpn-common:vpn-id
+--rw interface-id? string
+--rw description? string
+--rw vpn-network-access-type? identityref
+--rw vpn-instance-profile? leafref
+--rw status
| +--rw admin-status
| | +--rw status? identityref
| | +--rw last-change? yang:date-and-time
| +--ro oper-status
| +--ro status? identityref
| +--ro last-change? yang:date-and-time
+--rw connection
| ...
+--rw ip-connection
| ...
+--rw routing-protocols
| ...
+--rw oam
| ...
+--rw security
| ...
+--rw service
...
In reference to the subtree depicted in Figure 8, a 'vpn-network-access' includes the following data nodes:¶
Is used to select the type of network interface to be deployed in the devices. The available defined values are:¶
The 'connection' container represents the layer 2 connectivity to the L3VPN for a particular VPN network access. As shown in the tree depicted in Figure 9, the 'connection' container defines protocols and parameters to enable such connectivity at layer 2.¶
The traffic can enter the VPN with or without encapsulation (e.g., VLAN, QinQ). The 'encapsulation' container specifies the layer 2 encapsulation to use (if any) and allows to configure the relevant tags.¶
The interface that is attached to the L3VPN is identified by the 'interface-id' at the 'vpn-network-access' level. From a network model perspective, it is expected that the 'interface-id' is sufficient to identify the interface. However, specific layer 2 sub-interfaces may be required to be configured in some implementations/deployments. Such a layer 2 specific interface can be included in 'l2-termination-point'.¶
If a layer 2 tunnel is needed to terminate the service in the CE-PE connection, the 'l2-tunnel-service' container is used to specify the required parameters to set such tunneling service (e.g., VPLS, VXLAN). An identity, called 'l2-tunnel-type', is defined for layer 2 tunnel selection. The container can also identify the pseudowire (Section 6.1 of [RFC8077]).¶
As discussed in Section 7.6, 'l2vpn-id' is used to identify the L2VPN service that is associated with an IRB interface.¶
To accommodate implementations that require internal bridging, a local bridge reference can be specified in 'local-bridge-reference'. Such a reference may be a local bridge domain.¶
A site, as per [RFC4176] represents a VPN customer's location that is connected to the service provider network via a CE-PE link, which can access at least one VPN. The connection from the site to the service provider network is the bearer. Every site is associated with a list of bearers. A bearer is the layer two connection with the site. In the L3NM, it is assumed that the bearer has been allocated by the service provider at the service orchestration stage. The bearer is associated to a network element and a port. Hence, a bearer is just a 'bearer-reference' to allow the association between a service request (e.g., L3SM) and L3NM.¶
The L3NM can be used to create a LAG interface for a given L3VPN service ('lag-interface') [IEEE802.1AX]. Such a LAG interface can be referenced under 'interface-id' (Section 7.6).¶
...
+--rw connection
| +--rw encapsulation
| | +--rw type? identityref
| | +--rw dot1q {vpn-common:dot1q}?
| | | +--rw tag-type? identityref
| | | +--rw cvlan-id? uint16
| | +--rw priority-tagged
| | | +--rw tag-type? identityref
| | +--rw qinq {vpn-common:qinq}?
| | +--rw tag-type? identityref
| | +--rw svlan-id uint16
| | +--rw cvlan-id uint16
| +--rw (l2-service)?
| | +--:(l2-tunnel-service)
| | | +--rw l2-tunnel-service
| | | +--rw type? identityref
| | | +--rw pseudowire
| | | | +--rw vcid? uint32
| | | | +--rw far-end? union
| | | +--rw vpls
| | | | +--rw vcid? uint32
| | | | +--rw far-end* union
| | | +--rw vxlan {vpn-common:vxlan}?
| | | +--rw vni-id uint32
| | | +--rw peer-mode? identityref
| | | +--rw peer-ip-address* inet:ip-address
| | +--:(l2vpn)
| | +--rw l2vpn-id? vpn-common:vpn-id
| +--rw l2-termination-point? string
| +--rw local-bridge-reference? string
| +--rw bearer-reference? string
| | {vpn-common:bearer-reference}?
| +--rw lag-interface {vpn-common:lag-interface}?
| +--rw lag-interface-id? string
| +--rw member-link-list
| +--rw member-link* [name]
| +--rw name string
...
This container is used to group Layer 3 connectivity information, particularly the IP addressing information, of a VPN network access. The allocated address represents the PE interface address configuration. Note that a distinct layer 3 interface other than the one indicated under the 'connection' container may be needed to terminate the layer 3 service. The identifier of such interface is included in 'l3-termination-point'. For example, this data node can be used to carry the identifier of a bridge domain interface.¶
As shown in Figure 10, the 'ip-connection' container can include IPv4, IPv6, or both if dual-stack is enabled.¶
...
+--rw vpn-network-accesses
+--rw vpn-network-access* [id]
...
+--rw ip-connection
| +--rw l3-termination-point? string
| +--rw ipv4 {vpn-common:ipv4}?
| | ...
| +--rw ipv6 {vpn-common:ipv6}?
| ...
...
For both IPv4 and IPv6, the IP connection supports three IP address assignment modes for customer addresses: provider DHCP, DHCP relay, and static addressing. Note that for the IPv6 case, SLAAC [RFC4862] can be used. For both IPv4 and IPv6, 'address-allocation-type' is used to indicate the IP address allocation mode to activate for a given VPN network access.¶
When 'address-allocation-type' is set to 'provider-dhcp', DHCP assignments can be made locally or by an external DHCP server. Such as behavior is controlled by setting 'dhcp-service-type'.¶
Figure 11 shows the structure of the dynamic IPv4 address assignment (i.e., by means of DHCP).¶
...
+--rw ip-connection
| +--rw l3-termination-point? string
| +--rw ipv4 {vpn-common:ipv4}?
| | +--rw local-address? inet:ipv4-address
| | +--rw prefix-length? uint8
| | +--rw address-allocation-type? identityref
| | +--rw (allocation-type)?
| | +--:(provider-dhcp)
| | | +--rw dhcp-service-type? enumeration
| | | +--rw (service-type)?
| | | +--:(relay)
| | | | +--rw server-ip-address*
| | | | inet:ipv4-address
| | | +--:(server)
| | | +--rw (address-assign)?
| | | +--:(number)
| | | | +--rw number-of-dynamic-address?
| | | | uint16
| | | +--:(explicit)
| | | +--rw customer-addresses
| | | +--rw address-pool* [pool-id]
| | | +--rw pool-id string
| | | +--rw start-address
| | | | inet:ipv4-address
| | | +--rw end-address?
| | | inet:ipv4-address
| | +--:(dhcp-relay)
| | | +--rw customer-dhcp-servers
| | | +--rw server-ip-address* inet:ipv4-address
| | +--:(static-addresses)
| | ...
...
Figure 12 shows the structure of the dynamic IPv6 address assignment (i.e., DHCPv6 and/or SLAAC). Note that if 'address-allocation-type' is set to 'slaac', the Prefix Information option of Router Advertisements that will be issued for SLAAC purposes, will carry the IPv6 prefix that is determined by 'local-address' and 'prefix-length'. For example, if 'local-address' is set to '2001:db8:0:1::1' and 'prefix-length' is set to '64', the IPv6 prefix that will be used is '2001:db8:0:1::/64'.¶
...
+--rw ip-connection
| +--rw l3-termination-point? string
| +--rw ipv4 {vpn-common:ipv4}?
| | ...
| +--rw ipv6 {vpn-common:ipv6}?
| +--rw local-address? inet:ipv6-address
| +--rw prefix-length? uint8
| +--rw address-allocation-type? identityref
| +--rw (allocation-type)?
| +--:(provider-dhcp)
| | +--rw provider-dhcp
| | +--rw dhcp-service-type?
| | | enumeration
| | +--rw (service-type)?
| | +--:(relay)
| | | +--rw server-ip-address*
| | | inet:ipv6-address
| | +--:(server)
| | +--rw (address-assign)?
| | +--:(number)
| | | +--rw number-of-dynamic-address?
| | | uint16
| | +--:(explicit)
| | +--rw customer-addresses
| | +--rw address-pool* [pool-id]
| | +--rw pool-id string
| | +--rw start-address
| | | inet:ipv6-address
| | +--rw end-address?
| | inet:ipv6-address
| +--:(dhcp-relay)
| | +--rw customer-dhcp-servers
| | +--rw server-ip-address*
| | inet:ipv6-address
| +--:(static-addresses)
| ...
In the case of the static addressing (Figure 13), the model supports the assignment of several IP addresses in the same 'vpn-network-access'. To identify which of the addresses is the primary address of a connection, the 'primary-address' reference MUST be set with the corresponding 'address-id'.¶
...
+--rw ip-connection
| +--rw l3-termination-point? string
| +--rw ipv4 {vpn-common:ipv4}?
| | +--rw address-allocation-type? identityref
| | +--rw (allocation-type)?
| | ...
| | +--:(static-addresses)
| | +--rw primary-address? -> ../address/address-id
| | +--rw address* [address-id]
| | +--rw address-id string
| | +--rw customer-address? inet:ipv4-address
| +--rw ipv6 {vpn-common:ipv6}?
| +--rw address-allocation-type? identityref
| +--rw (allocation-type)?
| ...
| +--:(static-addresses)
| +--rw primary-address? -> ../address/address-id
| +--rw address* [address-id]
| +--rw address-id string
| +--rw customer-address? inet:ipv6-address
...
A VPN service provider can configure one or more routing protocols associated with a particular 'vpn-network-access'. Such routing protocols are enabled between the PE and the CE. Each instance is uniquely identified to accommodate scenarios where multiple instances of the same routing protocol have to be configured on the same link.¶
The subtree of the 'routing-protocols' is shown in Figure 14.¶
...
+--rw vpn-network-accesses
+--rw vpn-network-access* [id]
...
+--rw routing-protocols
| +--rw routing-protocol* [id]
| +--rw id string
| +--rw type? identityref
| +--rw routing-profiles* [id]
| | +--rw id leafref
| | +--rw type? identityref
| +--rw static
| | ...
| +--rw bgp {vpn-common:rtg-bgp}?
| | ...
| +--rw ospf {vpn-common:rtg-ospf}?
| | ...
| +--rw isis {vpn-common:rtg-isis}?
| | ...
| +--rw rip {vpn-common:rtg-rip}?
| | ...
| +--rw vrrp {vpn-common:rtg-vrrp}?
| ...
+--rw security
...
Multiple routing instances can be defined; each uniquely identified by an 'id'. The type of routing instance is indicated in 'type'. The values of these attributes are those defined in [I-D.ietf-opsawg-vpn-common] ('routing-protocol-type' identity).¶
Configuring multiple instances of the same routing protocol does not automatically imply that, from a device configuration perspective, there will be parallel instances (e.g., multiple processes) running on the PE-CE link. It is up to each implementation (typically, network orchestration shown in Figure 1) to decide about the appropriate configuration as a function of underlying capabilities and service provider operational guidelines. As an example, when multiple BGP peers need to be implemented, multiple instances of BGP must be configured as part of this model. However, from a device configuration point of view, this could be implemented as:¶
Routing configuration does not include low-level policies. Such policies are handled at the device configuration level. Local policies of a service provider (e.g., filtering) are implemented as part of the device configuration; these are not captured in the L3NM, but the model allows local profiles to be associated with routing instances ('routing-profiles'). Note that these routing profiles can be scoped to capture parameters that are globally applied to all L3VPN services within a service provider network, while customized L3VPN parameters are captured by means of the L3NM. The provisioning of an L3VPN service will, thus, rely upon the instantiation of these global routing profiles and the customized L3NM.¶
The L3NM supports the configuration of one or more IPv4/IPv6 static routes. Since the same structure is used for both IPv4 and IPv6, it was considered to have one single container to group both static entries independently of their address family, but that design was abandoned to ease the mapping with the structure in [RFC8299].¶
The L3NM supports the configuration of one or more IPv4/IPv6 static routes. Since the same structure is used for both IPv4 and IPv6, it was considered to have one single container to group both static entries independently of their address family, but that design was abandoned to ease the mapping with the structure in [RFC8299].¶
...
+--rw routing-protocols
| +--rw routing-protocol* [id]
| ...
| +--rw static
| | +--rw cascaded-lan-prefixes
| | +--rw ipv4-lan-prefixes*
| | | [lan next-hop]
| | | {vpn-common:ipv4}?
| | | +--rw lan inet:ipv4-prefix
| | | +--rw lan-tag? string
| | | +--rw next-hop union
| | | +--rw bfd-enable? boolean
| | | +--rw metric? uint32
| | | +--rw preference? uint32
| | | +--rw status
| | | +--rw admin-status
| | | | +--rw status? identityref
| | | | +--rw last-change? yang:date-and-time
| | | +--ro oper-status
| | | +--ro status? identityref
| | | +--ro last-change? yang:date-and-time
| | +--rw ipv6-lan-prefixes*
| | [lan next-hop]
| | {vpn-common:ipv6}?
| | +--rw lan inet:ipv6-prefix
| | +--rw lan-tag? string
| | +--rw next-hop union
| | +--rw bfd-enable? boolean
| | +--rw metric? uint32
| | +--rw preference? uint32
| | +--rw status
| | +--rw admin-status
| | | +--rw status? identityref
| | | +--rw last-change? yang:date-and-time
| | +--ro oper-status
| | +--ro status? identityref
| | +--ro last-change? yang:date-and-time
...
As depicted in Figure 15, the following data nodes can be defined for a given IP prefix:¶
The L3NM allows the configuration of a BGP neighbor, including a set for parameters that are pertinent to be tweaked at the network level for service customization purposes. The 'bgp' container does not aim to include every BGP parameter; a comprehensive set of parameters belongs more to the BGP device model. The following data nodes are captured in¶
...
+--rw routing-protocols
| +--rw routing-protocol* [id]
| ...
| +--rw bgp {vpn-common:rtg-bgp}?
| | +--rw description? string
| | +--rw local-as? inet:as-number
| | +--rw peer-as inet:as-number
| | +--rw address-family? identityref
| | +--rw local-address? union
| | +--rw neighbor* inet:ip-address
| | +--rw multihop? uint8
| | +--rw as-override? boolean
| | +--rw allow-own-as? uint8
| | +--rw prepend-global-as? boolean
| | +--rw send-default-route? boolean
| | +--rw site-of-origin? rt-types:route-origin
| | +--rw ipv6-site-of-origin? rt-types:ipv6-route-origin
| | +--rw redistribute-connected* [address-family]
| | | +--rw address-family identityref
| | | +--rw enable? boolean
| | +--rw bgp-max-prefix
| | | +--rw max-prefix? uint32
| | | +--rw warning-threshold? decimal64
| | | +--rw violate-action? enumeration
| | | +--rw restart-timer? uint32
| | +--rw bgp-timers
| | | +--rw keepalive? uint16
| | | +--rw hold-time? uint16
| | +--rw authentication
| | | +--rw enable? boolean
| | | +--rw keying-material
| | | +--rw (option)?
| | | +--:(ao)
| | | | +--rw enable-ao? boolean
| | | | +--rw ao-keychain? key-chain:key-chain-ref
| | | +--:(md5)
| | | | +--rw md5-keychain? key-chain:key-chain-ref
| | | +--:(explicit)
| | | | +--rw key-id? uint32
| | | | +--rw key? string
| | | | +--rw crypto-algorithm? identityref
| | | +--:(ipsec)
| | | +--rw sa? string
| | +--rw status
| | +--rw admin-status
| | | +--rw status? identityref
| | | +--rw last-change? yang:date-and-time
| | +--ro oper-status
| | +--ro status? identityref
| | +--ro last-change? yang:date-and-time
...
Figure 16. It is up to the implementation (e.g., network orchestrator) to derive the corresponding BGP device configuration:¶
Indicates the address-family of the peer. It can be set to IPv4, IPv6, or dual-stack.¶
This address family will be used together with the 'vpn-type' to derive the appropriate Address Family Identifiers (AFIs)/Subsequent Address Family Identifiers (SAFIs) that will be part of the derived device configurations (e.g., Unicast IPv4 MPLS L3VPN (AFI,SAFI = 1,128) defined in Section 4.3.4 of [RFC4364]).¶
Controls the behavior when a prefix maximum is reached.¶
The module adheres to the recommendations in Section 13.2 of [RFC4364] as it allows enabling TCP-AO [RFC5925] and accommodates the installed base that makes use of MD5. In addition, the module includes a provision for the use of IPsec.¶
This version of the L3NM assumes that TCP-AO specific parameters are preconfigured as part of the key-chain that is referenced in the L3NM. No assumption is made about how such a key-chain is pre-configured. However, the structure of the key-chain should cover data nodes beyond those in [RFC8177], mainly SendID and RecvID (Section 3.1 of [RFC5925]).¶
OSPF can be configured to run as a routing protocol on the 'vpn-network-access'.¶
...
+--rw routing-protocols
| +--rw routing-protocol* [id]
| ...
| +--rw ospf {vpn-common:rtg-ospf}?
| | +--rw address-family? identityref
| | +--rw area-id yang:dotted-quad
| | +--rw metric? uint16
| | +--rw sham-links {vpn-common:rtg-ospf-sham-link}?
| | | +--rw sham-link* [target-site]
| | | +--rw target-site
| | | | vpn-common:vpn-id
| | | +--rw metric? uint16
| | +--rw max-lsa? uint32
| | +--rw authentication
| | | +--rw enable? boolean
| | | +--rw keying-material
| | | +--rw (option)?
| | | +--:(auth-key-chain)
| | | | +--rw key-chain?
| | | | key-chain:key-chain-ref
| | | +--:(auth-key-explicit)
| | | | +--rw key-id? uint32
| | | | +--rw key? string
| | | | +--rw crypto-algorithm?
| | | | identityref
| | | +--:(ipsec)
| | | +--rw sa? string
| | +--rw status
| | +--rw admin-status
| | | +--rw status? identityref
| | | +--rw last-change? yang:date-and-time
| | +--ro oper-status
| | +--ro status? identityref
| | +--ro last-change? yang:date-and-time
...
The following data nodes are captured in Figure 17:¶
Indicates whether IPv4, IPv6, or both address families are to be activated.¶
When the IPv4 or dual-stack address-family is requested, it is up to the implementation (e.g., network orchestrator) to decide whether OSPFv2 [RFC4577] or OSPFv3 [RFC6565] is used to announce IPv4 routes. Such decision will be typically reflected in the device configurations that will be derived to implement the L3VPN.¶
The model (Figure 18) allows the user to configure IS-IS [ISO10589][RFC1195][RFC5308] to run on the 'vpn-network-access' interface.¶
...
+--rw routing-protocols
| +--rw routing-protocol* [id]
| ...
| +--rw isis {vpn-common:rtg-isis}?
| | +--rw address-family? identityref
| | +--rw area-address area-address
| | +--rw level? identityref
| | +--rw metric? uint16
| | +--rw mode? enumeration
| | +--rw authentication
| | | +--rw enable? boolean
| | | +--rw keying-material
| | | +--rw (option)?
| | | +--:(auth-key-chain)
| | | | +--rw key-chain?
| | | | key-chain:key-chain-ref
| | | +--:(auth-key-explicit)
| | | +--rw key-id? uint32
| | | +--rw key? string
| | | +--rw crypto-algorithm? identityref
| | +--rw status
| | +--rw admin-status
| | | +--rw status? identityref
| | | +--rw last-change? yang:date-and-time
| | +--ro oper-status
| | +--ro status? identityref
| | +--ro last-change? yang:date-and-time
...
The following IS-IS data nodes are supported:¶
The model (As shown in Figure 19) allows the user to configure RIP to run on the 'vpn-network-access' interface.¶
...
+--rw routing-protocols
| +--rw routing-protocol* [id]
| ...
| +--rw rip {vpn-common:rtg-rip}?
| | +--rw address-family? identityref
| | +--rw timers
| | | +--rw update-interval? uint16
| | | +--rw invalid-interval? uint16
| | | +--rw holddown-interval? uint16
| | | +--rw flush-interval? uint16
| | +--rw neighbor* inet:ip-address
| | +--rw default-metric? uint8
| | +--rw authentication
| | | +--rw enable? boolean
| | | +--rw keying-material
| | | +--rw (option)?
| | | +--:(auth-key-chain)
| | | | +--rw key-chain?
| | | | key-chain:key-chain-ref
| | | +--:(auth-key-explicit)
| | | +--rw key? string
| | | +--rw crypto-algorithm? identityref
| | +--rw status
| | +--rw admin-status
| | | +--rw status? identityref
| | | +--rw last-change? yang:date-and-time
| | +--ro oper-status
| | +--ro status? identityref
| | +--ro last-change? yang:date-and-time
...
Figure 19, the following RIP data nodes are supported:¶
Indicates the following timers:¶
The model (The following data nodes are supported:Figure 20) allows enabling VRRP on the 'vpn-network-access' interface.¶
...
+--rw routing-protocols
| +--rw routing-protocol* [id]
| ...
| +--rw vrrp {vpn-common:rtg-vrrp}?
| +--rw address-family* identityref
| +--rw vrrp-group? uint8
| +--rw backup-peer? inet:ip-address
| +--rw virtual-ip-address* inet:ip-address
| +--rw priority? uint8
| +--rw ping-reply? boolean
| +--rw status
| +--rw admin-status
| | +--rw status? identityref
| | +--rw last-change? yang:date-and-time
| +--ro oper-status
| +--ro status? identityref
| +--ro last-change? yang:date-and-time
...
Note that no authentication data node is included for VRRP as there isn't currently any type of VRRP authentication (see Section 9 of [RFC5798]).¶
This container (Figure 21) defines the Operations, Administration, and Maintenance (OAM) mechanisms used for a VPN network access. In the current version of the L3NM, only BFD is supported.¶
...
+--rw oam
| +--rw bfd {vpn-common:bfd}?
| +--rw session-type? identityref
| +--rw desired-min-tx-interval? uint32
| +--rw required-min-rx-interval? uint32
| +--rw local-multiplier? uint8
| +--rw holdtime? uint32
| +--rw profile? leafref
| +--rw authentication!
| | +--rw key-chain? key-chain:key-chain-ref
| | +--rw meticulous? boolean
| +--rw status
| +--rw admin-status
| | +--rw status? identityref
| | +--rw last-change? yang:date-and-time
| +--ro oper-status
| +--ro status? identityref
| +--ro last-change? yang:date-and-time
...
The following OAM data nodes can be specified:¶
The 'security' container specifies the authentication and the encryption to be applied for a given VPN network access traffic. As depicted in the subtree shown in Figure 22, the L3NM can be used to directly control the encryption to put in place (e.g., Layer 2 or Layer 3 encryption) or invoke a local encryption profile.¶
...
+--rw vpn-services
+--rw vpn-service* [vpn-id]
...
+--rw vpn-nodes
+--rw vpn-node* [vpn-node-id]
...
+--rw vpn-network-accesses
+--rw vpn-network-access* [id]
...
+--rw security
| +--rw encryption {vpn-common:encryption}?
| | +--rw enabled? boolean
| | +--rw layer? enumeration
| +--rw encryption-profile
| +--rw (profile)?
| +--:(provider-profile)
| | +--rw profile-name? leafref
| +--:(customer-profile)
| +--rw customer-key-chain?
| kc:key-chain-ref
+--rw service
...
The 'service' container specifies the service parameters to apply for a given VPN network access (Figure 23).¶
...
+--rw vpn-network-accesses
+--rw vpn-network-access* [id]
...
+--rw service
+--rw inbound-bandwidth? uint64 {vpn-common:inbound-bw}?
+--rw outbound-bandwidth? uint64 {vpn-common:outbound-bw}?
+--rw mtu? uint32
+--rw qos {vpn-common:qos}?
| ...
+--rw carriers-carrier
| {vpn-common:carriers-carrier}?
| +--rw signaling-type? enumeration
+--rw ntp
| +--rw broadcast? enumeration
| +--rw auth-profile
| | +--rw profile-id? string
| +--rw status
| +--rw admin-status
| | +--rw status? identityref
| | +--rw last-change? yang:date-and-time
| +--ro oper-status
| +--ro status? identityref
| +--ro last-change? yang:date-and-time
+--rw multicast {vpn-common:multicast}?
...
The following data nodes are defined:¶
'qos' container is used to define a set of QoS policies to apply on a given connection (Figure 24). A QoS policy may be a classification or an action policy. For example, a QoS action can be defined to rate limit inbound/outbound traffic of a given class of service.¶
...
+--rw qos {vpn-common:qos}?
| +--rw qos-classification-policy
| | +--rw rule* [id]
| | +--rw id string
| | +--rw (match-type)?
| | | +--:(match-flow)
| | | | +--rw (l3)?
| | | | | +--:(ipv4)
| | | | | | ...
| | | | | +--:(ipv6)
| | | | | ...
| | | | +--rw (l4)?
| | | | +--:(tcp)
| | | | | ...
| | | | +--:(udp)
| | | | ...
| | | +--:(match-application)
| | | +--rw match-application?
| | | identityref
| | +--rw target-class-id?
| | string
| +--rw qos-action
| | +--rw rule* [id]
| | +--rw id string
| | +--rw target-class-id? string
| | +--rw inbound-rate-limit? decimal64
| | +--rw outbound-rate-limit? decimal64
| +--rw qos-profile
| +--rw qos-profile* [profile]
| +--rw profile leafref
| +--rw direction? identityref
...
QoS classification can be based on many criteria such as:¶
As shown in Figure 25, classification can be based on any IP header field or a combination thereof. Both IPv4 and IPv6 are supported.¶
+--rw qos {vpn-common:qos}?
| +--rw qos-classification-policy
| | +--rw rule* [id]
| | +--rw id string
| | +--rw (match-type)?
| | | +--:(match-flow)
| | | | +--rw (l3)?
| | | | | +--:(ipv4)
| | | | | | +--rw ipv4
| | | | | | +--rw dscp? inet:dscp
| | | | | | +--rw ecn? uint8
| | | | | | +--rw length? uint16
| | | | | | +--rw ttl? uint8
| | | | | | +--rw protocol? uint8
| | | | | | +--rw ihl? uint8
| | | | | | +--rw flags? bits
| | | | | | +--rw offset? uint16
| | | | | | +--rw identification? uint16
| | | | | | +--rw (destination-network)?
| | | | | | | +--:(destination-ipv4-network)
| | | | | | | +--rw destination-ipv4-network?
| | | | | | | inet:ipv4-prefix
| | | | | | +--rw (source-network)?
| | | | | | +--:(source-ipv4-network)
| | | | | | +--rw source-ipv4-network?
| | | | | | inet:ipv4-prefix
| | | | | +--:(ipv6)
| | | | | +--rw ipv6
| | | | | +--rw dscp? inet:dscp
| | | | | +--rw ecn? uint8
| | | | | +--rw length? uint16
| | | | | +--rw ttl? uint8
| | | | | +--rw protocol? uint8
| | | | | +--rw (destination-network)?
| | | | | | +--:(destination-ipv6-network)
| | | | | | +--rw destination-ipv6-network?
| | | | | | inet:ipv6-prefix
| | | | | +--rw (source-network)?
| | | | | | +--:(source-ipv6-network)
| | | | | | +--rw source-ipv6-network?
| | | | | | inet:ipv6-prefix
| | | | | +--rw flow-label?
| | | | | inet:ipv6-flow-label
...
As discussed in [I-D.ietf-opsawg-vpn-common], any layer 4 protocol can be indicated in the 'protocol' data node under 'l3' (Figure 25), but only TCP and UDP specific match criteria are elaborated in this version as these protocols are widely used in the context of VPN services. Augmentations can be considered in the future to add other Layer 4 specific data nodes, if needed.¶
TCP or UDP-related match criteria can be specified in the L3NM as shown in Figure 26.¶
As discussed in [I-D.ietf-opsawg-vpn-common], some transport protocols use existing protocols (e.g., TCP or UDP) as substrate. The match criteria for such protocols may rely upon the 'protocol' under 'l3', TCP/UDP match criteria shown in Figure 26, part of the TCP/UDP payload, or a combination thereof. This version of the module does not support such advanced match criteria. Future revisions of the VPN common module or augmentations to the L3NM may consider adding match criteria based on the transport protocol payload (e.g., by means of a bitmask match).¶
+--rw qos {vpn-common:qos}?
| +--rw qos-classification-policy
| | +--rw rule* [id]
| | +--rw id string
| | +--rw (match-type)?
| | | +--:(match-flow)
| | | | +--rw (l3)?
| | | | | ...
| | | | +--rw (l4)?
| | | | +--:(tcp)
| | | | | +--rw tcp
| | | | | +--rw sequence-number? uint32
| | | | | +--rw acknowledgement-number? uint32
| | | | | +--rw data-offset? uint8
| | | | | +--rw reserved? uint8
| | | | | +--rw flags? bits
| | | | | +--rw window-size? uint16
| | | | | +--rw urgent-pointer? uint16
| | | | | +--rw options? binary
| | | | | +--rw (source-port)?
| | | | | | +--:(source-port-range-or-operator)
| | | | | | +--rw source-port-range-or-operator
| | | | | | +--rw (port-range-or-operator)?
| | | | | | +--:(range)
| | | | | | | +--rw lower-port
| | | | | | | | inet:port-number
| | | | | | | +--rw upper-port
| | | | | | | inet:port-number
| | | | | | +--:(operator)
| | | | | | +--rw operator? operator
| | | | | | +--rw port
| | | | | | inet:port-number
| | | | | +--rw (destination-port)?
| | | | +--:(destination-port-range-or-operator)
| | | | | +--rw destination-port-range-or-operator
| | | | | +--rw (port-range-or-operator)?
| | | | | +--:(range)
| | | | | | +--rw lower-port
| | | | | | | inet:port-number
| | | | | | +--rw upper-port
| | | | | | inet:port-number
| | | | | +--:(operator)
| | | | | +--rw operator? operator
| | | | | +--rw port
| | | | | inet:port-number
| | | | +--:(udp)
| | | | +--rw udp
| | | | +--rw length? uint16
| | | | +--rw (source-port)?
| | | | | +--:(source-port-range-or-operator)
| | | | | +--rw source-port-range-or-operator
| | | | | +--rw (port-range-or-operator)?
| | | | | +--:(range)
| | | | | | +--rw lower-port
| | | | | | | inet:port-number
| | | | | | +--rw upper-port
| | | | | | inet:port-number
| | | | | +--:(operator)
| | | | | +--rw operator? operator
| | | | | +--rw port
| | | | | inet:port-number
| | | | +--rw (destination-port)?
| | | | +--:(destination-port-range-or-operator)
| | | | +--rw destination-port-range-or-operator
| | | | +--rw (port-range-or-operator)?
| | | | +--:(range)
| | | | | +--rw lower-port
| | | | | | inet:port-number
| | | | | +--rw upper-port
| | | | | inet:port-number
| | | | +--:(operator)
| | | | +--rw operator? operator
| | | | +--rw port
| | | | inet:port-number
...
Multicast may be enabled for a particular VPN at the VPN node and VPN network access levels (see Figure 27). Some data nodes (e.g., max-groups) can be controlled at various levels: VPN service, VPN node level, or VPN network access.¶
...
+--rw vpn-services
+--rw vpn-service* [vpn-id]
...
+--rw vpn-instance-profiles
| +--rw vpn-instance-profile* [profile-id]
| ....
| +--rw multicast {vpn-common:multicast}?
| ...
+--rw vpn-nodes
+--rw vpn-node* [vpn-node-id]
...
+--rw active-vpn-instance-profiles
| +--rw vpn-instance-profile* [profile-id]
| ...
| +--rw multicast {vpn-common:multicast}?
| ...
+--rw vpn-network-accesses
+--rw vpn-network-access* [id]
...
+--rw service
...
+--rw multicast {vpn-common:multicast}?
...
Multicast-related data nodes at the VPN instance profile level has the structure that is shown in Figure 30.¶
...
+--rw vpn-services
+--rw vpn-service* [vpn-id]
...
+--rw vpn-instance-profiles
| +--rw vpn-instance-profile* [profile-id]
| ....
| +--rw multicast {vpn-common:multicast}?
| +--rw tree-flavor? identityref
| +--rw rp
| | +--rw rp-group-mappings
| | | +--rw rp-group-mapping* [id]
| | | +--rw id uint16
| | | +--rw provider-managed
| | | | +--rw enabled? boolean
| | | | +--rw rp-redundancy? boolean
| | | | +--rw optimal-traffic-delivery? boolean
| | | | +--rw anycast
| | | | +--rw local-address? inet:ip-address
| | | | +--rw rp-set-address* inet:ip-address
| | | +--rw rp-address inet:ip-address
| | | +--rw groups
| | | +--rw group* [id]
| | | +--rw id uint16
| | | +--rw (group-format)
| | | +--:(group-prefix)
| | | | +--rw group-address? inet:ip-prefix
| | | +--:(startend)
| | | +--rw group-start? inet:ip-address
| | | +--rw group-end? inet:ip-address
| | +--rw rp-discovery
| | +--rw rp-discovery-type? identityref
| | +--rw bsr-candidates
| | +--rw bsr-candidate-address* inet:ip-address
| +--rw igmp {vpn-common:igmp and vpn-common:ipv4}?
| | +--rw static-group* [group-addr]
| | | +--rw group-addr
| | | | rt-types:ipv4-multicast-group-address
| | | +--rw source-addr?
| | | rt-types:ipv4-multicast-source-address
| | +--rw max-groups? uint32
| | +--rw max-entries? uint32
| | +--rw version? identityref
| +--rw mld {vpn-common:mld and vpn-common:ipv6}?
| | +--rw static-group* [group-addr]
| | | +--rw group-addr
| | | | rt-types:ipv6-multicast-group-address
| | | +--rw source-addr?
| | | rt-types:ipv6-multicast-source-address
| | +--rw max-groups? uint32
| | +--rw max-entries? uint32
| | +--rw version? identityref
| +--rw pim {vpn-common:pim}?
| +--rw hello-interval? rt-types:timer-value-seconds16
| +--rw dr-priority? uint32
...
The model supports a single type of tree per VPN access ('tree-flavor'): Any-Source Multicast (ASM), Source-Specific Multicast (SSM), or bidirectional.¶
When ASM is used, the model supports the configuration of Rendezvous Points (RPs). RP discovery may be 'static', 'bsr-rp', or 'auto-rp'. When set to 'static', RP to multicast grouping mappings MUST be configured as part of the 'rp-group-mappings' container. The RP MAY be a provider node or a customer node. When the RP is a customer node, the RP address must be configured using the 'rp-address' leaf.¶
The model supports RP redundancy through the 'rp-redundancy' leaf. How the redundancy is achieved is out of scope.¶
When a particular VPN using ASM requires a more optimal traffic delivery (e.g., requested using [RFC8299]), 'optimal-traffic-delivery' can be set. When set to 'true', the implementation must use any mechanism to provide a more optimal traffic delivery for the customer. For example, anycast is one of the mechanisms to enhance RPs redundancy, resilience against failures, and to recover from failures quickly.¶
The same structure as the one depicted in Figure 30 is used when configuring multicast-related parameters at the VPN node level. When defined at the VPN node level (Figure 29), Internet Group Management Protocol (IGMP) [RFC1112][RFC2236][RFC3376], Multicast Listener Discovery (MLD) [RFC2710][RFC3810], and Protocol Independent Multicast (PIM) [RFC7761] parameters are applicable to all VPN network accesses of that VPN node unless corresponding nodes are overridden at the VPN network access level.¶
...
+--rw vpn-nodes
+--rw vpn-node* [vpn-node-id]
...
+--rw active-vpn-instance-profiles
| +--rw vpn-instance-profile* [profile-id]
| ...
| +--rw multicast {vpn-common:multicast}?
| +--rw tree-flavor* identityref
| +--rw rp
| | ...
| +--rw igmp {vpn-common:igmp and vpn-common:ipv4}?
| | ...
| +--rw mld {vpn-common:mld and vpn-common:ipv6}?
| | ...
| +--rw pim {vpn-common:pim}?
| ...
Multicast-related data nodes at the VPN network access level are shown in Figure 30. The values configured at the VPN network access level override the values configured for the corresponding data nodes in other levels.¶
...
+--rw vpn-network-accesses
+--rw vpn-network-access* [id]
...
+--rw service
...
+--rw multicast {vpn-common:multicast}?
+--rw access-type? enumeration
+--rw address-family? identityref
+--rw protocol-type? enumeration
+--rw remote-source? boolean
+--rw igmp {vpn-common:igmp}?
| +--rw static-group* [group-addr]
| | +--rw group-addr
| | rt-types:ipv4-multicast-group-address
| | +--rw source-addr?
| | rt-types:ipv4-multicast-source-address
| +--rw max-groups? uint32
| +--rw max-entries? uint32
| +--rw max-group-sources? uint32
| +--rw version? identityref
| +--rw status
| +--rw admin-status
| | +--rw status? identityref
| | +--rw last-change? yang:date-and-time
| +--ro oper-status
| +--ro status? identityref
| +--ro last-change? yang:date-and-time
+--rw mld {vpn-common:mld}?
| +--rw static-group* [group-addr]
| | +--rw group-addr
| | rt-types:ipv6-multicast-group-address
| | +--rw source-addr?
| | rt-types:ipv6-multicast-source-address
| +--rw max-groups? uint32
| +--rw max-entries? uint32
| +--rw max-group-sources? uint32
| +--rw version? identityref
| +--rw status
| +--rw admin-status
| | +--rw status? identityref
| | +--rw last-change? yang:date-and-time
| +--ro oper-status
| +--ro status? identityref
| +--ro last-change? yang:date-and-time
+--rw pim {vpn-common:pim}?
+--rw hello-interval? rt-types:timer-value-seconds16
+--rw dr-priority? uint32
+--rw status
+--rw admin-status
| +--rw status? identityref
| +--rw last-change? yang:date-and-time
+--ro oper-status
+--ro status? identityref
+--ro last-change? yang:date-and-time
This module uses types defined in [RFC6991] and [RFC8343]. It also uses groupings defined in [RFC8519], [RFC8177], and [RFC8294].¶
<CODE BEGINS> file "ietf-l3vpn-ntw@2021-09-10.yang"
module ietf-l3vpn-ntw {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-l3vpn-ntw";
prefix l3nm;
import ietf-vpn-common {
prefix vpn-common;
reference
"RFC UUUU: A Layer 2/3 VPN Common YANG Model";
}
import ietf-inet-types {
prefix inet;
reference
"RFC 6991: Common YANG Data Types, Section 4";
}
import ietf-yang-types {
prefix yang;
reference
"RFC 6991: Common YANG Data Types, Section 3";
}
import ietf-key-chain {
prefix key-chain;
reference
"RFC 8177: YANG Key Chain.";
}
import ietf-routing-types {
prefix rt-types;
reference
"RFC 8294: Common YANG Data Types for the Routing Area";
}
import ietf-interfaces {
prefix if;
reference
"RFC 8343: A YANG Data Model for Interface Management";
}
organization
"IETF OPSAWG (Operations and Management Area Working Group)";
contact
"WG Web: <https://datatracker.ietf.org/wg/opsawg/>
WG List: <mailto:opsawg@ietf.org>
Author: Samier Barguil
<mailto:samier.barguilgiraldo.ext@telefonica.com>
Editor: Oscar Gonzalez de Dios
<mailto:oscar.gonzalezdedios@telefonica.com>
Editor: Mohamed Boucadair
<mailto:mohamed.boucadair@orange.com>
Author: Luis Angel Munoz
<mailto:luis-angel.munoz@vodafone.com>
Author: Alejandro Aguado
<mailto:alejandro.aguado_martin@nokia.com>";
description
"This YANG module defines a generic network-oriented model
for the configuration of Layer 3 Virtual Private Networks.
Copyright (c) 2021 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices.";
revision 2021-09-10 {
description
"Initial revision.";
reference
"RFC XXXX: A Layer 3 VPN Network YANG Model";
}
/* Features */
feature msdp {
description
"This feature indicates that Multicast Source Discovery Protocol
(MSDP) capabilities are supported by the VPN.";
reference
"RFC 3618: Multicast Source Discovery Protocol (MSDP)";
}
/* Identities */
identity address-allocation-type {
description
"Base identity for address allocation type in the
Provider Edge (PE)-Customer Edge (CE) link.";
}
identity provider-dhcp {
base address-allocation-type;
description
"The Provider's network provides a DHCP service to the customer.";
}
identity provider-dhcp-relay {
base address-allocation-type;
description
"The Provider's network provides a DHCP relay service to the
customer.";
}
identity provider-dhcp-slaac {
if-feature "vpn-common:ipv6";
base address-allocation-type;
description
"The Provider's network provides a DHCP service to the customer
as well as IPv6 Stateless Address Autoconfiguration (SLAAC).";
reference
"RFC 4862: IPv6 Stateless Address Autoconfiguration";
}
identity static-address {
base address-allocation-type;
description
"The Provider's network provides static IP addressing to the
customer.";
}
identity slaac {
if-feature "vpn-common:ipv6";
base address-allocation-type;
description
"The Provider's network uses IPv6 SLAAC to provide addressing
to the customer.";
reference
"RFC 4862: IPv6 Stateless Address Autoconfiguration";
}
identity local-defined-next-hop {
description
"Base identity of local defined next-hops.";
}
identity discard {
base local-defined-next-hop;
description
"Indicates an action to discard traffic for the
corresponding destination.
For example, this can be used to blackhole traffic.";
}
identity local-link {
base local-defined-next-hop;
description
"Treat traffic towards addresses within the specified next-hop
prefix as though they are connected to a local link.";
}
identity l2-tunnel-type {
description
"Base identity for layer-2 tunnel selection under the VPN
network access.";
}
identity pseudowire {
base l2-tunnel-type;
description
"Pseudowire tunnel termination in the VPN network access.";
}
identity vpls {
base l2-tunnel-type;
description
"Virtual Private LAN Service (VPLS) tunnel termination in
the VPN network access.";
}
identity vxlan {
base l2-tunnel-type;
description
"Virtual eXtensible Local Area Network (VXLAN) tunnel
termination in the VPN network access.";
}
/* Typedefs */
typedef predefined-next-hop {
type identityref {
base local-defined-next-hop;
}
description
"Pre-defined next-hop designation for locally generated routes.";
}
typedef area-address {
type string {
pattern '[0-9A-Fa-f]{2}(\.[0-9A-Fa-f]{4}){0,6}';
}
description
"This type defines the area address format.";
}
/* Groupings */
grouping vpn-instance-profile {
description
"Grouping for data nodes that may be factorized
among many levels of the model. The grouping can
be used to define generic profiles at the VPN service
level and then referenced at the VPN node and VPN
network access levels.";
leaf local-as {
if-feature "vpn-common:rtg-bgp";
type inet:as-number;
description
"Provider's Autonomous System (AS) number. Used if the
customer requests BGP routing.";
}
uses vpn-common:route-distinguisher;
list address-family {
key "address-family";
description
"Set of per-address family parameters.";
leaf address-family {
type identityref {
base vpn-common:address-family;
}
description
"Indicates the address family (IPv4 and/or IPv6).";
}
container vpn-targets {
description
"Set of route targets to match for import and export routes
to/from VRF.";
uses vpn-common:vpn-route-targets;
}
list maximum-routes {
key "protocol";
description
"Defines the maximum number of routes for the VRF.";
leaf protocol {
type identityref {
base vpn-common:routing-protocol-type;
}
description
"Indicates the routing protocol. 'any' value can
be used to identify a limit that will apply for
each active routing protocol.";
}
leaf maximum-routes {
type uint32;
description
"Indicates the maximum number of prefixes that the
VRF can accept for this address family and protocol.";
}
}
}
container multicast {
if-feature "vpn-common:multicast";
description
"Global multicast parameters.";
leaf tree-flavor {
type identityref {
base vpn-common:multicast-tree-type;
}
description
"Type of the multicast tree to be used.";
}
container rp {
description
"Rendezvous Point (RP) parameters.";
container rp-group-mappings {
description
"RP-to-group mappings parameters.";
list rp-group-mapping {
key "id";
description
"List of RP-to-group mappings.";
leaf id {
type uint16;
description
"Unique identifier for the mapping.";
}
container provider-managed {
description
"Parameters for a provider-managed RP.";
leaf enabled {
type boolean;
default "false";
description
"Set to true if the Rendezvous Point (RP)
must be a provider-managed node. Set to
false if it is a customer-managed node.";
}
leaf rp-redundancy {
type boolean;
default "false";
description
"If set to true, it indicates that a redundancy
mechanism for the RP is required.";
}
leaf optimal-traffic-delivery {
type boolean;
default "false";
description
"If set to true, the service provider (SP) must
ensure that the traffic uses an optimal path.
An SP may use Anycast RP or RP-tree-to-SPT
switchover architectures.";
}
container anycast {
when "../rp-redundancy = 'true' and
../optimal-traffic-delivery = 'true'" {
description
"Only applicable if both RP redundancy and
delivery through optimal path are
activated.";
}
description
"PIM Anycast-RP parameters.";
leaf local-address {
type inet:ip-address;
description
"IP local address for PIM RP. Usually, it
corresponds to the Router ID or the
primary address.";
}
leaf-list rp-set-address {
type inet:ip-address;
description
"Specifies the IP address of other RP routers
that share the same RP IP address.";
}
}
}
leaf rp-address {
when "../provider-managed/enabled = 'false'" {
description
"Relevant when the RP is not
provider-managed.";
}
type inet:ip-address;
mandatory true;
description
"Defines the address of the RP.
Used if the RP is customer-managed.";
}
container groups {
description
"Multicast groups associated with the RP.";
list group {
key "id";
description
"List of multicast groups.";
leaf id {
type uint16;
description
"Identifier for the group.";
}
choice group-format {
mandatory true;
description
"Choice for multicast group format.";
case group-prefix {
leaf group-address {
type inet:ip-prefix;
description
"A single multicast group prefix.";
}
}
case startend {
leaf group-start {
type inet:ip-address;
description
"The first multicast group address in
the multicast group address range.";
}
leaf group-end {
type inet:ip-address;
description
"The last multicast group address in
the multicast group address range.";
}
}
}
}
}
}
}
container rp-discovery {
description
"RP discovery parameters.";
leaf rp-discovery-type {
type identityref {
base vpn-common:multicast-rp-discovery-type;
}
default "vpn-common:static-rp";
description
"Type of RP discovery used.";
}
container bsr-candidates {
when "derived-from-or-self(../rp-discovery-type, "
+ "'vpn-common:bsr-rp')" {
description
"Only applicable if discovery type is BSR-RP.";
}
description
"Container for the customer Bootstrap Router (BSR)
candidate's addresses.";
leaf-list bsr-candidate-address {
type inet:ip-address;
description
"Specifies the address of candidate BSR.";
}
}
}
}
container igmp {
if-feature "vpn-common:igmp and vpn-common:ipv4";
description
"Includes IGMP-related parameters.";
list static-group {
key "group-addr";
description
"Multicast static source/group associated to the
IGMP session.";
leaf group-addr {
type rt-types:ipv4-multicast-group-address;
description
"Multicast group IPv4 address.";
}
leaf source-addr {
type rt-types:ipv4-multicast-source-address;
description
"Multicast source IPv4 address.";
}
}
leaf max-groups {
type uint32;
description
"Indicates the maximum number of groups.";
}
leaf max-entries {
type uint32;
description
"Indicates the maximum number of IGMP entries.";
}
leaf version {
type identityref {
base vpn-common:igmp-version;
}
default "vpn-common:igmpv2";
description
"Indicates the IGMP version.";
reference
"RFC 1112: Host Extensions for IP Multicasting
RFC 2236: Internet Group Management Protocol, Version 2
RFC 3376: Internet Group Management Protocol, Version 3";
}
}
container mld {
if-feature "vpn-common:mld and vpn-common:ipv6";
description
"Includes MLD-related parameters.";
list static-group {
key "group-addr";
description
"Multicast static source/group associated with the
MLD session.";
leaf group-addr {
type rt-types:ipv6-multicast-group-address;
description
"Multicast group IPv6 address.";
}
leaf source-addr {
type rt-types:ipv6-multicast-source-address;
description
"Multicast source IPv6 address.";
}
}
leaf max-groups {
type uint32;
description
"Indicates the maximum number of groups.";
}
leaf max-entries {
type uint32;
description
"Indicates the maximum number of MLD entries.";
}
leaf version {
type identityref {
base vpn-common:mld-version;
}
default "vpn-common:mldv2";
description
"Indicates the MLD protocol version.";
reference
"RFC 2710: Multicast Listener Discovery (MLD) for IPv6
RFC 3810: Multicast Listener Discovery Version 2 (MLDv2)
for IPv6";
}
}
container pim {
if-feature "vpn-common:pim";
description
"Only applies when protocol type is PIM.";
leaf hello-interval {
type rt-types:timer-value-seconds16;
default "30";
description
"PIM hello-messages interval. If set to
'infinity' or 'not-set', no periodic
Hello messages are sent.";
reference
"RFC 7761: Protocol Independent Multicast - Sparse
Mode (PIM-SM): Protocol Specification (Revised),
Section 4.11";
}
leaf dr-priority {
type uint32;
default "1";
description
"Indicates the preference in the Designated Router (DR)
election process. A larger value has a higher
priority over a smaller value.";
reference
"RFC 7761: Protocol Independent Multicast - Sparse
Mode (PIM-SM): Protocol Specification (Revised),
Section 4.3.2";
}
}
}
}
/* Main Blocks */
/* Main l3vpn-ntw */
container l3vpn-ntw {
description
"Main container for L3VPN services management.";
container vpn-profiles {
description
"Contains a set of valid VPN profiles to reference in the VPN
service.";
uses vpn-common:vpn-profile-cfg;
}
container vpn-services {
description
"Container for the VPN services.";
list vpn-service {
key "vpn-id";
description
"List of VPN services.";
uses vpn-common:vpn-description;
leaf parent-service-id {
type vpn-common:vpn-id;
description
"Pointer to the parent service, if any.
A parent service can be an L3SM, a slice request, a VPN+
service, etc.";
}
leaf vpn-type {
type identityref {
base vpn-common:service-type;
}
description
"Indicates the service type.";
}
leaf vpn-service-topology {
type identityref {
base vpn-common:vpn-topology;
}
default "vpn-common:any-to-any";
description
"VPN service topology.";
}
uses vpn-common:service-status;
container vpn-instance-profiles {
description
"Container for a list of VPN instance profiles.";
list vpn-instance-profile {
key "profile-id";
description
"List of VPN instance profiles.";
leaf profile-id {
type string;
description
"VPN instance profile identifier.";
}
leaf role {
type identityref {
base vpn-common:role;
}
default "vpn-common:any-to-any-role";
description
"Role of the VPN node in the VPN.";
}
uses vpn-instance-profile;
}
}
container underlay-transport {
description
"Container for underlay transport.";
uses vpn-common:underlay-transport;
}
container external-connectivity {
if-feature "vpn-common:external-connectivity";
description
"Container for external connectivity.";
choice profile {
description
"Choice for the external connectivity profile.";
case profile {
leaf profile-name {
type leafref {
path "/l3vpn-ntw/vpn-profiles"
+ "/valid-provider-identifiers"
+ "/external-connectivity-identifier/id";
}
description
"Name of the service provider's profile to be applied
at the VPN service level.";
}
}
}
}
container vpn-nodes {
description
"Container for VPN nodes.";
list vpn-node {
key "vpn-node-id";
description
"Includes a list of VPN nodes.";
leaf vpn-node-id {
type vpn-common:vpn-id;
description
"An identifier of the VPN node.";
}
leaf description {
type string;
description
"Textual description of the VPN node.";
}
leaf ne-id {
type string;
description
"Unique identifier of the network element where the VPN
node is deployed.";
}
leaf local-as {
if-feature "vpn-common:rtg-bgp";
type inet:as-number;
description
"Provider's AS number in case the customer requests BGP
routing.";
}
leaf router-id {
type rt-types:router-id;
description
"A 32-bit number in the dotted-quad format that is used
to uniquely identify a node within an autonomous
system. This identifier is used for both IPv4 and
IPv6.";
}
container active-vpn-instance-profiles {
description
"Container for active VPN instance profiles.";
list vpn-instance-profile {
key "profile-id";
description
"Includes a list of active VPN instance profiles.";
leaf profile-id {
type leafref {
path "/l3vpn-ntw/vpn-services/vpn-service"
+ "/vpn-instance-profiles/vpn-instance-profile"
+ "/profile-id";
}
description
"Node's active VPN instance profile.";
}
list router-id {
key "address-family";
description
"Router-id per address family.";
leaf address-family {
type identityref {
base vpn-common:address-family;
}
description
"Indicates the address family for which the
Router-ID applies.";
}
leaf router-id {
type inet:ip-address;
description
"The router-id information can be an IPv4 or IPv6
address. This can be used, for example, to
configure an IPv6 address as a router-id
when such capability is supported by underlay
routers. In such case, the configured value
overrides the generic one defined at the VPN
node level.";
}
}
uses vpn-instance-profile;
}
}
container msdp {
if-feature "msdp";
description
"Includes MSDP-related parameters.";
leaf peer {
type inet:ipv4-address;
description
"Indicates the IPv4 address of the MSDP peer.";
}
leaf local-address {
type inet:ipv4-address;
description
"Indicates the IPv4 address of the local end.
This local address must be configured on
the node.";
}
uses vpn-common:service-status;
}
uses vpn-common:vpn-components-group;
uses vpn-common:service-status;
container vpn-network-accesses {
description
"List of network accesses.";
list vpn-network-access {
key "id";
description
"List of network accesses.";
leaf id {
type vpn-common:vpn-id;
description
"Identifier for the network access.";
}
leaf interface-id {
type string;
description
"Identifier for the physical or logical
interface.
The identification of the sub-interface
is provided at the connection and/or IP
connection levels.";
}
leaf description {
type string;
description
"Textual description of the network access.";
}
leaf vpn-network-access-type {
type identityref {
base vpn-common:site-network-access-type;
}
default "vpn-common:point-to-point";
description
"Describes the type of connection, e.g.,
point-to-point.";
}
leaf vpn-instance-profile {
type leafref {
path "/l3vpn-ntw/vpn-services/vpn-service/vpn-nodes"
+ "/vpn-node/active-vpn-instance-profiles"
+ "/vpn-instance-profile/profile-id";
}
description
"An identifier of an active VPN instance profile.";
}
uses vpn-common:service-status;
container connection {
description
"Defines layer 2 protocols and parameters that are
required to enable connectivity between the PE
and the CE.";
container encapsulation {
description
"Container for layer 2 encapsulation.";
leaf type {
type identityref {
base vpn-common:encapsulation-type;
}
default "vpn-common:priority-tagged";
description
"Encapsulation type. By default, the type of
the tagged interface is 'priority-tagged'.";
}
container dot1q {
when "derived-from-or-self(../type, "
+ "'vpn-common:dot1q')" {
description
"Only applies when the type of the
tagged interface is 'dot1q'.";
}
if-feature "vpn-common:dot1q";
description
"Tagged interface.";
leaf tag-type {
type identityref {
base vpn-common:tag-type;
}
default "vpn-common:c-vlan";
description
"Tag type. By default, the tag type is
'c-vlan'.";
}
leaf cvlan-id {
type uint16 {
range "1..4094";
}
description
"VLAN identifier.";
}
}
container priority-tagged {
when "derived-from-or-self(../type, "
+ "'vpn-common:priority-tagged')" {
description
"Only applies when the type of the
tagged interface is 'priority-tagged'.";
}
description
"Priority tagged.";
leaf tag-type {
type identityref {
base vpn-common:tag-type;
}
default "vpn-common:c-vlan";
description
"Tag type. By default, the tag type is
'c-vlan'.";
}
}
container qinq {
when "derived-from-or-self(../type, "
+ "'vpn-common:qinq')" {
description
"Only applies when the type of the tagged
interface is QinQ.";
}
if-feature "vpn-common:qinq";
description
"Includes QinQ parameters.";
leaf tag-type {
type identityref {
base vpn-common:tag-type;
}
default "vpn-common:s-c-vlan";
description
"Tag type. By default, the tag type is
'c-s-vlan'.";
}
leaf svlan-id {
type uint16;
mandatory true;
description
"S-VLAN identifier.";
}
leaf cvlan-id {
type uint16;
mandatory true;
description
"C-VLAN identifier.";
}
}
}
choice l2-service {
description
"The layer 2 connectivity service can be
provided by indicating a pointer to an L2VPN or
by specifying a layer 2 tunnel service.";
container l2-tunnel-service {
description
"Defines a layer 2 tunnel termination.
It is only applicable when a tunnel is
required. The supported values are:
pseudowire, VPLS, and VXLAN. Other
values may be defined, if needed.";
leaf type {
type identityref {
base l2-tunnel-type;
}
description
"Selects the tunnel termiantion option for
each vpn-network-access.";
}
container pseudowire {
when "derived-from-or-self(../type, "
+ "'pseudowire')" {
description
"Only applies when the type of the layer 2
service type is pseudowire .";
}
description
"Includes pseudowire termination parameters.";
leaf vcid {
type uint32;
description
"Indicates a PW or VC identifier.";
}
leaf far-end {
type union {
type uint32;
type inet:ip-address;
}
description
"Neighbor reference.";
reference
"RFC 8077: Pseudowire Setup and Maintenance
Using the Label Distribution
Protocol (LDP), Section 6.1";
}
}
container vpls {
when "derived-from-or-self(../type, "
+ "'vpls')" {
description
"Only applies when the type of the layer 2
service type is VPLS.";
}
description
"VPLS termination parameters.";
leaf vcid {
type uint32;
description
"VC Identifier.";
}
leaf-list far-end {
type union {
type uint32;
type inet:ip-address;
}
description
"Neighbor reference.";
}
}
container vxlan {
when "derived-from-or-self(../type, "
+ "'vxlan')" {
description
"Only applies when the type of the layer 2
service type is VXLAN.";
}
if-feature "vpn-common:vxlan";
description
"VXLAN termination parameters.";
leaf vni-id {
type uint32;
mandatory true;
description
"VXLAN Network Identifier (VNI).";
}
leaf peer-mode {
type identityref {
base vpn-common:vxlan-peer-mode;
}
default "vpn-common:static-mode";
description
"Specifies the VXLAN access mode. By
default, the peer mode is set to
'static-mode'.";
}
leaf-list peer-ip-address {
type inet:ip-address;
description
"List of peer's IP addresses.";
}
}
}
case l2vpn {
leaf l2vpn-id {
type vpn-common:vpn-id;
description
"Indicates the L2VPN service associated with
an Integrated Routing and Bridging (IRB)
interface.";
}
}
}
leaf l2-termination-point {
type string;
description
"Specifies a reference to a local layer 2
termination point such as a layer 2
sub-interface.";
}
leaf local-bridge-reference {
type string;
description
"Specifies a local bridge reference to
accommodate, for example, implementations
that require internal bridging.
A reference may be a local bridge domain.";
}
leaf bearer-reference {
if-feature "vpn-common:bearer-reference";
type string;
description
"This is an internal reference for the service
provider to identify the bearer associated
with this VPN.";
}
container lag-interface {
if-feature "vpn-common:lag-interface";
description
"Container of LAG interface attributes
configuration.";
leaf lag-interface-id {
type string;
description
"LAG interface identifier.";
}
container member-link-list {
description
"Container of Member link list.";
list member-link {
key "name";
description
"Member link.";
leaf name {
type string;
description
"Member link name.";
}
}
}
}
}
container ip-connection {
description
"Defines IP connection parameters.";
leaf l3-termination-point {
type string;
description
"Specifies a reference to a local layer 3
termination point such as a bridge domain
interface.";
}
container ipv4 {
if-feature "vpn-common:ipv4";
description
"IPv4-specific parameters.";
leaf local-address {
type inet:ipv4-address;
description
"The IP address used at the provider's
interface.";
}
leaf prefix-length {
type uint8 {
range "0..32";
}
description
"Subnet prefix length expressed in bits.
It is applied to both local and customer
addresses.";
}
leaf address-allocation-type {
type identityref {
base address-allocation-type;
}
must "not(derived-from-or-self(current(), "
+ "'slaac') or derived-from-or-self(current(),"
+ " 'provider-dhcp-slaac'))" {
error-message
"SLAAC is only applicable to IPv6.";
}
description
"Defines how addresses are allocated to the
peer site.
If there is no value for the address
allocation type, then IPv4 addressing is not
enabled.";
}
choice allocation-type {
description
"Choice of the IPv4 address allocation.";
case provider-dhcp {
description
"DHCP allocated addresses related
parameters. IP addresses are allocated
by DHCP that is operated by the provider";
leaf dhcp-service-type {
type enumeration {
enum server {
description
"Local DHCP server.";
}
enum relay {
description
"Local DHCP relay. DHCP requests are
relayed to a provider's server.";
}
}
description
"Indicates the type of DHCP service to
be enabled on this access.";
}
choice service-type {
description
"Choice based on the DHCP service type.";
case relay {
description
"Container for list of provider's DHCP
servers (i.e., dhcp-service-type is set
to relay).";
leaf-list server-ip-address {
type inet:ipv4-address;
description
"IPv4 addresses of the provider's DHCP
server to use by the local DHCP
relay.";
}
}
case server {
description
"A choice about how addresses are assigned
when a local DHCP server is enabled.";
choice address-assign {
default "number";
description
"Choice for how IPv4 addresses are
assigned.";
case number {
leaf number-of-dynamic-address {
type uint16;
default "1";
description
"Specifies the number of IP
addresses to be assigned to the
customer on this access.";
}
}
case explicit {
container customer-addresses {
description
"Container for customer
addresses to be allocated
using DHCP.";
list address-pool {
key "pool-id";
description
"Describes IP addresses to be
allocated by DHCP.
When only start-address is
present, it represents a single
address.
When both start-address and
end-address are specified, it
implies a range inclusive of both
addresses.";
leaf pool-id {
type string;
description
"A pool identifier for the
address range from start-
address to end-address.";
}
leaf start-address {
type inet:ipv4-address;
mandatory true;
description
"Indicates the first address
in the pool.";
}
leaf end-address {
type inet:ipv4-address;
description
"Indicates the last address
in the pool.";
}
}
}
}
}
}
}
}
case dhcp-relay {
description
"DHCP relay is provided by the operator.";
container customer-dhcp-servers {
description
"Container for a list of customer's DHCP
servers.";
leaf-list server-ip-address {
type inet:ipv4-address;
description
"IPv4 addresses of the customer's DHCP
server.";
}
}
}
case static-addresses {
description
"Lists the IPv4 addresses that are used.";
leaf primary-address {
type leafref {
path "../address/address-id";
}
description
"Primary address of the connection.";
}
list address {
key "address-id";
description
"Lists the IPv4 addresses that are used.";
leaf address-id {
type string;
description
"An identifier of the static IPv4
address.";
}
leaf customer-address {
type inet:ipv4-address;
description
"IPv4 address at the customer side.";
}
}
}
}
}
container ipv6 {
if-feature "vpn-common:ipv6";
description
"IPv6-specific parameters.";
leaf local-address {
type inet:ipv6-address;
description
"IPv6 address of the provider side.";
}
leaf prefix-length {
type uint8 {
range "0..128";
}
description
"Subnet prefix length expressed in bits.
It is applied to both local and customer
addresses.";
}
leaf address-allocation-type {
type identityref {
base address-allocation-type;
}
description
"Defines how addresses are allocated.
If there is no value for the address
allocation type, then IPv6 addressing is
disabled.";
}
choice allocation-type {
description
"A choice based on the IPv6 allocation type.";
container provider-dhcp {
when "derived-from-or-self(../address-allo"
+ "cation-type, 'provider-dhcp') "
+ "or derived-from-or-self(../address-allo"
+ "cation-type, 'provider-dhcp-slaac')" {
description
"Only applies when addresses are
allocated by DHCPv6 provided by the
operator.";
}
description
"DHCPv6 allocated addresses related
parameters.";
leaf dhcp-service-type {
type enumeration {
enum server {
description
"Local DHCPv6 server.";
}
enum relay {
description
"DHCPv6 relay.";
}
}
description
"Indicates the type of the DHCPv6 service to
be enabled on this access.";
}
choice service-type {
description
"Choice based on the DHCPv6 service type.";
case relay {
leaf-list server-ip-address {
type inet:ipv6-address;
description
"IPv6 addresses of the provider's
DHCPv6 server.";
}
}
case server {
choice address-assign {
default "number";
description
"Choice about how IPv6 prefixes are
assigned by the DHCPv6 server.";
case number {
leaf number-of-dynamic-address {
type uint16;
default "1";
description
"Describes the number of IPv6
prefixes that are allocated to
the customer on this access.";
}
}
case explicit {
container customer-addresses {
description
"Container for customer IPv6
addresses allocated by DHCPv6.";
list address-pool {
key "pool-id";
description
"Describes IPv6 addresses
allocated by DHCPv6.
When only start-address is
present, it represents a single
address.
When both start-address and
end-address are specified, it
implies a range inclusive of
both addresses.";
leaf pool-id {
type string;
description
"Pool identifier for the address
range from identified by start-
address and end-address.";
}
leaf start-address {
type inet:ipv6-address;
mandatory true;
description
"Indicates the first address.";
}
leaf end-address {
type inet:ipv6-address;
description
"Indicates the last address.";
}
}
}
}
}
}
}
}
case dhcp-relay {
description
"DHCPv6 relay provided by the operator.";
container customer-dhcp-servers {
description
"Container for a list of customer DHCP
servers.";
leaf-list server-ip-address {
type inet:ipv6-address;
description
"Contains the IP addresses of the customer
DHCPv6 server.";
}
}
}
case static-addresses {
description
"IPv6-specific parameters for static
allocation.";
leaf primary-address {
type leafref {
path "../address/address-id";
}
description
"Principal address of the connection";
}
list address {
key "address-id";
description
"Describes IPv6 addresses that are used.";
leaf address-id {
type string;
description
"An identifier of an IPv6 address.";
}
leaf customer-address {
type inet:ipv6-address;
description
"An IPv6 address of the customer side.";
}
}
}
}
}
}
container routing-protocols {
description
"Defines routing protocols.";
list routing-protocol {
key "id";
description
"List of routing protocols used on
the CE/PE link. This list can be augmented.";
leaf id {
type string;
description
"Unique identifier for routing protocol.";
}
leaf type {
type identityref {
base vpn-common:routing-protocol-type;
}
description
"Type of routing protocol.";
}
list routing-profiles {
key "id";
description
"Routing profiles.";
leaf id {
type leafref {
path "/l3vpn-ntw/vpn-profiles"
+ "/valid-provider-identifiers"
+ "/routing-profile-identifier/id";
}
description
"Routing profile to be used.";
}
leaf type {
type identityref {
base vpn-common:ie-type;
}
description
"Import, export, or both.";
}
}
container static {
when "derived-from-or-self(../type, "
+ "'vpn-common:static-routing')" {
description
"Only applies when protocol is static.";
}
description
"Configuration specific to static routing.";
container cascaded-lan-prefixes {
description
"LAN prefixes from the customer.";
list ipv4-lan-prefixes {
if-feature "vpn-common:ipv4";
key "lan next-hop";
description
"List of LAN prefixes for the site.";
leaf lan {
type inet:ipv4-prefix;
description
"LAN prefixes.";
}
leaf lan-tag {
type string;
description
"Internal tag to be used in VPN
policies.";
}
leaf next-hop {
type union {
type inet:ip-address;
type predefined-next-hop;
}
description
"The next-hop that is to be used
for the static route. This may be
specified as an IP address or a
pre-defined next-hop type (e.g.,
discard or local-link).";
}
leaf bfd-enable {
if-feature "vpn-common:bfd";
type boolean;
description
"Enables BFD.";
}
leaf metric {
type uint32;
description
"Indicates the metric associated with
the static route.";
}
leaf preference {
type uint32;
description
"Indicates the preference of the static
routes.";
}
uses vpn-common:service-status;
}
list ipv6-lan-prefixes {
if-feature "vpn-common:ipv6";
key "lan next-hop";
description
"List of LAN prefixes for the site.";
leaf lan {
type inet:ipv6-prefix;
description
"LAN prefixes.";
}
leaf lan-tag {
type string;
description
"Internal tag to be used in VPN
policies.";
}
leaf next-hop {
type union {
type inet:ip-address;
type predefined-next-hop;
}
description
"The next-hop that is to be used for the
static route. This may be specified as
an IP address or a pre-defined next-hop
type (e.g., discard or local-link).";
}
leaf bfd-enable {
if-feature "vpn-common:bfd";
type boolean;
description
"Enables BFD.";
}
leaf metric {
type uint32;
description
"Indicates the metric associated with
the static route.";
}
leaf preference {
type uint32;
description
"Indicates the preference associated
with the static route.";
}
uses vpn-common:service-status;
}
}
}
container bgp {
when "derived-from-or-self(../type, "
+ "'vpn-common:bgp-routing')" {
description
"Only applies when protocol is BGP.";
}
if-feature "vpn-common:rtg-bgp";
description
"BGP-specific configuration.";
leaf description {
type string;
description
"Includes a description of the BGP session.
This description is meant to be used for
diagnosis purposes. The semantic of the
description is local to an
implementation.";
}
leaf local-as {
type inet:as-number;
description
"Indicates a local AS Number (ASN) if a
distinct ASN than the one configured at
the VPN node level is needed.";
}
leaf peer-as {
type inet:as-number;
mandatory true;
description
"Indicates the customer's ASN when
the customer requests BGP routing.";
}
leaf address-family {
type identityref {
base vpn-common:address-family;
}
description
"This node contains the address families to be
activated. Dual-stack means that both IPv4
and IPv6 will be activated.";
}
leaf local-address {
type union {
type inet:ip-address;
type if:interface-ref;
}
description
"Set the local IP address to use for the BGP
transport session. This may be expressed as
either an IP address or a reference to an
interface.";
}
leaf-list neighbor {
type inet:ip-address;
description
"IP address(es) of the BGP neighbor. IPv4
and IPv6 neighbors may be indicated if
two sessions will be used for IPv4 and
IPv6.";
}
leaf multihop {
type uint8;
description
"Describes the number of IP hops allowed
between a given BGP neighbor and the PE.";
}
leaf as-override {
type boolean;
default "false";
description
"Defines whether ASN override is enabled,
i.e., replace the ASN of the customer
specified in the AS_Path attribute with
the local ASN.";
}
leaf allow-own-as {
type uint8;
default "0";
description
"Specifies the number of occurrences
of the provider's ASN that can occur
within the AS_PATH before it
is rejected.";
}
leaf prepend-global-as {
type boolean;
default "false";
description
"In some situations, the ASN that is
provided at the VPN node level may be
distinct from the one configured at the
VPN network access level. When such
ASNs are provided, they are both
prepended to the BGP route updates
for this access. To disable that
behavior, the prepend-global-as
must be set to 'false'. In such a case,
the ASN that is provided at
the VPN node level is not prepended to
the BGP route updates for this access.";
}
leaf send-default-route {
type boolean;
default "false";
description
"Defines whether default routes can be
advertised to its peer. If set, the
default routes are advertised to its
peer.";
}
leaf site-of-origin {
when "../address-family = 'vpn-common:ipv4' or "
+ "'vpn-common:dual-stack'" {
description
"Only applies if IPv4 is activated.";
}
type rt-types:route-origin;
description
"The Site of Origin attribute is encoded as
a Route Origin Extended Community. It is
meant to uniquely identify the set of routes
learned from a site via a particular CE/PE
connection and is used to prevent routing
loops.";
reference
"RFC 4364: BGP/MPLS IP Virtual Private
Networks (VPNs), Section 7";
}
leaf ipv6-site-of-origin {
when "../address-family = 'vpn-common:ipv6' or "
+ "'vpn-common:dual-stack'" {
description
"Only applies if IPv6 is activated.";
}
type rt-types:ipv6-route-origin;
description
"IPv6 Route Origins are IPv6 Address Specific
BGP Extended that are meant to the Site of
Origin for VRF information.";
reference
"RFC 5701: IPv6 Address Specific BGP Extended
Community Attribute";
}
list redistribute-connected {
key "address-family";
description
"Indicates the per-AF policy to follow
for connected routes.";
leaf address-family {
type identityref {
base vpn-common:address-family;
}
description
"Indicates the address family.";
}
leaf enable {
type boolean;
description
"Enables to redistribute connected
routes.";
}
}
container bgp-max-prefix {
description
"Controls the behavior when a prefix
maximum is reached.";
leaf max-prefix {
type uint32;
default "5000";
description
"Indicates the maximum number of BGP
prefixes allowed in the BGP session.
It allows control of how many prefixes
can be received from a neighbor.
If the limit is exceeded, the action
indicated in violate-action will be
followed.";
reference
"RFC 4271: A Border Gateway Protocol 4
(BGP-4), Section 8.2.2";
}
leaf warning-threshold {
type decimal64 {
fraction-digits 5;
range "0..100";
}
units "percent";
default "75";
description
"When this value is reached, a warning
notification will be triggered.";
}
leaf violate-action {
type enumeration {
enum warning {
description
"Only a warning message is sent to
the peer when the limit is
exceeded.";
}
enum discard-extra-paths {
description
"Discards extra paths when the
limit is exceeded.";
}
enum restart {
description
"The BGP session restarts after
a time interval.";
}
}
description
"BGP neighbor max-prefix violate
action.";
}
leaf restart-timer {
type uint32;
units "seconds";
description
"Time interval after which the BGP
session will be reestablished.";
}
}
container bgp-timers {
description
"Includes two BGP timers that can be
customized when building a VPN service
with BGP used as CE-PE routing
protocol.";
leaf keepalive {
type uint16 {
range "0..21845";
}
units "seconds";
default "30";
description
"This timer indicates the KEEPALIVE
messages' frequency between a PE
and a BGP peer.
If set to '0', it indicates KEEPALIVE
messages are disabled.
It is suggested that the maximum time
between KEEPALIVE messages would be
one third of the Hold Time interval.";
reference
"RFC 4271: A Border Gateway Protocol 4
(BGP-4), Section 4.4";
}
leaf hold-time {
type uint16 {
range "0 | 3..65535";
}
units "seconds";
default "90";
description
"It indicates the maximum number of
seconds that may elapse between the
receipt of successive KEEPALIVE
and/or UPDATE messages from the peer.
The Hold Time must be either zero or
at least three seconds.";
reference
"RFC 4271: A Border Gateway Protocol 4
(BGP-4), Section 4.2";
}
}
container authentication {
description
"Container for BGP authentication
parameters between a PE and a CE.";
leaf enable {
type boolean;
default "false";
description
"Enables or disables authentication.";
}
container keying-material {
when "../enable = 'true'";
description
"Container for describing how a BGP routing
session is to be secured between a PE and
a CE.";
choice option {
description
"Choice of authentication options.";
case ao {
description
"Uses TCP-Authentication Option
(TCP-AO).";
reference
"RFC 5925: The TCP Authentication
Option.";
leaf enable-ao {
type boolean;
description
"Enables TCP-AO.";
}
leaf ao-keychain {
type key-chain:key-chain-ref;
description
"Reference to the TCP-AO key chain.";
reference
"RFC 8177: YANG Key Chain.";
}
}
case md5 {
description
"Uses MD5 to secure the session.";
reference
"RFC 4364: BGP/MPLS IP Virtual Private
Networks (VPNs),
Section 13.2";
leaf md5-keychain {
type key-chain:key-chain-ref;
description
"Reference to the MD5 key chain.";
reference
"RFC 8177: YANG Key Chain";
}
}
case explicit {
leaf key-id {
type uint32;
description
"Key Identifier.";
}
leaf key {
type string;
description
"BGP authentication key in ASCII
format.";
}
leaf crypto-algorithm {
type identityref {
base key-chain:crypto-algorithm;
}
description
"Indicates the cryptographic algorithm
associated with the key.";
}
}
case ipsec {
description
"Specifies a reference to an IKE
Security Association (SA).";
leaf sa {
type string;
description
"Indicates the name of the SA.";
}
}
}
}
}
uses vpn-common:service-status;
}
container ospf {
when "derived-from-or-self(../type, "
+ "'vpn-common:ospf-routing')" {
description
"Only applies when protocol is OSPF.";
}
if-feature "vpn-common:rtg-ospf";
description
"OSPF-specific configuration.";
leaf address-family {
type identityref {
base vpn-common:address-family;
}
description
"Indicates whether IPv4, IPv6, or
both are to be activated.";
}
leaf area-id {
type yang:dotted-quad;
mandatory true;
description
"Area ID.";
reference
"RFC 4577: OSPF as the Provider/Customer
Edge Protocol for BGP/MPLS IP
Virtual Private Networks
(VPNs), Section 4.2.3
RFC 6565: OSPFv3 as a Provider Edge to
Customer Edge (PE-CE) Routing
Protocol, Section 4.2";
}
leaf metric {
type uint16;
default "1";
description
"Metric of the PE-CE link. It is used
in the routing state calculation and
path selection.";
}
container sham-links {
if-feature "vpn-common:rtg-ospf-sham-link";
description
"List of sham links.";
reference
"RFC 4577: OSPF as the Provider/Customer
Edge Protocol for BGP/MPLS IP
Virtual Private Networks
(VPNs), Section 4.2.7
RFC 6565: OSPFv3 as a Provider Edge to
Customer Edge (PE-CE) Routing
Protocol, Section 5";
list sham-link {
key "target-site";
description
"Creates a sham link with another site.";
leaf target-site {
type string;
description
"Target site for the sham link connection.
The site is referred to by its
identifier.";
}
leaf metric {
type uint16;
default "1";
description
"Metric of the sham link. It is used in
the routing state calculation and path
selection. The default value is set
to 1.";
reference
"RFC 4577: OSPF as the Provider/Customer
Edge Protocol for BGP/MPLS IP
Virtual Private Networks
(VPNs), Section 4.2.7.3
RFC 6565: OSPFv3 as a Provider Edge to
Customer Edge (PE-CE) Routing
Protocol, Section 5.2";
}
}
}
leaf max-lsa {
type uint32 {
range "1..4294967294";
}
description
"Maximum number of allowed LSAs OSPF.";
}
container authentication {
description
"Authentication configuration.";
leaf enable {
type boolean;
default "false";
description
"Enables or disables authentication.";
}
container keying-material {
when "../enable = 'true'";
description
"Container for describing how an OSPF
session is to be secured between a CE
and a PE.";
choice option {
description
"Options for OSPF authentication.";
case auth-key-chain {
leaf key-chain {
type key-chain:key-chain-ref;
description
"key-chain name.";
}
}
case auth-key-explicit {
leaf key-id {
type uint32;
description
"Key identifier.";
}
leaf key {
type string;
description
"OSPF authentication key in ASCII
format.";
}
leaf crypto-algorithm {
type identityref {
base key-chain:crypto-algorithm;
}
description
"Indicates the cryptographic algorithm
associated with the key.";
}
}
case ipsec {
leaf sa {
type string;
description
"Indicates the name of the SA.";
reference
"RFC 4552: Authentication
/Confidentiality for
OSPFv3";
}
}
}
}
}
uses vpn-common:service-status;
}
container isis {
when "derived-from-or-self(../type, "
+ "'vpn-common:isis-routing')" {
description
"Only applies when protocol is IS-IS.";
}
if-feature "vpn-common:rtg-isis";
description
"IS-IS specific configuration.";
leaf address-family {
type identityref {
base vpn-common:address-family;
}
description
"Indicates whether IPv4, IPv6, or both
are to be activated.";
}
leaf area-address {
type area-address;
mandatory true;
description
"Area address.";
}
leaf level {
type identityref {
base vpn-common:isis-level;
}
description
"Can be level-1, level-2, or level-1-2.";
}
leaf metric {
type uint16;
default "1";
description
"Metric of the PE-CE link. It is used
in the routing state calculation and
path selection.";
}
leaf mode {
type enumeration {
enum active {
description
"Interface sends or receives IS-IS
protocol control packets.";
}
enum passive {
description
"Suppresses the sending of IS-IS
updates through the specified
interface.";
}
}
default "active";
description
"IS-IS interface mode type.";
}
container authentication {
description
"Authentication configuration.";
leaf enable {
type boolean;
default "false";
description
"Enables or disables authentication.";
}
container keying-material {
when "../enable = 'true'";
description
"Container for describing how an IS-IS
session is to be secured between a CE
and a PE.";
choice option {
description
"Options for IS-IS authentication.";
case auth-key-chain {
leaf key-chain {
type key-chain:key-chain-ref;
description
"key-chain name.";
}
}
case auth-key-explicit {
leaf key-id {
type uint32;
description
"Key Identifier.";
}
leaf key {
type string;
description
"IS-IS authentication key in ASCII
format.";
}
leaf crypto-algorithm {
type identityref {
base key-chain:crypto-algorithm;
}
description
"Indicates the cryptographic algorithm
associated with the key.";
}
}
}
}
}
uses vpn-common:service-status;
}
container rip {
when "derived-from-or-self(../type, "
+ "'vpn-common:rip-routing')" {
description
"Only applies when the protocol is RIP.
For IPv4, the model assumes that RIP
version 2 is used.";
}
if-feature "vpn-common:rtg-rip";
description
"Configuration specific to RIP routing.";
leaf address-family {
type identityref {
base vpn-common:address-family;
}
description
"Indicates whether IPv4, IPv6, or both
address families are to be activated.";
}
container timers {
description
"Indicates the RIP timers.";
reference
"RFC 2453: RIP Version 2";
leaf update-interval {
type uint16 {
range "1..32767";
}
units "seconds";
default "30";
description
"Indicates the RIP update time.
That is, the amount of time for which
RIP updates are sent.";
}
leaf invalid-interval {
type uint16 {
range "1..32767";
}
units "seconds";
default "180";
description
"Is the interval before a route is declared
invalid after no updates are received.
This value is at least three times
the value for the update-interval
argument.";
}
leaf holddown-interval {
type uint16 {
range "1..32767";
}
units "seconds";
default "180";
description
"Specifies the interval before better routes
are released.";
}
leaf flush-interval {
type uint16 {
range "1..32767";
}
units "seconds";
default "240";
description
"Indicates the RIP flush timer. That is,
the amount of time that must elapse before
a route is removed from the routing
table.";
}
}
leaf default-metric {
type uint8 {
range "0..16";
}
default "1";
description
"Sets the default metric.";
}
container authentication {
description
"Authentication configuration.";
leaf enable {
type boolean;
default "false";
description
"Enables or disables authentication.";
}
container keying-material {
when "../enable = 'true'";
description
"Container for describing how a RIP
session is to be secured between a CE
and a PE.";
choice option {
description
"Specifies the authentication scheme.";
case auth-key-chain {
leaf key-chain {
type key-chain:key-chain-ref;
description
"key-chain name.";
}
}
case auth-key-explicit {
leaf key {
type string;
description
"RIP authentication key in ASCII
format.";
}
leaf crypto-algorithm {
type identityref {
base key-chain:crypto-algorithm;
}
description
"Indicates the cryptographic algorithm
associated with the key.";
}
}
}
}
}
uses vpn-common:service-status;
}
container vrrp {
when "derived-from-or-self(../type, "
+ "'vpn-common:vrrp-routing')" {
description
"Only applies when protocol is VRRP.";
}
if-feature "vpn-common:rtg-vrrp";
description
"Configuration specific to VRRP.";
reference
"RFC 5798: Virtual Router Redundancy Protocol
(VRRP) Version 3 for IPv4 and IPv6";
leaf address-family {
type identityref {
base vpn-common:address-family;
}
description
"Indicates whether IPv4, IPv6, or both
address families are to be enabled.";
}
leaf vrrp-group {
type uint8 {
range "1..255";
}
description
"Includes the VRRP group identifier.";
}
leaf backup-peer {
type inet:ip-address;
description
"Indicates the IP address of the peer.";
}
leaf-list virtual-ip-address {
type inet:ip-address;
description
"Virtual IP addresses for a single VRRP
group.";
reference
"RFC 5798: Virtual Router Redundancy Protocol
(VRRP) Version 3 for IPv4 and
IPv6, Sections1.2 and 1.3";
}
leaf priority {
type uint8 {
range "1..254";
}
default "100";
description
"Sets the local priority of the VRRP
speaker.";
}
leaf ping-reply {
type boolean;
default "false";
description
"Controls whether the VRRP speaker should
answer to ping requests.";
}
uses vpn-common:service-status;
}
}
}
container oam {
description
"Defines the Operations, Administration,
and Maintenance (OAM) mechanisms used.
BFD is set as a fault detection mechanism,
but other mechanisms can be defined in the
future.";
container bfd {
if-feature "vpn-common:bfd";
description
"Container for BFD.";
leaf session-type {
type identityref {
base vpn-common:bfd-session-type;
}
default "vpn-common:classic-bfd";
description
"Specifies the BFD session type.";
}
leaf desired-min-tx-interval {
type uint32;
units "microseconds";
default "1000000";
description
"The minimum interval between transmission of
BFD control packets that the operator
desires.";
reference
"RFC 5880: Bidirectional Forwarding Detection
(BFD), Section 6.8.7";
}
leaf required-min-rx-interval {
type uint32;
units "microseconds";
description
"The minimum interval between received BFD
control packets that the PE should support.";
reference
"RFC 5880: Bidirectional Forwarding Detection
(BFD), Section 6.8.7";
}
leaf local-multiplier {
type uint8 {
range "1..255";
}
default "3";
description
"Specifies the detection multiplier that is
transmitted to a BFD peer.
The detection interval for the receiving
BFD peer is calculated by multiplying the value
of the negotiated transmission interval by
the received detection multiplier value.";
reference
"RFC 5880: Bidirectional Forwarding Detection
(BFD), Section 6.8.7";
}
leaf holdtime {
type uint32;
units "msec";
description
"Expected BFD holdtime.
The customer may impose some fixed
values for the holdtime period if the
provider allows the customer use of
this function.
If the provider doesn't allow the
customer to use this function,
the fixed-value will not be set.";
reference
"RFC 5880: Bidirectional Forwarding Detection
(BFD), Section 6.8.18";
}
leaf profile {
type leafref {
path "/l3vpn-ntw/vpn-profiles"
+ "/valid-provider-identifiers"
+ "/bfd-profile-identifier/id";
}
description
"Well-known service provider profile name.
The provider can propose some profiles
to the customer, depending on the
service level the customer wants to
achieve.";
}
container authentication {
presence "Enables BFD authentication";
description
"Parameters for BFD authentication.";
leaf key-chain {
type key-chain:key-chain-ref;
description
"Name of the key-chain.";
}
leaf meticulous {
type boolean;
description
"Enables meticulous mode.";
reference
"RFC 5880: Bidirectional Forwarding
Detection (BFD), Section 6.7";
}
}
uses vpn-common:service-status;
}
}
container security {
description
"Site-specific security parameters.";
container encryption {
if-feature "vpn-common:encryption";
description
"Container for CE-PE security encryption.";
leaf enabled {
type boolean;
default "false";
description
"If true, traffic encryption on the
connection is required. Otherwise, it
is disabled.";
}
leaf layer {
when "../enabled = 'true'" {
description
"It is included only when enryption
is enabled.";
}
type enumeration {
enum layer2 {
description
"Encryption occurs at Layer 2.";
}
enum layer3 {
description
"Encryption occurs at Layer 3.
For example, IPsec may be used when
a customer requests Layer 3
encryption.";
}
}
description
"Indicates the layer on which encryption
is applied.";
}
}
container encryption-profile {
when "../encryption/enabled = 'true'" {
description
"Indicates the layer on which encryption
is enabled.";
}
description
"Container for encryption profile.";
choice profile {
description
"Choice for the encryption profile.";
case provider-profile {
leaf profile-name {
type leafref {
path "/l3vpn-ntw/vpn-profiles"
+ "/valid-provider-identifiers"
+ "/encryption-profile-identifier/id";
}
description
"Name of the service provider's profile
to be applied.";
}
}
case customer-profile {
leaf customer-key-chain {
type key-chain:key-chain-ref;
description
"Customer-supplied key chain.";
}
}
}
}
}
container service {
description
"Service parameters of the attachment.";
leaf inbound-bandwidth {
if-feature "vpn-common:inbound-bw";
type uint64;
units "bps";
description
"From the customer site's perspective, the
service inbound bandwidth of the connection
or download bandwidth from the SP to
the site. Note that the L3SM uses 'input-
-bandwidth' to refer to the same concept.";
}
leaf outbound-bandwidth {
if-feature "vpn-common:outbound-bw";
type uint64;
units "bps";
description
"From the customer site's perspective,
the service outbound bandwidth of the
connection or upload bandwidth from
the site to the SP. Note that the L3SM uses
'output-bandwidth' to refer to the same
concept.";
}
leaf mtu {
type uint32;
units "bytes";
description
"MTU at service level. If the service is IP,
it refers to the IP MTU. If Carriers'
Carriers (CsC) is enabled, the requested MTU
will refer to the MPLS maximum labeled packet
size and not to the IP MTU.";
}
container qos {
if-feature "vpn-common:qos";
description
"QoS configuration.";
container qos-classification-policy {
description
"Configuration of the traffic classification
policy.";
uses vpn-common:qos-classification-policy;
}
container qos-action {
description
"List of QoS action policies.";
list rule {
key "id";
description
"List of QoS actions.";
leaf id {
type string;
description
"An identifier of the QoS action rule.";
}
leaf target-class-id {
type string;
description
"Identification of the class of service.
This identifier is internal to the
administration.";
}
leaf inbound-rate-limit {
type decimal64 {
fraction-digits 5;
range "0..100";
}
units "percent";
description
"Specifies whether/how to rate-limit the
inbound traffic matching this QoS policy.
It is expressed as a percent of the value
that is indicated in 'input-bandwidth'.";
}
leaf outbound-rate-limit {
type decimal64 {
fraction-digits 5;
range "0..100";
}
units "percent";
description
"Specifies whether/how to rate-limit the
outbound traffic matching this QoS policy.
It is expressed as a percent of the value
that is indicated in 'output-bandwidth'.";
}
}
}
container qos-profile {
description
"QoS profile configuration.";
list qos-profile {
key "profile";
description
"QoS profile.
Can be standard profile or customized
profile.";
leaf profile {
type leafref {
path "/l3vpn-ntw/vpn-profiles"
+ "/valid-provider-identifiers"
+ "/qos-profile-identifier/id";
}
description
"QoS profile to be used.";
}
leaf direction {
type identityref {
base vpn-common:qos-profile-direction;
}
default "vpn-common:both";
description
"The direction to which the QoS profile
is applied.";
}
}
}
}
container carriers-carrier {
if-feature "vpn-common:carriers-carrier";
description
"This container is used when the customer
provides MPLS-based services. This is
only used in the case of CsC (i.e., a
customer builds an MPLS service using an
IP VPN to carry its traffic).";
leaf signaling-type {
type enumeration {
enum ldp {
description
"Use LDP as the signaling protocol
between the PE and the CE. In this
case, an IGP routing protocol must
also be configured.";
}
enum bgp {
description
"Use BGP as the signaling protocol
between the PE and the CE.
In this case, BGP must also be configured
as the routing protocol.";
reference
"RFC 8277: Using BGP to Bind MPLS Labels
to Address Prefixes";
}
}
default "bgp";
description
"MPLS signaling type.";
}
}
container ntp {
description
"Time synchronization may be needed in some
VPNs such as infrastructure and Management
VPNs. This container includes parameters to
enable NTP service.";
reference
"RFC 5905: Network Time Protocol Version 4:
Protocol and Algorithms
Specification";
leaf broadcast {
type enumeration {
enum client {
description
"The VPN node will listen to NTP broadcast
messages on this VPN network access.";
}
enum server {
description
"The VPN node will behave as a broadcast
server.";
}
}
description
"Indicates NTP broadcast mode to use for the
VPN network access.";
}
container auth-profile {
description
"Pointer to a local profile.";
leaf profile-id {
type string;
description
"A pointer to a local authentication
profile on the VPN node is provided.";
}
}
uses vpn-common:service-status;
}
container multicast {
if-feature "vpn-common:multicast";
description
"Multicast parameters for the network
access.";
leaf access-type {
type enumeration {
enum receiver-only {
description
"The peer site only has receivers.";
}
enum source-only {
description
"The peer site only has sources.";
}
enum source-receiver {
description
"The peer site has both sources and
receivers.";
}
}
default "source-receiver";
description
"Type of multicast site.";
}
leaf address-family {
type identityref {
base vpn-common:address-family;
}
description
"Indicates the address family.";
}
leaf protocol-type {
type enumeration {
enum host {
description
"Hosts are directly connected to the
provider network.
Host protocols such as IGMP or MLD are
required.";
}
enum router {
description
"Hosts are behind a customer router.
PIM will be implemented.";
}
enum both {
description
"Some hosts are behind a customer router,
and some others are directly connected
to the provider network. Both host and
routing protocols must be used.
Typically, IGMP and PIM will be
implemented.";
}
}
default "both";
description
"Multicast protocol type to be used with
the customer site.";
}
leaf remote-source {
type boolean;
default "false";
description
"A remote multicast source is a source that is
not on the same subnet as the
vpn-network-access. When set to 'true', the
multicast traffic from a remote source is
accepted.";
}
container igmp {
when "../protocol-type = 'host' and "
+ "../address-family = 'vpn-common:ipv4' or "
+ "'vpn-common:dual-stack'";
if-feature "vpn-common:igmp";
description
"Includes IGMP-related parameters.";
list static-group {
key "group-addr";
description
"Multicast static source/group associated to
IGMP session";
leaf group-addr {
type rt-types:ipv4-multicast-group-address;
description
"Multicast group IPv4 address.";
}
leaf source-addr {
type rt-types:ipv4-multicast-source-address;
description
"Multicast source IPv4 address.";
}
}
leaf max-groups {
type uint32;
description
"Indicates the maximum number of groups.";
}
leaf max-entries {
type uint32;
description
"Indicates the maximum number of IGMP
entries.";
}
leaf max-group-sources {
type uint32;
description
"The maximum number of group sources.";
}
leaf version {
type identityref {
base vpn-common:igmp-version;
}
default "vpn-common:igmpv2";
description
"Version of the IGMP.";
}
uses vpn-common:service-status;
}
container mld {
when "../protocol-type = 'host' and "
+ "../address-family = 'vpn-common:ipv6' or "
+ "'vpn-common:dual-stack'";
if-feature "vpn-common:mld";
description
"Includes MLD-related parameters.";
list static-group {
key "group-addr";
description
"Multicast static source/group associated to
the MLD session";
leaf group-addr {
type rt-types:ipv6-multicast-group-address;
description
"Multicast group IPv6 address.";
}
leaf source-addr {
type rt-types:ipv6-multicast-source-address;
description
"Multicast source IPv6 address.";
}
}
leaf max-groups {
type uint32;
description
"Indicates the maximum number of groups.";
}
leaf max-entries {
type uint32;
description
"Indicates the maximum number of MLD
entries.";
}
leaf max-group-sources {
type uint32;
description
"The maximum number of group sources.";
}
leaf version {
type identityref {
base vpn-common:mld-version;
}
default "vpn-common:mldv2";
description
"Version of the MLD protocol.";
}
uses vpn-common:service-status;
}
container pim {
when "../protocol-type = 'router'";
if-feature "vpn-common:pim";
description
"Only applies when protocol type is PIM.";
leaf hello-interval {
type rt-types:timer-value-seconds16;
default "30";
description
"PIM hello-messages interval. If set to
'infinity' or 'not-set', no periodic
Hello messages are sent.";
reference
"RFC 7761: Protocol Independent Multicast -
Sparse Mode (PIM-SM): Protocol
Specification (Revised),
Section 4.11";
}
leaf dr-priority {
type uint32;
default "1";
description
"Indicates the preference in the DR election
process. A larger value has a higher
priority over a smaller value.";
reference
"RFC 7761: Protocol Independent Multicast -
Sparse Mode (PIM-SM): Protocol
Specification (Revised),
Section 4.3.2";
}
uses vpn-common:service-status;
}
}
}
}
}
}
}
}
}
}
}
<CODE ENDS>¶
The YANG module specified in this document defines schema for data that is designed to be accessed via network management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS [RFC8446].¶
The Network Configuration Access Control Model (NACM) [RFC8341] provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content.¶
There are a number of data nodes defined in this YANG module that are writable/creatable/deletable (i.e., config true, which is the default). These data nodes may be considered sensitive or vulnerable in some network environments. Write operations (e.g., edit-config) and delete operations to these data nodes without proper protection or authentication can have a negative effect on network operations. These are the subtrees and data nodes and their sensitivity/vulnerability in the "ietf-l3vpn-ntw" module:¶
Some readable data nodes in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g., via get, get-config, or notification) to these data nodes. These are the subtrees and data nodes and their sensitivity/vulnerability:¶
Several data nodes ('bgp', 'ospf', 'isis', 'rip', and 'bfd') rely upon [RFC8177] for authentication purposes. Therefore, this 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 format is not included in this version of the L3NM because it is not supported by the underlying device modules (e.g., [RFC8695]).¶
As discussed in Section 7.6.3, the module supports MD5 to basically accommodate the installed BGP base. MD5 suffers from the security weaknesses discussed in Section 2 of [RFC6151] or Section 2.1 of [RFC6952].¶
[RFC8633] describes best current practices to be considered in VPNs making use of NTP. Moreover, a mechanism to provide cryptographic security for NTP is specified in [RFC8915].¶
This document requests IANA to register the following URI in the "ns" subregistry within the "IETF XML Registry" [RFC3688]:¶
URI: urn:ietf:params:xml:ns:yang:ietf-l3vpn-ntw
Registrant Contact: The IESG.
XML: N/A; the requested URI is an XML namespace.
¶
This document requests IANA to register the following YANG module in the "YANG Module Names" subregistry [RFC6020] within the "YANG Parameters" registry.¶
name: ietf-l3vpn-ntw
namespace: urn:ietf:params:xml:ns:yang:ietf-l3vpn-ntw
maintained by IANA: N
prefix: l3nm
reference: RFC XXXX
¶
L3VPNs are widely used to deploy 3G/4G, fixed, and enterprise services mainly because several traffic discrimination policies can be applied within the network to deliver to the mobile customers a service that meets the SLA requirements.¶
As it is shown in the Figure 31, typically, an eNodeB (CE) is directly connected to the access routers of the mobile backhaul and their logical interfaces (one or many according to the service type) are configured in a VPN that transports the packets to the mobile core platforms. In this example, a 'vpn-node' is created with two 'vpn-network-accesses'.¶
+-------------+ +------------------+
| | | PE |
| | | 198.51.100.1 |
| eNodeB |>--------/------->|........... |
| | vlan 1 | | |
| |>--------/------->|...... | |
| | vlan 2 | | | |
| | Direct | +-------------+ |
+-------------+ Routing | | vpn-node-id | |
| | 44 | |
| +-------------+ |
| |
+------------------+
To create an L3VPN service using the L3NM, the following steps can be followed.¶
First: Create the 4G VPN service (Figure 32).¶
POST: /restconf/data/ietf-l3vpn-ntw:l3vpn-ntw/vpn-services
Host: example.com
Content-Type: application/yang-data+json
{
"ietf-l3vpn-ntw:vpn-services": {
"vpn-service": [
{
"vpn-id": "4G",
"customer-name": "mycustomer",
"vpn-service-topology": "custom",
"description": "VPN to deploy 4G services",
"vpn-instance-profiles": {
"vpn-instance-profile": [
{
"profile-id": "simple-profile",
"local-as": 65550,
"rd": "0:65550:1",
"address-family": [
{
"address-family": "vpn-common:dual-stack",
"vpn-targets": {
"vpn-target": [
{
"id": "1",
"route-targets": [
"0:65550:1"
],
"route-target-type": "both"
}
]
}
}
]
}
]
}
}
]
}
}
Second: Create a VPN node as depicted in Figure 33. In this type of service, the VPN node is equivalent to the VRF configured in the physical device ('ne-id'=198.51.100.1).¶
POST: /restconf/data/ietf-l3vpn-ntw:l3vpn-ntw/\
vpn-services/vpn-service=4G
Host: example.com
Content-Type: application/yang-data+json
{
"ietf-l3vpn-ntw:vpn-nodes": {
"vpn-node": [
{
"vpn-node-id": "44",
"ne-id": "198.51.100.1",
"active-vpn-instance-profiles": {
"vpn-instance-profile": [
{
"profile-id": "simple-profile"
}
]
}
}
]
}
}
Finally, two VPN network accesses are created using the same physical port ('interface-id'=1/1/1). Each 'vpn-network-access' has a particular VLAN (1,2) to differentiate the traffic between: Sync and data (Figure 34).¶
POST: /restconf/data/ietf-l3vpn-ntw:l3vpn-ntw/\
vpn-services/vpn-service=4G/vpn-nodes/vpn-node=44
content-type: application/yang-data+json
{
"ietf-l3vpn-ntw:vpn-network-accesses": {
"vpn-network-access": [
{
"id": "1/1/1.1",
"interface-id": "1/1/1",
"description": "Interface SYNC to eNODE-B",
"vpn-network-access-type": "vpn-common:point-to-point",
"vpn-instance-profile": "simple-profile",
"status": {
"admin-status": {
"status": "vpn-common:admin-state-up"
}
},
"connection": {
"encapsulation": {
"type": "dot1q",
"dot1q": {
"cvlan-id": 1
}
}
},
"ip-connection": {
"ipv4": {
"local-address": "192.0.2.1",
"prefix-length": 30,
"address-allocation-type": "static-address",
"static-addresses": {
"primary-address": "1",
"address": [
{
"address-id": "1",
"customer-address": "192.0.2.2"
}
]
}
},
"ipv6": {
"local-address": "2001:db8::1",
"prefix-length": 64,
"address-allocation-type": "static-address",
"primary-address": "1",
"address": [
{
"address-id": "1",
"customer-address": "2001:db8::2"
}
]
}
},
"routing-protocols": {
"routing-protocol": [
{
"id": "1",
"type": "vpn-common:direct"
}
]
}
},
{
"id": "1/1/1.2",
"interface-id": "1/1/1",
"description": "Interface DATA to eNODE-B",
"vpn-network-access-type": "vpn-common:point-to-point",
"vpn-instance-profile": "simple-profile",
"status": {
"admin-status": {
"status": "vpn-common:admin-state-up"
}
},
"connection": {
"encapsulation": {
"type": "dot1q",
"dot1q": {
"cvlan-id": 2
}
}
},
"ip-connection": {
"ipv4": {
"local-address": "192.0.2.1",
"prefix-length": 30,
"address-allocation-type": "static-address",
"static-addresses": {
"primary-address": "1",
"address": [
{
"address-id": "1",
"customer-address": "192.0.2.2"
}
]
}
},
"ipv6": {
"local-address": "2001:db8::1",
"prefix-length": 64,
"address-allocation-type": "static-address",
"primary-address": "1",
"address": [
{
"address-id": "1",
"customer-address": "2001:db8::2"
}
]
}
},
"routing-protocols": {
"routing-protocol": [
{
"id": "1",
"type": "vpn-common:direct"
}
]
}
}
]
}
}
An example of loopback interface is depicted in Figure 35.¶
{
"ietf-l3vpn-ntw:vpn-network-accesses": {
"vpn-network-access": [
{
"id": "vpn-access-loopback",
"interface-id": "Loopback1",
"description": "An example of loopback interface.",
"vpn-network-access-type": "vpn-common:loopback",
"status": {
"admin-status": {
"status": "vpn-common:admin-state-up"
}
},
"ip-connection": {
"ipv6": {
"local-address": "2001:db8::4",
"prefix-length": 128
}
}
}
]
}
}
Figure 36 shows a simplified example to illustrate how some information that is provided at the VPN service level (particularly as part of the 'vpn-instance-profiles') can be overridden by the one configured at the VPN node level. In this example, PE3 and PE4 inherit the 'vpn-instance-profiles' parameters that are specified at the VPN service level, but PE1 and PE2 are provided with "maximum-routes" values at the VPN node level that override the ones that are specified at the VPN service level.¶
{
"ietf-l3vpn-ntw:vpn-services": {
"vpn-service": [
{
"vpn-id": "override-example",
"vpn-service-topology": "vpn-common:hub-spoke",
"vpn-instance-profiles": {
"vpn-instance-profile": [
{
"profile-id": "HUB",
"role": "vpn-common:hub-role",
"local-as": 64510,
"rd-suffix": 1001,
"address-family": [
{
"address-family": "vpn-common:dual-stack",
"maximum-routes": [
{
"protocol": "vpn-common:any",
"maximum-routes": 100
}
]
}
]
},
{
"profile-id": "SPOKE",
"role": "vpn-common:spoke-role",
"local-as": 64510,
"address-family": [
{
"address-family": "vpn-common:dual-stack",
"maximum-routes": [
{
"protocol": "vpn-common:any",
"maximum-routes": 1000
}
]
}
]
}
]
},
"vpn-nodes": {
"vpn-node": [
{
"vpn-node-id": "PE1",
"ne-id": "pe1",
"router-id": "198.51.100.1",
"active-vpn-instance-profiles": {
"vpn-instance-profile": [
{
"profile-id": "HUB",
"rd": "1:198.51.100.1:1001",
"address-family": [
{
"address-family": "vpn-common:dual-stack",
"maximum-routes": [
{
"protocol": "vpn-common:any",
"maximum-routes": 10
}
]
}
]
}
]
}
},
{
"vpn-node-id": "PE2",
"ne-id": "pe2",
"router-id": "198.51.100.2",
"active-vpn-instance-profiles": {
"vpn-instance-profile": [
{
"profile-id": "SPOKE",
"address-family": [
{
"address-family": "vpn-common:dual-stack",
"maximum-routes": [
{
"protocol": "vpn-common:any",
"maximum-routes": 100
}
]
}
]
}
]
}
},
{
"vpn-node-id": "PE3",
"ne-id": "pe3",
"router-id": "198.51.100.3",
"active-vpn-instance-profiles": {
"vpn-instance-profile": [
{
"profile-id": "SPOKE"
}
]
}
},
{
"vpn-node-id": "PE4",
"ne-id": "pe4",
"router-id": "198.51.100.4",
"active-vpn-instance-profiles": {
"vpn-instance-profile": [
{
"profile-id": "SPOKE"
}
]
}
}
]
}
}
]
}
}
IPTV is mainly distributed through multicast over the LANs. In the following example, PIM-SM is enabled and functional between the PE and the CE. The PE receives multicast traffic from a CE that is directly connected to the multicast source. The signaling between PE and CE is achieved using BGP. Also, RP is statically configured for a multicast group.¶
+-----------+ +------+ +------+ +-----------+
| Multicast |---| CE |--/--| PE |----| Backbone |
| source | +------+ +------+ | IP/MPLS |
+-----------+ +-----------+
An example is provided below to illustrate how to configure a multicast L3VPN service using the L3NM.¶
First, the multicast service is created together with a generic VPN instance profile (see the excerpt of the request message body shown in Figure 38)¶
{
"ietf-l3vpn-ntw:vpn-services": {
"vpn-service": [
{
"vpn-id": "Multicast-IPTV",
"vpn-description": "Multicast IPTV VPN service",
"customer-name": "a-name",
"vpn-service-topology": "vpn-common:hub-spoke",
"vpn-instance-profiles": {
"vpn-instance-profile": [
{
"profile-id": "multicast",
"role": "ietf-vpn-common:hub-role",
"local-as": 65536,
"multicast": {
"rp": {
"rp-group-mappings": {
"rp-group-mapping": [
{
"id": "1",
"rp-address": "203.0.113.17",
"groups": {
"group": [
{
"id": "1",
"group-address": "239.130.0.0/15"
}
]
}
}
]
},
"rp-discovery": {
"rp-discovery-type": "vpn-common:static-rp"
}
}
}
}
]
}
}
]
}
}
Then, the VPN nodes are created (see the excerpt of the request message body shown in Figure 39). In this example, the VPN node will represent VRF configured in the physical device.¶
{
"ietf-l3vpn-ntw:vpn-node": [
{
"vpn-node-id": "500003105",
"description": "VRF-IPTV-MULTICAST",
"ne-id": "198.51.100.10",
"router-id": "198.51.100.10",
"active-vpn-instance-profiles": {
"vpn-instance-profile": [
{
"profile-id": "multicast",
"rd": "65536:31050202"
}
]
}
}
]
}
Finally, create the VPN network access with multicast enabled (see the excerpt of the request message body shown in Figure 40).¶
{
"ietf-l3vpn-ntw:vpn-network-access": {
"id": "1/1/1",
"description": "Connected-to-source",
"vpn-network-access-type": "vpn-common:point-to-point",
"vpn-instance-profile": "multicast",
"status": {
"admin-status": {
"status": "vpn-common:admin-state-up"
},
"ip-connection": {
"ipv4": {
"local-address": "203.0.113.1",
"prefix-length": 30,
"address-allocation-type": "static-address",
"static-addresses": {
"primary-address": "1",
"address": [
{
"address-id": "1",
"customer-address": "203.0.113.2"
}
]
}
}
},
"routing-protocols": {
"routing-protocol": [
{
"id": "1",
"type": "vpn-common:bgp-routing",
"bgp": {
"description": "Connected to CE",
"peer-as": "65537",
"address-family": "vpn-common:ipv4",
"neighbor": "203.0.113.2"
}
}
]
},
"service": {
"inbound-bandwidth": "100000000",
"outbound-bandwidth": "100000000",
"mtu": 1500,
"multicast": {
"access-type": "source-only",
"address-family": "vpn-common:ipv4",
"protocol-type": "router",
"pim": {
"hello-interval": 30,
"status": {
"admin-status": {
"status": "vpn-common:admin-state-up"
}
}
}
}
}
}
}
}
This section records the status of known implementations of the YANG module defined by this specification at the time of posting of this document and is based on a proposal described in [RFC7942]. The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist.¶
According to [RFC7942], "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit".¶
Note to the RFC Editor: As per [RFC7942] guidelines, please remove this Implementation Status apendix prior publication.¶
Details can be found at: https://github.com/IETF-OPSAWG-WG/l3nm/blob/master/Implementattion/Nokia.txt¶
Details can be found at: https://github.com/IETF-OPSAWG-WG/l3nm/blob/master/Implementattion/Huawei.txt¶
Details can be found at: https://github.com/IETF-OPSAWG-WG/l3nm/blob/master/Implementattion/Infinera.txt¶
Details can be found at: https://github.com/IETF-OPSAWG-WG/l3nm/blob/master/Implementattion/Ribbon-ECI.txt¶
https://github.com/IETF-OPSAWG-WG/lxnm/blob/master/Implementattion/Juniper¶
During the discussions of this work, helpful comments, suggestions, and reviews were received from (listed alphabetically): Raul Arco, Miguel Cros Cecilia, Joe Clarke, Dhruv Dhody, Adrian Farrel, Roque Gagliano, Christian Jacquenet, Kireeti Kompella, Julian Lucek, Greg Mirsky, and Tom Petch. Many thanks to them. Thanks to Philip Eardly for the review of an early version of the document.¶
Daniel King, Daniel Voyer, Luay Jalil, and Stephane Litkowski contributed to early version of the individual submission. Many thanks to Robert Wilton for the AD review. Thanks to Andrew Malis for the routing directorate review, Rifaat Shekh-Yusef for the security directorate review, and Qin Wu for the opsdir review. Thanks to Michael Scharf for the discussion on TCP-AO. Thanks to Martin Duke, Lars Eagert, Zaheduzzaman Sarker, Roman Danyliw, Erik Kline, and Benjamin Kaduk for the IESG review.¶
This work was supported in part by the European Commission funded H2020-ICT-2016-2 METRO-HAUL project (G.A. 761727) and Horizon 2020 Secured autonomic traffic management for a Tera of SDN flows (Teraflow) project (G.A. 101015857).¶
Victor Lopez Telefonica Email: victor.lopezalvarez@telefonica.com Qin Wu Huawei Email: bill.wu@huawei.com> Manuel Julian Vodafone Email: manuel-julian.lopez@vodafone.com Lucia Oliva Ballega Telefonica Email: lucia.olivaballega.ext@telefonica.com Erez Segev ECI Telecom Email: erez.segev@ecitele.com> Paul Sherratt Gamma Telecom Email: paul.sherratt@gamma.co.uk¶