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
RFC 8340). Instead, subtrees are provided for the reader's convenience.
The "ietf-l3vpn-ntw" module uses two main containers: 'vpn-profiles' and 'vpn-services' (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. The '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 reason, 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 value 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 [
RFC 9181] 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 for 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:
-
'external-connectivity-identifier':
-
This identifier refers to a profile that defines the external connectivity provided to a VPN service (or a subset of VPN sites). External connectivity may be access to the Internet or restricted connectivity, such as access to a public/private cloud.
-
'encryption-profile-identifier':
-
An encryption profile refers to a set of policies related to the encryption schemes and setup that can be applied when building and offering a VPN service.
-
'qos-profile-identifier':
-
A Quality of Service (QoS) profile refers to a set of policies, such as classification, marking, and actions (e.g., [RFC 3644]).
-
'bfd-profile-identifier':
-
A Bidirectional Forwarding Detection (BFD) profile refers to a set of BFD policies [RFC 5880] that can be invoked when building a VPN service.
-
'forwarding-profile-identifier':
-
A forwarding profile refers to the policies that apply to the forwarding of packets conveyed within a VPN. Such policies may consist, for example, of applying Access Control Lists (ACLs).
-
'routing-profile-identifier':
-
A routing profile refers to a set of routing policies that will be invoked (e.g., BGP policies) when delivering the VPN service.
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 a '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)
| | +--rw transport-instance-id? string
| | +--rw instance-type? identityref
| +--:(protocol)
| +--rw protocol* identityref
+--rw external-connectivity
| {vpn-common:external-connectivity}?
| +--rw (profile)?
| +--:(profile)
| +--rw profile-name? leafref
+--rw vpn-nodes
...
The descriptions of the VPN service data nodes that are depicted in
Figure 5 are as follows:
-
'vpn-id':
-
An identifier that is used to uniquely identify the L3VPN service within the L3NM scope.
-
'vpn-name':
-
Associates a name with the service in order to facilitate the identification of the service.
-
'vpn-description':
-
Includes a textual description of the service.
The internal structure of a VPN description is local to each VPN service provider.
-
'customer-name':
-
Indicates the name of the customer who ordered the service.
-
'parent-service-id':
-
Refers to an identifier of the parent service (e.g., L3SM, IETF network slice, VPN+) that triggered the creation of the VPN service. This identifier is used to easily correlate the (network) service as built in the network with a service order. A controller can use that correlation to enrich or populate some fields (e.g., description fields) as a function of local deployments.
-
'vpn-type':
-
Indicates the VPN type. The values are taken from [RFC 9181]. For the L3NM, this is typically set to "BGP/MPLS L3VPN", but other values may be defined to support specific Layer 3 VPN capabilities (e.g., [RFC 9136]).
-
'vpn-service-topology':
-
Indicates the network topology for the service: 'hub-spoke', 'any-to-any', or 'custom'. The network implementation of this attribute is defined by the correct usage of import and export targets (Section 4.3.5 of RFC 4364).
-
'status':
-
Used to track the service status of a given VPN service. Both operational status and administrative status are maintained together with a timestamp. For example, a service can be created but not put into effect.
Administrative status and operational status can be used as a trigger to detect service anomalies. For example, a service that is declared active at the service layer but is 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.
-
'vpn-instance-profiles':
-
Defines reusable parameters for the same 'vpn-service'.
More details are provided in Section 7.4.
-
'underlay-transport':
-
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 [RFC 9181].
-
'external-connectivity':
-
Indicates whether/how external connectivity is provided to the VPN service. For example, a service provider may provide external connectivity to a VPN customer (e.g., to a public cloud). Such a service may involve tweaking both filtering and NAT rules (e.g., binding a Virtual Routing and Forwarding (VRF) interface with a NAT instance as discussed in Section 2.10 of RFC 8512). These value-added features may be bound to all, or a subset of, network accesses. Some of these value-added features may be implemented in a PE or in nodes other 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.
-
'vpn-node':
-
An abstraction that represents a set of policies applied to a network node and belonging 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 because this is a network data model, information about customers' sites is not required in the model. Rather, such information is relevant in the L3SM. Whether that information is included in the L3NM, e.g., to populate the various 'description' data nodes, 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 instance.
The subtree of the 'vpn-instance-profiles' 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 uint8
| | | | +--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 descriptions of the listed data nodes are as follows:
-
'profile-id':
-
Used to uniquely identify a VPN instance profile.
-
'role':
-
Indicates the role of the VPN instance profile in the VPN. Role values are defined in [RFC 9181] (e.g., 'any-to-any-role', 'spoke-role', 'hub-role').
-
'local-as':
-
Indicates the Autonomous System Number (ASN) that is configured for the VPN node.
-
'rd':
-
As defined in [RFC 9181], the following RD assignment modes are supported: direct assignment, full automatic assignment, automatic assignment from a given pool, and no assignment. For illustration purposes, the following modes can be used in the deployment cases:
-
'directly-assigned':
-
The VPN service provider (service orchestrator) assigns RDs explicitly. This case will fit with a brownfield scenario where some existing services need to be updated by the VPN service provider.
-
'full-auto':
-
The network controller auto-assigns RDs. This can apply for the deployment of new services.
-
'no-rd':
-
The VPN service provider (service orchestrator) explicitly wants no RD to be assigned. This case can be used for CE testing within the network or for troubleshooting proposes.
Also, the module accommodates deployments where only the Assigned Number subfield of RDs (Section 4.2 of RFC 4364) is assigned from a pool while the Administrator subfield is set to, for example, 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.
-
'address-family':
-
Includes a set of data nodes per address family:
-
'address-family':
-
Identifies the address family. It can be set to 'ipv4', 'ipv6', or 'dual-stack'.
-
'vpn-targets':
-
Specifies RT import/export rules for the VPN service (Section 4.3 of RFC 4364).
-
'maximum-routes':
-
Indicates the maximum number of prefixes that the VPN node can accept for a given routing protocol. If 'protocol' is set to 'any', this means that the maximum value applies to each active routing protocol.
-
'multicast':
-
Enables multicast traffic in the VPN service. Refer to Section 7.7.
The 'vpn-node' is an abstraction that represents a set of common policies applied on a given network node (typically, a PE) and belonging 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 to a VRF instance 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 VRF instances.
The VPN node subtree structure is shown in
Figure 7.
+--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
...
The descriptions of the 'vpn-node' data nodes (
Figure 7) are as follows:
-
'vpn-node-id':
-
An identifier that uniquely identifies a node that enables a VPN network access.
-
'description':
-
Provides a textual description of the VPN node.
-
'ne-id':
-
Includes a unique identifier of the network element where the VPN node is deployed.
-
'local-as':
-
Indicates the ASN that is configured for the VPN node.
-
'router-id':
-
Indicates a 32-bit number that is used to uniquely identify a router within an AS.
-
'active-vpn-instance-profiles':
-
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 structure discussed in Section 7.4, except that the structure of 'active-vpn-instance-profiles' includes 'router-id' but does not include the 'role' leaf. 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 a capability is supported by involved routers.
Values defined in 'active-vpn-instance-profiles' override the values defined at the VPN service level. An example is shown in Appendix A.3.
-
'msdp':
-
For redundancy purposes, the Multicast Source Discovery Protocol (MSDP) [RFC 3618] may be enabled and used to share state information about sources between multiple Rendezvous Points (RPs). The purpose of MSDP in this context is to enhance the robustness of the multicast service. MSDP may be configured on non-RP routers; this is useful in a domain that does not support multicast sources but does support multicast transit.
-
'groups':
-
Lists the groups to which a VPN node belongs [RFC 9181]. For example, the 'group-id' is used to associate redundancy or protection constraints with VPN nodes.
-
'status':
-
Tracks the status of a node involved in a VPN service. Both operational status and administrative status are maintained. A mismatch between the administrative status vs. the operational status can be used as a trigger to detect anomalies.
-
'vpn-network-accesses':
-
Represents the point to which sites are connected.
Note that unlike the L3SM, the L3NM does not need to model the customer site -- only the points that receive traffic from the site (i.e., the PE side of Provider Edge to Customer Edge (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
...
A 'vpn-network-access' (
Figure 8) includes the following data nodes:
-
'id':
-
An identifier of the VPN network access.
-
'interface-id':
-
Indicates the physical or logical interface on which the VPN network access is bound.
-
'description':
-
Includes a textual description of the VPN network access.
-
'vpn-network-access-type':
-
Used to select the type of network interface to be deployed in the devices. The available defined values are as follows:
-
'point-to-point':
-
Represents a direct connection between the endpoints. The controller must keep the association between a logical or physical interface on the device with the 'id' of the 'vpn-network-access'.
-
'multipoint':
-
Represents a multipoint connection between the customer site and the PEs. The controller must keep the association between a logical or physical interface on the device with the 'id' of the 'vpn-network-access'.
-
'irb':
-
Represents a connection coming from an L2VPN service. An identifier of such a service ('l2vpn-id') may be included in the 'connection' container, as depicted in Figure 9 (Section 7.6.1). The controller must keep the relationship between the logical tunnels or bridges on the devices with the 'id' of the 'vpn-network-access'.
-
'loopback':
-
Represents the creation of a logical interface on a device. An example that illustrates how a loopback interface can be used in the L3NM is provided in Appendix A.2.
-
'vpn-instance-profile':
-
Provides a pointer to an active VPN instance profile at the VPN node level. Referencing an active VPN instance profile implies that all associated data nodes will be inherited by the VPN network access. However, some inherited data nodes (e.g., multicast) can be overridden at the VPN network access level. In such a case, adjusted values take precedence over inherited values.
-
'status':
-
Indicates both operational status and administrative status of a VPN network access.
-
'connection':
-
Represents and groups the set of Layer 2 connectivity from where the traffic of the L3VPN in a particular VPN network access is coming. See Section 7.6.1.
-
'ip-connection':
-
Contains Layer 3 connectivity information on a VPN network access (e.g., IP addressing). See Section 7.6.2.
-
'routing-protocols':
-
Includes the CE-PE routing configuration information. See Section 7.6.3.
-
'oam':
-
Specifies the Operations, Administration, and Maintenance (OAM) mechanisms used for a VPN network access. See Section 7.6.4.
-
'security':
-
Specifies the authentication and the encryption to be applied for a given VPN network access. See Section 7.6.5.
-
'service':
-
Specifies the service parameters (e.g., QoS, multicast) to apply for a given VPN network access. See Section 7.6.6.
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 the configuration of 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 a tunneling service (e.g., a Virtual Private LAN Service (VPLS) or a Virtual eXtensible Local Area Network (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
RFC 8077).
As discussed in
Section 7.6, 'l2vpn-id' is used to identify the L2VPN service that is associated with an Integrated Routing and Bridging (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 [
RFC 4176], 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 2 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 with a network element and a port. Hence, a bearer is just a 'bearer-reference' to allow the association between a service request (e.g., the L3SM) and the L3NM.
The L3NM can be used to create a Link Aggregation Group (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
| | | +--rw tag-type? identityref
| | | +--rw cvlan-id? uint16
| | +--rw priority-tagged
| | | +--rw tag-type? identityref
| | +--rw 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
| | | +--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 interface indicated under the 'connection' container may be needed to terminate the Layer 3 service. The identifier of such an 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, Stateless Address Autoconfiguration (SLAAC) [
RFC 4862] 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 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 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
| | ...
| +--rw ospf
| | ...
| +--rw isis
| | ...
| +--rw rip
| | ...
| +--rw 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 [
RFC 9181] (the '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, as shown in
Figure 1) to decide on 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:
-
Multiple BGP processes with a single neighbor running in each process.
-
A single BGP process with multiple neighbors running.
-
A combination thereof.
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, using one single container to group both static entries independently of their address family was considered at one time, but that design was abandoned to ease the mapping, using the structure provided in [
RFC 8299].
The static routing subtree structure is shown in
Figure 15.
...
+--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:
-
'lan-tag':
-
Indicates a local tag (e.g., "myfavorite-lan") that is used to enforce local policies.
-
'next-hop':
-
Indicates the next hop to be used for the static route. It can be identified by an IP address, a predefined next-hop type (e.g., 'discard' or 'local-link'), etc.
-
'bfd-enable':
-
Indicates whether BFD is enabled or disabled for this static route entry.
-
'metric':
-
Indicates the metric associated with the static route entry. This metric is used when the route is exported into an IGP.
-
'preference':
-
Indicates the preference associated with the static route entry. This preference is used to select a preferred route among routes to the same destination prefix.
-
'status':
-
Used to convey the status of a static route entry. This data node can also be used to control the (de)activation of individual static route entries.
The L3NM allows the configuration of a BGP neighbor, including a set of 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 BGP routing subtree structure is shown in
Figure 16.
...
+--rw routing-protocols
| +--rw routing-protocol* [id]
| ...
| +--rw 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
...
The following data nodes are captured in
Figure 16. It is up to the implementation (e.g., network orchestrator) to derive the corresponding BGP device configuration:
-
'description':
-
Includes a description of the BGP session.
-
'local-as':
-
Indicates a local AS Number (ASN), if a distinct ASN is required other than the ASN configured at the VPN node level.
-
'peer-as':
-
Conveys the customer's ASN.
-
'address-family':
-
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) as defined in Section 4.3.4 of RFC 4364).
-
'local-address':
-
Specifies an address or a reference to an interface to use when establishing the BGP transport session.
-
'neighbor':
-
Can indicate two neighbors (each for a given address family) or one neighbor (if the 'address-family' attribute is set to 'dual-stack'). A list of IP address(es) of the BGP neighbor(s) can then be conveyed in this data node.
-
'multihop':
-
Indicates the number of allowed IP hops between a PE and its BGP peer.
-
'as-override':
-
If set, this parameter indicates whether ASN override is enabled, i.e., replacing the ASN of the customer specified in the AS_PATH BGP attribute with the ASN identified in the 'local-as' attribute.
-
'allow-own-as':
-
Used in some topologies (e.g., hub-and-spoke) to allow the provider's ASN to be included in the AS_PATH BGP attribute received from a CE. Loops are prevented by setting 'allow-own-as' to a maximum number of the provider's ASN occurrences. By default, this parameter is set to '0' (that is, reject any AS_PATH attribute that includes the provider's ASN).
-
'prepend-global-as':
-
When distinct ASNs are configured at the VPN node and network access levels, this parameter controls whether the ASN provided at the VPN node level is prepended to the AS_PATH attribute.
-
'send-default-route':
-
Controls whether default routes can be advertised to the peer.
-
'site-of-origin':
-
Meant to uniquely identify the set of routes learned from a site via a particular CE-PE connection. It is used to prevent routing loops (Section 7 of RFC 4364). The Site of Origin attribute is encoded as a Route Origin Extended Community.
-
'ipv6-site-of-origin':
-
Carries an IPv6 Address Specific BGP Extended Community that is used to indicate the Site of Origin for VRF information [RFC 5701]. It is used to prevent routing loops.
-
'redistribute-connected':
-
Controls whether the PE-CE link is advertised to other PEs.
-
'bgp-max-prefix':
-
Controls the behavior when a prefix maximum is reached.
-
'max-prefix':
-
Indicates the maximum number of BGP prefixes allowed in the BGP session. If the limit is reached, the action indicated in 'violate-action' will be followed.
-
'warning-threshold':
-
A warning notification is triggered when this limit is reached.
-
'violate-action':
-
Indicates which action to execute when the maximum number of BGP prefixes is reached. Examples of such actions include sending a warning message, discarding extra paths from the peer, or restarting the session.
-
'restart-timer':
-
Indicates, in seconds, the time interval after which the BGP session will be reestablished.
-
'bgp-timers':
-
Two timers can be captured in this container: (1) 'hold-time', which is the time interval that will be used for the Hold Timer (Section 4.2 of RFC 4271) when establishing a BGP session and (2) 'keepalive', which is the time interval for the KeepaliveTimer between a PE and a BGP peer (Section 4.4 of RFC 4271). Both timers are expressed in seconds.
-
'authentication':
-
The module adheres to the recommendations in Section 13.2 of RFC 4364, as it allows enabling the TCP Authentication Option (TCP-AO) [RFC 5925] and accommodates the installed base that makes use of MD5. In addition, the module includes a provision for using IPsec.
This version of the L3NM assumes that parameters specific to the TCP-AO 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 preconfigured. However, the structure of the key chain should cover data nodes beyond those in [RFC 8177], mainly SendID and RecvID (Section 3.1 of RFC 5925).
-
'status':
-
Indicates the status of the BGP routing instance.
OSPF can be configured to run as a routing protocol on the 'vpn-network-access'.
The OSPF routing subtree structure is shown in
Figure 17.
...
+--rw routing-protocols
| +--rw routing-protocol* [id]
| ...
| +--rw 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 string
| | | +--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:
-
'address-family':
-
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 [RFC 4577] or OSPFv3 [RFC 6565] is used to announce IPv4 routes. Such a decision will typically be reflected in the device configurations that will be derived to implement the L3VPN.
-
'area-id':
-
Indicates the OSPF Area ID.
-
'metric':
-
Associates a metric with OSPF routes.
-
'sham-links':
-
Used to create OSPF sham links between two VPN network accesses sharing the same area and having a backdoor link (Section 4.2.7 of RFC 4577 and Section 5 of RFC 6565).
-
'max-lsa':
-
Sets the maximum number of Link State Advertisements (LSAs) that the OSPF instance will accept.
-
'authentication':
-
Controls the authentication schemes to be enabled for the OSPF instance. The following options are supported: IPsec for OSPFv3 authentication [RFC 4552], and the Authentication Trailer for OSPFv2 [RFC 5709] [RFC 7474] and OSPFv3 [RFC 7166].
-
'status':
-
Indicates the status of the OSPF routing instance.
The model allows the user to configure IS-IS [
ISO10589] [
RFC 1195] [
RFC 5308] to run on the 'vpn-network-access' interface. See
Figure 18.
...
+--rw routing-protocols
| +--rw routing-protocol* [id]
| ...
| +--rw 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:
-
'address-family':
-
Indicates whether IPv4, IPv6, or both address families are to be activated.
-
'area-address':
-
Indicates the IS-IS area address.
-
'level':
-
Indicates the IS-IS level: Level 1, Level 2, or both.
-
'metric':
-
Associates a metric with IS-IS routes.
-
'mode':
-
Indicates the IS-IS interface mode type. It can be set to 'active' (that is, send or receive IS-IS protocol control packets) or 'passive' (that is, suppress the sending of IS-IS updates through the interface).
-
'authentication':
-
Controls the authentication schemes to be enabled for the IS-IS instance. Both the specification of a key chain [RFC 8177] and the direct specification of key and authentication algorithms are supported.
-
'status':
-
Indicates the status of the IS-IS routing instance.
The model allows the user to configure RIP to run on the 'vpn-network-access' interface. See
Figure 19.
...
+--rw routing-protocols
| +--rw routing-protocol* [id]
| ...
| +--rw rip
| | +--rw address-family? identityref
| | +--rw timers
| | | +--rw update-interval? uint16
| | | +--rw invalid-interval? uint16
| | | +--rw holddown-interval? uint16
| | | +--rw flush-interval? uint16
| | +--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
...
As shown in
Figure 19, the following RIP data nodes are supported:
-
'address-family':
-
Indicates whether IPv4, IPv6, or both address families are to be activated. This parameter is used to determine whether RIPv2 [RFC 2453], RIP Next Generation (RIPng), or both are to be enabled [RFC 2080].
-
'timers':
-
Indicates the following timers:
-
'update-interval':
-
The interval at which RIP updates are sent.
-
'invalid-interval':
-
The interval before a RIP route is declared invalid.
-
'holddown-interval':
-
The interval before better RIP routes are released.
-
'flush-interval':
-
The interval before a route is removed from the routing table.
These timers are expressed in seconds.
-
'default-metric':
-
Sets the default RIP metric.
-
'authentication':
-
Controls the authentication schemes to be enabled for the RIP instance.
-
'status':
-
Indicates the status of the RIP routing instance.
The model allows enabling the Virtual Router Redundancy Protocol (VRRP) on the 'vpn-network-access' interface. See
Figure 20.
...
+--rw routing-protocols
| +--rw routing-protocol* [id]
| ...
| +--rw 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
...
The following data nodes are supported:
-
'address-family':
-
Indicates whether IPv4, IPv6, or both address families are to be activated. Note that VRRP version 3 [RFC 5798] supports both IPv4 and IPv6.
-
'vrrp-group':
-
Used to identify the VRRP group.
-
'backup-peer':
-
Carries the IP address of the peer.
-
'virtual-ip-address':
-
Includes virtual IP addresses for a single VRRP group.
-
'priority':
-
Assigns the VRRP election priority for the backup virtual router.
-
'ping-reply':
-
Controls whether the VRRP speaker should reply to ping requests.
-
'status':
-
Indicates the status of the VRRP instance.
Note that no authentication data node is included for VRRP, as there isn't any type of VRRP authentication at this time (see
Section 9 of
RFC 5798).
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:
-
'session-type':
-
Indicates which BFD flavor is used to set up the session (e.g., classic BFD [RFC 5880], Seamless BFD [RFC 7880]). By default, it is assumed that the BFD session will follow the behavior specified in [RFC 5880].
-
'desired-min-tx-interval':
-
The minimum interval, in microseconds, that a PE would like to use when transmitting BFD Control packets, less any jitter applied.
-
'required-min-rx-interval':
-
The minimum interval, in microseconds, between received BFD Control packets that a PE is capable of supporting, less any jitter applied by the sender.
-
'local-multiplier':
-
The negotiated transmit interval, multiplied by this value, provides the detection time for the peer.
-
'holdtime':
-
Used to indicate the expected BFD holddown time, in milliseconds. This value may be inherited from the service request (see Section 6.3.2.2.2 of RFC 8299).
-
'profile':
-
Refers to a BFD profile (Section 7.2). Such a profile can be set by the provider or inherited from the service request (see Section 6.3.2.2.2 of RFC 8299).
-
'authentication':
-
Includes the required information to enable the BFD authentication modes discussed in Section 6.7 of RFC 5880. In particular, 'meticulous' controls the activation of meticulous mode as discussed in Sections 6.7.3 and 6.7.4 of [RFC 5880].
-
'status':
-
Indicates the status of BFD.
The 'security' container specifies the authentication and the encryption to be applied to traffic for a given VPN network access. As depicted in the subtree shown in
Figure 22, the L3NM can be used to directly control the encryption to be applied (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?
| key-chain: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 pe-to-ce-bandwidth? uint64 {vpn-common:inbound-bw}?
+--rw ce-to-pe-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:
-
'pe-to-ce-bandwidth':
-
Indicates, in bits per second (bps), the inbound bandwidth of the connection (i.e., the download bandwidth from the service provider to the site).
-
'ce-to-pe-bandwidth':
-
Indicates, in bps, the outbound bandwidth of the connection (i.e., the upload bandwidth from the site to the service provider).
-
'mtu':
-
Indicates the MTU at the service level.
-
'qos':
-
Used to define a set of QoS policies to apply on a given connection (refer to Section 7.6.6.2 for more details).
-
'carriers-carrier':
-
Groups a set of parameters that are used when Carriers' Carriers (CsC) is enabled, such as using BGP for signaling purposes [RFC 8277].
-
'ntp':
-
Time synchronization may be needed in some VPNs, such as infrastructure and management VPNs. This container is used to enable the NTP service [RFC 5905].
-
'multicast':
-
Specifies the multicast mode and other data nodes, such as the address family. Refer to Section 7.7.
The '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 the following:
-
Layer 3:
-
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
...
-
Layer 4:
-
As discussed in [RFC 9181], 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 [RFC 9181], some transport protocols use existing protocols (e.g., TCP or UDP) as the substrate. The match criteria for such protocols may rely upon the 'protocol' setting under 'l3', TCP/UDP match criteria as 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
...
-
Application match:
-
Relies upon application-specific classification (Figure 24).
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 (
Figure 28)) 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 have the structure shown in
Figure 28.
...
+--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-group 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 traffic delivery that is more optimal (e.g., requested per the guidance in [
RFC 8299]), 'optimal-traffic-delivery' can be set. When set to 'true', the implementation must use any mechanism to provide traffic delivery that is more optimal for the customer. For example, anycast is one of the mechanisms for enhancing RP redundancy, providing resilience against failures, and recovering from failures quickly.
When configuring multicast-related parameters at the VPN node level (
Figure 29), the same structure as the structure depicted in
Figure 30 is used. When defined at the VPN node level, Internet Group Management Protocol (IGMP) parameters [
RFC 1112] [
RFC 2236] [
RFC 3376], Multicast Listener Discovery (MLD) parameters [
RFC 2710] [
RFC 3810], and Protocol Independent Multicast (PIM) parameters [
RFC 7761] 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 at 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