--- 1/draft-ietf-opsawg-l3sm-l3nm-11.txt 2021-09-27 03:13:15.394179228 -0700
+++ 2/draft-ietf-opsawg-l3sm-l3nm-12.txt 2021-09-27 03:13:15.706187047 -0700
@@ -1,31 +1,33 @@
-OPSAWG S.B. Barguil
-Internet-Draft O.G.D. Gonzalez de Dios, Ed.
+OPSAWG S. Barguil
+Internet-Draft O. Gonzalez de Dios, Ed.
Intended status: Standards Track Telefonica
-Expires: 14 March 2022 M. Boucadair, Ed.
+Expires: 31 March 2022 M. Boucadair, Ed.
Orange
- L.A. Munoz
+ L. Munoz
Vodafone
- A.A. Aguado
+ A. Aguado
Nokia
- 10 September 2021
+ 27 September 2021
A Layer 3 VPN Network YANG Model
- draft-ietf-opsawg-l3sm-l3nm-11
+ draft-ietf-opsawg-l3sm-l3nm-12
Abstract
- 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.
+ 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.
Editorial Note (To be removed by RFC Editor)
Please update these statements within the document with the RFC
number to be assigned to this document:
@@ -49,87 +51,95 @@
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 14 March 2022.
+ This Internet-Draft will expire on 31 March 2022.
Copyright Notice
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
- 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. L3NM Reference Architecture . . . . . . . . . . . . . . . . . 7
- 5. Relation with other YANG Models . . . . . . . . . . . . . . . 10
- 6. Sample Uses of the L3NM Data Model . . . . . . . . . . . . . 11
- 6.1. Enterprise Layer 3 VPN Services . . . . . . . . . . . . . 11
- 6.2. Multi-Domain Resource Management . . . . . . . . . . . . 12
- 6.3. Management of Multicast Services . . . . . . . . . . . . 12
- 7. Description of the L3NM YANG Module . . . . . . . . . . . . . 12
- 7.1. Overall Structure of the Module . . . . . . . . . . . . . 13
- 7.2. VPN Profiles . . . . . . . . . . . . . . . . . . . . . . 13
- 7.3. VPN Services . . . . . . . . . . . . . . . . . . . . . . 15
- 7.4. VPN Instance Profiles . . . . . . . . . . . . . . . . . . 18
- 7.5. VPN Nodes . . . . . . . . . . . . . . . . . . . . . . . . 20
- 7.6. VPN Network Access . . . . . . . . . . . . . . . . . . . 23
- 7.6.1. Connection . . . . . . . . . . . . . . . . . . . . . 26
- 7.6.2. IP Connection . . . . . . . . . . . . . . . . . . . . 27
- 7.6.3. CE-PE Routing Protocols . . . . . . . . . . . . . . . 31
- 7.6.4. OAM . . . . . . . . . . . . . . . . . . . . . . . . . 43
- 7.6.5. Security . . . . . . . . . . . . . . . . . . . . . . 45
- 7.6.6. Services . . . . . . . . . . . . . . . . . . . . . . 45
- 7.7. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 51
- 8. L3NM YANG Module . . . . . . . . . . . . . . . . . . . . . . 55
- 9. Security Considerations . . . . . . . . . . . . . . . . . . . 116
- 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 117
- 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 117
- 11.1. Normative References . . . . . . . . . . . . . . . . . . 117
- 11.2. Informative References . . . . . . . . . . . . . . . . . 121
- Appendix A. L3VPN Examples . . . . . . . . . . . . . . . . . . . 126
- A.1. 4G VPN Provisioning Example . . . . . . . . . . . . . . . 126
- A.2. Loopback Interface . . . . . . . . . . . . . . . . . . . 131
- A.3. Overriding VPN Instance Profile Parameters . . . . . . . 132
- A.4. Multicast VPN Provisioning Example . . . . . . . . . . . 135
- Appendix B. Implementation Status . . . . . . . . . . . . . . . 139
- B.1. Nokia Implementation . . . . . . . . . . . . . . . . . . 139
- B.2. Huawei Implementation . . . . . . . . . . . . . . . . . . 139
- B.3. Infinera Implementation . . . . . . . . . . . . . . . . . 139
- B.4. Ribbon-ECI Implementation . . . . . . . . . . . . . . . . 139
- B.5. Juniper Implementation . . . . . . . . . . . . . . . . . 140
- Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 140
- Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 140
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 141
+ 5. Relation with other YANG Models . . . . . . . . . . . . . . . 11
+ 6. Sample Uses of the L3NM Data Model . . . . . . . . . . . . . 12
+ 6.1. Enterprise Layer 3 VPN Services . . . . . . . . . . . . . 12
+ 6.2. Multi-Domain Resource Management . . . . . . . . . . . . 13
+ 6.3. Management of Multicast Services . . . . . . . . . . . . 13
+ 7. Description of the L3NM YANG Module . . . . . . . . . . . . . 13
+ 7.1. Overall Structure of the Module . . . . . . . . . . . . . 14
+ 7.2. VPN Profiles . . . . . . . . . . . . . . . . . . . . . . 15
+ 7.3. VPN Services . . . . . . . . . . . . . . . . . . . . . . 16
+ 7.4. VPN Instance Profiles . . . . . . . . . . . . . . . . . . 20
+ 7.5. VPN Nodes . . . . . . . . . . . . . . . . . . . . . . . . 22
+ 7.6. VPN Network Accesses . . . . . . . . . . . . . . . . . . 25
+ 7.6.1. Connection . . . . . . . . . . . . . . . . . . . . . 28
+ 7.6.2. IP Connection . . . . . . . . . . . . . . . . . . . . 29
+ 7.6.3. CE-PE Routing Protocols . . . . . . . . . . . . . . . 33
+ 7.6.3.1. Static Routing . . . . . . . . . . . . . . . . . 35
+ 7.6.3.2. BGP . . . . . . . . . . . . . . . . . . . . . . . 37
+ 7.6.3.3. OSPF . . . . . . . . . . . . . . . . . . . . . . 40
+ 7.6.3.4. IS-IS . . . . . . . . . . . . . . . . . . . . . . 42
+ 7.6.3.5. RIP . . . . . . . . . . . . . . . . . . . . . . . 44
+ 7.6.3.6. VRRP . . . . . . . . . . . . . . . . . . . . . . 45
+ 7.6.4. OAM . . . . . . . . . . . . . . . . . . . . . . . . . 46
+ 7.6.5. Security . . . . . . . . . . . . . . . . . . . . . . 48
+ 7.6.6. Services . . . . . . . . . . . . . . . . . . . . . . 48
+ 7.6.6.1. Overview . . . . . . . . . . . . . . . . . . . . 48
+ 7.6.6.2. QoS . . . . . . . . . . . . . . . . . . . . . . . 50
+ 7.7. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 55
+ 8. L3NM YANG Module . . . . . . . . . . . . . . . . . . . . . . 59
+ 9. Security Considerations . . . . . . . . . . . . . . . . . . . 120
+ 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 122
+ 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 122
+ 11.1. Normative References . . . . . . . . . . . . . . . . . . 122
+ 11.2. Informative References . . . . . . . . . . . . . . . . . 126
+ Appendix A. L3VPN Examples . . . . . . . . . . . . . . . . . . . 131
+ A.1. 4G VPN Provisioning Example . . . . . . . . . . . . . . . 131
+ A.2. Loopback Interface . . . . . . . . . . . . . . . . . . . 137
+ A.3. Overriding VPN Instance Profile Parameters . . . . . . . 138
+ A.4. Multicast VPN Provisioning Example . . . . . . . . . . . 141
+ Appendix B. Implementation Status . . . . . . . . . . . . . . . 145
+ B.1. Nokia Implementation . . . . . . . . . . . . . . . . . . 145
+ B.2. Huawei Implementation . . . . . . . . . . . . . . . . . . 145
+ B.3. Infinera Implementation . . . . . . . . . . . . . . . . . 145
+ B.4. Ribbon-ECI Implementation . . . . . . . . . . . . . . . . 145
+ B.5. Juniper Implementation . . . . . . . . . . . . . . . . . 146
+ Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 146
+ Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 146
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 147
1. Introduction
[RFC8299] defines a Layer 3 Virtual Private Network Service YANG data
Model (L3SM) that can be used for communication between customers and
- network operators. Such a model focuses on describing the customer
+ 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
@@ -278,21 +288,21 @@
MLD Multicast Listener Discovery
MSDP Multicast Source Discovery Protocol
MVPN Multicast VPN
NAT Network Address Translation
OAM Operations, Administration, and Maintenance
OSPF Open Shortest Path First
PE Provider Edge
PIM Protocol Independent Multicast
QoS Quality of Service
RD Route Distinguisher
- RP Rendez-vous Point
+ RP Rendezvous Point
RT Route Target
SA Security Association
SSM Source-Specific Multicast
VPN Virtual Private Network
VRF Virtual Routing and Forwarding
4. L3NM Reference Architecture
Figure 1 depicts the reference architecture for the L3NM. The figure
is an expansion of the architecture presented in Section 5 of
@@ -353,28 +363,29 @@
| | |
+------------------------------------------------+
Network
Figure 1: L3NM Reference Architecture
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) [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].
+ 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) [RFC8453].
- Figure 2 shows the Customer Network Controller (CNC), the Multi-
- Domain Service Coordinator (MDSC), and the Provisioning Network
+ 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 | |
| +-----------------------------+ |
+----+-----------------------+-----+
| |
@@ -581,82 +592,90 @@
...
+--rw vpn-nodes
+--rw vpn-node* [vpn-node-id]
...
+--rw vpn-network-accesses
+--rw vpn-network-access* [id]
...
Figure 3: Overall L3NM Tree Structure
+ 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).
+
7.2. VPN Profiles
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
+ ...
+
+ Figure 4: VPN Profiles Subtree Structure
+
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 ease identifying and binding local
+ 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). An external connectivity may
be an access to the Internet or a 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 as set of policies such as classification, marking, and actions
+ to a set of policies such as classification, marking, and actions
(e.g., [RFC3644]).
'bfd-profile-identifier': A Bidirectional Forwarding Detection (BFD)
profile refers to a set of BFD [RFC5880] policies 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.
- +--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
- ...
-
- Figure 4: VPN Profiles Subtree Structure
-
7.3. VPN Services
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
@@ -762,21 +781,21 @@
'external-connectivity': 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 event a dedicated node that hosts the NAT function).
+ 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': 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
@@ -902,24 +921,24 @@
assignment, auto-assignment from a pool, and full auto-assignment.
'address-family': Includes a set of per-address family data nodes:
'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 [RFC4364]).
- 'maximum-routes': Indicates the maximum 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.
+ '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.
7.5. VPN 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
@@ -1002,44 +1021,47 @@
'router-id': Indicates a 32-bit number that is used to uniquely
identify a router within an Autonomous System.
'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 one discussed in
- Section 7.4 except 'router-id'. Indeed, 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.
+ 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.
'msdp': For redundancy purposes, Multicast Source Discovery Protocol
(MSDP) [RFC3618] may be enabled and used to share the state about
- sources between multiple rendez-vous points (RPs). The purpose of
+ 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, which 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 to
+
[I-D.ietf-opsawg-vpn-common]. The 'group-id' is used to
associate, e.g., redundancy or protection constraints with VPN
nodes.
'status': Tracks the status of a node involved in a VPN service.
-
Both operational 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 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
@@ -1043,21 +1065,21 @@
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.
-7.6. VPN Network Access
+7.6. VPN Network Accesses
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
@@ -1122,22 +1144,23 @@
access'.
'loopback': Represents the creation of a logical interface on a
device. An example to illustrate 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 refined at the VPN network access level.
- In such case, refined values take precedence over inherited ones.
+ (e.g., multicast) can be overridden at the VPN network access
+ level. In such case, adjusted values take precedence over
+ inherited ones.
'status': Indicates both operational 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 of a VPN
network access (e.g., IP addressing). See Section 7.6.2.
@@ -1173,34 +1196,34 @@
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 5.2 of [RFC4447]).
+ (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 connections with the site. In
+ 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.
...
+--rw connection
| +--rw encapsulation
| | +--rw type? identityref
@@ -1295,21 +1318,21 @@
| | | | 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?
+ | | | +--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)
| | ...
...
@@ -1327,45 +1350,47 @@
...
+--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 dhcp-service-type?
+ | | | enumeration
| | +--rw (service-type)?
- | | +--:(provider-dhcp-servers)
+ | | +--:(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?
+ | | +--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
+ | | +--rw server-ip-address*
+ | | inet:ipv6-address
| +--:(static-addresses)
| ...
- ...
Figure 12: IP Connection Subtree Structure (IPv6)
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'.
...
@@ -1432,69 +1457,60 @@
Figure 14: Routing Subtree Structure
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 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:
+ 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:
* 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').
+ 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]. 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., "myfavourite-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, an interface, 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.
+ abandoned to ease the mapping with the structure in [RFC8299].
- 'preference': Indicates the preference associated with the static
- route entry. This preference is used to selecting a preferred
- route among routes to the same destination prefix.
+7.6.3.1. Static Routing
- '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 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}?
@@ -1524,126 +1540,51 @@
| | +--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 15: Static Routing Subtree Structure
- In addition, the L3NM supports the following CE-PE routing protocols:
-
- BGP: 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.
-
- This 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 Figure 16. It is up to
- the implementation 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 one 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) defined in Section 4.3.4 of
- [RFC4364]).
-
- '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 'address-family' attribute is set
- to dual-stack). A list of IP address(es) of the BGP neighbors
- can be then 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., replace the ASN of the customer
- specified in the AS_PATH BGP attribute with the ASN identified
- in the 'local-as' attribute.
-
- 'allow-own-as': Is 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 provider's ASN
- occurrences. This parameter is set by default to '0' (that is,
- reject any AS_PATH attribute that includes the provider's ASN).
-
- 'prepend-global-as': When distinct ASNs are configured in 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': 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 (Section 7 of [RFC4364]). 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 [RFC5701]. It is used to prevent routing
- loops.
+ As depicted in Figure 15, the following data nodes can be defined for
+ a given IP prefix:
- 'redistribute-connected': Controls whether the PE-CE link is
- advertised to other PEs.
+ 'lan-tag': Indicates a local tag (e.g., "myfavourite-lan") that is
+ used to enforce local policies.
- 'bgp-max-prefix': Controls the behavior when a prefix maximum is
- reached.
+ 'next-hop': Indicates the next-hop to be used for the static route.
+ It can be identified by an IP address, an interface, etc.
- 'max-prefix': Indicates the maximum number of BGP prefixes
- allowed in the BGP session. If the limit is reached, the
- action indicated in 'action-violate' will be followed.
+ 'bfd-enable': Indicates whether BFD is enabled or disabled for this
+ static route entry.
- 'warning-threshold': A warning notification is triggered when
- this limit is reached.
+ 'metric': Indicates the metric associated with the static route
+ entry.
- 'violate-action': Indicates which action to execute when the
- maximum number of BGP prefixes is reached. Examples of such
- actions are: send a warning message, discard extra paths
- from the peer, or restart the session.
+ 'preference': Indicates the preference associated with the static
+ route entry. This preference is used to selecting a preferred
+ route among routes to the same destination prefix.
- 'bgp-timers': Two timers can be captured in this container: (1)
- 'hold-time' which is the time interval that will be used for
- the HoldTimer (Section 4.2 of [RFC4271]) when establishing a
- BGP session. (2) 'keepalive' which is the time interval for
- the KeepAlive timer between a PE and a BGP peer (Section 4.4 of
- [RFC4271]).
+ '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.
- 'authentication': 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.
+7.6.3.2. BGP
- 'status': Indicates the status of the BGP routing instance.
+ 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
@@ -1664,133 +1605,219 @@
| | | +--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)?
- | | | +--:(tcp-ao)
- | | | | +--rw enable-tcp-ao? boolean
+ | | | +--:(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: BGP Routing Subtree Structure
- OSPF: OSPF can be configured to run as a routing protocol on the
- 'vpn-network-access'. The following data nodes are captured in
- Figure 17:
+ Figure 16. It is up to the implementation (e.g., network
+ orchestrator) to derive the corresponding BGP device configuration:
- 'address-family': Indicates whether IPv4, IPv6, or both address
- families are to be activated.
+ 'description': Includes a description of the BGP session.
- When the IPv4 or dual-stack address-family is requested, it is
- up to the implementation 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.
+ 'local-as': Indicates a local AS Number (ASN) if a distinct ASN is
+ required, other than the one configured at the VPN node level.
- 'area-id': Indicates the OSPF Area ID.
+ 'peer-as': Conveys the customer's ASN.
- 'metric': Associates a metric with OSPF routes.
+ 'address-family': Indicates the address-family of the peer. It can
+ be set to IPv4, IPv6, or dual-stack.
- 'sham-links': Is 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 [RFC4577] and Section 5 of [RFC6565]).
+ 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]).
- 'max-lsa': Sets the maximum number of LSAs that the OSPF instance
- will accept.
+ 'local-address': Specifies an address or a reference to an interface
+ to use when establishing the BGP transport session.
- 'authentication': Controls the authentication schemes to be
- enabled for the OSPF instance. The following options are
- supported: IPsec for OSPFv3 authentication [RFC4552],
- authentication trailer for OSPFv2 [RFC5709] [RFC7474] and
- OSPFv3 [RFC7166].
+ 'neighbor': Can indicate two neighbors (each for a given address-
+ family) or one neighbor (if 'address-family' attribute is set to
+ dual-stack). A list of IP address(es) of the BGP neighbors can be
+ then conveyed in this data node.
- 'status': Indicates the status of the OSPF routing instance.
+ '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., replace the ASN of the customer specified in the
+ AS_PATH BGP attribute with the ASN identified in the 'local-as'
+ attribute.
+
+ 'allow-own-as': Is 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 provider's ASN occurrences.
+ This parameter is set by default to '0' (that is, reject any
+ AS_PATH attribute that includes the provider's ASN).
+
+ 'prepend-global-as': When distinct ASNs are configured in 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': 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 (Section 7 of [RFC4364]). 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 [RFC5701]. 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 are: send a warning message, discard extra paths from
+ the peer, or restart the session.
+
+ 'bgp-timers': Two timers can be captured in this container: (1)
+ 'hold-time' which is the time interval that will be used for the
+ HoldTimer (Section 4.2 of [RFC4271]) when establishing a BGP
+ session. (2) 'keepalive' which is the time interval for the
+ KeepAlive timer between a PE and a BGP peer (Section 4.4 of
+ [RFC4271]).
+
+ 'authentication': 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]).
+
+ 'status': Indicates the status of the BGP routing instance.
+
+7.6.3.3. OSPF
+
+ 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)?
- | | | +--:(md5)
- | | | | +--rw md5-keychain?
- | | | | kc:key-chain-ref
+ | | | +--:(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
...
Figure 17: OPSF Routing Subtree Structure
- IS-IS: The model (Figure 18) allows the user to configure IS-IS
- [ISO10589][RFC1195][RFC5308] to run on the 'vpn-network-access'
- interface. The following IS-IS data nodes are supported:
+ The following data nodes are captured in Figure 17:
'address-family': Indicates whether IPv4, IPv6, or both address
families are to be activated.
- 'area-address': Indicates the IS-IS area address.
+ 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.
- 'level': Indicates the IS-IS level: Level 1, Level 2, or both.
+ 'area-id': Indicates the OSPF Area ID.
- 'metric': Associates a metric with IS-IS routes.
+ 'metric': Associates a metric with OSPF 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).
+ 'sham-links': Is 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 [RFC4577] and Section 5 of [RFC6565]).
- 'authentication': Controls the authentication schemes to be
- enabled for the IS-IS instance. Both the specification of a
- key-chain [RFC8177] and the direct specification of key and
- authentication algorithm are supported.
+ 'max-lsa': Sets the maximum number of 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 [RFC4552], authentication trailer for
+ OSPFv2 [RFC5709] [RFC7474] and OSPFv3 [RFC7166].
'status': Indicates the status of the OSPF routing instance.
+7.6.3.4. IS-IS
+
+ 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
@@ -1809,49 +1836,47 @@
| | +--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 18: IS-IS Routing Subtree Structure
- RIP: The model allows the user to configure RIP to run on the 'vpn-
- network-access' interface. As shown in Figure 19, the following
- RIP data nodes are supported:
+ The following IS-IS 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 [RFC2453] and/or RIPng are to be
- enabled [RFC2080].
+ families are to be activated.
- 'timers': Indicates the following timers:
+ 'area-address': Indicates the IS-IS area address.
- 'update-interval': Is the interval at which RIP updates are
- sent.
+ 'level': Indicates the IS-IS level: Level 1, Level 2, or both.
- 'invalid-interval': Is the interval before a RIP route is
- declared invalid.
+ 'metric': Associates a metric with IS-IS routes.
- 'holddown-interval': Is the interval before better RIP routes
- are released.
+ '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).
- 'flush-interval': Is the interval before a route is removed
- from the routing table.
+ 'authentication': Controls the authentication schemes to be enabled
+ for the IS-IS instance. Both the specification of a key-chain
+ [RFC8177] and the direct specification of key and authentication
+ algorithm are supported.
- 'default-metric': Sets the default RIP metric.
+ 'status': Indicates the status of the OSPF routing instance.
- 'authentication': Controls the authentication schemes to be
- enabled for the RIP instance.
+7.6.3.5. RIP
- 'status': Indicates the status of the RIP routing instance.
+ 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
@@ -1873,45 +1898,50 @@
| | +--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: RIP Subtree Structure
- VRRP: The model (Figure 20) allows enabling VRRP on the 'vpn-
- network-access' interface. The following data nodes are
- supported:
+ Figure 19, the following RIP data nodes are supported:
'address-family': Indicates whether IPv4, IPv6, or both address
- families are to be activated. Note that VRRP version 3
- [RFC5798] supports both IPv4 and IPv6.
+ families are to be activated. This parameter is used to determine
+ whether RIPv2 [RFC2453] and/or RIPng are to be enabled [RFC2080].
- 'vrrp-group': Is used to identify the VRRP group.
+ 'timers': Indicates the following timers:
- 'backup-peer': Carries the IP address of the peer.
+ 'update-interval': Is the interval at which RIP updates are sent.
- 'virtual-ip-address': Includes virtual IP addresses for a single
- VRRP group.
+ 'invalid-interval': Is the interval before a RIP route is
+ declared invalid.
- 'priority': Assigns the VRRP election priority for the backup
- virtual router.
+ 'holddown-interval': Is the interval before better RIP routes are
+ released.
- 'ping-reply': Controls whether ping requests can be replied to.
+ 'flush-interval': Is the interval before a route is removed from
+ the routing table.
- 'status': Indicates the status of the VRRP instance.
+ 'default-metric': Sets the default RIP metric.
- 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]).
+ 'authentication': Controls the authentication schemes to be enabled
+ for the RIP instance.
+
+ 'status': Indicates the status of the RIP routing instance.
+
+7.6.3.6. VRRP
+
+ 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
@@ -1921,26 +1951,72 @@
| +--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 20: VRRP Subtree Structure
+ 'address-family': Indicates whether IPv4, IPv6, or both address
+ families are to be activated. Note that VRRP version 3 [RFC5798]
+ supports both IPv4 and IPv6.
+
+ 'vrrp-group': Is 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 ping requests can be replied to.
+
+ 'status': Indicates the status of the VRRP instance.
+
+ 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]).
+
7.6.4. OAM
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. The current
- data nodes can be specified:
+ 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
+ ...
+
+ Figure 21: IP Connection Subtree Structure (OAM)
+
+ The following OAM data nodes can be specified:
'session-type': Indicates which BFD flavor is used to setup the
session (e.g., classic BFD [RFC5880], Seamless BFD [RFC7880]). By
default, the BFD session is assumed to follow the behavior
specified in [RFC5880].
'desired-min-tx-interval': Is the minimum interval, in microseconds,
that a PE would like to use when transmitting BFD Control packets
less any jitter applied.
@@ -1960,43 +2036,20 @@
(see Section 6.3.2.2.2 of [RFC8299]).
'authentication': Includes the required information to enable the
BFD authentication modes discussed in Section 6.7 of [RFC5880].
In particular 'meticulous' controls the activation of the
meticulous mode discussed in Sections 6.7.3 and 6.7.4 of
[RFC5880].
'status': Indicates the status of BFD.
- ...
- +--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
- ...
-
- Figure 21: IP Connection Subtree Structure (OAM)
-
7.6.5. Security
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
@@ -2019,20 +2072,22 @@
| +--:(customer-profile)
| +--rw customer-key-chain?
| kc:key-chain-ref
+--rw service
...
Figure 22: Security Subtree Structure
7.6.6. Services
+7.6.6.1. Overview
+
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}?
@@ -2064,22 +2119,38 @@
connection (i.e., download bandwidth from the service provider to
the site).
'outbound-bandwidth': Indicates the outbound bandwidth of the
connection (i.e., upload bandwidth from the site to the service
provider).
'mtu': Indicates the MTU at the service level.
'qos': 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
+ 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 the use of BGP for
+ signaling purposes [RFC8277].
+
+ 'ntp': Time synchronization may be needed in some VPNs such as
+ infrastructure and management VPNs. This container is used to
+ enable the NTP service [RFC5905].
+
+ 'multicast': Specifies the multicast mode and other data nodes such
+ as the address-family. Refer to Section 7.7.
+
+7.6.6.2. QoS
+
+ '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)?
@@ -2106,23 +2177,23 @@
| +--rw qos-profile
| +--rw qos-profile* [profile]
| +--rw profile leafref
| +--rw direction? identityref
...
Figure 24: Services Subtree Structure
QoS classification can be based on many criteria such as:
- 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.
+ 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
@@ -2157,30 +2228,39 @@
| | | | | +--rw (source-network)?
| | | | | | +--:(source-ipv6-network)
| | | | | | +--rw source-ipv6-network?
| | | | | | inet:ipv6-prefix
| | | | | +--rw flow-label?
| | | | | inet:ipv6-flow-label
...
Figure 25: QoS Subtree Structure (L3)
- Layer 4: 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.
+ Layer 4: 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.
+ 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)?
@@ -2246,33 +2326,21 @@
| | | | | +--rw upper-port
| | | | | inet:port-number
| | | | +--:(operator)
| | | | +--rw operator? operator
| | | | +--rw port
| | | | inet:port-number
...
Figure 26: QoS Subtree Structure (L4)
- Application match: Relies upon application-specific
- classification.
-
- 'carrierscarrier': Groups a set of parameters that are used when
- Carriers' Carriers (CsC) is enabled such the use of BGP for
- signaling purposes [RFC8277].
-
- 'ntp': Time synchronization may be needed in some VPNs such as
- infrastructure and management VPNs. This container is used to
- enable the NTP service [RFC5905].
-
- 'multicast': Specifies the multicast mode and other data nodes such
- as the address-family. Refer to Section 7.7.
+ Application match: Relies upon application-specific classification.
7.7. Multicast
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
@@ -2305,21 +2373,21 @@
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 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
@@ -2356,50 +2424,50 @@
| | +--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
...
Figure 28: Multicast Subtree Structure (VPN Instance Profile Level)
- The model supports a single type of tree: Any-Source Multicast (ASM),
- Source-Specific Multicast (SSM), or bidirectional.
+ 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 rendez-vous
- points (RPs). RP discovery may be 'static', 'bsr-rp', or 'auto-rp'.
- When set to 'static', RP to multicast grouping mapping MUST be
+ 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
- otherwise no RP address is needed.
+ 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 and is up to the
- implementation.
+ How the redundancy is achieved is out of scope.
When a particular VPN using ASM requires a more optimal traffic
- delivery, '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.
+ 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
- refined at the VPN network access level.
+ 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
@@ -2515,21 +2583,21 @@
}
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:
+ "WG Web:
WG List:
Author: Samier Barguil
Editor: Oscar Gonzalez de Dios
Editor: Mohamed Boucadair
Author: Luis Angel Munoz
@@ -2681,22 +2749,22 @@
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 called at the VPN node and VPN network
- access levels.";
+ 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";
@@ -2733,26 +2801,26 @@
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-list tree-flavor {
+ leaf tree-flavor {
type identityref {
base vpn-common:multicast-tree-type;
}
description
- "Type of tree to be used.";
+ "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
@@ -2788,21 +2856,21 @@
"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
- and delivery through optimal path are
+ 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.";
@@ -2902,37 +2970,37 @@
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 addresss.";
+ "Multicast group IPv4 address.";
}
leaf source-addr {
type rt-types:ipv4-multicast-source-address;
description
- "Multicast source IPv4 addresss.";
+ "Multicast source IPv4 address.";
}
}
leaf max-groups {
type uint32;
description
- "Indicates the maximum groups.";
+ "Indicates the maximum number of groups.";
}
leaf max-entries {
type uint32;
description
- "Indicates the maximum IGMP entries.";
+ "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
@@ -2945,26 +3013,26 @@
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 addresss.";
+ "Multicast group IPv6 address.";
}
leaf source-addr {
type rt-types:ipv6-multicast-source-address;
description
- "Multicast source IPv6 addresss.";
+ "Multicast source IPv6 address.";
}
}
leaf max-groups {
type uint32;
description
"Indicates the maximum number of groups.";
}
leaf max-entries {
type uint32;
description
@@ -3260,21 +3328,21 @@
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
- "Tagged interface type. By default, the type of
+ "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";
@@ -3352,109 +3420,129 @@
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 defined, if needed.";
+ 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 4447: Pseudowire Setup and Maintenance
- Using the Label Distribution Protocol
- (LDP), Section 5.2";
+ "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'.";
+ "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)
+ "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.";
+ 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 {
@@ -3473,42 +3561,45 @@
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.";
+ "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.";
+ 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 {
@@ -3718,21 +3807,21 @@
"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 provider-dhcp-servers {
+ 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";
@@ -4274,28 +4362,28 @@
}
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 tcp-ao {
+ case ao {
description
"Uses TCP-Authentication Option
(TCP-AO).";
reference
"RFC 5925: The TCP Authentication
Option.";
- leaf enable-tcp-ao {
+ 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.";
@@ -4313,27 +4402,27 @@
description
"Reference to the MD5 key chain.";
reference
"RFC 8177: YANG Key Chain";
}
}
case explicit {
leaf key-id {
type uint32;
description
- "Key Identifier";
-
+ "Key Identifier.";
}
leaf key {
type string;
description
- "BGP authentication key.";
+ "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.";
}
}
@@ -4467,21 +4559,22 @@
}
case auth-key-explicit {
leaf key-id {
type uint32;
description
"Key identifier.";
}
leaf key {
type string;
description
- "OSPF authentication key.";
+ "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.";
}
}
@@ -4584,21 +4679,22 @@
}
case auth-key-explicit {
leaf key-id {
type uint32;
description
"Key Identifier.";
}
leaf key {
type string;
description
- "IS-IS authentication key.";
+ "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.";
}
}
@@ -4710,21 +4805,22 @@
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.";
+ "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.";
}
}
@@ -4762,37 +4858,40 @@
"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. ";
+ "Virtual IP addresses for a single VRRP
+ group.";
reference
- "RFC 5798: Virtual Router Redundancy Protocol (VRRP)
- Version 3 for IPv4 and IPv6, Sections
- 1.2 and 1.3";
+ "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
@@ -4813,24 +4912,26 @@
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.";
+ 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";
@@ -4917,21 +5017,21 @@
type boolean;
default "false";
description
"If true, traffic encryption on the
connection is required. Otherwise, it
is disabled.";
}
leaf layer {
when "../enabled = 'true'" {
description
- "Indicates the layer on which encryption
+ "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.
@@ -4992,21 +5091,21 @@
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 oubtound bandwidth of the
+ 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,
@@ -5234,55 +5331,59 @@
}
default "both";
description
"Multicast protocol type to be used with
the customer site.";
}
leaf remote-source {
type boolean;
default "false";
description
- "When true, there is no PIM adjacency on
- the interface.";
+ "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
- to IGMP session";
+ IGMP session";
leaf group-addr {
type rt-types:ipv4-multicast-group-address;
description
- "Multicast group IPv4 addresss.";
+ "Multicast group IPv4 address.";
}
leaf source-addr {
type rt-types:ipv4-multicast-source-address;
description
- "Multicast source IPv4 addresss.";
+ "Multicast source IPv4 address.";
}
}
leaf max-groups {
type uint32;
description
- "Indicates the maximum groups.";
+ "Indicates the maximum number of groups.";
}
leaf max-entries {
type uint32;
description
- "Indicates the maximum IGMP entries.";
+ "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;
}
@@ -5301,37 +5401,38 @@
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 addresss.";
+ "Multicast group IPv6 address.";
}
leaf source-addr {
type rt-types:ipv6-multicast-source-address;
description
- "Multicast source IPv6 addresss.";
+ "Multicast source IPv6 address.";
}
}
leaf max-groups {
type uint32;
description
- "Indicates the maximum groups.";
+ "Indicates the maximum number of groups.";
}
leaf max-entries {
type uint32;
description
- "Indicates the maximum MLD entries.";
+ "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;
}
@@ -5404,22 +5505,29 @@
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:
- * 'vpn-service': An attacker who is able to access network nodes can
- undertake various attacks, such as deleting a running L3VPN
+ * 'vpn-profiles': This container includes a set of sensitive data
+ that influence how the L3VPN service is delivered. For example,
+ an attacker who has access to these data nodes may be able to
+ manipulate routing policies, QoS policies, or encryption
+ properties. These data nodes are defined with "nacm:default-deny-
+ write" tagging [I-D.ietf-opsawg-vpn-common].
+
+ * ''vpn-services': An attacker who is able to access network nodes
+ can undertake various attacks, such as deleting a running L3VPN
service, interrupting all the traffic of a client. In addition,
an attacker may modify the attributes of a running service (e.g.,
QoS, bandwidth, routing protocols), leading to malfunctioning of
the service and therefore to SLA violations. In addition, an
attacker could attempt to create an L3VPN service or adding a new
network access. In addition to using NACM to prevent authorized
access, such activity can be detected by adequately monitoring and
tracking network configuration changes.
Some readable data nodes in this YANG module may be considered
@@ -5429,27 +5537,36 @@
nodes and their sensitivity/vulnerability:
* 'customer-name' and 'ip-connection': An attacker can retrieve
privacy-related information which can be used to track a customer.
Disclosing such information may be considered as a violation of
the customer-provider trust relationship.
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].
+ [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].
+
10. IANA Considerations
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
@@ -5462,23 +5579,23 @@
prefix: l3nm
reference: RFC XXXX
11. References
11.1. Normative References
[I-D.ietf-opsawg-vpn-common]
Barguil, S., Dios, O. G. D., Boucadair, M., and Q. Wu, "A
Layer 2/3 VPN Common YANG Model", Work in Progress,
- Internet-Draft, draft-ietf-opsawg-vpn-common-09, 15 July
- 2021, .
+ Internet-Draft, draft-ietf-opsawg-vpn-common-11, 23
+ September 2021, .
[ISO10589] ISO, "Intermediate System to Intermediate System intra-
domain routeing information exchange protocol for use in
conjunction with the protocol for providing the
connectionless-mode network service (ISO 8473)", 2002,
.
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5,
RFC 1112, DOI 10.17487/RFC1112, August 1989,
.
@@ -5751,26 +5868,20 @@
Provider-Provisioned Virtual Private Networks (PPVPNs)",
RFC 4110, DOI 10.17487/RFC4110, July 2005,
.
[RFC4176] El Mghazli, Y., Ed., Nadeau, T., Boucadair, M., Chan, K.,
and A. Gonguet, "Framework for Layer 3 Virtual Private
Networks (L3VPN) Operations and Management", RFC 4176,
DOI 10.17487/RFC4176, October 2005,
.
- [RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and
- G. Heron, "Pseudowire Setup and Maintenance Using the
- Label Distribution Protocol (LDP)", RFC 4447,
- DOI 10.17487/RFC4447, April 2006,
- .
-
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862,
DOI 10.17487/RFC4862, September 2007,
.
[RFC6037] Rosen, E., Ed., Cai, Y., Ed., and IJ. Wijnands, "Cisco
Systems' Solution for Multicast in BGP/MPLS IP VPNs",
RFC 6037, DOI 10.17487/RFC6037, October 2010,
.
@@ -5804,20 +5915,25 @@
[RFC7880] Pignataro, C., Ward, D., Akiya, N., Bhatia, M., and S.
Pallagatti, "Seamless Bidirectional Forwarding Detection
(S-BFD)", RFC 7880, DOI 10.17487/RFC7880, July 2016,
.
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205,
RFC 7942, DOI 10.17487/RFC7942, July 2016,
.
+ [RFC8077] Martini, L., Ed. and G. Heron, Ed., "Pseudowire Setup and
+ Maintenance Using the Label Distribution Protocol (LDP)",
+ STD 84, RFC 8077, DOI 10.17487/RFC8077, February 2017,
+ .
+
[RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address
Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017,
.
[RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki,
"YANG Data Model for L3VPN Service Delivery", RFC 8299,
DOI 10.17487/RFC8299, January 2018,
.
[RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models
@@ -5847,20 +5963,35 @@
Abstraction and Control of TE Networks (ACTN)", RFC 8453,
DOI 10.17487/RFC8453, August 2018,
.
[RFC8512] Boucadair, M., Ed., Sivakumar, S., Jacquenet, C.,
Vinapamula, S., and Q. Wu, "A YANG Module for Network
Address Translation (NAT) and Network Prefix Translation
(NPT)", RFC 8512, DOI 10.17487/RFC8512, January 2019,
.
+ [RFC8633] Reilly, D., Stenn, H., and D. Sibold, "Network Time
+ Protocol Best Current Practices", BCP 223, RFC 8633,
+ DOI 10.17487/RFC8633, July 2019,
+ .
+
+ [RFC8695] Liu, X., Sarda, P., and V. Choudhary, "A YANG Data Model
+ for the Routing Information Protocol (RIP)", RFC 8695,
+ DOI 10.17487/RFC8695, February 2020,
+ .
+
+ [RFC8915] Franke, D., Sibold, D., Teichel, K., Dansarie, M., and R.
+ Sundblad, "Network Time Security for the Network Time
+ Protocol", RFC 8915, DOI 10.17487/RFC8915, September 2020,
+ .
+
[RFC8969] Wu, Q., Ed., Boucadair, M., Ed., Lopez, D., Xie, C., and
L. Geng, "A Framework for Automating Service and Network
Management with YANG", RFC 8969, DOI 10.17487/RFC8969,
January 2021, .
Appendix A. L3VPN Examples
A.1. 4G VPN Provisioning Example
L3VPNs are widely used to deploy 3G/4G, fixed, and enterprise
@@ -6489,20 +6620,23 @@
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).
Contributors
Victor Lopez
Telefonica
Email: victor.lopezalvarez@telefonica.com