draft-ietf-opsawg-l3sm-l3nm-07.txt   draft-ietf-opsawg-l3sm-l3nm-08.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: September 11, 2021 M. Boucadair, Ed. Expires: October 24, 2021 M. Boucadair, Ed.
Orange Orange
L. Munoz L. Munoz
Vodafone Vodafone
A. Aguado A. Aguado
Nokia Nokia
March 10, 2021 April 22, 2021
A Layer 3 VPN Network YANG Model A Layer 3 VPN Network YANG Model
draft-ietf-opsawg-l3sm-l3nm-07 draft-ietf-opsawg-l3sm-l3nm-08
Abstract Abstract
This document defines a L3VPN Network YANG Model (L3NM) that can be This document defines an L3VPN Network YANG Model (L3NM) that can be
used for the provisioning of Layer 3 Virtual Private Network (VPN) used for the provisioning of Layer 3 Virtual Private Network (VPN)
services within a service provider network. The model provides a services within a service provider network. The model provides a
network-centric view of L3VPN services. 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.
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
Please update "RFC UUUU" to the RFC number to be assigned to I-
D.ietf-opsawg-vpn-common.
Also, please update the "revision" date of the YANG module. Also, please update the "revision" date of the YANG module.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 September 11, 2021. This Internet-Draft will expire on October 24, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 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 38 skipping to change at page 2, line 41
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. L3NM Reference Architecture . . . . . . . . . . . . . . . . . 7 4. L3NM Reference Architecture . . . . . . . . . . . . . . . . . 7
5. Relation with other YANG Models . . . . . . . . . . . . . . . 10 5. Relation with other YANG Models . . . . . . . . . . . . . . . 10
6. Sample Uses of the L3NM Data Model . . . . . . . . . . . . . 11 6. Sample Uses of the L3NM Data Model . . . . . . . . . . . . . 11
6.1. Enterprise Layer 3 VPN Services . . . . . . . . . . . . . 11 6.1. Enterprise Layer 3 VPN Services . . . . . . . . . . . . . 11
6.2. Multi-Domain Resource Management . . . . . . . . . . . . 11 6.2. Multi-Domain Resource Management . . . . . . . . . . . . 12
6.3. Management of Multicast Services . . . . . . . . . . . . 12 6.3. Management of Multicast Services . . . . . . . . . . . . 12
7. Description of the L3NM YANG Module . . . . . . . . . . . . . 12 7. Description of the L3NM YANG Module . . . . . . . . . . . . . 12
7.1. Overall Structure of the Module . . . . . . . . . . . . . 13 7.1. Overall Structure of the Module . . . . . . . . . . . . . 13
7.2. VPN Profiles . . . . . . . . . . . . . . . . . . . . . . 13 7.2. VPN Profiles . . . . . . . . . . . . . . . . . . . . . . 13
7.3. VPN Services . . . . . . . . . . . . . . . . . . . . . . 14 7.3. VPN Services . . . . . . . . . . . . . . . . . . . . . . 15
7.4. Import/Export Profiles . . . . . . . . . . . . . . . . . 17 7.4. VPN Instance Profiles . . . . . . . . . . . . . . . . . . 18
7.5. VPN Nodes . . . . . . . . . . . . . . . . . . . . . . . . 19 7.5. VPN Nodes . . . . . . . . . . . . . . . . . . . . . . . . 20
7.6. VPN Network Access . . . . . . . . . . . . . . . . . . . 23 7.6. VPN Network Access . . . . . . . . . . . . . . . . . . . 23
7.6.1. Connection . . . . . . . . . . . . . . . . . . . . . 25 7.6.1. Connection . . . . . . . . . . . . . . . . . . . . . 26
7.6.2. IP Connections . . . . . . . . . . . . . . . . . . . 26 7.6.2. IP Connection . . . . . . . . . . . . . . . . . . . . 27
7.6.3. CE-PE Routing Protocols . . . . . . . . . . . . . . . 29 7.6.3. CE-PE Routing Protocols . . . . . . . . . . . . . . . 31
7.6.4. OAM . . . . . . . . . . . . . . . . . . . . . . . . . 40 7.6.4. OAM . . . . . . . . . . . . . . . . . . . . . . . . . 43
7.6.5. Security . . . . . . . . . . . . . . . . . . . . . . 41 7.6.5. Security . . . . . . . . . . . . . . . . . . . . . . 44
7.6.6. Services . . . . . . . . . . . . . . . . . . . . . . 42 7.6.6. Services . . . . . . . . . . . . . . . . . . . . . . 45
7.7. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 47 7.7. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 51
8. L3NM YANG Module . . . . . . . . . . . . . . . . . . . . . . 52 8. L3NM YANG Module . . . . . . . . . . . . . . . . . . . . . . 55
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 104 9. Security Considerations . . . . . . . . . . . . . . . . . . . 115
10. Security Considerations . . . . . . . . . . . . . . . . . . . 104 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 117
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 105 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 117
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 106 11.1. Normative References . . . . . . . . . . . . . . . . . . 117
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 106 11.2. Informative References . . . . . . . . . . . . . . . . . 121
13.1. Normative References . . . . . . . . . . . . . . . . . . 106 Appendix A. L3VPN Examples . . . . . . . . . . . . . . . . . . . 124
13.2. Informative References . . . . . . . . . . . . . . . . . 109 A.1. 4G VPN Provisioning Example . . . . . . . . . . . . . . . 124
Appendix A. L3VPN Examples . . . . . . . . . . . . . . . . . . . 113 A.2. Loopback Interface . . . . . . . . . . . . . . . . . . . 130
A.1. 4G VPN Provisioning Example . . . . . . . . . . . . . . . 113 A.3. Multicast VPN Provisioning Example . . . . . . . . . . . 130
A.2. Multicast VPN Provisioning Example . . . . . . . . . . . 119 Appendix B. Implementation Status . . . . . . . . . . . . . . . 135
Appendix B. Implementation Status . . . . . . . . . . . . . . . 123 B.1. Nokia Implementation . . . . . . . . . . . . . . . . . . 135
B.1. Nokia Implementation . . . . . . . . . . . . . . . . . . 123 B.2. Huawei Implementation . . . . . . . . . . . . . . . . . . 135
B.2. Huawei Implementation . . . . . . . . . . . . . . . . . . 123 B.3. Infinera Implementation . . . . . . . . . . . . . . . . . 135
B.3. Infinera Implementation . . . . . . . . . . . . . . . . . 124 B.4. Ribbon-ECI Implementation . . . . . . . . . . . . . . . . 135
B.4. Ribbon-ECI Implementation . . . . . . . . . . . . . . . . 124 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 136
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 124 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 136
1. Introduction 1. Introduction
[RFC8299] defines a Layer 3 Virtual Private Network Service YANG data [RFC8299] defines a Layer 3 Virtual Private Network Service YANG data
Model (L3SM) that can be used for communication between customers and Model (L3SM) that can be used for communication between customers and
network operators. Such model is focused on describing the customer network operators. Such model is focused on describing the customer
view of the Virtual Private Network (VPN) services and provides an view of the Virtual Private Network (VPN) services and provides an
abstracted view of the customer's requested services. That approach abstracted view of the customer's requested services. That approach
limits the usage of the L3SM to the role of a Customer Service Model limits the usage of the L3SM to the role of a customer service model
(as per [RFC8309]). (as per [RFC8309]).
This document defines a YANG module called L3VPN Network Model This document defines a YANG module called L3VPN Network Model
(L3NM). The L3NM is aimed at providing a network-centric view of (L3NM). The L3NM is aimed at providing a network-centric view of
Layer 3 (L3) VPN services. This data model can be used to facilitate Layer 3 (L3) VPN services. This data model can be used to facilitate
communication between the service orchestrator (or a network communication between the service orchestrator and the network
operator) and the network controller/orchestrator by allowing for controller/orchestrator by allowing for more network-centric
more network-centric information to be included. It enables further information to be included. It enables further capabilities such as
capabilities, such as resource management or to serve as a multi- resource management or serves as a multi-domain orchestration
domain orchestration interface, where logical resources (such as interface, where logical resources (such as route targets or route
route targets or route distinguishers) must be coordinated. distinguishers) must be coordinated.
This document uses the common VPN YANG module defined in This document uses the common VPN YANG module defined in
[I-D.ietf-opsawg-vpn-common]. [I-D.ietf-opsawg-vpn-common].
This document does not obsolete [RFC8299]. These two modules are This document does not obsolete [RFC8299]. These two modules are
used for similar objectives but with different scopes and views. used for similar objectives but with different scopes and views.
The L3NM YANG module is initially built with a prune and extend The L3NM YANG module was 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, the L3NM is not defined as an augment to [RFC8299]. Nevertheless, the L3NM 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 feed 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 in charge of maintaining the correspondence orchestrator; which is in charge of maintaining the correspondence
between a customer view and its network instantiation. Likewise, between a customer view and its network instantiation. Likewise,
some of the information captured and exposed using the L3NM can feed some of the information captured and exposed using the L3NM can feed
the service layer (e.g., capabilities) to drive VPN service order the service layer (e.g., capabilities) to drive VPN service order
handling, and thus the L3SM. handling, and thus the L3SM.
Section 5.1 of [RFC8969] illustrates how the L3NM can be used within Section 5.1 of [RFC8969] illustrates how the L3NM can be used within
the network management automation architecture. the network management automation architecture.
The L3NM does not attempt to address all deployment cases especially The L3NM does not attempt to address all deployment cases especially
those where the L3VPN connectivity is supported through the those where the L3VPN connectivity is supported through 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 an end- different VPN instances and different technologies to provide an end-
to-end VPN connectivity are addressed by complementary YANG modules, to-end VPN connectivity are addressed by complementary YANG modules,
e.g., [I-D.evenwu-opsawg-yang-composed-vpn]. e.g., [I-D.evenwu-opsawg-yang-composed-vpn].
L3NM focuses on BGP Provider Edge (PE) based Layer 3 VPNs as L3NM focuses on BGP Provider Edge (PE) based Layer 3 VPNs as
described in [RFC4026][RFC4110][RFC4364] and Multicast VPNs as described in [RFC4026][RFC4110][RFC4364] and Multicast VPNs as
described in [RFC6037][RFC6513][RFC7988]. described in [RFC6037][RFC6513].
The YANG data model in this document conforms to the Network The YANG data model in this document conforms to the Network
Management Datastore Architecture (NMDA) defined in [RFC8342]. Management Datastore Architecture (NMDA) defined in [RFC8342].
2. Terminology 2. Terminology
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
skipping to change at page 5, line 11 skipping to change at page 5, line 11
This document uses the term "network model" defined in Section 2.1 of This document uses the term "network model" defined in Section 2.1 of
[RFC8969]. [RFC8969].
The meaning of the symbols in the tree diagrams is defined in The meaning of the symbols in the tree diagrams is defined in
[RFC8340]. [RFC8340].
This document makes use of the following terms: This document makes use of the following terms:
Layer 3 VPN Customer Service Model (L3SM): A YANG module that Layer 3 VPN Customer Service Model (L3SM): A YANG module that
describes the service requirements of a L3VPN that interconnects a describes the service requirements of an L3VPN that interconnects
set of sites from the point of view of the customer. The customer a set of sites from the point of view of the customer. The
service model does not provide details on the service provider customer service model does not provide details on the service
network. The L3VPN Customer Service model is defined in provider network. The L3VPN customer service model is defined in
[RFC8299]. [RFC8299].
Layer 3 VPN Service Network Model (L3NM): A YANG module that Layer 3 VPN Service Network Model (L3NM): A YANG module that
describes a VPN service in the service provider network. It describes a VPN service in the service provider network. It
contains information of the service provider network and might contains information of the service provider network and might
include allocated resources. It can be used by network include allocated resources. It can be used by network
controllers to manage and control the VPN service configuration in controllers to manage and control the VPN service configuration in
the service provider network. The YANG module can be consumed by the service provider network. The YANG module can be consumed by
a service orchestrator to request a VPN service to a Network a service orchestrator to request a VPN service to a network
Controller. controller.
Service orchestrator: A functional entity that interacts with the Service orchestrator: A functional entity that interacts with the
customer of a L3VPN. The service orchestrator interacts with the customer of an L3VPN. The service orchestrator interacts with the
customer using the L3SM. The service orchestrator is responsible customer using the L3SM. The service orchestrator is responsible
of the Customer Edge (CE) - Provider Edge (PE) attachment of the Customer Edge (CE) - Provider Edge (PE) attachment
circuits, the PE selection, and requesting the VPN service to the circuits, the PE selection, and requesting the VPN service to the
Network Controller. network controller.
Network orchestrator: A functional entity that is hierarchically Network orchestrator: A functional entity that is hierarchically
intermediate between a service orchestrator and network intermediate between a service orchestrator and network
nontrollers. A network orchestrator can manage one or several controllers. A network orchestrator can manage one or several
network nontrollers. network controllers.
Network controller: A functional entity responsible for the control Network controller: A functional entity responsible for the control
and management of the service provider network. and management of the service provider network.
VPN node: An abstraction that represents a set of policies applied VPN node: An abstraction that represents a set of policies applied
on a PE and that belong to a single VPN service. A VPN service on a PE and that belong to a single VPN service. A VPN service
involves one or more VPN nodes. As it is an abstraction, the involves one or more VPN nodes. As it is an abstraction, the
network controller will take on how to implement a VPN node. For network controller will take on how to implement a VPN node. For
example, typically, in a BGP-based VPN, a VPN node could be mapped example, typically, in a BGP-based VPN, a VPN node could be mapped
into a Virtual Routing and Forwarding (VRF). into a Virtual Routing and Forwarding (VRF).
VPN network access: An abstraction that represents the network VPN network access: An abstraction that represents the network
interfaces that are associated to a given VPN node. Traffic interfaces that are associated to a given VPN node. Traffic
coming from the VPN network access belongs to the VPN. The coming from the VPN network access belongs to the VPN. The
attachment circuits (bearers) between CEs and PEs are terminated attachment circuits (bearers) between CEs and PEs are terminated
in the VPN network access. A reference to the bearer is in the VPN network access. A reference to the bearer is
maintained to allow keeping the link between L3SM and L3NM. maintained to allow keeping the link between L3SM and L3NM when
both models are used in a given deployment.
VPN site: A VPN customer's location that is connected to the VPN site: A VPN customer's location that is connected to the
service provider network via a CE-PE link, which can access at service provider network via a CE-PE link, which can access at
least one VPN [RFC4176]. least one VPN [RFC4176].
VPN service provider: A service provider that offers VPN-related VPN service provider: A service provider that offers VPN-related
services [RFC4176]. services [RFC4176].
Service provider network: A network that is able to provide VPN- Service provider network: A network that is able to provide VPN-
related services. related services.
skipping to change at page 6, line 33 skipping to change at page 6, line 33
The following acronyms are used in the document: The following acronyms are used in the document:
ACL Access Control List ACL Access Control List
AS Autonomous System AS Autonomous System
ASM Any-Source Multicast ASM Any-Source Multicast
ASN AS Number ASN AS Number
BSR Bootstrap Router BSR Bootstrap Router
BFD Bidirectional Forwarding Detection BFD Bidirectional Forwarding Detection
BGP Border Gateway Protocol BGP Border Gateway Protocol
CE Customer Edge CE Customer Edge
IGMP nternet Group Management Protocol IGMP Internet Group Management Protocol
L3VPN Layer 3 Virtual Private Network L3VPN Layer 3 Virtual Private Network
L3SM L3VPN Service Model L3SM L3VPN Service Model
L3NM L3VPN Network Model L3NM L3VPN Network Model
MLD Multicast Listener Discovery MLD Multicast Listener Discovery
MSDP Multicast Source Discovery Protocol MSDP Multicast Source Discovery Protocol
MVPN Multicast VPN MVPN Multicast VPN
NAT Network Address Translation NAT Network Address Translation
OAM Operations, Administration, and Maintenance OAM Operations, Administration, and Maintenance
OSPF Open Shortest Path First OSPF Open Shortest Path First
PE Provider Edge PE Provider Edge
skipping to change at page 7, line 21 skipping to change at page 7, line 21
section into three separate functional components: Service section into three separate functional components: Service
Orchestration, Network Orchestration, and Domain Orchestration. 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]. This separation relies upon a dedicated Section 1.3 of [RFC4176]. This separation relies upon a dedicated
communication interface between these components and appropriate YANG communication interface between these components and appropriate YANG
module that reflect network-related information (that is hidden to modules that reflect network-related information. Such information
customers). 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 (and vice versa) 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, the between the customer service model, the service delivery model, the
network configuration model, and the device configuration model. In network configuration model, and the device configuration model. In
that context, the "Domain Orchestration" and "Config Manager" roles that context, the "Domain Orchestration" and "Config Manager" roles
may be performed by "Controllers". may be performed by "Controllers".
+---------------+ +---------------+
| Customer | | Customer |
+---------------+ +-------+-------+
Customer Service Model | Customer Service Model |
e.g., l3vpn-svc | e.g., l3vpn-svc |
+---------------+ +-------+-------+
| Service | | Service |
| Orchestration | | Orchestration |
+---------------+ +-------+-------+
Network Model | 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: L3NM Reference Architecture Figure 1: L3NM Reference Architecture
The customer may use a variety of means to request a service that may The customer may use a variety of means to request a service that may
trigger the instantiation of a L3NM. The customer may use the L3SM trigger the instantiation of an L3NM. The customer may use the L3SM
or may rely upon more abstract models to request a service that or more abstract models to request a service that relies upon an
relies upon an L3VPN service. For example, the customer may supply L3VPN service. For example, the customer may supply an IP
an IP Connectivity Provisioning Profile (CPP) [RFC7297], an enhanced Connectivity Provisioning Profile (CPP) [RFC7297], an enhanced VPN
VPN (VPN+) service [I-D.ietf-teas-enhanced-vpn], an IETF network (VPN+) service [I-D.ietf-teas-enhanced-vpn], or an IETF network slice
slice [I-D.ietf-teas-ietf-network-slice-definition], or Abstraction service [I-D.ietf-teas-ietf-network-slices].
and Control of TE Networks (ACTN) [RFC8453].
Note also that both the L3SM and the L3NM may be used in the context Note also that both the L3SM and the L3NM may be used in the context
of the ACTN architecture. Figure 2 shows the Customer Network of the Abstraction and Control of TE Networks (ACTN) [RFC8453].
Controller (CNC), the Multi-Domain Service Coordinator (MDSC), and Figure 2 shows the Customer Network Controller (CNC), the Multi-
the Provisioning Network Controller (PNC). Domain Service Coordinator (MDSC), and the Provisioning Network
Controller (PNC) components and the interfaces where L3SM/L3NM are
used.
+----------------------------------+ +----------------------------------+
| Customer | | Customer |
| +-----------------------------+ | | +-----------------------------+ |
| | CNC | | | | CNC | |
| +-----------------------------+ | | +-----------------------------+ |
+----:-----------------------:-----+ +----+-----------------------+-----+
: : | |
: L3SM : L3SM | L3SM | L3SM
: : | |
+---------:---------+ +-------------------+ +---------+---------+ +---------+---------+
| MDSC : | | MDSC | | MDSC | | MDSC |
| +---------------+ | | (parent) | | +---------------+ | | (parent) |
| | 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 | |
| +---------+ | | +---------+ | | +---------+ | | +---------+ |
+------------:-------+ +---------:------------+ +------------+-------+ +---------+------------+
: : | |
: 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
The "ietf-vpn-common" module [I-D.ietf-opsawg-vpn-common] includes a The "ietf-vpn-common" module [I-D.ietf-opsawg-vpn-common] includes a
set of identities, types, and groupings that are meant to be reused set of identities, types, and groupings that are meant to be reused
by VPN-related YANG modules independently of the layer (e.g., Layer by VPN-related YANG modules independently of the layer (e.g., Layer
skipping to change at page 10, line 25 skipping to change at page 10, line 25
layers when required (service layer to network layer and vice versa), layers when required (service layer to network layer and vice versa),
early versions of the L3NM reused many of the data nodes that are early versions of the L3NM reused many of the data nodes that are
defined in [RFC8299]. Nevertheless, that approach was abandoned in defined in [RFC8299]. Nevertheless, that approach was abandoned in
favor of the "ietf-vpn-common" module because that initial design was favor of the "ietf-vpn-common" module because that initial design was
interpreted as if the deployment of L3NM depends on L3SM, while this 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 is not the case. For example, a service provider may decide to use
the L3NM to build its L3VPN services without exposing the L3SM. the L3NM to build its L3VPN services without exposing the L3SM.
As discussed in Section 4, the L3NM is meant to manage L3VPN services As discussed in Section 4, the L3NM is meant to manage L3VPN services
within a service provider network. The module provides a network within a service provider network. The module provides a network
view of the service. Such view is only visible within the service view of the service. Such a view is only visible within the service
provider and is not exposed outside (to customers, for example). The provider and is not exposed outside (to customers, for example). The
following discusses how L3NM interfaces with other YANG modules: 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 (i.e., L3NM) may be mapped to an The internal view of the service (i.e., 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].
The L3NM can be fed with inputs that are requested by customers, The L3NM can be fed with inputs that are requested by customers,
typically, relying upon a L3SM template. Concretely, some parts typically, relying upon an L3SM template. Concretely, some parts
of the L3SM module can be directly mapped into L3NM while other of the L3SM module can be directly mapped into L3NM while other
parts are generated as a function of the requested service and parts are generated as a function of the requested service and
local guidelines. Some other parts are local to the service local guidelines. Some other parts are local to the service
provider and do not map directly to L3SM. provider and do not map directly to L3SM.
Note that the use of L3NM within a service provider does not Note that the use of L3NM within a service provider does not
assume nor preclude exposing the VPN service via the L3SM. This assume nor preclude exposing the VPN service via the L3SM. This
is deployment-specific. Nevertheless, the design of L3NM tries to is 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: An L3VPN involves nodes that are part of a
topology managed by the service provider network. Such topology topology managed by the service provider network. Such topology
can be represented as using the network topology module in can be represented using the network topology module in [RFC8345].
[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:
skipping to change at page 11, line 44 skipping to change at page 11, line 44
6.1. Enterprise Layer 3 VPN Services 6.1. Enterprise Layer 3 VPN Services
Enterprise L3VPNs are one of the most demanded services for carriers, Enterprise L3VPNs are one of the most demanded services for carriers,
and therefore, L3NM can be useful to automate the provisioning and and therefore, L3NM can be useful to automate the provisioning and
maintenance of these VPNs. Templates and batch processes can be maintenance of these VPNs. Templates and batch processes can be
built, and as a result many parameters are needed for the creation built, and as a result many parameters are needed for the creation
from scratch of a VPN that can be abstracted to the upper Software- from scratch of a VPN that can be abstracted to the upper Software-
Defined Networking (SDN) [RFC7149][RFC7426] layer and little manual Defined Networking (SDN) [RFC7149][RFC7426] layer and little manual
intervention will be still required. intervention will be still required.
Also common addition and/or removal of sites of an existing customer A common function that is supported by VPNs is the addition or
VPN can benefit of using L3NM by creation of workflows that either removal of customer sites. Workflows can use the L3NM in these
prune or add nodes as required from the network data mode. scenarios to add or prune nodes from the network data model as
required.
6.2. Multi-Domain Resource Management 6.2. Multi-Domain Resource Management
The implementation of L3VPN services which span across The implementation of L3VPN services which span across
administratively separated domains (i.e., that are under the administratively separated domains (i.e., that are under the
administration of different management systems or controllers) administration of different management systems or controllers)
requires some network resources to be synchronized between systems. requires some network resources to be synchronized between systems.
Particularly, there are two resources that must be orchestrated and Particularly, resources must be adequately managed in each domain to
manage to avoid asymmetric (non-functional) configuration, or the avoid broken configuration.
usage of unavailable resources.
For example, route targets (RTs) shall be synchronized between PEs. For example, route targets (RTs) shall be synchronized between PEs.
When all PEs are controlled by the same management system, RT When all PEs are controlled by the same management system, RT
allocation can be performed by that management system. In cases allocation can be performed by that management system. In cases
where the service spans across multiple management systems, the task where the service spans across multiple management systems, the task
of allocating RTs has to be aligned across the domains, therefore, of allocating RTs has to be aligned across the domains, therefore,
the service model must provide a way to specify RTs. In addition, the service model must provide a way to specify RTs. In addition,
route distinguishers (RDs) must also be synchronized to avoid route distinguishers (RDs) must also be synchronized to avoid
collisions in RD allocation between separate management systems. An collisions in RD allocation between separate management systems. An
incorrect allocation might lead to the same RD and IP prefixes being incorrect allocation might lead to the same RD and IP prefixes being
exported by different PEs. exported by different PEs.
6.3. Management of Multicast Services 6.3. Management of Multicast Services
Multicast services over L3VPN can be implemented using dual PIM MVPNs Multicast services over L3VPN can be implemented using dual PIM MVPNs
(also known as, Draft Rosen model) [RFC4364] or Multiprotocol BGP (also known as, Draft Rosen model) [RFC6037] or Multiprotocol BGP
(MP-BGP)-based MVPNs [RFC6513][RFC6514]. Both methods are supported (MP-BGP)-based MVPNs [RFC6513][RFC6514]. Both methods are supported
and equally effective, but the main difference is that MBGP-based and equally effective, but the main difference is that MBGP-based
MVPN does not require multicast configuration on the service provider MVPN does not require multicast configuration on the service provider
network. MBGP MVPNs employ the intra-autonomous system BGP control network. MBGP MVPNs employ the intra-autonomous system BGP control
plane and PIM sparse mode as the data plane. The PIM state plane and PIM sparse mode as the data plane. The PIM state
information is maintained between PEs using the same architecture information is maintained between PEs using the same architecture
that is used for unicast VPNs. that is used for unicast VPNs.
On the other hand, [RFC4364] has limitations such as reduced options On the other hand, [RFC6037] has limitations such as reduced options
for transport, control plane scalability, availability, operational for transport, control plane scalability, availability, operational
inconsistency, and the need of maintaining state in the backbone. inconsistency, and the need of maintaining state in the backbone.
Because of these limitations, MBGP MVPN is the architectural model Because of these limitations, MBGP MVPN is the architectural model
that has been taken as the base for implementing multicast service in that has been taken as the base for implementing multicast service in
L3VPNs. In this scenario, BGP auto discovery is used to discover L3VPNs. In this scenario, BGP is used to auto-discover MVPN PE
MVPN PE members and the customer PIM signaling is sent across the members and the customer PIM signaling is sent across the provider's
provider's core through MP-BGP. The multicast traffic is transported core through MP-BGP. The multicast traffic is transported on MPLS
on MPLS P2MP LSPs. P2MP LSPs.
7. Description of the L3NM YANG Module 7. Description of the L3NM YANG Module
The L3NM ('ietf-l3vpn-ntw') is defined to manage L3VPNs in a service The L3NM ('ietf-l3vpn-ntw') is defined to manage L3VPNs in a service
provider network. In particular, the 'ietf-l3vpn-ntw' module can be provider network. In particular, the 'ietf-l3vpn-ntw' module can be
used to create, modify, and retrieve L3VPN services of a network. used to create, modify, and retrieve L3VPN services of a network.
The full tree diagram of the module can be generated using the The full tree diagram of the module can be generated using the
"pyang" tool [PYANG]. That tree is not included here because it is "pyang" tool [PYANG]. That tree is not included here because it is
too long (Section 3.3 of [RFC8340]). Instead, subtrees are provided too long (Section 3.3 of [RFC8340]). Instead, subtrees are provided
skipping to change at page 14, line 6 skipping to change at page 14, line 12
policies when building a VPN service. As shown in Figure 4, the policies when building a VPN service. As shown in Figure 4, the
following identifiers can be included: following identifiers can be included:
'external-connectivity-identifier': This identifier refers to a 'external-connectivity-identifier': This identifier refers to a
profile that defines the external connectivity provided to a VPN profile that defines the external connectivity provided to a VPN
service (or a subset of VPN sites). An external connectivity may service (or a subset of VPN sites). An external connectivity may
be an access to the Internet or a restricted connectivity such as be an access to the Internet or a restricted connectivity such as
access to a public/private cloud. access to a public/private cloud.
'encryption-profile-identifier': An encryption profile refers to a 'encryption-profile-identifier': An encryption profile refers to a
set of policies related to the encryption scheme(s) and setup that set of policies related to the encryption schemes and setup that
can be applied when building and offering a VPN service. can be applied when building and offering a VPN service.
'qos-profile-identifier': A Quality of Service (QoS) profile refers 'qos-profile-identifier': A Quality of Service (QoS) profile refers
to as set of policies such as classification, marking, and actions to as set of policies such as classification, marking, and actions
(e.g., [RFC3644]). (e.g., [RFC3644]).
'bfd-profile-identifier': A Bidirectional Forwarding Detection (BFD) 'bfd-profile-identifier': A Bidirectional Forwarding Detection (BFD)
profile refers to a set of BFD [RFC5880] policies that can be profile refers to a set of BFD [RFC5880] policies that can be
invoked when building a VPN service. invoked when building a VPN service.
skipping to change at page 15, line 12 skipping to change at page 15, line 18
in the service provider network. Each 'vpn-service' is uniquely 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. The subtree of the meaningful locally within the network controller. The subtree of the
'vpn-services' is shown in Figure 5. 'vpn-services' is shown in Figure 5.
+--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 vpn-id +--rw vpn-id vpn-common:vpn-id
+--rw vpn-name? string +--rw vpn-name? string
+--rw vpn-description? string +--rw vpn-description? string
+--rw customer-name? string +--rw customer-name? string
+--rw parent-service-id? vpn-common:vpn-id +--rw parent-service-id? vpn-common:vpn-id
+--rw vpn-type? identityref +--rw vpn-type? identityref
+--rw vpn-service-topology? identityref +--rw vpn-service-topology? identityref
+--rw status +--rw status
| +--rw admin-status | +--rw admin-status
| | +--rw status? identityref | | +--rw status? identityref
| | +--rw last-updated? yang:date-and-time | | +--rw last-updated? yang:date-and-time
| +--ro oper-status | +--ro oper-status
| +--ro status? identityref | +--ro status? identityref
| +--ro last-updated? yang:date-and-time | +--ro last-updated? yang:date-and-time
+--rw ie-profiles +--rw vpn-instance-profiles
| ... | ...
+--rw underlay-transport +--rw underlay-transport
| +-- (type)? | +-- (type)?
| +--:(abstract) | +--:(abstract)
| | +-- transport-instance-id? string | | +-- transport-instance-id? string
| +--:(protocol) | +--:(protocol)
| +-- protocol* identityref | +-- protocol* identityref
+--rw external-connectivity +--rw external-connectivity
| {external-connectivity} | {external-connectivity}
| +--rw (profile)? | +--rw (profile)?
skipping to change at page 16, line 23 skipping to change at page 16, line 29
'parent-service-id': Refers to an identifier of the parent service 'parent-service-id': Refers to an identifier of the parent service
(e.g, L3SM, IETF network slice, VPN+) that triggered the creation (e.g, L3SM, IETF network slice, VPN+) that triggered the creation
of the VPN service. This identifier is used to easily correlate of the VPN service. This identifier is used to easily correlate
the (network) service as built in the network with a service the (network) service as built in the network with a service
order. A controller can use that correlation to enrich or order. A controller can use that correlation to enrich or
populate some fields (e.g., description fields) as a function of populate some fields (e.g., description fields) as a function of
local deployments. local deployments.
'vpn-type': Indicates the VPN type. The values are taken from 'vpn-type': Indicates the VPN type. The values are taken from
[I-D.ietf-opsawg-vpn-common]. For the L3NM, this is typically set [I-D.ietf-opsawg-vpn-common]. For the L3NM, this is typically set
to BGP/MPLS L3VPN. to BGP/MPLS L3VPN, but other values may be defined in the future
to support specific Layer 3 VPN capabilities (e.g.,
[I-D.ietf-bess-evpn-prefix-advertisement]).
'vpn-service-topology': Indicates the network topology for the 'vpn-service-topology': Indicates the network topology for the
service: hub-spoke, any-to-any, or custom. The network service: hub-spoke, any-to-any, or custom. The network
implementation of this attribute is defined by the correct usage implementation of this attribute is defined by the correct usage
of import and export profiles (Section 4.3.5 of [RFC4364]). of import and export profiles (Section 4.3.5 of [RFC4364]).
'status': Is used to track the service status of a given VPN 'status': Is used to track the service status of a given VPN
service. Both operational and administrative status are service. Both operational and administrative status are
maintained together with a timestamp. For example, a service can maintained together with a timestamp. For example, a service can
be created, but not put into effect. be created, but not put into effect.
Administrative and operational status can be used as a trigger to Administrative and operational status can be used as a trigger to
detect service anomalies. For example, a service that is declared detect service anomalies. For example, a service that is declared
at the service layer as being active but still inactive at the at the service layer as being active but still inactive at the
network layer is an indication that network provision actions are network layer is an indication that network provision actions are
needed to align the observed service status with the expected needed to align the observed service status with the expected
service status. service status.
'ie-profiles': Defines reusable import/export policies for the same 'vpn-instance-profiles': Defines reusable parameters for the same
'vpn-service'. 'vpn-service'.
More details are provided in Section 7.4. More details are provided in Section 7.4.
'underlay-transport': Describes the preference for the transport 'underlay-transport': Describes the preference for the transport
technology to carry the traffic of the VPN service. This technology to carry the traffic of the VPN service. This
preference is especially useful in networks with multiple domains preference is especially useful in networks with multiple domains
and Network-to-Network Interface (NNI) types. The underlay and Network-to-Network Interface (NNI) types. The underlay
transport can be expressed as an abstract transport instance transport can be expressed as an abstract transport instance
(e.g., an identifier of a VPN+ instance, a virtual network (e.g., an identifier of a VPN+ instance, a virtual network
skipping to change at page 17, line 42 skipping to change at page 18, line 5
'vpn-network-accesses'. 'vpn-network-accesses'.
Note that, as this is a network data model, the information about Note that, as this is a network data model, the information about
customers sites is not required in the model. Such information is customers sites is not required in the model. Such information is
rather relevant in the L3SM. Whether that information is included rather relevant in the L3SM. Whether that information is included
in the L3NM, e.g., to populate the various 'description' data node in the L3NM, e.g., to populate the various 'description' data node
is implementation specific. is implementation specific.
More details are provided in Section 7.5. More details are provided in Section 7.5.
7.4. Import/Export Profiles 7.4. VPN Instance Profiles
The import and export profiles construct contains a list with VPN instance profiles are meant to factorize data nodes that are used
information related with route targets and distinguishers (RTs and at many levels of the model. Generic VPN instance profiles are
RDs), grouped and identified by 'ie-profile-id'. The identifier is defined at the VPN service level and then called at the VPN node and
then referenced in one or multiple 'vpn-nodes' (Section 7.5) so that VPN network access levels. Each VPN instance profile is identified
the controller can identify RTs and RDs to be configured for a given by 'profile-id'. This identifier is then referenced for one or
VRF. The subtree of 'ie-profiles' is shown in Figure 6. multiple VPN nodes (Section 7.5) so that the controller can identify
generic resources (e.g., RTs and RDs) to be configured for a given
VRF.
The following modes are supported in: The subtree of 'vpn-instance-profile' is shown in Figure 6.
'full-autoasigned': The network controller auto-assigns logical +--rw l3vpn-ntw
resources (RTs, RDs). This can apply for the deployment of new +--rw vpn-profiles
services. | ...
+--rw vpn-services
+--rw vpn-service* [vpn-id]
+--rw vpn-id vpn-common:vpn-id
...
+--rw vpn-instance-profiles
| +--rw vpn-instance-profile* [profile-id]
| +--rw profile-id string
| +--rw role? identityref
| +--rw local-autonomous-system? inet:as-number
| | {vpn-common:rtg-bgp}?
| +--rw (rd-choice)?
| | +--:(directly-assigned)
| | | +--rw rd?
| | | rt-types:route-distinguisher
| | +--:(directly-assigned-suffix)
| | | +--rw rd-suffix? uint16
| | +--:(auto-assigned)
| | | +--rw rd-auto
| | | +--rw (auto-mode)?
| | | | +--:(from-pool)
| | | | | +--rw rd-pool-name? string
| | | | +--:(full-auto)
| | | | +--rw auto? empty
| | | +--ro auto-assigned-rd?
| | | rt-types:route-distinguisher
| | +--:(auto-assigned-suffix)
| | | +--rw rd-auto-suffix
| | | +--rw (auto-mode)?
| | | | +--:(from-pool)
| | | | | +--rw rd-pool-name? string
| | | | +--:(full-auto)
| | | | +--rw auto? empty
| | | +--ro auto-assigned-rd-suffix? uint16
| | +--:(no-rd)
| | +--rw no-rd? empty
| +--rw address-family* [address-family]
| | +--rw address-family identityref
| | +--rw vpn-targets
| | | +--rw vpn-target* [id]
| | | | +--rw id int8
| | | | +--rw route-targets* [route-target]
| | | | | +--rw route-target
| | | | | rt-types:route-target
| | | | +--rw route-target-type
| | | | rt-types:route-target-type
| | | +--rw vpn-policies
| | | +--rw import-policy? string
| | | +--rw export-policy? string
| | +--rw maximum-routes* [protocol]
| | +--rw protocol identityref
| | +--rw maximum-routes? uint32
| +--rw multicast {vpn-common:multicast}?
| ...
'rd-from-pool': A variant of the previous one is to indicate a pool Figure 6: Subtree Structure of VPN Instance Profiles
from where the RD values can be auto-assigned.
'directly-assigned': The VPN service provider (service orchestrator) The description of the listed data nodes is as follows:
assigns explicitly the RTs and RDs. This case will fit with a
brownfield scenario where some existing services need to be
updated by the VPN service provider.
'no-rd': The (service orchestrator) explicitly wants no RT/RD to be 'profile-id': Is used to uniquely identify a VPN instance profile.
assigned. This case can be used for CE testing within the network
or for troubleshooting proposes.
+--rw l3vpn-ntw 'role': Indicates the role of the VPN instance profile in the VPN.
+--rw vpn-profiles Role values are defined in [I-D.ietf-opsawg-vpn-common] (e.g.,
| ... any-to-any-role, spoke-role, hub-role).
+--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-choice)?
| | +--:(directly-assigned)
| | | +--rw rd?
| | | rt-types:route-distinguisher
| | +--:(pool-assigned)
| | | +--rw rd-pool-name? string
| | | +--ro rd-from-pool?
| | | rt-types:route-distinguisher
| | +--:(full-autoasigned)
| | | +--rw auto? empty
| | | +--ro rd-auto?
| | | rt-types:route-distinguisher
| | +--:(no-rd)
| | +--rw no-rd? empty
| +--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 node-ie-profile? leafref
...
Figure 6: Subtree Structure of Import/Export Profiles 'local-autonomous-system': Indicates the Autonomous System Number
(ASN) that is configured for the VPN node.
'rd': As defined in [I-D.ietf-opsawg-vpn-common], these RD
assignment modes are supported: direct assignment, automatic
assignment from a given pool, automatic assignment, and no
assignment. For illustration purposes, the following modes can be
used in the deployment cases:
'directly-assigned': The VPN service provider (service
orchestrator) assigns explicitly RDs. This case will fit with
a brownfield scenario where some existing services need to be
updated by the VPN service provider.
'full-auto': The network controller auto-assigns RDs. This can
apply for the deployment of new services.
'no-rd': The VPN service provider (service orchestrator)
explicitly wants no RD to be assigned. This case can be used
for CE testing within the network or for troubleshooting
proposes.
Also, the module accommodates deployments where only the Assigned
Number subfield of RDs (Section 4.2 of [RFC4364]) is assigned from
a pool while the Administrator subfield is set to, e.g., the
Router ID that is assigned to a VPN node. The module supports
these modes for managing the Assigned Number subfield: explicit
assignment, auto-assignment from a pool, and full auto-assignment.
'address-family': Includes a set of per-address family data nodes:
'address-family': Identifies the address family. It can be set
to IPv4, IPv6, or dual-stack.
'vpn-targets': Specifies RT import/export rules for the VPN
service (Section 4.3 of [RFC4364]).
'maximum-routes': Indicates the maximum prefixes that the VPN
node can accept for a given routing protocol. If 'protocol' is
set to 'any', this means that the maximum value applies to each
active routing protocol.
'multicast': Enables multicast traffic in the VPN service. Refer to
Section 7.7.
7.5. VPN Nodes 7.5. VPN Nodes
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 (typically, a PE) and belong policies applied on a given network node (typically, a PE) and belong
to one L3VPN service. The 'vpn-node' includes a parameter to to one L3VPN service. The 'vpn-node' includes a parameter to
indicate the network node on which it is applied. In the case that indicate the network node on which it is applied. In the case that
the 'ne-id' points to a specific PE, the 'vpn-node' will likely be the 'ne-id' points to a specific PE, the 'vpn-node' will likely be
mapped into a VRF in the node. However, the model also allows to mapped into a VRF in the node. However, the model also allows to
point to an abstract node. In this case, the network controller will point to an abstract node. In this case, the network controller will
decide how to split the 'vpn-node' into VRFs. decide how to split the 'vpn-node' into VRFs.
+--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-nodes +--rw vpn-nodes
+--rw vpn-node* [vpn-node-id] +--rw vpn-node* [vpn-node-id]
+--rw vpn-node-id union +--rw vpn-node-id vpn-common:vpn-id
+--rw description? string +--rw description? string
+--rw ne-id? string +--rw ne-id? string
+--rw node-role? identityref +--rw local-autonomous-system? inet:as-number
+--rw local-autonomous-system? inet:as-number | {vpn-common:rtg-bgp}?
| {vpn-common:rtg-bgp}? +--rw router-id? rt-types:router-id
+--rw address-family? identityref +--rw active-vpn-instance-profiles
+--rw router-id? inet:ip-address | +--rw vpn-instance-profile* [profile-id]
+--rw (rd-choice)? | +--rw profile-id leafref
| +--:(directly-assigned) | +--rw router-id* [address-family]
| | +--rw rd? | | +--rw address-family identityref
| | rt-types:route-distinguisher | | +--rw router-id? inet:ip-address
| +--:(pool-assigned) | +--rw local-autonomous-system? inet:as-number
| | +--rw rd-pool-name? string | | {vpn-common:rtg-bgp}?
| | +--ro rd-from-pool? | +--rw (rd-choice)?
| | rt-types:route-distinguisher | | ....
| +--:(full-autoasigned) | +--rw address-family* [address-family]
| | +--rw auto? empty | | +--rw address-family identityref
| | +--ro rd-auto? | | | ...
| | rt-types:route-distinguisher | | +--rw vpn-targets
| +--:(no-rd) | | | ...
| +--rw no-rd? empty | | +--rw maximum-routes* [protocol]
+--rw vpn-targets | | ...
| +--rw vpn-target* [id] | +--rw multicast {vpn-common:multicast}?
| | +--rw id int8 | ...
| | +--rw route-targets* [route-target] +--rw msdp {msdp}?
| | | +--rw route-target | +--rw peer? inet:ip-address
| | | rt-types:route-target | +--rw local-address? inet:ip-address
| | +--rw route-target-type | +--rw status
| | rt-types:route-target-type | +--rw admin-status
| +--rw vpn-policies | | +--rw status? identityref
| +--rw import-policy? string | | +--rw last-updated? yang:date-and-time
| +--rw export-policy? string | +--ro oper-status
+--rw node-ie-profile? leafref | +--ro status? identityref
+--rw maximum-routes | +--ro last-updated? yang:date-and-time
| +--rw selector* [address-family protocol] +--rw groups
| +--rw address-family identityref | +--rw group* [group-id]
| +--rw protocol identityref | +--rw group-id string
| +--rw maximum-routes? uint32 +--rw status
+--rw groups | +--rw admin-status
| +--rw group* [group-id] | | +--rw status? identityref
| +--rw group-id string | | +--rw last-updated? yang:date-and-time
+--rw multicast {vpn-common:multicast}? | +--ro oper-status
| ... | +--ro status? identityref
+--rw status | +--ro last-updated? yang:date-and-time
| +--rw admin-status +--rw vpn-network-accesses
| | +--rw status? identityref ...
| | +--rw last-updated? yang:date-and-time
| +--ro oper-status
| +--ro status? identityref
| +--ro last-updated? yang:date-and-time
+--rw vpn-network-accesses
...
Figure 7: VPN Node Subtree Structure Figure 7: VPN Node Subtree Structure
In reference to the subtree shown in Figure 7, the description of VPN In reference to the subtree shown in Figure 7, the description of VPN
node data nodes is as follows: node data nodes is as follows:
'vpn-node-id': Is an identifier that uniquely identifies a node that 'vpn-node-id': Is an identifier that uniquely identifies a node that
enable a VPN network access. enables a VPN network access.
'description': Providers a textual description of the VPN node. 'description': Provides a textual description of the VPN node.
'ne-id': Includes a unique identifier of the network element where 'ne-id': Includes a unique identifier of the network element where
the VPN node is deployed. the VPN node is deployed.
'node-role': Indicates the role of the VPN node in the VPN. Roles 'local-autonomous-system': Indicates the ASN that is configured for
values are defines defined in [I-D.ietf-opsawg-vpn-common] (e.g., the VPN node.
any-to-any-role, spoke-role, hub-role).
'local-autonomous-system': Indicates the BGP Autonomous System
Number (ASN) that is configured for the VPN node.
'address-family': Is used to identify the address family used for
the Router ID. It can be set to IPv4 or IPv6.
'router-id': Indicates a unique Router ID information. It can be an
IPv4 or IPv6 address as a function of the enclosed address-family.
'rd': If the logical resources are managed outside the network
controller, the model allows to explicitly indicate the logical
resources such as RTs and RDs.
As defined in [I-D.ietf-opsawg-vpn-common] and recalled in 'router-id': Indicates a 32-bit number that is used to uniquely
Section 7.4, RDs can be explicitly configured or automatically identify a router within an Autonomous System.
assigned. RD auto- assignment can also constrained by indicating
an RD pool name ('rd- pool-name').
'vpn-targets': Specifies RT import/export rules for the VPN service. 'active-vpn-instance-profiles': Lists the set of active VPN instance
profiles for this VPN node. Concretely, one or more VPN instance
profiles that are defined at the VPN service level can be enabled
at the VPN node level; each of these profiles is uniquely
identified by means of 'profile-id'. The structure of 'active-
vpn-instance-profiles' is the same as the one discussed in
Section 7.4 with the exception of 'router-id'. Indeed, Router IDs
can be configured per address family. This capability can be
used, for example, to configure an IPv6 address as a Router ID
when such capability is supported by involved routers.
'node-ie-profile': Refer to Section 7.4. Values defined in 'active-vpn-instance-profiles' overrides the
ones defined in the VPN service level.
'maximum-routes': Indicates the maximum prefixes that the VPN node 'msdp': For redundancy purposes, Multicast Source Discovery Protocol
can accept for a given address family and routing protocol. If (MSDP) [RFC3618] may be enabled and used to share the state about
'protocol' is set to 'any', this means that the maximum value sources between multiple rendez-vous points (RPs). The purpose of
applies to any active routing protocol. MSDP in this context is to enhance the robustness of the multicast
service. MSDP may be configured on non-RP routers, which is
useful in a domain that does not support multicast sources, but
does support multicast transit.
'groups': Lists the groups to which a VPN node belongs to 'groups': Lists the groups to which a VPN node belongs to
[I-D.ietf-opsawg-vpn-common]. The 'group-id' is used to [I-D.ietf-opsawg-vpn-common]. The 'group-id' is used to
associate, e.g., redundancy or protection constraints with VPN associate, e.g., redundancy or protection constraints with VPN
nodes. nodes.
'multicast': Enables multicast traffic in the VPN. Refer to
Section 7.7.
'status': Tracks the status of a node involved in a VPN service. 'status': Tracks the status of a node involved in a VPN service.
Both operational and administrative status are maintained. A Both operational and administrative status are maintained. A
mismatch between the administrative status vs. the operational mismatch between the administrative status vs. the operational
status can be used as a trigger to detect anomalies. status can be used as a trigger to detect anomalies.
'vpn-network-accesses': Represents the point to which sites are 'vpn-network-accesses': Represents the point to which sites are
connected. connected.
Note that, unlike in L3SM, the L3NM does not need to model the 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 customer site, only the points where the traffic from the site are
skipping to change at page 23, line 21 skipping to change at page 24, line 15
... ...
+--rw vpn-nodes +--rw vpn-nodes
+--rw vpn-node* [vpn-node-id] +--rw vpn-node* [vpn-node-id]
... ...
+--rw vpn-network-accesses +--rw vpn-network-accesses
+--rw vpn-network-access* [id] +--rw vpn-network-access* [id]
+--rw id vpn-common:vpn-id +--rw id vpn-common:vpn-id
+--rw port-id? vpn-common:vpn-id +--rw port-id? vpn-common:vpn-id
+--rw description? string +--rw description? string
+--rw vpn-network-access-type? identityref +--rw vpn-network-access-type? identityref
+--rw vpn-instance-profile? leafref
+--rw status +--rw status
| +--rw admin-status | +--rw admin-status
| | +--rw status? identityref | | +--rw status? identityref
| | +--rw last-updated? yang:date-and-time | | +--rw last-updated? yang:date-and-time
| +--ro oper-status | +--ro oper-status
| +--ro status? identityref | +--ro status? identityref
| +--ro last-updated? yang:date-and-time | +--ro last-updated? yang:date-and-time
+--rw connection +--rw connection
| ... | ...
+--rw ip-connection +--rw ip-connection
skipping to change at page 23, line 48 skipping to change at page 24, line 43
+--rw service +--rw service
... ...
Figure 8: VPN Network Access Subtree Structure Figure 8: VPN Network Access Subtree Structure
In reference to the subtree depicted in Figure 8, a 'vpn-network- In reference to the subtree depicted in Figure 8, a 'vpn-network-
access' includes the following data nodes: access' includes the following data nodes:
'id': Is an identifier of the VPN network access. 'id': Is an identifier of the VPN network access.
'port-id': Indicates the physical port on which the VPN network 'port-id': Indicates the port on which the VPN network access is
access is bound. bound.
'description': Includes a textual description of the VPN network 'description': Includes a textual description of the VPN network
access. access.
'vpn-network-access-type': Is used to select the type of network 'vpn-network-access-type': Is used to select the type of network
interface to be deployed in the devices. The available options interface to be deployed in the devices. The available defined
are: values are:
Point-to-Point: Represents a direct connection between the end- 'point-to-point': Represents a direct connection between the
points. It implies that the controller must keep the endpoints. The controller must keep the association between a
association between a logical or physical interface on the logical or physical interface on the device with the 'id' of
device with the 'id' of the 'vpn-network-access'. the 'vpn-network-access'.
Multipoint: Represents a broadcast connection between the end- 'multipoint': Represents a broadcast connection between the
points. It implies that the controller must keep the endpoints. The controller must keep the association between a
association between a logical or physical interface on the logical or physical interface on the device with the 'id' of
device with the 'id' of the 'vpn-network-access'. the 'vpn-network-access'.
Pseudowire: Represents a connection coming from an L2VPN service. 'irb': Represents a connection coming from an L2VPN service. An
It implies that the controller must keep the relationship identifier of such service ('l2vpn-id') may be included in the
between the logical tunnels or bridges on the devices with the 'connection' container as depicted in Figure 9. The controller
'id' of the' vpn-network-access'. must keep the relationship between the logical tunnels or
bridges on the devices with the 'id' of the' vpn-network-
access'.
Loopback: Represents the creation of a logical interface on a 'loopback': Represents the creation of a logical interface on a
device. An example to illustrate how loopback interfaces can device. An example to illustrate how a loopback interface can
be created is provided in Figure 35. be used in the L3NM is provided in Appendix A.2.
'vpn-instance-profile': Provides a pointer to an active VPN instance
profile at the VPN node level. Referencing an active VPN instance
profile implies that all associated data nodes will be inherited
by the VPN network access. However, some of the inherited data
nodes (e.g., multicast) can be refined at the VPN network access
level. In such case, refined values take precedence over
inherited ones.
'status': Indicates both operational and administrative status of a 'status': Indicates both operational and administrative status of a
VPN network access. VPN network access.
'connection': Represents and groups the set of Layer 2 connectivity 'connection': Represents and groups the set of Layer 2 connectivity
from where the traffic of the L3VPN in a particular VPN Network from where the traffic of the L3VPN in a particular VPN Network
access is coming. See Section 7.6.1. access is coming. See Section 7.6.1.
'ip-connection': Contains the IP addressing information of a VPN 'ip-connection': Contains Layer 3 connectivity information of a VPN
network access. See Section 7.6.2. network access (e.g., IP addressing). See Section 7.6.2.
'routing-protocols': Represents and groups the set of Layer 2 'routing-protocols': Includes the CE-PE rouing configuration
connectivity from where the traffic of the L3VPN in a particular information. See Section 7.6.3.
VPN Network access is coming. See Section 7.6.3.
'oam': Specifies the Operations, Administration, and Maintenance 'oam': Specifies the Operations, Administration, and Maintenance
(OAM) mechanisms used for a VPN network accesss. See (OAM) mechanisms used for a VPN network access. See
Section 7.6.4. Section 7.6.4.
'security': Specifies the authentication and the encryption to be 'security': Specifies the authentication and the encryption to be
applied for a given VPN network access. See Section 7.6.5. applied for a given VPN network access. See Section 7.6.5.
'service': Specifies the service parameters (e.g., QoS, multicast) 'service': Specifies the service parameters (e.g., QoS, multicast)
to apply for a given VPN network access. See Section 7.6.6. to apply for a given VPN network access. See Section 7.6.6.
7.6.1. Connection 7.6.1. Connection
The definition of a L3VPN is commonly specified not only at the IP The 'connection' container represents the layer 2 connectivity to the
layer, but also requires to provide parameters at the Ethernet layer, L3VPN for a particular VPN network access. As shown in the tree
such as specifying an encapsulation type (e.g., VLAN, QinQ, QinAny, depicted in Figure 9, the 'connection' container defines protocols
VxLAN, etc.). The L3NM uses the 'connection' container to specify and parameters to enable such connectivity at layer 2.
such parameters.
The traffic can enter the VPN with or without encapsulation (e.g.,
VLAN, QinQ). The 'encapsulation' container specifies the layer 2
encapsulation to use (if any) and allows to configure the relevant
tags.
The interface that is attached to the L3VPN is identified by the
'port-id' at the 'vpn-network-access' level. From a network model
perspective, it is expected that the 'port-id' is sufficient to
identify the interface. However, specific layer 2 sub-interfaces may
be required to be configured in some implementations/deployments.
Such a layer 2 specific interface can be included in 'l2-termination-
point'.
If a layer 2 tunnel is needed to terminate the service in the CE-PE
connection, the 'l2-tunnel-service' container is used to specify the
required parameters to set such tunneling service (e.g., VPLS,
VXLAN). An identity, called 'l2-tunnel-type', is defined for layer 2
tunnel selection.
To accommodate implementations that require internal bridging, a
local bridge reference can be specified in 'local-bridge-reference'.
Such a reference may be a local bridge domain.
As discussed in Section 7.6, 'l2vpn-id' is used to identify the L2VPN
service that is associated with an IRB interface.
A site, as per [RFC4176] represents a VPN customer's location that is A site, as per [RFC4176] represents a VPN customer's location that is
connected to the service provider network via a CE-PE link, which can connected to the service provider network via a CE-PE link, which can
access at least one VPN. The connection from the site to the service access at least one VPN. The connection from the site to the service
provider network is the bearer. Every site is associated with a list provider network is the bearer. Every site is associated with a list
of bearers. A bearer is the layer two connections with the site. In of bearers. A bearer is the layer two connections with the site. In
the L3NM, it is assumed that the bearer has been allocated by the the L3NM, it is assumed that the bearer has been allocated by the
service provider at the service orchestration stage. The bearer is service provider at the service orchestration stage. The bearer is
associated to a network element and a port. Hence, a bearer is just associated to a network element and a port. Hence, a bearer is just
a bearer-reference to allow the translation between a service request a 'bearer-reference' to allow the association between a service
(e.g., L3SM) and L3NM. request (e.g., L3SM) and L3NM.
As shown in Figure 9, the 'connection' container defines protocols
and parameters to enable connectivity at Layer 2.
... ...
+--rw connection +--rw connection
| +--rw encapsulation-type? identityref | +--rw encapsulation
| +--rw logical-interface | | +--rw type? identityref
| | +--rw peer-reference? uint32 | | +--rw dot1q {vpn-common:dot1q}?
| +--rw tagged-interface | | | +--rw tag-type? identityref
| | +--rw type? identityref | | | +--rw cvlan-id? uint16
| | +--rw dot1q-vlan-tagged {vpn-common:dot1q}? | | +--rw priority-tagged
| | | +--rw tag-type? identityref | | | +--rw tag-type? identityref
| | | +--rw cvlan-id? uint16 | | +--rw qinq {vpn-common:qinq}?
| | +--rw priority-tagged | | +--rw tag-type? identityref
| | | +--rw tag-type? identityref | | +--rw svlan-id uint16
| | +--rw qinq {vpn-common:qinq}? | | +--rw cvlan-id uint16
| | | +--rw tag-type? identityref | +--rw l2-tunnel-service
| | | +--rw svlan-id uint16 | | +--rw type? identityref
| | | +--rw cvlan-id uint16 | | +--rw pseudowire
| | +--rw qinany {vpn-common:qinany}? | | | +--rw vcid? uint32
| | | +--rw tag-type? identityref | | | +--rw far-end? union
| | | +--rw svlan-id uint16 | | +--rw vpls
| | +--rw vxlan {vpn-common:vxlan}? | | | +--rw vcid? union
| | +--rw vni-id uint32 | | | +--rw far-end? union
| | +--rw peer-mode? identityref | | +--rw vxlan {vpn-common:vxlan}?
| | +--rw peer-list* [peer-ip] | | +--rw vni-id uint32
| | +--rw peer-ip inet:ip-address | | +--rw peer-mode? identityref
| +--rw bearer | | +--rw peer-ip-address* inet:ip-address
| +--rw bearer-reference? string | +--rw l2-termination-point? vpn-common:vpn-id
| | {vpn-common:bearer-reference}? | +--rw local-bridge-reference? vpn-common:vpn-id
| +--rw pseudowire | +--rw l2vpn-id? vpn-common:vpn-id
| | +--rw vcid? uint32 | +--rw bearer-reference? string
| | +--rw far-end? union {vpn-common:bearer-reference}?
| +--rw vpls ...
| +--rw vcid? union
| +--rw far-end? union
...
Figure 9: Connection Subtree Structure Figure 9: Connection Subtree Structure
7.6.2. IP Connections 7.6.2. IP Connection
This container is used to group the IP addressing information of a This container is used to group Layer 3 connectivity information,
VPN network access. The allocated address represents the PE particularly the IP addressing information, of a VPN network access.
interface address configuration. As shown in Figure 10, this The allocated address represents the PE interface address
container can include IPv4, IPv6, or both information if dual-stack configuration. Note that a distinct layer 3 interface than the one
is enabled. indicated under the 'connection' container may be needed to terminate
the layer 3 service. The identifier of such interface is included in
'l3-termination-point'. For example, this data node can be used to
carry the identifier of a bridge domain Interface.
... As shown in Figure 10, the 'ip-connection' container can include
+--rw vpn-network-accesses IPv4, IPv6, or both if dual-stack is enabled.
+--rw vpn-network-access* [id]
... ...
+--rw ip-connection +--rw vpn-network-accesses
| +--rw ipv4 {vpn-common:ipv4}? +--rw vpn-network-access* [id]
| | ... ...
| +--rw ipv6 {vpn-common:ipv6}? +--rw ip-connection
| ... | +--rw l3-termination-point? vpn-common:vpn-id
... | +--rw ipv4 {vpn-common:ipv4}?
| | ...
| +--rw ipv6 {vpn-common:ipv6}?
| ...
...
Figure 10: IP Connection Subtree Structure Figure 10: IP Connection Subtree Structure
For both IPv4 and IPv6, the IP connection supports three IP address For both IPv4 and IPv6, the IP connection supports three IP address
assignment modes for customer addresses: provider DHCP, DHCP relay, assignment modes for customer addresses: provider DHCP, DHCP relay,
and static addressing. Only one mode is enabled for a given service. and static addressing. Note that for the IPv6 case, SLAAC [RFC4862]
Note that for the IPv6 cases, SLAAC [RFC7527] can be used. can be used. For both IPv4 and IPv6, 'address-allocation-type' is
used to indicate the IP address allocation mode to activate for a
given VPN network access.
Figure 11 shows the structure of the dynamic IPv4 address assignment. When 'address-allocation-type' is set to 'provider-dhcp', DHCP
assignments can be made locally or by an external DHCP server. Such
as behavior is controlled by setting 'dhcp-service-type'.
... Figure 11 shows the structure of the dynamic IPv4 address assignment
+--rw ip-connection (i.e., by means of DHCP).
| +--rw ipv4 {vpn-common:ipv4}?
| | +--rw local-address? inet:ipv4-prefix ...
| | +--rw address-allocation-type? identityref +--rw ip-connection
| | +--rw (allocation-type)? | +--rw l3-termination-point? vpn-common:vpn-id
| | +--:(provider-dhcp) | +--rw ipv4 {vpn-common:ipv4}?
| | | +--rw dhcp-server-enable? boolean | | +--rw local-address? inet:ipv4-address
| | | +--rw (address-assign)? | | +--rw prefix-length? uint8
| | | +--:(number) | | +--rw address-allocation-type? identityref
| | | | +--rw number-of-dynamic-address? uint16 | | +--rw (allocation-type)?
| | | +--:(explicit) | | +--:(provider-dhcp)
| | | +--rw customer-addresses | | | +--rw dhcp-service-type? enumeration
| | | +--rw address-group* [group-id] | | | +--rw (service-type)?
| | | +--rw group-id string | | | +--:(relay)
| | | +--rw start-address? inet:ipv4-address | | | | +--rw server-ip-address*
| | | +--rw end-address? inet:ipv4-address | | | | inet:ipv4-address
| | +--:(dhcp-relay) | | | +--:(server)
| | | +--rw dhcp-relay-enable? boolean | | | +--rw (address-assign)?
| | | +--rw customer-dhcp-servers | | | +--:(number)
| | | +--rw server-ip-address* inet:ipv4-address | | | | +--rw number-of-dynamic-address?
| | +--:(static-addresses) | | | | uint16
| | ... | | | +--:(explicit)
... | | | +--rw customer-addresses
| | | +--rw address-pool* [pool-id]
| | | +--rw pool-id string
| | | +--rw start-address?
| | | | inet:ipv4-address
| | | +--rw end-address?
| | | inet:ipv4-address
| | +--:(dhcp-relay)
| | | +--rw customer-dhcp-servers
| | | +--rw server-ip-address* inet:ipv4-address
| | +--:(static-addresses)
| | ...
...
Figure 11: IP Connection Subtree Structure (IPv4) Figure 11: IP Connection Subtree Structure (IPv4)
Figure 12 shows the structure of the dynamic IPv6 address assignment. Figure 12 shows the structure of the dynamic IPv6 address assignment
(i.e., DHCPv6 and/or SLAAC). Note that if 'address-allocation-type'
is set to 'slaac', the Prefix Information option of Router
Advertisements that will be issued for SLAAC purposes, will carry the
IPv6 prefix that is determined by 'local-address' and 'prefix-
length'. For example, if 'local-address' is set to '2001:db8:0:1::1'
and 'prefix-length' is set to '64', the IPv6 prefix that will be used
is '2001:db8:0:1::/64'.
... ...
+--rw ip-connection +--rw ip-connection
| +--rw ipv4 {vpn-common:ipv4}? | +--rw l3-termination-point? vpn-common:vpn-id
| | ... | +--rw ipv4 {vpn-common:ipv4}?
| +--rw ipv6 {vpn-common:ipv6}? | | ...
| +--rw local-address? inet:ipv6-prefix | +--rw ipv6 {vpn-common:ipv6}?
| +--rw address-allocation-type? identityref | +--rw local-address? inet:ipv6-address
| +--rw (allocation-type)? | +--rw prefix-length? uint8
| +--:(provider-dhcp) | +--rw address-allocation-type? identityref
| | +--rw dhcp-server-enable? boolean | +--rw (allocation-type)?
| | +--rw (address-assign)? | | +--rw provider-dhcp
| | +--:(number) | | +--rw dhcp-service-type? enumeration
| | | +--rw number-of-dynamic-address? uint16 | | +--rw (service-type)?
| | +--:(explicit) | | +--:(provider-dhcp-servers)
| | +--rw customer-addresses | | | +--rw server-ip-address*
| | +--rw address-group* [group-id] | | | inet:ipv6-address
| | +--rw group-id string | | +--:(server)
| | +--rw start-address? inet:ipv6-address | | +--rw (address-assign)?
| | +--rw end-address? inet:ipv6-address | | +--:(number)
| +--:(dhcp-relay) | | | +--rw number-of-dynamic-address?
| | +--rw dhcp-relay-enable? boolean | | | uint16
| | +--rw customer-dhcp-servers | | +--:(explicit)
| | +--rw server-ip-address* inet:ipv6-address | | +--rw customer-addresses
| +--:(static-addresses) | | +--rw address-pool* [pool-id]
| ... | | +--rw pool-id string
... | | +--rw start-address?
| | | inet:ipv6-address
| | +--rw end-address?
| | inet:ipv6-address
| +--:(dhcp-relay)
| | +--rw customer-dhcp-servers
| | +--rw server-ip-address* inet:ipv6-address
| +--:(static-addresses)
| ...
...
Figure 12: IP Connection Subtree Structure (IPv6) Figure 12: IP Connection Subtree Structure (IPv6)
In the case of the static addressing (Figure 13), the model supports In the case of the static addressing (Figure 13), the model supports
the assignment of several IP addresses in the same 'vpn-network- the assignment of several IP addresses in the same 'vpn-network-
access'. To identify which of the addresses is the primary address access'. To identify which of the addresses is the primary address
of a connection ,the 'primary-address' reference MUST be set with the of a connection ,the 'primary-address' reference MUST be set with the
corresponding 'address-id'. corresponding 'address-id'.
... ...
+--rw ip-connection +--rw ip-connection
| +--rw ipv4 {vpn-common:ipv4}? | +--rw l3-termination-point? vpn-common:vpn-id
| | +--rw address-allocation-type? identityref | +--rw ipv4 {vpn-common:ipv4}?
| | +--rw (allocation-type)? | | +--rw address-allocation-type? identityref
| | ... | | +--rw (allocation-type)?
| | +--:(static-addresses) | | ...
| | +--rw primary-address? -> ../address/address-id | | +--:(static-addresses)
| | +--rw address* [address-id] | | +--rw primary-address? -> ../address/address-id
| | +--rw address-id string | | +--rw address* [address-id]
| | +--rw customer-address? inet:ipv4-address | | +--rw address-id string
| +--rw ipv6 {vpn-common:ipv6}? | | +--rw customer-address? inet:ipv4-address
| +--rw address-allocation-type? identityref | +--rw ipv6 {vpn-common:ipv6}?
| +--rw (allocation-type)? | +--rw address-allocation-type? identityref
| ... | +--rw (allocation-type)?
| +--:(static-addresses) | ...
| +--rw primary-address? -> ../address/prefix-id | +--:(static-addresses)
| +--rw address* [address-id] | +--rw primary-address? -> ../address/address-id
| +--rw prefix-id string | +--rw address* [address-id]
| +--rw customer-prefix? inet:ipv6-prefix | +--rw address-id string
... | +--rw customer-address? inet:ipv6-address
...
Figure 13: IP Connection Subtree Structure (Static Mode) Figure 13: IP Connection Subtree Structure (Static Mode)
7.6.3. CE-PE Routing Protocols 7.6.3. CE-PE Routing Protocols
A VPN service provider can configure one or more routing protocols A VPN service provider can configure one or more routing protocols
associated with a particular 'vpn-network-access'. Such routing associated with a particular 'vpn-network-access'. Such routing
protocol is enabled between the PE and the CE. Each instance is protocol is enabled between the PE and the CE. Each instance is
uniquely identified to accommodate scenarios where multiple instances uniquely identified to accommodate scenarios where multiple instances
of the same routing protocol have to be configured on the same link. of the same routing protocol have to be configured on the same link.
skipping to change at page 33, line 15 skipping to change at page 35, line 15
This container does not aim to include every BGP parameter; a This container does not aim to include every BGP parameter; a
comprehensive set of parameters belongs more to the BGP device comprehensive set of parameters belongs more to the BGP device
model. model.
The following data nodes are captured in Figure 16. It is up to The following data nodes are captured in Figure 16. It is up to
the implementation to derive the corresponding BGP device the implementation to derive the corresponding BGP device
configuration: configuration:
'description': Includes a description of the BGP session. 'description': Includes a description of the BGP session.
'local-autonomous-system': Is set to the AS Number (ASN) to 'local-autonomous-system': Indicates a local AS Number (ASN) if a
override a customer ASN if such feature is requested by the distinct ASN than the one configured at the VPN node level is
customer. needed.
'peer-autonomous-system': Conveys the customer's ASN. 'peer-autonomous-system': Conveys the customer's ASN.
'address-family': Indicates the address-family of the peer. It 'address-family': Indicates the address-family of the peer. It
can be set to IPv4, IPv6, or dual-stack. can be set to IPv4, IPv6, or dual-stack.
'local-address': Specifies an address or a reference to an
interface to use when establishing the BGP transport session.
'neighbor': Can indicate two neighbors (each for a given address- 'neighbor': Can indicate two neighbors (each for a given address-
family) or one neighbor (if 'address-family' attribute is set family) or one neighbor (if 'address-family' attribute is set
to dual-stack). A list of IP address(es) of the BGP neighbors to dual-stack). A list of IP address(es) of the BGP neighbors
can be then conveyed in this data node. can be then conveyed in this data node.
'multihop': Indicates the number of allowed IP hops between a PE 'multihop': Indicates the number of allowed IP hops between a PE
and its BGP peer. and its BGP peer.
'as-override': If set, this parameter indicates whether ASN 'as-override': If set, this parameter indicates whether ASN
override is enabled, i.e., replace the ASN of the customer override is enabled, i.e., replace the ASN of the customer
specified in the AS_PATH BGP attribute with the ASN identified specified in the AS_PATH BGP attribute with the ASN identified
in the 'local-autonomous-system' attribute. in the 'local-autonomous-system' attribute.
'default-route': Controls whether default route(s) can be 'allow-own-as': Is used in some topologies (e.g., hub-and-spoke)
to allow the provider's ASN to be included in the AS_PATH BGP
attribute received from a CE. Loops are prevented by setting
'allow-own-as' to a maximum number of provider's ASN
occurrences. This parameter is set by default to '0' (that is,
reject any AS_PATH attribute that includes the provider's ASN).
'prepend-global-as': When distinct ASNs are configured in the VPN
node and network access levels, this parameter controls whether
the ASN provided at the VPN node level is prepended to the
AS_PATH attribute.
'default-route': Controls whether default routes can be
advertised to the peer. advertised to the peer.
'site-of-origin': Is meant to uniquely identify the set of routes 'site-of-origin': Is meant to uniquely identify the set of routes
learned from a site via a particular CE/PE connection and is learned from a site via a particular CE/PE connection and is
used to prevent routing loops (Section 7 of [RFC4364]). The used to prevent routing loops (Section 7 of [RFC4364]). The
Site of Origin attribute is encoded as a Route Origin Extended Site of Origin attribute is encoded as a Route Origin Extended
Community. Community.
'ipv6-site-of-origin': Carries an IPv6 Address Specific BGP 'ipv6-site-of-origin': Carries an IPv6 Address Specific BGP
Extended that is used to indicate the Site of Origin for VRF Extended that is used to indicate the Site of Origin for VRF
information [RFC5701]. It is used to prevent routing loops. information [RFC5701]. It is used to prevent routing loops.
'redistribute-connected': Controls whether the PE-CE link is
advertised to other PEs.
'bgp-max-prefix': Controls the behavior when a prefix maximum is 'bgp-max-prefix': Controls the behavior when a prefix maximum is
reached. reached.
'max-prefix': Indicates the maximum number of BGP prefixes 'max-prefix': Indicates the maximum number of BGP prefixes
allowed in the BGP session. If such limit is reached, the allowed in the BGP session. If such limit is reached, the
action indicated in 'action-violate' will be followed. action indicated in 'action-violate' will be followed.
'warning-threshold':a warning 'warning-threshold': A warning notification is triggered when
notification will be triggered' this limit is reached.
A warning notification is triggered when this limit is reached.
'violate-action': Indicates which action to execute when the maximum 'violate-action': Indicates which action to execute when the
number of BGP prefixes is reached. Examples of such actions are: maximum number of BGP prefixes is reached. Examples of such
send a warning message, discard extra paths from the peer, or actions are: send a warning message, discard extra paths
restart the session. from the peer, or restart the session.
'bgp-timers': Two timers can be captured in this container: (1) 'bgp-timers': Two timers can be captured in this container: (1)
'hold-time' which is the time interval that will be used for 'hold-time' which is the time interval that will be used for
the HoldTimer (Section 4.2 of [RFC4271]) when establishing a the HoldTimer (Section 4.2 of [RFC4271]) when establishing a
BGP session. (2) 'keep-alive' which is the time interval for 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 the KeepAlive timer between a PE and a BGP peer (Section 4.4 of
[RFC4271]). [RFC4271]).
'security': The module adheres to the recommendations in 'security': The module adheres to the recommendations in
Section 13.2 of [RFC4364] as it allows to enable TCP-AO Section 13.2 of [RFC4364] as it allows to enable TCP-AO
[RFC5925] and accommodates the installed base that make use of [RFC5925] and accommodates the installed base that makes use of
MD5. In addition, the module includes a provision for the use MD5. In addition, the module includes a provision for the use
of IPsec. of IPsec.
'status': Indicates the status of the BGP routing instance. 'status': Indicates the status of the BGP routing instance.
... ...
+--rw routing-protocols +--rw routing-protocols
| +--rw routing-protocol* [id] | +--rw routing-protocol* [id]
| ... | ...
| +--rw bgp {vpn-common:rtg-bgp}? | +--rw bgp {vpn-common:rtg-bgp}?
| | +--rw description? string | | +--rw description? string
| | +--rw local-autonomous-system? inet:as-number | | +--rw local-autonomous-system? inet:as-number
| | +--rw peer-autonomous-system inet:as-number | | +--rw peer-autonomous-system inet:as-number
| | +--rw address-family? identityref | | +--rw address-family? identityref
| | +--rw local-address? union
| | +--rw neighbor* inet:ip-address | | +--rw neighbor* inet:ip-address
| | +--rw multihop? uint8 | | +--rw multihop? uint8
| | +--rw as-override? boolean | | +--rw as-override? boolean
| | +--rw allow-own-as? uint8
| | +--rw prepend-global-as? boolean
| | +--rw default-route? boolean | | +--rw default-route? boolean
| | +--rw site-of-origin? rt-types:route-origin | | +--rw site-of-origin? rt-types:route-origin
| | +--rw ipv6-site-of-origin? rt-types:ipv6-route-origin | | +--rw ipv6-site-of-origin? rt-types:ipv6-route-origin
| | +--rw redistribute-connected* [address-family]
| | | +--rw address-family identityref
| | | +--rw enable? boolean
| | +--rw bgp-max-prefix | | +--rw bgp-max-prefix
| | | +--rw max-prefix? uint32 | | | +--rw max-prefix? uint32
| | | +--rw warning-threshold? decimal64 | | | +--rw warning-threshold? decimal64
| | | +--rw violate-action? enumeration | | | +--rw violate-action? enumeration
| | | +--rw restart-interval? uint16 | | | +--rw restart-interval? uint16
| | +--rw bgp-timers | | +--rw bgp-timers
| | | +--rw keep-alive? uint16 | | | +--rw keep-alive? uint16
| | | +--rw hold-time? uint16 | | | +--rw hold-time? uint16
| | +--rw security | | +--rw security
| | | +--rw enable? boolean | | | +--rw enable? boolean
skipping to change at page 36, line 6 skipping to change at page 38, line 10
| | | +--rw status? identityref | | | +--rw status? identityref
| | | +--rw last-updated? yang:date-and-time | | | +--rw last-updated? yang:date-and-time
| | +--ro oper-status | | +--ro oper-status
| | +--ro status? identityref | | +--ro status? identityref
| | +--ro last-updated? yang:date-and-time | | +--ro last-updated? yang:date-and-time
... ...
Figure 16: BGP Routing Subtree Structure Figure 16: BGP Routing Subtree Structure
OSPF: OSPF can be configured to run as a routing protocol on the OSPF: OSPF can be configured to run as a routing protocol on the
'vpn-network-access' [RFC4577][RFC6565]. The following data nodes 'vpn-network-access'. The following data nodes are captured in
are captured in Figure 17: Figure 17:
'address-family': Indicates whether IPv4, IPv6, or both address 'address-family': Indicates whether IPv4, IPv6, or both address
families are to be activated. families are to be activated.
When only the IPv4 address-family is requested, it will be up When only the IPv4 address-family is requested, it will be up
to the implementation to decide whether OSPFv2 [RFC2328] or to the implementation to decide whether OSPFv2 [RFC4577] or
OSPFv3 [RFC5340] is used. OSPFv3 [RFC6565] is used.
'area-id': Indicates the OSPF Area ID. 'area-id': Indicates the OSPF Area ID.
'metric': Associates a metric with OSPF routes. 'metric': Associates a metric with OSPF routes.
'sham-links': Is used to create OSPF sham links between two VPN 'sham-links': Is used to create OSPF sham links between two VPN
network accesses sharing the same area and having a backdoor network accesses sharing the same area and having a backdoor
link (Section 4.2.7 of [RFC4577]). link (Section 4.2.7 of [RFC4577] and Section 5 of [RFC6565]).
'max-lsa': Sets the maximum number of LSAs that the OSPF instance 'max-lsa': Sets the maximum number of LSAs that the OSPF instance
will accept. will accept.
'security': Controls the authentication schemes to be enabled for 'security': Controls the authentication schemes to be enabled for
the OSPF instance. The following options are supported: IPsec the OSPF instance. The following options are supported: IPsec
for OSPFv3 authentication [RFC4552], authentication trailer for for OSPFv3 authentication [RFC4552], authentication trailer for
OSPFv2 [RFC5709] [RFC7474] and OSPFv3 [RFC7166]. OSPFv2 [RFC5709] [RFC7474] and OSPFv3 [RFC7166].
'status': Indicates the status of the OSPF routing instance. 'status': Indicates the status of the OSPF routing instance.
skipping to change at page 38, line 21 skipping to change at page 40, line 21
the IS-IS instance. the IS-IS instance.
'status': Indicates the status of the OSPF routing instance. 'status': Indicates the status of the OSPF routing instance.
... ...
+--rw routing-protocols +--rw routing-protocols
| +--rw routing-protocol* [id] | +--rw routing-protocol* [id]
| ... | ...
| +--rw isis {vpn-common:rtg-isis}? | +--rw isis {vpn-common:rtg-isis}?
| | +--rw address-family? identityref | | +--rw address-family? identityref
| | +--rw area-address yang:dotted-quad | | +--rw area-address area-address
| | +--rw level? identityref | | +--rw level? identityref
| | +--rw metric? uint16 | | +--rw metric? uint16
| | +--rw mode? enumeration | | +--rw mode? enumeration
| | +--rw security | | +--rw security
| | | +--rw enable? boolean | | | +--rw enable? boolean
| | | +--rw keying-material | | | +--rw keying-material
| | | +--rw (option)? | | | +--rw (option)?
| | | +--:(auth-key-chain) | | | +--:(auth-key-chain)
| | | | +--rw key-chain? key-chain:key-chain-ref | | | | +--rw key-chain? key-chain:key-chain-ref
| | | +--:(auth-key-explicit) | | | +--:(auth-key-explicit)
skipping to change at page 38, line 46 skipping to change at page 40, line 46
| | +--rw admin-status | | +--rw admin-status
| | | +--rw status? identityref | | | +--rw status? identityref
| | | +--rw last-updated? yang:date-and-time | | | +--rw last-updated? yang:date-and-time
| | +--ro oper-status | | +--ro oper-status
| | +--ro status? identityref | | +--ro status? identityref
| | +--ro last-updated? yang:date-and-time | | +--ro last-updated? yang:date-and-time
... ...
Figure 18: IS-IS Routing Subtree Structure Figure 18: IS-IS Routing Subtree Structure
RIP: The module covers only a list of address-family and status as RIP: The model allows the user to configure RIP to run on the 'vpn-
shown in Figure 19. The meaning of these data nodes is similar to network-access' interface. As shown in Figure 19, the following
the other routing protocols. RIP data nodes are supported:
... 'address-family': Indicates whether IPv4, IPv6, or both address
+--rw routing-protocols families are to be activated. This parameter is used to
| +--rw routing-protocol* [id] determine whether RIPv2 [RFC2453] and/or RIPng are to be
| ... enabled [RFC2080].
| +--rw rip {vpn-common:rtg-rip}?
| | +--rw address-family* identityref 'timers': Indicates the following timers:
| | +--rw status
| | +--rw admin-status 'update-interval': Is the interval at which RIP updates are
| | | +--rw status? identityref sent.
| | | +--rw last-updated? yang:date-and-time
| | +--ro oper-status 'invalid-interval': Is the interval before a RIP route is
| | +--ro status? identityref declared invalid.
| | +--ro last-updated? yang:date-and-time
... 'holddown-interval': Is the interval before better RIP routes
are released.
'flush-interval': Is the interval before a route is removed
from the routing table.
'default-metric': Sets the default RIP metric.
'security': Controls the authentication schemes to be enabled for
the RIP instance.
'status': Indicates the status of the RIP routing instance.
...
+--rw routing-protocols
| +--rw routing-protocol* [id]
| ...
| +--rw rip {vpn-common:rtg-rip}?
| | +--rw address-family? identityref
| | +--rw timers
| | | +--rw update-interval? uint16
| | | +--rw invalid-interval? uint16
| | | +--rw holddown-interval? uint16
| | | +--rw flush-interval? uint16
| | +--rw neighbor* inet:ip-address
| | +--rw default-metric? uint8
| | +--rw security
| | | +--rw enable? boolean
| | | +--rw keying-material
| | | +--rw (option)?
| | | +--:(auth-key-chain)
| | | | +--rw key-chain? key-chain:key-chain-ref
| | | +--:(auth-key-explicit)
| | | +--rw key? string
| | | +--rw crypto-algorithm? identityref
| | +--rw status
| | +--rw admin-status
| | | +--rw status? identityref
| | | +--rw last-updated? yang:date-and-time
| | +--ro oper-status
| | +--ro status? identityref
| | +--ro last-updated? yang:date-and-time
...
Figure 19: RIP Subtree Structure Figure 19: RIP Subtree Structure
VRRP: The model (Figure 20) allows to enable VRRP on the 'vpn- VRRP: The model (Figure 20) allows to enable VRRP on the 'vpn-
network-access' interface. The following data nodes are network-access' interface. The following data nodes are
supported: supported:
'address-family': Indicates whether IPv4, IPv6, or both address 'address-family': Indicates whether IPv4, IPv6, or both address
families are to be activated. Note that VRRP version 3 families are to be activated. Note that VRRP version 3
[RFC5798] supports both IPv4 and IPv6. [RFC5798] supports both IPv4 and IPv6.
skipping to change at page 42, line 33 skipping to change at page 45, line 33
| +--:(customer-profile) | +--:(customer-profile)
| +--rw customer-key-chain? | +--rw customer-key-chain?
| kc:key-chain-ref | kc:key-chain-ref
+--rw service +--rw service
... ...
Figure 22: Security Subtree Structure Figure 22: Security Subtree Structure
7.6.6. Services 7.6.6. Services
The 'services' container specifies the service parameters to apply The 'service' container specifies the service parameters to apply for
for a given VPN network access (Figure 23). a given VPN network access (Figure 23).
... ...
+--rw vpn-network-accesses +--rw vpn-network-accesses
+--rw vpn-network-access* [id] +--rw vpn-network-access* [id]
... ...
+--rw service +--rw service
+--rw input-bandwidth uint64 +--rw input-bandwidth uint64
+--rw output-bandwidth uint64 +--rw output-bandwidth uint64
+--rw mtu uint16 +--rw mtu uint16
+--rw qos {vpn-common:qos}? +--rw qos {vpn-common:qos}?
| ... | ...
+--rw carrierscarrier +--rw carrierscarrier
| {vpn-common:carrierscarrier}? | {vpn-common:carrierscarrier}?
| +--rw signalling-type? enumeration | +--rw signalling-type? enumeration
+--rw multicast {vpn-common:multicast}? +--rw ntp
... | +--rw broadcast? enumeration
| +--rw auth-profile
| | +--rw profile-id? 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 multicast {vpn-common:multicast}?
...
Figure 23: Services Subtree Structure Figure 23: Services Subtree Structure
The following data nodes are defined: The following data nodes are defined:
'input-bandwidth': Indicates the inbound bandwidth of the connection 'input-bandwidth': Indicates the inbound bandwidth of the connection
(i.e., download bandwidth from the SP to the site). (i.e., download bandwidth from the service provider to the site).
'output-bandwidth': Indicates the outbound bandwidth of the 'output-bandwidth': Indicates the outbound bandwidth of the
connection (i.e., upload bandwidth from the site to the SP). connection (i.e., upload bandwidth from the site to the service
provider).
'mtu': Indicates the MTU at service level. It can be the IP MTU or 'mtu': Indicates the MTU at service level. It can be the IP MTU or
MPLS MTU, for example. MPLS MTU, for example.
'qos': Is used to define a set of QoS policies to apply on a given 'qos': Is used to define a set of QoS policies to apply on a given
connection (Figure 24). A QoS policy may be a classification or connection (Figure 24). A QoS policy may be a classification or
an action policy. For example, a QoS action can be defined to an action policy. For example, a QoS action can be defined to
rate limit inbound/outbound traffic of a given class of service. rate limit inbound/outbound traffic of a given class of service.
... ...
skipping to change at page 44, line 43 skipping to change at page 47, line 43
| +--rw qos-profile | +--rw qos-profile
| +--rw qos-profile* [profile] | +--rw qos-profile* [profile]
| +--rw profile leafref | +--rw profile leafref
| +--rw direction? identityref | +--rw direction? identityref
... ...
Figure 24: Services Subtree Structure Figure 24: Services Subtree Structure
QoS classification can be based on many criteria such as: QoS classification can be based on many criteria such as:
Layer 3: As shown in Figure 26, classification can be based on Layer 3: As shown in Figure 25, classification can be based on
any IP header field or a combination thereof. Both IPv4 and any IP header field or a combination thereof. Both IPv4 and
IPv6 are supported. IPv6 are supported.
+--rw qos {vpn-common:qos}? +--rw qos {vpn-common:qos}?
| +--rw qos-classification-policy | +--rw qos-classification-policy
| | +--rw rule* [id] | | +--rw rule* [id]
| | +--rw id string | | +--rw id string
| | +--rw (match-type)? | | +--rw (match-type)?
| | | +--:(match-flow) | | | +--:(match-flow)
| | | | +--rw (l3)? | | | | +--rw (l3)?
skipping to change at page 46, line 5 skipping to change at page 49, line 5
| | | | | +--rw (source-network)? | | | | | +--rw (source-network)?
| | | | | | +--:(source-ipv6-network) | | | | | | +--:(source-ipv6-network)
| | | | | | +--rw source-ipv6-network? | | | | | | +--rw source-ipv6-network?
| | | | | | inet:ipv6-prefix | | | | | | inet:ipv6-prefix
| | | | | +--rw flow-label? | | | | | +--rw flow-label?
| | | | | inet:ipv6-flow-label | | | | | inet:ipv6-flow-label
... ...
Figure 25: QoS Subtree Structure (L3) Figure 25: QoS Subtree Structure (L3)
Layer 4: As shown in Figure 26, TCP or UDP-related match crietria Layer 4: As discussed in [I-D.ietf-opsawg-vpn-common], any layer
can be specified in the L3NM. 4 protocol can be indicated in the 'protocol' data node under
'l3' (Figure 25), but only TCP and UDP specific match criteria
are elaborated in this version as these protocols are widely
used in the context of VPN services. Augmentations can be
considered in the future to add other Layer 4 specific data
nodes, if needed.
TCP or UDP-related match crietria can be specified in the L3NM
as shown in Figure 26.
+--rw qos {vpn-common:qos}? +--rw qos {vpn-common:qos}?
| +--rw qos-classification-policy | +--rw qos-classification-policy
| | +--rw rule* [id] | | +--rw rule* [id]
| | +--rw id string | | +--rw id string
| | +--rw (match-type)? | | +--rw (match-type)?
| | | +--:(match-flow) | | | +--:(match-flow)
| | | | +--rw (l3)? | | | | +--rw (l3)?
| | | | | ... | | | | | ...
| | | | +--rw (l4)? | | | | +--rw (l4)?
skipping to change at page 47, line 43 skipping to change at page 51, line 5
... ...
Figure 26: QoS Subtree Structure (L4) Figure 26: QoS Subtree Structure (L4)
Application match: Relies upon application-specific Application match: Relies upon application-specific
classification. classification.
'carrierscarrier': Groups a set of parameters that are used when CsC 'carrierscarrier': Groups a set of parameters that are used when CsC
is enabled such the use of BGP for signalling purposes [RFC8277]. is enabled such the use of BGP for signalling purposes [RFC8277].
'ntp': Time synchronization may be needed in some VPNs such as
infrastructure and management VPNs. This container is used to
enable the NTP service [RFC5905].
'multicast': Specifies the multicast mode and other data nodes such 'multicast': Specifies the multicast mode and other data nodes such
as the address-family. Refer to Section 7.7. as the address-family. Refer to Section 7.7.
7.7. Multicast 7.7. Multicast
Multicast may be enabled for a particular VPN at the VPN node and VPN Multicast may be enabled for a particular VPN at the VPN node and VPN
network access levels (see Figure 27). Some data nodes (e.g., max- network access levels (see Figure 27). Some data nodes (e.g., max-
groups) can be controlled at the VPN node level or at the VPN network groups) can be controlled at various levels: VPN service, VPN node
access. level, or VPN network access.
...
+--rw vpn-services
+--rw vpn-service* [vpn-id]
... ...
+--rw vpn-instance-profiles
| +--rw vpn-instance-profile* [profile-id]
| ....
| +--rw multicast {vpn-common:multicast}?
| ...
+--rw vpn-nodes +--rw vpn-nodes
+--rw vpn-node* [vpn-node-id] +--rw vpn-node* [vpn-node-id]
... ...
+--rw multicast {vpn-common:multicast}? +--rw active-vpn-instance-profiles
| ... | +--rw vpn-instance-profile* [profile-id]
| ...
| +--rw multicast {vpn-common:multicast}?
| ...
+--rw vpn-network-accesses +--rw vpn-network-accesses
+--rw vpn-network-access* [id] +--rw vpn-network-access* [id]
... ...
+--rw service +--rw service
... ...
+--rw multicast {vpn-common:multicast}? +--rw multicast {vpn-common:multicast}?
... ...
Figure 27: Overall Multicast Subtree Structure Figure 27: Overall Multicast Subtree Structure
Multicast-related data nodes at the VPN node level are shown in Multicast-related data nodes at the VPN instance profile level has
Figure 29. Disabling multicast at the VPN node level will have an the structure that is shown in Figure 30.
effect to disable it also at the VPN network access level. For IGMP,
MLD, and PIM, Global data nodes that are defined at the VPN node
level are applicable to all VPN network accesses whose corresponding
nodes are not provided at the VPN network access level.
...
+--rw vpn-nodes
+--rw vpn-node* [vpn-node-id]
...
+--rw multicast {vpn-common:multicast}?
| +--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 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 peer? inet:ip-address
| | +--rw local-address? inet:ip-address
| | +--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 igmp {vpn-common:igmp and vpn-common:ipv4}?
| | +--rw static-group* [group-addr]
| | | +--rw group-addr
| | | rt-types:ipv4-multicast-group-address
| | | +--rw source-addr?
| | | rt-types:ipv4-multicast-source-address
| | +--rw max-groups? uint32
| | +--rw max-entries? uint32
| | +--rw version? identityref
| | +--rw 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 mld {vpn-common:mld and vpn-common:ipv6}?
| | +--rw static-group* [group-addr]
| | | +--rw group-addr
| | | rt-types:ipv6-multicast-group-address
| | | +--rw source-addr?
| | | rt-types:ipv6-multicast-source-address
| | +--rw max-groups? uint32
| | +--rw max-entries? uint32
| | +--rw version? identityref
| | +--rw 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 pim {vpn-common:pim}?
| +--rw hello-interval? uint8
| +--rw dr-priority? uint16
| +--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
...
Figure 28: Multicast Subtree Structure (VPN Node Level)
Multicast-related data nodes at the VPN network access level are
shown in Figure 29. Except the 'status' node, the value configured
at the VPN network access level overrides the value configured for
the corresponding data node at the VPN node level.
...
+--rw vpn-services
+--rw vpn-service* [vpn-id]
... ...
+--rw vpn-network-accesses
+--rw vpn-network-access* [id]
...
+--rw service
...
+--rw multicast {vpn-common:multicast}?
+--rw access-type? enumeration
+--rw address-family? identityref
+--rw protocol-type? enumeration
+--rw remote-source? boolean
+--rw igmp {vpn-common:igmp}?
| +--rw static-group* [group-addr]
| | +--rw group-addr
| | rt-types:ipv4-multicast-group-address
| | +--rw source-addr?
| | rt-types:ipv4-multicast-source-address
| +--rw max-groups? uint32
| +--rw max-entries? uint32
| +--rw max-group-sources? uint32
| +--rw version? identityref
| +--rw status
| +--rw admin-status
| | +--rw status? identityref
| | +--rw last-updated? yang:date-and-time
| +--ro oper-status
| +--ro status? identityref
| +--ro last-updated? yang:date-and-time
+--rw mld {vpn-common:mld}?
| +--rw static-group* [group-addr]
| | +--rw group-addr
| | rt-types:ipv6-multicast-group-address
| | +--rw source-addr?
| | rt-types:ipv6-multicast-source-address
| +--rw max-groups? uint32
| +--rw max-entries? uint32
| +--rw max-group-sources? uint32
| +--rw version? identityref
| +--rw status
| +--rw admin-status
| | +--rw status? identityref
| | +--rw last-updated? yang:date-and-time
| +--ro oper-status
| +--ro status? identityref
| +--ro last-updated? yang:date-and-time
+--rw pim {vpn-common:pim}?
+--rw priority? uint8
+--rw hello-interval? uint8
+--rw dr-priority? uint16
+--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
Figure 29: Multicast Subtree Structure (VPN Network Access Level) +--rw vpn-instance-profiles
| +--rw vpn-instance-profile* [profile-id]
| ....
| +--rw multicast {vpn-common:multicast}?
| +--rw tree-flavor* identityref
| +--rw rp
| | +--rw rp-group-mappings
| | | +--rw rp-group-mapping* [id]
| | | +--rw id uint16
| | | +--rw provider-managed
| | | | +--rw enabled? boolean
| | | | +--rw rp-redundancy? boolean
| | | | +--rw optimal-traffic-delivery? boolean
| | | | +--rw anycast
| | | | +--rw local-address? inet:ip-address
| | | | +--rw rp-set-address* inet:ip-address
| | | +--rw rp-address inet:ip-address
| | | +--rw groups
| | | +--rw group* [id]
| | | +--rw id uint16
| | | +--rw (group-format)
| | | +--:(group-prefix)
| | | | +--rw group-address? inet:ip-prefix
| | | +--:(startend)
| | | +--rw group-start? inet:ip-address
| | | +--rw group-end? inet:ip-address
| | +--rw rp-discovery
| | +--rw rp-discovery-type? identityref
| | +--rw bsr-candidates
| | +--rw bsr-candidate-address* inet:ip-address
| +--rw igmp {vpn-common:igmp and vpn-common:ipv4}?
| | +--rw static-group* [group-addr]
| | | +--rw group-addr
| | | | rt-types:ipv4-multicast-group-address
| | | +--rw source-addr?
| | | rt-types:ipv4-multicast-source-address
| | +--rw max-groups? uint32
| | +--rw max-entries? uint32
| | +--rw version? identityref
| +--rw mld {vpn-common:mld and vpn-common:ipv6}?
| | +--rw static-group* [group-addr]
| | | +--rw group-addr
| | | | rt-types:ipv6-multicast-group-address
| | | +--rw source-addr?
| | | rt-types:ipv6-multicast-source-address
| | +--rw max-groups? uint32
| | +--rw max-entries? uint32
| | +--rw version? identityref
| +--rw pim {vpn-common:pim}?
| +--rw hello-interval? rt-types:timer-value-seconds16
| +--rw dr-priority? uint32
...
Figure 28: Multicast Subtree Structure (VPN Instance Profile Level)
The model supports a single type of tree: Any-Source Multicast (ASM), The model supports a single type of tree: Any-Source Multicast (ASM),
Source-Specific Multicast (SSM), or bidirectional. Source-Specific Multicast (SSM), or bidirectional.
When ASM is used, the model supports the configuration of rendez-vous When ASM is used, the model supports the configuration of rendez-vous
points (RPs). RP discovery may be 'static', 'bsr-rp', or 'auto-rp'. points (RPs). RP discovery may be 'static', 'bsr-rp', or 'auto-rp'.
When set to 'static', RP to multicast grouping mapping MUST be When set to 'static', RP to multicast grouping mapping MUST be
configured as part of the 'rp-group-mappings' container. The RP MAY 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 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 node, the RP address must be configured using the 'rp-address' leaf
skipping to change at page 52, line 16 skipping to change at page 53, line 33
How the redundancy is achieved is out of scope and is up to the How the redundancy is achieved is out of scope and is up to the
implementation. implementation.
When a particular VPN using ASM requires a more optimal traffic When a particular VPN using ASM requires a more optimal traffic
delivery, 'optimal-traffic-delivery' can be set. When set to 'true', delivery, 'optimal-traffic-delivery' can be set. When set to 'true',
the implementation must use any mechanism to provide a more optimal the implementation must use any mechanism to provide a more optimal
traffic delivery for the customer. For example, anycast is one of traffic delivery for the customer. For example, anycast is one of
the mechanisms to enhance RPs redundancy, resilience against the mechanisms to enhance RPs redundancy, resilience against
failures, and to recover from failures quickly. failures, and to recover from failures quickly.
For redundancy purposes, Multicast Source Discovery Protocol (MSDP) The same structure as the one depicted in Figure 30 is used when
[RFC3618] may be enabled and used to share the state about sources configuring multicast-related parameters at the VPN node level. When
between multiple RPs. The purpose of MSDP in this context is to defined at the VPN node level (Figure 29), Internet Group Management
enhance the robustness of the multicast service. MSDP may be Protocol (IGMP) [RFC1112][RFC2236][RFC3376], Multicast Listener
configured on non-RP routers, which is useful in a domain that does Discovery (MLD) [RFC2710][RFC3810], and Protocol Independent
not support multicast sources, but does support multicast transit. Multicast (PIM) [RFC7761] parameters are applicable to all VPN
network accesses of that VPN node unless corresponding nodes are
refined at the VPN network access level.
...
+--rw vpn-nodes
+--rw vpn-node* [vpn-node-id]
...
+--rw active-vpn-instance-profiles
| +--rw vpn-instance-profile* [profile-id]
| ...
| +--rw multicast {vpn-common:multicast}?
| +--rw tree-flavor* identityref
| +--rw rp
| | ...
| +--rw igmp {vpn-common:igmp and vpn-common:ipv4}?
| | ...
| +--rw mld {vpn-common:mld and vpn-common:ipv6}?
| | ...
| +--rw pim {vpn-common:pim}?
| ...
Figure 29: Multicast Subtree Structure (VPN Node Level)
Multicast-related data nodes at the VPN network access level are
shown in Figure 30. The values configured at the VPN network access
level override the values configured for the corresponding data nodes
in other levels.
...
+--rw vpn-network-accesses
+--rw vpn-network-access* [id]
...
+--rw service
...
+--rw multicast {vpn-common:multicast}?
+--rw access-type? enumeration
+--rw address-family? identityref
+--rw protocol-type? enumeration
+--rw remote-source? boolean
+--rw igmp {vpn-common:igmp}?
| +--rw static-group* [group-addr]
| | +--rw group-addr
| | rt-types:ipv4-multicast-group-address
| | +--rw source-addr?
| | rt-types:ipv4-multicast-source-address
| +--rw max-groups? uint32
| +--rw max-entries? uint32
| +--rw max-group-sources? uint32
| +--rw version? identityref
| +--rw status
| +--rw admin-status
| | +--rw status? identityref
| | +--rw last-updated? yang:date-and-time
| +--ro oper-status
| +--ro status? identityref
| +--ro last-updated? yang:date-and-time
+--rw mld {vpn-common:mld}?
| +--rw static-group* [group-addr]
| | +--rw group-addr
| | rt-types:ipv6-multicast-group-address
| | +--rw source-addr?
| | rt-types:ipv6-multicast-source-address
| +--rw max-groups? uint32
| +--rw max-entries? uint32
| +--rw max-group-sources? uint32
| +--rw version? identityref
| +--rw status
| +--rw admin-status
| | +--rw status? identityref
| | +--rw last-updated? yang:date-and-time
| +--ro oper-status
| +--ro status? identityref
| +--ro last-updated? yang:date-and-time
+--rw pim {vpn-common:pim}?
+--rw hello-interval? rt-types:timer-value-seconds16
+--rw dr-priority? uint32
+--rw status
+--rw admin-status
| +--rw status? identityref
| +--rw last-updated? yang:date-and-time
+--ro oper-status
+--ro status? identityref
+--ro last-updated? yang:date-and-time
Figure 30: Multicast Subtree Structure (VPN Network Access Level)
8. L3NM YANG Module 8. L3NM YANG Module
This module uses types defined in [RFC6991] and groupings defined in This module uses types defined in [RFC6991] and [RFC8343]. It also
[RFC8519], [RFC8177], and [RFC8294]. uses groupings defined in [RFC8519], [RFC8177], and [RFC8294].
<CODE BEGINS> file "ietf-l3vpn-ntw@2021-02-19.yang" <CODE BEGINS> file "ietf-l3vpn-ntw@2021-04-21.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 l3nm; prefix l3nm;
import ietf-vpn-common { import ietf-vpn-common {
prefix vpn-common; prefix vpn-common;
reference reference
"RFC UUUU: A Layer 2/3 VPN Common YANG Model"; "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"; "RFC 6991: Common YANG Data Types, Section 4";
} }
import ietf-yang-types { import ietf-yang-types {
prefix yang; prefix yang;
reference reference
"Section 3 of RFC 6991"; "RFC 6991: Common YANG Data Types, Section 3";
} }
import ietf-key-chain { import ietf-key-chain {
prefix key-chain; prefix key-chain;
reference reference
"RFC 8177: YANG Key Chain."; "RFC 8177: YANG Key Chain.";
} }
import ietf-routing-types { import ietf-routing-types {
prefix rt-types; prefix rt-types;
reference reference
"RFC 8294: Common YANG Data Types for the Routing Area"; "RFC 8294: Common YANG Data Types for the Routing Area";
} }
import ietf-interfaces {
prefix if;
reference
"RFC 8343: A YANG Data Model for Interface Management";
}
organization 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>
Editor: Samier Barguil Author: 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>
Editor: 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) 2021 IETF Trust and the persons identified as Copyright (c) 2021 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
the license terms contained in, the Simplified BSD License set to the license terms contained in, the Simplified BSD License
forth in Section 4 of the IETF Trust's Legal Provisions set 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). (http://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; see
(https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself the RFC itself for full legal notices.";
for full legal notices.";
revision 2021-02-19 { revision 2021-04-21 {
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";
} }
/* Features */ /* Features */
feature msdp { feature msdp {
description description
"This feature indicates that Multicast Source Discovery Protocol "This feature indicates that Multicast Source Discovery Protocol
(MSDP) capabilities are supported by the VPN."; (MSDP) capabilities are supported by the VPN.";
reference reference
"RFC 3618: Multicast Source Discovery Protocol (MSDP)"; "RFC 3618: Multicast Source Discovery Protocol (MSDP)";
} }
skipping to change at page 54, line 36 skipping to change at page 58, line 10
} }
identity provider-dhcp-relay { identity provider-dhcp-relay {
base address-allocation-type; base address-allocation-type;
description description
"The Provider's network provides a DHCP relay service to the "The Provider's network provides a DHCP relay service to the
customer."; customer.";
} }
identity provider-dhcp-slaac { identity provider-dhcp-slaac {
if-feature "vpn-common:ipv6";
base address-allocation-type; base address-allocation-type;
description description
"The Provider's network provides a DHCP service to the customer "The Provider's network provides a DHCP service to the customer
as well as IPv6 Stateless Address Autoconfiguration (SLAAC)."; as well as IPv6 Stateless Address Autoconfiguration (SLAAC).";
reference reference
"RFC 7527: IPv6 Stateless Address Autoconfiguration"; "RFC 4862: IPv6 Stateless Address Autoconfiguration";
} }
identity static-address { identity static-address {
base address-allocation-type; base address-allocation-type;
description description
"The Provider-to-customer addressing is static."; "The Provider-to-customer addressing is static.";
} }
identity slaac { identity slaac {
if-feature "vpn-common:ipv6"; if-feature "vpn-common:ipv6";
base address-allocation-type; base address-allocation-type;
description description
"Use IPv6 SLAAC."; "Use IPv6 SLAAC.";
reference reference
"RFC 7527: IPv6 Stateless Address Autoconfiguration"; "RFC 4862: IPv6 Stateless Address Autoconfiguration";
} }
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
skipping to change at page 55, line 49 skipping to change at page 59, line 24
For example, this can be used to blackhole traffic."; For example, this can be used to blackhole traffic.";
} }
identity local-link { identity local-link {
base local-defined-next-hop; base local-defined-next-hop;
description description
"Treat traffic towards addresses within the specified next-hop "Treat traffic towards addresses within the specified next-hop
prefix as though they are connected to a local link."; prefix as though they are connected to a local link.";
} }
identity l2-tunnel-type {
description
"Base identity for layer-2 tunnel selection under the VPN
network access.";
}
identity pseudowire {
base l2-tunnel-type;
description
"Pseudowire tunnel termination in the VPN network access.";
}
identity vpls {
base l2-tunnel-type;
description
"Virtual Private LAN Service (VPLS) tunnel termination in
the VPN network access.";
}
identity vxlan {
base l2-tunnel-type;
description
"Virtual eXtensible Local Area Network (VXLAN) tunnel
termination in the VPN network access.";
}
/* Typedefs */
typedef predefined-next-hop { typedef predefined-next-hop {
type identityref { type identityref {
base local-defined-next-hop; base local-defined-next-hop;
} }
description description
"Pre-defined next-hop designation for locally generated routes."; "Pre-defined next-hop designation for locally generated routes.";
} }
/* Typedefs */
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.";
} }
/* Groupings */
grouping vpn-instance-profile {
description
"Grouping for data nodes that may be factorized
among many levels of the model. The grouping can
be used to define generic profiles at the VPN service
level and then called at the VPN node and VPN network
access levels.";
leaf local-autonomous-system {
if-feature "vpn-common:rtg-bgp";
type inet:as-number;
description
"Provider's AS number in case the customer requests BGP
routing.";
}
uses vpn-common:route-distinguisher;
list address-family {
key "address-family";
description
"Set of per-address family paramters.";
leaf address-family {
type identityref {
base vpn-common:address-family;
}
description
"Indicates the address family (IPv4 or IPv6).";
}
container vpn-targets {
description
"Set of route targets to match for import and export routes
to/from VRF.";
uses vpn-common:vpn-route-targets;
}
list maximum-routes {
key "protocol";
description
"Defines maximum routes for the VRF.";
leaf protocol {
type identityref {
base vpn-common:routing-protocol-type;
}
description
"Indicates the routing protocol. 'any' value can
be used to identify a limit that will apply for
each active routing protocol.";
}
leaf maximum-routes {
type uint32;
description
"Indicates the maximum prefixes the VRF can accept
for this address family and protocol.";
}
}
}
container multicast {
if-feature "vpn-common:multicast";
description
"Global multicast parameters.";
leaf-list tree-flavor {
type identityref {
base vpn-common:multicast-tree-type;
}
description
"Type of tree to be used.";
}
container rp {
description
"RP parameters.";
container rp-group-mappings {
description
"RP-to-group mappings parameters.";
list rp-group-mapping {
key "id";
description
"List of RP-to-group mappings.";
leaf id {
type uint16;
description
"Unique identifier for the mapping.";
}
container provider-managed {
description
"Parameters for a provider-managed RP.";
leaf enabled {
type boolean;
default "false";
description
"Set to true if the Rendezvous Point (RP)
must be a provider-managed node. Set to
false if it is a customer-managed node.";
}
leaf rp-redundancy {
type boolean;
default "false";
description
"If 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.";
}
description
"PIM Anycast-RP parameters.";
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.";
}
}
}
leaf rp-address {
when "../provider-managed/enabled = 'false'" {
description
"Relevant when the RP is not
provider-managed.";
}
type inet:ip-address;
mandatory true;
description
"Defines the address of the RP.
Used if the RP is customer-managed.";
}
container groups {
description
"Multicast groups associated with the RP.";
list group {
key "id";
description
"List of multicast groups.";
leaf id {
type uint16;
description
"Identifier for the group.";
}
choice group-format {
mandatory true;
description
"Choice for multicast group format.";
case group-prefix {
leaf group-address {
type inet:ip-prefix;
description
"A single multicast group prefix.";
}
}
case startend {
leaf group-start {
type inet:ip-address;
description
"The first multicast group address in
the multicast group address range.";
}
leaf group-end {
type inet:ip-address;
description
"The last multicast group address in
the multicast group address range.";
}
}
}
}
}
}
}
container rp-discovery {
description
"RP discovery parameters.";
leaf rp-discovery-type {
type identityref {
base vpn-common:multicast-rp-discovery-type;
}
default "vpn-common:static-rp";
description
"Type of RP discovery used.";
}
container bsr-candidates {
when "derived-from-or-self(../rp-discovery-type, "
+ "'vpn-common:bsr-rp')" {
description
"Only applicable if discovery type is BSR-RP.";
}
description
"Container for List of Customer BSR candidate's
addresses.";
leaf-list bsr-candidate-address {
type inet:ip-address;
description
"Specifies the address of candidate Bootstrap
Router (BSR).";
}
}
}
}
container igmp {
if-feature "vpn-common:igmp and vpn-common:ipv4";
description
"Includes IGMP-related parameters.";
list static-group {
key "group-addr";
description
"Multicast static source/group associated to the
IGMP session";
leaf group-addr {
type rt-types:ipv4-multicast-group-address;
description
"Multicast group IPv4 addresss.";
}
leaf source-addr {
type rt-types:ipv4-multicast-source-address;
description
"Multicast source IPv4 addresss.";
}
}
leaf max-groups {
type uint32;
description
"Indicates the maximum groups.";
}
leaf max-entries {
type uint32;
description
"Indicates the maximum IGMP entries.";
}
leaf version {
type identityref {
base vpn-common:igmp-version;
}
default "vpn-common:igmpv2";
description
"Version of the IGMP.";
reference
"RFC 1112: Host Extensions for IP Multicasting
RFC 2236: Internet Group Management Protocol, Version 2
RFC 3376: Internet Group Management Protocol, Version 3";
}
}
container mld {
if-feature "vpn-common:mld and vpn-common:ipv6";
description
"Includes MLD-related parameters.";
list static-group {
key "group-addr";
description
"Multicast static source/group associated to the
MLD session";
leaf group-addr {
type rt-types:ipv6-multicast-group-address;
description
"Multicast group IPv6 addresss.";
}
leaf source-addr {
type rt-types:ipv6-multicast-source-address;
description
"Multicast source IPv6 addresss.";
}
}
leaf max-groups {
type uint32;
description
"Indicates the maximum groups.";
}
leaf max-entries {
type uint32;
description
"Indicates the maximum MLD entries.";
}
leaf version {
type identityref {
base vpn-common:mld-version;
}
default "vpn-common:mldv2";
description
"Version of the MLD protocol.";
reference
"RFC 2710: Multicast Listener Discovery (MLD) for IPv6
RFC 3810: Multicast Listener Discovery Version 2 (MLDv2)
for IPv6";
}
}
container pim {
if-feature "vpn-common:pim";
description
"Only applies when protocol type is PIM.";
leaf hello-interval {
type rt-types:timer-value-seconds16;
default "30";
description
"PIM hello-messages interval. If set to
'infinity' or 'not-set', no periodic
Hello messages are sent.";
reference
"RFC 7761: Protocol Independent Multicast - Sparse
Mode (PIM-SM): Protocol Specification (Revised),
Section 4.11";
}
leaf dr-priority {
type uint32;
default "1";
description
"Indicates the preference in the DR election
process. Numerically larger DR priority allows
a node to be elected as a DR.";
reference
"RFC 7761: Protocol Independent Multicast - Sparse
Mode (PIM-SM): Protocol Specification (Revised),
Section 4.3.2";
}
}
}
}
/* Main Blocks */ /* Main Blocks */
/* Main l3vpn-ntw */ /* Main l3vpn-ntw */
container l3vpn-ntw { container l3vpn-ntw {
description description
"Main container for L3VPN services management."; "Main container for L3VPN services management.";
container vpn-profiles { container vpn-profiles {
description description
"Contains a set of valid VPN Profiles to reference in the VPN "Contains a set of valid VPN Profiles to reference in the VPN
service."; service.";
skipping to change at page 56, line 44 skipping to change at page 67, line 42
"Top-level container for the VPN services."; "Top-level container for the VPN services.";
list vpn-service { list vpn-service {
key "vpn-id"; key "vpn-id";
description description
"List of VPN services."; "List of VPN services.";
uses vpn-common:vpn-description; uses vpn-common:vpn-description;
leaf parent-service-id { leaf parent-service-id {
type vpn-common:vpn-id; type vpn-common:vpn-id;
description description
"Pointer to the parent service, if any. "Pointer to the parent service, if any.
A parent service can an L3SM, a slice request, a VPN+ A parent service can be an L3SM, a slice request, a VPN+
service, etc."; service, etc.";
} }
leaf vpn-type { leaf vpn-type {
type identityref { type identityref {
base vpn-common:service-type; base vpn-common:service-type;
} }
description description
"Indicates the service type."; "Indicates the service type.";
} }
leaf vpn-service-topology { leaf vpn-service-topology {
type identityref { type identityref {
base vpn-common:vpn-topology; base vpn-common:vpn-topology;
} }
default "vpn-common:any-to-any"; default "vpn-common:any-to-any";
description description
"VPN service topology."; "VPN service topology.";
} }
uses vpn-common:service-status; uses vpn-common:service-status;
skipping to change at page 57, line 15 skipping to change at page 68, line 13
} }
leaf vpn-service-topology { leaf vpn-service-topology {
type identityref { type identityref {
base vpn-common:vpn-topology; base vpn-common:vpn-topology;
} }
default "vpn-common:any-to-any"; default "vpn-common:any-to-any";
description description
"VPN service topology."; "VPN service topology.";
} }
uses vpn-common:service-status; uses vpn-common:service-status;
container ie-profiles { container vpn-instance-profiles {
description description
"Container for Import/Export profiles."; "Container for a list of VPN instance profiles.";
list ie-profile { list vpn-instance-profile {
key "ie-profile-id"; key "profile-id";
description description
"List for Imort/Export profile."; "List of VPN instance profiles.";
leaf ie-profile-id { leaf profile-id {
type string; type string;
description description
"IE profile id."; "VPN instance profile identifier.";
} }
uses vpn-common:rt-rd; leaf role {
type identityref {
base vpn-common:role;
}
default "vpn-common:any-to-any-role";
description
"Role of the VPN node in the IP VPN.";
}
uses vpn-instance-profile;
} }
} }
container underlay-transport { container underlay-transport {
description description
"Container for underlay transport."; "Container for underlay transport.";
uses vpn-common:underlay-transport; uses vpn-common:underlay-transport;
} }
container external-connectivity { container external-connectivity {
if-feature "vpn-common:external-connectivity"; if-feature "vpn-common:external-connectivity";
description description
skipping to change at page 58, line 16 skipping to change at page 69, line 22
} }
} }
container vpn-nodes { container vpn-nodes {
description description
"Container for VPN nodes."; "Container for VPN nodes.";
list vpn-node { list vpn-node {
key "vpn-node-id"; key "vpn-node-id";
description description
"List for VPN node."; "List for VPN node.";
leaf vpn-node-id { leaf vpn-node-id {
type union { type vpn-common:vpn-id;
type vpn-common:vpn-id;
type uint32;
}
description description
"Type STRING or NUMBER identifier."; "An identifier of the VPN node.";
} }
leaf description { leaf description {
type string; type string;
description description
"Textual description of the VPN node."; "Textual description of the VPN node.";
} }
leaf ne-id { leaf ne-id {
type string; type string;
description description
"Unique identifier of the network element where the VPN "Unique identifier of the network element where the VPN
node is deployed."; node is deployed.";
} }
leaf node-role {
type identityref {
base vpn-common:role;
}
default "vpn-common:any-to-any-role";
description
"Role of the VPN node in the IP VPN.";
}
leaf local-autonomous-system { leaf local-autonomous-system {
if-feature "vpn-common:rtg-bgp"; if-feature "vpn-common:rtg-bgp";
type inet:as-number; type inet:as-number;
description description
"Provider's AS number in case the customer requests BGP "Provider's AS number in case the customer requests BGP
routing."; routing.";
} }
leaf address-family {
type identityref {
base vpn-common:address-family;
}
description
"The address family used for router-id information.";
}
leaf router-id { leaf router-id {
type inet:ip-address; type rt-types:router-id;
description
"The router-id information can be an IPv4 or IPv6
address.";
}
uses vpn-common:rt-rd;
leaf node-ie-profile {
type leafref {
path "/l3vpn-ntw/vpn-services/vpn-service"
+ "/ie-profiles/ie-profile/ie-profile-id";
}
description description
"Node's Import/Export profile."; "A 32-bit number in the dotted-quad format that is used
to uniquely identify a node within an autonomous
system. This identifier is used for both IPv4 and
IPv6.";
} }
container maximum-routes { container active-vpn-instance-profiles {
description description
"Defines maximum routes for the VRF."; "Container for active VPN instance profiles.";
list selector { list vpn-instance-profile {
key "address-family protocol"; key "profile-id";
description description
"List of address families."; "";
leaf address-family { leaf profile-id {
type identityref { type leafref {
base vpn-common:address-family; path "/l3vpn-ntw/vpn-services/vpn-service"
} + "/vpn-instance-profiles/vpn-instance-profile"
description + "/profile-id";
"Indicates the address family (IPv4 or IPv6).";
}
leaf protocol {
type identityref {
base vpn-common:routing-protocol-type;
} }
description description
"Indicates the routing protocol. 'any' value can "Node's Import/Export profile.";
be used to identify a limit that will apply for
any active routing protocol.";
}
leaf maximum-routes {
type uint32;
description
"Indicates the maximum prefixes the VRF can accept
for this address family and protocol.";
}
}
}
uses vpn-common:vpn-components-group;
container multicast {
if-feature "vpn-common:multicast";
description
"Global multicast parameters.";
uses vpn-common:service-status;
leaf-list tree-flavor {
type identityref {
base vpn-common:multicast-tree-type;
}
description
"Type of tree to be used.";
}
container rp {
description
"RP parameters.";
container rp-group-mappings {
description
"RP-to-group mappings parameters.";
list rp-group-mapping {
key "id";
description
"List of RP-to-group mappings.";
leaf id {
type uint16;
description
"Unique identifier for the mapping.";
}
container provider-managed {
description
"Parameters for a provider-managed RP.";
leaf enabled {
type boolean;
default "false";
description
"Set to true if the Rendezvous Point (RP)
must be a provider-managed node. Set to
false if it is a customer-managed node.";
}
leaf rp-redundancy {
type boolean;
default "false";
description
"If 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.";
}
description
"PIM Anycast-RP parameters.";
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.";
}
}
}
leaf rp-address {
when "../provider-managed/enabled = 'false'" {
description
"Relevant when the RP is not
provider-managed.";
}
type inet:ip-address;
mandatory true;
description
"Defines the address of the RP.
Used if the RP is customer-managed.";
}
container groups {
description
"Multicast groups associated with the RP.";
list group {
key "id";
description
"List of multicast groups.";
leaf id {
type uint16;
description
"Identifier for the group.";
}
choice group-format {
mandatory true;
description
"Choice for multicast group format.";
case group-prefix {
leaf group-address {
type inet:ip-prefix;
description
"A single multicast group prefix.";
}
}
case startend {
leaf group-start {
type inet:ip-address;
description
"The first multicast group address in
the multicast group address range.";
}
leaf group-end {
type inet:ip-address;
description
"The last multicast group address in
the multicast group address range.";
}
}
}
}
}
}
} }
container rp-discovery { list router-id {
key "address-family";
description description
"RP discovery parameters."; "Router-id per address family.";
leaf rp-discovery-type { leaf address-family {
type identityref { type identityref {
base vpn-common:multicast-rp-discovery-type; base vpn-common:address-family;
}
default "vpn-common:static-rp";
description
"Type of RP discovery used.";
}
container bsr-candidates {
when "derived-from-or-self(../rp-discovery-type, "
+ "'vpn-common:bsr-rp')" {
description
"Only applicable if discovery type is BSR-RP.";
} }
description description
"Container for List of Customer BSR candidate's "Indicates the address family (IPv4 or IPv6).";
addresses.";
leaf-list bsr-candidate-address {
type inet:ip-address;
description
"Specifies the address of candidate Bootstrap
Router (BSR).";
}
}
}
}
container msdp {
if-feature "msdp";
description
"Includes MSDP-related parameters.";
leaf peer {
type inet:ip-address;
description
"Indicates the IP address of the MSDP peer.";
}
leaf local-address {
type inet:ip-address;
description
"Indicates the IP address of the local end.
This local address must be configured on
the node.";
}
uses vpn-common:service-status;
}
container igmp {
if-feature "vpn-common:igmp and vpn-common:ipv4";
description
"Includes IGMP-related parameters.";
list static-group {
key "group-addr";
description
"Multicast static source/group associated to the
IGMP session";
leaf group-addr {
type rt-types:ipv4-multicast-group-address;
description
"Multicast group IPv4 addresss.";
} }
leaf source-addr { leaf router-id {
type rt-types:ipv4-multicast-source-address; type inet:ip-address;
description description
"Multicast source IPv4 addresss."; "The router-id information can be an IPv4 or IPv6
} address. This can be used, for example, to
} configure an IPv6 address as a router-id
leaf max-groups { when such capability is supported by underlay
type uint32; routers. In such case, the configured value
description overrides the generic one defined at the VPN
"Indicates the maximum groups."; node level.";
}
leaf max-entries {
type uint32;
description
"Indicates the maximum IGMP entries.";
}
leaf version {
type identityref {
base vpn-common:igmp-version;
} }
default "vpn-common:igmpv2";
description
"Version of the IGMP.";
} }
uses vpn-common:service-status; uses vpn-instance-profile;
} }
container mld { }
if-feature "vpn-common:mld and vpn-common:ipv6"; container msdp {
if-feature "msdp";
description
"Includes MSDP-related parameters.";
leaf peer {
type inet:ip-address;
description description
"Includes MLD-related parameters."; "Indicates the IP address of the MSDP peer.";
list static-group {
key "group-addr";
description
"Multicast static source/group associated to the
MLD session";
leaf group-addr {
type rt-types:ipv6-multicast-group-address;
description
"Multicast group IPv6 addresss.";
}
leaf source-addr {
type rt-types:ipv6-multicast-source-address;
description
"Multicast source IPv6 addresss.";
}
}
leaf max-groups {
type uint32;
description
"Indicates the maximum groups.";
}
leaf max-entries {
type uint32;
description
"Indicates the maximum MLD entries.";
}
leaf version {
type identityref {
base vpn-common:mld-version;
}
default "vpn-common:mldv2";
description
"Version of the MLD protocol.";
}
uses vpn-common:service-status;
} }
container pim { leaf local-address {
if-feature "vpn-common:pim"; type inet:ip-address;
description description
"Only applies when protocol type is PIM."; "Indicates the IP address of the local end.
leaf hello-interval { This local address must be configured on
type uint8; the node.";
units "seconds";
default "30";
description
"PIM hello-messages interval.";
}
leaf dr-priority {
type uint16;
description
"Value to increase or decrease the
chances of a given DR being elected.";
}
uses vpn-common:service-status;
} }
uses vpn-common:service-status;
} }
uses vpn-common:vpn-components-group;
uses vpn-common:service-status; uses vpn-common:service-status;
container vpn-network-accesses { container vpn-network-accesses {
description description
"List of network accesses."; "List of network accesses.";
list vpn-network-access { list vpn-network-access {
key "id"; key "id";
description description
"List of network accesses."; "List of network accesses.";
leaf id { leaf id {
type vpn-common:vpn-id; type vpn-common:vpn-id;
skipping to change at page 66, line 28 skipping to change at page 71, line 47
description description
"Textual description of the network access."; "Textual description of the network access.";
} }
leaf vpn-network-access-type { leaf vpn-network-access-type {
type identityref { type identityref {
base vpn-common:site-network-access-type; base vpn-common:site-network-access-type;
} }
default "vpn-common:point-to-point"; default "vpn-common:point-to-point";
description description
"Describes the type of connection, e.g., "Describes the type of connection, e.g.,
point-to-point or multipoint."; point-to-point.";
}
leaf vpn-instance-profile {
type leafref {
path "/l3vpn-ntw/vpn-services/vpn-service/vpn-nodes"
+ "/vpn-node/active-vpn-instance-profiles"
+ "/vpn-instance-profile/profile-id";
}
description
"An identifier of an active VPN instance profile.";
} }
uses vpn-common:service-status; uses vpn-common:service-status;
container connection { container connection {
description description
"Encapsulation types."; "Defines layer 2 protocols and parameters that are
leaf encapsulation-type { required to enable connectivity between the PE
type identityref { and the CE.";
base vpn-common:encapsulation-type; container encapsulation {
}
default "vpn-common:untagged-int";
description
"Encapsulation type. By default, the encapsulation
type is set to 'untagged'.";
}
container logical-interface {
description
"Reference of a logical interface
type.";
leaf peer-reference {
type uint32;
description
"Specifies the associated logical peer
interface.";
}
}
container tagged-interface {
description description
"Container for tagged interfaces."; "Container for layer 2 encapsulation.";
leaf type { leaf type {
type identityref { type identityref {
base vpn-common:encapsulation-type; base vpn-common:encapsulation-type;
} }
default "vpn-common:priority-tagged"; default "vpn-common:priority-tagged";
description description
"Tagged interface type. By default, the type of "Tagged interface type. By default, the type of
the tagged interface is 'priority-tagged'."; the tagged interface is 'priority-tagged'.";
} }
container dot1q-vlan-tagged { container dot1q {
when "derived-from-or-self(../type, " when "derived-from-or-self(../type, "
+ "'vpn-common:dot1q')" { + "'vpn-common:dot1q')" {
description description
"Only applies when the type of the "Only applies when the type of the
tagged interface is 'dot1q'."; tagged interface is 'dot1q'.";
} }
if-feature "vpn-common:dot1q"; if-feature "vpn-common:dot1q";
description description
"Tagged interface."; "Tagged interface.";
leaf tag-type { leaf tag-type {
skipping to change at page 68, line 20 skipping to change at page 73, line 30
description description
"Tag type. By default, the tag type is "Tag type. By default, the tag type is
'c-vlan'."; 'c-vlan'.";
} }
} }
container qinq { container qinq {
when "derived-from-or-self(../type, " when "derived-from-or-self(../type, "
+ "'vpn-common:qinq')" { + "'vpn-common:qinq')" {
description description
"Only applies when the type of the tagged "Only applies when the type of the tagged
interface is 'qinq'."; interface is QinQ.";
} }
if-feature "vpn-common:qinq"; if-feature "vpn-common:qinq";
description description
"QinQ."; "Includes QinQ parameters.";
leaf tag-type { leaf tag-type {
type identityref { type identityref {
base vpn-common:tag-type; base vpn-common:tag-type;
} }
default "vpn-common:c-s-vlan"; default "vpn-common:c-s-vlan";
description description
"Tag type. By default, the tag type is "Tag type. By default, the tag type is
'c-s-vlan'."; 'c-s-vlan'.";
} }
leaf svlan-id { leaf svlan-id {
skipping to change at page 68, line 47 skipping to change at page 74, line 8
description description
"SVLAN identifier."; "SVLAN identifier.";
} }
leaf cvlan-id { leaf cvlan-id {
type uint16; type uint16;
mandatory true; mandatory true;
description description
"CVLAN identifier."; "CVLAN identifier.";
} }
} }
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";
description
"Container for 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.";
}
}
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";
description
"QinQ.";
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";
description
"List of peer IP addresses.";
leaf peer-ip {
type inet:ip-address;
description
"Peer IP address.";
}
}
}
} }
container bearer { container l2-tunnel-service {
description description
"Defines physical properties of a site "Defines a layer 2 tunnel termination.
attachment."; It is only applicable when a tunnel is
leaf bearer-reference { required. The supported values are:
if-feature "vpn-common:bearer-reference"; pseudowire, VPLS and, VXLAN. Other
type string; values may defined, if needed.";
leaf type {
type identityref {
base l2-tunnel-type;
}
description description
"This is an internal reference for the service "Selects the tunnel termiantion option for
provider."; each vpn-network-access.";
} }
container pseudowire { container pseudowire {
description description
"Pseudowire termination parameters"; "Includes pseudowire termination parameters.";
leaf vcid { leaf vcid {
type uint32; type uint32;
description description
"Indicates a PW or VC identifier."; "Indicates a PW or VC identifier.";
} }
leaf far-end { leaf far-end {
type union { type union {
type uint32; type uint32;
type inet:ip-address; type inet:ip-address;
} }
description description
"SDP/Far End/LDP neighbour reference."; "SDP/Far End/LDP neighbour reference.";
} }
} }
container vpls { container vpls {
description description
"Pseudowire termination parameters"; "VPLS termination parameters.";
leaf vcid { leaf vcid {
type union { type union {
type uint32; type uint32;
type string; type string;
} }
description description
"VCID identifier, IRB/RVPPLs interface "VCID identifier, IRB/RVPPLs interface
supported using string format."; supported using string format.";
} }
leaf far-end { leaf far-end {
type union { type union {
type uint32; type uint32;
type inet:ip-address; type inet:ip-address;
} }
description description
"SDP/Far End/LDP Neighbour reference."; "SDP/Far End/LDP neighbour reference.";
} }
} }
container vxlan {
if-feature "vpn-common:vxlan";
description
"VXLAN termination parameters.";
leaf vni-id {
type uint32;
mandatory true;
description
"VXLAN Network Identifier (VNI).";
}
leaf peer-mode {
type identityref {
base vpn-common:vxlan-peer-mode;
}
default "vpn-common:static-mode";
description
"Specifies the VXLAN access mode. By default,
the peer mode is set to 'static-mode'.";
}
leaf-list peer-ip-address {
type inet:ip-address;
description
"List of peer's IP addresses.";
}
}
}
leaf l2-termination-point {
type vpn-common:vpn-id;
description
"Specifies a reference to a local layer 2
termination point such a layer 2 sub-interface.";
}
leaf local-bridge-reference {
type vpn-common:vpn-id;
description
"Specifies a local bridge reference to
accommodate, for example, implementations
that require internal bridging.
A reference may be a local bridge domain.";
}
leaf l2vpn-id {
type vpn-common:vpn-id;
description
"Indicates the L2VPN service associated with an
Integrated Routing and Bridging (IRB)
interface.";
}
leaf bearer-reference {
if-feature "vpn-common:bearer-reference";
type string;
description
"This is an internal reference for the service
provider.";
} }
} }
container ip-connection { container ip-connection {
description description
"Defines connection parameters."; "Defines IP connection parameters.";
leaf l3-termination-point {
type vpn-common:vpn-id;
description
"Specifies a reference to a local layer 3
termination point such as a bridge domain
interface.";
}
container ipv4 { container ipv4 {
if-feature "vpn-common:ipv4"; if-feature "vpn-common:ipv4";
description description
"IPv4-specific parameters."; "IPv4-specific parameters.";
leaf local-address { leaf local-address {
type inet:ipv4-prefix; type inet:ipv4-address;
description description
"This address is used at provider side."; "This address is used at the provider side.";
}
leaf prefix-length {
type uint8 {
range "0..32";
}
description
"Subnet prefix length expressed in bits.
It is applied to both local and customer
addresses.";
} }
leaf address-allocation-type { leaf address-allocation-type {
type identityref { type identityref {
base address-allocation-type; base address-allocation-type;
} }
must "not(derived-from-or-self(current(), " must "not(derived-from-or-self(current(), "
+ "'slaac') or derived-from-or-self(current()," + "'slaac') or derived-from-or-self(current(),"
+ " 'provider-dhcp-slaac'))" { + " 'provider-dhcp-slaac'))" {
error-message error-message
"SLAAC is only applicable to IPv6."; "SLAAC is only applicable to IPv6.";
} }
description description
"Defines how addresses are allocated to the "Defines how addresses are allocated to the
peer site. peer site.
skipping to change at page 71, line 44 skipping to change at page 77, line 17
+ "'slaac') or derived-from-or-self(current()," + "'slaac') or derived-from-or-self(current(),"
+ " 'provider-dhcp-slaac'))" { + " 'provider-dhcp-slaac'))" {
error-message error-message
"SLAAC is only applicable to IPv6."; "SLAAC is only applicable to IPv6.";
} }
description description
"Defines how addresses are allocated to the "Defines how addresses are allocated to the
peer site. peer site.
If there is no value for the address If there is no value for the address
allocation type, then IPv4 is not enabled."; allocation type, then IPv4 addressing is not
enabled.";
} }
choice allocation-type { choice allocation-type {
description description
"Choice of the IPv4 address allocation."; "Choice of the IPv4 address allocation.";
case provider-dhcp { case provider-dhcp {
when "derived-from-or-self(./address-" when "derived-from-or-self(./address-"
+ "allocation-type, 'provider-dhcp')" { + "allocation-type, 'provider-dhcp')" {
description description
"Only applies when addresses are allocated "Only applies when addresses are allocated
by DHCP."; by DHCP that is operated by the provider.";
} }
description description
"DHCP allocated addresses related "DHCP allocated addresses related
parameters."; parameters.";
leaf dhcp-server-enable { leaf dhcp-service-type {
type boolean; type enumeration {
default "true"; enum server {
description
"Local DHCP server.";
}
enum relay {
description
"Local DHCP relay. DHCP requests are
relayed to a provider's server.";
}
}
description description
"Enables a DHCP service on this access. "Indicates the type of the DHCP service to
The following information are passed to be enabled on this access.";
the provider's DHCP server.";
} }
choice address-assign { choice service-type {
default "number";
description description
"Choice for how IPv4 addresses are "Choice based on the DHCP service type.";
assigned."; case relay {
case number { when "./dhcp-service-type = 'relay'";
leaf number-of-dynamic-address { description
type uint16; "Container for list of provider's DHCP
default "1"; servers.";
leaf-list server-ip-address {
type inet:ipv4-address;
description description
"Specifies the number of IP addresses "IPv4 addresses of the provider's DHCP
to be assigned to the customer on this server to use by the local DHCP
access."; relay.";
} }
} }
case explicit { case server {
container customer-addresses { when "./dhcp-service-type = 'server'";
description
"A choice about how addresses are assigned
when a local DHCP server is enabled.";
choice address-assign {
default "number";
description description
"Container for customer addresses to be "Choice for how IPv4 addresses are
allocated using DHCP."; assigned.";
list address-group { case number {
key "group-id"; leaf number-of-dynamic-address {
description type uint16;
"Describes IP addresses to be default "1";
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.";
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 description
"Indicates the first address in "Specifies the number of IP
the group."; addresses to be assigned to the
customer on this access.";
} }
leaf end-address { }
type inet:ipv4-address; case explicit {
container customer-addresses {
description description
"Indicates the last address in the "Container for customer
group."; addresses to be allocated
using DHCP.";
list address-pool {
key "pool-id";
description
"Describes IP addresses to be
allocated by DHCP.
When only start-address 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.";
leaf pool-id {
type string;
description
"A pool identifier for the
address range from start-
address to end-address.";
}
leaf start-address {
type inet:ipv4-address;
description
"Indicates the first address
in the pool.";
}
leaf end-address {
type inet:ipv4-address;
description
"Indicates the last address
in the pool.";
}
}
} }
} }
} }
} }
} }
} }
case dhcp-relay { case dhcp-relay {
when "derived-from-or-self(./address-allocation" when "derived-from-or-self(./address-allocation"
+ "-type, 'provider-dhcp-relay')" { + "-type, 'provider-dhcp-relay')" {
description description
"Only applies when the provider is required "Only applies when the provider is required
to implement DHCP relay function."; to implement a DHCP relay function that
will relay DHCP requests to a customer's
DHCP server.";
} }
description description
"DHCP relay provided by operator."; "DHCP relay is provided by the operator.";
leaf dhcp-relay-enable {
type boolean;
default "true";
description
"Enables the DHCP relay function for this
access.";
}
container customer-dhcp-servers { container customer-dhcp-servers {
description description
"Container for list of customer "Container for a list of customer's DHCP
DHCP servers."; servers.";
leaf-list server-ip-address { leaf-list server-ip-address {
type inet:ipv4-address; type inet:ipv4-address;
description description
"IP address of customer DHCP server."; "IPv4 addresses of the customer's DHCP
server.";
} }
} }
} }
case static-addresses { case static-addresses {
when "derived-from-or-self(./address-allocation" when "derived-from-or-self(./address-allocation"
+ "-type, 'static-address')" { + "-type, 'static-address')" {
description description
"Only applies when address allocation "Only applies when address allocation
type is static."; type is static.";
} }
description description
"Describes IPv4 addresses used."; "Lists the IPv4 addresses that are used.";
leaf primary-address { leaf primary-address {
type leafref { type leafref {
path "../address/address-id"; path "../address/address-id";
} }
description description
"Primary address of the connection."; "Primary address of the connection.";
} }
list address { list address {
key "address-id"; key "address-id";
description description
"Describes IPv4 addresses used."; "Lists the IPv4 addresses that are used.";
leaf address-id { leaf address-id {
type string; type string;
description description
"Used static IPv4 address."; "An identifier of the static IPv4
address.";
} }
leaf customer-address { leaf customer-address {
type inet:ipv4-address; type inet:ipv4-address;
description description
"IPv4 address at the customer side."; "IPv4 address at the customer side.";
} }
} }
} }
} }
} }
container ipv6 { container ipv6 {
if-feature "vpn-common:ipv6"; if-feature "vpn-common:ipv6";
description description
"IPv6-specific parameters."; "IPv6-specific parameters.";
leaf local-address { leaf local-address {
type inet:ipv6-prefix; type inet:ipv6-address;
description description
"Address of the provider side."; "IPv6 address of the provider side.";
}
leaf prefix-length {
type uint8 {
range "0..128";
}
description
"Subnet prefix length expressed in bits.
It is applied to both local and customer
addresses.";
} }
leaf address-allocation-type { leaf address-allocation-type {
type identityref { type identityref {
base address-allocation-type; base address-allocation-type;
} }
description description
"Defines how addresses are allocated. "Defines how addresses are allocated.
If there is no value for the address If there is no value for the address
allocation type, then IPv6 is allocation type, then IPv6 addressing is
not enabled."; disabled.";
} }
choice allocation-type { choice allocation-type {
description description
"IPv6 allocation type."; "A choice based on the IPv6 allocation type.";
case provider-dhcp { container provider-dhcp {
when "derived-from-or-self(./address-allo" when "derived-from-or-self(../address-allo"
+ "cation-type, 'provider-dhcp') " + "cation-type, 'provider-dhcp') "
+ "or derived-from-or-self(./address-allo" + "or derived-from-or-self(../address-allo"
+ "cation-type, 'provider-dhcp-slaac')" { + "cation-type, 'provider-dhcp-slaac')" {
description description
"Only applies when addresses are "Only applies when addresses are
allocated by DHCPv6."; allocated by DHCPv6 provided by the
operator.";
} }
description description
"DHCPv6 allocated addresses related "DHCPv6 allocated addresses related
parameters."; parameters.";
leaf dhcp-server-enable { leaf dhcp-service-type {
type boolean; type enumeration {
default "true"; enum server {
description
"Local DHCPv6 server.";
}
enum relay {
description
"DHCPv6 relay.";
}
}
description description
"Enables DHCPv6 service for this access."; "Indicates the type of the DHCPv6 service to
be enabled on this access.";
} }
choice address-assign { choice service-type {
default "number";
description description
"Choice for the way to assign IPv6 "Choice based on the DHCPv6 service type.";
prefixes."; case provider-dhcp-servers {
case number { when "./dhcp-service-type = 'relay'";
leaf number-of-dynamic-address { description
type uint16; "Case where a local DHCPv6 relay is
default "1"; enabled. This list is used if and only
if a DHCP relay is enabled.";
leaf-list server-ip-address {
type inet:ipv6-address;
description description
"Describes the number of IPv6 prefixes "IPv6 addresses of the provider's
that are allocated to the customer DHCPv6 server.";
on this access.";
} }
} }
case explicit { case server {
container customer-addresses { when "./dhcp-service-type = 'server'";
description
"Case where a local DHCPv6 server is
enabled.";
choice address-assign {
default "number";
description description
"Container for customer IPv6 addresses "Choice about how IPv6 prefixes are
allocated by DHCPv6."; assigned by the DHCPv6 server.";
list address-group { case number {
key "group-id"; leaf number-of-dynamic-address {
description type uint16;
"Describes IPv6 addresses allocated default "1";
by DHCPv6.
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.";
leaf group-id {
type string;
description
"Group-id for the address range
from identified by start-address
and end-address.";
}
leaf start-address {
type inet:ipv6-address;
description description
"Indicates the first address."; "Describes the number of IPv6
prefixes that are allocated to
the customer on this access.";
} }
leaf end-address { }
type inet:ipv6-address; case explicit {
container customer-addresses {
description description
"Indicates the last address."; "Container for customer IPv6
addresses allocated by DHCPv6.";
list address-pool {
key "pool-id";
description
"Describes IPv6 addresses
allocated by DHCPv6.
When only start-address 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.";
leaf pool-id {
type string;
description
"Pool identifier for the address
range from identified by start-
address and end-address.";
}
leaf start-address {
type inet:ipv6-address;
description
"Indicates the first address.";
}
leaf end-address {
type inet:ipv6-address;
description
"Indicates the last address.";
}
}
} }
} }
} }
} }
} }
} }
case dhcp-relay { case dhcp-relay {
when "derived-from-or-self(./address-allo" when "derived-from-or-self(./address-allo"
+ "cation-type, 'provider-dhcp-relay')" { + "cation-type, 'provider-dhcp-relay')" {
description description
"Only applies when the provider is required "Only applies when the provider is required
to implement DHCP relay function."; to implement DHCP relay function that will
relay DHCPv6 requests to a customer's DHCP
server.";
} }
description description
"DHCP relay provided by operator."; "DHCPv6 relay provided by the operator.";
leaf dhcp-relay-enable {
type boolean;
default "true";
description
"Enables the DHCP relay function for this
access.";
}
container customer-dhcp-servers { container customer-dhcp-servers {
description description
"Container for list of customer DHCP "Container for a list of customer DHCP
servers."; servers.";
leaf-list server-ip-address { leaf-list server-ip-address {
type inet:ipv6-address; type inet:ipv6-address;
description description
"This node contains the IP address of "Contains the IP addresses of the customer
the customer DHCP server. If the DHCP DHCPv6 server.";
relay function is implemented by the
provider, this node contains the
configured value.";
} }
} }
} }
case static-addresses { case static-addresses {
when "derived-from-or-self(./address-allocation" when "derived-from-or-self(./address-allocation"
+ "-type, 'static-address')" { + "-type, 'static-address')" {
description description
"Only applies when protocol allocation type "Only applies when protocol allocation type
is static."; is static.";
} }
description description
"IPv6-specific parameters for static "IPv6-specific parameters for static
allocation."; allocation.";
leaf primary-address { leaf primary-address {
type leafref { type leafref {
path "../address/prefix-id"; path "../address/address-id";
} }
description description
"Principal address of the connection"; "Principal address of the connection";
} }
list address { list address {
key "prefix-id"; key "address-id";
description description
"Describes IPv6 prefixes used."; "Describes IPv6 addresses that are used.";
leaf prefix-id { leaf address-id {
type string; type string;
description description
"An identifier of an IPv6 prefix."; "An identifier of an IPv6 address.";
} }
leaf customer-prefix { leaf customer-address {
type inet:ipv6-prefix; type inet:ipv6-address;
description description
"An IPv6 prefix of the customer side."; "An IPv6 address of the customer side.";
} }
} }
} }
} }
} }
} }
container routing-protocols { container routing-protocols {
description description
"Defines routing protocols."; "Defines routing protocols.";
list routing-protocol { list routing-protocol {
key "id"; key "id";
description description
"List of routing protocols used on "List of routing protocols used on
the CE/PE link. This list can be augmented."; the CE/PE link. This list can be augmented.";
leaf id { leaf id {
type string; type string;
description description
"Unique identifier for routing protocol."; "Unique identifier for routing protocol.";
} }
skipping to change at page 81, line 45 skipping to change at page 88, line 30
"Includes a description of the BGP session. "Includes a description of the BGP session.
Such description is meant to be used for Such description is meant to be used for
diagnosis purposes. The semantic of the diagnosis purposes. The semantic of the
description is local to an description is local to an
implementation."; implementation.";
} }
leaf local-autonomous-system { leaf local-autonomous-system {
type inet:as-number; type inet:as-number;
description description
"Is set to the ASN to override a peers' ASN "Indicates a local AS Number (ASN) if a
if such feature is requested by the distinct ASN than the one configured at
Customer."; the VPN node level is needed.";
} }
leaf peer-autonomous-system { leaf peer-autonomous-system {
type inet:as-number; type inet:as-number;
mandatory true; mandatory true;
description description
"Indicates the Customer's AS Number (ASN) in "Indicates the customer's ASN in
case the Customer requests BGP routing."; case the customer requests BGP routing.";
} }
leaf address-family { leaf address-family {
type identityref { type identityref {
base vpn-common:address-family; base vpn-common:address-family;
} }
description description
"This node contains the address families to be "This node contains the address families to be
activated. Dual-stack means that both IPv4 activated. Dual-stack means that both IPv4
and IPv6 will be activated."; and IPv6 will be activated.";
} }
leaf local-address {
type union {
type inet:ip-address;
type if:interface-ref;
}
description
"Set the local IP address to use for the BGP
transport session. This may be expressed as
either an IP address or a reference to an
interface.";
}
leaf-list neighbor { leaf-list neighbor {
type inet:ip-address; type inet:ip-address;
description description
"IP address(es) of the BGP neighbor. IPv4 "IP address(es) of the BGP neighbor. IPv4
and IPv6 neighbors may be indicated if and IPv6 neighbors may be indicated if
two sessions will be used for IPv4 and two sessions will be used for IPv4 and
IPv6."; IPv6.";
} }
leaf multihop { leaf multihop {
type uint8; type uint8;
description description
"Describes the number of IP hops allowed "Describes the number of IP hops allowed
between a given BGP neighbor and the PE."; between a given BGP neighbor and the PE.";
} }
leaf as-override { leaf as-override {
type boolean; type boolean;
default "false"; default "false";
description description
"Defines whether AS override is enabled, "Defines whether ASN override is enabled,
i.e., replace the ASN of the customer i.e., replace the ASN of the customer
specified in the AS Path attribute with specified in the AS_Path attribute with
the local ASN."; the local ASN.";
} }
leaf allow-own-as {
type uint8;
default "0";
description
"Specifies the number of occurrences
of the provider's ASN that can occur
within the AS_PATH before it
is rejected.";
}
leaf prepend-global-as {
type boolean;
default "false";
description
"In some situations, the ASN that is
provided at the VPN node level may be
distinct from the one configured at the
VPN network access level. When set to
'true', this parameter prevents that
the ASN provided at the VPN node
level is also prepended to the BGP
route updates for this access.";
}
leaf default-route { leaf default-route {
type boolean; type boolean;
default "false"; default "false";
description description
"Defines whether default route(s) can be "Defines whether default routes can be
advertised to its peer. If set, the advertised to its peer. If set, the
default route(s) is advertised to its default routes are advertised to its
peer."; peer.";
} }
leaf site-of-origin { leaf site-of-origin {
when "../address-family = 'vpn-common:ipv4' or " when "../address-family = 'vpn-common:ipv4' or "
+ "'vpn-common:dual-stack'" { + "'vpn-common:dual-stack'" {
description description
"Only applies if IPv4 is activated."; "Only applies if IPv4 is activated.";
} }
type rt-types:route-origin; type rt-types:route-origin;
description description
"The Site of Origin attribute is encoded as "The Site of Origin attribute is encoded as
a Route Origin Extended Community. It is a Route Origin Extended Community. It is
meant to uniquely identify the set of routes meant to uniquely identify the set of routes
learned from a site via a particular CE/PE learned from a site via a particular CE/PE
connection and is used to prevent routing connection and is used to prevent routing
skipping to change at page 83, line 17 skipping to change at page 90, line 33
} }
type rt-types:route-origin; type rt-types:route-origin;
description description
"The Site of Origin attribute is encoded as "The Site of Origin attribute is encoded as
a Route Origin Extended Community. It is a Route Origin Extended Community. It is
meant to uniquely identify the set of routes meant to uniquely identify the set of routes
learned from a site via a particular CE/PE learned from a site via a particular CE/PE
connection and is used to prevent routing connection and is used to prevent routing
loops."; loops.";
reference reference
"RFC4364, Section 7"; "RFC 4364: BGP/MPLS IP Virtual Private
Networks (VPNs), Section 7";
} }
leaf ipv6-site-of-origin { leaf ipv6-site-of-origin {
when "../address-family = 'vpn-common:ipv6' or " when "../address-family = 'vpn-common:ipv6' or "
+ "'vpn-common:dual-stack'" { + "'vpn-common:dual-stack'" {
description description
"Only applies if IPv6 is activated."; "Only applies if IPv6 is activated.";
} }
type rt-types:ipv6-route-origin; type rt-types:ipv6-route-origin;
description description
"IPv6 Route Origins are IPv6 Address Specific "IPv6 Route Origins are IPv6 Address Specific
BGP Extended that are meant to the Site of BGP Extended that are meant to the Site of
Origin for VRF information."; Origin for VRF information.";
reference reference
"RFC 5701: IPv6 Address Specific BGP Extended "RFC 5701: IPv6 Address Specific BGP Extended
Community Attribute"; Community Attribute";
} }
list redistribute-connected {
key "address-family";
description
"Indicates the per-AF policy to follow
for connected routes.";
leaf address-family {
type identityref {
base vpn-common:address-family;
}
description
"Indicates the address family.";
}
leaf enable {
type boolean;
description
"Enables to redistribute connected
routes.";
}
}
container bgp-max-prefix { container bgp-max-prefix {
description description
"Controls the behavior when a prefix "Controls the behavior when a prefix
maximum is reached."; maximum is reached.";
leaf max-prefix { leaf max-prefix {
type uint32; type uint32;
default "5000"; default "5000";
description description
"Indicates the maximum number of BGP "Indicates the maximum number of BGP
prefixes allowed in the BGP session. prefixes allowed in the BGP session.
It allows to control how many prefixes It allows to control how many prefixes
can be received from a neighbor. can be received from a neighbor.
If the limit is exceeded, the action If the limit is exceeded, the action
indicated in violate-action will be indicated in violate-action will be
followed."; followed.";
reference reference
"RFC4271, Section 8.2.2."; "RFC 4271: A Border Gateway Protocol 4
(BGP-4), Section 8.2.2";
} }
leaf warning-threshold { leaf warning-threshold {
type decimal64 { type decimal64 {
fraction-digits 5; fraction-digits 5;
range "0..100"; range "0..100";
} }
units "percent"; units "percent";
default "75"; default "75";
description description
"When this value is reached, a warning "When this value is reached, a warning
skipping to change at page 85, line 23 skipping to change at page 93, line 12
messages' frequency between a PE messages' frequency between a PE
and a BGP peer. and a BGP peer.
If set to '0', it indicates KEEPALIVE If set to '0', it indicates KEEPALIVE
messages are disabled. messages are disabled.
It is suggested that the maximum time It is suggested that the maximum time
between KEEPALIVEmessages would be between KEEPALIVEmessages would be
one third of the Hold Time interval."; one third of the Hold Time interval.";
reference reference
"Section 4.4 of RFC 4271"; "RFC 4271: A Border Gateway Protocol 4
(BGP-4), Section 4.4";
} }
leaf hold-time { leaf hold-time {
type uint16 { type uint16 {
range "0 | 3..65535"; range "0 | 3..65535";
} }
units "seconds"; units "seconds";
default "90"; default "90";
description description
"It indicates the maximum number of "It indicates the maximum number of
seconds that may elapse between the seconds that may elapse between the
receipt of successive KEEPALIVE receipt of successive KEEPALIVE
and/or UPDATE messages from the peer. and/or UPDATE messages from the peer.
The Hold Time must be either zero or The Hold Time must be either zero or
at least three seconds."; at least three seconds.";
reference reference
"Section 4.2 of RFC 4271"; "RFC 4271: A Border Gateway Protocol 4
(BGP-4), Section 4.2";
} }
} }
container security { container security {
description description
"Container for BGP security parameters "Container for BGP security parameters
between a PE and a CE."; between a PE and a CE.";
leaf enable { leaf enable {
type boolean; type boolean;
default "false"; default "false";
description description
skipping to change at page 86, line 37 skipping to change at page 94, line 29
description description
"Reference to the TCP-AO key chain."; "Reference to the TCP-AO key chain.";
reference reference
"RFC 8177: YANG Key Chain."; "RFC 8177: YANG Key Chain.";
} }
} }
case md5 { case md5 {
description description
"Uses MD5 to secure the session."; "Uses MD5 to secure the session.";
reference reference
"Section 13.2 of RFC 4364"; "RFC 4364: BGP/MPLS IP Virtual Private
Networks (VPNs),
Section 13.2";
leaf md5-keychain { leaf md5-keychain {
type key-chain:key-chain-ref; type key-chain:key-chain-ref;
description description
"Reference to the MD5 key chain."; "Reference to the MD5 key chain.";
reference reference
"RFC 8177: YANG Key Chain."; "RFC 8177: YANG Key Chain.";
} }
} }
case explicit { case explicit {
leaf key-id { leaf key-id {
type uint32; type uint32;
description description
"Key Identifier"; "Key Identifier";
} }
leaf key { leaf key {
type string; type string;
description description
"OSPF authentication key."; "BGP authentication key.";
} }
leaf crypto-algorithm { leaf crypto-algorithm {
type identityref { type identityref {
base key-chain:crypto-algorithm; base key-chain:crypto-algorithm;
} }
description description
"Indicates the cryptographic algorithm "Indicates the cryptographic algorithm
associated with the key."; associated with the key.";
} }
} }
skipping to change at page 88, line 7 skipping to change at page 95, line 48
} }
description description
"Indicates whether IPv4, IPv6, or "Indicates whether IPv4, IPv6, or
both are to be activated."; both are to be activated.";
} }
leaf area-id { leaf area-id {
type yang:dotted-quad; type yang:dotted-quad;
mandatory true; mandatory true;
description description
"Area ID."; "Area ID.";
reference
"RFC 4577: OSPF as the Provider/Customer
Edge Protocol for BGP/MPLS IP
Virtual Private Networks
(VPNs), Section 4.2.3
RFC 6565: OSPFv3 as a Provider Edge to
Customer Edge (PE-CE) Routing
Protocol, Section 4.2";
} }
leaf metric { leaf metric {
type uint16; type uint16;
default "1"; default "1";
description description
"Metric of the PE-CE link. It is used "Metric of the PE-CE link. It is used
in the routing state calculation and in the routing state calculation and
path selection."; path selection.";
} }
container sham-links { container sham-links {
if-feature "vpn-common:rtg-ospf-sham-link"; if-feature "vpn-common:rtg-ospf-sham-link";
description description
"List of sham links."; "List of sham links.";
reference
"RFC 4577: OSPF as the Provider/Customer
Edge Protocol for BGP/MPLS IP
Virtual Private Networks
(VPNs), Section 4.2.7
RFC 6565: OSPFv3 as a Provider Edge to
Customer Edge (PE-CE) Routing
Protocol, Section 5";
list sham-link { list sham-link {
key "target-site"; key "target-site";
description description
"Creates a sham link with another site."; "Creates a sham link with another site.";
leaf target-site { leaf target-site {
type vpn-common:vpn-id; type vpn-common:vpn-id;
description description
"Target site for the sham link connection. "Target site for the sham link connection.
The site is referred to by its ID."; The site is referred to by its ID.";
} }
leaf metric { leaf metric {
type uint16; type uint16;
default "1"; default "1";
description description
"Metric of the sham link. It is used in "Metric of the sham link. It is used in
the routing state calculation and path the routing state calculation and path
selection. The default value is set selection. The default value is set
to 1."; to 1.";
reference
"RFC 4577: OSPF as the Provider/Customer
Edge Protocol for BGP/MPLS IP
Virtual Private Networks
(VPNs), Section 4.2.7.3
RFC 6565: OSPFv3 as a Provider Edge to
Customer Edge (PE-CE) Routing
Protocol, Section 5.2";
} }
} }
} }
leaf max-lsa { leaf max-lsa {
type uint32 { type uint32 {
range "1..4294967294"; range "1..4294967294";
} }
description description
"Maximum number of allowed LSAs OSPF."; "Maximum number of allowed LSAs OSPF.";
} }
skipping to change at page 89, line 29 skipping to change at page 97, line 47
leaf key-chain { leaf key-chain {
type key-chain:key-chain-ref; type key-chain:key-chain-ref;
description description
"key-chain name."; "key-chain name.";
} }
} }
case auth-key-explicit { case auth-key-explicit {
leaf key-id { leaf key-id {
type uint32; type uint32;
description description
"Key Identifier"; "Key identifier.";
} }
leaf key { leaf key {
type string; type string;
description description
"OSPF authentication key."; "OSPF authentication key.";
} }
leaf crypto-algorithm { leaf crypto-algorithm {
type identityref { type identityref {
base key-chain:crypto-algorithm; base key-chain:crypto-algorithm;
} }
description description
"Indicates the cryptographic algorithm "Indicates the cryptographic algorithm
associated with the key."; associated with the key.";
} }
} }
skipping to change at page 89, line 50 skipping to change at page 98, line 20
description description
"Indicates the cryptographic algorithm "Indicates the cryptographic algorithm
associated with the key."; associated with the key.";
} }
} }
case ipsec { case ipsec {
leaf sa { leaf sa {
type string; type string;
description description
"Indicates the name of the SA."; "Indicates the name of the SA.";
reference
"RFC 4552: Authentication
/Confidentiality for
OSPFv3";
} }
} }
} }
} }
} }
uses vpn-common:service-status; uses vpn-common:service-status;
} }
container isis { container isis {
when "derived-from-or-self(../type, " when "derived-from-or-self(../type, "
+ "'vpn-common:isis')" { + "'vpn-common:isis')" {
description description
"Only applies when protocol is IS-IS."; "Only applies when protocol is IS-IS.";
skipping to change at page 90, line 28 skipping to change at page 98, line 49
"IS-IS specific configuration."; "IS-IS specific configuration.";
leaf address-family { leaf address-family {
type identityref { type identityref {
base vpn-common:address-family; base vpn-common:address-family;
} }
description description
"Indicates whether IPv4, IPv6, or both "Indicates whether IPv4, IPv6, or both
are to be activated."; are to be activated.";
} }
leaf area-address { leaf area-address {
type yang:dotted-quad; type area-address;
mandatory true; mandatory true;
description description
"Area address."; "Area address.";
} }
leaf level { leaf level {
type identityref { type identityref {
base vpn-common:isis-level; base vpn-common:isis-level;
} }
description description
"Can be level1, level2, or level1-2."; "Can be level1, level2, or level1-2.";
} }
leaf metric { leaf metric {
type uint16; type uint16;
skipping to change at page 92, line 39 skipping to change at page 101, line 11
description description
"Configuration specific to RIP routing."; "Configuration specific to RIP routing.";
leaf address-family { leaf address-family {
type identityref { type identityref {
base vpn-common:address-family; base vpn-common:address-family;
} }
description description
"Indicates whether IPv4, IPv6, or both "Indicates whether IPv4, IPv6, or both
address families are to be activated."; address families are to be activated.";
} }
container timers {
description
"Indicates the RIP timers.";
reference
"RFC 2453: RIP Version 2";
leaf update-interval {
type uint16 {
range "1..32767";
}
units "seconds";
default "30";
description
"Indicates the RIP update time.
That is, the amount of time for which
routing updates are sent.";
}
leaf invalid-interval {
type uint16 {
range "1..32767";
}
units "seconds";
default "180";
description
"Is the interval before a route is declared
invalid after no updates are received.
This value is at least three times
the value for the update-interval
argument.";
}
leaf holddown-interval {
type uint16 {
range "1..32767";
}
units "seconds";
default "180";
description
"Specifies the interval before better routes
are released.";
}
leaf flush-interval {
type uint16 {
range "1..32767";
}
units "seconds";
default "180";
description
"Indicates the RIP flush timer. That is,
the amount of time that must elapse before
a route is removed from the routing
table.";
}
}
leaf default-metric {
type uint8 {
range "0..16";
}
default "1";
description
"Sets the default metric.";
}
container security {
description
"Authentication configuration.";
leaf enable {
type boolean;
default "false";
description
"Enables or disables authentication.";
}
container keying-material {
when "../enable = 'true'";
description
"Container for describing how a RIP
session is to be secured between a CE
and a PE.";
choice option {
description
"Specifies the authentication scheme.";
case auth-key-chain {
leaf key-chain {
type key-chain:key-chain-ref;
description
"key-chain name.";
}
}
case auth-key-explicit {
leaf key {
type string;
description
"RIP authentication key.";
}
leaf crypto-algorithm {
type identityref {
base key-chain:crypto-algorithm;
}
description
"Indicates the cryptographic algorithm
associated with the key.";
}
}
}
}
}
uses vpn-common:service-status; uses vpn-common:service-status;
} }
container vrrp { container vrrp {
when "derived-from-or-self(../type, " when "derived-from-or-self(../type, "
+ "'vpn-common:vrrp')" { + "'vpn-common:vrrp')" {
description description
"Only applies when protocol is VRRP."; "Only applies when protocol is VRRP.";
} }
if-feature "vpn-common:rtg-vrrp"; if-feature "vpn-common:rtg-vrrp";
description description
"Configuration specific to VRRP."; "Configuration specific to VRRP.";
reference
"RFC 5798: Virtual Router Redundancy Protocol
(VRRP) Version 3 for IPv4 and IPv6";
leaf address-family { leaf address-family {
type identityref { type identityref {
base vpn-common:address-family; base vpn-common:address-family;
} }
description description
"Indicates whether IPv4, IPv6, or both "Indicates whether IPv4, IPv6, or both
address families are to be enabled."; address families are to be enabled.";
} }
leaf vrrp-group { leaf vrrp-group {
type uint8 { type uint8 {
range "1..255"; range "1..255";
} }
description description
skipping to change at page 95, line 4 skipping to change at page 105, line 35
} }
} }
container authentication { container authentication {
presence "Enables BFD authentication"; presence "Enables BFD authentication";
description description
"Parameters for BFD authentication."; "Parameters for BFD authentication.";
leaf key-chain { leaf key-chain {
type key-chain:key-chain-ref; type key-chain:key-chain-ref;
description description
"Name of the key-chain."; "Name of the key-chain.";
} }
leaf meticulous { leaf meticulous {
type boolean; type boolean;
description description
"Enables meticulous mode."; "Enables meticulous mode.";
reference reference
"Section 6.7 of RFC 5880"; "RFC 5880: Bidirectional Forwarding
Detection (BFD), Section 6.7";
} }
} }
uses vpn-common:service-status; uses vpn-common:service-status;
} }
} }
container security { container security {
description description
"Site-specific security parameters."; "Site-specific security parameters.";
container encryption { container encryption {
if-feature "vpn-common:encryption"; if-feature "vpn-common:encryption";
skipping to change at page 96, line 42 skipping to change at page 107, line 26
type key-chain:key-chain-ref; type key-chain:key-chain-ref;
description description
"Customer-supplied key chain."; "Customer-supplied key chain.";
} }
} }
} }
} }
} }
container service { container service {
description description
"Service parameters on the attachment."; "Service parameters of the attachment.";
leaf input-bandwidth { leaf input-bandwidth {
type uint64; type uint64;
units "bps"; units "bps";
mandatory true; mandatory true;
description description
"From the customer site's perspective, the "From the customer site's perspective, the
service input bandwidth of the connection service input bandwidth of the connection
or download bandwidth from the SP to or download bandwidth from the SP to
the site."; the site.";
} }
leaf output-bandwidth { leaf output-bandwidth {
type uint64; type uint64;
units "bps"; units "bps";
mandatory true; mandatory true;
description description
"From the customer site's perspective, "From the customer site's perspective,
the service output bandwidth of the the service output bandwidth of the
connection or upload bandwidth from connection or upload bandwidth from
the site to the SP."; the site to the SP.";
skipping to change at page 99, line 19 skipping to change at page 109, line 51
is applied."; is applied.";
} }
} }
} }
} }
container carrierscarrier { container carrierscarrier {
if-feature "vpn-common:carrierscarrier"; if-feature "vpn-common:carrierscarrier";
description description
"This container is used when the customer "This container is used when the customer
provides MPLS-based services. This is provides MPLS-based services. This is
only used in the case of CsC (i.e., a only used in the case of CsC (i.e., a
customer builds an MPLSservice using an customer builds an MPLSservice using an
IP VPN to carry its traffic)."; IP VPN to carry its traffic).";
leaf signalling-type { leaf signalling-type {
type enumeration { type enumeration {
enum ldp { enum ldp {
description description
"Use LDP as the signalling protocol "Use LDP as the signalling protocol
between the PE and the CE. In this between the PE and the CE. In this
case, an IGP routing protocol must case, an IGP routing protocol must
also be activated."; also be activated.";
skipping to change at page 99, line 47 skipping to change at page 110, line 31
reference reference
"RFC 8277: Using BGP to Bind MPLS Labels "RFC 8277: Using BGP to Bind MPLS Labels
to Address Prefixes"; to Address Prefixes";
} }
} }
default "bgp"; default "bgp";
description description
"MPLS signalling type."; "MPLS signalling type.";
} }
} }
container ntp {
description
"Time synchronization may be needed in some
VPNs such as infrastructure and Management
VPNs. This container includes parameters to
enable NTP service.";
reference
"RFC 5905: Network Time Protocol Version 4:
Protocol and Algorithms
Specification";
leaf broadcast {
type enumeration {
enum client {
description
"The VPN node will listen to NTP broadcast
messages on this VPN network access.";
}
enum server {
description
"The VPN node will behave as a broadcast
server.";
}
}
description
"Indicates NTP broadcast mode to use for the
VPN network access.";
}
container auth-profile {
description
"Pointer to a local profile.";
leaf profile-id {
type string;
description
"A pointer to a local authentication
profile on the VPN node is provided.";
}
}
uses vpn-common:service-status;
}
container multicast { container multicast {
if-feature "vpn-common:multicast"; if-feature "vpn-common:multicast";
description description
"Multicast parameters for the network "Multicast parameters for the network
access."; access.";
leaf access-type { leaf access-type {
type enumeration { type enumeration {
enum receiver-only { enum receiver-only {
description description
"The peer site only has receivers."; "The peer site only has receivers.";
} }
enum source-only { enum source-only {
description description
"The peer site only has sources."; "The peer site only has sources.";
} }
skipping to change at page 103, line 26 skipping to change at page 114, line 49
description description
"Version of the MLD protocol."; "Version of the MLD protocol.";
} }
uses vpn-common:service-status; uses vpn-common:service-status;
} }
container pim { container pim {
when "../protocol-type = 'router'"; when "../protocol-type = 'router'";
if-feature "vpn-common:pim"; if-feature "vpn-common:pim";
description description
"Only applies when protocol type is PIM."; "Only applies when protocol type is PIM.";
leaf priority {
type uint8;
description
"PIM priority definition.";
}
leaf hello-interval { leaf hello-interval {
type uint8; type rt-types:timer-value-seconds16;
units "seconds";
default "30"; default "30";
description description
"PIM hello-messages interval."; "PIM hello-messages interval. If set to
'infinity' or 'not-set', no periodic
Hello messages are sent.";
reference
"RFC 7761: Protocol Independent Multicast -
Sparse Mode (PIM-SM): Protocol
Specification (Revised),
Section 4.11";
} }
leaf dr-priority { leaf dr-priority {
type uint16; type uint32;
default "1";
description description
"Value to increase or decrease the "Indicates the preference in the DR election
chances of a given DR being elected."; process. Numerically larger DR priority
allows a node to be elected as a DR.";
reference
"RFC 7761: Protocol Independent Multicast -
Sparse Mode (PIM-SM): Protocol
Specification (Revised),
Section 4.3.2";
} }
uses vpn-common:service-status; uses vpn-common:service-status;
} }
} }
} }
} }
} }
} }
} }
} }
skipping to change at page 104, line 4 skipping to change at page 115, line 36
} }
uses vpn-common:service-status; uses vpn-common:service-status;
} }
} }
} }
} }
} }
} }
} }
} }
} }
} }
} }
<CODE ENDS> <CODE ENDS>
9. IANA Considerations 9. Security Considerations
This document requests IANA to register the following URI in the "ns"
subregistry within the "IETF XML Registry" [RFC3688]:
URI: urn:ietf:params:xml:ns:yang:ietf-l3vpn-ntw
Registrant Contact: The IESG.
XML: N/A; the requested URI is an XML namespace.
This document requests IANA to register the following YANG module in
the "YANG Module Names" subregistry [RFC6020] within the "YANG
Parameters" registry.
name: ietf-l3vpn-ntw
namespace: urn:ietf:params:xml:ns:yang:ietf-l3vpn-ntw
maintained by IANA: N
prefix: l3nm
reference: RFC XXXX
10. Security Considerations
The YANG module specified in this document defines schema for data The YANG module specified in this document defines schema for data
that is designed to be accessed via network management protocols such that is designed to be accessed via network management protocols such
as NETCONF [RFC6241] or RESTCONF [RFC8040] . The lowest NETCONF layer as NETCONF [RFC6241] or RESTCONF [RFC8040] . The lowest NETCONF layer
is the secure transport layer, and the mandatory-to-implement secure is the secure transport layer, and the mandatory-to-implement secure
transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer
is HTTPS, and the mandatory-to-implement secure transport is TLS is HTTPS, and the mandatory-to-implement secure transport is TLS
[RFC8466]. [RFC8446].
The Network Configuration Access Control Model (NACM) [RFC8341] The Network Configuration Access Control Model (NACM) [RFC8341]
provides the means to restrict access for particular NETCONF or provides the means to restrict access for particular NETCONF or
RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or
RESTCONF protocol operations and content. RESTCONF protocol operations and content.
The "ietf-l3vpn-ntw" module is used to manage Layer 3 VPNs in a There are a number of data nodes defined in this YANG module that are
service provider backbone network. Hence, the module can be used to
request, modify, or retrieve L3VPN services. For example, the
creation of a 'vpn-service' leaf instance triggers the creation of an
L3VPN Service in a service provider network.
Due to the foreseen use of the "ietf-l3vpn-ntw" module, there are a
number of data nodes defined in the module that are
writable/creatable/deletable (i.e., config true, which is the writable/creatable/deletable (i.e., config true, which is the
default). These data nodes MAY be considered sensitive or vulnerable default). These data nodes may be considered sensitive or vulnerable
in some network environments. Write operations (e.g., edit-config) in some network environments. Write operations (e.g., edit-config)
and delete operations to these data nodes without proper protection and delete operations to these data nodes without proper protection
or authentication can have a negative effect on network operations. or authentication can have a negative effect on network operations.
These are the subtrees and data nodes and their sensitivity/ These are the subtrees and data nodes and their sensitivity/
vulnerability in the "ietf-l3vpn-ntw" module: vulnerability in the "ietf-l3vpn-ntw" module:
o 'vpn-service': An attacker who is able to access network nodes can o 'vpn-service': An attacker who is able to access network nodes can
undertake various attacks, such as deleting a running L3VPN undertake various attacks, such as deleting a running L3VPN
Service, interrupting all the traffic of a client. In addition, service, interrupting all the traffic of a client. In addition,
an attacker may modify the attributes of a running service (e.g., an attacker may modify the attributes of a running service (e.g.,
QoS, bandwidth, routing protocols), leading to malfunctioning of QoS, bandwidth, routing protocols), leading to malfunctioning of
the service and therefore to SLA violations. In addition, an the service and therefore to SLA violations. In addition, an
attacker could attempt to create a L3VPN Service or adding a new attacker could attempt to create an L3VPN service or adding a new
network access. Such activity can be detected by adequately network access. Such activity can be detected by adequately
monitoring and tracking network configuration changes. monitoring and tracking network configuration changes.
Some of the readable data nodes in the "ietf-l3vpn-ntw" module may be Some of the readable data nodes in this YANG module may be considered
considered sensitive or vulnerable in some network environments. It sensitive or vulnerable in some network environments. It is thus
is thus important to control read access (e.g., via get, get-config, important to control read access (e.g., via get, get-config, or
or notification) to these data nodes. These are the subtrees and notification) to these data nodes. These are the subtrees and data
data nodes and their sensitivity/vulnerability: nodes and their sensitivity/vulnerability:
o 'customer-name' and 'ip-connection': An attacker can retrieve o 'customer-name' and 'ip-connection': An attacker can retrieve
privacy-related information which can be used to track a customer. privacy-related information which can be used to track a customer.
Disclosing such information may be considered as a violation of Disclosing such information may be considered as a violation of
the customer-provider trust relationship. the customer-provider trust relationship.
The following summarizes the foreseen risks of using the "ietf-l3vpn- The following summarizes the foreseen risks of using the "ietf-l3vpn-
ntw" module can be classified into: ntw" module can be classified into:
o Malicious clients attempting to delete or modify VPN services. o Malicious clients attempting to delete or modify VPN services.
o Unauthorized clients attempting to create/modify/delete a VPN o Unauthorized clients attempting to create/modify/delete a VPN
service. service.
o Unauthorized clients attempting to read VPN service related o Unauthorized clients attempting to read VPN service related
information. information.
11. Acknowledgements 10. IANA Considerations
During the discussions of this work, helpful comments, suggestions,
and reviews were received from (listed alphabetically): Raul Arco,
Miguel Cros Cecilia, Joe Clarke, Adrian Farrel, Roque Gagliano,
Christian Jacquenet, Kireeti Kompella, and Julian Lucek. Many thanks
to them. Thanks to Philip Eardly for the review of an early version
of the document.
Daniel King, Daniel Voyer, Luay Jalil, and Stephane Litkowski
contributed to early version of the individual submission.
This work was supported in part by the European Commission funded
H2020-ICT-2016-2 METRO-HAUL project (G.A. 761727).
12. Contributors
Victor Lopez
Telefonica
Email: victor.lopezalvarez@telefonica.com
Qin Wu This document requests IANA to register the following URI in the "ns"
Huawei subregistry within the "IETF XML Registry" [RFC3688]:
Email: bill.wu@huawei.com>
Manuel Julian URI: urn:ietf:params:xml:ns:yang:ietf-l3vpn-ntw
Vodafone Registrant Contact: The IESG.
Email: manuel-julian.lopez@vodafone.com> XML: N/A; the requested URI is an XML namespace.
Lucia Oliva Ballega This document requests IANA to register the following YANG module in
Telefonica the "YANG Module Names" subregistry [RFC6020] within the "YANG
Email: lucia.olivaballega.ext@telefonica.com> Parameters" registry.
Erez Segev name: ietf-l3vpn-ntw
ECI Telecom namespace: urn:ietf:params:xml:ns:yang:ietf-l3vpn-ntw
Email: erez.segev@ecitele.com> maintained by IANA: N
prefix: l3nm
reference: RFC XXXX
13. References 11. References
13.1. Normative References 11.1. Normative References
[I-D.ietf-opsawg-vpn-common] [I-D.ietf-opsawg-vpn-common]
barguil, s., Dios, O., Boucadair, M., and Q. WU, "A Layer barguil, s., Dios, O., Boucadair, M., and Q. WU, "A Layer
2/3 VPN Common YANG Model", draft-ietf-opsawg-vpn- 2/3 VPN Common YANG Model", draft-ietf-opsawg-vpn-
common-03 (work in progress), January 2021. common-03 (work in progress), January 2021.
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5,
RFC 1112, DOI 10.17487/RFC1112, August 1989,
<https://www.rfc-editor.org/info/rfc1112>.
[RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080,
DOI 10.17487/RFC2080, January 1997,
<https://www.rfc-editor.org/info/rfc2080>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, [RFC2236] Fenner, W., "Internet Group Management Protocol, Version
DOI 10.17487/RFC2328, April 1998, 2", RFC 2236, DOI 10.17487/RFC2236, November 1997,
<https://www.rfc-editor.org/info/rfc2328>. <https://www.rfc-editor.org/info/rfc2236>.
[RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453,
DOI 10.17487/RFC2453, November 1998,
<https://www.rfc-editor.org/info/rfc2453>.
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast
Listener Discovery (MLD) for IPv6", RFC 2710,
DOI 10.17487/RFC2710, October 1999,
<https://www.rfc-editor.org/info/rfc2710>.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version
3", RFC 3376, DOI 10.17487/RFC3376, October 2002,
<https://www.rfc-editor.org/info/rfc3376>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004, DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>. <https://www.rfc-editor.org/info/rfc3688>.
[RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener
Discovery Version 2 (MLDv2) for IPv6", RFC 3810,
DOI 10.17487/RFC3810, June 2004,
<https://www.rfc-editor.org/info/rfc3810>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271, Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006, DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/info/rfc4271>. <https://www.rfc-editor.org/info/rfc4271>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
2006, <https://www.rfc-editor.org/info/rfc4364>. 2006, <https://www.rfc-editor.org/info/rfc4364>.
[RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality
for OSPFv3", RFC 4552, DOI 10.17487/RFC4552, June 2006, for OSPFv3", RFC 4552, DOI 10.17487/RFC4552, June 2006,
<https://www.rfc-editor.org/info/rfc4552>. <https://www.rfc-editor.org/info/rfc4552>.
[RFC4577] Rosen, E., Psenak, P., and P. Pillay-Esnault, "OSPF as the [RFC4577] Rosen, E., Psenak, P., and P. Pillay-Esnault, "OSPF as the
Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Provider/Customer Edge Protocol for BGP/MPLS IP Virtual
Private Networks (VPNs)", RFC 4577, DOI 10.17487/RFC4577, Private Networks (VPNs)", RFC 4577, DOI 10.17487/RFC4577,
June 2006, <https://www.rfc-editor.org/info/rfc4577>. June 2006, <https://www.rfc-editor.org/info/rfc4577>.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
<https://www.rfc-editor.org/info/rfc5340>.
[RFC5701] Rekhter, Y., "IPv6 Address Specific BGP Extended Community [RFC5701] Rekhter, Y., "IPv6 Address Specific BGP Extended Community
Attribute", RFC 5701, DOI 10.17487/RFC5701, November 2009, Attribute", RFC 5701, DOI 10.17487/RFC5701, November 2009,
<https://www.rfc-editor.org/info/rfc5701>. <https://www.rfc-editor.org/info/rfc5701>.
[RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., [RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M.,
Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic
Authentication", RFC 5709, DOI 10.17487/RFC5709, October Authentication", RFC 5709, DOI 10.17487/RFC5709, October
2009, <https://www.rfc-editor.org/info/rfc5709>. 2009, <https://www.rfc-editor.org/info/rfc5709>.
[RFC5798] Nadas, S., Ed., "Virtual Router Redundancy Protocol (VRRP) [RFC5798] Nadas, S., Ed., "Virtual Router Redundancy Protocol (VRRP)
Version 3 for IPv4 and IPv6", RFC 5798, Version 3 for IPv4 and IPv6", RFC 5798,
DOI 10.17487/RFC5798, March 2010, DOI 10.17487/RFC5798, March 2010,
<https://www.rfc-editor.org/info/rfc5798>. <https://www.rfc-editor.org/info/rfc5798>.
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
<https://www.rfc-editor.org/info/rfc5880>. <https://www.rfc-editor.org/info/rfc5880>.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<https://www.rfc-editor.org/info/rfc5905>.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", RFC 5925, DOI 10.17487/RFC5925, Authentication Option", RFC 5925, DOI 10.17487/RFC5925,
June 2010, <https://www.rfc-editor.org/info/rfc5925>. June 2010, <https://www.rfc-editor.org/info/rfc5925>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020, the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010, DOI 10.17487/RFC6020, October 2010,
<https://www.rfc-editor.org/info/rfc6020>. <https://www.rfc-editor.org/info/rfc6020>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
skipping to change at page 108, line 47 skipping to change at page 120, line 19
[RFC7166] Bhatia, M., Manral, V., and A. Lindem, "Supporting [RFC7166] Bhatia, M., Manral, V., and A. Lindem, "Supporting
Authentication Trailer for OSPFv3", RFC 7166, Authentication Trailer for OSPFv3", RFC 7166,
DOI 10.17487/RFC7166, March 2014, DOI 10.17487/RFC7166, March 2014,
<https://www.rfc-editor.org/info/rfc7166>. <https://www.rfc-editor.org/info/rfc7166>.
[RFC7474] Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, Ed., [RFC7474] Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, Ed.,
"Security Extension for OSPFv2 When Using Manual Key "Security Extension for OSPFv2 When Using Manual Key
Management", RFC 7474, DOI 10.17487/RFC7474, April 2015, Management", RFC 7474, DOI 10.17487/RFC7474, April 2015,
<https://www.rfc-editor.org/info/rfc7474>. <https://www.rfc-editor.org/info/rfc7474>.
[RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I.,
Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent
Multicast - Sparse Mode (PIM-SM): Protocol Specification
(Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March
2016, <https://www.rfc-editor.org/info/rfc7761>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016, RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>. <https://www.rfc-editor.org/info/rfc7950>.
[RFC7988] Rosen, E., Ed., Subramanian, K., and Z. Zhang, "Ingress
Replication Tunnels in Multicast VPN", RFC 7988,
DOI 10.17487/RFC7988, October 2016,
<https://www.rfc-editor.org/info/rfc7988>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>. <https://www.rfc-editor.org/info/rfc8040>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8177] Lindem, A., Ed., Qu, Y., Yeung, D., Chen, I., and J. [RFC8177] Lindem, A., Ed., Qu, Y., Yeung, D., Chen, I., and J.
Zhang, "YANG Data Model for Key Chains", RFC 8177, Zhang, "YANG Data Model for Key Chains", RFC 8177,
skipping to change at page 109, line 33 skipping to change at page 121, line 5
[RFC8294] Liu, X., Qu, Y., Lindem, A., Hopps, C., and L. Berger, [RFC8294] Liu, X., Qu, Y., Lindem, A., Hopps, C., and L. Berger,
"Common YANG Data Types for the Routing Area", RFC 8294, "Common YANG Data Types for the Routing Area", RFC 8294,
DOI 10.17487/RFC8294, December 2017, DOI 10.17487/RFC8294, December 2017,
<https://www.rfc-editor.org/info/rfc8294>. <https://www.rfc-editor.org/info/rfc8294>.
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
Access Control Model", STD 91, RFC 8341, Access Control Model", STD 91, RFC 8341,
DOI 10.17487/RFC8341, March 2018, DOI 10.17487/RFC8341, March 2018,
<https://www.rfc-editor.org/info/rfc8341>. <https://www.rfc-editor.org/info/rfc8341>.
[RFC8343] Bjorklund, M., "A YANG Data Model for Interface
Management", RFC 8343, DOI 10.17487/RFC8343, March 2018,
<https://www.rfc-editor.org/info/rfc8343>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[RFC8466] Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG [RFC8466] Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG
Data Model for Layer 2 Virtual Private Network (L2VPN) Data Model for Layer 2 Virtual Private Network (L2VPN)
Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October
2018, <https://www.rfc-editor.org/info/rfc8466>. 2018, <https://www.rfc-editor.org/info/rfc8466>.
[RFC8519] Jethanandani, M., Agarwal, S., Huang, L., and D. Blair, [RFC8519] Jethanandani, M., Agarwal, S., Huang, L., and D. Blair,
"YANG Data Model for Network Access Control Lists (ACLs)", "YANG Data Model for Network Access Control Lists (ACLs)",
RFC 8519, DOI 10.17487/RFC8519, March 2019, RFC 8519, DOI 10.17487/RFC8519, March 2019,
<https://www.rfc-editor.org/info/rfc8519>. <https://www.rfc-editor.org/info/rfc8519>.
13.2. Informative References 11.2. Informative References
[I-D.evenwu-opsawg-yang-composed-vpn] [I-D.evenwu-opsawg-yang-composed-vpn]
Even, R., Bo, W., Wu, Q., and Y. Cheng, "YANG Data Model Even, R., Bo, W., Wu, Q., and Y. Cheng, "YANG Data Model
for Composed VPN Service Delivery", draft-evenwu-opsawg- for Composed VPN Service Delivery", draft-evenwu-opsawg-
yang-composed-vpn-03 (work in progress), March 2019.