draft-ietf-opsawg-l3sm-l3nm-03.txt   draft-ietf-opsawg-l3sm-l3nm-04.txt 
OPSAWG S. Barguil OPSAWG S. Barguil
Internet-Draft O. Gonzalez de Dios, Ed. Internet-Draft O. Gonzalez de Dios, Ed.
Intended status: Standards Track Telefonica Intended status: Standards Track Telefonica
Expires: October 5, 2020 M. Boucadair Expires: April 7, 2021 M. Boucadair, Ed.
Orange Orange
L. Munoz L. Munoz
Vodafone Vodafone
A. Aguado A. Aguado
Nokia Nokia
April 03, 2020 October 4, 2020
A Layer 3 VPN Network YANG Model A Layer 3 VPN Network YANG Model
draft-ietf-opsawg-l3sm-l3nm-03 draft-ietf-opsawg-l3sm-l3nm-04
Abstract Abstract
This document defines a L3VPN Network YANG Model (L3NM) that can be This document defines a L3VPN Network YANG Model (L3NM) that can be
used to manage the provisioning of Layer 3 Virtual Private Network used to manage the provisioning of Layer 3 Virtual Private Network
(VPN) services within a Service Provider's network. The model (VPN) services within a Service Provider's network. The model
provides a network-centric view of L3VPN services. provides a network-centric view of L3VPN services.
L3NM is meant to be used by a Network Controller to derive the L3NM is meant to be used by a Network Controller to derive the
configuration information that will be sent to relevant network configuration information that will be sent to relevant network
devices. The model can also facilitate the communication between a devices. The model can also facilitate the communication between a
service orchestrator and a network controller/orchestrator. service orchestrator and a network controller/orchestrator.
L3NM focuses on BGP PE-based Layer 3 VPNs as described in RFCs 4026,
4110 and 4364 and Multicast VPNs as described in RFCs 6037, 6513 and
7988.
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";
o reference: RFC XXXX o reference: RFC XXXX
skipping to change at page 2, line 20 skipping to change at page 2, line 12
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 October 5, 2020. This Internet-Draft will expire on April 7, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 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
skipping to change at page 2, line 42 skipping to change at page 2, line 34
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
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Reference Architecture . . . . . . . . . . . . . . . . . . . 6 4. L3NM Reference Architecture . . . . . . . . . . . . . . . . . 6
5. Relation with other YANG Models . . . . . . . . . . . . . . . 8 5. Relation with other YANG Models . . . . . . . . . . . . . . . 8
6. Description of the L3NM YANG Module . . . . . . . . . . . . . 10 6. Sample Uses of the L3NM Data Model . . . . . . . . . . . . . 10
6.1. Overall Structure of the Module . . . . . . . . . . . . . 10 6.1. Enterprise Layer 3 VPN Services . . . . . . . . . . . . . 10
6.2. VPN Profiles . . . . . . . . . . . . . . . . . . . . . . 10 6.2. Multi-Domain Resource Management . . . . . . . . . . . . 10
6.3. Modeling a Layer 3 VPN Service . . . . . . . . . . . . . 11 6.3. Management of Multicast Services . . . . . . . . . . . . 11
6.3.1. Service Status . . . . . . . . . . . . . . . . . . . 12 7. Description of the L3NM YANG Module . . . . . . . . . . . . . 11
6.3.2. VPN Node . . . . . . . . . . . . . . . . . . . . . . 13 7.1. Overall Structure of the Module . . . . . . . . . . . . . 11
6.3.2.1. Node Status . . . . . . . . . . . . . . . . . . . 16 7.2. VPN Profiles . . . . . . . . . . . . . . . . . . . . . . 12
6.3.2.2. RT/RD Assignment/auto-assignment . . . . . . . . 16 7.3. Modeling a Layer 3 VPN Service . . . . . . . . . . . . . 13
6.3.2.3. VPN Network Access . . . . . . . . . . . . . . . 17 7.3.1. Service Status . . . . . . . . . . . . . . . . . . . 15
6.3.2.3.1. Connection . . . . . . . . . . . . . . . . . 18 7.3.2. Concept of Import/Export Profiles . . . . . . . . . . 15
6.3.2.3.2. IP Connections . . . . . . . . . . . . . . . 22 7.3.3. Underlay Transport . . . . . . . . . . . . . . . . . 16
6.3.2.3.3. Security . . . . . . . . . . . . . . . . . . 24 7.3.4. VPN Node . . . . . . . . . . . . . . . . . . . . . . 17
6.3.2.3.4. CE PE Routing Protocols . . . . . . . . . . . 25 7.3.4.1. RT/RD Assignment/auto-assignment . . . . . . . . 19
6.3.2.3.5. Services . . . . . . . . . . . . . . . . . . 29 7.3.4.2. VPN Network Access . . . . . . . . . . . . . . . 20
6.3.2.4. Multicast . . . . . . . . . . . . . . . . . . . . 31 7.3.4.2.1. Connection . . . . . . . . . . . . . . . . . 21
6.3.3. Concept of Import/Export Profiles . . . . . . . . . . 33 7.3.4.2.2. IP Connections . . . . . . . . . . . . . . . 23
6.3.4. Underlay Transport . . . . . . . . . . . . . . . . . 33 7.3.4.2.3. Security . . . . . . . . . . . . . . . . . . 27
7. L3NM Module Tree Structure . . . . . . . . . . . . . . . . . 33 7.3.4.2.4. CE-PE Routing Protocols . . . . . . . . . . . 27
8. Sample Uses of the L3NM Data Model . . . . . . . . . . . . . 43 7.3.4.2.5. Services . . . . . . . . . . . . . . . . . . 36
8.1. Enterprise L3 VPN Services . . . . . . . . . . . . . . . 43 7.3.4.3. Multicast . . . . . . . . . . . . . . . . . . . . 42
8.2. Multi-Domain Resource Management . . . . . . . . . . . . 43 8. Layer 3 Network Model . . . . . . . . . . . . . . . . . . . . 43
8.3. Management of Multicast services . . . . . . . . . . . . 44 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 89
9. L3VPN Examples . . . . . . . . . . . . . . . . . . . . . . . 44 10. Security Considerations . . . . . . . . . . . . . . . . . . . 89
9.1. 4G VPN Provisioning Example . . . . . . . . . . . . . . . 44 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 91
9.2. Multicast VPN Provisioning Example . . . . . . . . . . . 48 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 91
10. L3NM YANG Module . . . . . . . . . . . . . . . . . . . . . . 50 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 92
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 110 13.1. Normative References . . . . . . . . . . . . . . . . . . 92
12. Security Considerations . . . . . . . . . . . . . . . . . . . 110 13.2. Informative References . . . . . . . . . . . . . . . . . 93
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 112 Appendix A. L3VPN Examples . . . . . . . . . . . . . . . . . . . 96
14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 112 A.1. 4G VPN Provisioning Example . . . . . . . . . . . . . . . 96
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 113 A.2. Multicast VPN Provisioning Example . . . . . . . . . . . 100
15.1. Normative References . . . . . . . . . . . . . . . . . . 113 Appendix B. Implementation Status . . . . . . . . . . . . . . . 104
15.2. Informative References . . . . . . . . . . . . . . . . . 114 B.1. Nokia Implementation . . . . . . . . . . . . . . . . . . 104
Appendix A. Implementation Status . . . . . . . . . . . . . . . 115 B.2. Huawei Implementation . . . . . . . . . . . . . . . . . . 104
A.1. Nokia Implementation . . . . . . . . . . . . . . . . . . 115 B.3. Infinera Implementation . . . . . . . . . . . . . . . . . 104
A.2. Huawei Implementation . . . . . . . . . . . . . . . . . . 116 B.4. Ribbon-ECI Implementation . . . . . . . . . . . . . . . . 104
A.3. Infinera Implementation . . . . . . . . . . . . . . . . . 119 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 104
A.4. Ribbon-ECI Implementation . . . . . . . . . . . . . . . . 120
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 122
1. Introduction 1. Introduction
[RFC8299] defines an L3VPN Service YANG data Model (L3SM) that can be [RFC8299] defines a 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 Virtual
and provides an abstracted view of the customer's requested services. Private Network (VPN) services, and provides an abstracted view of
That approach limits the usage of the L3SM module to the role of a the customer's requested services. That approach limits the usage of
Customer Service Model, according to the terminology defined in the L3SM module to the role of a Customer Service Model, according to
[RFC8309]. the terminology defined in [RFC8309].
The YANG data model defined in this document is called L3VPN Network This document defined a YANG module called L3VPN Network Model
Model (L3NM). The L3NM module is aimed at providing a network- (L3NM). The L3NM is aimed at providing a network-centric view of
centric view of L3 VPN Services. The data model can be used to Layer 3 (L3) VPN Services. This data model can be used to facilitate
facilitate communication between the service orchestrator (or a communication between the service orchestrator (or a network
network operator) and the network controller/orchestrator by allowing operator) and the network controller/orchestrator by allowing for
for more network-centric information to be included. It enables more network-centric information to be included. It enables further
further capabilities, such as resource management or to serve as a capabilities, such as resource management or to serve as a multi-
multi-domain orchestration interface, where logical resources (such domain orchestration interface, where logical resources (such as
as route targets or route distinguishers) must be synchronized. route targets or route distinguishers) must be synchronized.
This document uses the common VPN YANG module defined in
[I-D.ietf-opsawg-vpn-common].
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 different 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 attributes (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 in charge of maintaining the correspondence
Customer view and its network instantiation. Likewise, some of the between a Customer view and its network instantiation. Likewise,
information captured and exposed using L3NM can fed the service layer some of the information captured and exposed using L3NM can fed the
(e.g., capabilities) to derive L3SM and drive VPN service order service layer (e.g., capabilities) to derive L3SM and drive VPN
handling. service order handling.
The L3NM module does not attempt to address all deployment cases The L3NM does not attempt to address all deployment cases especially
especially those where the L3VPN connectivity is supported through those where the L3VPN connectivity is supported through the
the coordination of different VPNs in different underlying networks. 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].
L3NM focuses on BGP PE-based Layer 3 VPNs as described in
[RFC4026][RFC4110][RFC4364] and Multicast VPNs as described in
[RFC6037][RFC6513][RFC7988].
2. Requirements Language 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Terminology 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 [RFC8340]. The meaning of the symbols in tree diagrams is defined in [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 [RFC4176] 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 Layer 3 VPN Customer Service Model (L3SM): A YANG module that
of a L3 VPN that interconnects a set of sites from the point of describes the requirements of a L3VPN that interconnects a set of
view of the customer. The customer service model does not provide sites from the point of view of the customer. The customer
details on the Service Provider Network. The L3 VPN Customer service model does not provide details on the service provider
Service model is defined in [RFC8299]. network. The L3VPN Customer Service model is defined in
[RFC8299].
o L3 VPN Service Network Model (L3NM): A YANG module that describes o Layer 3 VPN Service Network Model (L3NM): A YANG module that
a VPN Service in the Service Provider Network. It contains describes a VPN Service in the service provider network. It
information of the Service Provider network and might include contains information of the Service Provider network and might
allocated resources. It can be used by network controllers to include allocated resources. It can be used by network
manage and control the VPN Service configuration in the Service controllers to manage and control the VPN Service configuration in
Provider network. The YANG module can be consumed by a Service the Service Provider network. The YANG module can be consumed by
Orchestrator to request a VPN Service to a Network controller. a Service 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 L3VPN. 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 Customer Edge (CE) - the Provider Edge (PE) attachment
the VPN service to the network controller. circuits, the PE selection, and requesting the VPN service to the
network controller.
o Network Orchestrator: A functional entity that is hierarchically
intermediate between Service Orchestrator and Network Controllers.
A network orchestrator can manage one or several Network
Controllers.
o Network Controller: A functional entity responsible for the o Network Controller: A functional entity responsible for the
control and management of the service provider network. control and management of the service provider network.
o VPN node (vpn-node): An abstraction that represents a set of o VPN node: An abstraction that represents a set of policies applied
policies applied to a PE and that belong to a single VPN service on a PE and that belong to a single VPN service. A VPN service
(vpn-service). A vpn-service involves one or more vpn-nodes. As involves one or more VPN nodes. As it is an abstraction, the
it is an abstraction, the network controller will take on how to network controller will take on how to implement a VPN node. For
implement a vpn-node. For example, typically, in a BGP-based VPN, example, typically, in a BGP-based VPN, a VPN node could be mapped
a vpn-node could be mapped into a VRF. into a Virtual Routing and Forwarding (VRF).
o VPN network access (vpn-network-access): An abstraction that o VPN network access: An abstraction that represents the network
represents the network interfaces that are associated to a given interfaces that are associated to a given VPN node. Traffic
vpn-node. Traffic coming from the vpn-network-access belongs to coming from the VPN network access belongs to the VPN. The
the VPN. The attachment circuits (bearers) between CEs and PEs attachment circuits (bearers) between CEs and PEs are terminated
are terminated in the vpn-network-access. A reference to the in the VPN network access. A reference to the bearer is
bearer is maintained to allow keeping the link between L3SM and maintained to allow keeping the link between L3SM and L3NM.
L3NM.
o VPN Site (vpn-site): A VPN customer's location that is connected o VPN Site: A VPN customer's location that is connected to the
to the Service Provider network via a CE-PE link, which can access Service Provider network via a CE-PE link, which can access at
at least one VPN [RFC4176]. least one VPN [RFC4176].
o VPN Service Provider (SP): A Service Provider offers VPN-related o VPN Service Provider (SP): A Service Provider that offers VPN-
services [RFC4176]. related services [RFC4176].
o Service Provider (SP) Network: A network able to provide VPN- o Service Provider (SP) Network: A network that is able to provide
related services. VPN-related services.
4. Reference Architecture 4. L3NM Reference Architecture
Figure 1 depicts 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
dedicated 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
Manager" roles may be performed by "Controllers". Manager" roles may be performed by "Controllers".
+---------------+ +---------------+
| Customer | | Customer |
+---------------+ +---------------+
skipping to change at page 7, line 20 skipping to change at page 7, line 20
+---------------+ +---------------+
| Service | | Service |
| Orchestration | | Orchestration |
+---------------+ +---------------+
L3NM Network Model | L3NM Network Model |
l3vpn-ntw | l3vpn-ntw |
+---------------+ +---------------+
| Network | | Network |
| Orchestration | | Orchestration |
+---------------+ +---------------+
Network Configuration Model | Network Configuration Model |
__________|____________ +-----------+-----------+
| | | |
+---------------+ +---------------+ +---------------+ +---------------+
| Domain | | Domain | | Domain | | Domain |
| Orchestration | | Orchestration | | Orchestration | | Orchestration |
+---------------+ +---------------+ +---------------+ +---------------+
Device | | | Device | | |
Configuration | | | Configuration | | |
Model | | | Model | | |
+---------+ | | +---------+ | |
| Config | | | | Config | | |
| Manager | | | | Manager | | |
+---------+ | | +---------+ | |
| | | | | |
| NETCONF/CLI.................. | NETCONF/CLI..................
| | | | | |
+------------------------------------------------+ +------------------------------------------------+
Network Network
Figure 1: L3SM and L3NM Figure 1: Reference Architecture
The L3SM and L3NM modules may also be set in the context of the ACTN The L3SM and the L3NM may also be used in the context of the ACTN
architecture [RFC8453]. Figure 2 shows the Customer Network architecture [RFC8453]. Figure 2 shows the Customer Network
Controller (CNC), the Multi-Domain Service Coordinator (MDSC), and Controller (CNC), the Multi-Domain Service Coordinator (MDSC), and
the Provisioning Network Controller (PNC). It also shows the the Provisioning Network Controller (PNC). It also shows the
interfaces between these functional blocks: the CNC-MDSC Interface interfaces between these functional blocks: the CNC-MDSC Interface
(CMI), the MDSC-PNC Interface (MPI), and the Southbound Interface (CMI), the MDSC-PNC Interface (MPI), and the Southbound Interface
(SBI). (SBI).
+----------------------------------+ +----------------------------------+
| Customer | | Customer |
| +-----------------------------+ | | +-----------------------------+ |
skipping to change at page 8, line 27 skipping to change at page 8, line 27
| | Service | | +-------------------+ | | Service | | +-------------------+
| | Orchestration | | : | | Orchestration | | :
| +---------------+ | : L3NM | +---------------+ | : L3NM
| : | : | : | :
| : L3NM | +-------------------+ | : L3NM | +-------------------+
| : | | MDSC | | : | | MDSC |
| +---------------+ | | (child) | | +---------------+ | | (child) |
| | Network | | +-------------------+ | | Network | | +-------------------+
| | Orchestration | | : | | Orchestration | | :
| +---------------+ | : | +---------------+ | :
---------:--------- : +---------:---------+ :
: : : :
: Network Configuration : : Network Configuration :
: : : :
+------------:-------+ +---------:------------+ +------------:-------+ +---------:------------+
| Domain : | | : Domain | | Domain : | | : Domain |
| Controller : | | : Controller | | Controller : | | : Controller |
| +---------+ | | +---------+ | | +---------+ | | +---------+ |
| | PNC | | | | PNC | | | | PNC | | | | PNC | |
| +---------+ | | +---------+ | | +---------+ | | +---------+ |
+------------:-------+ +---------:------------+ +------------:-------+ +---------:------------+
skipping to change at page 8, line 49 skipping to change at page 8, line 49
: 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
5. Relation with other YANG Models 5. Relation with other YANG Models
As discussed in the previous section, the L3NM YANG module is meant The "ietf-vpn-common" module [I-D.ietf-opsawg-vpn-common] includes a
to manage L3VPN Services within a Service Provider network. The set of identities, types, and groupings that are meant to be reused
module provides a network-wise view of the service. Such view is by VPN-related YANG modules independently of the layer (e.g., Layer
only visible within the Service Provider and is not exposed outside. 2, Layer 3) and the type of the module (e.g., network model, service
The following discusses how L3NM interfaces with other YANG modules: model) including future revisions of existing models (e.g., [RFC8299]
or [RFC8466]). The L3NM reuses these common types and grouping.
In order to avoid data duplication and to ease passing data between
layers when required (service layer to network layer and vice versa),
early versions of the L3NM reused many of the data nodes that are
defined in [RFC8299]. Nevertheless, that approach was abandoned in
favor of the "ietf-vpn-common" module because that design was
interpreted as if the deployment of L3NM depends on L3SM, while this
is not the case. For example, a Service Provider may decide to use
the L3NM to build its L3VPN services without exposing the L3SM.
As discussed in Section 4, the L3NM YANG module is meant to manage
L3VPN services within a Service Provider network. The module
provides a network view of the service. Such view is only visible
within the Service Provider and is not exposed outside (to customers,
for example). The following discusses how L3NM interfaces with other
YANG modules:
L3SM: L3NM is not a Customer Service Model. L3SM: L3NM is not a Customer Service Model.
The internal view of the service (L3NM) may be mapped to an The internal view of the service (L3NM) may be mapped to an
external view which is visible to Customers : L3VPN Service YANG external view which is visible to Customers : L3VPN Service YANG
data Model (L3SM) [RFC8299]. data Model (L3SM) [RFC8299].
Typically, the L3NM module can be fed with inputs that are Typically, the L3NM can be fed with inputs that are requested by
requested by Customers, typically, relying upon a L3SM template. Customers, typically, relying upon a L3SM template. Concretely,
Concretely, some parts of the L3SM module can be directly mapped some parts of the L3SM module can be directly mapped into L3NM
into L3NM while other parts are generated as a function of the while other parts are generated as a function of the requested
requested service and local guidelines. Some other parts are service and local guidelines. Some other parts are local to the
local to the Service Provider and do not map directly to L3SM. Service Provider and do not map directly to L3SM.
Note that the use of L3NM within a Service Provider does assume Note that the use of L3NM within a Service Provider does not
nor preclude exposing the VPN service via L3SM. This is assume nor preclude exposing the VPN service via L3SM. This is
deployment-specific. Nevertheless, the design of L3NM tries to deployment-specific. Nevertheless, the design of L3NM tries to
align as much as possible with the features supported by the L3SM align as much as possible with the features supported by the L3SM
to ease grafting both L3NM and L3SM for the sake of highly to ease grafting both L3NM and L3SM for the sake of highly
automated VPN service provisioning and delivery. automated VPN service provisioning and delivery.
Network Topology Modules: A L3VPN involves nodes that are part of a Network Topology Modules: A L3VPN involves nodes that are part of a
topology managed by the Service Provider Backbone network. Such topology managed by the Service Provider Backbone network. Such
topology can be represented as using the network topology module topology can be represented as using the network topology module
in [RFC8345]. in [RFC8345].
Device Modules: L3NM is not a device model. Device Modules: L3NM is not a device model.
Once a global VPN service is captured by means of L3NM, the actual Once a global VPN service is captured by means of L3NM, the actual
activation and provisioning of the VPN service will involve a activation and provisioning of the VPN service will involve a
variety of device modules to tweak the required functions for the variety of device modules to tweak the required functions for the
delivery of the service. These functions are supported by the VPN delivery of the service. These functions are supported by the VPN
nodes and can be managed using device YANG modules. A non- nodes and can be managed using device YANG modules. A non-
comprehensive list of such device YANG modules is provided below: comprehensive list of such device YANG modules is provided below:
* Routing management ([RFC8349]) * Routing management [RFC8349].
* BGP ([I-D.ietf-idr-bgp-model]) * BGP [I-D.ietf-idr-bgp-model].
* PIM ([I-D.ietf-pim-yang]) * PIM [I-D.ietf-pim-yang].
* NAT management ([RFC8512]) * NAT management [RFC8512].
* QoS management ([I-D.ietf-rtgwg-qos-model]) * QoS management [I-D.ietf-rtgwg-qos-model].
* ACLs [RFC8519].
* ACL ([RFC8519])
How L3NM is used to derive device-specific actions is How L3NM is used to derive device-specific actions is
implementation-specific. implementation-specific.
6. Description of the L3NM YANG Module 6. Sample Uses of the L3NM Data Model
The L3NM module ('ietf-l3vpn-ntw') is meant to manage L3 VPNs in a 6.1. Enterprise Layer 3 VPN Services
service provider network. In particular, the 'ietf-l3vpn-ntw' module
can be used to create, modify, and retrieve L3VPN Services of a
network.
The detailed tree structure is provided in Figure 17. 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.
6.1. Overall Structure of the Module 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.
6.2. Multi-Domain Resource Management
The implementation of L3VPN services which span across
administratively separated domains (i.e., that are under the
administration of different management systems or controllers)
requires some network resources to be synchronized between systems.
Particularly, there are two resources that must be orchestrated and
manage to avoid asymmetric (non-functional) configuration, or the
usage of unavailable resources.
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.
6.3. Management of Multicast Services
Multicast services over L3VPN can be implemented either using dual
PIM MVPNs (also known as, Draft Rosen model) [RFC4364] or
multiprotocol BGP (MBGP)-based MVPNs[RFC6513][RFC6514]. Both methods
are supported and equally effective, but the main difference is that
MBGP-based MVPN does not require multicast configuration on the
service provider backbone. MBGP MVPNs employ the intra-autonomous
system BGP control plane and PIM sparse mode as the data plane. The
PIM state information is maintained between the PE routers using the
same architecture that is used for unicast VPNs.
On the other hand, Draft Rosen has limitations such as reduced
options for transport, control plane scalability, availability,
operational inconsistency, and the need of maintaining state in the
backbone. Because of this, MBGP MVPN is the architectural model that
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.
7. Description of the L3NM YANG Module
The L3NM ('ietf-l3vpn-ntw') is defined to manage L3VPNs in a service
provider network. In particular, the 'ietf-l3vpn-ntw' module can be
used to create, modify, and retrieve L3VPN Services of a network.
7.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). and 'vpn-profiles' (see Figure 3).
The 'vpn-services' container maintains the set of VPN services The 'vpn-services' container maintains the set of VPN services
managed within the service provider's network. 'vpn-service' is the managed within the service provider's network. 'vpn-service' is the
data structure that abstracts a VPN service (Section 6.3). data structure that abstracts a VPN service (Section 7.3).
The 'vpn-profiles' container is used by the provider to maintain a The 'vpn-profiles' container is used by the provider to maintain a
set of common VPN profiles that apply to several VPN services set of common VPN profiles that apply to one or several VPN services
(Section 6.2). (Section 7.2).
module: ietf-l3vpn-ntw module: ietf-l3vpn-ntw
+--rw 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: Overall L3NM Tree Structure Figure 3: Overall L3NM Tree Structure
6.2. VPN Profiles 7.2. VPN Profiles
The 'vpn-profiles' containers (Figure 4) allow the network provider The 'vpn-profiles' container (Figure 4) allows the network provider
to define and maintain a set of common VPN profiles that apply to to define and maintain a set of common VPN profiles
several VPN services. The exaact definition of the profiles is local [I-D.ietf-opsawg-vpn-common] that apply to one or several VPN
to each network provider. services. The exact definition of the profiles is local to each
network provider.
+--rw l3vpn-ntw This document does not make any assumption about the exact definition
+--rw vpn-profiles of these profiles. How such profiles are defined is deployment
| +--rw valid-provider-identifiers specific. The model only includes an identifier to these profiles to
| +--rw cloud-identifier* [id] {l3vpn-svc:cloud-access}? ease identifying local policies when building a VPN service. As
| | +--rw id string shown in Figure 4, the following identifiers can be included:
| +--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 o 'cloud-identifier': This identifier refers to a cloud service.
6.3. Modeling a Layer 3 VPN Service o 'encryption-profile-identifier': An encryption profile refers to a
set of policies related to the encryption scheme(s) and setup that
can be applied when building and offering a VPN service.
The 'vpn-service' is the data structure that abstracts a VPN Service o 'qos-profile-identifier': A QoS profile refers to as set of
in the Service Provider Network. Each 'vpn-service' is uniquely policies such as classification, marking, and actions (e.g.,
[RFC3644]).
o 'bfd-profile-identifier': A Bidirectional Forwarding Detection
(BFD) profile refers to a set of BFD [RFC5880] policies that can
be invoked when building a VPN service.
o 'forwarding-profile-identifier': A forwarding profile refers to
the policies that apply to the forwarding of packets conveyed
within a VPN. Such policies may consist at applying Access
Control Lists (ACLs).
o 'routing-profile-identifier': A routing profile refers to a set of
routing policies that will be invoked (e.g., BGP policies).
+--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 forwarding-profile-identifier* [id]
| | +--rw id string
| +--rw routing-profile-identifier* [id]
| +--rw id string
+--rw vpn-services
...
Figure 4: VPN Profiles Subtree Structure
7.3. Modeling a Layer 3 VPN Service
The 'vpn-service' is the data structure that abstracts a VPN service
in the service provider network. Each 'vpn-service' is uniquely
identified by an identifier: 'vpn-id'. Such 'vpn-id' is only identified by an identifier: 'vpn-id'. Such 'vpn-id' is only
meaningful locally within the Network controller. meaningful locally within the Network controller.
In order to facilitate the identification of the service, 'customer- In order to facilitate the identification of the service, 'customer-
name' and 'description' attributes may be provided. name' and 'description' attributes may be provided.
The 'vpn-service' parameters are: The main 'vpn-service' parameters are:
o 'service-status': Allows the control of the operative and o 'status': Allows the control of the operative and administrative
administrative status of the service as a whole. status of the service as a whole.
o 'vpn-id': Is an identifier that is used to uniquely identify the o 'vpn-id': Is an identifier that is used to uniquely identify the
L3VPN Service within L3NM scope. L3VPN Service within L3NM scope.
o 'l3sm-vpn-id': Refers to an identifier of L3SM service. This o 'l3sm-vpn-id': Refers to an identifier of L3SM service. This
identifier allows to easily correlate the (network) service as identifier allows to easily correlate the (network) service as
built in the network with a service order. built in the network with a service order.
o 'vpn-service-topology': Indicates the network topology for the o 'vpn-service-topology': Indicates the network topology for the
service: Hub-Spoke, Any-to-Any, and Custom. The deployment on the service: Hub-Spoke, Any-to-Any, and Custom. The deployment on the
network is defined by the correct usage of import and export network is defined by the correct usage of import and export
profiles profiles
o 'vpn-type': Indicate the VPN service signaling type.
o 'ie-profiles': Defines reusable import/export policies for the o 'ie-profiles': Defines reusable import/export policies for the
same 'vpn-service'. More details are provided in Section 6.3.3 same 'vpn-service'. More details are provided in Section 7.3.2.
o 'underlay-transport': Describes the preference for the transport o 'underlay-transport': Describes the preference for the transport
technology to carry the traffic of the VPN service. technology to carry the traffic of the VPN service
(Section 7.3.3).
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 service is typically built by adding instances of 'vpn-node' to A VPN service is typically built by adding instances of 'vpn-node' to
the 'vpn-nodes' container. The 'vpn-node' is an abstraction that the 'vpn-nodes' container.
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 A 'vpn-node' contains 'vpn-network-accesses', which are the
interfaces attached to the VPN by which the customer traffic is interfaces attached to the VPN by which the customer traffic is
received. Therefore, the customer sites are connected to the 'vpn- received. Therefore, the customer sites are connected to the 'vpn-
network-accesses'. Note that, as this is a network data model, the network-accesses'.
information about customers sites is not required in the model. Such
information, is rather relevant in the L3SM model.
+--rw vpn-service* [vpn-id] Note that, as this is a network data model, the information about
+--rw service-status customers sites is not required in the model. Such information is
| ... rather relevant in the L3SM.
+--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 +--rw l3vpn-ntw
+--rw vpn-profiles
| ...
+--rw vpn-services
+--rw vpn-service* [vpn-id]
+--rw status
| ...
+--rw vpn-id vpn-common:vpn-id
+--rw vpn-name? string
+--rw vpn-description? string
+--rw customer-name? string
+--rw l3sm-vpn-id? vpn-common:vpn-id
+--rw vpn-type? identityref
+--rw vpn-service-topology? identityref
+--rw ie-profiles
| ...
+--rw underlay-transport
| ...
+--rw vpn-nodes
...
6.3.1. Service Status Figure 5: VPN Services Subtree Structure
The L3NM module allows to track service status ('service-status') of 7.3.1. Service Status
a given VPN service (Figure 6). Both operational and administrative
status are maintained together with a timestamp. For example, a The L3NM allows to track service status ('status') of a given VPN
service can be created but not put into effect. 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 'admin' and 'ops' status can be used as trigger to detect service
anomalies. For example, a service that is declared at the service anomalies. For example, a service that is declared at the service
layer as active but still inactive at the network layer is an layer as active but still inactive at the network layer is an
indication that network provision actions are needed to align the indication that network provision actions are needed to align the
observed service with the expected service status. observed service with the expected service status.
+--rw 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]
+--rw service-status +--rw status
| +--rw admin | +--rw admin-status
| | +--rw status? operational-type | | +--rw status? identityref
| | +--rw timestamp? yang:date-and-time | | +--rw last-updated? yang:date-and-time
| +--ro ops | +--ro oper-status
| +--ro status? operational-type | +--ro status? identityref
| +--ro timestamp? yang:date-and-time | +--ro last-updated? yang:date-and-time
... ...
Figure 6: VPN Service Status Tree Structure Figure 6: VPN Service Status Subtree Structure
6.3.2. VPN Node 7.3.2. Concept of Import/Export Profiles
The import and export profiles construct contains a list with
information related with route target and distinguishers (RTs and
RDs), grouped and identified by 'ie-profile-id'. The identifier is
then referenced in one or multiple 'vpn-nodes' so the controller can
identify RTs and RDs to be configured for a given VRF. The subtree
is shown in Figure 7.
+--rw l3vpn-ntw
+--rw vpn-profiles
| ...
+--rw vpn-services
+--rw vpn-service* [vpn-id]
+--rw vpn-id vpn-common:vpn-id
+ ...
+--rw ie-profiles
| +--rw ie-profile* [ie-profile-id]
| +--rw ie-profile-id string
| +--rw rd? union
| +--rw vpn-targets
| +--rw vpn-target* [id]
| | +--rw id int8
| | +--rw route-targets* [route-target]
| | | +--rw route-target rt-types:route-target
| | +--rw route-target-type
| | rt-types:route-target-type
| +--rw vpn-policies
| +--rw import-policy? string
| +--rw export-policy? string
+--rw vpn-nodes
+--rw vpn-node* [ne-id]
+--rw ne-id string
...
+--rw vpn-targets
| +--rw vpn-target* [id]
| | +--rw id int8
| | +--rw route-targets* [route-target]
| | | +--rw route-target rt-types:route-target
| | +--rw route-target-type
| | rt-types:route-target-type
| +--rw vpn-policies
| +--rw import-policy? string
| +--rw export-policy? string
...
Figure 7: Subtree Structure of Import/Export Profiles
7.3.3. Underlay Transport
The model allows to indicate a preference for the underlay transport
technology when activating a L3VPN service (Figure 8). This
preference is especially useful in networks with multiple domains and
NNI types. This version of the YANG module supports these options:
BGP, LDP, GRE, SR, SR-TE, and RSVP-TE as underlay transport
mechanisms. Other profiles can be defined in the future.
+--rw l3vpn-ntw
+--rw vpn-profiles
| ...
+--rw vpn-services
+--rw vpn-service* [vpn-id]
+--rw vpn-id vpn-common:vpn-id
+ ...
+--rw underlay-transport
| +--rw type* identityref
+--rw vpn-nodes
+--rw vpn-node* [ne-id]
...
Figure 8: Subtree Structure of the Underlying Transport
7.3.4. 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 on 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 nodes where to one L3VPN service. In order to indicate the network nodes where
the 'vpn-node' applies, the 'ne-id' must be indicated. The 'vpn- the 'vpn-node' applies, the 'ne-id' must be indicated. The 'vpn-
node' includes a parameter to indicate the network node on which it node' includes a parameter to indicate the network node on which it
is applied. In the case that the 'ne-id' points to a specific PE, is applied. In the case that the 'ne-id' points to a specific PE,
the 'vpn-node' will likely be mapped into a VRF in the node. the 'vpn-node' will likely be mapped into a VRF in the node.
However, the model also allows to point to an abstract node. In this However, the model also allows to point to an abstract node. In this
case, the network controller will decide how to split the 'vpn-node' case, the network controller will decide how to split the 'vpn-node'
into VRFs. Soem 'vpn-node' parameters are listed below: into VRFs. Some 'vpn-node' parameters are listed below:
o local-autonomous-system: Refers to the autonomous system number o local-autonomous-system: Refers to the autonomous system number
that is locally configured in the instance. It can be overwritten that is locally configured in the instance. It can be overwritten
for specific purposes in the CE-PE BGP session. for specific purposes in the CE-PE BGP session.
o maximum-routes: Set the maximum number of prefixes allowed in the o maximum-routes: Set the maximum number of prefixes allowed in the
'vpn-node' instance. This value is typically set in the service 'vpn-node' instance. This value is typically set in the service
request. request.
o 'rd' and 'vpn-targets': For the cases the logical resources are o 'rd' and 'vpn-targets': For the cases the logical resources are
managed outside the network controller, the model allows to managed outside the network controller, the model allows to
explicitely indicate the logical resources such as Route targets explicitely indicate the logical resources such as Route targets
(RTs) and Route Distinguishers (RDs) (RT,RD). (RTs) and Route Distinguishers (RDs) (RT,RD).
o Multicast: Enable multicast traffic inside the VPN. Refer to o Multicast: Enable multicast traffic inside the VPN. Refer to
Section 6.3.2.4. Section 7.3.4.3.
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 rw rd? union
+--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 Under the VPN Node ('vpn-node') container, VPN Network Accesses
('vpn-network-access') can be created. The VPN Network Access
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 (i.e., the PE
side of PE-CE connections). Hence, the VPN Network access contains
the connectivity information between the provider's network and the
customer premises. The VPN profiles ('vpn-profiles') have a set of
routing policies than can be applied during the service creation.
The L3NM module allows to track the status ('status') of the nodes The L3NM allows to track the status ('status') of the nodes involved
involved in a VPN service (Figure 8). Both operational and in a VPN service. Both operational and administrative status are
administrative status are maintained. Mismatch between an maintained. Mismatch between an administrative status vs. the
administrative status vs. the operational status can be used as operational status can be used as trigger to detect anomalies.
trigger to detect anomalies.
+--rw 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]
+--rw vpn-id l3vpn-svc:svc-id +--rw vpn-id vpn-common:vpn-id
... ...
+--rw vpn-nodes +--rw vpn-nodes
| +--rw vpn-node* [ne-id] +--rw vpn-node* [ne-id]
| +--rw ne-id string +--rw vpn-node-id? union
| ... +--rw local-autonomous-system? inet:as-number
| +--rw status +--rw description? string
| | +--rw admin-enabled? boolean +--rw ne-id string
| | +--ro oper-status? operational-type +--rw router-id? inet:ip-address
+--rw address-family?
| vpn-common:address-family
+--rw node-role? identityref
+--rw rd? union
+--rw vpn-targets
| +--rw vpn-target* [id]
| | +--rw id int8
| | +--rw route-targets* [route-target]
| | | +--rw route-target rt-types:route-target
| | +--rw route-target-type
| | rt-types:route-target-type
| +--rw vpn-policies
| +--rw import-policy? string
| +--rw export-policy? string
+--rw status
| +--rw admin-status
| | +--rw status? identityref
| | +--rw last-updated? yang:date-and-time
| +--ro oper-status
| +--ro status? identityref
| +--ro last-updated? yang:date-and-time
+--rw node-ie-profile? leafref
+--rw groups
| +--rw group* [group-id]
| +--rw group-id string
+--rw vpn-network-accesses
| +--rw vpn-network-access* [id]
| ...
+--rw maximum-routes
| +--rw address-family* [af]
| +--rw af
| | vpn-common:address-family
| +--rw maximum-routes? uint32
+--rw multicast {vpn-common:multicast}?
...
Figure 8: Node Status Tree Structure Figure 9: VPN Node Subtree Structure
6.3.2.2. RT/RD Assignment/auto-assignment 7.3.4.1. RT/RD Assignment/auto-assignment
For the cases the logical resources are managed outside the network For the cases the logical resources are managed outside the network
controller, the model allows to explicitely indicate the logical controller, the model allows to explicitely indicate the logical
resources such as Route targets (RTs) and Route Distinguishers (RDs) resources such as Route targets (RTs) and Route Distinguishers (RDs)
(RT,RD). (RT,RD).
Three possible behaviors are needed to fulfil the identified use Three possible behaviors are needed to fulfil the identified use
cases: cases:
o The network controller auto-assigns logical resources (RTs, RDs). o The network controller auto-assigns logical resources (RTs, RDs).
skipping to change at page 17, line 12 skipping to change at page 20, line 5
RD to be assigned. This case will fit in VRF-Lite scenarios, CE RD to be assigned. This case will fit in VRF-Lite scenarios, CE
testing inside the Network or just for troubleshooting pruposes. testing inside the Network or just for troubleshooting pruposes.
Thus a union between two yang data types are included in order to Thus a union between two yang data types are included in order to
support this scenarios. So, if the leaf is not created in the Yang support this scenarios. So, if the leaf is not created in the Yang
the expected behavior is the auto-assigns. If the Leaf is created the expected behavior is the auto-assigns. If the Leaf is created
with a valid rd value it will be explicitly assign in the VPN Node with a valid rd value it will be explicitly assign in the VPN Node
and if the leaf is created with an empty value, the RD value will not and if the leaf is created with an empty value, the RD value will not
be deployed in the VPN node. be deployed in the VPN node.
6.3.2.3. VPN Network Access 7.3.4.2. VPN Network Access
A 'vpn-network-access' represents an entry point to a VPN service A 'vpn-network-access' represents an entry point to a VPN service
(Figure 9). In other words, this container encloses the parameters (Figure 10). In other words, this container encloses the parameters
that describe the access information for the traffic that belongs to that describe the access information for the traffic that belongs to
a particular L3VPN. As such, every 'vpn-network-access' MUST belong a particular L3VPN. As such, every 'vpn-network-access' MUST belong
to one and only one 'vpn-node'. to one and only one 'vpn-node'.
A 'vpn-network-access' includes information such as the connection on A 'vpn-network-access' includes information such as the connection on
which the access is defined (see Section 6.3.2.3.1), the which the access is defined (see Section 7.3.4.2.1), the
encapsulation of the traffic, policies that are applied on the encapsulation of the traffic, policies that are applied on the
access, etc. access, etc.
A provisioning Network Controller (PNC) [RFC8453] will accept VPN Each 'vpn-network-access' SHOULD have a 'vpn-network-access-type' to
requests containing this construct, using the enclosed data to: select the type of network interface to be deployed in the devices.
configure the router's interface to include the parameters described The available options are:
at the 'vpn-network-access', include the given interface into a VRF,
configuring policies or schedulers for processing the incoming
traffic, etc.
module: ietf-l3vpn-ntw o Point-to-Point: The point-to-point type represent a direct
+--rw l3vpn-ntw connection between the end-points. It implies the controller must
+--rw vpn-profiles keep the association between a logical or physical interface on
| ... the device with the 'id' of the vpn-network-access.
+--rw vpn-services
o Multipoint: This option represents a broadcast connection between
two end-points. It implies the controller must keep the
association between a logical or physical interface on the device
with the 'id' of the 'vpn-network-access'.
o Pseudowire: Represent a connection coming from an L2VPN service.
It implies the controller must keep the relationship between the
logical tunnels or bridges on the devices with the 'id' of the'
vpn-network-access'.
o Loopback: It represents the creation of a logical interface on the
devices.
A PNC [RFC8453] will accept VPN requests containing this construct,
using the enclosed data to: configure the router's interface to
include the parameters described at the 'vpn-network-access', include
the given interface into a VRF, configuring policies or schedulers
for processing the incoming traffic, etc.
...
+--rw vpn-services
+--rw vpn-service* [vpn-id] +--rw vpn-service* [vpn-id]
+--rw vpn-id l3vpn-svc:svc-id +--rw vpn-id vpn-common:vpn-id
+ ... + ...
+--rw vpn-node* [ne-id] +--rw vpn-node* [ne-id]
+--rw ne-id string +--rw ne-id string
+ ... + ...
+--rw vpn-network-accesses +--rw vpn-network-accesses
| +--rw vpn-network-access* [id] | +--rw vpn-network-access* [id]
| +--rw id | +--rw id
| | l3vpn-svc:svc-id | | vpn-common:vpn-id
| +--rw port-id? | +--rw port-id?
| | l3vpn-svc:svc-id | | vpn-common:vpn-id
| +--rw description? string | +--rw description? string
| +--rw status | +--rw status
| | +--rw admin-enabled? boolean | | +--rw admin-enabled? boolean
| | +--ro oper-status? operational-type | | +--ro oper-status? operational-type
| +--rw vpn-network-access-type? identityref | +--rw vpn-network-access-type? identityref
| +--rw connection | +--rw connection
| | ... | | ...
| | +--rw bearer
| | ...
| +--rw ip-connection | +--rw ip-connection
| | ... | | ...
| +--rw security | +--rw security
| | ... | | ...
| +--rw routing-protocols | +--rw routing-protocols
| | ... | | ...
| +--rw service | +--rw service
| ... | ...
| ... ...
Figure 9: VPN Network Access Tree Structure Figure 10: VPN Network Access Tree Structure
6.3.2.3.1. Connection 7.3.4.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 Layer 2 connectivity from where the traffic of the L3VPN in a
VPN Network access is coming. particular VPN Network access is coming.
Additionally, the bearer-reference and the pseudowire termination are
supported.
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.
module: ietf-l3vpn-ntw ...
+--rw l3vpn-ntw +--rw vpn-services
+--rw vpn-profiles
| ...
+--rw vpn-services
+--rw vpn-service* [vpn-id] +--rw vpn-service* [vpn-id]
+--rw vpn-id l3vpn-svc:svc-id +--rw vpn-id vpn-common:vpn-id
+ ... + ...
+--rw vpn-node* [ne-id] +--rw vpn-node* [ne-id]
+--rw ne-id string +--rw ne-id string
+ ... + ...
+--rw vpn-network-accesses +--rw vpn-network-accesses
| +--rw vpn-network-access* [id] | +--rw vpn-network-access* [id]
| +--rw id | +--rw id
| | l3vpn-svc:svc-id | | vpn-common:vpn-id
| + ... | ...
| +--rw connection | +--rw connection
| | +--rw encapsulation-type? identityref | | +--rw encapsulation-type? identityref
| | +--rw logical-interface | | +--rw logical-interface
| | | +--rw peer-reference? uint32 | | | +--rw peer-reference? uint32
| | +--rw tagged-interface | | +--rw tagged-interface
| | | +--rw type? identityref | | | +--rw type? identityref
| | | +--rw dot1q-vlan-tagged {dot1q}? | | | +--rw dot1q-vlan-tagged
| | | | {vpn-common:dot1q}?
| | | | +--rw tag-type? identityref | | | | +--rw tag-type? identityref
| | | | +--rw cvlan-id? uint16 | | | | +--rw cvlan-id? uint16
| | | +--rw priority-tagged | | | +--rw priority-tagged
| | | | +--rw tag-type? identityref | | | | +--rw tag-type? identityref
| | | +--rw qinq {qinq}? | | | +--rw qinq {vpn-common:qinq}?
| | | | +--rw tag-type? identityref | | | | +--rw tag-type? identityref
| | | | +--rw svlan-id uint16 | | | | +--rw svlan-id uint16
| | | | +--rw cvlan-id uint16 | | | | +--rw cvlan-id uint16
| | | +--rw qinany {qinany}? | | | +--rw qinany {vpn-common:qinany}?
| | | | +--rw tag-type? identityref | | | | +--rw tag-type? identityref
| | | | +--rw svlan-id uint16 | | | | +--rw svlan-id uint16
| | | +--rw vxlan {vxlan}? | | | +--rw vxlan {vpn-common:vxlan}?
| | | +--rw vni-id uint32 | | | +--rw vni-id uint32
| | | +--rw peer-mode? identityref | | | +--rw peer-mode? identityref
| | | +--rw peer-list* [peer-ip] | | | +--rw peer-list* [peer-ip]
| | | +--rw peer-ip inet:ip-address | | | +--rw peer-ip inet:ip-address
| | +--rw bearer | | +--rw bearer
| | ... | | ...
| +--rw ip-connection ...
| | ...
| +--rw security
| | ...
| +--rw routing-protocols
| | ...
| +--rw service
| ...
| ...
Figure 10: Encapsulation Tree Structure
Depending on the control plane implementation, different network Figure 11: Encapsulation Subtree Structure
scenarios might require additional information for the L3VPN 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
reflector, may require additional configuration (e.g., a new BGP
neighbor) to be coordinated between both management systems. This
definition requires for every management system participant in the
VPN to receive not just their own sites and site-network-accesses,
but also to receive information about external ones, identified as an
external site-network-access-type. In addition, this particular
site-network-access is augmented to include the loopback address of
the far-end (remote/external) PE router.
module: ietf-l3vpn-ntw Additionally, the 'bearer-reference' and the pseudowire termination
+--rw l3vpn-ntw are supported (see Figure 12). A site, as per [RFC4176] represents a
+--rw vpn-profiles VPN customer's location that is connected to the Service Provider
| ... network via a CE-PE link, which can access at least one VPN. The
+--rw vpn-services connection from the site to the Service Provider network is the
+--rw vpn-service* [vpn-id] bearer. Every site is associated with a list of bearers. A bearer
+--rw vpn-id l3vpn-svc:svc-id is the layer two connections with the site. In the module it is
+ ... assumed that the bearer has been allocated by the Service Provider at
+--rw vpn-node* [ne-id] the service orchestration step. The bearer is associated to a
+--rw ne-id string network element and a port. Hence, a bearer is just a bearer-
+ ... reference to allow the translation between L3SM and L3NM.
+--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
| ...
| ...
Figure 11: Bearer Tree Structure ...
+--rw vpn-network-accesses
| +--rw vpn-network-access* [id]
| +--rw id
| | vpn-common:vpn-id
| ...
| +--rw vpn-network-access-type? identityref
| +--rw connection
| | ...
| | +--rw bearer
| | +--rw bearer-reference? string
| | | {vpn-common:bearer-reference}?
| | +--rw pseudowire
| | | +--rw vcid? uint32
| | | +--rw far-end? union
| | +--rw vpls
| | +--rw vcid? union
| | +--rw far-end? union
| ...
A site, as per [RFC4176] represents a VPN customer's location that is Figure 12: Bearer Subtree Structure
connected to the Service Provider network via a CE-PE link, which can
access at least one VPN. The connection from the site to the Service
Provider network is the bearer. Every site is associated with a list
of bearers. A bearer is the layer two connections with the site. In
the module it is assumed that the bearer has been allocated by the
Service Provider at the service orchestration step. The bearer is
associated to a network element and a port. Hence, a bearer is just
a bearer-reference to allow the translation between L3SM and L3NM.
6.3.2.3.2. IP Connections 7.3.4.2.2. IP Connections
IP connection container (Figure 12) has the parameters of the 'vpn- IP connection container (Figure 13) has the parameters of the 'vpn-
network-access' addressing information. The address allocated in network-access' addressing information. The address allocated in
this container would represent the PE interface address this container would represent the PE interface address
configuration. The IP connection container is designed to support configuration. The IP connection container is designed to support
both IPv4 and IPv6. It also supports three options for IP address both IPv4 and IPv6. It also supports three IP address assignment
assignment: Provider DHCP, DHCP relay, and static addressing. modes: SLAAC [RFC7527], Provider DHCP, DHCP relay, and static
addressing. Only one of them is enabled for a given service.
In the case of the static addressing, the model supports the ...
assignment of several IP addresses in the same 'vpn-network-access'. +--rw vpn-network-accesses
To identify which of the addresses is the primary address of a | +--rw vpn-network-access* [id]
connection ,the "primary-address" reference MUST be set with the | +--rw id
| | vpn-common:vpn-id
| ...
| +--rw vpn-network-access-type? identityref
| +--rw connection
| | ...
| +--rw ip-connection
| | +--rw ipv4 {vpn-common:ipv4}?
| | | +--rw address-allocation-type?
| | | | identityref
| | | +--rw (allocation-type)?
| | | +--:(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
| | | +--:(dhcp-relay)
| | | | +--rw dr-provider-address?
| | | | | inet:ipv4-address
| | | | +--rw dr-prefix-length?
| | | | | uint8
| | | | +--rw customer-dhcp-servers
| | | | +--rw server-ip-address*
| | | | inet:ipv4-address
| | | +--:(static-addresses)
| | | ...
| | +--rw ipv6 {vpn-common:ipv6}?
| | | +--rw address-allocation-type?
| | | | identityref
| | | +--rw (allocation-type)?
| | | +--:(provider-dhcp)
| | | | +--rw (provider-dhcp)?
| | | | +--:(provider-address)
| | | | | +--rw provider-address?
| | | | | inet:ipv6-address
| | | | +--:(prefix-length)
| | | | | +--rw prefix-length?
| | | | | uint8
| | | | +--:(address-assign)
| | | | +--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
| | | +--:(dhcp-relay)
| | | | +--rw dr-provider-address?
| | | | | inet:ipv6-address
| | | | +--rw dr-prefix-length?
| | | | | uint8
| | | | +--rw customer-dhcp-servers
| | | | +--rw server-ip-address*
| | | | inet:ipv6-address
| | | +--:(static-addresses)
| | | ...
Figure 13: IP Connection Subtree Structure
In the case of the static addressing (Figure 14), the model supports
the assignment of several IP addresses in the same 'vpn-network-
access'. To identify which of the addresses is the primary address
of a connection ,the 'primary-address' reference MUST be set with the
corresponding 'address-id'. corresponding 'address-id'.
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-accesses
| +--rw vpn-network-access* [id] | +--rw vpn-network-access* [id]
| +--rw id | +--rw id
| | l3vpn-svc:svc-id | | vpn-common:vpn-id
| + ... | ...
| +--rw connection | +--rw vpn-network-access-type? identityref
| | ... | +--rw connection
| +--rw ip-connection | | ...
| | +--rw ipv4 {l3vpn-svc:ipv4}? | +--rw ip-connection
| | | +--rw address-allocation-type? | | +--rw ipv4 {vpn-common:ipv4}?
| | | | identityref | | | +--rw address-allocation-type?
| | | +--rw provider-dhcp | | | | identityref
| | | | +--rw provider-address? | | | +--rw (allocation-type)?
| | | | | inet:ipv4-address | | | ...
| | | | +--rw prefix-length? | | | +--:(static-addresses)
| | | | | uint8 | | | +--rw primary-address?
| | | | +--rw (address-assign)? | | | | -> ../address/address-id
| | | | +--:(number) | | | +--rw address* [address-id]
| | | | | +--rw number-of-dynamic-address? | | | +--rw address-id
| | | | | uint16 | | | | string
| | | | +--:(explicit) | | | +--rw s-provider-address?
| | | | +--rw customer-addresses | | | | inet:ipv4-address
| | | | +--rw address-group* | | | +--rw s-customer-address?
| | | | [group-id] | | | | inet:ipv4-address
| | | | +--rw group-id | | | +--rw s-prefix-length?
| | | | | string | | | uint8
| | | | +--rw start-address? | | +--rw ipv6 {vpn-common:ipv6}?
| | | | | inet:ipv4-address | | | +--rw address-allocation-type?
| | | | +--rw end-address? | | | | identityref
| | | | inet:ipv4-address | | | +--rw (allocation-type)?
| | | +--rw dhcp-relay | | | ...
| | | | +--rw provider-address? | | | +--:(static-addresses)
| | | | | inet:ipv4-address | | | +--rw s-primary-address?
| | | | +--rw prefix-length? uint8 | | | | -> ../s-address/address-id
| | | | +--rw customer-dhcp-servers | | | +--rw s-address* [address-id]
| | | | +--rw server-ip-address* | | | +--rw address-id
| | | | inet:ipv4-address | | | | string
| | | +--rw static-addresses | | | +--rw provider-address?
| | | +--rw primary-address? leafref | | | | inet:ipv6-address
| | | +--rw address* [address-id] | | | +--rw customer-address?
| | | +--rw address-id string | | | | inet:ipv6-address
| | | +--rw provider-address? | | | +--rw prefix-length? uint8
| | | | 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 12: IP Connection Tree Structure Figure 14: IP Connection Subtree Structure: Static Mode
6.3.2.3.3. Security 7.3.4.2.3. Security
The 'security' container specifies the authentication and the The 'security' container specifies the authentication and the
encryption to be applied for a given VPN network access (Figure 13). encryption to be applied for a given VPN network access (Figure 15).
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-accesses
| +--rw vpn-network-access* [id] | +--rw vpn-network-access* [id]
| +--rw id | +--rw id
| | l3vpn-svc:svc-id | | vpn-common:vpn-id
| + ... | + ...
| +--rw connection | +--rw connection
| | ... | | ...
| +--rw ip-connection | +--rw ip-connection
| | ... | | ...
| +--rw security | +--rw security
| | +--rw authentication | | +--rw encryption {vpn-common:encryption}?
| | +--rw encryption {l3vpn-svc:encryption}?
| | | +--rw enabled? boolean | | | +--rw enabled? boolean
| | | +--rw layer? enumeration | | | +--rw layer? enumeration
| | +--rw encryption-profile | | +--rw encryption-profile
| | +--rw (profile)? | | +--rw (profile)?
| | | +--:(provider-profile) | | | +--:(provider-profile)
| | | | +--rw profile-name? leafref | | | | +--rw profile-name? leafref
| | | +--:(customer-profile) | | | +--:(customer-profile)
| | | +--rw algorithm? string | | | +--rw algorithm? string
| | +--rw (key-type)? | | +--rw (key-type)?
| | +--:(psk) | | +--:(psk)
| | +--rw preshared-key? string | | +--rw preshared-key? string
| +--rw routing-protocols | +--rw routing-protocols
| | ... | | ...
| +--rw service | +--rw service
| ... | ...
| ... | ...
Figure 13: Security Tree Structure Figure 15: Security Subtree Structure
6.3.2.3.4. CE PE Routing Protocols 7.3.4.2.4. CE-PE Routing Protocols
The model allows the Provider to configure one or more routing The model allows the Provider to configure one or more routing
protocols associated with a particular 'vpn-network-access' protocols associated with a particular 'vpn-network-access'
(Figure 14). This protocol will run between the PE and the CE. A (Figure 16). This protocol will run between the PE and the CE. A
routing protocol instance MUST have a type (e.g., bgp, ospf) and an routing protocol instance MUST have a type (e.g., bgp, ospf) and an
identifier. The identifier is necessary when multiple instances of identifier. The identifier is necessary when multiple instances of
the same protocol have to be configured. the same protocol have to be configured.
...
+--rw vpn-network-accesses
| +--rw vpn-network-access* [id]
| +--rw id
| | vpn-common:vpn-id
| ...
| +--rw ip-connection
| | ...
| +--rw routing-protocols
| | +--rw routing-protocol* [id]
| | +--rw id string
| | +--rw type? identityref
| | +--rw routing-profiles* [id]
| | | +--rw id leafref
| | | +--rw type? identityref
| | +--rw ospf {vpn-common:rtg-ospf}?
| | | ...
| | +--rw bgp {vpn-common:rtg-bgp}?
| | | ...
| | +--rw isis {vpn-common:rtg-isis}?
| | | ...
| | +--rw static
| | | ...
| | +--rw rip {vpn-common:rtg-rip}?
| | | +--rw address-family*
| | | vpn-common:address-family
| | +--rw vrrp {vpn-common:rtg-vrrp}?
| | +--rw address-family*
| | vpn-common:address-family
| +--rw service
| ...
...
Figure 16: Routing Subtree Structure
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'.
When configuring multiple instances of the same routing protocol, When configuring multiple instances of the same routing protocol,
this does not automatically imply that, from a device configuration this does not automatically imply that, from a device configuration
perspective, there will be parallel instances (multiple processes) perspective, there will be parallel instances (multiple processes)
running. It will be up to the implementation to use the most running. It will be up to the implementation to use the most
appropriate deployment model. As an example, when multiple BGP peers appropriate deployment model. As an example, when multiple BGP peers
need to be implemented, multiple instances of BGP must be configured need to be implemented, multiple instances of BGP must be configured
as part of this model. However, from a device configuration point of as part of this model. However, from a device configuration point of
view, this could be implemented as: view, this 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 CE-PE
protocols: routing protocols:
o VRRP: takes only a list of address-family as parameter. VRRP
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 BGP: allows to configure a BGP neighbor including parameters like
authentication using a key. The authentication type will be
driven by the implementation but the module supports any
authentication that uses a key as a parameter. A BGP neighbor can
support IPv4, IPv6, or both address families. The module supports
supplying two neighbors (each for a given address family) or one
neighbor (for both IPv4 and IPv6 of "address-family" attribute is
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-
access interface. An OSPF instance can run ipv4, ipv6 or both.
When only ipv4 address-family is requested, it will be up to the
implementation to drive if OSPFv2 or v3 is used.
o IS-IS: allows the user to configure IS-IS to run on the vpn-
network-access interface. An IS-IS instance can run L1, L2 or
both levels.
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 14: Routing Tree Structure
6.3.2.3.5. Services
The 'services' container specifies the service parameter to apply for
a give VPN network access (Figure 15). The following attributes are
defined:
o TBC
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 connection
| | ...
| +--rw ip-connection
| | ...
| +--rw security
| | ...
| +--rw routing-protocols
| | ...
| +--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)
| | | | | | | ...
| | | | | | +--:(ipv6)
| | | | | | ...
| | | | | +--rw (l4)?
| | | | | +--:(tcp)
| | | | | | ...
| | | | | +--:(udp)
| | | | | ...
| | | | +--:(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 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
| ...
Figure 15: Services Tree Structure
6.3.2.4. Multicast
Multicast MAY be enabled for a particular vpn-network-node (see
Figure 16).
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 16: Multicast Tree Structure
6.3.3. Concept of Import/Export Profiles
The import and export profiles construct contains a list with o OSPF: The model (Figure 17) allows the user to configure OSPF to
information related with route target and distinguishers (RTs and run as routing protocol on the 'vpn-network-access interface'. An
RDs), grouped and identified by ie-profile-id. The identifier is OSPF instance can be bound to IPv4, IPv6 or both. When only IPv4
then referenced in one or multiple vpn-nodes, so the PNC can identify address-family is requested, it will be up to the implementation
RTs and RDs to be configured in the VRF. to drive whether OSPFv2 or OSPFv3 is used.
6.3.4. Underlay Transport ...
+--rw vpn-network-accesses
| +--rw vpn-network-access* [id]
| +--rw id
| | vpn-common:vpn-id
| ...
| +--rw ip-connection
| | ...
| +--rw routing-protocols
| | +--rw routing-protocol* [id]
| | +--rw id string
| | +--rw type? identityref
| | +--rw routing-profiles* [id]
| | | +--rw id leafref
| | | +--rw type? identityref
| | +--rw ospf {vpn-common:rtg-ospf}?
| | | +--rw address-family*
| | | | vpn-common: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
| | | {vpn-common:rtg-ospf-sham-link}?
| | | +--rw sham-link* [target-site]
| | | +--rw target-site
| | | | vpn-common:vpn-id
| | | +--rw metric? uint16
| | +--rw bgp {vpn-common:rtg-bgp}?
| | | ...
| | +--rw isis {vpn-common:rtg-isis}?
| | | ...
| | +--rw static
| | | ...
| | +--rw rip {vpn-common:rtg-rip}?
| | | ...
| | +--rw vrrp {vpn-common:rtg-vrrp}?
| | ...
| +--rw service
| ...
...
The model allows to indicate a preference for the underlay transport Figure 17: OPSF Routing Subtree Structure
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.
Other profiles can be defined in the future. o BGP: The model (Figure 18) allows to configure a BGP neighbor,
including a set for parameters that are pertinent to be tweaked at
the network level for service customization purposes. This
container does not aim to include every BGP parameter; a
comprehensive set of parameters belongs more to the BGP device
model. The following parameters are captured in Figure 18. It is
up to the implementation to drive the corresponding BGP device
configuration.
This document does not make any assumption about the exact definition * 'peer-autonomous-system': This parameter conveys the Customer's
of these profiles. How such profiles are defined is deployment- AS Number (ASN).
specific.
7. L3NM Module Tree Structure * 'local-autonomous-system': This parameter is set of AS override
is activated for this peer.
The L3NM Module Tree Structure is depicted in Figure 17. * 'address-family': This attribute indicates the address-family
of the peer. It can be set to IPv4, IPv6, or both address-
families.
module: ietf-l3vpn-ntw * 'neighbor': The module supports supplying two neighbors (each
+--rw l3vpn-ntw for a given address-family) or one neighbor (if 'address-
+--rw vpn-profiles family' attribute is set to both IPv4 and IPv6 address-
| +--rw valid-provider-identifiers families). A list of IP address(es) of the BGP neighbor can be
| +--rw cloud-identifier* [id] {l3vpn-svc:cloud-access}? then conveyed in this parameter.
| | +--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 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* protocol-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? union
+--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* [profile]
| | +--rw profile -> /l3vpn-ntw/...
| | +--rw direction? identityref
| +--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
Figure 17 * 'multihop': This attribute indicates the number of allowed IP
hops between a BGP peer and a PE.
8. Sample Uses of the L3NM Data Model * 'security': The authentication type will be driven by the
implementation but the module supports any authentication that
uses a key as a parameter.
8.1. Enterprise L3 VPN Services * 'as-override': If set, this parameter indicates whether AS
override is enabled, i.e., replace the ASN of the peer
specified in the AS Path attribute with the ASN identified by
the 'local-autonomous-system' attribute.
Enterprise L3VPNs are one of the most demanded services for carriers, * 'default-route': This attribute controls whether default
and therefore, L3NM can be useful to automate the tasks of route(s) can be advertised to the peer.
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.
Also common addition/removal of sites of an existing customer VPN can * 'bgp-max-prefix': This attribute is used to control how many
benefit of using L3NM, by creation of workflows that either prune or prefixes can be received from a neighbor. If reached, the BGP
add nodes as required from the network data model object. session will be teared down.
8.2. Multi-Domain Resource Management * 'bgp-timer': Two timers can be captured in this container: (1)
'hold-time' which is the time interval that will be used for
the HoldTimer (Section 4.2 of [RFC4271]) when establishing a
BGP session. (2) 'keep-alive' which is the time interval for
the KeepAlive timer between a PE and a BGP peer (Section 4.4 of
[RFC4271]).
The implementation of L3VPN services which span across ...
administratively separated domains (i.e., that are under the +--rw vpn-network-accesses
administration of different management systems or controllers) | +--rw vpn-network-access* [id]
requires some network resources to be synchronized between systems. | +--rw id
Particularly, there are two resources that must be orchestrated and | | vpn-common:vpn-id
manage to avoid asymmetric (non-functional) configuration, or the | ...
usage of unavailable resources. | +--rw ip-connection
| | ...
| +--rw routing-protocols
| | +--rw routing-protocol* [id]
| | +--rw id string
| | +--rw type? identityref
| | +--rw routing-profiles* [id]
| | | +--rw id leafref
| | | +--rw type? identityref
| | +--rw ospf {vpn-common:rtg-ospf}?
| | | ...
| | +--rw bgp {vpn-common:rtg-bgp}?
| | | +--rw peer-autonomous-system
| | | | inet:as-number
| | | +--rw local-autonomous-system?
| | | | inet:as-number
| | | +--rw address-family*
| | | | vpn-common:address-family
| | | +--rw neighbor*
| | | | inet:ip-address
| | | +--rw multihop? uint8
| | | +--rw security
| | | | +--rw auth-key? string
| | | +--rw status
| | | | +--rw admin-status
| | | | | +--rw status? identityref
| | | | | +--rw last-updated?
| | | | | | yang:date-and-time
| | | | +--ro oper-status
| | | | +--ro status? identityref
| | | | +--ro last-updated?
| | | | yang:date-and-time
| | | +--rw description? string
| | | +--rw as-override? boolean
| | | +--rw default-route? boolean
| | | +--rw bgp-max-prefix
| | | | +--rw max-prefix? uint32
| | | | +--rw warning-threshold? decimal64
| | | | +--rw violate-action? enumeration
| | | | +--rw restart-interval? uint16
| | | +--rw bgp-timer
| | | +--rw keep-alive? uint16
| | | +--rw hold-time? uint16
| | +--rw isis {vpn-common:rtg-isis}?
| | | ...
| | +--rw static
| | | ...
| | +--rw rip {vpn-common:rtg-rip}?
| | | ...
| | +--rw vrrp {vpn-common:rtg-vrrp}?
| | ...
| +--rw service
| ...
...
For example, RTs shall be synchronized between PEs. When every PE is Figure 18: BGP Routing Subtree Structure
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.
8.3. Management of Multicast services o IS-IS: The model (Figure 19) allows the user to configure IS-IS to
run on the 'vpn-network-access' interface. An IS-IS instance can
run L1, L2, or both levels.
Multicast services over L3VPN can be implemented either using dual ...
PIM MVPNs (also known as Draft Rosen model) [RFC 4364] or +--rw vpn-network-accesses
multiprotocol BGP (MBGP)-based MVPNs called Next Generation Multicast | +--rw vpn-network-access* [id]
VPN (ng-MVPN) [RFC 6513/6514]. Both methods are supported and | +--rw id
equally effective, but the main difference is that MBGP-based MVPN | | vpn-common:vpn-id
does not require multicast configuration on the service provider | ...
backbone. Multiprotocol BGP multicast VPNs employ the intra- | +--rw ip-connection
autonomous system (AS) next-generation BGP control plane and PIM | | ...
sparse mode as the data plane. The PIM state information is | +--rw routing-protocols
maintained between the PE routers using the same architecture that is | | +--rw routing-protocol* [id]
used for unicast VPNs. | | +--rw id string
| | +--rw type?
| | | identityref
| | +--rw routing-profiles* [id]
| | | +--rw id leafref
| | | +--rw type? identityref
| | +--rw ospf {vpn-common:rtg-ospf}?
| | | ...
| | +--rw bgp {vpn-common:rtg-bgp}?
| | | ...
| | +--rw isis {vpn-common:rtg-isis}?
| | | +--rw address-family*
| | | | vpn-common:address-family
| | | +--rw area-address
| | | | yang:dotted-quad
| | | +--rw level? identityref
| | | +--rw metric? uint16
| | | +--rw process-id? uint16
| | | +--rw mode? enumeration
| | | +--rw status
| | | +--rw admin-status
| | | | +--rw status?
| | | | | identityref
| | | | +--rw last-updated?
| | | | yang:date-and-time
| | | +--ro oper-status
| | | +--ro status?
| | | | identityref
| | | +--ro last-updated?
| | | yang:date-and-time
| | +--rw static
| | | ...
| | +--rw rip {vpn-common:rtg-rip}?
| | | ...
| | +--rw vrrp {vpn-common:rtg-vrrp}?
| | ...
| +--rw service
| ...
...
On the other hand, Draft Rosen has limitations such as reduced Figure 19: IS-IS Routing Subtree Structure
options for transport, control plane scalability, availability,
operational inconsistency and the need of maintaining state in the
backbone. Because of this, ng-MNPN is the architectural model that
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.
9. L3VPN Examples o RIP: The module covers only a list of address-family as parameter.
9.1. 4G VPN Provisioning Example o VRRP: The module covers only a list of address-family as
parameter.
L3VPNs are widely used to deploy 3G/4G, fixed, and enterprise The module allows a user to configure one or more IPv4 and/or IPv6
services mainly because several traffic discrimination policies can static routes as depicted in Figure 20.
be applied within the network to deliver to the mobile customers a
service that meets the SLA requirements.
As it is shown in the Figure 18, typically, an eNodeB (CE) is ...
directly connected to the access routers of the mobile backhaul and +--rw vpn-network-accesses
their logical interfaces (one or many according to the Service type) | +--rw vpn-network-access* [id]
are configured in a VPN that transports the packets to the mobile | +--rw id
core platforms. In this example, a 'vpn-node' is created with two | | vpn-common:vpn-id
'vpn-network-accesses'. | ...
| +--rw ip-connection
| | ...
| +--rw routing-protocols
| | +--rw routing-protocol* [id]
| | +--rw id string
| | +--rw type? identityref
| | +--rw routing-profiles* [id]
| | | +--rw id leafref
| | | +--rw type? identityref
| | +--rw ospf {vpn-common:rtg-ospf}?
| | | ...
| | +--rw bgp {vpn-common:rtg-bgp}?
| | | ...
| | +--rw isis {vpn-common:rtg-isis}?
| | | ...
| | +--rw static
| | | +--rw cascaded-lan-prefixes
| | | +--rw ipv4-lan-prefixes*
| | | | [lan next-hop]
| | | | {vpn-common:ipv4}?
| | | | +--rw lan
| | | | | inet:ipv4-prefix
| | | | +--rw lan-tag? string
| | | | +--rw next-hop
| | | | inet:ipv4-address
| | | +--rw ipv6-lan-prefixes*
| | | [lan next-hop]
| | | {vpn-common:ipv6}?
| | | +--rw lan
| | | | inet:ipv6-prefix
| | | +--rw lan-tag? string
| | | +--rw next-hop
| | | inet:ipv6-address
| | +--rw rip {vpn-common:rtg-rip}?
| | | ...
| | +--rw vrrp {vpn-common:rtg-vrrp}?
| | ...
| +--rw service
| ...
...
+-------------+ +------------------+ Figure 20: Static Routing Subtree Structure
| | | PE |
| | 192.168.0.2 | 10.0.0.1 |
| eNodeB |>--------/------->|........... |
| | Vlan 1 | | |
| |>--------/------->|...... | |
| | Vlan 2 | | | |
| | Direct | +-------------+ |
+-------------+ Routing | | vpn-node-id | |
| | 44 | |
| +-------------+ |
| |
+------------------+
Figure 18: Mobile Backhaul Example 7.3.4.2.5. Services
To create a L3VPN service using the L3NM model, the following sample The 'services' container specifies the service parameters to apply
steps can be followed: for a given VPN network access (Figure 21).
First: Create the 4G VPN Service (Figure 19). ...
+--rw vpn-network-accesses
| +--rw vpn-network-access* [id]
| +--rw id
| | vpn-common:vpn-id
| ...
| +--rw service
| +--rw svc-input-bandwidth uint64
| +--rw svc-output-bandwidth uint64
| +--rw svc-mtu uint16
| +--rw qos {vpn-common:qos}?
| | +--rw qos-classification-policy
| | | +--rw rule* [id]
| | | +--rw id
| | | | string
| | | +--rw (match-type)?
| | | | +--:(match-flow)
| | | | | +--rw (l3)?
| | | | | | +--:(ipv4)
| | | | | | | ...
| | | | | | +--:(ipv6)
| | | | | | ...
| | | | | +--rw (l4)?
| | | | | +--:(tcp)
| | | | | | ...
| | | | | +--:(udp)
| | | | | ...
| | | | +--:(match-application)
| | | | +--rw match-application?
| | | | identityref
| | | +--rw target-class-id?
| | | string
| | +--rw qos-profile
| | +--rw qos-profile* [profile]
| | +--rw profile leafref
| | +--rw direction? identityref
| +--rw carrierscarrier
| | {vpn-common:carrierscarrier}?
| | +--rw signalling-type? enumeration
| +--rw multicast {vpn-common:multicast}?
| +--rw site-type? enumeration
| +--rw address-family?
| | vpn-common:address-family
| +--rw protocol-type? enumeration
| +--rw remote-source? boolean
...
POST: /restconf/data/ietf-l3vpn-ntw:l3vpn-ntw/vpn-services Figure 21: Services Subtree Structure
Host: example.com
Content-Type: application/yang-data+json
{ The following attributes are defined:
"ietf-l3vpn-ntw:vpn-services": {
"vpn-service": [
"vpn-id": "4G",
"customer-name": "mycustomer",
"vpn-service-topology": "custom",
"description": "VPN to deploy 4G services"
]
}
}
Figure 19: Create VPN Service o 'svc-input-bandwidth': Indicates the inbound bandwidth of the
connection (i.e., download bandwidth from the SP to the site).
Second: Create a VPN Node as depicted in Figure 20. In this type of o 'svc-output-bandwidth': Indicates the outbound bandwidth of the
service, the VPN Node is equivalent to the VRF configured in the connection (i.e., upload bandwidth from the site to the SP).
physical device ('ne-id'=10.0.0.1).
POST: /restconf/data/ietf-l3vpn-ntw:l3vpn-ntw/\ o 'svc-mtu': Indicates the MTU at service level. It can be the IP
vpn-services/vpn-service=4G MTU or MPLS MTU, for example.
Host: example.com
Content-Type: application/yang-data+json
{ o 'carrierscarrier': Groups a set of parameters that are used when
"ietf-l3vpn-ntw:vpn-nodes": { CsC is enabled such the use of BGP for signalling purposes
"vpn-node": [ [RFC8277].
"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"
}
}
]
}
}
Figure 20: Create VPN Node o 'multicast': Specifies the multicast mode and other service-
related attributes such as the address-family.
Finally, two VPN Network Accesses are created using the same physical o 'qos': Is used to define QoS policies to apply on a given
port ('port-id'=1/1/1). Each 'vpn-network-access' has a particular connection. Classification can be based on many criteria such as:
VLAN (1,2) to differentiate the traffic between: Sync and data
(Figure 21).
POST: /restconf/data/ietf-l3vpn-ntw:l3vpn-ntw/\ * Layer 3: As shown in Figure 23, the model allow to classify
vpn-services/vpn-service=4G/vpn-nodes/vpn-node=44 based on any IP header field or a combination thereof. Both
content-type: application/yang-data+json IPv4 and IPv6 are supported.
{ +--rw qos {vpn-common:qos}?
"ietf-l3vpn-ntw:vpn-network-accesses": { | +--rw qos-classification-policy
"vpn-network-access": [ | | +--rw rule* [id]
{ | | +--rw id
"vpn-network-access-id": "1/1/1.1", | | | string
"port-id": "1/1/1", | | +--rw (match-type)?
"description": "Interface SYNC to eNODE-B", | | | +--:(match-flow)
"status": {"admin-enabled": "true"}, | | | | +--rw (l3)?
"vpn-network-access-type": "l3vpn-svc:point-to-point", | | | | | +--:(ipv4)
"ip-connection": { | | | | | | ...
"ipv4": { | | | | | +--:(ipv6)
"address-allocation-type": "l3vpn-svc:static-address", | | | | | ...
"static-addresses": { | | | | +--rw (l4)?
"primary-address": "1", | | | | +--rw (l3)?
"address": [ | | | | | +--:(ipv4)
"address-id": "1", | | | | | | +--rw ipv4
"provider-address": "192.168.0.1", | | | | | | +--rw dscp?
"customer-address": "192.168.0.1", | | | | | | | inet:dscp
"prefix-length": "32" | | | | | | +--rw ecn?
] | | | | | | | uint8
} | | | | | | +--rw length?
} | | | | | | | uint16
}, | | | | | | +--rw ttl?
"routing-protocols": { | | | | | | | uint8
"routing-protocol": [ | | | | | | +--rw protocol?
"id": "1", | | | | | | | uint8
"type": "l3vpn-svc:direct" | | | | | | +--rw ihl?
] | | | | | | | uint8
} | | | | | | +--rw flags?
}, | | | | | | | bits
{ | | | | | | +--rw offset?
"vpn-network-access-id": "1/1/1.2", | | | | | | | uint16
"port-id": "1/1/1", | | | | | | +--rw identification?
"description": "Interface DATA to eNODE-B", | | | | | | | uint16
"status": {"admin-enabled": "true"}, | | | | | | +--rw (destination-network)?
"ip-connection": { | | | | | | | +--:(destination-ipv4-network)
"ipv4": { | | | | | | | +--rw destination-ipv4-network?
"static-addresses": { | | | | | | | inet:ipv4-prefix
"primary-address": "1", | | | | | | +--rw (source-network)?
"address": [ | | | | | | +--:(source-ipv4-network)
"address-id": "1", | | | | | | +--rw source-ipv4-network?
"provider-address": "192.168.1.1", | | | | | | inet:ipv4-prefix
"customer-address": "192.168.1.2", | | | | | +--:(ipv6)
"prefix-length": "32" | | | | | +--rw ipv6
] | | | | | +--rw dscp?
} | | | | | | inet:dscp
} | | | | | +--rw ecn?
}, | | | | | | uint8
"routing-protocols": { | | | | | +--rw length?
"routing-protocol": [ | | | | | | uint16
"id": "1", | | | | | +--rw ttl?
"type": "l3vpn-svc:direct" | | | | | | uint8
] | | | | | +--rw protocol?
} | | | | | | uint8
} | | | | | +--rw (destination-network)?
] | | | | | | +--:(destination-ipv6-network)
} | | | | | | +--rw destination-ipv6-network?
} | | | | | | inet:ipv6-prefix
| | | | | +--rw (source-network)?
| | | | | | +--:(source-ipv6-network)
| | | | | | +--rw source-ipv6-network?
| | | | | | inet:ipv6-prefix
| | | | | +--rw flow-label?
| | | | | inet:ipv6-flow-label
| | | | +--rw (l4)?
| | | | +--:(tcp)
| | | | | ...
| | | | +--:(udp)
| | | | ...
...
Figure 21: Create VPN Network Access Figure 22: QoS Subtree Structure (L3)
9.2. Multicast VPN Provisioning Example * Layer 4: As shown in Figure 23, TCP or UDP-related match
crietria can be specified.
IPTV is mainly distributed through multicast over the LANs. In the +--rw qos {vpn-common:qos}?
following example, PIM-SM is enabled and functional between the PE | +--rw qos-classification-policy
and the CE. The PE receives multicast traffic from a CE that is | | +--rw rule* [id]
directly connected to the multicast source. The signaling between PE | | +--rw id
and CE is achieved using BGP. Also, RP is statically configured for | | | string
a multicast group. | | +--rw (match-type)?
| | | +--:(match-flow)
| | | | +--rw (l3)?
| | | | | +--:(ipv4)
| | | | | | ...
| | | | | +--:(ipv6)
| | | | | ...
| | | | +--rw (l4)?
| | | | +--:(tcp)
| | | | | +--rw tcp
| | | | | +--rw sequence-number?
| | | | | | uint32
| | | | | +--rw acknowledgement-number?
| | | | | | uint32
| | | | | +--rw data-offset?
| | | | | | uint8
| | | | | +--rw reserved?
| | | | | | uint8
| | | | | +--rw flags?
| | | | | | bits
| | | | | +--rw window-size?
| | | | | | uint16
| | | | | +--rw urgent-pointer?
| | | | | | uint16
| | | | | +--rw options?
| | | | | | binary
| | | | | +--rw (source-port)?
| | | | | | +--:(source-port-range-or-operator)
| | | | | | +--rw source-port-range-or-operator
| | | | | | +--rw (port-range-or-operator)?
| | | | | | +--:(range)
| | | | | | | +--rw lower-port
| | | | | | | | inet:port-number
| | | | | | | +--rw upper-port
| | | | | | | inet:port-number
| | | | | | +--:(operator)
| | | | | | +--rw operator?
| | | | | | | operator
| | | | | | +--rw port
| | | | | | inet:port-number
| | | | | +--rw (destination-port)?
| | | | +--:(destination-port-range-or-operator)
| | | | | +--rw destination-port-range-or-operator
| | | | | +--rw (port-range-or-operator)?
| | | | | +--:(range)
| | | | | | +--rw lower-port
| | | | | | | inet:port-number
| | | | | | +--rw upper-port
| | | | | | inet:port-number
| | | | | +--:(operator)
| | | | | +--rw operator?
| | | | | | operator
| | | | | +--rw port
| | | | | inet:port-number
| | | | +--:(udp)
| | | | +--rw udp
| | | | +--rw length?
| | | | | uint16
| | | | +--rw (source-port)?
| | | | | +--:(source-port-range-or-operator)
| | | | | +--rw source-port-range-or-operator
| | | | | +--rw (port-range-or-operator)?
| | | | | +--:(range)
| | | | | | +--rw lower-port
| | | | | | | inet:port-number
| | | | | | +--rw upper-port
| | | | | | inet:port-number
| | | | | +--:(operator)
| | | | | +--rw operator?
| | | | | | operator
| | | | | +--rw port
| | | | | inet:port-number
| | | | +--rw (destination-port)?
| | | | +--:(destination-port-range-or-operator)
| | | | +--rw destination-port-range-or-operator
| | | | +--rw (port-range-or-operator)?
| | | | +--:(range)
| | | | | +--rw lower-port
| | | | | | inet:port-number
| | | | | +--rw upper-port
| | | | | inet:port-number
| | | | +--:(operator)
| | | | +--rw operator?
| | | | | operator
| | | | +--rw port
| | | | inet:port-number
...
+-----------+ +------+ +------+ +-----------+ Figure 23: QoS Subtree Structure (L4)
| Multicast |---| CE |--/--| PE |----| Backbone |
| source | +------+ +------+ | IP/MPLS |
+-----------+ +-----------+
Figure 22: Multicast L3VPN Service Example * Application match
To configure a Multicast L3VPN service using the L3NM model the 7.3.4.3. Multicast
procedure and the JSON with the data structure is the following:
First, the multicast service is created (see the excerpt of the Multicast MAY be enabled for a particular vpn-network-node (see
request message body shown in Figure 23) Figure 24).
"vpn-services": { The model supports a single type of tree (Any-Source Multicast (ASM),
"vpn-service": { Source-Specific Multicast (SSM), or bidirectional).
"vpn-id": "Multicast_IPTV",
"customer-name": "310",
"vpn-service-topology": "hub-spoke",
"description": "Multicast IPTV VPN service"
}
}
Figure 23: Create Multicast VPN Service (Excerpt of the Message When ASM is used, the model supports the configuration of rendez-vous
Request Body) 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.
Then, the VPN nodes are created (see the excerpt of the request The model supports RP redundancy through the 'rp-redundancy' leaf.
message body shown in Figure 24). In this example, the VPN Node will How the redundancy is achieved is out of scope and is up to the
represent VRF configured in the physical device. implementation.
"vpn-node": [ When a particular VPN using ASM requires a more optimal traffic
"vpn-node-id": "500003105", delivery, 'optimal-traffic-delivery' can be set. When set to 'true',
"ne-id": "10.250.2.202", the implementation must use any mechanism to provide a more optimal
"autonomous-system": "3816", traffic delivery for the customer. Anycast is one of the mechanisms
"description": "VRF_IPTV_MULTICAST", to enhance RPs redundancy, resilience against failures, and to
"router-id": "10.250.2.202", recover from failures quickly.
"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 24: Create Multicast VPN Node (Excerpt of the Message Request For redundancy purposes, Multicast Source Discovery Protocol (MSDP)
Body) [RFC3618] 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.
Finally, create the VPN Network Access with Multicast enabled (see ...
the excerpt of the request message body shown in Figure 25) +--rw vpn-network-accesses
| +--rw vpn-network-access* [id]
| +--rw id
| ..
+--rw multicast {vpn-common: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
"vpn-network-access": { Figure 24: Multicast Subtree Structure
"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 25: Create VPN Network Access (Excerpt of the Message Request 8. Layer 3 Network Model
Body)
10. L3NM YANG Module This module uses types defined in [RFC6991] and groupings defined in
[RFC8519].
<CODE BEGINS> file "ietf-l3vpn-ntw@2020-03.09.yang" <CODE BEGINS> file "ietf-l3vpn-ntw@2020-09-15.yang"
module ietf-l3vpn-ntw { 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 l3nm;
import ietf-vpn-common {
prefix vpn-common;
reference
"RFC UUUU: A Layer 2/3 VPN Common YANG Model";
}
import ietf-inet-types { import ietf-inet-types {
prefix inet; prefix inet;
reference reference
"Section 4 of RFC 6991"; "Section 4 of RFC 6991";
} }
import ietf-yang-types { import ietf-yang-types {
prefix yang; prefix yang;
reference reference
"Section 3 of RFC 6991"; "Section 3 of RFC 6991";
} }
import ietf-netconf-acm {
prefix nacm;
reference
"RFC 8341: Network Configuration Access Control Model";
}
import ietf-routing-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 { import ietf-packet-fields {
prefix packet-fields; prefix pf;
reference reference
"RFC 8519: YANG Data Model for Network Access "RFC 8519: YANG Data Model for Network Access
Control Lists (ACLs)"; 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 Editor: Samier Barguil
<mailto:samier.barguilgiraldo.ext@telefonica.com> <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>
Author: Mohamed Boucadair Editor: Mohamed Boucadair
<mailto:mohamed.boucadair@orange.com> <mailto:mohamed.boucadair@orange.com>
Author: Luis Angel Munoz Author: Luis Angel Munoz
<mailto:luis-angel.munoz@vodafone.com> <mailto:luis-angel.munoz@vodafone.com>
Author: Alejandro Aguado Author: Alejandro Aguado
<mailto:alejandro.aguado_martin@nokia.com> <mailto:alejandro.aguado_martin@nokia.com>
"; ";
description description
"This YANG module defines a generic network-oriented model "This YANG module defines a generic network-oriented model
for the configuration of Layer 3 Virtual Private Networks. for the configuration of Layer 3 Virtual Private Networks.
Copyright (c) 2020 IETF Trust and the persons identified as Copyright (c) 2020 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 Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to without modification, is permitted pursuant to, and subject to
the license terms contained in, the Simplified BSD License set the license terms contained in, the Simplified BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(https://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
skipping to change at page 52, line 25 skipping to change at page 45, line 19
without modification, is permitted pursuant to, and subject to without modification, is permitted pursuant to, and subject to
the license terms contained in, the Simplified BSD License set the license terms contained in, the Simplified BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(https://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX This version of this YANG module is part of RFC XXXX
(https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself
for full legal notices."; for full legal notices.";
revision 2020-04-03 { revision 2020-09-15 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC XXXX: A Layer 3 VPN Network YANG Model"; "RFC XXXX: A Layer 3 VPN Network YANG Model";
// RFC Ed.: replace XXXX with actual RFC number and remove
// this note
} }
/* Features */ /* Features */
feature msdp { feature msdp {
description description
"This feature indicates that msdp capabilities "This feature indicates that Multicast Source
are supported by the VPN."; Discovery Protocol (MSDP) capabilities are
} supported by the VPN.";
reference
feature rtg-isis { "RFC 3618: Multicast Source Discovery Protocol (MSDP)";
description
"This features indicates the support of the ISIS
routing protocol.";
}
feature rtg-ospf-sham-link {
description
"This feature indicates the support of OSPF sham links.";
}
feature input-bw {
description
"This feature indicates the support of
the 'input-bw' limit.";
}
feature dot1q {
description
"This feature indicates the support of
the 'dot1q' encapsulation.";
}
feature qinq {
description
"This feature indicates the support of
the 'qinq' encapsulation.";
}
feature qinany {
description
"This feature indicates the support of
the 'qinany' encapsulation.";
}
feature vxlan {
description
"This feature indicates the support of
the 'vxlan' encapsulation.";
} }
/* Typedefs */ /* Typedefs */
typedef protocol-type {
type enumeration {
enum GRE {
value 0;
description
"Transport based on GRE.";
}
enum LDP {
value 1;
description
"Transport based on LDP.";
}
enum BGP {
value 2;
description
"Transport based on BGP.";
}
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";
}
}
description
"These attributes are used to identify underlying
protocols when activating an L3VPN service.";
}
typedef area-address { typedef area-address {
type string { type string {
pattern '[0-9A-Fa-f]{2}(\.[0-9A-Fa-f]{4}){0,6}'; pattern '[0-9A-Fa-f]{2}(\.[0-9A-Fa-f]{4}){0,6}';
} }
description description
"This type defines the area address format."; "This type defines the area address format.";
} }
typedef isis-level {
type enumeration {
enum level1 {
value 0;
description
"ISIS level 1";
}
enum level2 {
value 1;
description
"ISIS level 2";
}
enum level1-2 {
value 2;
description
"ISIS level 1 and 2";
}
}
description
"Defines the ISIS level for interface and system.";
}
typedef ie-type {
type enumeration {
enum import {
value 0;
description
"Import a routing profile.";
}
enum export {
value 1;
description
"Export a routing profile.";
}
enum both {
value 2;
description
"Import/Export a routing profile.";
}
}
description
"Defines Import-Export routing profiles.
Those profiles can be reused between VPN nodes.";
}
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
"This attribute is used to determine the
status of a particular element.";
}
/* Identities */ /* Identities */
identity vpn-topology { identity address-allocation-type {
description
"Base identity for VPN topology.";
}
identity any-to-any {
base vpn-topology;
description
"Identity for any-to-any VPN topology.";
}
identity hub-spoke {
base vpn-topology;
description
"Identity for Hub-and-Spoke VPN topology.";
}
identity hub-spoke-disjoint {
base vpn-topology;
description
"Identity for Hub-and-Spoke VPN topology
where Hubs cannot communicate with each other.";
}
identity custom {
base vpn-topology;
description description
"Identity for CUSTOM VPN topology "Base identity for address-allocation-type for
where Hubs can act as Spoke for certain part of PE-CE link.";
the network or Spokes as Hubs.";
}
identity isis {
base l3vpn-svc:routing-protocol-type;
description
"Identity for ISIS protocol type.";
} }
identity pseudowire { identity provider-dhcp {
base l3vpn-svc:site-network-access-type; base address-allocation-type;
description description
"Identity for pseudowire connections."; "The Provider's network provides a DHCP service
to the customer.";
} }
identity loopback { identity provider-dhcp-relay {
base l3vpn-svc:site-network-access-type; base address-allocation-type;
description description
"Identity for loopback connections."; "The Provider's network provides a DHCP relay service
to the customer.";
} }
identity encapsulation-type { identity provider-dhcp-slaac {
base address-allocation-type;
description description
"Identity for the encapsulation type."; "The Provider's network provides a DHCP service to
the customer, as well as IPv6 Stateless Address
Autoconfiguration (SLAAC).";
reference
"RFC 7527: IPv6 Stateless Address Autoconfiguration";
} }
identity untagged-int { identity static-address {
base encapsulation-type; base address-allocation-type;
description description
"Identity for Ethernet type."; "The Provider-to-customer addressing is static.";
} }
identity tagged-int { identity slaac {
base encapsulation-type; base address-allocation-type;
description description
"Identity for the VLAN type."; "Use IPv6 SLAAC.";
reference
"RFC 7527: IPv6 Stateless Address Autoconfiguration";
} }
identity eth-inf-type { identity isis-level {
description description
"Identity of the Ethernet interface type."; "Defines the IS-IS level for interface
and system.";
} }
identity tagged { identity level1 {
base eth-inf-type; base isis-level;
description description
"Identity of the tagged interface type."; "IS-IS level 1.";
} }
identity untagged { identity level2 {
base eth-inf-type; base isis-level;
description description
"Identity of the untagged interface type."; "IS-IS level 2.";
} }
identity lag { identity level1-2 {
base eth-inf-type; base isis-level;
description description
"Identity of the LAG interface type."; "IS-IS levels 1 and 2.";
} }
identity bearer-inf-type { identity bearer-inf-type {
description description
"Identity for the bearer interface type."; "Identity for the bearer interface type.";
} }
identity port-id { identity port-id {
base bearer-inf-type; base bearer-inf-type;
description description
"Identity for the priority-tagged interface."; "Identity for the priority-tagged interface.";
} }
identity lag-id { identity lag-id {
base bearer-inf-type; base bearer-inf-type;
description description
"Identity for the priority-tagged interface."; "Identity for the lag-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 {
description
"Base identity for the VXLAN peer mode.";
}
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 using BGP EVPN.";
}
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 {
description
"Identity of the bandwidth type.";
}
identity bw-per-cos {
base bw-type;
description
"Bandwidth is per CoS.";
}
identity bw-per-port {
base bw-type;
description
"Bandwidth is per site network access.";
}
identity bw-per-site {
base bw-type;
description
"Bandwidth is per site. It is applicable to
all the site network accesses within a site.";
}
identity bw-per-svc {
base bw-type;
description
"Bandwidth is per VPN service.";
} }
/* Groupings */ /* Groupings */
grouping svc-transport-encapsulation { grouping security-params {
container underlay-transport { container security {
leaf-list type { leaf auth-key {
type protocol-type; type string;
ordered-by user;
description
"Protocols used to deliver an L3VPN service.";
}
description
"Container for the Transport Underlay.";
}
description
"This grouping defines the type of underlay transport
for VPN service.";
}
grouping multicast-rp-group-cfg {
choice group-format {
mandatory true;
case group-prefix {
leaf group-address {
type inet:ip-prefix;
description
"A single multicast group prefix.";
}
}
case startend {
leaf group-start {
type inet:ip-address;
description
"The first multicast group address in
the multicast group address range.";
}
leaf group-end {
type inet:ip-address;
description
"The last multicast group address in
the multicast group address range.";
}
}
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
"Enables multicast.";
}
leaf-list tree-flavor {
type identityref {
base l3vpn-svc:multicast-tree-type;
}
description
"Type of tree to be used.";
}
container rp {
container rp-group-mappings {
list rp-group-mapping {
key "id";
leaf id {
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
"RP-to-group mappings parameters.";
}
container rp-discovery {
leaf rp-discovery-type {
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-svc: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
"RP parameters.";
}
container msdp {
if-feature "msdp";
leaf enabled {
type boolean;
default "false";
description
"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.";
}
description
"MSDP parameters.";
}
description
"Multicast global parameters for the VPN service.";
}
description
"Grouping for multicast VPN definition.";
}
grouping vpn-service-mpls {
leaf carrierscarrier {
if-feature "l3vpn-svc:carrierscarrier";
type boolean;
default "false";
description
"The VPN is using CsC, and so MPLS is required.";
}
description
"Grouping for MPLS Carriers'Carrier 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
"Optional leaf indicating requested date and
time when the service at a particular site is
expected to stop.";
}
description
"This grouping defines some operational
parameters.";
}
grouping status-timestamp {
leaf status {
type operational-type;
description
"Operations status";
}
leaf timestamp {
type yang:date-and-time;
description
"Indicates the actual date and time when
the service actually started (UP) or
stopped (DOWN).";
}
description
"This grouping defines some operational
parameters for the service.";
}
grouping service-status {
container service-status {
container admin {
uses status-timestamp;
description
"Administrative service status.";
}
container ops {
config false;
uses status-timestamp;
description
"Operational service status.";
}
description
"Service status.";
}
description
"Service status grouping. Reused in
vpn-node and vpn-network-access.";
}
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 {
container traffic-protection {
if-feature "l3vpn-svc:fast-reroute";
leaf enabled {
type boolean;
default "false";
description
"Enables traffic protection of access link.";
}
description
"Fast Reroute service parameters for the site.";
}
description
"Defines protection service parameters for a site.";
}
grouping site-service-mpls {
container carrierscarrier {
if-feature "l3vpn-svc:carrierscarrier";
leaf signalling-type {
type enumeration {
enum ldp {
description
"Use LDP as the signalling protocol
between the PE and the CE. In this case,
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 description
"MPLS signalling type."; "MD5 authentication password for the connection
towards the customer edge.";
} }
description description
"This container is used when the customer provides "Container for aggregating any security parameter
MPLS-based services. This is only used in the case for routing sessions between a PE and a CE.";
of CsC (i.e., a customer builds an MPLS service using
an IP VPN to carry its traffic).";
} }
description description
"Defines MPLS service parameters for a site."; "Grouping to define a set of security parameters";
} }
grouping ports { grouping ports {
choice source-port { choice source-port {
container source-port-range-or-operator { container source-port-range-or-operator {
uses packet-fields:port-range-or-operator; uses pf:port-range-or-operator;
description description
"Source port definition."; "Source port definition.";
} }
description description
"Choice of specifying the source port or referring to "Choice of specifying the source port or
a group of source port numbers."; referring to a group of source port numbers.";
} }
choice destination-port { choice destination-port {
container destination-port-range-or-operator { container destination-port-range-or-operator {
uses packet-fields:port-range-or-operator; uses pf:port-range-or-operator;
description description
"Destination port definition."; "Destination port definition.";
} }
description description
"Choice of specifying a destination port or referring "Choice of specifying a destination port or
to a group of destination port numbers."; referring to a group of destination port
} numbers.";
description
"Choice of specifying a source or destination port numbers.";
}
grouping site-service-qos-profile {
container qos {
if-feature "l3vpn-svc: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 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 {
leaf match-application {
type identityref {
base l3vpn-svc:customer-application;
}
description
"Defines the application to match.";
}
}
description
"Choice for classification.";
}
leaf target-class-id {
type string;
description
"Identification of the class of service.
This identifier is internal to the administration.";
}
description
"List of marking rules.";
}
description
"Configuration of the traffic classification policy.";
}
container qos-profile {
list qos-profile {
key profile;
description
"QoS profile.
Can be standard profile or customized profile.";
leaf profile {
type leafref {
path "/l3vpn-ntw/vpn-profiles/"
+ "valid-provider-identifiers"
+ "/qos-profile-identifier/id";
}
description
"QoS profile to be used.";
}
leaf direction {
type identityref {
base l3vpn-svc:qos-profile-direction;
}
default "l3vpn-svc:both";
description
"The direction to which the QoS profile
is applied.";
}
}
description
"QoS profile configuration.";
}
description
"QoS configuration.";
} }
description description
"This grouping defines QoS parameters for a site."; "Choice of specifying a source or destination
port numbers.";
} }
grouping site-security-authentication { /* Main Blocks */
container authentication { /* Main l3nm */
description
"Authentication parameters.";
}
description
"This grouping defines authentication parameters
for a site.";
}
grouping site-security-encryption { container l3vpn-ntw {
container encryption { container vpn-profiles {
if-feature "l3vpn-svc:encryption"; uses vpn-common:vpn-profile-cfg;
leaf enabled {
type boolean;
default "false";
description
"If true, traffic encryption on the connection
is required. It is disabled, otherwise.";
}
leaf layer {
when "../enabled = 'true'" {
description
"Require a value for layer when enabled
is true.";
}
type enumeration {
enum layer2 {
description
"Encryption will occur at Layer 2.";
}
enum layer3 {
description
"Encryption will occur at Layer 3.
For example, IPsec may be used when
a customer requests Layer 3 encryption.";
}
}
description
"Layer on which encryption is applied.";
}
description
"Container for CE-PE security encryption.";
}
container encryption-profile {
choice profile {
case provider-profile {
leaf profile-name {
type leafref {
path "/l3vpn-ntw/vpn-profiles/"
+ "valid-provider-identifiers"
+ "/encryption-profile-identifier/id";
}
description
"Name of the SP profile to be applied.";
}
}
case customer-profile {
leaf algorithm {
type string;
description
"Encryption algorithm to be used.";
}
}
description
"Choice for encryption profile.";
}
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 description
"Container for encryption profile."; "Contains a set of valid VPN Profiles to
reference in the VPN service.";
} }
description container vpn-services {
"This grouping defines encryption parameters for list vpn-service {
a site."; key "vpn-id";
} uses vpn-common:service-status;
uses vpn-common:vpn-description;
grouping site-routing { leaf l3sm-vpn-id {
container routing-protocols { type vpn-common:vpn-id;
list routing-protocol {
key "id";
leaf id {
type string;
description description
"Unique identifier for routing protocol."; "Pointer to the parent L3SM service,
if any.";
} }
leaf type { leaf vpn-type {
type identityref { type identityref {
base l3vpn-svc:routing-protocol-type; base vpn-common:vpn-signaling-type;
} }
description description
"Type of routing protocol."; "Indicates the service type";
} }
list routing-profiles { leaf vpn-service-topology {
key "id"; type identityref {
leaf id { base vpn-common:vpn-topology;
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.";
} }
default "vpn-common:any-to-any";
description description
"Import or Export profile reference"; "VPN service topology.";
} }
container ospf { container ie-profiles {
when "derived-from-or-self(../type, 'l3vpn-svc:ospf')" { list ie-profile {
description key "ie-profile-id";
"Only applies when protocol is OSPF."; leaf ie-profile-id {
} type string;
if-feature "l3vpn-svc:rtg-ospf";
leaf-list address-family {
type l3vpn-svc: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.";
}
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 description
"Creates a sham link with another site."; "IE profile id.";
} }
uses vpn-common:rt-rd;
description description
"List of sham links."; "List for Imort/Export profile.";
}
description
"OSPF-specific configuration.";
}
container bgp {
when "derived-from-or-self(../type, 'l3vpn-svc: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
"BGP-specific configuration."; "Container for Import/Export profiles.";
} }
container isis { uses vpn-common:svc-transport-encapsulation;
when "derived-from-or-self(../type, 'l3vpn-ntw:isis')" { container vpn-nodes {
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
"ISIS-specific configuration."; "Container for VPN nodes.";
} list vpn-node {
container static { key "vpn-node-id";
when "derived-from-or-self(../type, 'l3vpn-svc:static')" { leaf vpn-node-id {
description type union {
"Only applies when protocol is static. type vpn-common:vpn-id;
BGP activation requires the SP to know type uint32;
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 "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 description
"List of LAN prefixes for the site."; "Type STRING or NUMBER Service-Id.";
}
description
"LAN prefixes from the customer.";
}
description
"Configuration specific to static routing.";
}
container rip {
when "derived-from-or-self(../type, 'l3vpn-svc:rip')" {
description
"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.";
}
container vrrp {
when "derived-from-or-self(../type, 'l3vpn-svc: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
"Configuration specific to VRRP routing.";
}
description
"List of routing protocols used on
the site. This list can be augmented.";
}
description
"Defines routing protocols.";
}
description
"Grouping for routing protocols.";
}
grouping site-attachment-ip-connection {
container ip-connection {
container ipv4 {
if-feature "l3vpn-svc:ipv4";
leaf address-allocation-type {
type identityref {
base l3vpn-svc:address-allocation-type;
}
must "not(derived-from-or-self(current(), 'l3vpn-svc:slaac')"
+ " or derived-from-or-self(current(), "
+ "'l3vpn-svc:provider-dhcp-slaac'))" {
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-svc:provider-dhcp')" {
description
"Only applies when addresses are allocated by DHCP.";
}
leaf provider-address {
type inet:ipv4-address;
description
"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
"If the 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.";
}
choice address-assign {
default "number";
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";
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
"DHCP allocated addresses related parameters.";
}
container dhcp-relay {
when "derived-from-or-self(../address-allocation-type, "
+ "'l3vpn-svc:provider-dhcp-relay')" {
description
"Only applies when provider is required to implement
DHCP relay function.";
}
leaf provider-address {
type inet:ipv4-address;
description
"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 prefix-length {
type uint8 {
range "0..32";
} }
must '(../provider-address)' { leaf local-autonomous-system {
error-message type inet:as-number;
"If prefix length is specified, provider-address
must also be specified.";
description description
"If prefix length is specified, provider-address "Provider's AS number in case the customer
must also be specified."; requests BGP routing.";
} }
description leaf description {
"Subnet prefix length expressed in bits. If not type string;
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 description
"IP address of customer DHCP server."; "Textual description of the VPN node.";
}
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-svc: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 leaf ne-id {
"Principal address of the connection.";
}
list address {
key "address-id";
leaf address-id {
type string; type string;
description description
"IPv4 Address"; "Unique identifier of the network element
where the VPN node is deployed.";
} }
leaf provider-address { leaf router-id {
type inet:ipv4-address; type inet:ip-address;
description description
"IPv4 Address List of the provider side. "The router-id information can be an IPv4
When the protocol allocation type is static, or IPv6 address.";
the provider address must be configured.";
} }
leaf customer-address { leaf address-family {
type inet:ipv4-address; type vpn-common:address-family;
description description
"IPv4 Address of customer side."; "The address family used for router-id
information.";
} }
leaf prefix-length { leaf node-role {
type uint8 { type identityref {
range "0..32"; base vpn-common:role;
} }
default "vpn-common:any-to-any-role";
description description
"Subnet prefix length expressed in bits. "Role of the VPN node in the IP VPN.";
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 "l3vpn-svc:ipv6";
leaf address-allocation-type {
type identityref {
base l3vpn-svc: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-svc:provider-dhcp') "
+ "or derived-from-or-self(../address-allocation-type, "
+ "'l3vpn-svc:provider-dhcp-slaac')" {
description
"Only applies when addresses are allocated by DHCP.";
}
leaf provider-address {
type inet:ipv6-address;
description
"Address of the 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 prefix-length {
type uint8 {
range "0..128";
}
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 uses vpn-common:rt-rd;
"Subnet prefix length expressed in bits. If not uses vpn-common:service-status;
specified, or specified as zero, this means the leaf node-ie-profile {
customer leaves the actual prefix length value type leafref {
to the provider."; path "/l3vpn-ntw/vpn-services/"
} + "vpn-service/ie-profiles/"
choice address-assign { + "ie-profile/ie-profile-id";
default "number";
case number {
leaf number-of-dynamic-address {
type uint16;
default "1";
description
"Describes the number of IP addresses the customer
requires.";
} }
description
"Node's Import/Export profile.";
} }
case explicit { uses vpn-common:vpn-node-group;
container customer-addresses { container vpn-network-accesses {
list address-group { list vpn-network-access {
key "group-id"; key "id";
leaf group-id { leaf id {
type string; type vpn-common:vpn-id;
description
"Identifier for the access.";
}
leaf port-id {
type vpn-common:vpn-id;
description
"Identifier for the network access.";
}
leaf description {
type string;
description
"Textual description of a network access.";
}
uses vpn-common:service-status;
leaf vpn-network-access-type {
type identityref {
base vpn-common:site-network-access-type;
}
default "vpn-common:point-to-point";
description
"Describes the type of connection, e.g.,
point-to-point or multipoint.";
}
container connection {
leaf encapsulation-type {
type identityref {
base vpn-common:encapsulation-type;
}
default "vpn-common:untagged-int";
description description
"Group-id for the address range from "Encapsulation type. By default,
start-address to end-address."; the encapsulation type is set to
'untagged'.";
} }
leaf start-address { container logical-interface {
type inet:ipv6-address; leaf peer-reference {
type uint32;
description
"Specify the associated logical peer
interface";
}
description description
"First address."; "Reference of a logical interface
type.";
} }
leaf end-address { container tagged-interface {
type inet:ipv6-address; leaf type {
type identityref {
base vpn-common:encapsulation-type;
}
default "vpn-common:priority-tagged";
description
"Tagged interface type. By default,
the type of the tagged interface is
'priority-tagged'.";
}
container dot1q-vlan-tagged {
when "derived-from-or-self(../type, "
+ "'vpn-common:dot1q')" {
description
"Only applies when the type of the
tagged interface is 'dot1q'.";
}
if-feature "vpn-common:dot1q";
leaf tag-type {
type identityref {
base vpn-common:tag-type;
}
default "vpn-common:c-vlan";
description
"Tag type. By default, the tag
type is 'c-vlan'.";
}
leaf cvlan-id {
type uint16;
description
"VLAN identifier.";
}
description
"Tagged interface.";
}
container priority-tagged {
when "derived-from-or-self(../type, "
+ "'vpn-common:priority-tagged')" {
description
"Only applies when the type of the
tagged interface is
'priority-tagged'.";
}
leaf tag-type {
type identityref {
base vpn-common:tag-type;
}
default "vpn-common:c-vlan";
description
"Tag type. By default, the tag
type is 'c-vlan'.";
}
description
"Priority tagged.";
}
container qinq {
when "derived-from-or-self(../type, "
+ "'vpn-common:qinq')" {
description
"Only applies when the type of
the tagged interface is 'qinq'.";
}
if-feature "vpn-common:qinq";
leaf tag-type {
type identityref {
base vpn-common:tag-type;
}
default "vpn-common:c-s-vlan";
description
"Tag type. By default, the tag
type is 'c-s-vlan'.";
}
leaf svlan-id {
type uint16;
mandatory true;
description
"SVLAN identifier.";
}
leaf cvlan-id {
type uint16;
mandatory true;
description
"CVLAN identifier.";
}
description
"QinQ.";
}
container qinany {
when "derived-from-or-self(../type, "
+ "'vpn-common:qinany')" {
description
"Only applies when the type of the
tagged interface is 'qinany'.";
}
if-feature "vpn-common:qinany";
leaf tag-type {
type identityref {
base vpn-common:tag-type;
}
default "vpn-common:s-vlan";
description
"Tag type. By default, the tag type
is 's-vlan'.";
}
leaf svlan-id {
type uint16;
mandatory true;
description
"Service VLAN ID.";
}
description
"Container for QinAny.";
}
container vxlan {
when "derived-from-or-self(../type, "
+ "'vpn-common:vxlan')" {
description
"Only applies when the type of the
tagged interface is 'vxlan'.";
}
if-feature "vpn-common:vxlan";
leaf vni-id {
type uint32;
mandatory true;
description
"VXLAN Network Identifier (VNI).";
}
leaf peer-mode {
type identityref {
base vpn-common:vxlan-peer-mode;
}
default "vpn-common:static-mode";
description
"Specifies the VXLAN access mode.
By default, the peer mode is set
to 'static-mode'.";
}
list peer-list {
key "peer-ip";
leaf peer-ip {
type inet:ip-address;
description
"Peer IP.";
}
description
"List of peer IP addresses.";
}
description
"QinQ.";
}
description description
"Last address."; "Container for tagged interfaces.";
}
container bearer {
leaf bearer-reference {
if-feature "vpn-common:bearer-reference";
type string;
description
"This is an internal reference for*
the SP.";
}
container pseudowire {
leaf vcid {
type uint32;
description
"PW or VC identifier.";
}
leaf far-end {
type union {
type uint32;
type inet:ipv4-address;
}
description
"SDP/Far End/LDP neighbour reference.";
}
description
"Pseudowire termination parameters";
}
container vpls {
leaf vcid {
type union {
type uint32;
type string;
}
description
"VCID identifier, IRB/RVPPLs interface
supported using string
format.";
}
leaf far-end {
type union {
type uint32;
type inet:ipv4-address;
}
description
"SDP/Far End/LDP Neighbour reference.";
}
description
"Pseudowire termination parameters";
}
description
"Defines physical properties of a site
attachment.";
} }
description description
"Describes IP addresses allocated by DHCP. "Encapsulation types";
When only start-address or only end-address
is present, it represents a single address.
When both start-addressand 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 allocated
by DHCP.";
}
}
description
"Choice for the way to assign addresses.";
}
description
"DHCP allocated addresses related parameters.";
}
container dhcp-relay {
when "derived-from-or-self(../address-allocation-type, "
+ "'l3vpn-svc:provider-dhcp-relay')" {
description
"Only applies when the provider is required
to implement DHCP relay function.";
}
leaf provider-address {
type inet:ipv6-address;
description
"Address of the 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 prefix-length {
type uint8 {
range "0..128";
}
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:ipv6-address;
description
"This node contains the IP address of
the customer DHCP server. If the DHCP relay
function is implemented by the
provider, this node contains the
configured value.";
}
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-svc: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/ipv6/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:ipv6-address;
description
"IPv6 Address of the provider side. When the protocol
allocation type is static, the provider address
must be configured.";
}
leaf customer-address {
type inet:ipv6-address;
description
"The IPv6 Address of the customer side.";
}
leaf prefix-length {
type uint8 {
range "0..128";
}
description
"Subnet prefix length expressed in bits.
It is applied to both provider-address and
customer-address.";
}
description
"Describes IPv6 addresses used.";
}
description
"IPv6-specific parameters.";
}
description
"IPv6-specific parameters.";
}
container oam {
container bfd {
if-feature "l3vpn-svc:bfd";
leaf enabled {
type boolean;
default "false";
description
"If true, BFD activation is required.";
}
choice holdtime {
default "fixed";
case fixed {
leaf fixed-value {
type uint32;
units "msec";
description
"Expected BFD holdtime expressed in msec. The customer
may impose some fixed values for the holdtime period
if the provider allows the customer use this function.
If the provider doesn't allow the customer to use this
function, the fixed-value will not be set.";
}
}
case profile {
leaf profile-name {
type leafref {
path "/l3vpn-ntw/vpn-profiles/"
+ "valid-provider-identifiers/"
+ "bfd-profile-identifier/id";
} }
description container ip-connection {
"Well-known SP profile name. The provider can propose container ipv4 {
some profiles to the customer, depending on the if-feature "vpn-comm