draft-ietf-opsawg-l3sm-l3nm-01.txt   draft-ietf-opsawg-l3sm-l3nm-02.txt 
OPSAWG A. Aguado OPSAWG S. Barguil
Internet-Draft Nokia Internet-Draft O. Gonzalez de Dios, Ed.
Intended status: Standards Track O. Gonzalez de Dios, Ed. Intended status: Standards Track Telefonica
Expires: May 20, 2020 V. Lopez Expires: September 10, 2020 M. Boucadair
Telefonica Orange
D. Voyer
Bell Canada
L. Munoz L. Munoz
Vodafone Vodafone
November 17, 2019 A. Aguado
Nokia
March 09, 2020
A Layer 3 VPN Network YANG Model A Layer 3 VPN Network YANG Model
draft-ietf-opsawg-l3sm-l3nm-01 draft-ietf-opsawg-l3sm-l3nm-02
Abstract Abstract
RFC8299 defines a L3VPN Service YANG data Model (L3SM) that can be This document defines a L3 VPN Network YANG Data model, called L3NM
used for communication between customers and VPN service providers. that can be used to manage the provisioning of Layer 3 VPN services
That data model plays the role of a Customer Service Model, according within a Service Provider Network. The module is meant to be used by
to the terminology defined in RFC8309, and is as such adequate for a Network Controller to derive the configuration information that
service negotiation and order handling matters. will be sent to relevant network devices.
There is a need for a more network-centric YANG data model to be used The L3VPN Network YANG Model (L3NM) can also facilitates the
in the communication between the entity that interacts directly with communication between a service orchestrator and a network
the customer, the service orchestrator, (either fully automated or a controller/orchestrator. The model provides a network-centric view
human operator) and the entity in charge of network orchestration and of the L3VPN services.
control (a.k.a., network controller/orchestrator).
This document specifies a L3VPN Network YANG Model (L3NM) to The L3NM YANG module is aimed at managing BGP PE-based Layer 3 VPNs
facilitate communication between a service orchestrator and a network as described in RFCs 4026, 4110 and 4364 and Multicast VPNs as
controller/orchestrator. Such data model provides a network-centric described in RFCs 6037, 6513 and 7988.
view of the L3VPN services. The Yang model proposed is limited to
BGP PE-based VPNs as described in RFCs 4026, 4110, and 4364.
Editorial Note (To be removed by RFC Editor) Editorial Note (To be removed by RFC Editor)
Please update these statements within the document with the RFC Please update these statements within the document with the RFC
number to be assigned to this document: number to be assigned to this document:
o "This version of this YANG module is part of RFC XXXX;" o "This version of this YANG module is part of RFC XXXX;"
o "RFC XXXX: Layer 3 VPN Network Model"; o "RFC XXXX: Layer 3 VPN Network Model";
skipping to change at page 2, line 20 skipping to change at page 2, line 20
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 20, 2020. This Internet-Draft will expire on September 10, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Reference Architecture . . . . . . . . . . . . . . . . . . . 6 4. Reference Architecture . . . . . . . . . . . . . . . . . . . 6
3. Description of the L3NM YANG Module . . . . . . . . . . . . . 8 5. Relation with other YANG Models . . . . . . . . . . . . . . . 8
3.1. Structure of the Module . . . . . . . . . . . . . . . . . 9 6. Description of the L3NM YANG Module . . . . . . . . . . . . . 10
3.2. Modeling a L3 VPN Service . . . . . . . . . . . . . . . . 9 6.1. Overall Structure of the Module . . . . . . . . . . . . . 10
3.2.1. VPN node . . . . . . . . . . . . . . . . . . . . . . 10 6.2. VPN Profiles . . . . . . . . . . . . . . . . . . . . . . 10
3.2.1.1. VPN Network Access . . . . . . . . . . . . . . . 11 6.3. Modeling a Layer 3 VPN Service . . . . . . . . . . . . . 11
3.2.1.1.1. Connection . . . . . . . . . . . . . . . . . 11 6.3.1. Service Status . . . . . . . . . . . . . . . . . . . 12
3.2.1.1.2. IP Connection . . . . . . . . . . . . . . . . 13 6.3.2. VPN Node . . . . . . . . . . . . . . . . . . . . . . 13
3.2.1.1.3. Routing Protocols . . . . . . . . . . . . . . 14 6.3.2.1. Node Status . . . . . . . . . . . . . . . . . . . 15
3.2.2. Concept of Import/Export Profiles . . . . . . . . . . 15 6.3.2.2. VPN Network Access . . . . . . . . . . . . . . . 15
3.2.3. Multicast . . . . . . . . . . . . . . . . . . . . . . 16 6.3.2.2.1. Connection . . . . . . . . . . . . . . . . . 17
6.3.2.2.2. IP Connections . . . . . . . . . . . . . . . 20
3.3. VPN profiles . . . . . . . . . . . . . . . . . . . . . . 16 6.3.2.2.3. CE PE Routing Protocols . . . . . . . . . . . 22
3.4. Model tree . . . . . . . . . . . . . . . . . . . . . . . 17 6.3.2.3. Multicast . . . . . . . . . . . . . . . . . . . . 26
4. Use of the Data Model . . . . . . . . . . . . . . . . . . . . 23 6.3.3. Concept of Import/Export Profiles . . . . . . . . . . 28
4.1. Multi-Domain Resource Management . . . . . . . . . . . . 23 6.3.4. Underlay Transport . . . . . . . . . . . . . . . . . 28
5. Relation with other Yang Models . . . . . . . . . . . . . . . 23 7. L3NM Module Tree Structure . . . . . . . . . . . . . . . . . 28
5.1. Relation with L3SM . . . . . . . . . . . . . . . . . . . 23 8. Sample Uses of the L3NM Data Model . . . . . . . . . . . . . 39
5.2. Relation with Network Topology . . . . . . . . . . . . . 24 8.1. Enterprise L3 VPN Services . . . . . . . . . . . . . . . 39
5.3. Relation with Device Models . . . . . . . . . . . . . . . 24 8.2. Multi-Domain Resource Management . . . . . . . . . . . . 39
6. L3VPN Examples . . . . . . . . . . . . . . . . . . . . . . . 24 8.3. Management of Multicast services . . . . . . . . . . . . 39
6.1. 4G VPN Provissioning Example . . . . . . . . . . . . . . 24 9. L3VPN Examples . . . . . . . . . . . . . . . . . . . . . . . 40
7. Yang Module . . . . . . . . . . . . . . . . . . . . . . . . . 26 9.1. 4G VPN Provissioning Example . . . . . . . . . . . . . . 40
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 89 9.2. Multicast VPN Provisioning Example . . . . . . . . . . . 44
9. Security Considerations . . . . . . . . . . . . . . . . . . . 90 10. L3NM YANG Module . . . . . . . . . . . . . . . . . . . . . . 46
10. Implementation Status . . . . . . . . . . . . . . . . . . . . 91 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 108
10.1. Nokia Implementation . . . . . . . . . . . . . . . . . . 91 12. Security Considerations . . . . . . . . . . . . . . . . . . . 109
10.2. Huawei Implementation . . . . . . . . . . . . . . . . . 92 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 110
10.3. Infinera Implementation . . . . . . . . . . . . . . . . 96 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 110
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 96 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 111
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 96 15.1. Normative References . . . . . . . . . . . . . . . . . . 111
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 97 15.2. Informative References . . . . . . . . . . . . . . . . . 112
13.1. Normative References . . . . . . . . . . . . . . . . . . 97 Appendix A. Implementation Status . . . . . . . . . . . . . . . 113
13.2. Informative References . . . . . . . . . . . . . . . . . 98 A.1. Nokia Implementation . . . . . . . . . . . . . . . . . . 113
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 99 A.2. Huawei Implementation . . . . . . . . . . . . . . . . . . 114
A.3. Infinera Implementation . . . . . . . . . . . . . . . . . 118
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 118
1. Introduction 1. Introduction
[RFC8299] defines an L3VPN Service YANG data Model (L3SM) that can be [RFC8299] defines an L3VPN Service YANG data Model (L3SM) that can be
used for communication between customers and network operators. Such used for communication between customers and network operators. Such
model is focused on describing the customer view of the VPN services, model is focused on describing the customer view of the VPN services,
and provides an abstracted view of the customer's requested services. and provides an abstracted view of the customer's requested services.
That aproach limits the usage of the L3SM module to the role of a That approach limits the usage of the L3SM module to the role of a
Customer Service Model, according to the terminology defined in Customer Service Model, according to the terminology defined in
[RFC8309]. [RFC8309].
The YANG data model defined in this document is called L3VPN Network The YANG data model defined in this document is called L3VPN Network
Model (L3NM). The L3NM module is aimed at providing a network- Model (L3NM). The L3NM module is aimed at providing a network-
centric view of L3 VPN Services. The data model can be used to centric view of L3 VPN Services. The data model can be used to
facilitate communication between the service orchestrator (or a facilitate communication between the service orchestrator (or a
network operator) and the network controller/orchestrator by allowing network operator) and the network controller/orchestrator by allowing
for more network-centric information to be included. It enables for more network-centric information to be included. It enables
further capabilities, such as resource management or to serve as a further capabilities, such as resource management or to serve as a
multi-domain orchestration interface, where logical resources (such multi-domain orchestration interface, where logical resources (such
as route targets or route distinguishers) must be synchronized. as route targets or route distinguishers) must be synchronized.
This document does not obsolete, but uses, the definitions in This document does not obsolete, but uses, the definitions in
[RFC8299]. These two modules are used for similar objectives but [RFC8299]. These two modules are used for similar objectives but
with differents scopes and views. with different scopes and views.
The L3NM YANG module is initially built with a prune and extend The L3NM YANG module is initially built with a prune and extend
approach, taking as a starting points the YANG module described in approach, taking as a starting points the YANG module described in
[RFC8299]. Nevertheless, this module is not defined as an augment to [RFC8299]. Nevertheless, this module is not defined as an augment to
L3SM because a specific structure is required to meet network- L3SM because a specific structure is required to meet network-
oriented L3 needs. oriented L3 needs.
Some of the information captured in the L3SM can be passed by the Some of the information captured in the L3SM can be passed by the
Orchestrator in the L3NM (e.g., customer) or be used to fed some of Orchestrator in the L3NM (e.g., customer) or be used to fed some of
the L3NM attribute (e.g., actual forwarding policies). Some of the the L3NM attributes (e.g., actual forwarding policies). Some of the
information captured in L3SM may be maintained locally within the information captured in L3SM may be maintained locally within the
Orchestrator; which is supposed to maintain a "glue" between a Orchestrator; which is supposed to maintain a "glue" between a
Customer view and its network instantiation. Customer view and its network instantiation. Likewise, some of the
information captured and exposed using L3NM can fed the service layer
(e.g., capabilities) to derive L3SM and drive VPN service order
handling.
The L3NM module does not attempt to address all deployment cases The L3NM module does not attempt to address all deployment cases
especially those where the L3VPN connectivity is supported through especially those where the L3VPN connectivity is supported through
the coordination of different VPNs in different underlying networks. the coordination of different VPNs in different underlying networks.
More complex deployment scenarios involving the coordination of More complex deployment scenarios involving the coordination of
different VPN instances and different technologies to provide end-to- different VPN instances and different technologies to provide end-to-
end VPN connectivity are addressed by a complementary YANG model end VPN connectivity are addressed by a complementary YANG model
defined in [I-D.evenwu-opsawg-yang-composed-vpn]. defined in [I-D.evenwu-opsawg-yang-composed-vpn].
1.1. Terminology 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Terminology
This document assumes that the reader is familiar with the contents This document assumes that the reader is familiar with the contents
of [RFC6241], [RFC7950], [RFC8299], [RFC8309], and [RFC8453] and uses of [RFC6241], [RFC7950], [RFC8299], [RFC8309], and [RFC8453] and uses
the terminology defined in those documents. the terminology defined in those documents.
The meaning of the symbols in tree diagrams is defined in in The meaning of the symbols in tree diagrams is defined in [RFC8340].
[RFC8340].
The document is aimed at modeling BGP PE-based VPNs in a Service The document is aimed at modeling BGP PE-based VPNs in a Service
Provider Network, so the terms defined in [RFC4026] and [RFC4076] are Provider Network, so the terms defined in [RFC4026] and [RFC4176] are
used. used.
This document makes use of the following terms: This document makes use of the following terms:
o L3 VPN Customer Service Model (L3SM): Describes the requirements o L3 VPN Customer Service Model (L3SM): Describes the requirements
of a L3 VPN that interconnects a set of sites from the point of of a L3 VPN that interconnects a set of sites from the point of
view of the customer. The customer service model does not provide view of the customer. The customer service model does not provide
details on the Service Provider Network. The L3 VPN Customer details on the Service Provider Network. The L3 VPN Customer
Service model is defined in [RFC8299]. Service model is defined in [RFC8299].
o L3 VPN Service Network Model (L3NM): A YANG module that describes o L3 VPN Service Network Model (L3NM): A YANG module that describes
a VPN Service in the Service Provider Network. It containts a VPN Service in the Service Provider Network. It contains
information of the Service Provider network and might include information of the Service Provider network and might include
allocated resources. It can be used by network controllers to allocated resources. It can be used by network controllers to
manage and control the VPN Service configuration in the Service manage and control the VPN Service configuration in the Service
Provider network. The YANG module can be consumed by a Service Provider network. The YANG module can be consumed by a Service
Orchestrator to request a VPN Service to a Network controller. Orchestrator to request a VPN Service to a Network controller.
o Service Orchestrator: A functional entity that interacts with the o Service Orchestrator: A functional entity that interacts with the
customer of a L3 VPN. The Service Orchestrator interacts with the customer of a L3 VPN. The Service Orchestrator interacts with the
customer using L3SM. The Service Orchestrator is responsible of customer using L3SM. The Service Orchestrator is responsible of
the CE-PE attachment circuits, the PE selection, and requesting the CE-PE attachment circuits, the PE selection, and requesting
skipping to change at page 5, line 41 skipping to change at page 6, line 8
o VPN Site (vpn-site): A VPN customer's location that is connected o VPN Site (vpn-site): A VPN customer's location that is connected
to the Service Provider network via a CE-PE link, which can access to the Service Provider network via a CE-PE link, which can access
at least one VPN [RFC4176]. at least one VPN [RFC4176].
o VPN Service Provider (SP): A Service Provider offers VPN-related o VPN Service Provider (SP): A Service Provider offers VPN-related
services [RFC4176]. services [RFC4176].
o Service Provider (SP) Network: A network able to provide VPN- o Service Provider (SP) Network: A network able to provide VPN-
related services. related services.
1.2. Requirements Language 4. Reference Architecture
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Reference Architecture
Figure 1 depices the reference architecture for L3NM. The figure is Figure 1 depicts the reference architecture for L3NM. The figure is
an expansion of the architecture presented in Section 5 of [RFC8299] an expansion of the architecture presented in Section 5 of [RFC8299]
and decomposes the box marked "orchestration" in that figure into and decomposes the box marked "orchestration" in that figure into
three separate functional components called "Service Orchestration", three separate functional components called "Service Orchestration",
"Network Orchestration", and "Domain Orchestration". "Network Orchestration", and "Domain Orchestration".
Although some deployments may choose to construct a monolithic Although some deployments may choose to construct a monolithic
orchestration component (covering both service and network matters), orchestration component (covering both service and network matters),
this document advocates for a clear separation between service and this document advocates for a clear separation between service and
network orchestration components for the sake of better flexibility. network orchestration components for the sake of better flexibility.
Such design adheres to the L3VPN reference architecture defined in Such design adheres to the L3VPN reference architecture defined in
Section 1.3 of [RFC4176]. The above separation relies upon a Section 1.3 of [RFC4176]. The above separation relies upon a
dediciated communication interface between these components and dedicated communication interface between these components and
appropriate YANG module that reflect network-related information appropriate YANG module that reflect network-related information
(that is hidden to customers). (that is hidden to customers).
The intelligence for translating customer-facing information into The intelligence for translating customer-facing information into
network-centric one is implementation-specific. network-centric one is implementation-specific.
The terminology from [RFC8309] is introduced to show the distinction The terminology from [RFC8309] is introduced to show the distinction
between the "Customer Service Model", the "Service Delivery Model", between the "Customer Service Model", the "Service Delivery Model",
the "Network Configuration Model", and the "Device Configuration the "Network Configuration Model", and the "Device Configuration
Model". In that context, the "Domain Orchestration" and "Config Model". In that context, the "Domain Orchestration" and "Config
skipping to change at page 8, line 47 skipping to change at page 8, line 47
+------------:-------+ +---------:------------+ +------------:-------+ +---------:------------+
: : : :
: Device Configuration : : Device Configuration :
: : : :
+--------+ +--------+ +--------+ +--------+
| Device | | Device | | Device | | Device |
+--------+ +--------+ +--------+ +--------+
Figure 2: L3SM and L3NM in the Context of ACTN Figure 2: L3SM and L3NM in the Context of ACTN
3. Description of the L3NM YANG Module 5. Relation with other YANG Models
As discussed in the previous section, the L3NM YANG module is meant
to manage L3VPN Services within a Service Provider network. The
module provides a network-wise view of the service. Such view is
only visible within the Service Provider and is not exposed outside.
The following discusses how L3NM interfaces with other YANG modules:
L3SM: L3NM is not a Customer Service Model.
The internal view of the service (L3NM) may be mapped to an
external view which is visible to Customers : L3VPN Service YANG
data Model (L3SM) [RFC8299].
Typically, the L3NM module can be fed with inputs that are
requested by Customers, typically, relying upon a L3SM template.
Concretely, some parts of the L3SM module can be directly mapped
into L3NM while other parts are generated as a function of the
requested service and local guidelines. Some other parts are
local to the Service Provider and do not map directly to L3SM.
Note that the use of L3NM within a Service Provider does assume
nor preclude exposing the VPN service via L3SM. This is
deployment-specific. Nevertheless, the design of L3NM tries to
align as much as possible with the features supported by the L3SM
to ease grafting both L3NM and L3SM for the sake of highly
automated VPN service provisioning and delivery.
Network Topology Modules: A L3VPN involves nodes that are part of a
topology managed by the Service Provider Backbone network. Such
topology can be represented as using the network topology module
in [RFC8345].
Device Modules: L3NM is not a device model.
Once a global VPN service is captured by means of L3NM, the actual
activation and provisioning of the VPN service will involve a
variety of device modules to tweak the required functions for the
delivery of the service. These functions are supported by the VPN
nodes and can be managed using device YANG modules. A non-
comprehensive list of such device YANG modules is provided below:
* Routing management ([RFC8349])
* BGP ([I-D.ietf-idr-bgp-model])
* PIM ([I-D.liu-pim-yang])
* NAT management ([RFC8512])
* QoS management ([I-D.ietf-rtgwg-qos-model])
* ACL ([RFC8519])
How L3NM is used to derive device-specific actions is
implementation-specific.
6. Description of the L3NM YANG Module
The L3NM module ('ietf-l3vpn-ntw') is meant to manage L3 VPNs in a The L3NM module ('ietf-l3vpn-ntw') is meant to manage L3 VPNs in a
service provider network. In particular, the 'ietf-l3vpn-ntw' module service provider network. In particular, the 'ietf-l3vpn-ntw' module
can be used to create, modify, and retrieve L3VPN Services of a can be used to create, modify, and retrieve L3VPN Services of a
network. network.
3.1. Structure of the Module The detailed tree structure is provided in Figure 15.
6.1. Overall Structure of the Module
The 'ietf-l3vpn-ntw' module uses two main containers: 'vpn-services' The 'ietf-l3vpn-ntw' module uses two main containers: 'vpn-services'
and 'vpn-profiles' (see Figure 3). The 'vpn-services' container and 'vpn-profiles' (see Figure 3).
maintains the set of VPN Services managed in the service provider
network. The module allows to create a new VPN service by adding a
new instance of 'vpn-service'. The 'vpn-service' is the data
structure that abstracts the VPN Service.
The 'vpn-profiles' container allows the provider to maintain a set of The 'vpn-services' container maintains the set of VPN services
commmon VPN profiles that apply to several VPN Services. managed within the service provider's network. 'vpn-service' is the
data structure that abstracts a VPN service (Section 6.3).
module: ietf-l3vpn-ntw The 'vpn-profiles' container is used by the provider to maintain a
+--rw l3vpn-ntw set of common VPN profiles that apply to several VPN services
(Section 6.2).
module: ietf-l3vpn-ntw
+--rw l3vpn-ntw
+--rw vpn-profiles +--rw vpn-profiles
| ....... | ...
+--rw vpn-services +--rw vpn-services
+--rw vpn-service* [vpn-id] +--rw vpn-service* [vpn-id]
........ ...
Figure 3 Figure 3: Overall L3NM Tree Structure
3.2. Modeling a L3 VPN Service 6.2. VPN Profiles
The 'vpn-profiles' containers (Figure 4) allow the network provider
to define and maintain a set of common VPN profiles that apply to
several VPN services. The exaact definition of the profiles is local
to each network provider.
+--rw l3vpn-ntw
+--rw vpn-profiles
| +--rw valid-provider-identifiers
| +--rw cloud-identifier* [id] {l3vpn-svc:cloud-access}?
| | +--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 routing-profile-identifier* [id]
| +--rw id string
+--rw vpn-services
+--rw vpn-service* [vpn-id]
...
Figure 4: VPN Profiles Tree Structure
6.3. Modeling a Layer 3 VPN Service
The 'vpn-service' is the data structure that abstracts a VPN Service The 'vpn-service' is the data structure that abstracts a VPN Service
in the Service Provider Network. Every 'vpn-service' has a unique in the Service Provider Network. Each 'vpn-service' is uniquely
identifier: vpn-id. Such vpn-id is only meaningful locally within identified by an identifier: 'vpn-id'. Such 'vpn-id' is only
the Network controller. In order to facilitate the recognition of meaningful locally within the Network controller.
the service, a 'customer-name' and a 'description' may be included.
The topology of the VPN service is expressed in the 'vpn-service-
topology' leaf.
A VPN Service is built by adding instances of 'vpn-node' to the 'vpn- In order to facilitate the identification of the service, 'customer-
nodes' container. The 'vpn-node' is an abstractions that represent a name' and 'description' attributes may be provided.
set of policies applied to a network node and that belong to a single
'vpn-service'. A 'vpn-node' contains 'vpn_network_accesses', which
are the interfaces involved in the creation of the VPN. The customer
sites are connected to the 'vpn_network_accesses'. Note that, as
this is a network data model, the information about customers site is
not needed. Such information, is relevant in the L3SM model.
+--rw vpn-service* [vpn-id] The 'vpn-service' parameters are:
+--rw vpn-id svc-id
+--rw customer-name? string
+--rw vpn-service-topology? identityref
+--rw description? string
+--rw ie-profiles
| ...
+--rw vpn-nodes
| ...
+--rw multicast
Figure 4 o service-status: Allows the control of the operative and
administrative status of the service as a whole.
3.2.1. VPN node o vpn-id: Unique identifier of the L3VPN Service within L3NM scope.
o l3sm-vpn-id: Refers to the L3SNM Id of this service. This
identifier allows to easily correlate the service as built in the
network with a service request.
o vpn-service-topology: Typical network topologies are supported.
Hub-Spoke, Any-to-Any, and Custom. Real deployment on the network
is defined by the correct usage of import and export profiles
o ie-profiles: Define reusable import/export policies for the same
VPN-Service. Described in detail in Section 6.3.3
o Underlay-Transport: Describes the preference for the transport
technology to carry the traffic of the VPN-Service.
A VPN service is typically built by adding instances of 'vpn-node' to
the 'vpn-nodes' container. The '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-node' contains 'vpn-network-accesses', which are the
interfaces attached to the VPN by which the customer traffic is
received. Therefore, the customer sites are connected to the 'vpn-
network-accesses'. Note that, as this is a network data model, the
information about customers sites is not required in the model. Such
information, is rather relevant in the L3SM model.
+--rw vpn-service* [vpn-id]
+--rw service-status
| ...
+--rw vpn-id l3vpn-svc:svc-id
+--rw l3sm-vpn-id? l3vpn-svc:svc-id
+--rw customer-name? string
+--rw vpn-service-topology? identityref
+--rw description? string
+--rw ie-profiles
| ...
+--rw underlay-transport
| ...
Figure 5: vpn-service tree structure
6.3.1. Service Status
The L3NM module allows to track service status ('service-status') of
a given VPN service (Figure 6). Both operational and administrative
status are maintained together with a timestamp. For example, a
service can be created but not put into effect.
'admin' and 'ops' status can be used as trigger to detect service
anomalies. For example, a service that is declared at the service
layer as active but still inactive at the network layer is an
indication that network provision actions are needed to align the
observed service with the expected service status.
+--rw l3vpn-ntw
+--rw vpn-profiles
| ...
+--rw vpn-services
+--rw vpn-service* [vpn-id]
+--rw service-status
| +--rw admin
| | +--rw status? operational-type
| | +--rw timestamp? yang:date-and-time
| +--ro ops
| +--ro status? operational-type
| +--ro timestamp? yang:date-and-time
...
Figure 6: VPN Service Status Tree Structure
6.3.2. VPN Node
The 'vpn-node' is an abstraction that represents a set of common The 'vpn-node' is an abstraction that represents a set of common
policies applied in a given network node (tipcally a PE) and belong policies applied on a given network node (tipcally, a PE) and belong
to one L3 VPN Service. In order to indicate the network node where to one L3 VPN Service. In order to indicate the network node where
the 'vpn-node' applies the the ne-id MUST be facilitated. The 'vpn- the 'vpn-node' applies the 'ne-id' must be indicated. The 'vpn-node'
node' includes a parameter to indicate in which network node it is includes a parameter to indicate in which network node it is applied.
applied. In the case that the ne-id points to a specific PE, the In the case that the 'ne-id' points to a specific PE, the 'vpn-node'
vpn_node will likely be mapped into a vrf in the node. However, the will likely be mapped into a VRF in the node. However, the model
model also allows to point to an abstract node. In this case, the also allows to point to an abstract node. In this case, the network
network controller will decide how to split the vpn_node into vrfs. controller will decide how to split the 'vpn-node' into VRFs.
For the cases the logical resources are managed outside the network Additionally the 'vpn-node' parameters are:
controller, the model allows to explicitely indicate the logical
resources such as Route targets and Route distinguishers (RT,RD).
Under the VPN Node container, VPN Network Acesses can be created. o status: Allows the control of the operative and administrative
The VPN Network Acess represents the point to which sites are status of the 'vpn-node'.
connected. Note that, unlike in L3SM, the L3NM does not need to
model the customer site, only the points where the traffic from the
site are received. Hence, the VPN Network access contains the
connectivity information between the provider's Network and the
customer premises. The VPN profiles have a set of routing policies
than can be applied during the service creation.
+--rw vpn-node* [vpn-node-id ne-id] o local-autonomous-system: Autonomous system of locally configured
+--rw vpn-node-id string in the instance. It can be overwritten for specific purposes in
+--rw description? string the CE-PE BGP session.
+--rw ne-id string
+--rw router-id? inet:ip-address
+--rw address-family? address-family
+--rw node-role? identityref
+--rw rd? rt-types:route-distinguisher
+--rw vpn-targets
....
+--rw vpn-network-accesses
....
Figure 5 o maximum-routes: Max-number of prefixes allowed in the vpn-node
instance.
3.2.1.1. VPN Network Access o rd and vpn-targets: For the cases the logical resources are
managed outside the network controller, the model allows to
explicitely indicate the logical resources such as Route targets
(RTs) and Route Distinguishers (RDs) (RT,RD).
A 'vpn-network-access' represents an entry point to a VPN service. o Multicast: Enable multicast traffic inside the vpn. Detailed
In other words, this container encloses the parameters that describe description in Section 6.3.2.3
the access information for the traffic that belongs to a particular
L3 VPN. As such, every vpn-network-access belongs to one and only
one vpn-node. As an example, a vpn-network-access includes
information such as the connection on which the access is defined
(see the section below), the encapsulation of the traffic, policies
that are applied on the access, etc.
A provisioning network controller (PNC) [RFC8453] will accept VPN Under the VPN Node ('vpn-node') container, VPN Network Acesses ('vpn-
network-access') can be created. The VPN Network Acess represents
the point to which sites are connected. Note that, unlike in L3SM,
the L3NM does not need to model the customer site, only the points
where the traffic from the site are received. 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 than can be applied during the service
creation.
module: ietf-l3vpn-ntw
+--rw l3vpn-ntw
+--rw vpn-profiles
| ...
+--rw vpn-services
+--rw vpn-service* [vpn-id]
+--rw vpn-id l3vpn-svc:svc-id
+ ...
+--rw vpn-nodes
+--rw vpn-node* [ne-id]
+--rw vpn-node-id? union
+--rw local-autonomous-system? inet:as-number
+--rw description? string
+--rw ne-id string
+--rw router-id? inet:ip-address
+--rw address-family?
| l3vpn-svc:address-family
+--rw node-role? identityref
+--rw rd?
| rt-types:route-distinguisher
+--rw vpn-targets
| +--rw vpn-target* [id]
| | +--rw id int8
| | +--rw route-targets* [route-target]
| | | +--rw route-target
| | | rt-types:route-target
| | +--rw route-target-type
| | rt-types:route-target-type
| +--rw vpn-policies
| +--rw import-policy? leafref
| +--rw export-policy? leafref
+--rw status
| +--rw admin-enabled? boolean
| +--ro oper-status? operational-type
+--rw vpn-network-accesses
| +--rw vpn-network-access* [id]
| +--rw id
| | l3vpn-svc:svc-id
| ...
+--rw maximum-routes
| +--rw address-family* [af]
| +--rw af
| | l3vpn-svc:address-family
| +--rw maximum-routes? uint32
+--rw multicast {l3vpn-svc:multicast}?
| ...
+--rw node-ie-profile? leafref
Figure 7: VPN Node Tree Structure
6.3.2.1. Node Status
The L3NM module allows to track the status ('status') of the nodes
involved in a VPN service (Figure 8). Both operational and
administrative status are maintained. Mismatch between an
administrative status vs. the operational status can be used as
trigger to detect anomalies.
+--rw l3vpn-ntw
+--rw vpn-profiles
| ...
+--rw vpn-services
+--rw vpn-service* [vpn-id]
+--rw vpn-id l3vpn-svc:svc-id
...
+--rw vpn-nodes
| +--rw vpn-node* [ne-id]
| +--rw ne-id string
| ...
| +--rw status
| | +--rw admin-enabled? boolean
| | +--ro oper-status? operational-type
Figure 8: Node Status Tree Structure
6.3.2.2. VPN Network Access
A 'vpn-network-access' represents an entry point to a VPN service
(Figure 9). In other words, this container encloses the parameters
that describe the access information for the traffic that belongs to
a particular L3VPN. As such, every 'vpn-network-access' MUST belong
to one and only one 'vpn-node'.
A 'vpn-network-access' includes information such as the connection on
which the access is defined (see Section 6.3.2.2.1), the
encapsulation of the traffic, policies that are applied on the
access, etc.
A provisioning Network Controller (PNC) [RFC8453] will accept VPN
requests containing this construct, using the enclosed data to: requests containing this construct, using the enclosed data to:
configure the router's interface to include the parameters described configure the router's interface to include the parameters described
at the vpn-network-access, include the given interface into a VRF, at the 'vpn-network-access', include the given interface into a VRF,
configuring policies or schedulers for the incoming traffic, etc. configuring policies or schedulers for processing the incoming
traffic, etc.
3.2.1.1.1. Connection module: ietf-l3vpn-ntw
+--rw l3vpn-ntw
+--rw vpn-profiles
| ...
+--rw vpn-services
+--rw vpn-service* [vpn-id]
+--rw vpn-id l3vpn-svc:svc-id
+ ...
+--rw vpn-node* [ne-id]
+--rw ne-id string
+ ...
+--rw vpn-network-accesses
| +--rw vpn-network-access* [id]
| +--rw id
| | l3vpn-svc:svc-id
| +--rw port-id?
| | l3vpn-svc:svc-id
| +--rw description? string
| +--rw status
| | +--rw admin-enabled? boolean
| | +--ro oper-status? operational-type
| +--rw vpn-network-access-type? identityref
| +--rw connection
| | ...
| | +--rw bearer
| | ...
| +--rw ip-connection
| | ...
| +--rw security
| | ...
| +--rw routing-protocols
| | ...
| +--rw service
| ...
| ...
Figure 9: VPN Network Access Tree Structure
6.3.2.2.1. Connection
The definition of a L3VPN is commonly specified not only at the IP The definition of a L3VPN is commonly specified not only at the IP
layer, but also requires to identify parameters at the Ethernet layer, but also requires to identify parameters at the Ethernet
layer, such as encapsulation type (e.g., VLAN, QinQ, QinAny, VxLAN, layer, such as encapsulation type (e.g., VLAN, QinQ, QinAny, VxLAN,
etc.). The 'connection' container represents and groups the set of etc.). The 'connection' container represents and groups the set of
L2 connectivity from where the traffic of the L3VPN in a particular L2 connectivity from where the traffic of the L3VPN in a particular
VPN Network access is coming. VPN Network access is coming.
Additionally, the bearer-reference (Section 3.2.1.1.1.3) and the Additionally, the bearer-reference and the pseudowire termination are
pseudowire termination (Section 3.2.1.1.1.2) is supported. supported.
3.2.1.1.1.1. Encapsulation options
Ethernet encapsulation description is not supported in [RFC8299]. Ethernet encapsulation description is not supported in [RFC8299].
However, this parameters are mandatory to configure the PE However, this parameters are mandatory to configure the PE
interfaces. Thus, In the L3NM, these parameters uses the connection interfaces. Thus, In the L3NM, these parameters uses the connection
container inside the vpn-network-access. This container defines container inside the vpn-network-access. This container defines
protocols and parameters to enable connectivity at Layer 2. protocols and parameters to enable connectivity at Layer 2.
+--rw connection module: ietf-l3vpn-ntw
+--rw encapsulation-type? identityref +--rw l3vpn-ntw
+--rw tagged-interface +--rw vpn-profiles
+--rw type? identityref | ...
+--rw dot1q-vlan-tagged {dot1q}? +--rw vpn-services
| +--rw tag-type? identityref +--rw vpn-service* [vpn-id]
| +--rw cvlan-id? uint16 +--rw vpn-id l3vpn-svc:svc-id
+--rw priority-tagged + ...
| +--rw tag-type? identityref +--rw vpn-node* [ne-id]
+--rw qinq {qinq}? +--rw ne-id string
| +--rw tag-type? identityref + ...
| +--rw svlan-id uint16 +--rw vpn-network-accesses
| +--rw cvlan-id uint16 | +--rw vpn-network-access* [id]
+--rw qinany {qinany}? | +--rw id
| +--rw tag-type? identityref | | l3vpn-svc:svc-id
| +--rw svlan-id uint16 | + ...
+--rw vxlan {vxlan}? | +--rw connection
+--rw vni-id uint32 | | +--rw encapsulation-type? identityref
+--rw peer-mode? identityref | | +--rw logical-interface
+--rw peer-list* [peer-ip] | | | +--rw peer-reference? uint32
+--rw peer-ip inet:ip-address | | +--rw tagged-interface
| | | +--rw type? identityref
Figure 6 | | | +--rw dot1q-vlan-tagged {dot1q}?
| | | | +--rw tag-type? identityref
| | | | +--rw cvlan-id? uint16
| | | +--rw priority-tagged
| | | | +--rw tag-type? identityref
| | | +--rw qinq {qinq}?
| | | | +--rw tag-type? identityref
| | | | +--rw svlan-id uint16
| | | | +--rw cvlan-id uint16
| | | +--rw qinany {qinany}?
| | | | +--rw tag-type? identityref
| | | | +--rw svlan-id uint16
| | | +--rw vxlan {vxlan}?
| | | +--rw vni-id uint32
| | | +--rw peer-mode? identityref
| | | +--rw peer-list* [peer-ip]
| | | +--rw peer-ip inet:ip-address
| | +--rw bearer
| | ...
| +--rw ip-connection
| | ...
| +--rw security
| | ...
| +--rw routing-protocols
| | ...
| +--rw service
| ...
| ...
3.2.1.1.1.2. Remote Far End Configuration Figure 10: Encapsulation Tree Structure
Depending on the control plane implementation, different network Depending on the control plane implementation, different network
scenarios might require additional information for the L3VPN service scenarios might require additional information for the L3VPN service
to be configured and active. For example, an L3VPN Option C service, to be configured and active. For example, an L3VPN Option C service,
if no reflection of IPv4 VPN routes is configured via ASBR or route if no reflection of IPv4 VPN routes is configured via ASBR or route
reflector, may require additional configuration (e.g. a new BGP reflector, may require additional configuration (e.g., a new BGP
neighbor) to be coordinated between both management systems. This neighbor) to be coordinated between both management systems. This
definition requires for every management system participant in the definition requires for every management system participant in the
VPN to receive not just their own sites and site-network-accesses, VPN to receive not just their own sites and site-network-accesses,
but also to receive information about external ones, identified as an but also to receive information about external ones, identified as an
external site-network-access-type. In addition, this particular external site-network-access-type. In addition, this particular
site-network-access is augmented to include the loopback address of site-network-access is augmented to include the loopback address of
the far-end (remote/external) PE router. the far-end (remote/external) PE router.
+--rw bearer module: ietf-l3vpn-ntw
+--rw connection +--rw l3vpn-ntw
... +--rw vpn-profiles
+--rw pseudowire | ...
+--rw vcid? uint32 +--rw vpn-services
+--rw vpn-service* [vpn-id]
Figure 7 +--rw vpn-id l3vpn-svc:svc-id
+ ...
+--rw vpn-node* [ne-id]
+--rw ne-id string
+ ...
+--rw vpn-network-accesses
| +--rw vpn-network-access* [id]
| +--rw id
| | l3vpn-svc:svc-id
| + ...
| +--rw connection
| | ...
| | +--rw bearer
| | +--rw bearer-reference? string
| | | {l3vpn-svc:bearer-reference}?
| | +--rw pseudowire
| | | +--rw vcid? uint32
| | | +--rw far-end? union
| | +--rw vpls
| | +--rw vcid? union
| | +--rw far-end? union
| +--rw ip-connection
| | ...
| +--rw security
| | ...
| +--rw routing-protocols
| | ...
| +--rw service
| ...
| ...
3.2.1.1.1.3. Bearers Figure 11: Bearer Tree Structure
A site, as per [RFC4176] represents a VPN customer's location that is 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 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 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 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 connections with the site. In
the module it is assumed that the bearer has been allocated by the the module it is assumed that the bearer has been allocated by the
Service Provider at the service orchestration step. The bearer is Service Provider at the service orchestration step. The bearer is
associated to a network element and a port. Hence, a bearer is just associated to a network element and a port. Hence, a bearer is just
a bearer-reference to allow the translation between L3SM and L3NM. a bearer-reference to allow the translation between L3SM and L3NM.
3.2.1.1.2. IP Connection 6.3.2.2.2. IP Connections
IP Connection container has the parameters of the vpn-network-access IP connection container (Figure 12) has the parameters of the 'vpn-
addressing information. The address allocated in this container network-access' addressing information. The address allocated in
would represent the PE interface address configuration. The IP this container would represent the PE interface address
Connection container is designed to support dual stack (IPv4/IPv6) configuration. The IP connection container is designed to support
and three options to set the ip address: Provider DHCP, DHCP relay or both IPv4 and IPv6. It also supports three options for IP address
static addressing. assignment: Provider DHCP, DHCP relay, and static addressing.
In the case of the static addressing the model supports the In the case of the static addressing, the model supports the
assignation of several IP addresses in the same vpn-network-access. assignment of several IP addresses in the same 'vpn-network-access'.
To identify which of the addresses is the primary address of the To identify which of the addresses is the primary address of a
connection the "primary-address" reference must be set with the connection ,the "primary-address" reference MUST be set with the
corresponding address-id. corresponding 'address-id'.
+--rw ip-connection module: ietf-l3vpn-ntw
+--rw ipv4 {ipv4}? +--rw l3vpn-ntw
+--rw address-allocation-type? identityref +--rw vpn-profiles
+--rw provider-dhcp | ...
... +--rw vpn-services
+--rw dhcp-relay +--rw vpn-service* [vpn-id]
... +--rw vpn-id l3vpn-svc:svc-id
+--rw static-addresses + ...
+--rw primary-address? leafref +--rw vpn-nodes
+--rw address* [address-id] +--rw vpn-node* [ne-id]
... +--rw ne-id string
+--rw ipv6 {ipv6}? + ...
+--rw address-allocation-type? identityref +--rw status
+--rw provider-dhcp | +--rw admin-enabled? boolean
... | +--ro oper-status? operational-type
+--rw dhcp-relay +--rw vpn-network-accesses
... | +--rw vpn-network-access* [id]
+--rw static-addresses | +--rw id
+--rw primary-address? leafref | | l3vpn-svc:svc-id
+--rw address* [address-id] | + ...
... | +--rw connection
| | ...
| +--rw ip-connection
| | +--rw ipv4 {l3vpn-svc:ipv4}?
| | | +--rw address-allocation-type?
| | | | identityref
| | | +--rw provider-dhcp
| | | | +--rw provider-address?
| | | | | inet:ipv4-address
| | | | +--rw prefix-length?
| | | | | uint8
| | | | +--rw (address-assign)?
| | | | +--:(number)
| | | | | +--rw number-of-dynamic-address?
| | | | | uint16
| | | | +--:(explicit)
| | | | +--rw customer-addresses
| | | | +--rw address-group*
| | | | [group-id]
| | | | +--rw group-id
| | | | | string
| | | | +--rw start-address?
| | | | | inet:ipv4-address
| | | | +--rw end-address?
| | | | inet:ipv4-address
| | | +--rw dhcp-relay
| | | | +--rw provider-address?
| | | | | inet:ipv4-address
| | | | +--rw prefix-length? uint8
| | | | +--rw customer-dhcp-servers
| | | | +--rw server-ip-address*
| | | | inet:ipv4-address
| | | +--rw static-addresses
| | | +--rw primary-address? leafref
| | | +--rw address* [address-id]
| | | +--rw address-id string
| | | +--rw provider-address?
| | | | inet:ipv4-address
| | | +--rw customer-address?
| | | | inet:ipv4-address
| | | +--rw prefix-length? uint8
| | +--rw ipv6 {l3vpn-svc:ipv6}?
| | | +--rw address-allocation-type?
| | | | identityref
| | | +--rw provider-dhcp
| | | | +--rw provider-address?
| | | | | inet:ipv6-address
| | | | +--rw prefix-length?
| | | | | uint8
| | | | +--rw (address-assign)?
| | | | +--:(number)
| | | | | +--rw number-of-dynamic-address?
| | | | | uint16
| | | | +--:(explicit)
| | | | +--rw customer-addresses
| | | | +--rw address-group*
| | | | [group-id]
| | | | +--rw group-id
| | | | | string
| | | | +--rw start-address?
| | | | | inet:ipv6-address
| | | | +--rw end-address?
| | | | inet:ipv6-address
| | | +--rw dhcp-relay
| | | | +--rw provider-address?
| | | | | inet:ipv6-address
| | | | +--rw prefix-length? uint8
| | | | +--rw customer-dhcp-servers
| | | | +--rw server-ip-address*
| | | | inet:ipv6-address
| | | +--rw static-addresses
| | | +--rw primary-address? leafref
| | | +--rw address* [address-id]
| | | +--rw address-id string
| | | +--rw provider-address?
| | | | inet:ipv6-address
| | | +--rw customer-address?
| | | | inet:ipv6-address
| | | +--rw prefix-length? uint8
| | +--rw oam
| | +--rw bfd {l3vpn-svc:bfd}?
| | +--rw enabled? boolean
| | +--rw (holdtime)?
| | +--:(fixed)
| | | +--rw fixed-value? uint32
| | +--:(profile)
| | +--rw profile-name? leafref
| +--rw security
| | ...
| +--rw routing-protocols
| | ...
| +--rw service
| ...
Figure 8 Figure 12: IP Connection Tree Structure
3.2.1.1.3. Routing Protocols 6.3.2.2.3. CE PE Routing Protocols
The model allows the Network Operator to configure one or more The model allows the Provider to configure one or more routing
routing protocols associated with a particular vpn-network-access. protocols associated with a particular 'vpn-network-access'
This protocol will run between the PE and the CE. A routing protocol (Figure 13). This protocol will run between the PE and the CE. A
instance MUST have a type (e.g. bgp, ospf, etc.) and an identifier. routing protocol instance MUST have a type (e.g., bgp, ospf) and an
The identifier is necessary when multiple instances of the same identifier. The identifier is necessary when multiple instances of
protocol need to be configured. the same protocol have to be configured.
The model uses an abstracted view of routing protocols. When When configuring multiple instances of the same routing protocol,
configuring multiple instances of the same protocol, this does not this does not automatically imply that, from a device configuration
automatically imply that, from a device configuration perspective, perspective, there will be parallel instances (multiple processes)
there will be parallel instances (multiple processes) running. It running. It will be up to the implementation to use the most
will be up to the implementation to use the most appropriate appropriate deployment model. As an example, when multiple BGP peers
deployment model. As an example, when multiple BGP peers need to be need to be implemented, multiple instances of BGP must be configured
implemented, multiple instances of BGP must be configured as part of as part of this model. However, from a device configuration point of
this model. However from a device configuration point of view, this view, this could be implemented as:
could be implemented as:
o Multiple BGP processes with a single neighbor running in each o Multiple BGP processes with a single neighbor running in each
process. process.
o A single BGP process with multiple neighbors running. o A single BGP process with multiple neighbors running.
o A combination of both. o A combination of both.
To be aligned with [RFC8299], this model supports the following To be aligned with [RFC8299], this model supports the following
protocols: protocols:
o vrrp: takes only a list of address-family as parameter. VRRP o VRRP: takes only a list of address-family as parameter. VRRP
instance is expected to run on the vpn-network-access interface. instance is expected to run on the 'vpn-network-access' interface.
o rip: takes only a list of address-family as parameter. RIP
instance is expected to run on the vpn-network-access interface.
o static: allows user to configure one or more IPv4 and IPv6 static o RIP: takes only a list of address-family as parameter. RIP
routes. instance is expected to run on the 'vpn-network-access' interface.
o bgp: allows the user to configure a BGP neighbor including o BGP: allows to configure a BGP neighbor including parameters like
parameters like authentication using a key. The authentication authentication using a key. The authentication type will be
type will be driven by the implementation but the model supports driven by the implementation but the module supports any
any authentication that uses a key as a parameter. A BGP neighbor authentication that uses a key as a parameter. A BGP neighbor can
can support ipv4, ipv6, or both address-families. Again, it is up support IPv4, IPv6, or both address families. The module supports
to the implementation to drive the device configuration (e.g. supplying two neighbors (each for a given address family) or one
separate BGP sessions for Dual Stack, single session for Dual neighbor (for both IPv4 and IPv6 of "address-family" attribute is
Stack, etc.). set to both). It is then up to the implementation to drive the
device configuration.
o ospf: allows the user to configure OSPF to run on the vpn-network- o OSPF: allows the user to configure OSPF to run on the vpn-network-
access interface. An OSPF instance can run ipv4, ipv6 or both. access interface. An OSPF instance can run ipv4, ipv6 or both.
When only ipv4 address-family is requested, it will be up to the When only ipv4 address-family is requested, it will be up to the
implementation to drive if OSPFv2 or v3 is used. implementation to drive if OSPFv2 or v3 is used.
Routing protocol configuration do not have any routing policy o IS-IS: allows the user to configure IS-IS to run on the vpn-
configuration. Routing policies are low level device configurations network-access interface. An IS-IS instance can run L1, L2 or
that must not be part of an abstracted model. Service Provider both levels.
internal policies (such as security filters) will be implemented as
part of the device configuration but does not require any input from
this model. Some policies like primary/backup, load-balancing can be
inferred from access-priority.
3.2.2. Concept of Import/Export Profiles The module allows a user to configure one or more IPv4 and/or IPv6
static routes.
Routing configuration does not include low-level policies. These
policies are low level device configurations that must not be part of
an abstracted model. A provider's internal policies (such as
security filters) will be implemented as part of the device
configuration but does not require any input from this model. Some
policies like primary/backup or load-balancing can be inferred from
'access-priority'.
module: ietf-l3vpn-ntw
+--rw l3vpn-ntw
+--rw vpn-profiles
| ...
+--rw vpn-services
+--rw vpn-service* [vpn-id]
+--rw vpn-id l3vpn-svc:svc-id
+ ...
+--rw vpn-nodes
+--rw vpn-node* [ne-id]
+--rw ne-id string
+ ...
+--rw status
| +--rw admin-enabled? boolean
| +--ro oper-status? operational-type
+--rw vpn-network-accesses
| +--rw vpn-network-access* [id]
| +--rw id
| | l3vpn-svc:svc-id
| + ...
| +--rw connection
| | ...
| +--rw ip-connection
| | ...
| | +--rw oam
| | ...
| +--rw security
| | ...
| +--rw routing-protocols
| | +--rw routing-protocol* [id]
| | +--rw id string
| | +--rw type? identityref
| | +--rw routing-profiles* [id]
| | | +--rw id leafref
| | | +--rw type? ie-type
| | +--rw ospf {l3vpn-svc:rtg-ospf}?
| | | +--rw address-family*
| | | | l3vpn-svc:address-family
| | | +--rw area-address
| | | | yang:dotted-quad
| | | +--rw metric? uint16
| | | +--rw mtu? uint16
| | | +--rw process-id? uint16
| | | +--rw security
| | | | +--rw auth-key? string
| | | +--rw sham-links
| | | {rtg-ospf-sham-link}?
| | | +--rw sham-link* [target-site]
| | | +--rw target-site
| | | | l3vpn-svc:svc-id
| | | +--rw metric? uint16
| | +--rw bgp {l3vpn-svc:rtg-bgp}?
| | | +--rw peer-autonomous-system
| | | | inet:as-number
| | | +--rw local-autonomous-system?
| | | | inet:as-number
| | | +--rw address-family*
| | | | l3vpn-svc:address-family
| | | +--rw neighbor*
| | | | inet:ip-address
| | | +--rw multihop?
| | | | uint8
| | | +--rw security
| | | | +--rw auth-key? string
| | | +--rw status
| | | | +--rw admin-enabled? boolean
| | | | +--ro oper-status?
| | | | operational-type
| | | +--rw description?
| | | string
| | +--rw isis {rtg-isis}?
| | | +--rw address-family*
| | | | l3vpn-svc:address-family
| | | +--rw area-address area-address
| | | +--rw level? isis-level
| | | +--rw metric? uint16
| | | +--rw process-id? uint16
| | | +--rw mode? enumeration
| | | +--rw status
| | | +--rw admin-enabled? boolean
| | | +--ro oper-status?
| | | operational-type
| | +--rw static
| | | +--rw cascaded-lan-prefixes
| | | +--rw ipv4-lan-prefixes*
| | | | [lan next-hop]
| | | | {l3vpn-svc:ipv4}?
| | | | +--rw lan
| | | | | inet:ipv4-prefix
| | | | +--rw lan-tag? string
| | | | +--rw next-hop
| | | | inet:ipv4-address
| | | +--rw ipv6-lan-prefixes*
| | | [lan next-hop]
| | | {l3vpn-svc:ipv6}?
| | | +--rw lan
| | | | inet:ipv6-prefix
| | | +--rw lan-tag? string
| | | +--rw next-hop
| | | inet:ipv6-address
| | +--rw rip {l3vpn-svc:rtg-rip}?
| | | +--rw address-family*
| | | l3vpn-svc:address-family
| | +--rw vrrp {l3vpn-svc:rtg-vrrp}?
| | +--rw address-family*
| | l3vpn-svc:address-family
| +--rw service
| ...
Figure 13: Routing Tree Structure
6.3.2.3. Multicast
Multicast MAY be enabled for a particular vpn-network-node (see
Figure 14).
The model supports a single type of tree (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
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.
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.
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. Anycast is one of the mechanisms
to enhance RPs redundancy, resilience against failures, and to
recover from failures quickly.
For redundancy purposes, Multicast Source Discovery Protocol (MSDP)
may be enabled and used to share the state about sources between
multiple 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.
module: ietf-l3vpn-ntw
+--rw l3vpn-ntw
+--rw vpn-profiles
| ...
+--rw vpn-service* [vpn-id]
+--rw vpn-id l3vpn-svc:svc-id
+ ..
+--rw vpn-nodes
+--rw vpn-node* [ne-id]
+--rw ne-id string
+ ...
+--rw vpn-network-accesses
| ...
+--rw multicast {l3vpn-svc:multicast}?
| +--rw enabled? boolean
| +--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 msdp {msdp}?
| +--rw enabled? boolean
| +--rw peer? inet:ip-address
| +--rw local-address? inet:ip-address
+ ...
Figure 14: Multicast Tree Structure
6.3.3. Concept of Import/Export Profiles
The import and export profiles construct contains a list with The import and export profiles construct contains a list with
information related with route target and distinguishers (RTs and information related with route target and distinguishers (RTs and
RDs), grouped and identified by ie-profile-id. The identifier is RDs), grouped and identified by ie-profile-id. The identifier is
then referenced in one or multiple vpn-nodes, so the PNC can identify then referenced in one or multiple vpn-nodes, so the PNC can identify
RTs and RDs to be configured in the VRF. RTs and RDs to be configured in the VRF.
3.2.3. Multicast 6.3.4. Underlay Transport
Multicast can be optionally enabled for a particular vpn-network- The model allows to indicate a preference for the underlay transport
access. technology when activating a L3VPN service. This preference is
especially useful in networks with multiple domains and NNI types.
The model supports these option: BGP, LDP, GRE, SR, SR-TE, and RSVP-
TE as possible underlay transport.
The model supports a single type of tree (ASM, SSM or bidirectional). Other profiles can be defined in the future.
When ASM is used, the model supports configuration of rendez-vous This document does not make any assumption about the exact definition
points. RP discovery could be static, bsr-rp or auto-rp. When of these profiles. How such profiles are defined is deployment-
static is used RP to multicast grouping mapping must be configured as specific.
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. 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. When a particular VPN using ASM
requires a more optimal traffic delivery, the leaf optimal-traffic-
delivery can be used. When set to true, the implementation must use
any mechanism to provide a more optimal traffic delivery for the
customer. As an example, the implementation can use RP tree to
Shortest Path tree switchover or simply deploy additional RPs working
in an anycast mode.
3.3. VPN profiles 7. L3NM Module Tree Structure
The vpn-profiles containers allow the network operator to maintain a The L3NM Module Tree Structure is depicted in Figure 15.
set of commmon VPN Profiles that apply to several VPN Services.
Through this container these common profiles can be created, modified
and deleted.
module: ietf-l3vpn-ntw
+--rw l3vpn-ntw
+--rw vpn-profiles +--rw vpn-profiles
| +--rw valid-provider-identifiers | +--rw valid-provider-identifiers
| +--rw cloud-identifier* [id] {cloud-access}? | +--rw cloud-identifier* [id] {l3vpn-svc:cloud-access}?
| | +--rw id string | | +--rw id string
| +--rw encryption-profile-identifier* [id] | +--rw encryption-profile-identifier* [id]
| | +--rw id string | | +--rw id string
| +--rw qos-profile-identifier* [id] | +--rw qos-profile-identifier* [id]
| | +--rw id string | | +--rw id string
| +--rw bfd-profile-identifier* [id] | +--rw bfd-profile-identifier* [id]
| | +--rw id string | | +--rw id string
| +--rw routing-profile-identifier* [id] | +--rw routing-profile-identifier* [id]
| +--rw id string | +--rw id string
+--rw vpn-services
Figure 9 +--rw vpn-service* [vpn-id]
+--rw service-status
| +--rw admin
| | +--rw status? operational-type
| | +--rw timestamp? yang:date-and-time
| +--ro ops
| +--ro status? operational-type
| +--ro timestamp? yang:date-and-time
+--rw vpn-id l3vpn-svc:svc-id
+--rw l3sm-vpn-id? l3vpn-svc:svc-id
+--rw customer-name? string
+--rw vpn-service-topology? identityref
+--rw description? string
+--rw ie-profiles
| +--rw ie-profile* [ie-profile-id]
| +--rw ie-profile-id string
| +--rw rd? rt-types:route-distinguisher
| +--rw vpn-targets
| +--rw vpn-target* [id]
| | +--rw id int8
| | +--rw route-targets* [route-target]
| | | +--rw route-target
| | | rt-types:route-target
| | +--rw route-target-type
| | rt-types:route-target-type
| +--rw vpn-policies
| +--rw import-policy? leafref
| +--rw export-policy? leafref
+--rw underlay-transport
| +--rw type? protocols-type
+--rw vpn-nodes
+--rw vpn-node* [ne-id]
+--rw vpn-node-id? union
+--rw local-autonomous-system? inet:as-number
+--rw description? string
+--rw ne-id string
+--rw router-id? inet:ip-address
+--rw address-family?
| l3vpn-svc:address-family
+--rw node-role? identityref
+--rw rd?
| rt-types:route-distinguisher
+--rw vpn-targets
| +--rw vpn-target* [id]
| | +--rw id int8
| | +--rw route-targets* [route-target]
| | | +--rw route-target
| | | rt-types:route-target
| | +--rw route-target-type
| | rt-types:route-target-type
| +--rw vpn-policies
| +--rw import-policy? leafref
| +--rw export-policy? leafref
+--rw status
| +--rw admin-enabled? boolean
| +--ro oper-status? operational-type
+--rw vpn-network-accesses
| +--rw vpn-network-access* [id]
| +--rw id
| | l3vpn-svc:svc-id
| +--rw port-id?
| | l3vpn-svc:svc-id
| +--rw description? string
| +--rw status
| | +--rw admin-enabled? boolean
| | +--ro oper-status? operational-type
| +--rw vpn-network-access-type? identityref
| +--rw connection
| | +--rw encapsulation-type? identityref
| | +--rw logical-interface
| | | +--rw peer-reference? uint32
| | +--rw tagged-interface
| | | +--rw type? identityref
| | | +--rw dot1q-vlan-tagged {dot1q}?
| | | | +--rw tag-type? identityref
| | | | +--rw cvlan-id? uint16
| | | +--rw priority-tagged
| | | | +--rw tag-type? identityref
| | | +--rw qinq {qinq}?
| | | | +--rw tag-type? identityref
| | | | +--rw svlan-id uint16
| | | | +--rw cvlan-id uint16
| | | +--rw qinany {qinany}?
| | | | +--rw tag-type? identityref
| | | | +--rw svlan-id uint16
| | | +--rw vxlan {vxlan}?
| | | +--rw vni-id uint32
| | | +--rw peer-mode? identityref
| | | +--rw peer-list* [peer-ip]
| | | +--rw peer-ip inet:ip-address
| | +--rw bearer
| | +--rw bearer-reference? string
| | | {l3vpn-svc:bearer-reference}?
| | +--rw pseudowire
| | | +--rw vcid? uint32
| | | +--rw far-end? union
| | +--rw vpls
| | +--rw vcid? union
| | +--rw far-end? union
| +--rw ip-connection
| | +--rw ipv4 {l3vpn-svc:ipv4}?
| | | +--rw address-allocation-type?
| | | | identityref
| | | +--rw provider-dhcp
| | | | +--rw provider-address?
| | | | | inet:ipv4-address
| | | | +--rw prefix-length?
| | | | | uint8
| | | | +--rw (address-assign)?
| | | | +--:(number)
| | | | | +--rw number-of-dynamic-address?
| | | | | uint16
| | | | +--:(explicit)
| | | | +--rw customer-addresses
| | | | +--rw address-group*
| | | | [group-id]
| | | | +--rw group-id
| | | | | string
| | | | +--rw start-address?
| | | | | inet:ipv4-address
| | | | +--rw end-address?
| | | | inet:ipv4-address
| | | +--rw dhcp-relay
| | | | +--rw provider-address?
| | | | | inet:ipv4-address
| | | | +--rw prefix-length? uint8
| | | | +--rw customer-dhcp-servers
| | | | +--rw server-ip-address*
| | | | inet:ipv4-address
| | | +--rw static-addresses
| | | +--rw primary-address? leafref
| | | +--rw address* [address-id]
| | | +--rw address-id string
| | | +--rw provider-address?
| | | | inet:ipv4-address
| | | +--rw customer-address?
| | | | inet:ipv4-address
| | | +--rw prefix-length? uint8
| | +--rw ipv6 {l3vpn-svc:ipv6}?
| | | +--rw address-allocation-type?
| | | | identityref
| | | +--rw provider-dhcp
| | | | +--rw provider-address?
| | | | | inet:ipv6-address
| | | | +--rw prefix-length?
| | | | | uint8
| | | | +--rw (address-assign)?
| | | | +--:(number)
| | | | | +--rw number-of-dynamic-address?
| | | | | uint16
| | | | +--:(explicit)
| | | | +--rw customer-addresses
| | | | +--rw address-group*
| | | | [group-id]
| | | | +--rw group-id
| | | | | string
| | | | +--rw start-address?
| | | | | inet:ipv6-address
| | | | +--rw end-address?
| | | | inet:ipv6-address
| | | +--rw dhcp-relay
| | | | +--rw provider-address?
| | | | | inet:ipv6-address
| | | | +--rw prefix-length? uint8
| | | | +--rw customer-dhcp-servers
| | | | +--rw server-ip-address*
| | | | inet:ipv6-address
| | | +--rw static-addresses
| | | +--rw primary-address? leafref
| | | +--rw address* [address-id]
| | | +--rw address-id string
| | | +--rw provider-address?
| | | | inet:ipv6-address
| | | +--rw customer-address?
| | | | inet:ipv6-address
| | | +--rw prefix-length? uint8
| | +--rw oam
| | +--rw bfd {l3vpn-svc:bfd}?
| | +--rw enabled? boolean
| | +--rw (holdtime)?
| | +--:(fixed)
| | | +--rw fixed-value? uint32
| | +--:(profile)
| | +--rw profile-name? leafref
| +--rw security
| | +--rw authentication
| | +--rw encryption {l3vpn-svc:encryption}?
| | | +--rw enabled? boolean
| | | +--rw layer? enumeration
| | +--rw encryption-profile
| | +--rw (profile)?
| | | +--:(provider-profile)
| | | | +--rw profile-name? leafref
| | | +--:(customer-profile)
| | | +--rw algorithm? string
| | +--rw (key-type)?
| | +--:(psk)
| | +--rw preshared-key? string
| +--rw routing-protocols
| | +--rw routing-protocol* [id]
| | +--rw id string
| | +--rw type? identityref
| | +--rw routing-profiles* [id]
| | | +--rw id leafref
| | | +--rw type? ie-type
| | +--rw ospf {l3vpn-svc:rtg-ospf}?
| | | +--rw address-family*
| | | | l3vpn-svc:address-family
| | | +--rw area-address
| | | | yang:dotted-quad
| | | +--rw metric? uint16
| | | +--rw mtu? uint16
| | | +--rw process-id? uint16
| | | +--rw security
| | | | +--rw auth-key? string
| | | +--rw sham-links
| | | {rtg-ospf-sham-link}?
| | | +--rw sham-link* [target-site]
| | | +--rw target-site
| | | | l3vpn-svc:svc-id
| | | +--rw metric? uint16
| | +--rw bgp {l3vpn-svc:rtg-bgp}?
| | | +--rw peer-autonomous-system
| | | | inet:as-number
| | | +--rw local-autonomous-system?
| | | | inet:as-number
| | | +--rw address-family*
| | | | l3vpn-svc:address-family
| | | +--rw neighbor*
| | | | inet:ip-address
| | | +--rw multihop?
| | | | uint8
| | | +--rw security
| | | | +--rw auth-key? string
| | | +--rw status
| | | | +--rw admin-enabled? boolean
| | | | +--ro oper-status?
| | | | operational-type
| | | +--rw description?
| | | string
| | +--rw isis {rtg-isis}?
| | | +--rw address-family*
| | | | l3vpn-svc:address-family
| | | +--rw area-address area-address
| | | +--rw level? isis-level
| | | +--rw metric? uint16
| | | +--rw process-id? uint16
| | | +--rw mode? enumeration
| | | +--rw status
| | | +--rw admin-enabled? boolean
| | | +--ro oper-status?
| | | operational-type
| | +--rw static
| | | +--rw cascaded-lan-prefixes
| | | +--rw ipv4-lan-prefixes*
| | | | [lan next-hop]
| | | | {l3vpn-svc:ipv4}?
| | | | +--rw lan
| | | | | inet:ipv4-prefix
| | | | +--rw lan-tag? string
| | | | +--rw next-hop
| | | | inet:ipv4-address
| | | +--rw ipv6-lan-prefixes*
| | | [lan next-hop]
| | | {l3vpn-svc:ipv6}?
| | | +--rw lan
| | | | inet:ipv6-prefix
| | | +--rw lan-tag? string
| | | +--rw next-hop
| | | inet:ipv6-address
| | +--rw rip {l3vpn-svc:rtg-rip}?
| | | +--rw address-family*
| | | l3vpn-svc:address-family
| | +--rw vrrp {l3vpn-svc:rtg-vrrp}?
| | +--rw address-family*
| | l3vpn-svc:address-family
| +--rw service
| +--rw svc-input-bandwidth uint64
| +--rw svc-output-bandwidth uint64
| +--rw svc-mtu uint16
| +--rw qos {l3vpn-svc: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 (dst-network)?
| | | | | | | | +--:(dst-ipv4-network)
| | | | | | | | +--rw dst-ipv4-network?
| | | | | | | | inet:ipv4-prefix
| | | | | | | +--rw (source-network)?
| | | | | | | +--:(src-ipv4-network)
| | | | | | | +--rw src-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)?
| | | | | | | +--:(dst-ipv6-network)
| | | | | | | +--rw dst-ipv6-network?
| | | | | | | inet:ipv6-prefix
| | | | | | +--rw (src-network)?
| | | | | | | +--:(src-ipv6-network)
| | | | | | | +--rw src-ipv6-network?
| | | | | | | inet:ipv6-prefix
| | | | | | +--rw flow-label?
| | | | | | inet:ipv6-flow-label
| | | | | +--rw (l4)?
| | | | | +--:(tcp)
| | | | | | +--rw tcp
| | | | | | +--rw sequence-number?
| | | | | | | uint32
| | | | | | +--rw ack-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)?
| | | | | | | ...
| | | | | | +--rw (destination-port)?
| | | | | | | ...
| | | | | +--:(udp)
| | | | | +--rw udp
| | | | | +--rw length?
| | | | | | uint16
| | | | | +--rw (source-port)?
| | | | | | ...
| | | | | +--rw (destination-port)?
| | | | | | ...
| | | | +--:(match-application)
| | | | +--rw match-application?
| | | | identityref
| | | +--rw target-class-id?
| | | string
| | +--rw qos-profile
| | +--rw (qos-profile)?
| | +--:(standard)
| | | +--rw profile? leafref
| | | +--rw direction? identityref
| | +--:(custom)
| | +--rw classes
| | {l3vpn-svc:qos-custom}?
| | +--rw class* [class-id]
| | +--rw class-id
| | | string
| | +--rw direction?
| | | identityref
| | +--rw rate-limit?
| | | decimal64
| | +--rw latency
| | | +--rw (flavor)?
| | | +--:(lowest)
| | | | +--rw use-lowest-latency?
| | | | empty
| | | +--:(boundary)
| | | +--rw jitter-boundary?
| | | uint16
| | +--rw jitter
| | | +--rw (flavor)?
| | | +--:(lowest)
| | | | +--rw use-lowest-jitter?
| | | | empty
| | | +--:(boundary)
| | | +--rw latency-boundary?
| | | uint32
| | +--rw bandwidth
| | +--rw guaranteed-bw-percent
| | | decimal64
| | +--rw end-to-end?
| | empty
| +--rw carrierscarrier
| | {l3vpn-svc:carrierscarrier}?
| | +--rw signalling-type? enumeration
| +--rw multicast {l3vpn-svc:multicast}?
| +--rw site-type? enumeration
| +--rw address-family
| | +--rw ipv4? boolean
| | | {l3vpn-svc:ipv4}?
| | +--rw ipv6? boolean
| | {l3vpn-svc:ipv6}?
| +--rw protocol-type? enumeration
| +--rw remote-source? boolean
+--rw maximum-routes
| +--rw address-family* [af]
| +--rw af
| | l3vpn-svc:address-family
| +--rw maximum-routes? uint32
+--rw multicast {l3vpn-svc:multicast}?
| +--rw enabled? boolean
| +--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 msdp {msdp}?
| +--rw enabled? boolean
| +--rw peer? inet:ip-address
| +--rw local-address? inet:ip-address
+--rw node-ie-profile? leafref
3.4. Model tree Figure 15
The high-level model structure defined by this document is as shown 8. Sample Uses of the L3NM Data Model
below:
module: ietf-l3vpn-ntw 8.1. Enterprise L3 VPN Services
+--rw l3vpn-ntw
+--rw vpn-profiles
| +--rw valid-provider-identifiers
| +--rw cloud-identifier* [id] {cloud-access}?
| | +--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 routing-profile-identifier* [id]
| +--rw id string
+--rw vpn-services
+--rw vpn-service* [vpn-id]
+--rw vpn-id svc-id
+--rw customer-name? string
+--rw vpn-service-topology? identityref
+--rw description? string
+--rw ie-profiles
| +--rw ie-profile* [ie-profile-id]
| +--rw ie-profile-id string
| +--rw rd?
| | rt-types:route-distinguisher
| +--rw vpn-targets
| +--rw vpn-target* [route-target]
| +--rw route-target
| | rt-types:route-target
| +--rw route-target-type
| rt-types:route-target-type
+--rw vpn-nodes
| +--rw vpn-node* [vpn-node-id ne-id]
| +--rw vpn-node-id string
| +--rw autonomous-system? uint32
| +--rw description? string
| +--rw ne-id string
| +--rw router-id? inet:ip-address
| +--rw address-family? address-family
| +--rw node-role? identityref
| +--rw rd?
| | rt-types:route-distinguisher
| +--rw vpn-targets
| | +--rw vpn-target* [route-target]
| | +--rw route-target
| | | rt-types:route-target
| | +--rw route-target-type
| | rt-types:route-target-type
| +--rw status
| | +--rw admin-enabled? boolean
| | +--ro oper-status? operational-type
| +--rw vpn-network-accesses
| | +--rw vpn-network-access*
| | [vpn-network-access-id]
| | +--rw vpn-network-access-id svc-id
| | +--rw description? string
| | +--rw status
| | | +--rw admin-enabled? boolean
| | | +--ro oper-status? operational-type
| | +--rw vpn-network-access-type?
| | | identityref
| | +--rw connection
| | | +--rw encapsulation-type? identityref
| | | +--rw tagged-interface
| | | | +--rw type?
| | | | | identityref
| | | | +--rw dot1q-vlan-tagged {dot1q}?
| | | | | +--rw tag-type? identityref
| | | | | +--rw cvlan-id? uint16
| | | | +--rw priority-tagged
| | | | | +--rw tag-type? identityref
| | | | +--rw qinq {qinq}?
| | | | | +--rw tag-type? identityref
| | | | | +--rw svlan-id uint16
| | | | | +--rw cvlan-id uint16
| | | | +--rw qinany {qinany}?
| | | | | +--rw tag-type? identityref
| | | | | +--rw svlan-id uint16
| | | | +--rw vxlan {vxlan}?
| | | | +--rw vni-id uint32
| | | | +--rw peer-mode? identityref
| | | | +--rw peer-list* [peer-ip]
| | | | +--rw peer-ip
| | | | inet:ip-address
| | | +--rw bearer
| | | +--rw bearer-reference? string
| | | | {bearer-reference}?
| | | +--rw pseudowire
| | | +--rw vcid? uint32
| | +--rw ip-connection
| | | +--rw ipv4 {ipv4}?
| | | | +--rw address-allocation-type?
| | | | | identityref
| | | | +--rw provider-dhcp
| | | | | +--rw provider-address?
| | | | | | inet:ipv4-address
| | | | | +--rw prefix-length?
| | | | | | uint8
| | | | | +--rw (address-assign)?
| | | | | +--:(number)
| | | | | | +--rw number-of-dynamic-address?
| | | | | | uint16
| | | | | +--:(explicit)
| | | | | +--rw customer-addresses
| | | | | +--rw address-group*
| | | | | [group-id]
| | | | | +--rw group-id
| | | | | | string
| | | | | +--rw start-address?
| | | | | | inet:ipv4-address
| | | | | +--rw end-address?
| | | | | inet:ipv4-address
| | | | +--rw dhcp-relay
| | | | | +--rw provider-address?
| | | | | | inet:ipv4-address
| | | | | +--rw prefix-length?
| | | | | | uint8
| | | | | +--rw customer-dhcp-servers
| | | | | +--rw server-ip-address*
| | | | | inet:ipv4-address
| | | | +--rw static-addresses
| | | | +--rw primary-address? leafref
| | | | +--rw address* [address-id]
| | | | +--rw address-id
| | | | | string
| | | | +--rw provider-address?
| | | | | inet:ipv4-address
| | | | +--rw customer-address?
| | | | | inet:ipv4-address
| | | | +--rw prefix-length?
| | | | uint8
| | | +--rw ipv6 {ipv6}?
| | | | +--rw address-allocation-type?
| | | | | identityref
| | | | +--rw provider-dhcp
| | | | | +--rw provider-address?
| | | | | | inet:ipv6-address
| | | | | +--rw prefix-length?
| | | | | | uint8
| | | | | +--rw (address-assign)?
| | | | | +--:(number)
| | | | | | +--rw number-of-dynamic-address?
| | | | | | uint16
| | | | | +--:(explicit)
| | | | | +--rw customer-addresses
| | | | | +--rw address-group*
| | | | | [group-id]
| | | | | +--rw group-id
| | | | | | string
| | | | | +--rw start-address?
| | | | | | inet:ipv6-address
| | | | | +--rw end-address?
| | | | | inet:ipv6-address
| | | | +--rw dhcp-relay
| | | | | +--rw provider-address?
| | | | | | inet:ipv6-address
| | | | | +--rw prefix-length?
| | | | | | uint8
| | | | | +--rw customer-dhcp-servers
| | | | | +--rw server-ip-address*
| | | | | inet:ipv6-address
| | | | +--rw static-addresses
| | | | +--rw primary-address? leafref
| | | | +--rw address* [address-id]
| | | | +--rw address-id
| | | | | string
| | | | +--rw provider-address?
| | | | | inet:ipv6-address
| | | | +--rw customer-address?
| | | | | inet:ipv6-address
| | | | +--rw prefix-length?
| | | | uint8
| | | +--rw oam
| | | +--rw bfd {bfd}?
| | | +--rw enabled?
| | | | boolean
| | | +--rw (holdtime)?
| | | +--:(fixed)
| | | | +--rw fixed-value?
| | | | uint32
| | | +--:(profile)
| | | +--rw profile-name? leafref
| | +--rw security
| | | +--rw authentication
| | | +--rw encryption {encryption}?
| | | | +--rw enabled? boolean
| | | | +--rw layer? enumeration
| | | +--rw encryption-profile
| | | +--rw (profile)?
| | | | +--:(provider-profile)
| | | | | +--rw profile-name? leafref
| | | | +--:(customer-profile)
| | | | +--rw algorithm? string
| | | +--rw (key-type)?
| | | +--:(psk)
| | | +--rw preshared-key? string
| | +--rw routing-protocols
| | +--rw routing-protocol* [id]
| | +--rw id string
| | +--rw type?
| | | identityref
| | +--rw routing-profiles* [id]
| | | +--rw id leafref
| | | +--rw type? ie-type
| | +--rw ospf {rtg-ospf}?
| | | +--rw address-family*
| | | | address-family
| | | +--rw area-address
| | | | yang:dotted-quad
| | | +--rw metric? uint16
| | | +--rw mtu? uint16
| | | +--rw process-id? uint16
| | | +--rw security
| | | | +--rw auth-key? string
| | | +--rw sham-links
| | | {rtg-ospf-sham-link}?
| | | +--rw sham-link* [target-site]
| | | +--rw target-site svc-id
| | | +--rw metric? uint16
| | +--rw bgp {rtg-bgp}?
| | | +--rw autonomous-system uint32
| | | +--rw address-family*
| | | | address-family
| | | +--rw neighbor?
| | | | inet:ip-address
| | | +--rw multihop? uint8
| | | +--rw security
| | | +--rw auth-key? string
| | +--rw static
| | | +--rw cascaded-lan-prefixes
| | | +--rw ipv4-lan-prefixes*
| | | | [lan next-hop] {ipv4}?
| | | | +--rw lan
| | | | | inet:ipv4-prefix
| | | | +--rw lan-tag? string
| | | | +--rw next-hop
| | | | inet:ipv4-address
| | | +--rw ipv6-lan-prefixes*
| | | [lan next-hop] {ipv6}?
| | | +--rw lan
| | | | inet:ipv6-prefix
| | | +--rw lan-tag? string
| | | +--rw next-hop
| | | inet:ipv6-address
| | +--rw rip {rtg-rip}?
| | | +--rw address-family*
| | | address-family
| | +--rw vrrp {rtg-vrrp}?
| | +--rw address-family*
| | address-family
| +--rw maximum-routes
| | +--rw address-family* [af]
| | +--rw af address-family
| | +--rw maximum-routes? uint32
| +--rw node-ie-profile? leafref
+--rw multicast {multicast}?
+--rw enabled? boolean
+--rw customer-tree-flavors
| +--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 rp-address inet:ip-address
| +--rw groups
| +--rw group* [id]
| +--rw id uint16
| +--rw (group-format)
| +--:(singleaddress)
| | +--rw group-address?
| | inet:ip-address
| +--:(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
Figure 10 Enterprise L3VPNs are one of the most demanded services for carriers,
and therefore, L3NM can be useful to automate the tasks of
provisioning and maintenance of these VPNs. Templates and batch
processes can be built, and as a result many parameters are needed
for the creation from scratch of a VPN that can be abstracted to the
upper SDN layer and little manual intervention will be still
required.
4. Use of the Data Model Also common addition/removal of sites of an existing customer VPN can
benefit of using L3NM, by creation of workflows that either prune or
add nodes as required from the network data model object.
4.1. Multi-Domain Resource Management 8.2. Multi-Domain Resource Management
The implementation of L3VPN services which span across The implementation of L3VPN services which span across
administratively separated domains (i.e., that are under the administratively separated domains (i.e., that are under the
administration of different management systems or controllers) administration of different management systems or controllers)
requires some network resources to be synchronized between systems. requires some network resources to be synchronized between systems.
Particularly, there are two resources that must be orchestrated and Particularly, there are two resources that must be orchestrated and
manage to avoid asymmetric (non-functional) configuration, or the manage to avoid asymmetric (non-functional) configuration, or the
usage of unavailable resources. For example, RTs shall be usage of unavailable resources.
synchronized between PEs. When every PE is controlled by the same
management system, RT allocation can be performed by the system. In
cases where the service spans across multiple management systems,
this task of allocating RTs has to be aligned across the domains,
therefore, the service model must provide a way to specify RTs. In
addition, RDs must also be synchronized to avoid collisions in RD
allocation between separate systems. An incorrect allocation might
lead to the same RD and IP prefixes being exported by different PE
routers.
5. Relation with other Yang Models For example, RTs shall be synchronized between PEs. When every PE is
controlled by the same management system, RT allocation can be
performed by the system. In cases where the service spans across
multiple management systems, this task of allocating RTs has to be
aligned across the domains, therefore, the service model must provide
a way to specify RTs. In addition, RDs must also be synchronized to
avoid collisions in RD allocation between separate systems. An
incorrect allocation might lead to the same RD and IP prefixes being
exported by different PE routers.
The L3NM model, aimed at managing the L3VPN Services in a Service 8.3. Management of Multicast services
Provider Network controller/orchestrator has relations with other
Yang modules.
5.1. Relation with L3SM Multicast services over L3VPN can be implemented either using dual
PIM MVPNs (also known as Draft Rosen model) [RFC 4364] or
multiprotocol BGP (MBGP)-based MVPNs called Next Generation Multicast
VPN (ng-MVPN) [RFC 6513/6514]. Both methods are supported and
equally effective, but the main difference is that MBGP-based MVPN
does not require multicast configuration on the service provider
backbone. Multiprotocol BGP multicast VPNs employ the intra-
autonomous system (AS) next-generation BGP control plane and PIM
sparse mode as the data plane. The PIM state information is
maintained between the PE routers using the same architecture that is
used for unicast VPNs.
[RFC8299] defines a L3VPN Service YANG data Model (L3SM) that can be On the other hand, Draft Rosen has limitations such as reduced
used for communication between customers and VPN service providers. options for transport, control plane scalability, availability,
Hence, the model provides inputs to the Network Operator to deliver operational inconsistency and the need of maintaining state in the
such service to the customer. Hence, some parts of the model can be backbone. Because of this, ng-MNPN is the architectural model that
directly mapped into L3NM. has been taken as the base for implementing multicast service on
L3VPN. In this scenario, BGP auto discovery is used to discover MVPN
PE members and the customer PIM signaling is sent across provider
core through MP-BGP. The multicast traffic is transported on MPLS
P2MP LSPs. All of the previous information is carried in the MCAST-
VPN BGP NRLI.
o Routing protocols requested by the client at PE-CE interface. In 9. L3VPN Examples
sake of alignment, the same protocols are supported.
5.2. Relation with Network Topology 9.1. 4G VPN Provissioning Example
The L3NM model manages VPN Services running over Service Provider L3VPNs are widely used to deploy 3G/4G, fixed, and enterprise
Backbone network. The set of nodes over which it is possible to services mainly because several traffic discrimination policies can
deploy a L3 VPN Service MAY be part of the topology contained in an be applied within the network to deliver to the mobile customers a
ietf-network module. service that meets the SLA requiremets.
5.3. Relation with Device Models As it is shown in the Figure 16, typically, an eNodeB (CE) is
directly connected to the access routers of the mobile backhaul and
their logical interfaces (one or many according to the Service type)
are configured in a VPN that transports the packets to the mobile
core platforms. In this example, a 'vpn-node' is created with two
'vpn-network-accesses'.
Creating services in the l3vpn-ntw module will will lead at some +-------------+ +------------------+
point to the configuration of devices. Hence, it is foreseen that | | | PE |
the data for the device yang modules will be derived partially from | | 192.168.0.2 | 10.0.0.1 |
the L3NM vpn-service container. Note that L3NM is NOT a device | eNodeB |>--------/------->|........... |
model. | | Vlan 1 | | |
| |>--------/------->|...... | |
| | Vlan 2 | | | |
| | Direct | +-------------+ |
+-------------+ Routing | | vpn-node-id | |
| | 44 | |
| +-------------+ |
| |
+------------------+
6. L3VPN Examples Figure 16: Mobile Backhaul Example
6.1. 4G VPN Provissioning Example To create a L3VPN service using the L3NM model, the followng sample
steps can be followed:
The L3VPN service defined in this draft provides a multipoint, routed First: Create the 4G VPN Service (Figure 17).
service to the customer over an IP/MPLS core. The L3VPNs are widely
used to deploy 3G/4G, fixed and enterprise services principally due
to the fact that several traffic discrimination policies can be
applied in the network to transport and guarantee the right SLAs to
the mobile customers.
As it is shown in the Figure 11, commonly the eNODEB (CE) is directly POST: /restconf/data/ietf-l3vpn-ntw:l3vpn-ntw/vpn-services
connected to the access routers (DCSG) of the mobile backhaul and Host: example.com
their logical interfaces (one or many according to the Service type) Content-Type: application/yang-data+json
are configured in a VPN that transport the packets to the mobile core
platforms.
+--------------+ {
+------+ +-----+ +-----+ +-----+ | Platforms | "ietf-l3vpn-ntw:vpn-services": {
|eNODEB|--/-| PE |----| P |----| PE |----| (SGW/MME) | "vpn-service": [
+------+ +-----+ +-----+ +-----+ | ... | "vpn-id": "4G",
+--------------+ "customer-name": "mycustomer",
"vpn-service-topology": "custom",
"description": "VPN to deploy 4G services"
]
}
}
Figure 11: Mobile Backhaul Example Figure 17: Create VPN Service
To configure a L3VPN service using the L3NM model the procedure and Second: Create a VPN Node as depicted in Figure 18. In this type of
the JSON with the data structure is the following: service, the VPN Node is equivalent to the VRF configured in the
physical device ('ne-id'=10.0.0.1).
Create VPN Service POST: /restconf/data/ietf-l3vpn-ntw:l3vpn-ntw/\
<vpn-services> vpn-services/vpn-service=4G
<vpn-service> Host: example.com
<vpn-id>1</vpn-id> Content-Type: application/yang-data+json
<customer-name>4G</customer-name>
<vpn-service-topology>hub-spoke</vpn-service-topology>
<description>4G</description>
</vpn-service>
</vpn-services>
</l3vpn-ntw>
Figure 12: Create VPN Service {
"ietf-l3vpn-ntw:vpn-nodes": {
"vpn-node": [
"vpn-node-id": "44",
"ne-id": "10.0.0.1",
"local-autonomous-system": "65550",
"rd": "0:65550:1",
"vpn-targets": {
"vpn-target": [
"id": "1",
"route-targets": ["route-target": "0:65550:1"],
"route-target-type": "both"
}
}
]
}
}
Create VPN Node: For this type of service the VPN Node is equivalent Figure 18: Create VPN Node
with the VRF configured in the physical device.
<vpn-nodes> Finally, two VPN Network Accesses are created using the same physical
<vpn-node> port ('port-id'=1/1/1). Each 'vpn-network-access' has a particular
<vpn-node-id>1</vpn-node-id> VLAN (1,2) to differentiante the traffic between: Sync and data
<ne-id>10.0.0.1</ne-id> (Figure 19).
<autonomous-system>65000</autonomous-system>
<description>4G</description>
<router-id>10.0.0.1</router-id>
<address-family>ipv4</address-family>
<node-role>any-to-any-role</node-role>
<rd>1:1</rd>
</vpn-node>
</vpn-nodes>
Figure 13: Create VPN Node POST: /restconf/data/ietf-l3vpn-ntw:l3vpn-ntw/\
vpn-services/vpn-service=4G/vpn-nodes/vpn-node=44
content-type: application/yang-data+json
{
"ietf-l3vpn-ntw:vpn-network-accesses": {
"vpn-network-access": [
{
"vpn-network-access-id": "1/1/1.1",
"port-id": "1/1/1",
"description": "Interface SYNC to eNODE-B",
"status": {"admin-enabled": "true"},
"vpn-network-access-type": "l3vpn-svc:point-to-point",
"ip-connection": {
"ipv4": {
"address-allocation-type": "l3vpn-svc:static-address",
"static-addresses": {
"primary-address": "1",
"address": [
"address-id": "1",
"provider-address": "192.168.0.1",
"customer-address": "192.168.0.1",
"prefix-length": "32"
]
}
}
},
"routing-protocols": {
"routing-protocol": [
"id": "1",
"type": "l3vpn-svc:direct"
]
}
},
{
"vpn-network-access-id": "1/1/1.2",
"port-id": "1/1/1",
"description": "Interface DATA to eNODE-B",
"status": {"admin-enabled": "true"},
"ip-connection": {
"ipv4": {
"static-addresses": {
"primary-address": "1",
"address": [
"address-id": "1",
"provider-address": "192.168.1.1",
"customer-address": "192.168.1.2",
"prefix-length": "32"
]
}
}
},
"routing-protocols": {
"routing-protocol": [
"id": "1",
"type": "l3vpn-svc:direct"
]
}
}
]
}
}
Create VPN Network Access Figure 19: Create VPN Network Access
<vpn-network-accesses> 9.2. Multicast VPN Provisioning Example
<vpn-network-access>
<vpn-network-access-id>1/1/1</vpn-network-access-id>
<description>4G</description>
<status>
<admin-enabled>true</admin-enabled>
</status>
<vpn-network-access-type>point-to-point</vpn-network-access-type>
<ip-connection>
<ipv4>
<address-allocation-type>static-address</address-allocation-type>
<static-addresses>
<primary-address>1</primary-address>
<address>
<address-id>1</address-id>
<provider-address>192.168.0.1</provider-address>
<customer-address>192.168.0.2</customer-address>
<prefix-length>30</prefix-length>
</address>
</static-addresses>
</ipv4>
</ip-connection>
<routing-protocols>
<routing-protocol>
<id>1</id>
<type>direct</type>
</routing-protocol>
</routing-protocols>
</vpn-network-access>
</vpn-network-accesses>
Figure 14: Create VPN Network Access IPTV is mainly distributed through multicast over the LANs. In the
following example, PIM-SM is enabled and functional between the PE
and the CE. The PE receives multicast traffic from a CE that is
directly connected to the multicast source. The signaling between PE
and CE is achieved using BGP. Also, RP is statically configured for
a multicast group.
7. Yang Module +-----------+ +------+ +------+ +-----------+
| Multicast |---| CE |--/--| PE |----| Backbone |
| source | +------+ +------+ | IP/MPLS |
+-----------+ +-----------+
<CODE BEGINS> file "ietf-l3vpn-ntw@2019-11-17.yang" Figure 20: Multicast L3VPN Service Example
module ietf-l3vpn-ntw {
To configure a Multicast L3VPN service using the L3NM model the
procedure and the JSON with the data structure is the following:
First, the multicast service is created (see the excerpt of the
request message body shown in Figure 21)
"vpn-services": {
"vpn-service": {
"vpn-id": "Multicast_IPTV",
"customer-name": "310",
"vpn-service-topology": "hub-spoke",
"description": "Multicast IPTV VPN service"
}
}
Figure 21: Create Multicast VPN Service (Excerpt of the Message
Request Body)
Then, the VPN nodes are created (see the excerpt of the request
message body shown in Figure 22). In this example, the VPN Node will
represent VRF configured in the physical device.
"vpn-node": [
"vpn-node-id": "500003105",
"ne-id": "10.250.2.202",
"autonomous-system": "3816",
"description": "VRF_IPTV_MULTICAST",
"router-id": "10.250.2.202",
"address-family": "ipv4",
"node-role": {
"l3vpn-svc:hub-role"
},
"rd": "3816:31050202",
"multicast": {
"enabled": "true",
"rp": {
"rp-group-mappings": {
"rp-group-mapping": {
"id": "1",
"rp-address": "172.19.48.17",
"groups": {
"group": {
"id": "1",
"group-address": "239.130.0.0/15"
}
}
}
},
"rp-discovery": {
"rp-discovery-type": {
"l3vpn-svc:static-rp"
}
}
}
}
]
Figure 22: Create Multicast VPN Node (Excerpt of the Message Request
Body)
Finally, create the VPN Network Access with Multicast enabled (see
the excerpt of the request message body shown in Figure 23)
"vpn-network-access": {
"vpn-network-access-id": "1/1/1",
"description": "Connected_to_source",
"status": { "admin-enabled": "true" },
"vpn-network-access-type": {
"l3vpn-svc:point-to-point"
},
"ip-connection": {
"ipv4": {
"address-allocation-type": {
"l3vpn-svc:static-address"
},
"static-addresses": {
"primary-address": "1",
"address": {
"address-id": "1",
"provider-address": "172.19.48.1",
"prefix-length": "30"
}
}
}
},
"routing-protocols": {
"routing-protocol": {
"id": "1",
"type": {
"l3vpn-svc:bgp"
},
"bgp": {
"peer-autonomous-system": "6500",
"local-autonomous-system": "3816",
"address-family": "ipv4",
"neighbor": "172.19.48.2",
"description": "Connected_to_CE"
}
}
},
"service": {
"multicast": {
"multicast-site-type": "source-only",
"multicast-address-family": { "ipv4": "true" },
"protocol-type": "router"
}
}
}
Figure 23: Create VPN Network Access (Excerpt of the Message Request
Body)
10. L3NM YANG Module
<CODE BEGINS> file "ietf-l3vpn-ntw@2020-03.09.yang"
module ietf-l3vpn-ntw {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-l3vpn-ntw"; namespace "urn:ietf:params:xml:ns:yang:ietf-l3vpn-ntw";
prefix l3vpn-ntw; prefix l3vpn-ntw;
import ietf-inet-types { import ietf-inet-types {
prefix inet; prefix inet;
reference
"Section 4 of RFC 6991";
} }
import ietf-yang-types { import ietf-yang-types {
prefix yang; prefix yang;
reference
"Section 3 of RFC 6991";
} }
import ietf-netconf-acm { import ietf-netconf-acm {
prefix nacm; prefix nacm;
reference
"RFC 8341: Network Configuration Access Control Model";
} }
import ietf-routing-types { import ietf-routing-types {
prefix rt-types; prefix rt-types;
reference
"RFC 8294: Common YANG Data Types for the Routing Area";
} }
import ietf-l3vpn-svc {
prefix l3vpn-svc;
reference
"RFC 8299: YANG Data Model for L3VPN Service Delivery";
}
import ietf-packet-fields {
prefix packet-fields;
reference
"RFC 8519: YANG Data Model for Network Access
Control Lists (ACLs)";
}
organization organization
"IETF OPSA (Operations and Management Area) Working Group "; "IETF OPSA (Operations and Management Area) Working Group ";
contact contact
"WG Web: <http://tools.ietf.org/wg/opsawg/> "WG Web: <http://tools.ietf.org/wg/opsawg/>
WG List: <mailto:opsawg@ietf.org> WG List: <mailto:opsawg@ietf.org>
Author: Samier Barguil
<mailto:samier.barguilgiraldo.ext@telefonica.com>
Editor: Oscar Gonzalez de Dios Editor: Oscar Gonzalez de Dios
<mailto:oscar.gonzalezdedios@telefonica.com> <mailto:oscar.gonzalezdedios@telefonica.com>
Editor: Alejandro Aguado Author: Mohamed Boucadair
<mailto:alejandro.aguado_martin@nokia.com> <mailto:mohamed.boucadair@orange.com>
Editor: Victor Lopez Author: Luis Angel Munoz
<mailto:victor.lopezalvarez@telefonica.com>
Editor: Daniel Voyer
<mailto:daniel.voyer@bell.ca>
Editor: Luis Angel Munoz
<mailto:luis-angel.munoz@vodafone.com> <mailto:luis-angel.munoz@vodafone.com>
";
description Author: Alejandro Aguado
<mailto:alejandro.aguado_martin@nokia.com>
";
description
"This YANG module defines a generic network-oriented model "This YANG module defines a generic network-oriented model
for the management of Layer 3 VPNs in a Service Provider for the configuration of Layer 3 Virtual Private Networks.
backbone network. Copyright (c) 2020 IETF Trust and the persons identified as
Copyright (c) 2019 IETF Trust and the persons identified as authors of the code. All rights reserved.
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to
the license terms contained in, the Simplified BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX Redistribution and use in source and binary forms, with or
(https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself without modification, is permitted pursuant to, and subject to
for full legal notices. the license terms contained in, the Simplified BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(https://trustee.ietf.org/license-info).
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL This version of this YANG module is part of RFC XXXX
NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself
'MAY', and 'OPTIONAL' in this document are to be interpreted as for full legal notices.";
described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
they appear in all capitals, as shown here.";
revision 2019-11-17 { revision 2020-03-09 {
description description
"Network centric hierarchy. Customer unused parameters prunned. "Initial revision.";
Site removal"; reference
reference "RFC XXXX: A Layer 3 VPN Network YANG Model";
"draft-ietf-opsawg-l3sm-l3nm-01"; }
}
revision 2019-09-13 {
description
"Initial document. The document as a whole is based on L3SM
module, defined in RFC 8299, modified to fit the requirements
of the platforms at the network layer.";
reference
"RFC 8049.";
}
/* Features */ /* Features */
feature cloud-access {
description feature msdp {
"Allows the VPN to connect to a CSP."; description
} "This feature indicates that msdp capabilities
feature multicast { are supported by the VPN.";
description
"Enables multicast capabilities in a VPN.";
}
feature ipv4 {
description
"Enables IPv4 support in a VPN.";
}
feature ipv6 {
description
"Enables IPv6 support in a VPN.";
}
feature lan-tag {
description
"Enables LAN Tag support in a VPN Policy filter.";
}
feature carrierscarrier {
description
"Enables support of CsC.";
}
feature extranet-vpn {
description
"Enables support of extranet VPNs.";
}
feature encryption {
description
"Enables support of encryption.";
}
feature qos {
description
"Enables support of classes of services.";
}
feature qos-custom {
description
"Enables support of the custom QoS profile.";
}
feature rtg-bgp {
description
"Enables support of the BGP routing protocol.";
}
feature rtg-rip {
description
"Enables support of the RIP routing protocol.";
} }
feature rtg-ospf {
description feature rtg-isis {
"Enables support of the OSPF routing protocol."; description
"This features indicates the support of the ISIS
routing protocol.";
} }
feature rtg-ospf-sham-link { feature rtg-ospf-sham-link {
description description
"Enables support of OSPF sham links."; "This feature indicates the support of OSPF sham links.";
}
feature rtg-vrrp {
description
"Enables support of the VRRP routing protocol.";
}
feature fast-reroute {
description
"Enables support of Fast Reroute.";
}
feature bfd {
description
"Enables support of BFD.";
}
feature bearer-reference {
description
"Enables support of the 'bearer-reference' access constraint.";
}
feature target-sites {
description
"Enables support of the 'target-sites' match flow parameter.";
} }
feature input-bw {
description feature input-bw {
"Enables support of the 'input-bw' limit."; description
"This feature indicates the support of
the 'input-bw' limit.";
} }
feature dot1q {
description feature dot1q {
"Enables support of the 'dot1q' encapsulation."; description
"This feature indicates the support of
the 'dot1q' encapsulation.";
} }
feature qinq {
description feature qinq {
"Enables support of the 'qinq' encapsulation."; description
"This feature indicates the support of
the 'qinq' encapsulation.";
} }
feature qinany {
description feature qinany {
"Enables support of the 'qinany' encapsulation."; description
"This feature indicates the support of
the 'qinany' encapsulation.";
} }
feature vxlan {
description feature vxlan {
"Enables support of the 'vxlan' encapsulation."; description
"This feature indicates the support of
the 'vxlan' encapsulation.";
} }
/* Typedefs */ /* Typedefs */
typedef svc-id {
type string; typedef protocols-type {
description type enumeration {
"Defines a type of service component identifier."; enum GRE {
} value 0;
typedef template-id { description
type string; "Transport based on GRE.";
description }
"Defines a type of service template identifier."; enum LDP {
} value 1;
typedef address-family { description
type enumeration { "Transport based on LDP.";
enum ipv4 { }
description enum BGP {
"IPv4 address family."; value 2;
} description
enum ipv6 { "Transport based on BGP.";
description }
"IPv6 address family."; enum SR {
value 3;
description
"Transport based on Segment Routing (SR)";
}
enum SR-TE {
value 4;
description
"Transport based on SR for Traffic Engineering.";
}
enum RSVP-TE {
value 5;
description
"Transport based on RSVP for Traffic Engineering";
}
enum unknown {
value 6;
description
"Transport UNKNOWN";
}
} }
enum ipv4/ipv6 { description
description "These attributes are used to identify underlying
"IPv4/IPv6 address family."; protocols when activating an L3VPN service.";
}
typedef area-address {
type string {
pattern '[0-9A-Fa-f]{2}(\.[0-9A-Fa-f]{4}){0,6}';
} }
} description
description "This type defines the area address format.";
"Defines a type for the address family.";
} }
typedef ie-type { typedef isis-level {
type enumeration { type enumeration {
enum "import" { enum level1 {
value 0; value 0;
description "Import routing profile."; description
"ISIS level 1";
} }
enum "export" { enum level2 {
value 1; value 1;
description "Export routing profile"; description
"ISIS level 2";
} }
enum "both" { enum level1-2 {
value 2; value 2;
description "Import/Export routing profile"; description
"ISIS level 1 and 2";
} }
} }
description description
"Defines Import-Export routing profiles. "Defines the ISIS level for interface and system.";
Those are able to be reused between vpn-nodes"; }
}
typedef operational-type { typedef ie-type {
type enumeration { type enumeration {
enum "up" { enum import {
value 0; value 0;
description "Operational status UP."; description
"Import a routing profile.";
} }
enum "down" { enum export {
value 1; value 1;
description "Operational status DOWN"; description
"Export a routing profile.";
} }
enum "unknown" { enum both {
value 2; value 2;
description "Operational status UNKNOWN"; description
"Import/Export a routing profile.";
} }
} }
description description
"This is a read-only attribute used to determine the "Defines Import-Export routing profiles.
status of a particular element"; Those profiles can be reused between VPN nodes.";
}
/* Identities */
identity site-network-access-type {
description
"Base identity for site-network-access type.";
}
identity point-to-point {
base site-network-access-type;
description
"Identity for point-to-point connection.";
}
/* Extension */
identity pseudowire {
base site-network-access-type;
description
"Identity for pseudowire connection.";
}
/* End of Extension */
identity multipoint {
base site-network-access-type;
description
"Identity for multipoint connection.
Example: Ethernet broadcast segment.";
}
identity customer-application {
description
"Base identity for customer application.";
}
identity web {
base customer-application;
description
"Identity for Web application (e.g., HTTP, HTTPS).";
}
identity mail {
base customer-application;
description
"Identity for mail application.";
}
identity file-transfer {
base customer-application;
description
"Identity for file transfer application (e.g., FTP, SFTP).";
}
identity database {
base customer-application;
description
"Identity for database application.";
}
identity social {
base customer-application;
description
"Identity for social-network application.";
}
identity games {
base customer-application;
description
"Identity for gaming application.";
}
identity p2p {
base customer-application;
description
"Identity for peer-to-peer application.";
}
identity network-management {
base customer-application;
description
"Identity for management application
(e.g., Telnet, syslog, SNMP).";
}
identity voice {
base customer-application;
description
"Identity for voice application.";
}
identity video {
base customer-application;
description
"Identity for video conference application.";
}
identity embb {
base customer-application;
description
"Identity for an enhanced Mobile Broadband (eMBB)
application. Note that an eMBB application demands
network performance with a wide variety of
characteristics, such as data rate, latency,
loss rate, reliability, and many other parameters.";
}
identity urllc {
base customer-application;
description
"Identity for an Ultra-Reliable and Low Latency
Communications (URLLC) application. Note that a
URLLC application demands network performance
with a wide variety of characteristics, such as latency,
reliability, and many other parameters.";
} }
identity mmtc {
base customer-application; typedef operational-type {
type enumeration {
enum up {
value 0;
description
"Operational status UP/Enabled.";
}
enum down {
value 1;
description
"Operational status DOWN/Disabled.";
}
enum unknown {
value 2;
description
"Operational status UNKNOWN.";
}
}
description description
"Identity for a massive Machine Type "This attribute is used to determine the
Communications (mMTC) application. Note that an status of a particular element.";
mMTC application demands network performance
with a wide variety of characteristics, such as data
rate, latency, loss rate, reliability, and many
other parameters.";
}
identity address-allocation-type {
description
"Base identity for address-allocation-type for PE-CE link.";
}
identity provider-dhcp {
base address-allocation-type;
description
"Provider network provides DHCP service to customer.";
}
identity provider-dhcp-relay {
base address-allocation-type;
description
"Provider network provides DHCP relay service to customer.";
}
identity provider-dhcp-slaac {
base address-allocation-type;
description
"Provider network provides DHCP service to customer,
as well as SLAAC.";
}
identity static-address {
base address-allocation-type;
description
"Provider-to-customer addressing is static.";
}
identity slaac {
base address-allocation-type;
description
"Use IPv6 SLAAC.";
}
identity site-role {
description
"Base identity for site type.";
}
identity any-to-any-role {
base site-role;
description
"Site in an any-to-any IP VPN.";
}
identity spoke-role {
base site-role;
description
"Spoke site in a Hub-and-Spoke IP VPN.";
} }
identity hub-role {
base site-role;
description
"Hub site in a Hub-and-Spoke IP VPN.";
} /* Identities */
identity vpn-topology { identity vpn-topology {
description description
"Base identity for VPN topology."; "Base identity for VPN topology.";
} }
identity any-to-any { identity any-to-any {
base vpn-topology; base vpn-topology;
description description
"Identity for any-to-any VPN topology."; "Identity for any-to-any VPN topology.";
} }
identity hub-spoke { identity hub-spoke {
base vpn-topology; base vpn-topology;
description description
"Identity for Hub-and-Spoke VPN topology."; "Identity for Hub-and-Spoke VPN topology.";
} }
identity hub-spoke-disjoint { identity hub-spoke-disjoint {
base vpn-topology; base vpn-topology;
description description
"Identity for Hub-and-Spoke VPN topology "Identity for Hub-and-Spoke VPN topology
where Hubs cannot communicate with each other."; where Hubs cannot communicate with each other.";
}
identity multicast-tree-type {
description
"Base identity for multicast tree type.";
}
identity ssm-tree-type {
base multicast-tree-type;
description
"Identity for SSM tree type.";
}
identity asm-tree-type {
base multicast-tree-type;
description
"Identity for ASM tree type.";
}
identity bidir-tree-type {
base multicast-tree-type;
description
"Identity for bidirectional tree type.";
}
identity multicast-rp-discovery-type {
description
"Base identity for RP discovery type.";
} }
identity auto-rp {
base multicast-rp-discovery-type;
description
"Base identity for Auto-RP discovery type.";
identity custom {
base vpn-topology;
description
"Identity for CUSTOM VPN topology
where Hubs can act as Spoke for certain part of
the network or Spokes as Hubs.";
} }
identity static-rp {
base multicast-rp-discovery-type; identity isis {
description base l3vpn-svc:routing-protocol-type;
"Base identity for static type."; description
"Identity for ISIS protocol type.";
} }
identity bsr-rp {
base multicast-rp-discovery-type; identity pseudowire {
description base l3vpn-svc:site-network-access-type;
"Base identity for BSR discovery type."; description
"Identity for pseudowire connections.";
} }
identity routing-protocol-type {
description identity loopback {
"Base identity for routing protocol type."; base l3vpn-svc:site-network-access-type;
description
"Identity for loopback connections.";
} }
identity ospf {
base routing-protocol-type; identity encapsulation-type {
description description
"Identity for OSPF protocol type."; "Identity for the encapsulation type.";
} }
identity bgp {
base routing-protocol-type; identity untagged-int {
description base encapsulation-type;
"Identity for BGP protocol type."; description
"Identity for Ethernet type.";
} }
identity static {
base routing-protocol-type; identity tagged-int {
description base encapsulation-type;
"Identity for static routing protocol type."; description
"Identity for the VLAN type.";
} }
identity rip {
base routing-protocol-type; identity eth-inf-type {
description description
"Identity for RIP protocol type."; "Identity of the Ethernet interface type.";
} }
identity vrrp {
base routing-protocol-type; identity tagged {
description base eth-inf-type;
"Identity for VRRP protocol type. description
This is to be used when LANs are directly connected "Identity of the tagged interface type.";
to PE routers.";
} }
identity direct {
base routing-protocol-type; identity untagged {
description base eth-inf-type;
"Identity for direct protocol type."; description
"Identity of the untagged interface type.";
} }
identity protocol-type {
description identity lag {
"Base identity for protocol field type."; base eth-inf-type;
description
"Identity of the LAG interface type.";
} }
identity tcp { identity bearer-inf-type {
base protocol-type; description
description "Identity for the bearer interface type.";
"TCP protocol type.";
} }
identity udp {
base protocol-type; identity port-id {
description base bearer-inf-type;
"UDP protocol type."; description
"Identity for the priority-tagged interface.";
} }
identity icmp { identity lag-id {
base protocol-type; base bearer-inf-type;
description description
"ICMP protocol type."; "Identity for the priority-tagged interface.";
} }
identity icmp6 {
base protocol-type; identity tagged-inf-type {
description description
"ICMPv6 protocol type."; "Identity for the tagged interface type.";
} }
identity gre {
base protocol-type; identity priority-tagged {
description base tagged-inf-type;
"GRE protocol type."; description
"Identity for the priority-tagged interface.";
} }
identity ipip {
base protocol-type; identity qinq {
description base tagged-inf-type;
"IP-in-IP protocol type."; description
"Identity for the QinQ tagged interface.";
} }
identity hop-by-hop {
base protocol-type; identity dot1q {
description base tagged-inf-type;
"Hop-by-Hop IPv6 header type."; description
"Identity for the dot1Q VLAN tagged interface.";
} }
identity routing {
base protocol-type; identity qinany {
description base tagged-inf-type;
"Routing IPv6 header type."; description
"Identity for the QinAny tagged interface.";
} }
identity esp {
base protocol-type;
description
"ESP header type.";
identity vxlan {
base tagged-inf-type;
description
"Identity for the VXLAN tagged interface.";
} }
identity ah {
base protocol-type; identity tag-type {
description description
"AH header type."; "Base identity from which all tag types are derived.";
} }
identity vpn-policy-filter-type {
description identity c-vlan {
"Base identity for VPN Policy filter type."; base tag-type;
description
"A CVLAN tag, normally using the 0x8100 Ethertype.";
} }
identity ipv4 {
base vpn-policy-filter-type; identity s-vlan {
base tag-type;
description description
"Identity for IPv4 Prefix filter type."; "An SVLAN tag.";
} }
identity ipv6 {
base vpn-policy-filter-type; identity c-s-vlan {
base tag-type;
description description
"Identity for IPv6 Prefix filter type."; "Using both a CVLAN tag and an SVLAN tag.";
} }
identity lan {
base vpn-policy-filter-type; identity vxlan-peer-mode {
description description
"Identity for LAN Tag filter type."; "Base identity for the VXLAN peer mode.";
} }
identity qos-profile-direction { identity static-mode {
description base vxlan-peer-mode;
"Base identity for QoS profile direction."; description
"Identity for VXLAN access in the static mode.";
} }
identity site-to-wan { identity bgp-mode {
base qos-profile-direction; base vxlan-peer-mode;
description description
"Identity for Site-to-WAN direction."; "Identity for VXLAN access using BGP EVPN.";
} }
identity wan-to-site {
base qos-profile-direction; identity bw-direction {
description description
"Identity for WAN-to-Site direction."; "Identity for the bandwidth direction.";
} }
identity both { identity input-bw {
base qos-profile-direction; base bw-direction;
description description
"Identity for both WAN-to-Site direction "Identity for the input bandwidth.";
and Site-to-WAN direction.";
} }
/* Extended Identities */
identity encapsulation-type {
description
"Identity for the encapsulation type.";
}
identity untagged-int {
base encapsulation-type;
description
"Identity for Ethernet type.";
}
identity tagged-int {
base encapsulation-type;
description
"Identity for the VLAN type.";
}
identity eth-inf-type {
description
"Identity of the Ethernet interface type.";
}
identity tagged {
base eth-inf-type;
description
"Identity of the tagged interface type.";
}
identity untagged {
base eth-inf-type;
description
"Identity of the untagged interface type.";
}
identity lag {
base eth-inf-type;
description
"Identity of the LAG interface type.";
}
identity bearer-inf-type {
description
"Identity for the bearer interface type.";
}
identity port-id {
base bearer-inf-type;
description
"Identity for the priority-tagged interface.";
}
identity lag-id {
base bearer-inf-type;
description
"Identity for the priority-tagged interface.";
}
identity tagged-inf-type {
description
"Identity for the tagged interface type.";
}
identity priority-tagged {
base tagged-inf-type;
description
"Identity for the priority-tagged interface.";
}
identity qinq {
base tagged-inf-type;
description
"Identity for the QinQ tagged interface.";
}
identity dot1q {
base tagged-inf-type;
description
"Identity for the dot1Q VLAN tagged interface.";
}
identity qinany {
base tagged-inf-type;
description
"Identity for the QinAny tagged interface.";
}
identity vxlan {
base tagged-inf-type;
description
"Identity for the VXLAN tagged interface.";
}
identity tag-type {
description
"Base identity from which all tag types are derived.";
}
identity c-vlan {
base tag-type;
description
"A CVLAN tag, normally using the 0x8100 Ethertype.";
}
identity s-vlan {
base tag-type;
description
"An SVLAN tag.";
}
identity c-s-vlan {
base tag-type;
description
"Using both a CVLAN tag and an SVLAN tag.";
}
identity vxlan-peer-mode { identity output-bw {
description base bw-direction;
"Base identity for the VXLAN peer mode."; description
} "Identity for the output bandwidth.";
}
identity static-mode {
base vxlan-peer-mode;
description
"Identity for VXLAN access in the static mode.";
}
identity bgp-mode {
base vxlan-peer-mode;
description
"Identity for VXLAN access by BGP EVPN learning.";
}
identity bw-direction {
description
"Identity for the bandwidth direction.";
}
identity input-bw {
base bw-direction;
description
"Identity for the input bandwidth.";
}
identity output-bw {
base bw-direction;
description
"Identity for the output bandwidth.";
}
identity bw-type { identity bw-type {
description description
"Identity of the bandwidth type."; "Identity of the bandwidth type.";
} }
identity bw-per-cos { identity bw-per-cos {
base bw-type; base bw-type;
description description
"Bandwidth is per CoS."; "Bandwidth is per Class of Service (CoS).";
} }
identity bw-per-port { identity bw-per-port {
base bw-type; base bw-type;
description description
"Bandwidth is per site network access."; "Bandwidth is per site network access.";
} }
identity bw-per-site { identity bw-per-site {
base bw-type; base bw-type;
description description
"Bandwidth is per site. It is applicable to "Bandwidth is per site. It is applicable to
all the site network accesses within the site."; all the site network accesses within a site.";
} }
identity bw-per-svc { identity bw-per-svc {
base bw-type; base bw-type;
description description
"Bandwidth is per VPN service."; "Bandwidth is per VPN service.";
} }
/* Groupings */ /* Groupings */
grouping multicast-rp-group-cfg {
choice group-format { grouping svc-transport-encapsulation {
mandatory true; container underlay-transport {
case singleaddress { leaf type {
leaf group-address { type protocols-type;
type inet:ip-address; description
description "Protocols used to deliver an L3VPN service.";
"A single multicast group address."; }
}
}
case startend {
leaf group-start {
type inet:ip-address;
description
"The first multicast group address in
the multicast group address range.";
}
leaf group-end {
type inet:ip-address;
description description
"The last multicast group address in "";
the multicast group address range.";
}
} }
description description
"Choice for multicast group format."; "";
}
description
"This grouping defines multicast group or
multicast groups for RP-to-group mapping.";
} }
grouping vpn-service-multicast {
container multicast {
if-feature multicast;
leaf enabled {
type boolean;
default false;
description
"Enables multicast.";
}
container customer-tree-flavors {
leaf-list tree-flavor {
type identityref {
base multicast-tree-type;
}
description
"Type of tree to be used.";
}
description
"Type of trees used by customer.";
}
container rp {
container rp-group-mappings {
list rp-group-mapping {
key id;
leaf id {
type uint16;
description
"Unique identifier for the mapping.";
} grouping multicast-rp-group-cfg {
container provider-managed { choice group-format {
leaf enabled { mandatory true;
type boolean; case group-prefix {
default false; leaf group-address {
description type inet:ip-prefix;
"Set to true if the Rendezvous Point (RP) description
must be a provider-managed node. Set to false "A single multicast group prefix.";
if it is a customer-managed node.";
} }
leaf rp-redundancy { }
type boolean; case startend {
default false; leaf group-start {
description type inet:ip-address;
"If true, a redundancy mechanism for the RP description
is required."; "The first multicast group address in
the multicast group address range.";
} }
leaf optimal-traffic-delivery { leaf group-end {
type boolean; type inet:ip-address;
default false; description
description "The last multicast group address in
"If true, the SP must ensure that the multicast group address range.";
traffic uses an optimal path. An SP may use
Anycast RP or RP-tree-to-SPT switchover
architectures.";
} }
}
description
"Choice for multicast group format.";
}
description
"This grouping defines multicast group or
multicast groups for RP-to-group mapping.";
}
grouping vpn-service-multicast {
container multicast {
if-feature "l3vpn-svc:multicast";
leaf enabled {
type boolean;
default "false";
description description
"Parameters for a provider-managed RP."; "Enables multicast.";
} }
leaf rp-address { leaf-list tree-flavor {
when "../provider-managed/enabled = 'false'" { type identityref {
description base l3vpn-svc:multicast-tree-type;
"Relevant when the RP is not provider-managed.";
} }
type inet:ip-address;
mandatory true;
description description
"Defines the address of the RP. "Type of tree to be used.";
Used if the RP is customer-managed."; }
} container rp {
container groups { container rp-group-mappings {
list group { list rp-group-mapping {
key id; key "id";
leaf id { leaf id {
type uint16; type uint16;
description
"Unique identifier for the mapping.";
}
container provider-managed {
leaf enabled {
type boolean;
default "false";
description
"Set to true if the Rendezvous Point (RP)
must be a provider-managed node. Set to false
if it is a customer-managed node.";
}
leaf rp-redundancy {
type boolean;
default "false";
description
"If true, a redundancy mechanism for the RP
is required.";
}
leaf optimal-traffic-delivery {
type boolean;
default "false";
description
"If true, the SP must ensure that
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
RP redundancy is
enabled and delivery through
optimal path is activated.";
}
leaf local-address {
type inet:ip-address;
description
"IP local address for PIM RP.
Usually, it corresponds to router
ID or primary address";
}
leaf-list rp-set-address {
type inet:ip-address;
description
"Address other RP routers
that share the same RP IP address.";
}
description
"PIM Anycast-RP parameters.";
}
description
"Parameters for a provider-managed RP.";
}
leaf rp-address {
when "../provider-managed/enabled = 'false'" {
description
"Relevant when the RP is not provider-managed.";
}
type inet:ip-address;
mandatory true;
description
"Defines the address of the RP.
Used if the RP is customer-managed.";
}
container groups {
list group {
key "id";
leaf id {
type uint16;
description
"Identifier for the group.";
}
uses multicast-rp-group-cfg;
description
"List of multicast groups.";
}
description
"Multicast groups associated with the RP.";
}
description
"List of RP-to-group mappings.";
}
description description
"Identifier for the group."; "RP-to-group mappings parameters.";
} }
uses multicast-rp-group-cfg; container rp-discovery {
description leaf rp-discovery-type {
"List of multicast groups."; type identityref {
base l3vpn-svc:multicast-rp-discovery-type;
}
default "l3vpn-svc:static-rp";
description
"Type of RP discovery used.";
}
container bsr-candidates {
when "derived-from-or-self(../rp-discovery-type, "
+ "'l3vpn-ntw:bsr-rp')" {
description
"Only applicable if discovery type
is BSR-RP.";
}
leaf-list bsr-candidate-address {
type inet:ip-address;
description
"Address of candidate Bootstrap Router (BSR).";
}
description
"Container for List of Customer
BSR candidate's addresses.";
}
description
"RP discovery parameters.";
} }
description description
"Multicast groups associated with the RP."; "RP parameters.";
}
description
"List of RP-to-group mappings.";
} }
description container msdp {
"RP-to-group mappings parameters."; if-feature "msdp";
} leaf enabled {
container rp-discovery { type boolean;
leaf rp-discovery-type { default "false";
type identityref { description
base multicast-rp-discovery-type; "If true, Multicast Source Discovery Protocol (MSDP)
protocol is activated.";
}
leaf peer {
type inet:ip-address;
description
"IP address of the MSDP peer.";
}
leaf local-address {
type inet:ip-address;
description
"IP address of the local end. This local address
must be configured on the node.";
} }
default static-rp;
description
"Type of RP discovery used.";
}
container bsr-candidates {
when "derived-from-or-self(../rp-discovery-type, "+
"'l3vpn-ntw:bsr-rp')" {
description description
"Only applicable if discovery type "MSDP parameters.";
is BSR-RP.";
}
leaf-list bsr-candidate-address {
type inet:ip-address;
description
"Address of BSR candidate.";
}
description
"Container for List of Customer
BSR candidate's addresses.";
} }
description description
"RP discovery parameters."; "Multicast global parameters for the VPN service.";
}
description
"RP parameters.";
} }
description description
"Multicast global parameters for the VPN service."; "Grouping for multicast VPN definition.";
}
description
"Grouping for multicast VPN definition.";
} }
grouping vpn-service-mpls { grouping vpn-service-mpls {
leaf carrierscarrier { leaf carrierscarrier {
if-feature carrierscarrier; if-feature "l3vpn-svc:carrierscarrier";
type boolean; type boolean;
default false; default "false";
description
"The VPN is using CsC, and so MPLS is required.";
}
description
"Grouping for MPLS CsC definition.";
}
grouping operational-requirements {
leaf requested-site-start {
type yang:date-and-time;
description
"Optional leaf indicating requested date and
time when the service at a particular site is
expected to start.";
}
leaf requested-site-stop {
type yang:date-and-time;
description description
"Optional leaf indicating requested date and "The VPN is using CsC, and so MPLS is required.";
time when the service at a particular site is }
expected to stop."; description
} "Grouping for MPLS Carriers'Carrier definition.";
description
"This grouping defines some operational
parameters.";
} }
grouping operational-requirements-ops {
leaf actual-site-start {
type yang:date-and-time;
config false;
description
"Optional leaf indicating actual date and
time when the service at a particular site
actually started.";
}
leaf actual-site-stop {
type yang:date-and-time;
config false;
description
"Optional leaf indicating actual date and
time when the service at a particular site
actually stopped.";
} grouping operational-requirements {
description leaf requested-site-start {
"This grouping defines some operational type yang:date-and-time;
parameters.";
}
grouping flow-definition {
container match-flow {
leaf dscp {
type inet:dscp;
description description
"DSCP value."; "Optional leaf indicating requested date and
} time when the service at a particular site is
leaf dot1p { expected to start.";
type uint8 {
range "0..7";
}
description
"802.1p matching.";
} }
leaf ipv4-src-prefix { leaf requested-site-stop {
type inet:ipv4-prefix; type yang:date-and-time;
description description
"Match on IPv4 src address."; "Optional leaf indicating requested date and
time when the service at a particular site is
expected to stop.";
} }
leaf ipv6-src-prefix { description
type inet:ipv6-prefix; "This grouping defines some operational
parameters.";
}
grouping status-timestamp {
leaf status {
type operational-type;
description description
"Match on IPv6 src address."; "Operations status";
} }
leaf ipv4-dst-prefix { leaf timestamp {
type inet:ipv4-prefix; type yang:date-and-time;
description description
"Match on IPv4 dst address."; "Indicates the actual date and time when
} the service actually started (UP) or
leaf ipv6-dst-prefix { stopped (DOWN).";
type inet:ipv6-prefix;
description
"Match on IPv6 dst address.";
} }
leaf l4-src-port { description
type inet:port-number; "This grouping defines some operational
must "current() < ../l4-src-port-range/lower-port or "+ parameters for the service.";
"current() > ../l4-src-port-range/upper-port" { }
description
"If l4-src-port and l4-src-port-range/lower-port and grouping service-status {
upper-port are set at the same time, l4-src-port container service-status {
should not overlap with l4-src-port-range."; container admin {
uses status-timestamp;
description
"Administrative service status.";
} }
description container ops {
"Match on Layer 4 src port."; config false;
} uses status-timestamp;
leaf-list target-sites { description
if-feature target-sites; "Operational service status.";
type svc-id;
description
"Identify a site as traffic destination.";
}
container l4-src-port-range {
leaf lower-port {
type inet:port-number;
description
"Lower boundary for port.";
}
leaf upper-port {
type inet:port-number;
must ". >= ../lower-port" {
description
"Upper boundary for port. If it
exists, the upper boundary must be
higher than the lower boundary.";
} }
description description
"Upper boundary for port."; "Service status.";
}
description
"Match on Layer 4 src port range. When
only the lower-port is present, it represents
a single port. When both the lower-port and
upper-port are specified, it implies
a range inclusive of both values.";
} }
leaf l4-dst-port { description
type inet:port-number; "Service status grouping. Reused in
must "current() < ../l4-dst-port-range/lower-port or "+ vpn-node and vpn-network-access.";
"current() > ../l4-dst-port-range/upper-port" { }
description
"If l4-dst-port and l4-dst-port-range/lower-port grouping site-service-basic {
and upper-port are set at the same time, leaf svc-input-bandwidth {
l4-dst-port should not overlap with type uint64;
l4-src-port-range."; units "bps";
} mandatory true;
description description
"Match on Layer 4 dst port."; "From the customer site's perspective, the service
input bandwidth of the connection or download
bandwidth from the SP to the site.";
} }
container l4-dst-port-range { leaf svc-output-bandwidth {
leaf lower-port { type uint64;
type inet:port-number; units "bps";
description mandatory true;
"Lower boundary for port.";
}
leaf upper-port {
type inet:port-number;
must ". >= ../lower-port" {
description
"Upper boundary must be
higher than lower boundary.";
}
description description
"Upper boundary for port. If it exists, "From the customer site's perspective, the service
upper boundary must be higher than lower output bandwidth of the connection or upload
boundary."; bandwidth from the site to the SP.";
}
description
"Match on Layer 4 dst port range. When only
lower-port is present, it represents a single
port. When both lower-port and upper-port are
specified, it implies a range inclusive of both
values.";
} }
leaf protocol-field { leaf svc-mtu {
type union { type uint16;
type uint8; units "bytes";
type identityref { mandatory true;
base protocol-type; description
} "MTU at service level. If the service is IP,
} it refers to the IP MTU. If CsC is enabled,
description the requested 'svc-mtu' leaf will refer to the
"Match on IPv4 protocol or IPv6 Next Header field."; MPLS MTU and not to the IP MTU.";
} }
description description
"Describes flow-matching criteria."; "Defines basic service parameters for a site.";
}
description
"Flow definition based on criteria.";
} }
grouping site-service-basic {
leaf svc-input-bandwidth {
type uint64;
units bps;
mandatory true;
description
"From the customer site's perspective, the service
input bandwidth of the connection or download
bandwidth from the SP to the site.";
}
leaf svc-output-bandwidth {
type uint64;
units bps;
mandatory true;
description
"From the customer site's perspective, the service
output bandwidth of the connection or upload
bandwidth from the site to the SP.";
}
leaf svc-mtu {
type uint16;
units bytes;
mandatory true;
description
"MTU at service level. If the service is IP,
it refers to the IP MTU. If CsC is enabled,
the requested 'svc-mtu' leaf will refer to the
MPLS MTU and not to the IP MTU.";
}
description
"Defines basic service parameters for a site.";
}
grouping site-protection { grouping site-protection {
container traffic-protection { container traffic-protection {
if-feature fast-reroute; if-feature "l3vpn-svc:fast-reroute";
leaf enabled { leaf enabled {
type boolean; type boolean;
default false; default "false";
description
"Enables traffic protection of access link.";
}
description description
"Enables traffic protection of access link."; "Fast Reroute service parameters for the site.";
} }
description description
"Fast Reroute service parameters for the site."; "Defines protection service parameters for a site.";
}
description
"Defines protection service parameters for a site.";
} }
grouping site-service-mpls { grouping site-service-mpls {
container carrierscarrier { container carrierscarrier {
if-feature carrierscarrier; if-feature "l3vpn-svc:carrierscarrier";
leaf signalling-type { leaf signalling-type {
type enumeration { type enumeration {
enum ldp { enum ldp {
description description
"Use LDP as the signalling protocol "Use LDP as the signalling protocol
between the PE and the CE. In this case, between the PE and the CE. In this case,
an IGP routing protocol must also be activated."; an IGP routing protocol must also be activated.";
}
enum bgp {
description
"Use BGP as the signalling protocol
between the PE and the CE.
In this case, BGP must also be configured as
the routing protocol.";
reference
"RFC 8277: Using BGP to Bind MPLS Labels to
Address Prefixes";
}
}
default "bgp";
description
"MPLS signalling type.";
} }
enum bgp {
description description
"Use BGP (as per RFC 8277) as the signalling protocol "This container is used when the customer provides
between the PE and the CE. MPLS-based services. This is only used in the case
In this case, BGP must also be configured as of CsC (i.e., a customer builds an MPLS service using
the routing protocol."; an IP VPN to carry its traffic).";
}
}
default bgp;
description
"MPLS signalling type.";
} }
description description
"This container is used when the customer provides
MPLS-based services. This is only used in the case
of CsC (i.e., a customer builds an MPLS service using
an IP VPN to carry its traffic).";
}
description
"Defines MPLS service parameters for a site."; "Defines MPLS service parameters for a site.";
} }
grouping site-service-qos-profile {
container qos {
if-feature qos;
container qos-classification-policy {
list rule {
key id;
ordered-by user;
leaf id {
type string;
description
"A description identifying the
qos-classification-policy rule.";
}
choice match-type {
default match-flow;
case match-flow {
uses flow-definition;
}
case match-application {
leaf match-application {
type identityref {
base customer-application;
}
description
"Defines the application to match.";
}
} grouping ports {
description choice source-port {
"Choice for classification."; container source-port-range-or-operator {
} uses packet-fields:port-range-or-operator;
leaf target-class-id { description
type string; "Source port definition.";
description
"Identification of the class of service.
This identifier is internal to the administration.";
} }
description description
"List of marking rules."; "Choice of specifying the source port or referring to
} a group of source port numbers.";
description
"Configuration of the traffic classification policy.";
} }
container qos-profile { choice destination-port {
choice qos-profile { container destination-port-range-or-operator {
description uses packet-fields:port-range-or-operator;
"Choice for QoS profile.
Can be standard profile or customized profile.";
case standard {
description
"Standard QoS profile.";
leaf profile {
type leafref {
path "/l3vpn-ntw/vpn-profiles/valid-provider-identifiers"+
"/qos-profile-identifier/id";
}
description description
"QoS profile to be used."; "Destination port definition.";
}
leaf direction {
type identityref {
base qos-profile-direction;}
default both;
description
"The direction to which the QoS profile
is applied.";
}
} }
case custom { description
description "Choice of specifying a destination port or referring
"Customized QoS profile."; to a group of destination port numbers.";
container classes { }
if-feature qos-custom; description
list class { "Choice of specifying a source or destination port numbers.";
key class-id; }
leaf class-id {
type string;
description
"Identification of the class of service.
This identifier is internal to the
administration.";
}
leaf direction {
type identityref {
base qos-profile-direction;
}
default both;
description
"The direction to which the QoS profile
is applied.";
}
leaf rate-limit {
type decimal64 {
fraction-digits 5;
range "0..100";
}
units percent;
description
"To be used if the class must be rate-limited.
Expressed as percentage of the service
bandwidth.";
}
container latency { grouping site-service-qos-profile {
choice flavor { container qos {
case lowest { if-feature "l3vpn-svc:qos";
leaf use-lowest-latency { container qos-classification-policy {
type empty; list rule {
description key "id";
"The traffic class should use the path with the ordered-by user;
lowest latency."; leaf id {
type string;
description
"A description identifying the
qos-classification-policy rule.";
}
choice match-type {
default "match-flow";
case match-flow {
//uses l3vpn-svc:flow-definition;
choice l3 {
container ipv4 {
uses packet-fields:acl-ip-header-fields;
uses packet-fields:acl-ipv4-header-fields;
description
"Rule set that matches IPv4 header.";
}
container ipv6 {
uses packet-fields:acl-ip-header-fields;
uses packet-fields:acl-ipv6-header-fields;
description
"Rule set that matches IPv6 header.";
}
description
"Either IPv4 or IPv6.";
}
choice l4 {
container tcp {
uses packet-fields:acl-tcp-header-fields;
uses ports;
description
"Rule set that matches TCP header.";
}
container udp {
uses packet-fields:acl-udp-header-fields;
uses ports;
description
"Rule set that matches UDP header.";
}
description
"Can be TCP or UDP";
}
} }
} case match-application {
case boundary { leaf match-application {
leaf jitter-boundary { type identityref {
type uint16; base l3vpn-svc:customer-application;
units msec; }
default 400; description
description "Defines the application to match.";
"The traffic class should use a path with a }
defined maximum latency.";
} }
} description
description "Choice for classification.";
"Latency constraint on the traffic class."; }
leaf target-class-id {
type string;
description
"Identification of the class of service.
This identifier is internal to the administration.";
} }
description description
"Latency constraint on the traffic class."; "List of marking rules.";
} }
container jitter { description
choice flavor { "Configuration of the traffic classification policy.";
case lowest { }
leaf use-lowest-jitter { container qos-profile {
type empty; choice qos-profile {
description
"Choice for QoS profile.
Can be standard profile or customized profile.";
case standard {
description
"Standard QoS profile.";
leaf profile {
type leafref {
path "/l3vpn-ntw/vpn-profiles/"
+ "valid-provider-identifiers"
+ "/qos-profile-identifier/id";
}
description description
"The traffic class should use the path with the "QoS profile to be used.";
lowest jitter.";
} }
} leaf direction {
case boundary { type identityref {
leaf latency-boundary { base l3vpn-svc:qos-profile-direction;
type uint32; }
units usec; default "l3vpn-svc:both";
default 40000;
description description
"The traffic class should use a path with a "The direction to which the QoS profile
defined maximum jitter."; is applied.";
} }
}
description
"Jitter constraint on the traffic class.";
} }
description case custom {
"Jitter constraint on the traffic class.";
}
container bandwidth {
leaf guaranteed-bw-percent {
type decimal64 {
fraction-digits 5;
range "0..100";
}
units percent;
mandatory true;
description
"To be used to define the guaranteed bandwidth
as a percentage of the available service bandwidth.";
}
leaf end-to-end {
type empty;
description description
"Used if the bandwidth reservation "Customized QoS profile.";
must be done on the MPLS network too."; container classes {
if-feature "l3vpn-svc:qos-custom";
list class {
key "class-id";
leaf class-id {
type string;
description
"Identification of the class of service.
This identifier is internal to the
administration.";
}
leaf direction {
type identityref {
base l3vpn-svc:qos-profile-direction;
}
default "l3vpn-svc:both";
description
"The direction to which the QoS profile
is applied.";
}
leaf rate-limit {
type decimal64 {
fraction-digits 5;
range "0..100";
}
units "percent";
description
"To be used if the class must be rate-limited.
Expressed as percentage of the service
bandwidth.";
}
container latency {
choice flavor {
case lowest {
leaf use-lowest-latency {
type empty;
description
"The traffic class should
use the path with the
lowest latency.";
}
}
case boundary {
leaf jitter-boundary {
type uint16;
units "msec";
default "400";
description
"The traffic class
should use a path with a
defined maximum latency.";
}
}
description
"Latency constraint
on the traffic class.";
}
description
"Latency constraint
on the traffic class.";
}
container jitter {
choice flavor {
case lowest {
leaf use-lowest-jitter {
type empty;
description
"The traffic class
should use the path with the
lowest jitter.";
}
}
case boundary {
leaf latency-boundary {
type uint32;
units "usec";
default "40000";
description
"The traffic class
should use a path with a
defined maximum jitter.";
}
}
description
"Jitter constraint on the traffic class.";
}
description
"Jitter constraint on the traffic class.";
}
container bandwidth {
leaf guaranteed-bw-percent {
type decimal64 {
fraction-digits 5;
range "0..100";
}
units "percent";
mandatory true;
description
"To be used to define the guaranteed bandwidth
as a percentage of the available service
bandwidth.";
}
leaf end-to-end {
type empty;
description
"Used if the bandwidth reservation
must be done on the MPLS network too.";
}
description
"Bandwidth constraint on the traffic class.";
}
description
"List of classes of services.";
}
description
"Container for list of classes of services.";
}
} }
description
"Bandwidth constraint on the traffic class.";
}
description
"List of classes of services.";
} }
description description
"Container for list of classes of services."; "QoS profile configuration.";
}
} }
} description
description "QoS configuration.";
"QoS profile configuration.";
} }
description description
"QoS configuration."; "This grouping defines QoS parameters for a site.";
}
description
"This grouping defines QoS parameters for a site.";
} }
grouping site-security-authentication { grouping site-security-authentication {
container authentication { container authentication {
description description
"Authentication parameters."; "Authentication parameters.";
} }
description description
"This grouping defines authentication parameters for a site."; "This grouping defines authentication parameters
for a site.";
} }
grouping site-security-encryption { grouping site-security-encryption {
container encryption { container encryption {
if-feature encryption; if-feature "l3vpn-svc:encryption";
leaf enabled { leaf enabled {
type boolean; type boolean;
default false; default "false";
description description
"If true, traffic encryption on the connection is required."; "If true, traffic encryption on the connection
} is required. It is disabled, otherwise.";
}
leaf layer { leaf layer {
when "../enabled = 'true'" { when "../enabled = 'true'" {
description description
"Require a value for layer when enabled is true."; "Require a value for layer when enabled
is true.";
} }
type enumeration { type enumeration {
enum layer2 { enum layer2 {
description description
"Encryption will occur at Layer 2."; "Encryption will occur at Layer 2.";
} }
enum layer3 { enum layer3 {
description description
"Encryption will occur at Layer 3. "Encryption will occur at Layer 3.
For example, IPsec may be used when For example, IPsec may be used when
a customer requests Layer 3 encryption."; a customer requests Layer 3 encryption.";
}
} }
} description
description "Layer on which encryption is applied.";
"Layer on which encryption is applied."; }
} description
description "";
""; }
} container encryption-profile {
container encryption-profile { choice profile {
choice profile { case provider-profile {
case provider-profile { leaf profile-name {
leaf profile-name {
type leafref { type leafref {
path "/l3vpn-ntw/vpn-profiles/valid-provider-identifiers"+ path "/l3vpn-ntw/vpn-profiles/"
"/encryption-profile-identifier/id"; + "valid-provider-identifiers"
+ "/encryption-profile-identifier/id";
} }
description description
"Name of the SP profile to be applied."; "Name of the SP profile to be applied.";
} }
} }
case customer-profile { case customer-profile {
leaf algorithm { leaf algorithm {
type string; type string;
description description
"Encryption algorithm to be used."; "Encryption algorithm to be used.";
} }
}
description
"";
}
choice key-type {
default psk;
case psk {
leaf preshared-key {
type string;
description
"Pre-Shared Key (PSK) coming from the customer.";
}
}
description
"Choice of encryption profile.
The encryption profile can be the provider profile
or customer profile.";
}
description
"This grouping defines encryption parameters for a site.";
}
description
"";
}
grouping site-routing {
container routing-protocols {
list routing-protocol {
key id;
leaf id{
type string;
description
"";
}
leaf type {
type identityref {
base routing-protocol-type;
}
description
"Type of routing protocol.";
}
list routing-profiles {
key "id";
leaf id {
type leafref {
path "/l3vpn-ntw/vpn-profiles/valid-provider-identifiers"+
"/routing-profile-identifier/id";
} }
description description
"Routing profile to be used."; "";
}
leaf type {
type ie-type;
description
"Import, export or both.";
}
description
"Import or Export profile reference";
}
container ospf {
when "derived-from-or-self(../type, 'l3vpn-ntw:ospf')" {
description
"Only applies when protocol is OSPF.";
}
if-feature rtg-ospf;
leaf-list address-family {
type address-family;
min-elements "1";
description
"If OSPF is used on this site, this node
contains a configured value. This node
contains at least one address family
to be activated.";
}
leaf area-address {
type yang:dotted-quad;
mandatory true;
description
"Area address.";
}
leaf metric {
type uint16;
default 1;
description
"Metric of the PE-CE link. It is used
in the routing state calculation and
path selection.";
}
/* Extension */
leaf mtu {
type uint16;
description "Maximum transmission unit for a given
OSPF link.";
} }
choice key-type {
leaf process-id { default "psk";
type uint16; case psk {
description leaf preshared-key {
"Process id of the OSPF CE-PE connection."; type string;
description
"Pre-Shared Key (PSK) coming from the customer.";
}
}
description
"Choice of encryption profile.
The encryption profile can be the provider profile
or customer profile.";
} }
uses security-params; description
"This grouping defines encryption parameters for
a site.";
}
description
"";
}
/* End of Extension */ grouping site-routing {
container sham-links { container routing-protocols {
if-feature rtg-ospf-sham-link; list routing-protocol {
list sham-link { key "id";
key target-site; leaf id {
leaf target-site { type string;
type svc-id;
description description
"Target site for the sham link connection. "";
The site is referred to by its ID.";
} }
leaf metric { leaf type {
type uint16; type identityref {
default 1; base l3vpn-svc:routing-protocol-type;
}
description description
"Metric of the sham link. It is used in "Type of routing protocol.";
the routing state calculation and path
selection. The default value is set
to 1.";
} }
list routing-profiles {
key "id";
leaf id {
type leafref {
path "/l3vpn-ntw/vpn-profiles/"
+ "valid-provider-identifiers"
+ "/routing-profile-identifier/id";
}
description
"Routing profile to be used.";
}
leaf type {
type ie-type;
description
"Import, export or both.";
}
description description
"Creates a sham link with another site."; "Import or Export profile reference";
} }
description container ospf {
"List of sham links."; when "derived-from-or-self(../type, 'l3vpn-ntw:ospf')" {
} description
description "Only applies when protocol is OSPF.";
"OSPF-specific configuration."; }
} if-feature "l3vpn-svc:rtg-ospf";
container bgp { leaf-list address-family {
when "derived-from-or-self(../type, 'l3vpn-ntw:bgp')" { type l3vpn-svc:address-family;
description min-elements 1;
"Only applies when protocol is BGP."; description
} "If OSPF is used on this site, this node
if-feature rtg-bgp; contains a configured value. This node
leaf autonomous-system { contains at least one address family
type uint32; to be activated.";
mandatory true; }
description leaf area-address {
"Customer AS number in case the customer type yang:dotted-quad;
requests BGP routing."; mandatory true;
} description
leaf-list address-family { "Area address.";
type address-family; }
min-elements "1"; leaf metric {
description type uint16;
"If BGP is used on this site, this node default "1";
contains a configured value. This node description
contains at least one address family "Metric of the PE-CE link. It is used
to be activated."; in the routing state calculation and
} path selection.";
/* Extension */ }
leaf neighbor { /* Extension */
type inet:ip-address; leaf mtu {
description type uint16;
"IP address of the BGP neighbor."; description
} "Maximum transmission unit for a given
OSPF link.";
leaf multihop { }
type uint8; leaf process-id {
type uint16;
description
"Process id of the OSPF CE-PE connection.";
}
uses security-params;
/* End of Extension */
container sham-links {
if-feature "rtg-ospf-sham-link";
list sham-link {
key "target-site";
leaf target-site {
type l3vpn-svc:svc-id;
description
"Target site for the sham link connection.
The site is referred to by its ID.";
}
leaf metric {
type uint16;
default "1";
description
"Metric of the sham link. It is used in
the routing state calculation and path
selection. The default value is set
to 1.";
}
description
"Creates a sham link with another site.";
}
description
"List of sham links.";
}
description description
"Describes the number of hops allowed between the "OSPF-specific configuration.";
given BGP neighbor and the PE router.";
}
uses security-params;
description
"BGP-specific configuration.";
}
container static {
when "derived-from-or-self(../type, 'l3vpn-ntw:static')" {
description
"Only applies when protocol is static.
BGP activation requires the SP to know
the address of the customer peer. When
BGP is enabled, the 'static-address'
allocation type for the IP connection
MUST be used.";
}
container cascaded-lan-prefixes {
list ipv4-lan-prefixes {
if-feature ipv4;
key "lan next-hop";
leaf lan {
type inet:ipv4-prefix;
description
"LAN prefixes.";
} }
leaf lan-tag { container bgp {
type string; when "derived-from-or-self(../type, 'l3vpn-ntw:bgp')" {
description
"Only applies when protocol is BGP.";
}
if-feature "l3vpn-svc:rtg-bgp";
leaf peer-autonomous-system {
type inet:as-number;
mandatory true;
description
"Customer AS number in case the customer
requests BGP routing.";
}
leaf local-autonomous-system {
type inet:as-number;
description
"Local-AS overwrite.";
}
leaf-list address-family {
type l3vpn-svc:address-family;
min-elements 1;
description
"If BGP is used on this site, this node
contains a configured value. This node
contains at least one address family
to be activated.";
}
/* Extension */
leaf-list neighbor {
type inet:ip-address;
description
"IP address(es) of the BGP neighbor. An IPv4
and IPv6 neighbors may be indicated if
two sessions will be used for IPv4 and IPv6.";
}
leaf multihop {
type uint8;
description
"Describes the number of hops allowed between
a given BGP neighbor and the PE router.";
}
uses security-params;
uses status-params;
leaf description {
type string;
description
"Includes a description of the BGP session.
Such description is meant to be used for
diagnosis purposes. The semantic of the description
is local to an implementation.";
}
/* End- Extension */
description description
"Internal tag to be used in VPN policies."; "BGP-specific configuration.";
} }
leaf next-hop { container isis {
type inet:ipv4-address; when "derived-from-or-self(../type, 'l3vpn-ntw:isis')" {
description
"Only applies when protocol is ISIS.";
}
if-feature "rtg-isis";
leaf-list address-family {
type l3vpn-svc:address-family;
min-elements 1;
description
"If ISIS is used on this site, this node
contains a configured value. This node
contains at least one address family
to be activated.";
}
leaf area-address {
type area-address;
mandatory true;
description
"Area address.";
}
leaf level {
type isis-level;
description
"level1, level2 or level1-2";
}
leaf metric {
type uint16;
default "1";
description
"Metric of the PE-CE link. It is used
in the routing state calculation and
path selection.";
}
leaf process-id {
type uint16;
description
"Process id of the ISIS CE-PE connection.";
}
leaf mode {
type enumeration {
enum active {
description
"Interface sends or receives ISIS protocol
control packets.";
}
enum passive {
description
"Suppresses the sending of ISIS routing updates
through the specified interface.";
}
}
default "active";
description
"ISIS interface mode type.";
}
uses status-params;
description description
"Next-hop address to use on the customer side."; "ISIS-specific configuration.";
} }
description container static {
"List of LAN prefixes for the site."; when "derived-from-or-self(../type, 'l3vpn-ntw:static')" {
} description
list ipv6-lan-prefixes { "Only applies when protocol is static.
if-feature ipv6; BGP activation requires the SP to know
key "lan next-hop"; the address of the customer peer. When
leaf lan { BGP is enabled, the 'static-address'
type inet:ipv6-prefix; allocation type for the IP connection
MUST be used.";
}
container cascaded-lan-prefixes {
list ipv4-lan-prefixes {
if-feature "l3vpn-svc:ipv4";
key "lan next-hop";
leaf lan {
type inet:ipv4-prefix;
description
"LAN prefixes.";
}
leaf lan-tag {
type string;
description
"Internal tag to be used in VPN policies.";
}
leaf next-hop {
type inet:ipv4-address;
description
"Next-hop address to use on the customer side.";
}
description
"List of LAN prefixes for the site.";
}
list ipv6-lan-prefixes {
if-feature "l3vpn-svc:ipv6";
key "lan next-hop";
leaf lan {
type inet:ipv6-prefix;
description
"LAN prefixes.";
}
leaf lan-tag {
type string;
description
"Internal tag to be used in VPN policies.";
}
leaf next-hop {
type inet:ipv6-address;
description
"Next-hop address to use on the customer side.";
}
description
"List of LAN prefixes for the site.";
}
description
"LAN prefixes from the customer.";
}
description description
"LAN prefixes."; "Configuration specific to static routing.";
} }
leaf lan-tag { container rip {
type string; when "derived-from-or-self(../type, 'l3vpn-ntw:rip')" {
description description
"Internal tag to be used in VPN policies."; "Only applies when the protocol is RIP. For IPv4,
the model assumes that RIP version 2 is used.";
}
if-feature "l3vpn-svc:rtg-rip";
leaf-list address-family {
type l3vpn-svc:address-family;
min-elements 1;
description
"If RIP is used on this site, this node
contains a configured value. This node
contains at least one address family
to be activated.";
}
description
"Configuration specific to RIP routing.";
} }
leaf next-hop { container vrrp {
type inet:ipv6-address; when "derived-from-or-self(../type, 'l3vpn-ntw:vrrp')" {
description
"Only applies when protocol is VRRP.";
}
if-feature "l3vpn-svc:rtg-vrrp";
leaf-list address-family {
type l3vpn-svc:address-family;
min-elements 1;
description
"If VRRP is used on this site, this node
contains a configured value. This node contains
at least one address family to be activated.";
}
description description
"Next-hop address to use on the customer side."; "Configuration specific to VRRP routing.";
} }
description description
"List of LAN prefixes for the site."; "List of routing protocols used on
} the site. This list can be augmented.";
description
"LAN prefixes from the customer.";
}
description
"Configuration specific to static routing.";
}
container rip {
when "derived-from-or-self(../type, 'l3vpn-ntw:rip')" {
description
"Only applies when the protocol is RIP. For IPv4,
the model assumes that RIP version 2 is used.";
}
if-feature rtg-rip;
leaf-list address-family {
type address-family;
min-elements "1";
description
"If RIP is used on this site, this node
contains a configured value. This node
contains at least one address family
to be activated.";
}
description
"Configuration specific to RIP routing.";
}
container vrrp {
when "derived-from-or-self(../type, 'l3vpn-ntw:vrrp')" {
description
"Only applies when protocol is VRRP.";
}
if-feature rtg-vrrp;
leaf-list address-family {
type address-family;
min-elements "1";
description
"If VRRP is used on this site, this node
contains a configured value. This node contains
at least one address family to be activated.";
} }
description description
"Configuration specific to VRRP routing."; "Defines routing protocols.";
}
description
"List of routing protocols used on
the site. This list can be augmented.";
} }
description description
"Defines routing protocols."; "Grouping for routing protocols.";
}
description
"Grouping for routing protocols.";
} }
grouping site-attachment-ip-connection {
grouping site-attachment-ip-connection {
container ip-connection { container ip-connection {
container ipv4 { container ipv4 {
if-feature ipv4; if-feature "l3vpn-svc:ipv4";
leaf address-allocation-type { leaf address-allocation-type {
type identityref { type identityref {
base address-allocation-type; base l3vpn-svc:address-allocation-type;
} }
must "not(derived-from-or-self(current(), 'l3vpn-ntw:slaac') or "+ must "not(derived-from-or-self(current(), 'l3vpn-ntw:slaac')"
"derived-from-or-self(current(), "+ + " or derived-from-or-self(current(), "
"'l3vpn-ntw:provider-dhcp-slaac'))" { + "'l3vpn-ntw: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.
If there is no value for the address
allocation type, then IPv4 is not enabled.";
}
container provider-dhcp {
when "derived-from-or-self(../address-allocation-type, "+
"'l3vpn-ntw:provider-dhcp')" {
description
"Only applies when addresses are allocated by DHCP.";
}
leaf provider-address {
type inet:ipv4-address;
description description
"Address of provider side. If provider-address is not "Defines how addresses are allocated.
specified, then prefix length should not be specified If there is no value for the address
either. It also implies provider-dhcp allocation is allocation type, then IPv4 is not enabled.";
not enabled. If provider-address is specified, then }
the prefix length may or may not be specified."; container provider-dhcp {
} when "derived-from-or-self(../address-allocation-type, "
leaf prefix-length { + "'l3vpn-ntw:provider-dhcp')" {
type uint8 { description
range "0..32"; "Only applies when addresses are allocated by DHCP.";
} }
must "(../provider-address)" { leaf provider-address {
error-message type inet:ipv4-address;
"If the prefix length is specified, provider-address description
must also be specified."; "Address of provider side. If provider-address is not
specified, then prefix length should not be specified
either. It also implies provider-dhcp allocation is
not enabled. If provider-address is specified, then
the prefix length may or may not be specified.";
}
leaf prefix-length {
type uint8 {
range "0..32";
}
must '(../provider-address)' {
error-message
"If the prefix length is specified, provider-address
must also be specified.";
description description
"If the prefix length is specified, provider-address "If the prefix length is specified, provider-address
must also be specified."; must also be specified.";
} }
description description
"Subnet prefix length expressed in bits. "Subnet prefix length expressed in bits.
If not specified, or specified as zero, If not specified, or specified as zero,
this means the customer leaves the actual this means the customer leaves the actual
prefix length value to the provider."; prefix length value to the provider.";
} }
choice address-assign { choice address-assign {
default number; default "number";
case number { case number {
leaf number-of-dynamic-address { leaf number-of-dynamic-address {
type uint16; type uint16;
default 1; default "1";
description
"Describes the number of IP addresses
the customer requires.";
}
}
case explicit {
container customer-addresses {
list address-group {
key "group-id";
leaf group-id {
type string;
description
"Group-id for the address range from
start-address to end-address.";
}
leaf start-address {
type inet:ipv4-address;
description
"First address.";
}
leaf end-address {
type inet:ipv4-address;
description
"Last address.";
}
description
"Describes IP addresses allocated by DHCP.
When only start-address or only end-address
is present, it represents a single address.
When both start-address and end-address are
specified, it implies a range inclusive of both
addresses. If no address is specified, it implies
customer addresses group is not supported.";
}
description
"Container for customer addresses is allocated by
DHCP.";
}
}
description
"Choice for the way to assign addresses.";
}
description description
"Describes the number of IP addresses "DHCP allocated addresses related parameters.";
the customer requires.";
} }
} container dhcp-relay {
case explicit { when "derived-from-or-self(../address-allocation-type, "
container customer-addresses { + "'l3vpn-ntw:provider-dhcp-relay')" {
list address-group { description
key "group-id"; "Only applies when provider is required to implement
leaf group-id { DHCP relay function.";
type string;
description
"Group-id for the address range from
start-address to end-address.";
} }
leaf start-address { leaf provider-address {
type inet:ipv4-address; type inet:ipv4-address;
description description
"First address."; "Address of provider side. If provider-address is not
specified, then prefix length should not be specified
either. It also implies provider-dhcp allocation is
not enabled. If provider-address is specified, then
prefix length may or may not be specified.";
} }
leaf end-address { leaf prefix-length {
type inet:ipv4-address; type uint8 {
description range "0..32";
"Last address."; }
must '(../provider-address)' {
error-message
"If prefix length is specified, provider-address
must also be specified.";
description
"If prefix length is specified, provider-address
must also be specified.";
}
description
"Subnet prefix length expressed in bits. If not
specified, or specified as zero, this means the
customer leaves the actual prefix length value
to the provider.";
}
container customer-dhcp-servers {
leaf-list server-ip-address {
type inet:ipv4-address;
description
"IP address of customer DHCP server.";
}
description
"Container for list of customer DHCP servers.";
} }
description description
"Describes IP addresses allocated by DHCP. "DHCP relay provided by operator.";
When only start-address or only end-address
is present, it represents a single address.
When both start-address and end-address are
specified, it implies a range inclusive of both
addresses. If no address is specified, it implies
customer addresses group is not supported.";
}
description
"Container for customer addresses is allocated by DHCP.";
} }
} container static-addresses {
description when "derived-from-or-self(../address-allocation-type, "
"Choice for the way to assign addresses."; + "'l3vpn-ntw:static-address')" {
} description
description "Only applies when protocol allocation type is static.";
"DHCP allocated addresses related parameters."; }
} leaf primary-address {
container dhcp-relay { type leafref {
when "derived-from-or-self(../address-allocation-type, "+ path "/l3vpn-ntw/vpn-services/vpn-service/vpn-nodes/"
"'l3vpn-ntw:provider-dhcp-relay')" { + "vpn-node/vpn-network-accesses/vpn-network-access/"
description + "ip-connection/ipv4/static-addresses/address/"
"Only applies when provider is required to implement + "address-id";
DHCP relay function."; }
} description
leaf provider-address { "Principal address of the connection.";
type inet:ipv4-address; }
description list address {
"Address of provider side. If provider-address is not key "address-id";
specified, then prefix length should not be specified leaf address-id {
either. It also implies provider-dhcp allocation is type string;
not enabled. If provider-address is specified, then description
prefix length may or may not be specified."; "IPv4 Address";
} }
leaf prefix-length { leaf provider-address {
type uint8 { type inet:ipv4-address;
range "0..32"; description
} "IPv4 Address List of the provider side.
must "(../provider-address)" { When the protocol allocation type is static,
error-message the provider address must be configured.";
"If prefix length is specified, provider-address }
must also be specified."; leaf customer-address {
description type inet:ipv4-address;
"If prefix length is specified, provider-address description
must also be specified."; "IPv4 Address of customer side.";
} }
description leaf prefix-length {
"Subnet prefix length expressed in bits. If not type uint8 {
specified, or specified as zero, this means the range "0..32";
customer leaves the actual prefix length value }
to the provider."; description
} "Subnet prefix length expressed in bits.
container customer-dhcp-servers { It is applied to both provider-address
leaf-list server-ip-address { and customer-address.";
type inet:ipv4-address; }
description description
"IP address of customer DHCP server."; "Describes IPv4 addresses used.";
} }
description
"Container for list of customer DHCP servers.";
}
description
"DHCP relay provided by operator.";
}
container static-addresses {
when "derived-from-or-self(../address-allocation-type, "+
"'l3vpn-ntw:static-address')" {
description
"Only applies when protocol allocation type is static.";
}
leaf primary-address{
type leafref {
path "/l3vpn-ntw/vpn-services/vpn-service/vpn-nodes/"+
"vpn-node/vpn-network-accesses/vpn-network-access/"+
"ip-connection/ipv4/static-addresses/address/address-id";
}
description
"Principal address of the connection.";
}
list address{
key address-id;
leaf address-id {
type string;
description
"IPv4 Address";
}
leaf provider-address {
type inet:ipv4-address;
description description
"IPv4 Address List of the provider side. "Describes IPv4 addresses used.";
When the protocol allocation type is static, }
the provider address must be configured."; description
"IPv4-specific parameters.";
} }
leaf customer-address { container ipv6 {
type inet:ipv4-address; if-feature "l3vpn-svc:ipv6";
leaf address-allocation-type {
type identityref {
base l3vpn-svc:address-allocation-type;
}
description description
"IPv4 Address of customer side."; "Defines how addresses are allocated.
} If there is no value for the address
leaf prefix-length { allocation type, then IPv6 is
type uint8 { not enabled.";
range "0..32";
}
description
"Subnet prefix length expressed in bits.
It is applied to both provider-address
and customer-address.";
}
description
"Describes IPv4 addresses used.";
}
description
"Describes IPv4 addresses used.";
}
description
"IPv4-specific parameters.";
}
container ipv6 {
if-feature ipv6;
leaf address-allocation-type {
type identityref {
base address-allocation-type;
}
description
"Defines how addresses are allocated.
If there is no value for the address
allocation type, then IPv6 is
not enabled.";
}
container provider-dhcp {
when "derived-from-or-self(../address-allocation-type, "+
"'l3vpn-ntw:provider-dhcp') "+
"or derived-from-or-self(../address-allocation-type, "+
"'l3vpn-ntw:provider-dhcp-slaac')" {
description
"Only applies when addresses are allocated by DHCP.";
} }
leaf provider-address { container provider-dhcp {
when "derived-from-or-self(../address-allocation-type, "
+ "'l3vpn-ntw:provider-dhcp') "
+ "or derived-from-or-self(../address-allocation-type, "
+ "'l3vpn-ntw:provider-dhcp-slaac')" {
description
"Only applies when addresses are allocated by DHCP.";
}
leaf provider-address {
type inet:ipv6-address; type inet:ipv6-address;
description description
"Address of the provider side. If provider-address "Address of the provider side. If provider-address
is not specified, then prefix length should not be is not specified, then prefix length should not be
specified either. It also implies provider-dhcp specified either. It also implies provider-dhcp
allocation is not enabled. If provider-address is allocation is not enabled. If provider-address is
specified, then prefix length may or may specified, then prefix length may or may
not be specified."; not be specified.";
} }
leaf prefix-length { leaf prefix-length {
type uint8 { type uint8 {
range "0..128"; range "0..128";
} }
must "(../provider-address)" { must '(../provider-address)' {
error-message error-message
"If prefix length is specified, provider-address "If prefix length is specified, provider-address
must also be specified."; must also be specified.";
description description
"If prefix length is specified, provider-address "If prefix length is specified, provider-address
must also be specified."; must also be specified.";
} }
description
"Subnet prefix length expressed in bits. If not
specified, or specified as zero, this means the
customer leaves the actual prefix length value
to the provider.";
}
choice address-assign {
default number;
case number {
leaf number-of-dynamic-address {
type uint16;
default 1;
description description
"Describes the number of IP addresses the customer "Subnet prefix length expressed in bits. If not
requires."; specified, or specified as zero, this means the
customer leaves the actual prefix length value
} to the provider.";
} }
case explicit { choice address-assign {
container customer-addresses { default "number";
list address-group { case number {
leaf number-of-dynamic-address {
type uint16;
default "1";
description
"Describes the number of IP addresses the customer
requires.";
}
}
case explicit {
container customer-addresses {
list address-group {
key "group-id"; key "group-id";
leaf group-id { leaf group-id {
type string; type string;
description description
"Group-id for the address range from "Group-id for the address range from