rfc9182.original   rfc9182.txt 
OPSAWG S. Barguil Internet Engineering Task Force (IETF) S. Barguil
Internet-Draft O. Gonzalez de Dios, Ed. Request for Comments: 9182 O. Gonzalez de Dios, Ed.
Intended status: Standards Track Telefonica Category: Standards Track Telefonica
Expires: 11 April 2022 M. Boucadair, Ed. ISSN: 2070-1721 M. Boucadair, Ed.
Orange Orange
L. Munoz L. Munoz
Vodafone Vodafone
A. Aguado A. Aguado
Nokia Nokia
8 October 2021 February 2022
A Layer 3 VPN Network YANG Model A YANG Network Data Model for Layer 3 VPNs
draft-ietf-opsawg-l3sm-l3nm-18
Abstract Abstract
As a complement to the Layer 3 Virtual Private Network Service YANG As a complement to the Layer 3 Virtual Private Network Service Model
data Model (L3SM), used for communication between customers and (L3SM), which is used for communication between customers and service
service providers, this document defines an L3VPN Network YANG Model providers, this document defines an L3VPN Network Model (L3NM) that
(L3NM) that can be used for the provisioning of Layer 3 Virtual can be used for the provisioning of Layer 3 Virtual Private Network
Private Network (VPN) services within a service provider network. (L3VPN) services within a service provider network. The model
The model provides a network-centric view of L3VPN services. provides a network-centric view of L3VPN services.
L3NM is meant to be used by a network controller to derive the 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 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)
Please update these statements within the document with the RFC
number to be assigned to this document:
* "This version of this YANG module is part of RFC XXXX;"
* "RFC XXXX: Layer 3 VPN Network Model";
* 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.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 11 April 2022. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9182.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2022 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Simplified BSD License text to this document. Code Components extracted from this document must
as described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Simplified BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology
3. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Acronyms and Abbreviations
4. L3NM Reference Architecture . . . . . . . . . . . . . . . . . 7 4. L3NM Reference Architecture
5. Relation with other YANG Models . . . . . . . . . . . . . . . 11 5. Relationship to Other YANG Data Models
6. Sample Uses of the L3NM Data Model . . . . . . . . . . . . . 12 6. Sample Uses of the L3NM Data Model
6.1. Enterprise Layer 3 VPN Services . . . . . . . . . . . . . 12 6.1. Enterprise Layer 3 VPN Services
6.2. Multi-Domain Resource Management . . . . . . . . . . . . 13 6.2. Multi-Domain Resource Management
6.3. Management of Multicast Services . . . . . . . . . . . . 13 6.3. Management of Multicast Services
7. Description of the L3NM YANG Module . . . . . . . . . . . . . 13 7. Description of the L3NM YANG Module
7.1. Overall Structure of the Module . . . . . . . . . . . . . 14 7.1. Overall Structure of the Module
7.2. VPN Profiles . . . . . . . . . . . . . . . . . . . . . . 15 7.2. VPN Profiles
7.3. VPN Services . . . . . . . . . . . . . . . . . . . . . . 16 7.3. VPN Services
7.4. VPN Instance Profiles . . . . . . . . . . . . . . . . . . 20 7.4. VPN Instance Profiles
7.5. VPN Nodes . . . . . . . . . . . . . . . . . . . . . . . . 22 7.5. VPN Nodes
7.6. VPN Network Accesses . . . . . . . . . . . . . . . . . . 25 7.6. VPN Network Accesses
7.6.1. Connection . . . . . . . . . . . . . . . . . . . . . 28 7.6.1. Connection
7.6.2. IP Connection . . . . . . . . . . . . . . . . . . . . 30 7.6.2. IP Connection
7.6.3. CE-PE Routing Protocols . . . . . . . . . . . . . . . 33 7.6.3. CE-PE Routing Protocols
7.6.3.1. Static Routing . . . . . . . . . . . . . . . . . 35 7.6.3.1. Static Routing
7.6.3.2. BGP . . . . . . . . . . . . . . . . . . . . . . . 37 7.6.3.2. BGP
7.6.3.3. OSPF . . . . . . . . . . . . . . . . . . . . . . 40 7.6.3.3. OSPF
7.6.3.4. IS-IS . . . . . . . . . . . . . . . . . . . . . . 42 7.6.3.4. IS-IS
7.6.3.5. RIP . . . . . . . . . . . . . . . . . . . . . . . 44 7.6.3.5. RIP
7.6.3.6. VRRP . . . . . . . . . . . . . . . . . . . . . . 45 7.6.3.6. VRRP
7.6.4. OAM . . . . . . . . . . . . . . . . . . . . . . . . . 47 7.6.4. OAM
7.6.5. Security . . . . . . . . . . . . . . . . . . . . . . 48 7.6.5. Security
7.6.6. Services . . . . . . . . . . . . . . . . . . . . . . 49 7.6.6. Services
7.6.6.1. Overview . . . . . . . . . . . . . . . . . . . . 49 7.6.6.1. Overview
7.6.6.2. QoS . . . . . . . . . . . . . . . . . . . . . . . 50 7.6.6.2. QoS
7.7. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 55 7.7. Multicast
8. L3NM YANG Module . . . . . . . . . . . . . . . . . . . . . . 59 8. L3NM YANG Module
9. Security Considerations . . . . . . . . . . . . . . . . . . . 121 9. Security Considerations
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 122 10. IANA Considerations
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 123 11. References
11.1. Normative References . . . . . . . . . . . . . . . . . . 123 11.1. Normative References
11.2. Informative References . . . . . . . . . . . . . . . . . 127 11.2. Informative References
Appendix A. L3VPN Examples . . . . . . . . . . . . . . . . . . . 132 Appendix A. L3VPN Examples
A.1. 4G VPN Provisioning Example . . . . . . . . . . . . . . . 132 A.1. 4G VPN Provisioning Example
A.2. Loopback Interface . . . . . . . . . . . . . . . . . . . 137 A.2. Loopback Interface
A.3. Overriding VPN Instance Profile Parameters . . . . . . . 138 A.3. Overriding VPN Instance Profile Parameters
A.4. Multicast VPN Provisioning Example . . . . . . . . . . . 141 A.4. Multicast VPN Provisioning Example
Appendix B. Implementation Status . . . . . . . . . . . . . . . 145 Acknowledgements
B.1. Nokia Implementation . . . . . . . . . . . . . . . . . . 145 Contributors
B.2. Huawei Implementation . . . . . . . . . . . . . . . . . . 145 Authors' Addresses
B.3. Infinera Implementation . . . . . . . . . . . . . . . . . 145
B.4. Ribbon-ECI Implementation . . . . . . . . . . . . . . . . 145
B.5. Juniper Implementation . . . . . . . . . . . . . . . . . 146
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 146
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 146
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 147
1. Introduction 1. Introduction
[RFC8299] defines a Layer 3 Virtual Private Network Service YANG data [RFC8299] defines a YANG Layer 3 Virtual Private Network Service
Model (L3SM) that can be used for communication between customers and Model (L3SM) that can be used for communication between customers and
service providers. Such a model focuses on describing the customer service providers. Such a model focuses on describing the customer
view of the Virtual Private Network (VPN) services and provides an 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 the "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 and the network communication between the service orchestrator and the network
controller/orchestrator by allowing for more network-centric controller/orchestrator by allowing more network-centric information
information to be included. It enables further capabilities such as to be included. It enables such additional capabilities as resource
resource management or serves as a multi-domain orchestration management, or it serves as a multi-domain orchestration interface
interface, where logical resources (such as route targets or route where logical resources (such as 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 [RFC9181].
[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 was 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 point 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- the L3SM, because a specific structure is required to meet network-
oriented L3 needs. oriented L3 needs.
Some information captured in the L3SM can be passed by the Some information captured in the L3SM can be passed by the
orchestrator in the L3NM (e.g., customer) or be used to feed some orchestrator in the L3NM (e.g., customer) or be used to feed some
L3NM attributes (e.g., actual forwarding policies). Also, some L3NM attributes (e.g., actual forwarding policies). Also, some
information captured in the L3SM may be maintained locally within the information captured in the L3SM may be maintained locally within the
orchestrator; which is in charge of maintaining the correlation orchestrator, which is in charge of maintaining the correlation
between a customer view and its network instantiation. Likewise, between a customer view and its network instantiation. Likewise,
some information captured and exposed using the L3NM can feed the some information captured and exposed using the L3NM can feed the
service layer (e.g., capabilities) to drive VPN service order 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 L3VPN connectivity is supported through the coordination
coordination of different VPNs in different underlying networks. of different VPNs in different underlying networks. More complex
More complex deployment scenarios involving the coordination of deployment scenarios involving the coordination of different VPN
different VPN instances and different technologies to provide an end- instances and different technologies to provide end-to-end VPN
to-end VPN connectivity are addressed by complementary YANG modules, connectivity are addressed by complementary YANG modules, e.g.,
e.g., [I-D.evenwu-opsawg-yang-composed-vpn]. [YANG-Composed-VPN].
The L3NM focuses on BGP Provider Edge (PE) based Layer 3 VPNs as The L3NM focuses on Layer 3 VPNs based on BGP Provider Edges (PEs) as
described in [RFC4026][RFC4110][RFC4364] and Multicast VPNs as described in [RFC4026], [RFC4110], and [RFC4364]; and Multicast VPNs
described in [RFC6037][RFC6513]. as described in [RFC6037] and [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
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
This document assumes that the reader is familiar with the contents This document assumes that the reader is familiar with the contents
of [RFC6241], [RFC7950], [RFC8299], [RFC8309], and [RFC8453] and uses of [RFC6241], [RFC7950], [RFC8299], [RFC8309], and [RFC8453] and uses
the terminology defined in those documents. the terminology defined in those documents.
This document uses the term "network model" defined in Section 2.1 of This document uses the term "network model" as defined in Section 2.1
[RFC8969]. of [RFC8969].
The meaning of the symbols in the tree diagrams is defined in The meanings of the symbols in the tree diagrams are 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 Service Model (L3SM): A YANG data model that describes
describes the service requirements of an L3VPN that interconnects the service requirements of an L3VPN that interconnects a set of
a set of sites from the point of view of the customer. The sites from the point of view of the customer. The customer
customer service model does not provide details on the service service model does not provide details on the service provider
provider network. The L3VPN customer service model is defined in 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 Network Model (L3NM): A YANG data model that describes a
describes a VPN service in the service provider network. It VPN service in the service provider network. It contains
contains information of the service provider network and might information on the service provider network and might include
include allocated resources. It can be used by network allocated resources. It can be used by network controllers to
controllers to manage and control the VPN service configuration in manage and control the VPN service configuration in the service
the service provider network. The YANG module can be consumed by provider network. The corresponding YANG module can be used by a
a service orchestrator to request a VPN service to a network 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 an 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
for the Customer Edge (CE) - Provider Edge (PE) attachment for the Customer Edge to Provider Edge (CE-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
controllers. A network orchestrator can manage one or several controllers. A network orchestrator can manage one or several
network controllers. 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 belonging 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 decide how to implement a VPN node. For
example, typically, in a BGP-based VPN, a VPN node could be mapped example, in a BGP-based VPN, a VPN node could typically be mapped
into a Virtual Routing and Forwarding (VRF). to a Virtual Routing and Forwarding (VRF) instance.
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 with 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 when maintained to allow keeping the link between the L3SM and L3NM
both models are used in a given deployment. when both models are used in a given deployment.
VPN site: A VPN customer's location that is connected to the service VPN site: A VPN customer's location that is connected to the service
provider network via a CE-PE link, which can access at least one provider network via a CE-PE link, which can access at least one
VPN [RFC4176]. 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.
The document is aimed at modeling BGP PE-based VPNs in a service This document is aimed at modeling BGP PE-based VPNs in a service
provider network, so the terms defined in [RFC4026] and [RFC4176] are provider network, so the terms defined in [RFC4026] and [RFC4176] are
used. used in this document as well.
3. Acronyms 3. Acronyms and Abbreviations
The following acronyms are used in the document: The following acronyms and abbreviations are used in this 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
BFD Bidirectional Forwarding Detection BFD Bidirectional Forwarding Detection
BGP Border Gateway Protocol BGP Border Gateway Protocol
BSR Bootstrap Router
CE Customer Edge CE Customer Edge
CsC Carriers' Carriers CsC Carriers' Carriers
IGMP Internet Group Management Protocol IGMP Internet Group Management Protocol
L3VPN Layer 3 Virtual Private Network
L3SM L3VPN Service Model
L3NM L3VPN Network Model L3NM L3VPN Network Model
L3SM L3VPN Service Model
L3VPN Layer 3 Virtual Private Network
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
PIM Protocol Independent Multicast PIM Protocol Independent Multicast
QoS Quality of Service QoS Quality of Service
RD Route Distinguisher RD Route Distinguisher
skipping to change at page 7, line 31 skipping to change at line 284
SA Security Association SA Security Association
SSM Source-Specific Multicast SSM Source-Specific Multicast
VPN Virtual Private Network VPN Virtual Private Network
VRF Virtual Routing and Forwarding VRF Virtual Routing and Forwarding
4. L3NM Reference Architecture 4. L3NM Reference Architecture
Figure 1 depicts the reference architecture for the L3NM. The figure Figure 1 depicts the reference architecture for the L3NM. The figure
is an expansion of the architecture presented in Section 5 of is an expansion of the architecture presented in Section 5 of
[RFC8299]; it decomposes the box marked "orchestration" in that [RFC8299]; it decomposes the box marked "orchestration" in that
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 a 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
modules that reflect network-related information. Such information modules that reflect network-related information. Such information
is hidden to customers. is hidden from customers.
The intelligence for translating customer-facing information into The intelligence for translating customer-facing information into
network-centric one (and vice versa) is implementation specific. network-centric information (and vice versa) is implementation
specific.
The terminology from [RFC8309] is introduced to show the distinction The terminology from [RFC8309] is used here 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 |
+-------+-------+ +-------+-------+
Service Delivery Model | Service Delivery 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
NETCONF: Network Configuration Protocol
CLI: Command-Line Interface
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 an L3NM. The customer may use the L3SM trigger the instantiation of an L3NM. The customer may use the L3SM
or more abstract models to request a service that relies upon an or more abstract models to request a service that relies upon an
L3VPN service. For example, the customer may supply an IP L3VPN service. For example, the customer may supply an IP
Connectivity Provisioning Profile (CPP) that characterizes the Connectivity Provisioning Profile (CPP) that characterizes the
requested service [RFC7297], an enhanced VPN (VPN+) service requested service [RFC7297], an enhanced VPN (VPN+) service
[I-D.ietf-teas-enhanced-vpn], or an IETF network slice service [Enhanced-VPN-Framework], or an IETF network slice service
[I-D.ietf-teas-ietf-network-slices]. [Network-Slices-Framework].
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 Abstraction and Control of TE Networks (ACTN) Framework of the Abstraction and Control of TE Networks (ACTN) framework
[RFC8453]. Figure 2 shows the Customer Network Controller (CNC), the [RFC8453]. Figure 2 shows the Customer Network Controller (CNC), the
Multi-Domain Service Coordinator (MDSC), and the Provisioning Network Multi-Domain Service Coordinator (MDSC), the Provisioning Network
Controller (PNC) components and the interfaces where L3SM/L3NM are Controller (PNC) components, and the interfaces where the L3SM and
used. 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 the ACTN
5. Relation with other YANG Models 5. Relationship to Other YANG Data Models
The "ietf-vpn-common" module [I-D.ietf-opsawg-vpn-common] includes a The "ietf-vpn-common" module [RFC9181] includes a set of identities,
set of identities, types, and groupings that are meant to be reused types, and groupings that are meant to be reused by VPN-related YANG
by VPN-related YANG modules independently of the layer (e.g., Layer modules independently of the layer (e.g., Layer 2, Layer 3) and the
2, Layer 3) and the type of the module (e.g., network model, service type of the module (e.g., network model, service model), including
model) including future revisions of existing models (e.g., [RFC8299] future revisions of existing models (e.g., [RFC8299] or [RFC8466]).
or [RFC8466]). The L3NM reuses these common types and groupings. The L3NM reuses these common types and groupings.
In order to avoid data duplication and to ease passing data between In order to avoid data duplication and to ease passing data between
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 the L3NM depends on the L3SM,
is not the case. For example, a service provider may decide to use while this is not the case. For example, a service provider may
the L3NM to build its L3VPN services without exposing the L3SM. decide to use 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 a 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: items below discuss how the L3NM interfaces with other YANG modules:
L3SM: L3NM is not a customer service model. L3SM: The 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., the L3NM) may be mapped to
external view which is visible to customers: L3VPN Service YANG an external view that is visible to customers: the L3VPN Service
data Model (L3SM) [RFC8299]. 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 an L3SM template. Concretely, some parts Such requests typically rely upon an L3SM template. Concretely,
of the L3SM module can be directly mapped into L3NM while other some parts of the L3SM module can be directly mapped to the L3NM,
parts are generated as a function of the requested service and while other parts are generated as a function of the requested
local guidelines. Some other parts are local to the service service and local guidelines. Some other parts are local to the
provider and do not map directly to L3SM. service provider and do not map directly to the L3SM.
Note that the use of L3NM within a service provider does not Note that using the L3NM within a service provider does not
assume nor preclude exposing the VPN service via the L3SM. This assume, nor does it preclude, exposing the VPN service via the
is deployment-specific. Nevertheless, the design of L3NM tries to L3SM. This is deployment specific. Nevertheless, the design of
align as much as possible with the features supported by the L3SM the L3NM tries to align as much as possible with the features
to ease grafting both L3NM and L3SM for the sake of highly supported by the L3SM to ease the grafting of both the L3NM and
automated VPN service provisioning and delivery. the L3SM for the sake of highly automated VPN service provisioning
and delivery.
Network Topology Modules: An 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. The topology topology managed by the service provider network. The topology
can be represented using the network topology YANG module defined can be represented using the network topology YANG module defined
in [RFC8345] or its extension such as a User-Network Interface in [RFC8345] or its extension, such as a network YANG module for
(UNI) topology module (e.g., [I-D.ogondio-opsawg-uni-topology]). Service Attachment Points (SAPs) [YANG-SAPs].
Device Modules: L3NM is not a device model. Device Modules: The 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 the L3NM, the
activation and provisioning of the VPN service will involve a actual activation and provisioning of the VPN service will involve
variety of device modules to tweak the required functions for the a variety of device modules to tweak the required functions for
delivery of the service. These functions are supported by the VPN the delivery of the service. These functions are supported by the
nodes and can be managed using device YANG modules. A non- VPN nodes and can be managed using device YANG modules. A non-
comprehensive list of such device YANG modules is provided below: comprehensive list of such device YANG modules is provided below:
* Routing management [RFC8349]. * Routing management [RFC8349].
* BGP [I-D.ietf-idr-bgp-model]. * BGP [BGP-YANG].
* PIM [I-D.ietf-pim-yang]. * PIM [PIM-YANG].
* NAT management [RFC8512]. * NAT management [RFC8512].
* QoS management [I-D.ietf-rtgwg-qos-model]. * QoS management [QoS-YANG].
* ACLs [RFC8519]. * ACLs [RFC8519].
How L3NM is used to derive device-specific actions is How the L3NM is used to derive device-specific actions is
implementation-specific. implementation specific.
6. Sample Uses of the L3NM Data Model 6. Sample Uses of the L3NM Data Model
This section provides a non-exhaustive list of examples to illustrate This section provides a non-exhaustive list of examples that
contexts where the L3NM can be used. illustrate contexts where the L3NM can be used.
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 therefore, L3NM can be useful for automating 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, but some manual Defined Networking (SDN) layer [RFC7149] [RFC7426], but some manual
intervention will still be required. intervention will still be required.
A common function that is supported by VPNs is the addition or A common function that is supported by VPNs is the addition or
removal of VPN nodes. Workflows can use the L3NM in these scenarios removal of VPN nodes. Workflows can use the L3NM in these scenarios
to add or prune nodes from the network data model as required. 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 that span administratively
administratively separated domains (i.e., that are under the separated domains (i.e., that are under the administration of
administration of different management systems or controllers) different management systems or controllers) requires some network
requires some network resources to be synchronized between systems. resources to be synchronized between systems. Particularly,
Particularly, resources must be adequately managed in each domain to resources must be adequately managed in each domain to avoid broken
avoid broken configuration. configurations.
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 multiple management systems, the task of
of allocating RTs has to be aligned across the domains, therefore, allocating RTs has to be aligned across the domains; therefore, the
the network model must provide a way to specify RTs. In addition, network model must provide a way to specify RTs. In addition, route
route distinguishers (RDs) must also be synchronized to avoid distinguishers (RDs) must also be synchronized to avoid collisions of
collisions in RD allocation between separate management systems. An RD allocations between separate management systems. An incorrect
incorrect allocation might lead to the same RD and IP prefixes being allocation might lead to the same RD and IP prefixes being exported
exported by different PEs. 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 L3VPNs can be implemented using dual PIM
(also known as, Draft Rosen model) [RFC6037] or Multiprotocol BGP MVPNs (also known as the draft-rosen model) [RFC6037] or MVPNs based
(MP-BGP)-based MVPNs [RFC6513][RFC6514]. Both methods are supported on Multiprotocol BGP (MP-BGP) [RFC6513] [RFC6514]. Both methods are
and equally effective, but the main difference is that MBGP-based supported and equally effective, but the main difference is that MP-
MVPN does not require multicast configuration on the service provider BGP-based MVPNs do not require multicast configuration on the service
network. MBGP MVPNs employ the intra-autonomous system BGP control provider network. MP-BGP MVPNs employ the intra-AS BGP control plane
plane and PIM sparse mode as the data plane. The PIM state and PIM Sparse Mode [RFC7761] 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, [RFC6037] 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 to maintain state in the backbone.
Because of these limitations, MBGP MVPN is the architectural model Because of these limitations, MP-BGP MVPNs provide the architectural
that has been taken as the base for implementing multicast service in model that has been taken as the base for implementing multicast
L3VPNs. In this scenario, BGP is used to auto-discover MVPN PE services in L3VPNs. In this scenario, BGP is used to autodiscover
members and the customer PIM signaling is sent across the provider's MVPN PE members and the customer PIM signaling is sent across the
core through MP-BGP. The multicast traffic is transported on MPLS provider's core through MP-BGP. The multicast traffic is transported
P2MP LSPs. on MPLS Point-to-Multipoint (P2MP) Label Switched Paths (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
for the reader's convenience. for the reader's convenience.
7.1. Overall Structure of the Module 7.1. Overall Structure of the Module
The 'ietf-l3vpn-ntw' module uses two main containers: 'vpn-services' The "ietf-l3vpn-ntw" module uses two main containers: 'vpn-profiles'
and 'vpn-profiles' (see Figure 3). and 'vpn-services' (see Figure 3).
The 'vpn-profiles' container is used by the provider to maintain a The 'vpn-profiles' container is used by the provider to maintain a
set of common VPN profiles that apply to one or several VPN services set of common VPN profiles that apply to one or several VPN services
(Section 7.2). (Section 7.2).
The 'vpn-services' container maintains the set of VPN services The 'vpn-services' container maintains the set of VPN services
managed within the service provider network. 'vpn-service' is the managed within the service provider network. The 'vpn-service' is
data structure that abstracts a VPN service (Section 7.3). the data structure that abstracts a VPN service (Section 7.3).
module: ietf-l3vpn-ntw module: ietf-l3vpn-ntw
+--rw l3vpn-ntw +--rw l3vpn-ntw
+--rw vpn-profiles +--rw vpn-profiles
| ... | ...
+--rw vpn-services +--rw vpn-services
+--rw vpn-service* [vpn-id] +--rw vpn-service* [vpn-id]
... ...
+--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]
... ...
Figure 3: Overall L3NM Tree Structure Figure 3: Overall L3NM Tree Structure
Some of the data nodes are keyed by the address-family. For the sake Some of the data nodes are keyed by the address family. For the sake
of data representation compactness, It is RECOMMENDED to use the of data representation compactness, it is RECOMMENDED to use the
dual-stack address-family for data nodes that have the same value for dual-stack address family for data nodes that have the same value for
both IPv4 and IPv6. If, for some reasons, a data node is present for both IPv4 and IPv6. If, for some reason, a data node is present for
both dual-stack and IPv4 (or IPv6), the value that is indicated under both dual-stack and IPv4 (or IPv6), the value that is indicated under
dual-stack takes precedence over the one that is indicated under IPv4 dual-stack takes precedence over the value that is indicated under
(or IPv6). IPv4 (or IPv6).
7.2. VPN Profiles 7.2. VPN Profiles
The 'vpn-profiles' container (Figure 4) allows the VPN service The 'vpn-profiles' container (Figure 4) allows the VPN service
provider to define and maintain a set of VPN profiles provider to define and maintain a set of VPN profiles [RFC9181] that
[I-D.ietf-opsawg-vpn-common] that apply to one or several VPN apply to one or several VPN services.
services.
+--rw l3vpn-ntw +--rw l3vpn-ntw
+--rw vpn-profiles +--rw vpn-profiles
| +--rw valid-provider-identifiers | +--rw valid-provider-identifiers
| +--rw external-connectivity-identifier* [id] | +--rw external-connectivity-identifier* [id]
| | {external-connectivity}? | | {external-connectivity}?
| | +--rw id string | | +--rw id string
| +--rw encryption-profile-identifier* [id] | +--rw encryption-profile-identifier* [id]
| | +--rw id string | | +--rw id string
| +--rw qos-profile-identifier* [id] | +--rw qos-profile-identifier* [id]
| | +--rw id string | | +--rw id string
| +--rw bfd-profile-identifier* [id] | +--rw bfd-profile-identifier* [id]
| | +--rw id string | | +--rw id string
| +--rw forwarding-profile-identifier* [id] | +--rw forwarding-profile-identifier* [id]
| | +--rw id string | | +--rw id string
| +--rw routing-profile-identifier* [id] | +--rw routing-profile-identifier* [id]
| +--rw id string | +--rw id string
+--rw vpn-services +--rw vpn-services
... ...
Figure 4: VPN Profiles Subtree Structure Figure 4: VPN Profiles Subtree Structure
This document does not make any assumption about the exact definition This document does not make any assumption about the exact definition
of these profiles. The exact definition of the profiles is local to of these profiles. The exact definition of the profiles is local to
each VPN service provider. The model only includes an identifier to each VPN service provider. The model only includes an identifier for
these profiles in order to facilitate identifying and binding local these profiles in order to facilitate identifying and binding local
policies when building a VPN service. As shown in Figure 4, the 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). External connectivity may be
be an access to the Internet or a restricted connectivity such as access to the Internet or restricted connectivity, such as access
access to a public/private cloud. 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 schemes 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 a set of policies such as classification, marking, and actions to a 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 policies [RFC5880] that can be
invoked when building a VPN service. invoked when building a VPN service.
'forwarding-profile-identifier': A forwarding profile refers to the 'forwarding-profile-identifier': A forwarding profile refers to the
policies that apply to the forwarding of packets conveyed within a policies that apply to the forwarding of packets conveyed within a
VPN. Such policies may consist, for example, of applying Access VPN. Such policies may consist, for example, of applying Access
Control Lists (ACLs). Control Lists (ACLs).
'routing-profile-identifier': A routing profile refers to a set of 'routing-profile-identifier': A routing profile refers to a set of
routing policies that will be invoked (e.g., BGP policies) when routing policies that will be invoked (e.g., BGP policies) when
delivering the VPN service. delivering the VPN service.
7.3. VPN Services 7.3. VPN Services
The 'vpn-service' is the data structure that abstracts a VPN service The 'vpn-service' is the data structure that abstracts a VPN service
in the service provider network. 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 a 'vpn-id' is only
meaningful locally (e.g., the network controller). The subtree of meaningful locally (e.g., the network controller). The subtree of
the 'vpn-services' is shown in Figure 5. the '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-common: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-change? yang:date-and-time | | +--rw last-change? yang:date-and-time
| +--ro oper-status | +--ro oper-status
| +--ro status? identityref | +--ro status? identityref
| +--ro last-change? yang:date-and-time | +--ro last-change? yang:date-and-time
+--rw vpn-instance-profiles +--rw vpn-instance-profiles
| ... | ...
+--rw underlay-transport +--rw underlay-transport
| +-- (type)? | +-- (type)?
| +--:(abstract) | +--:(abstract)
| | +-- transport-instance-id? string | | +--rw transport-instance-id? string
| +--:(protocol) | | +--rw instance-type? identityref
| +-- protocol* identityref | +--:(protocol)
+--rw external-connectivity | +--rw protocol* identityref
| {external-connectivity} +--rw external-connectivity
| +--rw (profile)? | {vpn-common:external-connectivity}?
| +--:(profile) | +--rw (profile)?
| +--rw profile-name? leafref | +--:(profile)
+--rw vpn-nodes | +--rw profile-name? leafref
... +--rw vpn-nodes
...
Figure 5: VPN Services Subtree Structure Figure 5: VPN Services Subtree Structure
The description of the VPN service data nodes that are depicted in The descriptions of the VPN service data nodes that are depicted in
Figure 5 are as follows: Figure 5 are as follows:
'vpn-id': Is an identifier that is used to uniquely identify the 'vpn-id': An identifier that is used to uniquely identify the L3VPN
L3VPN service within L3NM scope. service within the L3NM scope.
'vpn-name': Associates a name with the service in order to 'vpn-name': Associates a name with the service in order to
facilitate the identification of the service. facilitate the identification of the service.
'vpn-description': Includes a textual description of the service. 'vpn-description': Includes a textual description of the service.
The internal structure of a VPN description is local to each VPN The internal structure of a VPN description is local to each VPN
service provider. service provider.
'customer-name': Indicates the name of the customer who ordered the 'customer-name': Indicates the name of the customer who ordered the
service. service.
'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 [RFC9181]. For the L3NM, this is typically set to "BGP/MPLS
to BGP/MPLS L3VPN, but other values may be defined in the future L3VPN", but other values may be defined to support specific Layer
to support specific Layer 3 VPN capabilities (e.g., 3 VPN capabilities (e.g., [RFC9136]).
[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 targets (Section 4.3.5 of [RFC4364]).
'status': Is used to track the service status of a given VPN 'status': Used to track the service status of a given VPN service.
service. Both operational and administrative status are Both operational status and administrative status are maintained
maintained together with a timestamp. For example, a service can together with a timestamp. For example, a service can be created
be created, but not put into effect. but not put into effect.
Administrative and operational status can be used as a trigger to Administrative status and operational status can be used as a
detect service anomalies. For example, a service that is declared trigger to detect service anomalies. For example, a service that
at the service layer as being active but still inactive at the is declared active at the service layer but is still inactive at
network layer may be an indication that network provision actions the network layer may be an indication that network provision
are needed to align the observed service status with the expected actions are needed to align the observed service status with the
service status. expected service status.
'vpn-instance-profiles': Defines reusable parameters 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
identifier, or a network slice name) or as an ordered list of the identifier, or a network slice name) or as an ordered list of the
actual protocols to be enabled in the network. actual protocols to be enabled in the network.
A rich set of protocol identifiers that can be used to refer to an A rich set of protocol identifiers that can be used to refer to an
underlay transport are defined in [I-D.ietf-opsawg-vpn-common]. underlay transport are defined in [RFC9181].
'external-connectivity': Indicates whether/how external connectivity 'external-connectivity': Indicates whether/how external connectivity
is provided to the VPN service. For example, a service provider is provided to the VPN service. For example, a service provider
may provide an external connectivity to a VPN customer (e.g., to a may provide external connectivity to a VPN customer (e.g., to a
public cloud). Such service may involve tweaking both filtering public cloud). Such a service may involve tweaking both filtering
and NAT rules (e.g., bind a Virtual Routing and Forwarding (VRF) and NAT rules (e.g., binding a Virtual Routing and Forwarding
interface with a NAT instance as discussed in Section 2.10 of (VRF) interface with a NAT instance as discussed in Section 2.10
[RFC8512]). These added value features may be bound to all or a of [RFC8512]). These value-added features may be bound to all, or
subset of network accesses. Some of these added value features a subset of, network accesses. Some of these value-added features
may be implemented in a PE or in other nodes than PEs (e.g., a P may be implemented in a PE or in nodes other than PEs (e.g., a P
node or even a dedicated node that hosts the NAT function). node or even a dedicated node that hosts the NAT function).
Only a pointer to a local profile that defines the external Only a pointer to a local profile that defines the external-
connectivity feature is supported in this document. connectivity feature is supported in this document.
'vpn-node': Is an abstraction that represents a set of policies 'vpn-node': An abstraction that represents a set of policies applied
applied to a network node and that belong to a single 'vpn- to a network node and belonging to a single 'vpn-service'. A VPN
service'. A VPN service is typically built by adding instances of service is typically built by adding instances of 'vpn-node' to
'vpn-node' to the 'vpn-nodes' container. the 'vpn-nodes' container.
A 'vpn-node' contains 'vpn-network-accesses', which are the A 'vpn-node' contains 'vpn-network-accesses', which are the
interfaces attached to the VPN by which the customer traffic is interfaces attached to the VPN by which the customer traffic is
received. Therefore, the customer sites are connected to the received. Therefore, the customer sites are connected to the
'vpn-network-accesses'. 'vpn-network-accesses'.
Note that, as this is a network data model, the information about Note that because this is a network data model, information about
customers sites is not required in the model. Such information is customers' sites is not required in the model. Rather, such
rather relevant in the L3SM. Whether that information is included information is relevant in the L3SM. Whether that information is
in the L3NM, e.g., to populate the various 'description' data node included in the L3NM, e.g., to populate the various 'description'
is implementation specific. data nodes, is implementation specific.
More details are provided in Section 7.5. More details are provided in Section 7.5.
7.4. VPN Instance Profiles 7.4. VPN Instance Profiles
VPN instance profiles are meant to factorize data nodes that are used VPN instance profiles are meant to factorize data nodes that are used
at many levels of the model. Generic VPN instance profiles are at many levels of the model. Generic VPN instance profiles are
defined at the VPN service level and then called at the VPN node and defined at the VPN service level and then called at the VPN node and
VPN network access levels. Each VPN instance profile is identified VPN network access levels. Each VPN instance profile is identified
by 'profile-id'. This identifier is then referenced for one or by 'profile-id'. This identifier is then referenced for one or
multiple VPN nodes (Section 7.5) so that the controller can identify 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 generic resources (e.g., RTs and RDs) to be configured for a given
VRF. VRF instance.
The subtree of 'vpn-instance-profile' is shown in Figure 6. The subtree of the 'vpn-instance-profiles' is shown in Figure 6.
+--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-common:vpn-id +--rw vpn-id vpn-common:vpn-id
... ...
+--rw vpn-instance-profiles +--rw vpn-instance-profiles
| +--rw vpn-instance-profile* [profile-id] | +--rw vpn-instance-profile* [profile-id]
| +--rw profile-id string | +--rw profile-id string
| +--rw role? identityref | +--rw role? identityref
| +--rw local-as? inet:as-number | +--rw local-as? inet:as-number
| | {vpn-common:rtg-bgp}? | | {vpn-common:rtg-bgp}?
| +--rw (rd-choice)? | +--rw (rd-choice)?
| | +--:(directly-assigned) | | +--:(directly-assigned)
| | | +--rw rd? | | | +--rw rd?
| | | rt-types:route-distinguisher | | | rt-types:route-distinguisher
| | +--:(directly-assigned-suffix) | | +--:(directly-assigned-suffix)
| | | +--rw rd-suffix? uint16 | | | +--rw rd-suffix? uint16
| | +--:(auto-assigned) | | +--:(auto-assigned)
| | | +--rw rd-auto | | | +--rw rd-auto
| | | +--rw (auto-mode)? | | | +--rw (auto-mode)?
| | | | +--:(from-pool) | | | | +--:(from-pool)
| | | | | +--rw rd-pool-name? string | | | | | +--rw rd-pool-name? string
| | | | +--:(full-auto) | | | | +--:(full-auto)
| | | | +--rw auto? empty | | | | +--rw auto? empty
| | | +--ro auto-assigned-rd? | | | +--ro auto-assigned-rd?
| | | rt-types:route-distinguisher | | | rt-types:route-distinguisher
| | +--:(auto-assigned-suffix) | | +--:(auto-assigned-suffix)
| | | +--rw rd-auto-suffix | | | +--rw rd-auto-suffix
| | | +--rw (auto-mode)? | | | +--rw (auto-mode)?
| | | | +--:(from-pool) | | | | +--:(from-pool)
| | | | | +--rw rd-pool-name? string | | | | | +--rw rd-pool-name? string
| | | | +--:(full-auto) | | | | +--:(full-auto)
| | | | +--rw auto? empty | | | | +--rw auto? empty
| | | +--ro auto-assigned-rd-suffix? uint16 | | | +--ro auto-assigned-rd-suffix? uint16
| | +--:(no-rd) | | +--:(no-rd)
| | +--rw no-rd? empty | | +--rw no-rd? empty
| +--rw address-family* [address-family] | +--rw address-family* [address-family]
| | +--rw address-family identityref | | +--rw address-family identityref
| | +--rw vpn-targets | | +--rw vpn-targets
| | | +--rw vpn-target* [id] | | | +--rw vpn-target* [id]
| | | | +--rw id uint8 | | | | +--rw id uint8
| | | | +--rw route-targets* [route-target] | | | | +--rw route-targets* [route-target]
| | | | | +--rw route-target | | | | | +--rw route-target
| | | | | rt-types:route-target | | | | | rt-types:route-target
| | | | +--rw route-target-type | | | | +--rw route-target-type
| | | | rt-types:route-target-type | | | | rt-types:route-target-type
| | | +--rw vpn-policies | | | +--rw vpn-policies
| | | +--rw import-policy? string | | | +--rw import-policy? string
| | | +--rw export-policy? string | | | +--rw export-policy? string
| | +--rw maximum-routes* [protocol] | | +--rw maximum-routes* [protocol]
| | +--rw protocol identityref | | +--rw protocol identityref
| | +--rw maximum-routes? uint32 | | +--rw maximum-routes? uint32
| +--rw multicast {vpn-common:multicast}? | +--rw multicast {vpn-common:multicast}?
| ... | ...
Figure 6: Subtree Structure of VPN Instance Profiles Figure 6: Subtree Structure of VPN Instance Profiles
The description of the listed data nodes is as follows: The descriptions of the listed data nodes are as follows:
'profile-id': Is used to uniquely identify a VPN instance profile. 'profile-id': Used to uniquely identify a VPN instance profile.
'role': Indicates the role of the VPN instance profile in the VPN. 'role': Indicates the role of the VPN instance profile in the VPN.
Role values are defined in [I-D.ietf-opsawg-vpn-common] (e.g., Role values are defined in [RFC9181] (e.g., 'any-to-any-role',
any-to-any-role, spoke-role, hub-role). 'spoke-role', 'hub-role').
'local-as': Indicates the Autonomous System Number (ASN) that is 'local-as': Indicates the Autonomous System Number (ASN) that is
configured for the VPN node. configured for the VPN node.
'rd': As defined in [I-D.ietf-opsawg-vpn-common], the following RD 'rd': As defined in [RFC9181], the following RD assignment modes are
assignment modes are supported: direct assignment, automatic supported: direct assignment, full automatic assignment, automatic
assignment from a given pool, automatic assignment, and no assignment from a given pool, and no assignment. For illustration
assignment. For illustration purposes, the following modes can be purposes, the following modes can be used in the deployment cases:
used in the deployment cases:
'directly-assigned': The VPN service provider (service 'directly-assigned': The VPN service provider (service
orchestrator) assigns explicitly RDs. This case will fit with orchestrator) assigns RDs explicitly. This case will fit with
a brownfield scenario where some existing services need to be a brownfield scenario where some existing services need to be
updated by the VPN service provider. updated by the VPN service provider.
'full-auto': The network controller auto-assigns RDs. This can 'full-auto': The network controller auto-assigns RDs. This can
apply for the deployment of new services. apply for the deployment of new services.
'no-rd': The VPN service provider (service orchestrator) 'no-rd': The VPN service provider (service orchestrator)
explicitly wants no RD to be assigned. This case can be used explicitly wants no RD to be assigned. This case can be used
for CE testing within the network or for troubleshooting for CE testing within the network or for troubleshooting
proposes. proposes.
Also, the module accommodates deployments where only the Assigned Also, the module accommodates deployments where only the Assigned
Number subfield of RDs (Section 4.2 of [RFC4364]) is assigned from Number subfield of RDs (Section 4.2 of [RFC4364]) is assigned from
a pool while the Administrator subfield is set to, e.g., the a pool while the Administrator subfield is set to, for example,
Router ID that is assigned to a VPN node. The module supports the Router ID that is assigned to a VPN node. The module supports
these modes for managing the Assigned Number subfield: explicit these modes for managing the Assigned Number subfield: explicit
assignment, auto-assignment from a pool, and full auto-assignment. assignment, auto-assignment from a pool, and full auto-assignment.
'address-family': Includes a set of per-address family data nodes: 'address-family': Includes a set of data nodes per address family:
'address-family': Identifies the address family. It can be set 'address-family': Identifies the address family. It can be set
to IPv4, IPv6, or dual-stack. to 'ipv4', 'ipv6', or 'dual-stack'.
'vpn-targets': Specifies RT import/export rules for the VPN 'vpn-targets': Specifies RT import/export rules for the VPN
service (Section 4.3 of [RFC4364]). service (Section 4.3 of [RFC4364]).
'maximum-routes': Indicates the maximum number of prefixes that 'maximum-routes': Indicates the maximum number of prefixes that
the VPN node can accept for a given routing protocol. If the VPN node can accept for a given routing protocol. If
'protocol' is set to 'any', this means that the maximum value 'protocol' is set to 'any', this means that the maximum value
applies to each active routing protocol. applies to each active routing protocol.
'multicast': Enables multicast traffic in the VPN service. Refer to 'multicast': Enables multicast traffic in the VPN service. Refer to
Section 7.7. 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
to one L3VPN service. The 'vpn-node' includes a parameter to belonging to one L3VPN service. The 'vpn-node' includes a parameter
indicate the network node on which it is applied. In the case that to indicate the network node on which it is applied. In the case
the 'ne-id' points to a specific PE, the 'vpn-node' will likely be that the 'ne-id' points to a specific PE, the 'vpn-node' will likely
mapped into a VRF in the node. However, the model also allows be mapped to a VRF instance in the node. However, the model also
pointing to an abstract node. In this case, the network controller allows pointing to an abstract node. In this case, the network
will decide how to split the 'vpn-node' into VRFs. controller will decide how to split the 'vpn-node' into VRF
instances.
The VPN node subtree structure is shown in Figure 7.
+--rw l3vpn-ntw +--rw 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 vpn-common:vpn-id +--rw vpn-node-id vpn-common:vpn-id
skipping to change at page 24, line 7 skipping to change at line 989
| | +--rw status? identityref | | +--rw status? identityref
| | +--rw last-change? yang:date-and-time | | +--rw last-change? yang:date-and-time
| +--ro oper-status | +--ro oper-status
| +--ro status? identityref | +--ro status? identityref
| +--ro last-change? yang:date-and-time | +--ro last-change? yang:date-and-time
+--rw vpn-network-accesses +--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 The descriptions of the 'vpn-node' data nodes (Figure 7) are as
node data nodes is as follows: follows:
'vpn-node-id': Is an identifier that uniquely identifies a node that 'vpn-node-id': An identifier that uniquely identifies a node that
enables a VPN network access. enables a VPN network access.
'description': Provides 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.
'local-autonomous-system': Indicates the ASN that is configured for 'local-as': Indicates the ASN that is configured for the VPN node.
the VPN node.
'router-id': Indicates a 32-bit number that is used to uniquely 'router-id': Indicates a 32-bit number that is used to uniquely
identify a router within an Autonomous System. identify a router within an AS.
'active-vpn-instance-profiles': Lists the set of active VPN instance 'active-vpn-instance-profiles': Lists the set of active VPN instance
profiles for this VPN node. Concretely, one or more 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 profiles that are defined at the VPN service level can be enabled
at the VPN node level; each of these profiles is uniquely at the VPN node level; each of these profiles is uniquely
identified by means of 'profile-id'. The structure of 'active- identified by means of 'profile-id'. The structure of 'active-
vpn-instance-profiles' is the same as the one discussed in vpn-instance-profiles' is the same as the structure discussed in
Section 7.4 except 'router-id'. The value of 'router-id' Section 7.4, except that the structure of 'active-vpn-instance-
indicated under 'active-vpn-instance-profiles' takes precedence profiles' includes 'router-id' but does not include the 'role'
over the 'router-id' under the 'vpn-node' for the indicated leaf. The value of 'router-id' indicated under 'active-vpn-
address family. For example, Router IDs can be configured per instance-profiles' takes precedence over the 'router-id' under the
address family. This capability can be used, for example, to 'vpn-node' for the indicated address family. For example, Router
configure an IPv6 address as a Router ID when such capability is IDs can be configured per address family. This capability can be
supported by involved routers. used, for example, to configure an IPv6 address as a Router ID
when such a capability is supported by involved routers.
Values defined in 'active-vpn-instance-profiles' overrides the Values defined in 'active-vpn-instance-profiles' override the
ones defined in the VPN service level. An example is shown in values defined at the VPN service level. An example is shown in
Appendix A.3. Appendix A.3.
'msdp': For redundancy purposes, Multicast Source Discovery Protocol 'msdp': For redundancy purposes, the Multicast Source Discovery
(MSDP) [RFC3618] may be enabled and used to share the state about Protocol (MSDP) [RFC3618] may be enabled and used to share state
sources between multiple Rendezvous Points (RPs). The purpose of information about sources between multiple Rendezvous Points
MSDP in this context is to enhance the robustness of the multicast (RPs). The purpose of MSDP in this context is to enhance the
service. MSDP may be configured on non-RP routers, which is robustness of the multicast service. MSDP may be configured on
useful in a domain that does not support multicast sources, but non-RP routers; this is useful in a domain that does not support
does support multicast transit. multicast sources but does support multicast transit.
'groups': Lists the groups to which a VPN node belongs to
[I-D.ietf-opsawg-vpn-common]. The 'group-id' is used to 'groups': Lists the groups to which a VPN node belongs [RFC9181].
associate, e.g., redundancy or protection constraints with VPN For example, the 'group-id' is used to associate redundancy or
nodes. protection constraints with VPN nodes.
'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 status and administrative status are maintained.
mismatch between the administrative status vs. the operational A 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 the L3SM, the L3NM does not need to model the Note that unlike the 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 that receive traffic from the
received (i.e., the PE side of PE-CE connections). Hence, the VPN site (i.e., the PE side of Provider Edge to Customer Edge (PE-CE)
network access contains the connectivity information between the connections). Hence, the VPN network access contains the
provider's network and the customer premises. The VPN profiles connectivity information between the provider's network and the
('vpn-profiles') have a set of routing policies that can be customer premises. The VPN profiles ('vpn-profiles') have a set
applied during the service creation. of routing policies that can be applied during the service
creation.
See Section 7.6 for more details. See Section 7.6 for more details.
7.6. VPN Network Accesses 7.6. VPN Network Accesses
The 'vpn-network-access' includes a set of data nodes that describe The 'vpn-network-access' includes a set of data nodes that describe
the access information for the traffic that belongs to a particular the access information for the traffic that belongs to a particular
L3VPN (Figure 8). L3VPN (Figure 8).
... ...
skipping to change at page 26, line 38 skipping to change at line 1094
| ... | ...
+--rw oam +--rw oam
| ... | ...
+--rw security +--rw security
| ... | ...
+--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- A 'vpn-network-access' (Figure 8) includes the following data nodes:
access' includes the following data nodes:
'id': Is an identifier of the VPN network access. 'id': An identifier of the VPN network access.
'interface-id': Indicates the physical or logical interface on which 'interface-id': Indicates the physical or logical interface on which
the VPN network access is bound. the VPN network access is 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': Used to select the type of network
interface to be deployed in the devices. The available defined interface to be deployed in the devices. The available defined
values are: values are as follows:
'point-to-point': Represents a direct connection between the 'point-to-point': Represents a direct connection between the
endpoints. The controller must keep the association between a endpoints. The controller must keep the association between a
logical or physical interface on the device with the 'id' of logical or physical interface on the device with the 'id' of
the 'vpn-network-access'. the 'vpn-network-access'.
'multipoint': Represents a multipoint connection between the 'multipoint': Represents a multipoint connection between the
customer site and the PEs. The controller must keep the customer site and the PEs. The controller must keep the
association between a logical or physical interface on the association between a logical or physical interface on the
device with the 'id' of the 'vpn-network-access'. device with the 'id' of the 'vpn-network-access'.
'irb': Represents a connection coming from an L2VPN service. An 'irb': Represents a connection coming from an L2VPN service. An
identifier of such service ('l2vpn-id') may be included in the identifier of such a service ('l2vpn-id') may be included in
'connection' container as depicted in Figure 9. The controller the 'connection' container, as depicted in Figure 9
must keep the relationship between the logical tunnels or (Section 7.6.1). The controller must keep the relationship
bridges on the devices with the 'id' of the' vpn-network- between the logical tunnels or bridges on the devices with the
access'. '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 a loopback interface can device. An example that illustrates how a loopback interface
be used in the L3NM is provided in Appendix A.2. can be used in the L3NM is provided in Appendix A.2.
'vpn-instance-profile': Provides a pointer to an active VPN instance 'vpn-instance-profile': Provides a pointer to an active VPN instance
profile at the VPN node level. Referencing 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 profile implies that all associated data nodes will be inherited
by the VPN network access. However, some inherited data nodes by the VPN network access. However, some inherited data nodes
(e.g., multicast) can be overridden at the VPN network access (e.g., multicast) can be overridden at the VPN network access
level. In such case, adjusted values take precedence over level. In such a case, adjusted values take precedence over
inherited ones. inherited values.
'status': Indicates both operational and administrative status of a 'status': Indicates both operational status and administrative
VPN network access. status of a 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 Layer 3 connectivity information of a VPN 'ip-connection': Contains Layer 3 connectivity information on a VPN
network access (e.g., IP addressing). See Section 7.6.2. network access (e.g., IP addressing). See Section 7.6.2.
'routing-protocols': Includes the CE-PE routing configuration 'routing-protocols': Includes the CE-PE routing configuration
information. See Section 7.6.3. information. 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 access. 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 'connection' container represents the layer 2 connectivity to the The 'connection' container represents the Layer 2 connectivity to the
L3VPN for a particular VPN network access. As shown in the tree L3VPN for a particular VPN network access. As shown in the tree
depicted in Figure 9, the 'connection' container defines protocols depicted in Figure 9, the 'connection' container defines protocols
and parameters to enable such connectivity at layer 2. and parameters to enable such connectivity at Layer 2.
The traffic can enter the VPN with or without encapsulation (e.g., The traffic can enter the VPN with or without encapsulation (e.g.,
VLAN, QinQ). The 'encapsulation' container specifies the layer 2 VLAN, QinQ). The 'encapsulation' container specifies the Layer 2
encapsulation to use (if any) and allows to configure the relevant encapsulation to use (if any) and allows the configuration of the
tags. relevant tags.
The interface that is attached to the L3VPN is identified by the The interface that is attached to the L3VPN is identified by the
'interface-id' at the 'vpn-network-access' level. From a network 'interface-id' at the 'vpn-network-access' level. From a network
model perspective, it is expected that the 'interface-id' is model perspective, it is expected that the 'interface-id' is
sufficient to identify the interface. However, specific layer 2 sub- sufficient to identify the interface. However, specific Layer 2 sub-
interfaces may be required to be configured in some implementations/ interfaces may be required to be configured in some implementations/
deployments. Such a layer 2 specific interface can be included in deployments. Such a Layer-2-specific interface can be included in
'l2-termination-point'. 'l2-termination-point'.
If a layer 2 tunnel is needed to terminate the service in the CE-PE 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 connection, the 'l2-tunnel-service' container is used to specify the
required parameters to set such tunneling service (e.g., VPLS, required parameters to set such a tunneling service (e.g., a Virtual
VXLAN). An identity, called 'l2-tunnel-type', is defined for layer 2 Private LAN Service (VPLS) or a Virtual eXtensible Local Area Network
(VXLAN)). An identity called 'l2-tunnel-type' is defined for Layer 2
tunnel selection. The container can also identify the pseudowire tunnel selection. The container can also identify the pseudowire
(Section 6.1 of [RFC8077]). (Section 6.1 of [RFC8077]).
As discussed in Section 7.6, 'l2vpn-id' is used to identify the L2VPN As discussed in Section 7.6, 'l2vpn-id' is used to identify the L2VPN
service that is associated with an IRB interface. service that is associated with an Integrated Routing and Bridging
(IRB) interface.
To accommodate implementations that require internal bridging, a To accommodate implementations that require internal bridging, a
local bridge reference can be specified in 'local-bridge-reference'. local bridge reference can be specified in 'local-bridge-reference'.
Such a reference may be a local bridge domain. Such a reference may be a local bridge domain.
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
connected to the service provider network via a CE-PE link, which can is connected to the service provider network via a CE-PE link, which
access at least one VPN. The connection from the site to the service can access at least one VPN. The connection from the site to the
provider network is the bearer. Every site is associated with a list service provider network is the bearer. Every site is associated
of bearers. A bearer is the layer two connection with the site. In with a list of bearers. A bearer is the Layer 2 connection with the
the L3NM, it is assumed that the bearer has been allocated by the site. In the L3NM, it is assumed that the bearer has been allocated
service provider at the service orchestration stage. The bearer is by the service provider at the service orchestration stage. The
associated to a network element and a port. Hence, a bearer is just bearer is associated with a network element and a port. Hence, a
a 'bearer-reference' to allow the association between a service bearer is just a 'bearer-reference' to allow the association between
request (e.g., L3SM) and L3NM. a service request (e.g., the L3SM) and the L3NM.
The L3NM can be used to create a LAG interface for a given L3VPN The L3NM can be used to create a Link Aggregation Group (LAG)
service ('lag-interface') [IEEE802.1AX]. Such a LAG interface can be interface for a given L3VPN service ('lag-interface') [IEEE802.1AX].
referenced under 'interface-id' (Section 7.6). Such a LAG interface can be referenced under 'interface-id'
(Section 7.6).
... ...
+--rw connection +--rw connection
| +--rw encapsulation | +--rw encapsulation
| | +--rw type? identityref | | +--rw type? identityref
| | +--rw dot1q | | +--rw dot1q
| | | +--rw tag-type? identityref | | | +--rw tag-type? identityref
| | | +--rw cvlan-id? uint16 | | | +--rw cvlan-id? uint16
| | +--rw priority-tagged | | +--rw priority-tagged
| | | +--rw tag-type? identityref | | | +--rw tag-type? identityref
| | +--rw qinq | | +--rw qinq
| | +--rw tag-type? identityref | | +--rw tag-type? identityref
| | +--rw svlan-id uint16 | | +--rw svlan-id uint16
| | +--rw cvlan-id uint16 | | +--rw cvlan-id uint16
| +--rw (l2-service)? | +--rw (l2-service)?
| | +--:(l2-tunnel-service) | | +--:(l2-tunnel-service)
| | | +--rw l2-tunnel-service | | | +--rw l2-tunnel-service
| | | +--rw type? identityref | | | +--rw type? identityref
| | | +--rw pseudowire | | | +--rw pseudowire
| | | | +--rw vcid? uint32 | | | | +--rw vcid? uint32
| | | | +--rw far-end? union | | | | +--rw far-end? union
| | | +--rw vpls | | | +--rw vpls
| | | | +--rw vcid? uint32 | | | | +--rw vcid? uint32
| | | | +--rw far-end* union | | | | +--rw far-end* union
| | | +--rw vxlan | | | +--rw vxlan
| | | +--rw vni-id uint32 | | | +--rw vni-id uint32
| | | +--rw peer-mode? identityref | | | +--rw peer-mode? identityref
| | | +--rw peer-ip-address* inet:ip-address | | | +--rw peer-ip-address* inet:ip-address
| | +--:(l2vpn) | | +--:(l2vpn)
| | +--rw l2vpn-id? vpn-common:vpn-id | | +--rw l2vpn-id? vpn-common:vpn-id
| +--rw l2-termination-point? string | +--rw l2-termination-point? string
| +--rw local-bridge-reference? string | +--rw local-bridge-reference? string
| +--rw bearer-reference? string | +--rw bearer-reference? string
| | {vpn-common:bearer-reference}? | | {vpn-common:bearer-reference}?
| +--rw lag-interface {vpn-common:lag-interface}? | +--rw lag-interface {vpn-common:lag-interface}?
| +--rw lag-interface-id? string | +--rw lag-interface-id? string
| +--rw member-link-list | +--rw member-link-list
| +--rw member-link* [name] | +--rw member-link* [name]
| +--rw name string | +--rw name string
... ...
Figure 9: Connection Subtree Structure Figure 9: Connection Subtree Structure
7.6.2. IP Connection 7.6.2. IP Connection
This container is used to group Layer 3 connectivity information, This container is used to group Layer 3 connectivity information,
particularly the IP addressing information, of a VPN network access. particularly the IP addressing information, of a VPN network access.
The allocated address represents the PE interface address The allocated address represents the PE interface address
configuration. Note that a distinct layer 3 interface other than the configuration. Note that a distinct Layer 3 interface other than the
one indicated under the 'connection' container may be needed to interface indicated under the 'connection' container may be needed to
terminate the layer 3 service. The identifier of such interface is terminate the Layer 3 service. The identifier of such an interface
included in 'l3-termination-point'. For example, this data node can is included in 'l3-termination-point'. For example, this data node
be used to carry the identifier of a bridge domain interface. can be used to carry the identifier of a bridge domain interface.
As shown in Figure 10, the 'ip-connection' container can include As shown in Figure 10, the 'ip-connection' container can include
IPv4, IPv6, or both if dual-stack is enabled. IPv4, IPv6, or both if dual-stack is enabled.
... ...
+--rw vpn-network-accesses +--rw vpn-network-accesses
+--rw vpn-network-access* [id] +--rw vpn-network-access* [id]
... ...
+--rw ip-connection +--rw ip-connection
| +--rw l3-termination-point? string | +--rw l3-termination-point? string
| +--rw ipv4 {vpn-common:ipv4}? | +--rw ipv4 {vpn-common:ipv4}?
| | ... | | ...
| +--rw ipv6 {vpn-common:ipv6}? | +--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. Note that for the IPv6 case, SLAAC [RFC4862] and static addressing. Note that for the IPv6 case, Stateless
can be used. For both IPv4 and IPv6, 'address-allocation-type' is Address Autoconfiguration (SLAAC) [RFC4862] can be used. For both
used to indicate the IP address allocation mode to activate for a IPv4 and IPv6, 'address-allocation-type' is used to indicate the IP
given VPN network access. address allocation mode to activate for a given VPN network access.
When 'address-allocation-type' is set to 'provider-dhcp', DHCP When 'address-allocation-type' is set to 'provider-dhcp', DHCP
assignments can be made locally or by an external DHCP server. Such assignments can be made locally or by an external DHCP server. Such
as behavior is controlled by setting 'dhcp-service-type'. behavior is controlled by setting 'dhcp-service-type'.
Figure 11 shows the structure of the dynamic IPv4 address assignment Figure 11 shows the structure of the dynamic IPv4 address assignment
(i.e., by means of DHCP). (i.e., by means of DHCP).
... ...
+--rw ip-connection +--rw ip-connection
| +--rw l3-termination-point? string | +--rw l3-termination-point? string
| +--rw ipv4 {vpn-common:ipv4}? | +--rw ipv4 {vpn-common:ipv4}?
| | +--rw local-address? inet:ipv4-address | | +--rw local-address? inet:ipv4-address
| | +--rw prefix-length? uint8 | | +--rw prefix-length? uint8
| | +--rw address-allocation-type? identityref | | +--rw address-allocation-type? identityref
| | +--rw (allocation-type)? | | +--rw (allocation-type)?
| | +--:(provider-dhcp) | | +--:(provider-dhcp)
| | | +--rw dhcp-service-type? enumeration | | | +--rw dhcp-service-type? enumeration
| | | +--rw (service-type)? | | | +--rw (service-type)?
| | | +--:(relay) | | | +--:(relay)
| | | | +--rw server-ip-address* | | | | +--rw server-ip-address*
| | | | inet:ipv4-address | | | | inet:ipv4-address
| | | +--:(server) | | | +--:(server)
| | | +--rw (address-assign)? | | | +--rw (address-assign)?
| | | +--:(number) | | | +--:(number)
| | | | +--rw number-of-dynamic-address? | | | | +--rw number-of-dynamic-address?
| | | | uint16 | | | | uint16
| | | +--:(explicit) | | | +--:(explicit)
| | | +--rw customer-addresses | | | +--rw customer-addresses
| | | +--rw address-pool* [pool-id] | | | +--rw address-pool* [pool-id]
| | | +--rw pool-id string | | | +--rw pool-id string
| | | +--rw start-address | | | +--rw start-address
| | | | inet:ipv4-address | | | | inet:ipv4-address
| | | +--rw end-address? | | | +--rw end-address?
| | | inet:ipv4-address | | | inet:ipv4-address
| | +--:(dhcp-relay) | | +--:(dhcp-relay)
| | | +--rw customer-dhcp-servers | | | +--rw customer-dhcp-servers
| | | +--rw server-ip-address* inet:ipv4-address | | | +--rw server-ip-address* inet:ipv4-address
| | +--:(static-addresses) | | +--:(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' (i.e., DHCPv6 and/or SLAAC). Note that if 'address-allocation-type'
is set to 'slaac', the Prefix Information option of Router is set to 'slaac', the Prefix Information option of Router
Advertisements that will be issued for SLAAC purposes, will carry the Advertisements that will be issued for SLAAC purposes will carry the
IPv6 prefix that is determined by 'local-address' and 'prefix- IPv6 prefix that is determined by 'local-address' and 'prefix-
length'. For example, if 'local-address' is set to '2001:db8:0:1::1' 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 and 'prefix-length' is set to '64', the IPv6 prefix that will be used
is '2001:db8:0:1::/64'. is '2001:db8:0:1::/64'.
... ...
+--rw ip-connection +--rw ip-connection
| +--rw l3-termination-point? string | +--rw l3-termination-point? string
| +--rw ipv4 {vpn-common:ipv4}? | +--rw ipv4 {vpn-common:ipv4}?
| | ... | | ...
| +--rw ipv6 {vpn-common:ipv6}? | +--rw ipv6 {vpn-common:ipv6}?
| +--rw local-address? inet:ipv6-address | +--rw local-address? inet:ipv6-address
| +--rw prefix-length? uint8 | +--rw prefix-length? uint8
| +--rw address-allocation-type? identityref | +--rw address-allocation-type? identityref
| +--rw (allocation-type)? | +--rw (allocation-type)?
| +--:(provider-dhcp) | +--:(provider-dhcp)
| | +--rw provider-dhcp | | +--rw provider-dhcp
| | +--rw dhcp-service-type? | | +--rw dhcp-service-type?
| | | enumeration | | | enumeration
| | +--rw (service-type)? | | +--rw (service-type)?
| | +--:(relay) | | +--:(relay)
| | | +--rw server-ip-address* | | | +--rw server-ip-address*
| | | inet:ipv6-address | | | inet:ipv6-address
| | +--:(server) | | +--:(server)
| | +--rw (address-assign)? | | +--rw (address-assign)?
| | +--:(number) | | +--:(number)
| | | +--rw number-of-dynamic-address? | | | +--rw number-of-dynamic-address?
| | | uint16 | | | uint16
| | +--:(explicit) | | +--:(explicit)
| | +--rw customer-addresses | | +--rw customer-addresses
| | +--rw address-pool* [pool-id] | | +--rw address-pool* [pool-id]
| | +--rw pool-id string | | +--rw pool-id string
| | +--rw start-address | | +--rw start-address
| | | inet:ipv6-address | | | inet:ipv6-address
| | +--rw end-address? | | +--rw end-address?
| | inet:ipv6-address | | inet:ipv6-address
| +--:(dhcp-relay) | +--:(dhcp-relay)
| | +--rw customer-dhcp-servers | | +--rw customer-dhcp-servers
| | +--rw server-ip-address* | | +--rw server-ip-address*
| | inet:ipv6-address | | inet:ipv6-address
| +--:(static-addresses) | +--:(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 static addressing (Figure 13), the model supports the
the assignment of several IP addresses in the same 'vpn-network- assignment of several IP addresses in the same 'vpn-network-access'.
access'. To identify which of the addresses is the primary address To identify which of the addresses is the primary address of a
of a connection, the 'primary-address' reference MUST be set with the connection, the 'primary-address' reference MUST be set with the
corresponding 'address-id'. corresponding 'address-id'.
... ...
+--rw ip-connection +--rw ip-connection
| +--rw l3-termination-point? string | +--rw l3-termination-point? string
| +--rw ipv4 {vpn-common:ipv4}? | +--rw ipv4 {vpn-common:ipv4}?
| | +--rw address-allocation-type? identityref | | +--rw address-allocation-type? identityref
| | +--rw (allocation-type)? | | +--rw (allocation-type)?
| | ... | | ...
| | +--:(static-addresses) | | +--:(static-addresses)
| | +--rw primary-address? -> ../address/address-id | | +--rw primary-address? -> ../address/address-id
| | +--rw address* [address-id] | | +--rw address* [address-id]
| | +--rw address-id string | | +--rw address-id string
| | +--rw customer-address? inet:ipv4-address | | +--rw customer-address? inet:ipv4-address
| +--rw ipv6 {vpn-common:ipv6}? | +--rw ipv6 {vpn-common:ipv6}?
| +--rw address-allocation-type? identityref | +--rw address-allocation-type? identityref
| +--rw (allocation-type)? | +--rw (allocation-type)?
| ... | ...
| +--:(static-addresses) | +--:(static-addresses)
| +--rw primary-address? -> ../address/address-id | +--rw primary-address? -> ../address/address-id
| +--rw address* [address-id] | +--rw address* [address-id]
| +--rw address-id string | +--rw address-id string
| +--rw customer-address? inet:ipv6-address | +--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
protocols are enabled between the PE and the CE. Each instance is protocols are 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.
The subtree of the 'routing-protocols' is shown in Figure 14. The subtree of the 'routing-protocols' is shown in Figure 14.
... ...
+--rw vpn-network-accesses +--rw vpn-network-accesses
+--rw vpn-network-access* [id] +--rw vpn-network-access* [id]
... ...
+--rw routing-protocols +--rw routing-protocols
| +--rw routing-protocol* [id] | +--rw routing-protocol* [id]
| +--rw id string | +--rw id string
| +--rw type? identityref | +--rw type? identityref
| +--rw routing-profiles* [id] | +--rw routing-profiles* [id]
| | +--rw id leafref | | +--rw id leafref
| | +--rw type? identityref | | +--rw type? identityref
| +--rw static | +--rw static
| | ... | | ...
| +--rw bgp | +--rw bgp
| | ... | | ...
| +--rw ospf | +--rw ospf
| | ... | | ...
| +--rw isis | +--rw isis
| | ... | | ...
| +--rw rip | +--rw rip
| | ... | | ...
| +--rw vrrp | +--rw vrrp
| ... | ...
+--rw security +--rw security
... ...
Figure 14: Routing Subtree Structure Figure 14: Routing Subtree Structure
Multiple routing instances can be defined; each uniquely identified Multiple routing instances can be defined, each uniquely identified
by an 'id'. The type of routing instance is indicated in 'type'. by an 'id'. The type of routing instance is indicated in 'type'.
The values of these attributes are those defined in The values of these attributes are those defined in [RFC9181] (the
[I-D.ietf-opsawg-vpn-common] ('routing-protocol-type' identity). 'routing-protocol-type' identity).
Configuring multiple instances of the same routing protocol does not Configuring multiple instances of the same routing protocol does not
automatically imply that, from a device configuration perspective, automatically imply that, from a device configuration perspective,
there will be parallel instances (e.g., multiple processes) running there will be parallel instances (e.g., multiple processes) running
on the PE-CE link. It is up to each implementation (typically, on the PE-CE link. It is up to each implementation (typically,
network orchestration shown in Figure 1) to decide about the network orchestration, as shown in Figure 1) to decide on the
appropriate configuration as a function of underlying capabilities appropriate configuration as a function of underlying capabilities
and service provider operational guidelines. As an example, when and service provider operational guidelines. As an example, when
multiple BGP peers need to be implemented, multiple instances of BGP multiple BGP peers need to be implemented, multiple instances of BGP
must be configured as part of this model. However, from a device must be configured as part of this model. However, from a device
configuration point of view, this could be implemented as: configuration point of view, this could be implemented as:
* Multiple BGP processes with a single neighbor running in each * Multiple BGP processes with a single neighbor running in each
process. process.
* A single BGP process with multiple neighbors running. * A single BGP process with multiple neighbors running.
skipping to change at page 35, line 16 skipping to change at line 1482
Routing configuration does not include low-level policies. Such Routing configuration does not include low-level policies. Such
policies are handled at the device configuration level. Local policies are handled at the device configuration level. Local
policies of a service provider (e.g., filtering) are implemented as policies of a service provider (e.g., filtering) are implemented as
part of the device configuration; these are not captured in the L3NM, part of the device configuration; these are not captured in the L3NM,
but the model allows local profiles to be associated with routing but the model allows local profiles to be associated with routing
instances ('routing-profiles'). Note that these routing profiles can instances ('routing-profiles'). Note that these routing profiles can
be scoped to capture parameters that are globally applied to all be scoped to capture parameters that are globally applied to all
L3VPN services within a service provider network, while customized L3VPN services within a service provider network, while customized
L3VPN parameters are captured by means of the L3NM. The provisioning L3VPN parameters are captured by means of the L3NM. The provisioning
of an L3VPN service will, thus, rely upon the instantiation of these of an L3VPN service will thus rely upon the instantiation of these
global routing profiles and the customized L3NM. global routing profiles and the customized L3NM.
7.6.3.1. Static Routing 7.6.3.1. Static Routing
The L3NM supports the configuration of one or more IPv4/IPv6 static The L3NM supports the configuration of one or more IPv4/IPv6 static
routes. Since the same structure is used for both IPv4 and IPv6, it routes. Since the same structure is used for both IPv4 and IPv6,
was considered to have one single container to group both static using one single container to group both static entries independently
entries independently of their address family, but that design was of their address family was considered at one time, but that design
abandoned to ease the mapping with the structure in [RFC8299]. was abandoned to ease the mapping, using the structure provided in
[RFC8299].
... The static routing subtree structure is shown in Figure 15.
+--rw routing-protocols
| +--rw routing-protocol* [id] ...
| ... +--rw routing-protocols
| +--rw static | +--rw routing-protocol* [id]
| | +--rw cascaded-lan-prefixes | ...
| | +--rw ipv4-lan-prefixes* | +--rw static
| | | [lan next-hop] | | +--rw cascaded-lan-prefixes
| | | {vpn-common:ipv4}? | | +--rw ipv4-lan-prefixes*
| | | +--rw lan inet:ipv4-prefix | | | [lan next-hop]
| | | +--rw lan-tag? string | | | {vpn-common:ipv4}?
| | | +--rw next-hop union | | | +--rw lan inet:ipv4-prefix
| | | +--rw bfd-enable? boolean | | | +--rw lan-tag? string
| | | +--rw metric? uint32 | | | +--rw next-hop union
| | | +--rw preference? uint32 | | | +--rw bfd-enable? boolean
| | | +--rw status | | | +--rw metric? uint32
| | | +--rw admin-status | | | +--rw preference? uint32
| | | | +--rw status? identityref | | | +--rw status
| | | | +--rw last-change? yang:date-and-time | | | +--rw admin-status
| | | +--ro oper-status | | | | +--rw status? identityref
| | | +--ro status? identityref | | | | +--rw last-change? yang:date-and-time
| | | +--ro last-change? yang:date-and-time | | | +--ro oper-status
| | +--rw ipv6-lan-prefixes* | | | +--ro status? identityref
| | [lan next-hop] | | | +--ro last-change? yang:date-and-time
| | {vpn-common:ipv6}? | | +--rw ipv6-lan-prefixes*
| | +--rw lan inet:ipv6-prefix | | [lan next-hop]
| | +--rw lan-tag? string | | {vpn-common:ipv6}?
| | +--rw next-hop union | | +--rw lan inet:ipv6-prefix
| | +--rw bfd-enable? boolean | | +--rw lan-tag? string
| | +--rw metric? uint32 | | +--rw next-hop union
| | +--rw preference? uint32 | | +--rw bfd-enable? boolean
| | +--rw status | | +--rw metric? uint32
| | +--rw admin-status | | +--rw preference? uint32
| | | +--rw status? identityref | | +--rw status
| | | +--rw last-change? yang:date-and-time | | +--rw admin-status
| | +--ro oper-status | | | +--rw status? identityref
| | +--ro status? identityref | | | +--rw last-change? yang:date-and-time
| | +--ro last-change? yang:date-and-time | | +--ro oper-status
... | | +--ro status? identityref
| | +--ro last-change? yang:date-and-time
...
Figure 15: Static Routing Subtree Structure Figure 15: Static Routing Subtree Structure
As depicted in Figure 15, the following data nodes can be defined for As depicted in Figure 15, the following data nodes can be defined for
a given IP prefix: a given IP prefix:
'lan-tag': Indicates a local tag (e.g., "myfavourite-lan") that is 'lan-tag': Indicates a local tag (e.g., "myfavorite-lan") that is
used to enforce local policies. used to enforce local policies.
'next-hop': Indicates the next-hop to be used for the static route. 'next-hop': Indicates the next hop to be used for the static route.
It can be identified by an IP address, an interface, etc. It can be identified by an IP address, a predefined next-hop type
(e.g., 'discard' or 'local-link'), etc.
'bfd-enable': Indicates whether BFD is enabled or disabled for this 'bfd-enable': Indicates whether BFD is enabled or disabled for this
static route entry. static route entry.
'metric': Indicates the metric associated with the static route 'metric': Indicates the metric associated with the static route
entry. entry. This metric is used when the route is exported into an
IGP.
'preference': Indicates the preference associated with the static 'preference': Indicates the preference associated with the static
route entry. This preference is used to selecting a preferred route entry. This preference is used to select a preferred route
route among routes to the same destination prefix. among routes to the same destination prefix.
'status': Used to convey the status of a static route entry. This 'status': Used to convey the status of a static route entry. This
data node can also be used to control the (de)activation of data node can also be used to control the (de)activation of
individual static route entries. individual static route entries.
7.6.3.2. BGP 7.6.3.2. BGP
The L3NM allows the configuration of a BGP neighbor, including a set The L3NM allows the configuration of a BGP neighbor, including a set
for parameters that are pertinent to be tweaked at the network level of parameters that are pertinent to be tweaked at the network level
for service customization purposes. The 'bgp' container does not aim for service customization purposes. The 'bgp' container does not aim
to include every BGP parameter; a comprehensive set of parameters to include every BGP parameter; a comprehensive set of parameters
belongs more to the BGP device model. belongs more to the BGP device model.
... The BGP routing subtree structure is shown in Figure 16.
+--rw routing-protocols
| +--rw routing-protocol* [id]
| ...
| +--rw bgp
| | +--rw description? string
| | +--rw local-as? inet:as-number
| | +--rw peer-as inet:as-number
| | +--rw address-family? identityref
| | +--rw local-address? union
| | +--rw neighbor* inet:ip-address
| | +--rw multihop? uint8
| | +--rw as-override? boolean
| | +--rw allow-own-as? uint8
| | +--rw prepend-global-as? boolean
| | +--rw send-default-route? boolean
| | +--rw site-of-origin? rt-types:route-origin
| | +--rw ipv6-site-of-origin? rt-types:ipv6-route-origin
| | +--rw redistribute-connected* [address-family]
| | | +--rw address-family identityref
| | | +--rw enable? boolean
| | +--rw bgp-max-prefix
| | | +--rw max-prefix? uint32
| | | +--rw warning-threshold? decimal64
| | | +--rw violate-action? enumeration
| | | +--rw restart-timer? uint32
| | +--rw bgp-timers
| | | +--rw keepalive? uint16
| | | +--rw hold-time? uint16
| | +--rw authentication
| | | +--rw enable? boolean
| | | +--rw keying-material
| | | +--rw (option)?
| | | +--:(ao)
| | | | +--rw enable-ao? boolean
| | | | +--rw ao-keychain? key-chain:key-chain-ref
| | | +--:(md5)
| | | | +--rw md5-keychain? key-chain:key-chain-ref
| | | +--:(explicit)
| | | | +--rw key-id? uint32
| | | | +--rw key? string
| | | | +--rw crypto-algorithm? identityref
| | | +--:(ipsec)
| | | +--rw sa? string
| | +--rw status
| | +--rw admin-status
| | | +--rw status? identityref
| | | +--rw last-change? yang:date-and-time
| | +--ro oper-status
| | +--ro status? identityref
| | +--ro last-change? yang:date-and-time
...
Figure 16: BGP Routing Subtree Structure ...
+--rw routing-protocols
| +--rw routing-protocol* [id]
| ...
| +--rw bgp
| | +--rw description? string
| | +--rw local-as? inet:as-number
| | +--rw peer-as inet:as-number
| | +--rw address-family? identityref
| | +--rw local-address? union
| | +--rw neighbor* inet:ip-address
| | +--rw multihop? uint8
| | +--rw as-override? boolean
| | +--rw allow-own-as? uint8
| | +--rw prepend-global-as? boolean
| | +--rw send-default-route? boolean
| | +--rw site-of-origin? rt-types:route-origin
| | +--rw ipv6-site-of-origin? rt-types:ipv6-route-origin
| | +--rw redistribute-connected* [address-family]
| | | +--rw address-family identityref
| | | +--rw enable? boolean
| | +--rw bgp-max-prefix
| | | +--rw max-prefix? uint32
| | | +--rw warning-threshold? decimal64
| | | +--rw violate-action? enumeration
| | | +--rw restart-timer? uint32
| | +--rw bgp-timers
| | | +--rw keepalive? uint16
| | | +--rw hold-time? uint16
| | +--rw authentication
| | | +--rw enable? boolean
| | | +--rw keying-material
| | | +--rw (option)?
| | | +--:(ao)
| | | | +--rw enable-ao? boolean
| | | | +--rw ao-keychain? key-chain:key-chain-ref
| | | +--:(md5)
| | | | +--rw md5-keychain? key-chain:key-chain-ref
| | | +--:(explicit)
| | | | +--rw key-id? uint32
| | | | +--rw key? string
| | | | +--rw crypto-algorithm? identityref
| | | +--:(ipsec)
| | | +--rw sa? string
| | +--rw status
| | +--rw admin-status
| | | +--rw status? identityref
| | | +--rw last-change? yang:date-and-time
| | +--ro oper-status
| | +--ro status? identityref
| | +--ro last-change? yang:date-and-time
...
Figure 16: BGP Routing Subtree Structure
The following data nodes are captured in Figure 16. It is up to the The following data nodes are captured in Figure 16. It is up to the
implementation (e.g., network orchestrator) to derive the implementation (e.g., network orchestrator) to derive the
corresponding BGP device configuration: corresponding BGP device configuration:
'description': Includes a description of the BGP session. 'description': Includes a description of the BGP session.
'local-as': Indicates a local AS Number (ASN) if a distinct ASN is 'local-as': Indicates a local AS Number (ASN), if a distinct ASN is
required, other than the one configured at the VPN node level. required other than the ASN configured at the VPN node level.
'peer-as': Conveys the customer's ASN. 'peer-as': Conveys the customer's ASN.
'address-family': Indicates the address-family of the peer. It can 'address-family': Indicates the address family of the peer. It can
be set to IPv4, IPv6, or dual-stack. be set to 'ipv4', 'ipv6', or 'dual-stack'.
This address family will be used together with the 'vpn-type' to This address family will be used together with the 'vpn-type' to
derive the appropriate Address Family Identifiers derive the appropriate Address Family Identifiers (AFIs) /
(AFIs)/Subsequent Address Family Identifiers (SAFIs) that will be Subsequent Address Family Identifiers (SAFIs) that will be part of
part of the derived device configurations (e.g., Unicast IPv4 MPLS the derived device configurations (e.g., unicast IPv4 MPLS L3VPN
L3VPN (AFI,SAFI = 1,128) defined in Section 4.3.4 of [RFC4364]). (AFI,SAFI = 1,128) as defined in Section 4.3.4 of [RFC4364]).
'local-address': Specifies an address or a reference to an interface 'local-address': Specifies an address or a reference to an interface
to use when establishing the BGP transport session. 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 to family) or one neighbor (if the 'address-family' attribute is set
dual-stack). A list of IP address(es) of the BGP neighbors can be to 'dual-stack'). A list of IP address(es) of the BGP neighbor(s)
then conveyed in this data node. can then be conveyed in this data node.
'multihop': Indicates the number of allowed IP hops between a PE and 'multihop': Indicates the number of allowed IP hops between a PE and
its BGP peer. its BGP peer.
'as-override': If set, this parameter indicates whether ASN override 'as-override': If set, this parameter indicates whether ASN override
is enabled, i.e., replace the ASN of the customer specified in the is enabled, i.e., replacing the ASN of the customer specified in
AS_PATH BGP attribute with the ASN identified in the 'local-as' the AS_PATH BGP attribute with the ASN identified in the 'local-
attribute. as' attribute.
'allow-own-as': Is used in some topologies (e.g., hub-and-spoke) to 'allow-own-as': Used in some topologies (e.g., hub-and-spoke) to
allow the provider's ASN to be included in the AS_PATH BGP allow the provider's ASN to be included in the AS_PATH BGP
attribute received from a CE. Loops are prevented by setting attribute received from a CE. Loops are prevented by setting
'allow-own-as' to a maximum number of provider's ASN occurrences. 'allow-own-as' to a maximum number of the provider's ASN
This parameter is set by default to '0' (that is, reject any occurrences. By default, this parameter is set to '0' (that is,
AS_PATH attribute that includes the provider's ASN). reject any AS_PATH attribute that includes the provider's ASN).
'prepend-global-as': When distinct ASNs are configured in the VPN 'prepend-global-as': When distinct ASNs are configured at the VPN
node and network access levels, this parameter controls whether node and network access levels, this parameter controls whether
the ASN provided at the VPN node level is prepended to the AS_PATH the ASN provided at the VPN node level is prepended to the AS_PATH
attribute. attribute.
'send-default-route': Controls whether default routes can be 'send-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': Meant to uniquely identify the set of routes
learned from a site via a particular CE/PE connection and is used learned from a site via a particular CE-PE connection. It is used
to prevent routing loops (Section 7 of [RFC4364]). The Site of to prevent routing loops (Section 7 of [RFC4364]). The Site of
Origin attribute is encoded as a Route Origin Extended Community. Origin attribute is encoded as a Route Origin Extended Community.
'ipv6-site-of-origin': Carries an IPv6 Address Specific BGP Extended 'ipv6-site-of-origin': Carries an IPv6 Address Specific BGP Extended
Community that is used to indicate the Site of Origin for VRF Community 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 'redistribute-connected': Controls whether the PE-CE link is
advertised to other PEs. advertised to other PEs.
skipping to change at page 40, line 17 skipping to change at line 1703
'max-prefix': Indicates the maximum number of BGP prefixes 'max-prefix': Indicates the maximum number of BGP prefixes
allowed in the BGP session. If the limit is reached, the allowed in the BGP session. If the limit is reached, the
action indicated in 'violate-action' will be followed. action indicated in 'violate-action' will be followed.
'warning-threshold': A warning notification is triggered when 'warning-threshold': A warning notification is triggered when
this limit is reached. this limit is reached.
'violate-action': Indicates which action to execute when the 'violate-action': Indicates which action to execute when the
maximum number of BGP prefixes is reached. Examples of such maximum number of BGP prefixes is reached. Examples of such
actions are: send a warning message, discard extra paths from actions include sending a warning message, discarding extra
the peer, or restart the session. paths from the peer, or restarting the session.
'restart-timer': Indicates, in seconds, the time interval after 'restart-timer': Indicates, in seconds, the time interval after
which the BGP session will be reestablished. which the BGP session will be reestablished.
'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 the 'hold-time', which is the time interval that will be used for the
HoldTimer (Section 4.2 of [RFC4271]) when establishing a BGP Hold Timer (Section 4.2 of [RFC4271]) when establishing a BGP
session. (2) 'keepalive' which is the time interval for the session and (2) 'keepalive', which is the time interval for the
KeepAlive timer between a PE and a BGP peer (Section 4.4 of KeepaliveTimer between a PE and a BGP peer (Section 4.4 of
[RFC4271]). Both timers are expressed in seconds. [RFC4271]). Both timers are expressed in seconds.
'authentication': The module adheres to the recommendations in 'authentication': The module adheres to the recommendations in
Section 13.2 of [RFC4364] as it allows enabling TCP-AO [RFC5925] Section 13.2 of [RFC4364], as it allows enabling the TCP
and accommodates the installed base that makes use of MD5. In Authentication Option (TCP-AO) [RFC5925] and accommodates the
addition, the module includes a provision for the use of IPsec. installed base that makes use of MD5. In addition, the module
includes a provision for using IPsec.
This version of the L3NM assumes that TCP-AO specific parameters This version of the L3NM assumes that parameters specific to the
are preconfigured as part of the key-chain that is referenced in TCP-AO are preconfigured as part of the key chain that is
the L3NM. No assumption is made about how such a key-chain is referenced in the L3NM. No assumption is made about how such a
pre-configured. However, the structure of the key-chain should key chain is preconfigured. However, the structure of the key
cover data nodes beyond those in [RFC8177], mainly SendID and chain should cover data nodes beyond those in [RFC8177], mainly
RecvID (Section 3.1 of [RFC5925]). SendID and RecvID (Section 3.1 of [RFC5925]).
'status': Indicates the status of the BGP routing instance. 'status': Indicates the status of the BGP routing instance.
7.6.3.3. OSPF 7.6.3.3. OSPF
OSPF can be configured to run as a routing protocol on the 'vpn- OSPF can be configured to run as a routing protocol on the 'vpn-
network-access'. network-access'.
... The OSPF routing subtree structure is shown in Figure 17.
+--rw routing-protocols
| +--rw routing-protocol* [id]
| ...
| +--rw ospf
| | +--rw address-family? identityref
| | +--rw area-id yang:dotted-quad
| | +--rw metric? uint16
| | +--rw sham-links {vpn-common:rtg-ospf-sham-link}?
| | | +--rw sham-link* [target-site]
| | | +--rw target-site
| | | | vpn-common:vpn-id
| | | +--rw metric? uint16
| | +--rw max-lsa? uint32
| | +--rw authentication
| | | +--rw enable? boolean
| | | +--rw keying-material
| | | +--rw (option)?
| | | +--:(auth-key-chain)
| | | | +--rw key-chain?
| | | | key-chain:key-chain-ref
| | | +--:(auth-key-explicit)
| | | | +--rw key-id? uint32
| | | | +--rw key? string
| | | | +--rw crypto-algorithm?
| | | | identityref
| | | +--:(ipsec)
| | | +--rw sa? string
| | +--rw status
| | +--rw admin-status
| | | +--rw status? identityref
| | | +--rw last-change? yang:date-and-time
| | +--ro oper-status
| | +--ro status? identityref
| | +--ro last-change? yang:date-and-time
...
Figure 17: OPSF Routing Subtree Structure ...
+--rw routing-protocols
| +--rw routing-protocol* [id]
| ...
| +--rw ospf
| | +--rw address-family? identityref
| | +--rw area-id yang:dotted-quad
| | +--rw metric? uint16
| | +--rw sham-links {vpn-common:rtg-ospf-sham-link}?
| | | +--rw sham-link* [target-site]
| | | +--rw target-site string
| | | +--rw metric? uint16
| | +--rw max-lsa? uint32
| | +--rw authentication
| | | +--rw enable? boolean
| | | +--rw keying-material
| | | +--rw (option)?
| | | +--:(auth-key-chain)
| | | | +--rw key-chain?
| | | | key-chain:key-chain-ref
| | | +--:(auth-key-explicit)
| | | | +--rw key-id? uint32
| | | | +--rw key? string
| | | | +--rw crypto-algorithm?
| | | | identityref
| | | +--:(ipsec)
| | | +--rw sa? string
| | +--rw status
| | +--rw admin-status
| | | +--rw status? identityref
| | | +--rw last-change? yang:date-and-time
| | +--ro oper-status
| | +--ro status? identityref
| | +--ro last-change? yang:date-and-time
...
Figure 17: OSPF Routing Subtree Structure
The following data nodes are captured in Figure 17: The following data nodes are captured in 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 the IPv4 or dual-stack address-family is requested, it is up When the IPv4 or dual-stack address family is requested, it is up
to the implementation (e.g., network orchestrator) to decide to the implementation (e.g., network orchestrator) to decide
whether OSPFv2 [RFC4577] or OSPFv3 [RFC6565] is used to announce whether OSPFv2 [RFC4577] or OSPFv3 [RFC6565] is used to announce
IPv4 routes. Such decision will be typically reflected in the IPv4 routes. Such a decision will typically be reflected in the
device configurations that will be derived to implement the L3VPN. device configurations that will be derived to implement the L3VPN.
'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': Used to create OSPF sham links between two VPN network
network accesses sharing the same area and having a backdoor link accesses sharing the same area and having a backdoor link
(Section 4.2.7 of [RFC4577] and Section 5 of [RFC6565]). (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 Link State Advertisements
will accept. (LSAs) that the OSPF instance will accept.
'authentication': Controls the authentication schemes to be enabled 'authentication': Controls the authentication schemes to be enabled
for the OSPF instance. The following options are supported: IPsec for the OSPF instance. The following options are supported: IPsec
for OSPFv3 authentication [RFC4552], authentication trailer for for OSPFv3 authentication [RFC4552], and the Authentication
OSPFv2 [RFC5709] [RFC7474] and OSPFv3 [RFC7166]. Trailer for OSPFv2 [RFC5709] [RFC7474] and OSPFv3 [RFC7166].
'status': Indicates the status of the OSPF routing instance. 'status': Indicates the status of the OSPF routing instance.
7.6.3.4. IS-IS 7.6.3.4. IS-IS
The model (Figure 18) allows the user to configure IS-IS The model allows the user to configure IS-IS [ISO10589] [RFC1195]
[ISO10589][RFC1195][RFC5308] to run on the 'vpn-network-access' [RFC5308] to run on the 'vpn-network-access' interface. See
interface. Figure 18.
... ...
+--rw routing-protocols +--rw routing-protocols
| +--rw routing-protocol* [id] | +--rw routing-protocol* [id]
| ... | ...
| +--rw isis | +--rw isis
| | +--rw address-family? identityref | | +--rw address-family? identityref
| | +--rw area-address area-address | | +--rw area-address area-address
| | +--rw level? identityref | | +--rw level? identityref
| | +--rw metric? uint16 | | +--rw metric? uint16
| | +--rw mode? enumeration | | +--rw mode? enumeration
| | +--rw authentication | | +--rw authentication
| | | +--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? | | | | +--rw key-chain?
| | | | key-chain:key-chain-ref | | | | key-chain:key-chain-ref
| | | +--:(auth-key-explicit) | | | +--:(auth-key-explicit)
| | | +--rw key-id? uint32 | | | +--rw key-id? uint32
| | | +--rw key? string | | | +--rw key? string
| | | +--rw crypto-algorithm? identityref | | | +--rw crypto-algorithm? identityref
| | +--rw status | | +--rw status
| | +--rw admin-status | | +--rw admin-status
| | | +--rw status? identityref | | | +--rw status? identityref
| | | +--rw last-change? yang:date-and-time | | | +--rw last-change? yang:date-and-time
| | +--ro oper-status | | +--ro oper-status
| | +--ro status? identityref | | +--ro status? identityref
| | +--ro last-change? yang:date-and-time | | +--ro last-change? yang:date-and-time
... ...
Figure 18: IS-IS Routing Subtree Structure Figure 18: IS-IS Routing Subtree Structure
The following IS-IS data nodes are supported: The following IS-IS data nodes are supported:
'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.
'area-address': Indicates the IS-IS area address. 'area-address': Indicates the IS-IS area address.
'level': Indicates the IS-IS level: Level 1, Level 2, or both. 'level': Indicates the IS-IS level: Level 1, Level 2, or both.
'metric': Associates a metric with IS-IS routes. 'metric': Associates a metric with IS-IS routes.
'mode': Indicates the IS-IS interface mode type. It can be set to 'mode': Indicates the IS-IS interface mode type. It can be set to
'active' (that is, send or receive IS-IS protocol control packets) 'active' (that is, send or receive IS-IS protocol control packets)
or 'passive' (that is, suppress the sending of IS-IS updates or 'passive' (that is, suppress the sending of IS-IS updates
through the interface). through the interface).
'authentication': Controls the authentication schemes to be enabled 'authentication': Controls the authentication schemes to be enabled
for the IS-IS instance. Both the specification of a key-chain for the IS-IS instance. Both the specification of a key chain
[RFC8177] and the direct specification of key and authentication [RFC8177] and the direct specification of key and authentication
algorithm are supported. algorithms are supported.
'status': Indicates the status of the IS-IS routing instance. 'status': Indicates the status of the IS-IS routing instance.
7.6.3.5. RIP 7.6.3.5. RIP
The model (Figure 19) allows the user to configure RIP to run on the The model allows the user to configure RIP to run on the 'vpn-
'vpn-network-access' interface. network-access' interface. See Figure 19.
... ...
+--rw routing-protocols +--rw routing-protocols
| +--rw routing-protocol* [id] | +--rw routing-protocol* [id]
| ... | ...
| +--rw rip | +--rw rip
| | +--rw address-family? identityref | | +--rw address-family? identityref
| | +--rw timers | | +--rw timers
| | | +--rw update-interval? uint16 | | | +--rw update-interval? uint16
| | | +--rw invalid-interval? uint16 | | | +--rw invalid-interval? uint16
| | | +--rw holddown-interval? uint16 | | | +--rw holddown-interval? uint16
| | | +--rw flush-interval? uint16 | | | +--rw flush-interval? uint16
| | +--rw neighbor* inet:ip-address | | +--rw default-metric? uint8
| | +--rw default-metric? uint8 | | +--rw authentication
| | +--rw authentication | | | +--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?
| | | | +--rw key-chain? | | | | key-chain:key-chain-ref
| | | | key-chain:key-chain-ref | | | +--:(auth-key-explicit)
| | | +--:(auth-key-explicit) | | | +--rw key? string
| | | +--rw key? string | | | +--rw crypto-algorithm? identityref
| | | +--rw crypto-algorithm? identityref | | +--rw status
| | +--rw status | | +--rw admin-status
| | +--rw admin-status | | | +--rw status? identityref
| | | +--rw status? identityref | | | +--rw last-change? yang:date-and-time
| | | +--rw last-change? yang:date-and-time | | +--ro oper-status
| | +--ro oper-status | | +--ro status? identityref
| | +--ro status? identityref | | +--ro last-change? yang:date-and-time
| | +--ro last-change? yang:date-and-time ...
...
Figure 19: RIP Subtree Structure Figure 19: RIP Subtree Structure
As shown in Figure 19, the following RIP data nodes are supported: As shown in Figure 19, the following RIP data nodes are supported:
'address-family': Indicates whether IPv4, IPv6, or both address 'address-family': Indicates whether IPv4, IPv6, or both address
families are to be activated. This parameter is used to determine families are to be activated. This parameter is used to determine
whether RIPv2 [RFC2453] and/or RIPng are to be enabled [RFC2080]. whether RIPv2 [RFC2453], RIP Next Generation (RIPng), or both are
to be enabled [RFC2080].
'timers': Indicates the following timers: 'timers': Indicates the following timers:
'update-interval': Is the interval at which RIP updates are sent. 'update-interval': The interval at which RIP updates are sent.
'invalid-interval': Is the interval before a RIP route is 'invalid-interval': The interval before a RIP route is declared
declared invalid. invalid.
'holddown-interval': Is the interval before better RIP routes are 'holddown-interval': The interval before better RIP routes are
released. released.
'flush-interval': Is the interval before a route is removed from 'flush-interval': The interval before a route is removed from the
the routing table. routing table.
These timers are expressed in seconds. These timers are expressed in seconds.
'default-metric': Sets the default RIP metric. 'default-metric': Sets the default RIP metric.
'authentication': Controls the authentication schemes to be enabled 'authentication': Controls the authentication schemes to be enabled
for the RIP instance. for the RIP instance.
'status': Indicates the status of the RIP routing instance. 'status': Indicates the status of the RIP routing instance.
7.6.3.6. VRRP 7.6.3.6. VRRP
The model (Figure 20) allows enabling VRRP on the 'vpn-network- The model allows enabling the Virtual Router Redundancy Protocol
access' interface. (VRRP) on the 'vpn-network-access' interface. See Figure 20.
... ...
+--rw routing-protocols +--rw routing-protocols
| +--rw routing-protocol* [id] | +--rw routing-protocol* [id]
| ... | ...
| +--rw vrrp | +--rw vrrp
| +--rw address-family* identityref | +--rw address-family* identityref
| +--rw vrrp-group? uint8 | +--rw vrrp-group? uint8
| +--rw backup-peer? inet:ip-address | +--rw backup-peer? inet:ip-address
| +--rw virtual-ip-address* inet:ip-address | +--rw virtual-ip-address* inet:ip-address
| +--rw priority? uint8 | +--rw priority? uint8
| +--rw ping-reply? boolean | +--rw ping-reply? boolean
| +--rw status | +--rw status
| +--rw admin-status | +--rw admin-status
| | +--rw status? identityref | | +--rw status? identityref
| | +--rw last-change? yang:date-and-time | | +--rw last-change? yang:date-and-time
| +--ro oper-status | +--ro oper-status
| +--ro status? identityref | +--ro status? identityref
| +--ro last-change? yang:date-and-time | +--ro last-change? yang:date-and-time
... ...
Figure 20: VRRP Subtree Structure Figure 20: VRRP Subtree Structure
The following data nodes are supported: The following data nodes are 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 [RFC5798] families are to be activated. Note that VRRP version 3 [RFC5798]
supports both IPv4 and IPv6. supports both IPv4 and IPv6.
'vrrp-group': Is used to identify the VRRP group. 'vrrp-group': Used to identify the VRRP group.
'backup-peer': Carries the IP address of the peer. 'backup-peer': Carries the IP address of the peer.
'virtual-ip-address': Includes virtual IP addresses for a single 'virtual-ip-address': Includes virtual IP addresses for a single
VRRP group. VRRP group.
'priority': Assigns the VRRP election priority for the backup 'priority': Assigns the VRRP election priority for the backup
virtual router. virtual router.
'ping-reply': Controls whether ping requests can be replied to. 'ping-reply': Controls whether the VRRP speaker should reply to ping
requests.
'status': Indicates the status of the VRRP instance. 'status': Indicates the status of the VRRP instance.
Note that no authentication data node is included for VRRP as there Note that no authentication data node is included for VRRP, as there
isn't currently any type of VRRP authentication (see Section 9 of isn't any type of VRRP authentication at this time (see Section 9 of
[RFC5798]). [RFC5798]).
7.6.4. OAM 7.6.4. OAM
This container (Figure 21) defines the Operations, Administration, This container (Figure 21) defines the Operations, Administration,
and Maintenance (OAM) mechanisms used for a VPN network access. In and Maintenance (OAM) mechanisms used for a VPN network access. In
the current version of the L3NM, only BFD is supported. the current version of the L3NM, only BFD is supported.
... ...
+--rw oam +--rw oam
| +--rw bfd {vpn-common:bfd}? | +--rw bfd {vpn-common:bfd}?
| +--rw session-type? identityref | +--rw session-type? identityref
| +--rw desired-min-tx-interval? uint32 | +--rw desired-min-tx-interval? uint32
| +--rw required-min-rx-interval? uint32 | +--rw required-min-rx-interval? uint32
| +--rw local-multiplier? uint8 | +--rw local-multiplier? uint8
| +--rw holdtime? uint32 | +--rw holdtime? uint32
| +--rw profile? leafref | +--rw profile? leafref
| +--rw authentication! | +--rw authentication!
| | +--rw key-chain? key-chain:key-chain-ref | | +--rw key-chain? key-chain:key-chain-ref
| | +--rw meticulous? boolean | | +--rw meticulous? boolean
| +--rw status | +--rw status
| +--rw admin-status | +--rw admin-status
| | +--rw status? identityref | | +--rw status? identityref
| | +--rw last-change? yang:date-and-time | | +--rw last-change? yang:date-and-time
| +--ro oper-status | +--ro oper-status
| +--ro status? identityref | +--ro status? identityref
| +--ro last-change? yang:date-and-time | +--ro last-change? yang:date-and-time
... ...
Figure 21: IP Connection Subtree Structure (OAM) Figure 21: IP Connection Subtree Structure (OAM)
The following OAM data nodes can be specified: The following OAM data nodes can be specified:
'session-type': Indicates which BFD flavor is used to set up the 'session-type': Indicates which BFD flavor is used to set up the
session (e.g., classic BFD [RFC5880], Seamless BFD [RFC7880]). By session (e.g., classic BFD [RFC5880], Seamless BFD [RFC7880]). By
default, the BFD session is assumed to follow the behavior default, it is assumed that the BFD session will follow the
specified in [RFC5880]. behavior specified in [RFC5880].
'desired-min-tx-interval': Is the minimum interval, in microseconds, 'desired-min-tx-interval': The minimum interval, in microseconds,
that a PE would like to use when transmitting BFD Control packets that a PE would like to use when transmitting BFD Control packets,
less any jitter applied. less any jitter applied.
'required-min-rx-interval': Is the minimum interval, in 'required-min-rx-interval': The minimum interval, in microseconds,
microseconds, between received BFD Control packets that a PE is between received BFD Control packets that a PE is capable of
capable of supporting, less any jitter applied by the sender. supporting, less any jitter applied by the sender.
'local-multiplier': The negotiated transmit interval, multiplied by 'local-multiplier': The negotiated transmit interval, multiplied by
this value, provides the detection time for the peer. this value, provides the detection time for the peer.
'holdtime': Is used to indicate the expected BFD holddown time, in 'holdtime': Used to indicate the expected BFD holddown time, in
milliseconds. This value may be inherited from the service milliseconds. This value may be inherited from the service
request (see Section 6.3.2.2.2 of [RFC8299]). request (see Section 6.3.2.2.2 of [RFC8299]).
'profile': Refers to a BFD profile (Section 7.2). Such a profile 'profile': Refers to a BFD profile (Section 7.2). Such a profile
can be set by the provider or inherited from the service request can be set by the provider or inherited from the service request
(see Section 6.3.2.2.2 of [RFC8299]). (see Section 6.3.2.2.2 of [RFC8299]).
'authentication': Includes the required information to enable the 'authentication': Includes the required information to enable the
BFD authentication modes discussed in Section 6.7 of [RFC5880]. BFD authentication modes discussed in Section 6.7 of [RFC5880].
In particular 'meticulous' controls the activation of the In particular, 'meticulous' controls the activation of meticulous
meticulous mode discussed in Sections 6.7.3 and 6.7.4 of mode as discussed in Sections 6.7.3 and 6.7.4 of [RFC5880].
[RFC5880].
'status': Indicates the status of BFD. 'status': Indicates the status of BFD.
7.6.5. Security 7.6.5. Security
The 'security' container specifies the authentication and the The 'security' container specifies the authentication and the
encryption to be applied for a given VPN network access traffic. As encryption to be applied to traffic for a given VPN network access.
depicted in the subtree shown in Figure 22, the L3NM can be used to As depicted in the subtree shown in Figure 22, the L3NM can be used
directly control the encryption to put in place (e.g., Layer 2 or to directly control the encryption to be applied (e.g., Layer 2 or
Layer 3 encryption) or invoke a local encryption profile. Layer 3 encryption) or invoke a local encryption profile.
... ...
+--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-network-accesses +--rw vpn-network-accesses
+--rw vpn-network-access* [id] +--rw vpn-network-access* [id]
... ...
+--rw security +--rw security
| +--rw encryption {vpn-common:encryption}? | +--rw encryption {vpn-common:encryption}?
| | +--rw enabled? boolean | | +--rw enabled? boolean
| | +--rw layer? enumeration | | +--rw layer? enumeration
| +--rw encryption-profile | +--rw encryption-profile
| +--rw (profile)? | +--rw (profile)?
| +--:(provider-profile) | +--:(provider-profile)
| | +--rw profile-name? leafref | | +--rw profile-name? leafref
| +--:(customer-profile) | +--:(customer-profile)
| +--rw customer-key-chain? | +--rw customer-key-chain?
| kc:key-chain-ref | key-chain: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
7.6.6.1. Overview 7.6.6.1. Overview
The 'service' container specifies the service parameters to apply for The 'service' container specifies the service parameters to apply 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 inbound-bandwidth? uint64 {vpn-common:inbound-bw}? +--rw pe-to-ce-bandwidth? uint64 {vpn-common:inbound-bw}?
+--rw outbound-bandwidth? uint64 {vpn-common:outbound-bw}? +--rw ce-to-pe-bandwidth? uint64 {vpn-common:outbound-bw}?
+--rw mtu? uint32 +--rw mtu? uint32
+--rw qos {vpn-common:qos}? +--rw qos {vpn-common:qos}?
| ... | ...
+--rw carriers-carrier +--rw carriers-carrier
| {vpn-common:carriers-carrier}? | {vpn-common:carriers-carrier}?
| +--rw signaling-type? enumeration | +--rw signaling-type? enumeration
+--rw ntp +--rw ntp
| +--rw broadcast? enumeration | +--rw broadcast? enumeration
| +--rw auth-profile | +--rw auth-profile
| | +--rw profile-id? string | | +--rw profile-id? string
| +--rw status | +--rw status
| +--rw admin-status | +--rw admin-status
| | +--rw status? identityref | | +--rw status? identityref
| | +--rw last-change? yang:date-and-time | | +--rw last-change? yang:date-and-time
| +--ro oper-status | +--ro oper-status
| +--ro status? identityref | +--ro status? identityref
| +--ro last-change? yang:date-and-time | +--ro last-change? yang:date-and-time
+--rw multicast {vpn-common:multicast}? +--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:
'inbound-bandwidth': Indicates, in bits per second (bps), the 'pe-to-ce-bandwidth': Indicates, in bits per second (bps), the
inbound bandwidth of the connection (i.e., download bandwidth from inbound bandwidth of the connection (i.e., the download bandwidth
the service provider to the site). from the service provider to the site).
'outbound-bandwidth': Indicates, in bps, the outbound bandwidth of 'ce-to-pe-bandwidth': Indicates, in bps, the outbound bandwidth of
the connection (i.e., upload bandwidth from the site to the the connection (i.e., the upload bandwidth from the site to the
service provider). service provider).
'mtu': Indicates the MTU at the service level. 'mtu': Indicates the MTU at the service level.
'qos': Is used to define a set of QoS policies to apply on a given 'qos': Used to define a set of QoS policies to apply on a given
connection (refer to Section 7.6.6.2 for more details). connection (refer to Section 7.6.6.2 for more details).
'carriers-carrier': Groups a set of parameters that are used when 'carriers-carrier': Groups a set of parameters that are used when
Carriers' Carriers (CsC) is enabled such the use of BGP for Carriers' Carriers (CsC) is enabled, such as using BGP for
signaling purposes [RFC8277]. signaling purposes [RFC8277].
'ntp': Time synchronization may be needed in some VPNs such as 'ntp': Time synchronization may be needed in some VPNs, such as
infrastructure and management VPNs. This container is used to infrastructure and management VPNs. This container is used to
enable the NTP service [RFC5905]. 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.6.6.2. QoS 7.6.6.2. QoS
'qos' container is used to define a set of QoS policies to apply on a The 'qos' container is used to define a set of QoS policies to apply
given connection (Figure 24). A QoS policy may be a classification on a given connection (Figure 24). A QoS policy may be a
or an action policy. For example, a QoS action can be defined to classification or an action policy. For example, a QoS action can be
rate limit inbound/outbound traffic of a given class of service. defined to rate-limit inbound/outbound traffic of a given class of
service.
... ...
+--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)?
| | | | | +--:(ipv4) | | | | | +--:(ipv4)
| | | | | | ... | | | | | | ...
| | | | | +--:(ipv6) | | | | | +--:(ipv6)
| | | | | ... | | | | | ...
| | | | +--rw (l4)? | | | | +--rw (l4)?
| | | | +--:(tcp) | | | | +--:(tcp)
| | | | | ... | | | | | ...
| | | | +--:(udp) | | | | +--:(udp)
| | | | ... | | | | ...
| | | +--:(match-application) | | | +--:(match-application)
| | | +--rw match-application? | | | +--rw match-application?
| | | identityref | | | identityref
| | +--rw target-class-id? | | +--rw target-class-id? string
| | string | +--rw qos-action
| +--rw qos-action | | +--rw rule* [id]
| | +--rw rule* [id] | | +--rw id string
| | +--rw id string | | +--rw target-class-id? string
| | +--rw target-class-id? string | | +--rw inbound-rate-limit? decimal64
| | +--rw inbound-rate-limit? decimal64 | | +--rw outbound-rate-limit? decimal64
| | +--rw outbound-rate-limit? decimal64 | +--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: Overall QoS Subtree Structure
QoS classification can be based on many criteria such as: QoS classification can be based on many criteria, such as the
following:
Layer 3: As shown in Figure 25, classification can be based on any Layer 3: As shown in Figure 25, classification can be based on any
IP header field or a combination thereof. Both IPv4 and IPv6 are IP header field or a combination thereof. Both IPv4 and IPv6 are
supported. 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)?
| | | | | +--:(ipv4) | | | | | +--:(ipv4)
| | | | | | +--rw ipv4 | | | | | | +--rw ipv4
| | | | | | +--rw dscp? inet:dscp | | | | | | +--rw dscp? inet:dscp
| | | | | | +--rw ecn? uint8 | | | | | | +--rw ecn? uint8
| | | | | | +--rw length? uint16 | | | | | | +--rw length? uint16
| | | | | | +--rw ttl? uint8 | | | | | | +--rw ttl? uint8
| | | | | | +--rw protocol? uint8 | | | | | | +--rw protocol? uint8
| | | | | | +--rw ihl? uint8 | | | | | | +--rw ihl? uint8
| | | | | | +--rw flags? bits | | | | | | +--rw flags? bits
| | | | | | +--rw offset? uint16 | | | | | | +--rw offset? uint16
| | | | | | +--rw identification? uint16 | | | | | | +--rw identification? uint16
| | | | | | +--rw (destination-network)? | | | | | | +--rw (destination-network)?
| | | | | | | +--:(destination-ipv4-network) | | | | | | | +--:(destination-ipv4-network)
| | | | | | | +--rw destination-ipv4-network? | | | | | | | +--rw destination-ipv4-network?
| | | | | | | inet:ipv4-prefix | | | | | | | inet:ipv4-prefix
| | | | | | +--rw (source-network)? | | | | | | +--rw (source-network)?
| | | | | | +--:(source-ipv4-network) | | | | | | +--:(source-ipv4-network)
| | | | | | +--rw source-ipv4-network? | | | | | | +--rw source-ipv4-network?
| | | | | | inet:ipv4-prefix | | | | | | inet:ipv4-prefix
| | | | | +--:(ipv6) | | | | | +--:(ipv6)
| | | | | +--rw ipv6 | | | | | +--rw ipv6
| | | | | +--rw dscp? inet:dscp | | | | | +--rw dscp? inet:dscp
| | | | | +--rw ecn? uint8 | | | | | +--rw ecn? uint8
| | | | | +--rw length? uint16 | | | | | +--rw length? uint16
| | | | | +--rw ttl? uint8 | | | | | +--rw ttl? uint8
| | | | | +--rw protocol? uint8 | | | | | +--rw protocol? uint8
| | | | | +--rw (destination-network)? | | | | | +--rw (destination-network)?
| | | | | | +--:(destination-ipv6-network) | | | | | | +--:(destination-ipv6-network)
| | | | | | +--rw destination-ipv6-network? | | | | | | +--rw destination-ipv6-network?
| | | | | | inet:ipv6-prefix | | | | | | inet:ipv6-prefix
| | | | | +--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 discussed in [I-D.ietf-opsawg-vpn-common], any layer 4 Layer 4: As discussed in [RFC9181], any Layer 4 protocol can be
protocol can be indicated in the 'protocol' data node under 'l3' indicated in the 'protocol' data node under 'l3' (Figure 25), but
(Figure 25), but only TCP and UDP specific match criteria are only TCP- and UDP-specific match criteria are elaborated in this
elaborated in this version as these protocols are widely used in version, as these protocols are widely used in the context of VPN
the context of VPN services. Augmentations can be considered in services. Augmentations can be considered in the future to add
the future to add other Layer 4 specific data nodes, if needed. other Layer-4-specific data nodes, if needed.
TCP or UDP-related match criteria can be specified in the L3NM as TCP- or UDP-related match criteria can be specified in the L3NM,
shown in Figure 26. as shown in Figure 26.
As discussed in [I-D.ietf-opsawg-vpn-common], some transport As discussed in [RFC9181], some transport protocols use existing
protocols use existing protocols (e.g., TCP or UDP) as substrate. protocols (e.g., TCP or UDP) as the substrate. The match criteria
The match criteria for such protocols may rely upon the 'protocol' for such protocols may rely upon the 'protocol' setting under
under 'l3', TCP/UDP match criteria shown in Figure 26, part of the 'l3', TCP/UDP match criteria as shown in Figure 26, part of the
TCP/UDP payload, or a combination thereof. This version of the TCP/UDP payload, or a combination thereof. This version of the
module does not support such advanced match criteria. Future module does not support such advanced match criteria. Future
revisions of the VPN common module or augmentations to the L3NM revisions of the VPN common module or augmentations to the L3NM
may consider adding match criteria based on the transport protocol may consider adding match criteria based on the transport protocol
payload (e.g., by means of a bitmask match). payload (e.g., by means of a bitmask match).
+--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 54, line 8 skipping to change at line 2293
| | | | | | +--:(range) | | | | | | +--:(range)
| | | | | | | +--rw lower-port | | | | | | | +--rw lower-port
| | | | | | | | inet:port-number | | | | | | | | inet:port-number
| | | | | | | +--rw upper-port | | | | | | | +--rw upper-port
| | | | | | | inet:port-number | | | | | | | inet:port-number
| | | | | | +--:(operator) | | | | | | +--:(operator)
| | | | | | +--rw operator? operator | | | | | | +--rw operator? operator
| | | | | | +--rw port | | | | | | +--rw port
| | | | | | inet:port-number | | | | | | inet:port-number
| | | | | +--rw (destination-port)? | | | | | +--rw (destination-port)?
| | | | +--:(destination-port-range-or-operator) | | | | | +--:(destination-port-range-or-operator)
| | | | | +--rw destination-port-range-or-operator | | | | | +--rw destination-port-range-or-operator
| | | | | +--rw (port-range-or-operator)? | | | | | +--rw (port-range-or-operator)?
| | | | | +--:(range) | | | | | +--:(range)
| | | | | | +--rw lower-port | | | | | | +--rw lower-port
| | | | | | | inet:port-number | | | | | | | inet:port-number
| | | | | | +--rw upper-port | | | | | | +--rw upper-port
| | | | | | inet:port-number | | | | | | inet:port-number
| | | | | +--:(operator) | | | | | +--:(operator)
| | | | | +--rw operator? operator | | | | | +--rw operator? operator
| | | | | +--rw port | | | | | +--rw port
skipping to change at page 54, line 51 skipping to change at line 2336
| | | | | +--rw lower-port | | | | | +--rw lower-port
| | | | | | inet:port-number | | | | | | inet:port-number
| | | | | +--rw upper-port | | | | | +--rw upper-port
| | | | | inet:port-number | | | | | inet:port-number
| | | | +--:(operator) | | | | +--:(operator)
| | | | +--rw operator? operator | | | | +--rw operator? operator
| | | | +--rw port | | | | +--rw port
| | | | inet:port-number | | | | inet:port-number
... ...
Figure 26: QoS Subtree Structure (L4) Figure 26: QoS Subtree Structure (L4)
Application match: Relies upon application-specific classification. Application match: Relies upon application-specific classification
(Figure 24).
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 various levels: VPN service, VPN node groups (Figure 28)) can be controlled at various levels: VPN service,
level, or VPN network access. VPN node level, or VPN network access.
... ...
+--rw vpn-services +--rw vpn-services
+--rw vpn-service* [vpn-id] +--rw vpn-service* [vpn-id]
... ...
+--rw vpn-instance-profiles +--rw vpn-instance-profiles
| +--rw vpn-instance-profile* [profile-id] | +--rw vpn-instance-profile* [profile-id]
| .... | ....
| +--rw multicast {vpn-common:multicast}? | +--rw multicast {vpn-common:multicast}?
| ... | ...
+--rw vpn-nodes +--rw vpn-nodes
+--rw vpn-node* [vpn-node-id] +--rw vpn-node* [vpn-node-id]
... ...
+--rw active-vpn-instance-profiles +--rw active-vpn-instance-profiles
| +--rw vpn-instance-profile* [profile-id] | +--rw vpn-instance-profile* [profile-id]
| ... | ...
| +--rw multicast {vpn-common:multicast}? | +--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 instance profile level has Multicast-related data nodes at the VPN instance profile level have
the structure that is shown in Figure 30. the structure shown in Figure 28.
... ...
+--rw vpn-services +--rw vpn-services
+--rw vpn-service* [vpn-id] +--rw vpn-service* [vpn-id]
... ...
+--rw vpn-instance-profiles +--rw vpn-instance-profiles
| +--rw vpn-instance-profile* [profile-id] | +--rw vpn-instance-profile* [profile-id]
| .... | ....
| +--rw multicast {vpn-common:multicast}? | +--rw multicast {vpn-common:multicast}?
| +--rw tree-flavor? identityref | +--rw tree-flavor? identityref
| +--rw rp | +--rw rp
| | +--rw rp-group-mappings | | +--rw rp-group-mappings
| | | +--rw rp-group-mapping* [id] | | | +--rw rp-group-mapping* [id]
| | | +--rw id uint16 | | | +--rw id uint16
| | | +--rw provider-managed | | | +--rw provider-managed
| | | | +--rw enabled? boolean | | | | +--rw enabled? boolean
| | | | +--rw rp-redundancy? boolean | | | | +--rw rp-redundancy? boolean
| | | | +--rw optimal-traffic-delivery? boolean | | | | +--rw optimal-traffic-delivery? boolean
| | | | +--rw anycast | | | | +--rw anycast
| | | | +--rw local-address? inet:ip-address | | | | +--rw local-address? inet:ip-address
| | | | +--rw rp-set-address* inet:ip-address | | | | +--rw rp-set-address* inet:ip-address
| | | +--rw rp-address inet:ip-address | | | +--rw rp-address inet:ip-address
| | | +--rw groups | | | +--rw groups
| | | +--rw group* [id] | | | +--rw group* [id]
| | | +--rw id uint16 | | | +--rw id uint16
| | | +--rw (group-format) | | | +--rw (group-format)
| | | +--:(group-prefix) | | | +--:(group-prefix)
| | | | +--rw group-address? inet:ip-prefix | | | | +--rw group-address?
| | | +--:(startend) | | | | inet:ip-prefix
| | | +--rw group-start? inet:ip-address | | | +--:(startend)
| | | +--rw group-end? inet:ip-address | | | +--rw group-start?
| | +--rw rp-discovery | | | | inet:ip-address
| | +--rw rp-discovery-type? identityref | | | +--rw group-end?
| | +--rw bsr-candidates | | | | inet:ip-address
| | +--rw bsr-candidate-address* inet:ip-address | | +--rw rp-discovery
| +--rw igmp {vpn-common:igmp and vpn-common:ipv4}? | | +--rw rp-discovery-type? identityref
| | +--rw static-group* [group-addr] | | +--rw bsr-candidates
| | | +--rw group-addr | | +--rw bsr-candidate-address*
| | | | rt-types:ipv4-multicast-group-address | | | inet:ip-address
| | | +--rw source-addr? | +--rw igmp {vpn-common:igmp and vpn-common:ipv4}?
| | | rt-types:ipv4-multicast-source-address | | +--rw static-group* [group-addr]
| | +--rw max-groups? uint32 | | | +--rw group-addr
| | +--rw max-entries? uint32 | | | | rt-types:ipv4-multicast-group-address
| | +--rw version? identityref | | | +--rw source-addr?
| +--rw mld {vpn-common:mld and vpn-common:ipv6}? | | | rt-types:ipv4-multicast-source-address
| | +--rw static-group* [group-addr] | | +--rw max-groups? uint32
| | | +--rw group-addr | | +--rw max-entries? uint32
| | | | rt-types:ipv6-multicast-group-address | | +--rw version? identityref
| | | +--rw source-addr? | +--rw mld {vpn-common:mld and vpn-common:ipv6}?
| | | rt-types:ipv6-multicast-source-address | | +--rw static-group* [group-addr]
| | +--rw max-groups? uint32 | | | +--rw group-addr
| | +--rw max-entries? uint32 | | | | rt-types:ipv6-multicast-group-address
| | +--rw version? identityref | | | +--rw source-addr?
| +--rw pim {vpn-common:pim}? | | | rt-types:ipv6-multicast-source-address
| +--rw hello-interval? rt-types:timer-value-seconds16 | | +--rw max-groups? uint32
| +--rw dr-priority? 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) Figure 28: Multicast Subtree Structure (VPN Instance Profile Level)
The model supports a single type of tree per VPN access ('tree- The model supports a single type of tree per VPN access ('tree-
flavor'): Any-Source Multicast (ASM), Source-Specific Multicast flavor'): Any-Source Multicast (ASM), Source-Specific Multicast
(SSM), or bidirectional. (SSM), or bidirectional.
When ASM is used, the model supports the configuration of Rendezvous When ASM is used, the model supports the configuration of Rendezvous
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 mappings MUST be When set to 'static', RP-to-multicast-group mappings 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.
The model supports RP redundancy through the 'rp-redundancy' leaf. The model supports RP redundancy through the 'rp-redundancy' leaf.
How the redundancy is achieved is out of scope. How the redundancy is achieved is out of scope.
When a particular VPN using ASM requires a more optimal traffic When a particular VPN using ASM requires traffic delivery that is
delivery (e.g., requested using [RFC8299]), 'optimal-traffic- more optimal (e.g., requested per the guidance in [RFC8299]),
delivery' can be set. When set to 'true', the implementation must 'optimal-traffic-delivery' can be set. When set to 'true', the
use any mechanism to provide a more optimal traffic delivery for the implementation must use any mechanism to provide traffic delivery
customer. For example, anycast is one of the mechanisms to enhance that is more optimal for the customer. For example, anycast is one
RPs redundancy, resilience against failures, and to recover from of the mechanisms for enhancing RP redundancy, providing resilience
failures quickly. against failures, and recovering from failures quickly.
The same structure as the one depicted in Figure 30 is used when When configuring multicast-related parameters at the VPN node level
configuring multicast-related parameters at the VPN node level. When (Figure 29), the same structure as the structure depicted in
defined at the VPN node level (Figure 29), Internet Group Management Figure 30 is used. When defined at the VPN node level, Internet
Protocol (IGMP) [RFC1112][RFC2236][RFC3376], Multicast Listener Group Management Protocol (IGMP) parameters [RFC1112] [RFC2236]
Discovery (MLD) [RFC2710][RFC3810], and Protocol Independent [RFC3376], Multicast Listener Discovery (MLD) parameters [RFC2710]
Multicast (PIM) [RFC7761] parameters are applicable to all VPN [RFC3810], and Protocol Independent Multicast (PIM) parameters
network accesses of that VPN node unless corresponding nodes are [RFC7761] are applicable to all VPN network accesses of that VPN node
overridden at the VPN network access level. unless corresponding nodes are overridden at the VPN network access
level.
... ...
+--rw vpn-nodes +--rw vpn-nodes
+--rw vpn-node* [vpn-node-id] +--rw vpn-node* [vpn-node-id]
... ...
+--rw active-vpn-instance-profiles +--rw active-vpn-instance-profiles
| +--rw vpn-instance-profile* [profile-id] | +--rw vpn-instance-profile* [profile-id]
| ... | ...
| +--rw multicast {vpn-common:multicast}? | +--rw multicast {vpn-common:multicast}?
| +--rw tree-flavor* identityref | +--rw tree-flavor* identityref
| +--rw rp | +--rw rp
| | ... | | ...
| +--rw igmp {vpn-common:igmp and vpn-common:ipv4}? | +--rw igmp {vpn-common:igmp and vpn-common:ipv4}?
| | ... | | ...
| +--rw mld {vpn-common:mld and vpn-common:ipv6}? | +--rw mld {vpn-common:mld and vpn-common:ipv6}?
| | ... | | ...
| +--rw pim {vpn-common:pim}? | +--rw pim {vpn-common:pim}?
| ... | ...
Figure 29: Multicast Subtree Structure (VPN Node Level) Figure 29: Multicast Subtree Structure (VPN Node Level)
Multicast-related data nodes at the VPN network access level are Multicast-related data nodes at the VPN network access level are
shown in Figure 30. The values configured at the VPN network access shown in Figure 30. The values configured at the VPN network access
level override the values configured for the corresponding data nodes level override the values configured for the corresponding data nodes
in other levels. at other levels.
... ...
+--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}?
+--rw access-type? enumeration +--rw access-type? enumeration
+--rw address-family? identityref +--rw address-family? identityref
+--rw protocol-type? enumeration +--rw protocol-type? enumeration
+--rw remote-source? boolean +--rw remote-source? boolean
+--rw igmp {vpn-common:igmp}? +--rw igmp {vpn-common:igmp}?
| +--rw static-group* [group-addr] | +--rw static-group* [group-addr]
| | +--rw group-addr | | +--rw group-addr
| | rt-types:ipv4-multicast-group-address | | rt-types:ipv4-multicast-group-address
| | +--rw source-addr? | | +--rw source-addr?
| | rt-types:ipv4-multicast-source-address | | rt-types:ipv4-multicast-source-address
| +--rw max-groups? uint32 | +--rw max-groups? uint32
| +--rw max-entries? uint32 | +--rw max-entries? uint32
| +--rw max-group-sources? uint32 | +--rw max-group-sources? uint32
| +--rw version? identityref | +--rw version? identityref
| +--rw status | +--rw status
| +--rw admin-status | +--rw admin-status
| | +--rw status? identityref | | +--rw status? identityref
| | +--rw last-change? yang:date-and-time | | +--rw last-change? yang:date-and-time
| +--ro oper-status | +--ro oper-status
| +--ro status? identityref | +--ro status? identityref
| +--ro last-change? yang:date-and-time | +--ro last-change? yang:date-and-time
+--rw mld {vpn-common:mld}? +--rw mld {vpn-common:mld}?
| +--rw static-group* [group-addr] | +--rw static-group* [group-addr]
| | +--rw group-addr | | +--rw group-addr
| | rt-types:ipv6-multicast-group-address | | rt-types:ipv6-multicast-group-address
| | +--rw source-addr? | | +--rw source-addr?
| | rt-types:ipv6-multicast-source-address | | rt-types:ipv6-multicast-source-address
| +--rw max-groups? uint32 | +--rw max-groups? uint32
| +--rw max-entries? uint32 | +--rw max-entries? uint32
| +--rw max-group-sources? uint32 | +--rw max-group-sources? uint32
| +--rw version? identityref | +--rw version? identityref
| +--rw status | +--rw status
| +--rw admin-status | +--rw admin-status
| | +--rw status? identityref | | +--rw status? identityref
| | +--rw last-change? yang:date-and-time | | +--rw last-change? yang:date-and-time
| +--ro oper-status | +--ro oper-status
| +--ro status? identityref | +--ro status? identityref
skipping to change at page 59, line 41 skipping to change at line 2559
| +--rw status? identityref | +--rw status? identityref
| +--rw last-change? yang:date-and-time | +--rw last-change? yang:date-and-time
+--ro oper-status +--ro oper-status
+--ro status? identityref +--ro status? identityref
+--ro last-change? yang:date-and-time +--ro last-change? yang:date-and-time
Figure 30: Multicast Subtree Structure (VPN Network Access Level) 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 [RFC8343]. It also This module uses types defined in [RFC6991], [RFC8343], and
uses groupings defined in [RFC8519], [RFC8177], and [RFC8294]. [RFC9181]. It also uses groupings defined in [RFC8519], [RFC8177],
and [RFC8294].
<CODE BEGINS> file "ietf-l3vpn-ntw@2021-09-28.yang" <CODE BEGINS> file "ietf-l3vpn-ntw@2022-01-19.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 9181: A Common YANG Data Model for Layer 2 and Layer 3
VPNs";
} }
import ietf-inet-types { import ietf-inet-types {
prefix inet; prefix inet;
reference reference
"RFC 6991: Common YANG Data Types, Section 4"; "RFC 6991: Common YANG Data Types, Section 4";
} }
import ietf-yang-types { import ietf-yang-types {
prefix yang; prefix yang;
reference reference
"RFC 6991: Common YANG Data Types, Section 3"; "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 Data Model for Key Chains";
} }
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 { import ietf-interfaces {
prefix if; prefix if;
reference reference
"RFC 8343: A YANG Data Model for Interface Management"; "RFC 8343: A YANG Data Model for Interface Management";
} }
organization organization
"IETF OPSAWG (Operations and Management Area Working Group)"; "IETF OPSAWG (Operations and Management Area Working Group)";
contact contact
"WG Web: <https://datatracker.ietf.org/wg/opsawg/> "WG Web: <https://datatracker.ietf.org/wg/opsawg/>
WG List: <mailto:opsawg@ietf.org> WG List: <mailto:opsawg@ietf.org>
Author: 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) 2022 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 without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License to the license terms contained in, the Revised BSD License
set forth in Section 4.c 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
(http://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see This version of this YANG module is part of RFC 9182; see the
the RFC itself for full legal notices."; RFC itself for full legal notices.";
revision 2021-09-28 { revision 2022-01-19 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC XXXX: A Layer 3 VPN Network YANG Model"; "RFC 9182: A YANG Network Data Model for Layer 3 VPNs";
} }
/* Features */ /* Features */
feature msdp { feature msdp {
description description
"This feature indicates that Multicast Source Discovery Protocol "This feature indicates that Multicast Source Discovery
(MSDP) capabilities are supported by the VPN."; Protocol (MSDP) capabilities are supported by the VPN.";
reference reference
"RFC 3618: Multicast Source Discovery Protocol (MSDP)"; "RFC 3618: Multicast Source Discovery Protocol (MSDP)";
} }
/* Identities */ /* Identities */
identity address-allocation-type { identity address-allocation-type {
description description
"Base identity for address allocation type in the "Base identity for address allocation type in the
Provider Edge (PE)-Customer Edge (CE) link."; Provider Edge to Customer Edge (PE-CE) link.";
} }
identity provider-dhcp { identity provider-dhcp {
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.";
} }
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"; 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
as well as IPv6 Stateless Address Autoconfiguration (SLAAC)."; customer as well as IPv6 Stateless Address
Autoconfiguration (SLAAC).";
reference reference
"RFC 4862: 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's network provides static IP addressing to the "The provider's network provides static IP addressing to the
customer."; customer.";
} }
identity slaac { identity slaac {
if-feature "vpn-common:ipv6"; if-feature "vpn-common:ipv6";
base address-allocation-type; base address-allocation-type;
description description
"The Provider's network uses IPv6 SLAAC to provide addressing "The provider's network uses IPv6 SLAAC to provide
to the customer."; addressing to the customer.";
reference reference
"RFC 4862: IPv6 Stateless Address Autoconfiguration"; "RFC 4862: IPv6 Stateless Address Autoconfiguration";
} }
identity local-defined-next-hop { identity local-defined-next-hop {
description description
"Base identity of local defined next-hops."; "Base identity of local defined next hops.";
} }
identity discard { identity discard {
base local-defined-next-hop; base local-defined-next-hop;
description description
"Indicates an action to discard traffic for the "Indicates an action to discard traffic for the
corresponding destination. corresponding destination.
For example, this can be used to blackhole traffic."; For example, this can be used to black-hole 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
prefix as though they are connected to a local link."; next-hop prefix as though they are connected to a local
link.";
} }
identity l2-tunnel-type { identity l2-tunnel-type {
description description
"Base identity for layer-2 tunnel selection under the VPN "Base identity for Layer 2 tunnel selection under the VPN
network access."; network access.";
} }
identity pseudowire { identity pseudowire {
base l2-tunnel-type; base l2-tunnel-type;
description description
"Pseudowire tunnel termination in the VPN network access."; "Pseudowire tunnel termination in the VPN network access.";
} }
identity vpls { identity vpls {
skipping to change at page 63, line 40 skipping to change at line 2755
termination in the VPN network access."; termination in the VPN network access.";
} }
/* Typedefs */ /* 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."; "Predefined next-hop designation for locally generated
routes.";
} }
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.";
} }
skipping to change at page 64, line 4 skipping to change at line 2768
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 */ /* Groupings */
grouping vpn-instance-profile { grouping vpn-instance-profile {
description description
"Grouping for data nodes that may be factorized "Grouping for data nodes that may be factorized
among many levels of the model. The grouping can among many levels of the model. The grouping can
be used to define generic profiles at the VPN service be used to define generic profiles at the VPN service
level and then referenced at the VPN node and VPN level and then referenced at the VPN node and VPN
network access levels."; network access levels.";
leaf local-as { leaf local-as {
if-feature "vpn-common:rtg-bgp"; if-feature "vpn-common:rtg-bgp";
type inet:as-number; type inet:as-number;
description description
"Provider's Autonomous System (AS) number. Used if the "Provider's Autonomous System (AS) number. Used if the
customer requests BGP routing."; customer requests BGP routing.";
} }
uses vpn-common:route-distinguisher; uses vpn-common:route-distinguisher;
list address-family { list address-family {
key "address-family"; key "address-family";
description description
"Set of per-address family parameters."; "Set of parameters per address family.";
leaf address-family { leaf address-family {
type identityref { type identityref {
base vpn-common:address-family; base vpn-common:address-family;
} }
description description
"Indicates the address family (IPv4 and/or IPv6)."; "Indicates the address family (IPv4 and/or IPv6).";
} }
container vpn-targets { container vpn-targets {
description description
"Set of route targets to match for import and export routes "Set of route targets to match for import and export
to/from VRF."; routes to/from VRF.";
uses vpn-common:vpn-route-targets; uses vpn-common:vpn-route-targets;
} }
list maximum-routes { list maximum-routes {
key "protocol"; key "protocol";
description description
"Defines the maximum number of routes for the VRF."; "Defines the maximum number of routes for VRF.";
leaf protocol { leaf protocol {
type identityref { type identityref {
base vpn-common:routing-protocol-type; base vpn-common:routing-protocol-type;
} }
description description
"Indicates the routing protocol. 'any' value can "Indicates the routing protocol. A value of 'any'
be used to identify a limit that will apply for can be used to identify a limit that will apply for
each active routing protocol."; each active routing protocol.";
} }
leaf maximum-routes { leaf maximum-routes {
type uint32; type uint32;
description description
"Indicates the maximum number of prefixes that the "Indicates the maximum number of prefixes that VRF can
VRF can accept for this address family and protocol."; accept for this address family and protocol.";
} }
} }
} }
container multicast { container multicast {
if-feature "vpn-common:multicast"; if-feature "vpn-common:multicast";
description description
"Global multicast parameters."; "Global multicast parameters.";
leaf tree-flavor { leaf tree-flavor {
type identityref { type identityref {
base vpn-common:multicast-tree-type; base vpn-common:multicast-tree-type;
} }
description description
"Type of the multicast tree to be used."; "Type of the multicast tree to be used.";
} }
container rp { container rp {
description description
"Rendezvous Point (RP) parameters."; "Rendezvous Point (RP) parameters.";
container rp-group-mappings { container rp-group-mappings {
description description
"RP-to-group mappings parameters."; "RP-to-group mapping parameters.";
list rp-group-mapping { list rp-group-mapping {
key "id"; key "id";
description description
"List of RP-to-group mappings."; "List of RP-to-group mappings.";
leaf id { leaf id {
type uint16; type uint16;
description description
"Unique identifier for the mapping."; "Unique identifier for the mapping.";
} }
container provider-managed { container provider-managed {
description description
"Parameters for a provider-managed RP."; "Parameters for a provider-managed RP.";
leaf enabled { leaf enabled {
type boolean; type boolean;
default "false"; default "false";
description description
"Set to true if the Rendezvous Point (RP) "Set to 'true' if the RP must be a
must be a provider-managed node. Set to provider-managed node. Set to 'false' if it is
false if it is a customer-managed node."; a customer-managed node.";
} }
leaf rp-redundancy { leaf rp-redundancy {
type boolean; type boolean;
default "false"; default "false";
description description
"If set to true, it indicates that a redundancy "If set to 'true', it indicates that a
mechanism for the RP is required."; redundancy mechanism for the RP is required.";
} }
leaf optimal-traffic-delivery { leaf optimal-traffic-delivery {
type boolean; type boolean;
default "false"; default "false";
description description
"If set to true, the service provider (SP) must "If set to 'true', the service provider (SP)
ensure that the traffic uses an optimal path. must ensure that the traffic uses an optimal
An SP may use Anycast RP or RP-tree-to-SPT path. An SP may use Anycast RP or
RP-tree-to-SPT ('SPT' is 'shortest path tree')
switchover architectures."; switchover architectures.";
} }
container anycast { container anycast {
when "../rp-redundancy = 'true' and when "../rp-redundancy = 'true' and
../optimal-traffic-delivery = 'true'" { ../optimal-traffic-delivery = 'true'" {
description description
"Only applicable if both RP redundancy and "Only applicable if both RP redundancy and
delivery through optimal path are delivery through an optimal path are
activated."; activated.";
} }
description description
"PIM Anycast-RP parameters."; "PIM Anycast-RP parameters.";
leaf local-address { leaf local-address {
type inet:ip-address; type inet:ip-address;
description description
"IP local address for PIM RP. Usually, it "IP local address for the PIM RP. Usually
corresponds to the Router ID or the corresponds to the Router ID or the
primary address."; primary address.";
} }
leaf-list rp-set-address { leaf-list rp-set-address {
type inet:ip-address; type inet:ip-address;
description description
"Specifies the IP address of other RP routers "Specifies the IP address of other RP routers
that share the same RP IP address."; that share the same RP IP address.";
} }
} }
} }
leaf rp-address { leaf rp-address {
when "../provider-managed/enabled = 'false'" { when "../provider-managed/enabled = 'false'" {
description description
"Relevant when the RP is not "Relevant when the RP is not managed by the
provider-managed."; provider.";
} }
type inet:ip-address; type inet:ip-address;
mandatory true; mandatory true;
description description
"Defines the address of the RP. "Defines the address of the RP.
Used if the RP is customer-managed."; Used if the RP is managed by the customer.";
} }
container groups { container groups {
description description
"Multicast groups associated with the RP."; "Multicast groups associated with the RP.";
list group { list group {
key "id"; key "id";
description description
"List of multicast groups."; "List of multicast groups.";
leaf id { leaf id {
type uint16; type uint16;
skipping to change at page 68, line 12 skipping to change at line 2970
base vpn-common:multicast-rp-discovery-type; base vpn-common:multicast-rp-discovery-type;
} }
default "vpn-common:static-rp"; default "vpn-common:static-rp";
description description
"Type of RP discovery used."; "Type of RP discovery used.";
} }
container bsr-candidates { container bsr-candidates {
when "derived-from-or-self(../rp-discovery-type, " when "derived-from-or-self(../rp-discovery-type, "
+ "'vpn-common:bsr-rp')" { + "'vpn-common:bsr-rp')" {
description description
"Only applicable if discovery type is BSR-RP."; "Only applicable if the discovery type
is 'bsr-rp'.";
} }
description description
"Container for the customer Bootstrap Router (BSR) "Container for the customer Bootstrap Router (BSR)
candidate's addresses."; candidate's addresses.";
leaf-list bsr-candidate-address { leaf-list bsr-candidate-address {
type inet:ip-address; type inet:ip-address;
description description
"Specifies the address of candidate BSR."; "Specifies the address of the candidate BSR.";
} }
} }
} }
} }
container igmp { container igmp {
if-feature "vpn-common:igmp and vpn-common:ipv4"; if-feature "vpn-common:igmp and vpn-common:ipv4";
description description
"Includes IGMP-related parameters."; "Includes IGMP-related parameters.";
list static-group { list static-group {
key "group-addr"; key "group-addr";
description description
"Multicast static source/group associated to the "Multicast static source/group associated with the
IGMP session."; IGMP session.";
leaf group-addr { leaf group-addr {
type rt-types:ipv4-multicast-group-address; type rt-types:ipv4-multicast-group-address;
description description
"Multicast group IPv4 address."; "Multicast group IPv4 address.";
} }
leaf source-addr { leaf source-addr {
type rt-types:ipv4-multicast-source-address; type rt-types:ipv4-multicast-source-address;
description description
"Multicast source IPv4 address."; "Multicast source IPv4 address.";
skipping to change at page 69, line 16 skipping to change at line 3023
} }
leaf version { leaf version {
type identityref { type identityref {
base vpn-common:igmp-version; base vpn-common:igmp-version;
} }
default "vpn-common:igmpv2"; default "vpn-common:igmpv2";
description description
"Indicates the IGMP version."; "Indicates the IGMP version.";
reference reference
"RFC 1112: Host Extensions for IP Multicasting "RFC 1112: Host Extensions for IP Multicasting
RFC 2236: Internet Group Management Protocol, Version 2 RFC 2236: Internet Group Management Protocol,
RFC 3376: Internet Group Management Protocol, Version 3"; Version 2
RFC 3376: Internet Group Management Protocol,
Version 3";
} }
} }
container mld { container mld {
if-feature "vpn-common:mld and vpn-common:ipv6"; if-feature "vpn-common:mld and vpn-common:ipv6";
description description
"Includes MLD-related parameters."; "Includes MLD-related parameters.";
list static-group { list static-group {
key "group-addr"; key "group-addr";
description description
"Multicast static source/group associated with the "Multicast static source/group associated with the
skipping to change at page 70, line 11 skipping to change at line 3068
} }
leaf version { leaf version {
type identityref { type identityref {
base vpn-common:mld-version; base vpn-common:mld-version;
} }
default "vpn-common:mldv2"; default "vpn-common:mldv2";
description description
"Indicates the MLD protocol version."; "Indicates the MLD protocol version.";
reference reference
"RFC 2710: Multicast Listener Discovery (MLD) for IPv6 "RFC 2710: Multicast Listener Discovery (MLD) for IPv6
RFC 3810: Multicast Listener Discovery Version 2 (MLDv2) RFC 3810: Multicast Listener Discovery Version 2
for IPv6"; (MLDv2) for IPv6";
} }
} }
container pim { container pim {
if-feature "vpn-common:pim"; if-feature "vpn-common:pim";
description description
"Only applies when protocol type is PIM."; "Only applies when the protocol type is 'pim'.";
leaf hello-interval { leaf hello-interval {
type rt-types:timer-value-seconds16; type rt-types:timer-value-seconds16;
default "30"; default "30";
description description
"PIM hello-messages interval. If set to "Interval between PIM Hello messages. If set to
'infinity' or 'not-set', no periodic 'infinity' or 'not-set', no periodic Hello messages
Hello messages are sent."; are sent.";
reference reference
"RFC 7761: Protocol Independent Multicast - Sparse "RFC 7761: Protocol Independent Multicast - Sparse
Mode (PIM-SM): Protocol Specification (Revised), Mode (PIM-SM): Protocol Specification
Section 4.11"; (Revised), Section 4.11
RFC 8294: Common YANG Data Types for the Routing
Area";
} }
leaf dr-priority { leaf dr-priority {
type uint32; type uint32;
default "1"; default "1";
description description
"Indicates the preference in the Designated Router (DR) "Indicates the preference associated with the
election process. A larger value has a higher Designated Router (DR) election process. A larger
priority over a smaller value."; value has a higher priority over a smaller value.";
reference reference
"RFC 7761: Protocol Independent Multicast - Sparse "RFC 7761: Protocol Independent Multicast - Sparse
Mode (PIM-SM): Protocol Specification (Revised), Mode (PIM-SM): Protocol Specification
Section 4.3.2"; (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 management of Layer 3 Virtual Private
Network (L3VPN) services.";
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
service."; in the VPN service.";
uses vpn-common:vpn-profile-cfg; uses vpn-common:vpn-profile-cfg;
} }
container vpn-services { container vpn-services {
description description
"Container for the VPN services."; "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 be an L3SM, a slice request, a VPN+ A parent service can be an L3SM, a slice request,
service, etc."; a VPN+ 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 {
skipping to change at page 72, line 19 skipping to change at line 3175
} }
default "vpn-common:any-to-any-role"; default "vpn-common:any-to-any-role";
description description
"Role of the VPN node in the VPN."; "Role of the VPN node in the VPN.";
} }
uses vpn-instance-profile; uses vpn-instance-profile;
} }
} }
container underlay-transport { container underlay-transport {
description description
"Container for underlay transport."; "Container for the 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
"Container for external connectivity."; "Container for external connectivity.";
choice profile { choice profile {
description description
"Choice for the external connectivity profile."; "Choice for the external connectivity profile.";
case profile { case profile {
leaf profile-name { leaf profile-name {
type leafref { type leafref {
path "/l3vpn-ntw/vpn-profiles" path "/l3vpn-ntw/vpn-profiles"
+ "/valid-provider-identifiers" + "/valid-provider-identifiers"
+ "/external-connectivity-identifier/id"; + "/external-connectivity-identifier/id";
} }
description description
"Name of the service provider's profile to be applied "Name of the service provider's profile to be
at the VPN service level."; applied at the VPN service level.";
} }
} }
} }
} }
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
skipping to change at page 73, line 15 skipping to change at line 3219
"An identifier of the VPN node."; "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
node is deployed."; the VPN node is deployed.";
} }
leaf local-as { leaf local-as {
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. Used if the customer
routing."; requests BGP routing.";
} }
leaf router-id { leaf router-id {
type rt-types:router-id; type rt-types:router-id;
description description
"A 32-bit number in the dotted-quad format that is used "A 32-bit number in the dotted-quad format that is
to uniquely identify a node within an autonomous used to uniquely identify a node within an AS.
system. This identifier is used for both IPv4 and This identifier is used for both IPv4 and IPv6.";
IPv6.";
} }
container active-vpn-instance-profiles { container active-vpn-instance-profiles {
description description
"Container for active VPN instance profiles."; "Container for active VPN instance profiles.";
list vpn-instance-profile { list vpn-instance-profile {
key "profile-id"; key "profile-id";
description description
"Includes a list of active VPN instance profiles."; "Includes a list of active VPN instance
profiles.";
leaf profile-id { leaf profile-id {
type leafref { type leafref {
path "/l3vpn-ntw/vpn-services/vpn-service" path "/l3vpn-ntw/vpn-services/vpn-service"
+ "/vpn-instance-profiles/vpn-instance-profile" + "/vpn-instance-profiles"
+ "/profile-id"; + "/vpn-instance-profile/profile-id";
} }
description description
"Node's active VPN instance profile."; "Node's active VPN instance profile.";
} }
list router-id { list router-id {
key "address-family"; key "address-family";
description description
"Router-id per address family."; "Router ID per address family.";
leaf address-family { leaf address-family {
type identityref { type identityref {
base vpn-common:address-family; base vpn-common:address-family;
} }
description description
"Indicates the address family for which the "Indicates the address family for which the
Router-ID applies."; Router ID applies.";
} }
leaf router-id { leaf router-id {
type inet:ip-address; type inet:ip-address;
description description
"The router-id information can be an IPv4 or IPv6 "The 'router-id' information can be an IPv4
address. This can be used, for example, to or IPv6 address. This can be used,
configure an IPv6 address as a router-id for example, to configure an IPv6 address
when such capability is supported by underlay as a Router ID when such a capability is
routers. In such case, the configured value supported by underlay routers. In such a
overrides the generic one defined at the VPN case, the configured value overrides the
node level."; generic value defined at the VPN node
level.";
} }
} }
uses vpn-instance-profile; uses vpn-instance-profile;
} }
} }
container msdp { container msdp {
if-feature "msdp"; if-feature "msdp";
description description
"Includes MSDP-related parameters."; "Includes MSDP-related parameters.";
leaf peer { leaf peer {
skipping to change at page 75, line 18 skipping to change at line 3319
type vpn-common:vpn-id; type vpn-common:vpn-id;
description description
"Identifier for the network access."; "Identifier for the network access.";
} }
leaf interface-id { leaf interface-id {
type string; type string;
description description
"Identifier for the physical or logical "Identifier for the physical or logical
interface. interface.
The identification of the sub-interface The identification of the sub-interface
is provided at the connection and/or IP is provided at the connection level and/or
connection levels."; the IP connection level.";
} }
leaf description { leaf description {
type string; type string;
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."; point to point.";
} }
leaf vpn-instance-profile { leaf vpn-instance-profile {
type leafref { type leafref {
path "/l3vpn-ntw/vpn-services/vpn-service/vpn-nodes" path "/l3vpn-ntw/vpn-services/vpn-service"
+ "/vpn-node/active-vpn-instance-profiles" + "/vpn-nodes/vpn-node"
+ "/active-vpn-instance-profiles"
+ "/vpn-instance-profile/profile-id"; + "/vpn-instance-profile/profile-id";
} }
description description
"An identifier of an active VPN instance profile."; "An identifier of an active VPN instance
profile.";
} }
uses vpn-common:service-status; uses vpn-common:service-status;
container connection { container connection {
description description
"Defines layer 2 protocols and parameters that are "Defines Layer 2 protocols and parameters that
required to enable connectivity between the PE are required to enable connectivity between
and the CE."; the PE and the CE.";
container encapsulation { container encapsulation {
description description
"Container for layer 2 encapsulation."; "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
"Encapsulation type. By default, the type of "Encapsulation type. By default, the type
the tagged interface is 'priority-tagged'."; of the tagged interface is
'priority-tagged'.";
} }
container dot1q { 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'.";
} }
description description
"Tagged interface."; "Tagged interface.";
leaf tag-type { leaf tag-type {
type identityref { type identityref {
base vpn-common:tag-type; base vpn-common:tag-type;
} }
default "vpn-common:c-vlan"; default "vpn-common:c-vlan";
description description
"Tag type. By default, the tag type is "Tag type. By default, the tag type is
'c-vlan'."; 'c-vlan'.";
} }
leaf cvlan-id { leaf cvlan-id {
type uint16 { type uint16 {
range "1..4094"; range "1..4094";
} }
description description
"VLAN identifier."; "VLAN identifier.";
} }
} }
container priority-tagged { container priority-tagged {
when "derived-from-or-self(../type, " when "derived-from-or-self(../type, "
+ "'vpn-common:priority-tagged')" { + "'vpn-common:priority-tagged')" {
description description
"Only applies when the type of the "Only applies when the type of
tagged interface is 'priority-tagged'."; the tagged interface is
'priority-tagged'.";
} }
description description
"Priority tagged."; "Priority tagged.";
leaf tag-type { leaf tag-type {
type identityref { type identityref {
base vpn-common:tag-type; base vpn-common:tag-type;
} }
default "vpn-common:c-vlan"; default "vpn-common:c-vlan";
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
interface is QinQ."; tagged interface is 'qinq'.";
} }
description description
"Includes QinQ parameters."; "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:s-c-vlan"; default "vpn-common:s-c-vlan";
description description
"Tag type. By default, the tag type is "Tag type.";
'c-s-vlan'.";
} }
leaf svlan-id { leaf svlan-id {
type uint16; type uint16;
mandatory true; mandatory true;
description description
"S-VLAN identifier."; "Service VLAN (S-VLAN) identifier.";
} }
leaf cvlan-id { leaf cvlan-id {
type uint16; type uint16;
mandatory true; mandatory true;
description description
"C-VLAN identifier."; "Customer VLAN (C-VLAN) identifier.";
} }
} }
} }
choice l2-service { choice l2-service {
description description
"The layer 2 connectivity service can be "The Layer 2 connectivity service can be
provided by indicating a pointer to an L2VPN or provided by indicating a pointer to an
by specifying a layer 2 tunnel service."; L2VPN or by specifying a Layer 2 tunnel
service.";
container l2-tunnel-service { container l2-tunnel-service {
description description
"Defines a layer 2 tunnel termination. "Defines a Layer 2 tunnel termination.
It is only applicable when a tunnel is It is only applicable when a tunnel is
required. The supported values are: required. The supported values are
pseudowire, VPLS, and VXLAN. Other 'pseudowire', 'vpls', and 'vxlan'. Other
values may be defined, if needed."; values may be defined, if needed.";
leaf type { leaf type {
type identityref { type identityref {
base l2-tunnel-type; base l2-tunnel-type;
} }
description description
"Selects the tunnel termiantion option for "Selects the tunnel termination option
each vpn-network-access."; for each VPN network access.";
} }
container pseudowire { container pseudowire {
when "derived-from-or-self(../type, " when "derived-from-or-self(../type, "
+ "'pseudowire')" { + "'pseudowire')" {
description description
"Only applies when the type of the layer 2 "Only applies when the Layer 2 service
service type is pseudowire ."; type is 'pseudowire'.";
} }
description description
"Includes 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 pseudowire (PW) or
virtual circuit (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
"Neighbor reference."; "Neighbor reference.";
reference reference
"RFC 8077: Pseudowire Setup and Maintenance "RFC 8077: Pseudowire Setup and
Using the Label Distribution Maintenance Using the Label
Protocol (LDP), Section 6.1"; Distribution Protocol
(LDP), Section 6.1";
} }
} }
container vpls { container vpls {
when "derived-from-or-self(../type, " when "derived-from-or-self(../type, "
+ "'vpls')" { + "'vpls')" {
description description
"Only applies when the type of the layer 2 "Only applies when the Layer 2 service
service type is VPLS."; type is 'vpls'.";
} }
description description
"VPLS termination parameters."; "VPLS termination parameters.";
leaf vcid { leaf vcid {
type uint32; type uint32;
description description
"VC Identifier."; "VC identifier.";
} }
leaf-list far-end { leaf-list far-end {
type union { type union {
type uint32; type uint32;
type inet:ip-address; type inet:ip-address;
} }
description description
"Neighbor reference."; "Neighbor reference.";
} }
} }
container vxlan { container vxlan {
when "derived-from-or-self(../type, " when "derived-from-or-self(../type, "
+ "'vxlan')" { + "'vxlan')" {
description description
"Only applies when the type of the layer 2 "Only applies when the Layer 2 service
service type is VXLAN."; type is 'vxlan'.";
} }
description description
"VXLAN termination parameters."; "VXLAN termination parameters.";
leaf vni-id { leaf vni-id {
type uint32; type uint32;
mandatory true; mandatory true;
description description
"VXLAN Network Identifier (VNI)."; "VXLAN Network Identifier (VNI).";
} }
leaf peer-mode { leaf peer-mode {
type identityref { type identityref {
base vpn-common:vxlan-peer-mode; base vpn-common:vxlan-peer-mode;
} }
default "vpn-common:static-mode"; default "vpn-common:static-mode";
description description
"Specifies the VXLAN access mode. By "Specifies the VXLAN access mode. By
default, the peer mode is set to default, the peer mode is set to
'static-mode'."; 'static-mode'.";
} }
leaf-list peer-ip-address { leaf-list peer-ip-address {
type inet:ip-address; type inet:ip-address;
description description
"List of peer's IP addresses."; "List of a peer's IP addresses.";
} }
} }
} }
case l2vpn { case l2vpn {
leaf l2vpn-id { leaf l2vpn-id {
type vpn-common:vpn-id; type vpn-common:vpn-id;
description description
"Indicates the L2VPN service associated with "Indicates the L2VPN service associated
an Integrated Routing and Bridging (IRB) with an Integrated Routing and Bridging
interface."; (IRB) interface.";
} }
} }
} }
leaf l2-termination-point { leaf l2-termination-point {
type string; type string;
description description
"Specifies a reference to a local layer 2 "Specifies a reference to a local Layer 2
termination point such as a layer 2 termination point, such as a Layer 2
sub-interface."; sub-interface.";
} }
leaf local-bridge-reference { leaf local-bridge-reference {
type string; type string;
description description
"Specifies a local bridge reference to "Specifies a local bridge reference to
accommodate, for example, implementations accommodate, for example, implementations
that require internal bridging. that require internal bridging.
A reference may be a local bridge domain."; A reference may be a local bridge domain.";
} }
leaf bearer-reference { leaf bearer-reference {
if-feature "vpn-common:bearer-reference"; if-feature "vpn-common:bearer-reference";
type string; type string;
description description
"This is an internal reference for the service "This is an internal reference for the
provider to identify the bearer associated service provider to identify the bearer
with this VPN."; associated with this VPN.";
} }
container lag-interface { container lag-interface {
if-feature "vpn-common:lag-interface"; if-feature "vpn-common:lag-interface";
description description
"Container of LAG interface attributes "Container for configuration of Link
configuration."; Aggregation Group (LAG) interface
attributes.";
leaf lag-interface-id { leaf lag-interface-id {
type string; type string;
description description
"LAG interface identifier."; "LAG interface identifier.";
} }
container member-link-list { container member-link-list {
description description
"Container of Member link list."; "Container for the member link list.";
list member-link { list member-link {
key "name"; key "name";
description description
"Member link."; "Member link.";
leaf name { leaf name {
type string; type string;
description description
"Member link name."; "Member link name.";
} }
} }
} }
} }
} }
container ip-connection { container ip-connection {
description description
"Defines IP connection parameters."; "Defines IP connection parameters.";
leaf l3-termination-point { leaf l3-termination-point {
type string; type string;
description description
"Specifies a reference to a local layer 3 "Specifies a reference to a local Layer 3
termination point such as a bridge domain termination point, such as a bridge domain
interface."; 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-address; type inet:ipv4-address;
description description
"The IP address used at the provider's "The IP address used at the provider's
skipping to change at page 81, line 46 skipping to change at line 3643
description description
"Subnet prefix length expressed in bits. "Subnet prefix length expressed in bits.
It is applied to both local and customer It is applied to both local and customer
addresses."; 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 "
+ " 'provider-dhcp-slaac'))" { + "derived-from-or-self(current(), "
error-message + "'provider-dhcp-slaac'))" {
"SLAAC is only applicable to IPv6."; error-message "SLAAC is only applicable "
+ "to IPv6.";
} }
description description
"Defines how addresses are allocated to the "Defines how addresses are allocated to
peer site. the peer site.
If there is no value for the address If there is no value for the address
allocation type, then IPv4 addressing is not allocation type, then IPv4 addressing
enabled."; 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 {
description description
"DHCP allocated addresses related "Parameters related to DHCP-allocated
parameters. IP addresses are allocated addresses. IP addresses are allocated
by DHCP that is operated by the provider"; by DHCP, which is provided by the
operator.";
leaf dhcp-service-type { leaf dhcp-service-type {
type enumeration { type enumeration {
enum server { enum server {
description description
"Local DHCP server."; "Local DHCP server.";
} }
enum relay { enum relay {
description description
"Local DHCP relay. DHCP requests are "Local DHCP relay. DHCP requests
relayed to a provider's server."; are relayed to a provider's
server.";
} }
} }
description description
"Indicates the type of DHCP service to "Indicates the type of DHCP service to
be enabled on this access."; be enabled on this access.";
} }
choice service-type { choice service-type {
description description
"Choice based on the DHCP service type."; "Choice based on the DHCP service
type.";
case relay { case relay {
description description
"Container for list of provider's DHCP "Container for a list of the
servers (i.e., dhcp-service-type is set provider's DHCP servers (i.e.,
to relay)."; 'dhcp-service-type' is set to
'relay').";
leaf-list server-ip-address { leaf-list server-ip-address {
type inet:ipv4-address; type inet:ipv4-address;
description description
"IPv4 addresses of the provider's DHCP "IPv4 addresses of the provider's
server to use by the local DHCP DHCP server, for use by the local
relay."; DHCP relay.";
} }
} }
case server { case server {
description description
"A choice about how addresses are assigned "A choice for how addresses are
when a local DHCP server is enabled."; assigned when a local DHCP server
is enabled.";
choice address-assign { choice address-assign {
default "number"; default "number";
description description
"Choice for how IPv4 addresses are "A choice for how IPv4 addresses
assigned."; are assigned.";
case number { case number {
leaf number-of-dynamic-address { leaf number-of-dynamic-address {
type uint16; type uint16;
default "1"; default "1";
description description
"Specifies the number of IP "Specifies the number of IP
addresses to be assigned to the addresses to be assigned to
customer on this access."; the customer on this
access.";
} }
} }
case explicit { case explicit {
container customer-addresses { container customer-addresses {
description description
"Container for customer "Container for customer
addresses to be allocated addresses to be allocated
using DHCP."; using DHCP.";
list address-pool { list address-pool {
key "pool-id"; key "pool-id";
description description
"Describes IP addresses to be "Describes IP addresses to
allocated by DHCP. be allocated by DHCP.
When only start-address is When only 'start-address'
present, it represents a single is present, it represents a
address. single address.
When both start-address and When both 'start-address'
end-address are specified, it and 'end-address' are
implies a range inclusive of both specified, it implies a
range inclusive of both
addresses."; addresses.";
leaf pool-id { leaf pool-id {
type string; type string;
description description
"A pool identifier for the "A pool identifier for the
address range from start- address range from
address to end-address."; 'start-address' to
'end-address'.";
} }
leaf start-address { leaf start-address {
type inet:ipv4-address; type inet:ipv4-address;
mandatory true; mandatory true;
description description
"Indicates the first address "Indicates the first
in the pool."; address in the pool.";
} }
leaf end-address { leaf end-address {
type inet:ipv4-address; type inet:ipv4-address;
description description
"Indicates the last address "Indicates the last
in the pool."; address in the pool.";
} }
} }
} }
} }
} }
} }
} }
} }
case dhcp-relay { case dhcp-relay {
description description
"DHCP relay is provided by the operator."; "The DHCP relay is provided by the
operator.";
container customer-dhcp-servers { container customer-dhcp-servers {
description description
"Container for a list of customer's DHCP "Container for a list of the
servers."; customer's DHCP servers.";
leaf-list server-ip-address { leaf-list server-ip-address {
type inet:ipv4-address; type inet:ipv4-address;
description description
"IPv4 addresses of the customer's DHCP "IPv4 addresses of the customer's
server."; DHCP server.";
} }
} }
} }
case static-addresses { case static-addresses {
description description
"Lists the IPv4 addresses that are 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
"Lists the IPv4 addresses that are used."; "Lists the IPv4 addresses that are
used.";
leaf address-id { leaf address-id {
type string; type string;
description description
"An identifier of the static IPv4 "An identifier of the static IPv4
address."; 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 of 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 {
skipping to change at page 85, line 47 skipping to change at line 3849
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 addressing is allocation type, then IPv6 addressing is
disabled."; disabled.";
} }
choice allocation-type { choice allocation-type {
description description
"A choice based on the IPv6 allocation type."; "A choice based on the IPv6 allocation
type.";
container 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 "
+ "or derived-from-or-self(../address-allo" + "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 provided by the allocated by DHCPv6 as provided by
operator."; the operator.";
} }
description description
"DHCPv6 allocated addresses related "Parameters related to DHCP-allocated
parameters."; addresses.";
leaf dhcp-service-type { leaf dhcp-service-type {
type enumeration { type enumeration {
enum server { enum server {
description description
"Local DHCPv6 server."; "Local DHCPv6 server.";
} }
enum relay { enum relay {
description description
"DHCPv6 relay."; "DHCPv6 relay.";
} }
} }
description description
"Indicates the type of the DHCPv6 service to "Indicates the type of the DHCPv6
be enabled on this access."; service to be enabled on this
access.";
} }
choice service-type { choice service-type {
description description
"Choice based on the DHCPv6 service type."; "Choice based on the DHCPv6 service
type.";
case relay { case relay {
leaf-list server-ip-address { leaf-list server-ip-address {
type inet:ipv6-address; type inet:ipv6-address;
description description
"IPv6 addresses of the provider's "IPv6 addresses of the provider's
DHCPv6 server."; DHCPv6 server.";
} }
} }
case server { case server {
choice address-assign { choice address-assign {
default "number"; default "number";
description description
"Choice about how IPv6 prefixes are "Choice for how IPv6 prefixes are
assigned by the DHCPv6 server."; assigned by the DHCPv6 server.";
case number { case number {
leaf number-of-dynamic-address { leaf number-of-dynamic-address {
type uint16; type uint16;
default "1"; default "1";
description description
"Describes the number of IPv6 "Describes the number of IPv6
prefixes that are allocated to prefixes that are allocated
the customer on this access."; to the customer on this
access.";
} }
} }
case explicit { case explicit {
container customer-addresses { container customer-addresses {
description description
"Container for customer IPv6 "Container for customer IPv6
addresses allocated by DHCPv6."; addresses allocated by
DHCPv6.";
list address-pool { list address-pool {
key "pool-id"; key "pool-id";
description description
"Describes IPv6 addresses "Describes IPv6 addresses
allocated by DHCPv6. allocated by DHCPv6.
When only start-address is When only 'start-address'
present, it represents a single is present, it represents a
address. single address.
When both start-address and When both 'start-address'
end-address are specified, it and 'end-address' are
implies a range inclusive of specified, it implies a
both addresses."; range inclusive of both
addresses.";
leaf pool-id { leaf pool-id {
type string; type string;
description description
"Pool identifier for the address "A pool identifier for the
range from identified by start- address range from
address and end-address."; 'start-address' to
'end-address'.";
} }
leaf start-address { leaf start-address {
type inet:ipv6-address; type inet:ipv6-address;
mandatory true; mandatory true;
description description
"Indicates the first address."; "Indicates the first
address.";
} }
leaf end-address { leaf end-address {
type inet:ipv6-address; type inet:ipv6-address;
description description
"Indicates the last address."; "Indicates the last
address.";
} }
} }
} }
} }
} }
} }
} }
} }
case dhcp-relay { case dhcp-relay {
description description
"DHCPv6 relay provided by the operator."; "DHCPv6 relay provided by the
operator.";
container customer-dhcp-servers { container customer-dhcp-servers {
description description
"Container for a list of customer DHCP "Container for a list of the
servers."; customer's DHCP servers.";
leaf-list server-ip-address { leaf-list server-ip-address {
type inet:ipv6-address; type inet:ipv6-address;
description description
"Contains the IP addresses of the customer "Contains the IP addresses of the
DHCPv6 server."; customer's DHCPv6 server.";
} }
} }
} }
case static-addresses { case static-addresses {
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/address-id"; path "../address/address-id";
} }
description description
"Principal address of the connection"; "Principal address of the
connection.";
} }
list address { list address {
key "address-id"; key "address-id";
description description
"Describes IPv6 addresses that are used."; "Describes IPv6 addresses that are
used.";
leaf address-id { leaf address-id {
type string; type string;
description description
"An identifier of an IPv6 address."; "An identifier of an IPv6 address.";
} }
leaf customer-address { leaf customer-address {
type inet:ipv6-address; type inet:ipv6-address;
description description
"An IPv6 address 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
the CE/PE link. This list can be augmented."; 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 the routing
protocol.";
} }
leaf type { leaf type {
type identityref { type identityref {
base vpn-common:routing-protocol-type; base vpn-common:routing-protocol-type;
} }
description description
"Type of routing protocol."; "Type of routing protocol.";
} }
list routing-profiles { list routing-profiles {
key "id"; key "id";
skipping to change at page 89, line 45 skipping to change at line 4053
base vpn-common:ie-type; base vpn-common:ie-type;
} }
description description
"Import, export, or both."; "Import, export, or both.";
} }
} }
container static { container static {
when "derived-from-or-self(../type, " when "derived-from-or-self(../type, "
+ "'vpn-common:static-routing')" { + "'vpn-common:static-routing')" {
description description
"Only applies when protocol is static."; "Only applies when the protocol is a
static routing protocol.";
} }
description description
"Configuration specific to static routing."; "Configuration specific to static
routing.";
container cascaded-lan-prefixes { container cascaded-lan-prefixes {
description description
"LAN prefixes from the customer."; "LAN prefixes from the customer.";
list ipv4-lan-prefixes { list ipv4-lan-prefixes {
if-feature "vpn-common:ipv4"; if-feature "vpn-common:ipv4";
key "lan next-hop"; key "lan next-hop";
description description
"List of LAN prefixes for the site."; "List of LAN prefixes for the site.";
leaf lan { leaf lan {
type inet:ipv4-prefix; type inet:ipv4-prefix;
description description
"LAN prefixes."; "LAN prefixes.";
} }
skipping to change at page 90, line 27 skipping to change at line 4084
description description
"Internal tag to be used in VPN "Internal tag to be used in VPN
policies."; policies.";
} }
leaf next-hop { leaf next-hop {
type union { type union {
type inet:ip-address; type inet:ip-address;
type predefined-next-hop; type predefined-next-hop;
} }
description description
"The next-hop that is to be used "The next hop that is to be used
for the static route. This may be for the static route. This may be
specified as an IP address or a specified as an IP address or a
pre-defined next-hop type (e.g., predefined next-hop type (e.g.,
discard or local-link)."; 'discard' or 'local-link').";
} }
leaf bfd-enable { leaf bfd-enable {
if-feature "vpn-common:bfd"; if-feature "vpn-common:bfd";
type boolean; type boolean;
description description
"Enables BFD."; "Enables Bidirectional Forwarding
Detection (BFD).";
} }
leaf metric { leaf metric {
type uint32; type uint32;
description description
"Indicates the metric associated with "Indicates the metric associated
the static route."; with the static route.";
} }
leaf preference { leaf preference {
type uint32; type uint32;
description description
"Indicates the preference of the static "Indicates the preference associated
routes."; with the static route.";
} }
uses vpn-common:service-status; uses vpn-common:service-status;
} }
list ipv6-lan-prefixes { list ipv6-lan-prefixes {
if-feature "vpn-common:ipv6"; if-feature "vpn-common:ipv6";
key "lan next-hop"; key "lan next-hop";
description description
"List of LAN prefixes for the site."; "List of LAN prefixes for the site.";
leaf lan { leaf lan {
type inet:ipv6-prefix; type inet:ipv6-prefix;
skipping to change at page 91, line 26 skipping to change at line 4133
description description
"Internal tag to be used in VPN "Internal tag to be used in VPN
policies."; policies.";
} }
leaf next-hop { leaf next-hop {
type union { type union {
type inet:ip-address; type inet:ip-address;
type predefined-next-hop; type predefined-next-hop;
} }
description description
"The next-hop that is to be used for the "The next hop that is to be used for
static route. This may be specified as the static route. This may be
an IP address or a pre-defined next-hop specified as an IP address or a
type (e.g., discard or local-link)."; predefined next-hop type (e.g.,
'discard' or 'local-link').";
} }
leaf bfd-enable { leaf bfd-enable {
if-feature "vpn-common:bfd"; if-feature "vpn-common:bfd";
type boolean; type boolean;
description description
"Enables BFD."; "Enables BFD.";
} }
leaf metric { leaf metric {
type uint32; type uint32;
description description
"Indicates the metric associated with "Indicates the metric associated
the static route."; with the static route.";
} }
leaf preference { leaf preference {
type uint32; type uint32;
description description
"Indicates the preference associated "Indicates the preference associated
with the static route."; with the static route.";
} }
uses vpn-common:service-status; uses vpn-common:service-status;
} }
} }
skipping to change at page 92, line 4 skipping to change at line 4160
} }
leaf preference { leaf preference {
type uint32; type uint32;
description description
"Indicates the preference associated "Indicates the preference associated
with the static route."; with the static route.";
} }
uses vpn-common:service-status; uses vpn-common:service-status;
} }
} }
} }
container bgp { container bgp {
when "derived-from-or-self(../type, " when "derived-from-or-self(../type, "
+ "'vpn-common:bgp-routing')" { + "'vpn-common:bgp-routing')" {
description description
"Only applies when protocol is BGP."; "Only applies when the protocol is
BGP.";
} }
description description
"BGP-specific configuration."; "Configuration specific to BGP.";
leaf description { leaf description {
type string; type string;
description description
"Includes a description of the BGP session. "Includes a description of the BGP
session.
This description is meant to be used for This description is meant to be used
diagnosis purposes. The semantic of the for diagnostic purposes. The semantic
description is local to an of the description is local to an
implementation."; implementation.";
} }
leaf local-as { leaf local-as {
type inet:as-number; type inet:as-number;
description description
"Indicates a local AS Number (ASN) if a "Indicates a local AS Number (ASN), if
distinct ASN than the one configured at an ASN distinct from the ASN configured
the VPN node level is needed."; at the VPN node level is needed.";
} }
leaf peer-as { leaf peer-as {
type inet:as-number; type inet:as-number;
mandatory true; mandatory true;
description description
"Indicates the customer's ASN when "Indicates the customer's ASN when
the customer requests BGP routing."; 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
activated. Dual-stack means that both IPv4 to be activated. 'dual-stack' means
and IPv6 will be activated."; that both IPv4 and IPv6 will be
activated.";
} }
leaf local-address { leaf local-address {
type union { type union {
type inet:ip-address; type inet:ip-address;
type if:interface-ref; type if:interface-ref;
} }
description description
"Set the local IP address to use for the BGP "Sets the local IP address to use for
transport session. This may be expressed as the BGP transport session. This may be
either an IP address or a reference to an expressed as either an IP address or a
interface."; 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.
and IPv6 neighbors may be indicated if IPv4 and IPv6 neighbors may be
two sessions will be used for IPv4 and indicated if two sessions will be used
IPv6."; for IPv4 and 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 ASN override is enabled, "Defines whether ASN override is
i.e., replace the ASN of the customer enabled, i.e., replacing the ASN of
specified in the AS_Path attribute with the customer specified in the AS_PATH
the local ASN."; attribute with the local ASN.";
} }
leaf allow-own-as { leaf allow-own-as {
type uint8; type uint8;
default "0"; default "0";
description description
"Specifies the number of occurrences "If set, specifies the maximum number of
of the provider's ASN that can occur occurrences of the provider's ASN that
within the AS_PATH before it are permitted within the AS_PATH
is rejected."; before it is rejected.";
} }
leaf prepend-global-as { leaf prepend-global-as {
type boolean; type boolean;
default "false"; default "false";
description description
"In some situations, the ASN that is "In some situations, the ASN that is
provided at the VPN node level may be provided at the VPN node level may be
distinct from the one configured at the distinct from the ASN configured at the
VPN network access level. When such VPN network access level. When such
ASNs are provided, they are both ASNs are provided, they are both
prepended to the BGP route updates prepended to the BGP route updates
for this access. To disable that for this access. To disable that
behavior, the prepend-global-as behavior, 'prepend-global-as'
must be set to 'false'. In such a case, must be set to 'false'. In such a
the ASN that is provided at case, the ASN that is provided at
the VPN node level is not prepended to the VPN node level is not prepended
the BGP route updates for this access."; to the BGP route updates for
this access.";
} }
leaf send-default-route { leaf send-default-route {
type boolean; type boolean;
default "false"; default "false";
description description
"Defines whether default routes can be "Defines whether default routes can be
advertised to its peer. If set, the advertised to a peer. If set, the
default routes are advertised to its default routes are advertised to a
peer."; peer.";
} }
leaf site-of-origin { leaf site-of-origin {
when "../address-family = 'vpn-common:ipv4' or " when "../address-family = 'vpn-common:ipv4' "
+ "'vpn-common:dual-stack'" { + "or '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
a Route Origin Extended Community. It is as a Route Origin Extended Community.
meant to uniquely identify the set of routes It is meant to uniquely identify the
learned from a site via a particular CE/PE set of routes learned from a site via a
connection and is used to prevent routing particular CE-PE connection and is used
loops."; to prevent routing loops.";
reference reference
"RFC 4364: BGP/MPLS IP Virtual Private "RFC 4364: BGP/MPLS IP Virtual Private
Networks (VPNs), Section 7"; 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' "
+ "'vpn-common:dual-stack'" { + "or '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 "The IPv6 Site of Origin attribute is
BGP Extended that are meant to the Site of encoded as an IPv6 Route Origin
Origin for VRF information."; Extended Community. It is meant to
uniquely identify the set of routes
learned from a site via VRF
information.";
reference reference
"RFC 5701: IPv6 Address Specific BGP Extended "RFC 5701: IPv6 Address Specific BGP
Community Attribute"; Extended Community
Attribute";
} }
list redistribute-connected { list redistribute-connected {
key "address-family"; key "address-family";
description description
"Indicates the per-AF policy to follow "Indicates, per address family, the
for connected routes."; policy to follow for connected
routes.";
leaf address-family { leaf address-family {
type identityref { type identityref {
base vpn-common:address-family; base vpn-common:address-family;
} }
description description
"Indicates the address family."; "Indicates the address family.";
} }
leaf enable { leaf enable {
type boolean; type boolean;
description description
"Enables to redistribute connected "Enables the redistribution of
routes."; 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 control of how many prefixes It allows control of how many
can be received from a neighbor. prefixes 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
"RFC 4271: A Border Gateway Protocol 4 "RFC 4271: A Border Gateway Protocol 4
(BGP-4), Section 8.2.2"; (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";
} }
skipping to change at page 96, line 23 skipping to change at line 4382
exceeded."; exceeded.";
} }
enum discard-extra-paths { enum discard-extra-paths {
description description
"Discards extra paths when the "Discards extra paths when the
limit is exceeded."; limit is exceeded.";
} }
enum restart { enum restart {
description description
"The BGP session restarts after "The BGP session restarts after
a time interval."; the indicated time interval.";
} }
} }
description description
"BGP neighbor max-prefix violate "If the BGP neighbor 'max-prefix'
action."; limit is reached, the action
indicated in 'violate-action'
will be followed.";
} }
leaf restart-timer { leaf restart-timer {
type uint32; type uint32;
units "seconds"; units "seconds";
description description
"Time interval after which the BGP "Time interval after which the BGP
session will be reestablished."; session will be reestablished.";
} }
} }
container bgp-timers { container bgp-timers {
description description
"Includes two BGP timers that can be "Includes two BGP timers that can be
customized when building a VPN service customized when building a VPN service
with BGP used as CE-PE routing with BGP used as the CE-PE routing
protocol."; protocol.";
leaf keepalive { leaf keepalive {
type uint16 { type uint16 {
range "0..21845"; range "0..21845";
} }
units "seconds"; units "seconds";
default "30"; default "30";
description description
"This timer indicates the KEEPALIVE "This timer indicates the KEEPALIVE
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 that
messages are disabled. KEEPALIVE messages are disabled.
It is suggested that the maximum time It is suggested that the maximum
between KEEPALIVE messages would be time between KEEPALIVE messages be
one third of the Hold Time interval."; one-third of the Hold Time
interval.";
reference reference
"RFC 4271: A Border Gateway Protocol 4 "RFC 4271: A Border Gateway Protocol 4
(BGP-4), Section 4.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 "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
"RFC 4271: A Border Gateway Protocol 4 "RFC 4271: A Border Gateway Protocol 4
(BGP-4), Section 4.2"; (BGP-4), Section 4.2";
} }
skipping to change at page 97, line 49 skipping to change at line 4459
parameters between a PE and a CE."; parameters between a PE and a CE.";
leaf enable { leaf enable {
type boolean; type boolean;
default "false"; default "false";
description description
"Enables or disables authentication."; "Enables or disables authentication.";
} }
container keying-material { container keying-material {
when "../enable = 'true'"; when "../enable = 'true'";
description description
"Container for describing how a BGP routing "Container for describing how a BGP
session is to be secured between a PE and routing session is to be secured
a CE."; between a PE and a CE.";
choice option { choice option {
description description
"Choice of authentication options."; "Choice of authentication options.";
case ao { case ao {
description description
"Uses TCP-Authentication Option "Uses the TCP Authentication
(TCP-AO)."; Option (TCP-AO).";
reference reference
"RFC 5925: The TCP Authentication "RFC 5925: The TCP Authentication
Option."; Option";
leaf enable-ao { leaf enable-ao {
type boolean; type boolean;
description description
"Enables TCP-AO."; "Enables the TCP-AO.";
} }
leaf ao-keychain { leaf ao-keychain {
type key-chain:key-chain-ref; type key-chain:key-chain-ref;
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 Data Model for
Key Chains";
} }
} }
case md5 { case md5 {
description description
"Uses MD5 to secure the session."; "Uses MD5 to secure the session.";
reference reference
"RFC 4364: BGP/MPLS IP Virtual Private "RFC 4364: BGP/MPLS IP Virtual
Networks (VPNs), Private Networks
Section 13.2"; (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 Data Model for
Key Chains";
} }
} }
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
"BGP authentication key. "BGP authentication key.
This model only supports the
This model only supports the subset subset of keys that are
of keys that are representable as representable as ASCII
ASCII strings."; strings.";
} }
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
associated with the key."; algorithm associated with the
key.";
} }
} }
case ipsec { case ipsec {
description description
"Specifies a reference to an IKE "Specifies a reference to an
Security Association (SA)."; Internet Key Exchange Protocol
(IKE) Security Association
(SA).";
leaf sa { leaf sa {
type string; type string;
description description
"Indicates the administrator-assigned "Indicates the
name of the SA."; administrator-assigned name
of the SA.";
} }
} }
} }
} }
} }
uses vpn-common:service-status; uses vpn-common:service-status;
} }
container ospf { container ospf {
when "derived-from-or-self(../type, " when "derived-from-or-self(../type, "
+ "'vpn-common:ospf-routing')" { + "'vpn-common:ospf-routing')" {
description description
"Only applies when protocol is OSPF."; "Only applies when the protocol is
OSPF.";
} }
description description
"OSPF-specific configuration."; "Configuration specific to OSPF.";
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 "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;
skipping to change at page 100, line 19 skipping to change at line 4583
Virtual Private Networks Virtual Private Networks
(VPNs), Section 4.2.3 (VPNs), Section 4.2.3
RFC 6565: OSPFv3 as a Provider Edge to RFC 6565: OSPFv3 as a Provider Edge to
Customer Edge (PE-CE) Routing Customer Edge (PE-CE) Routing
Protocol, Section 4.2"; 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 reference
"RFC 4577: OSPF as the Provider/Customer "RFC 4577: OSPF as the Provider/Customer
Edge Protocol for BGP/MPLS IP Edge Protocol for BGP/MPLS IP
Virtual Private Networks Virtual Private Networks
(VPNs), Section 4.2.7 (VPNs), Section 4.2.7
RFC 6565: OSPFv3 as a Provider Edge to RFC 6565: OSPFv3 as a Provider Edge to
Customer Edge (PE-CE) Routing Customer Edge (PE-CE) Routing
Protocol, Section 5"; 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 string; type string;
description description
"Target site for the sham link connection. "Target site for the sham link
The site is referred to by its connection. The site is referred
identifier."; to by its identifier.";
} }
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
the routing state calculation and path used in the routing state
selection. The default value is set calculation and path selection.
to 1."; The default value is set to '1'.";
reference reference
"RFC 4577: OSPF as the Provider/Customer "RFC 4577: OSPF as the
Edge Protocol for BGP/MPLS IP Provider/Customer Edge
Protocol for BGP/MPLS IP
Virtual Private Networks Virtual Private Networks
(VPNs), Section 4.2.7.3 (VPNs), Section 4.2.7.3
RFC 6565: OSPFv3 as a Provider Edge to RFC 6565: OSPFv3 as a Provider Edge
Customer Edge (PE-CE) Routing to Customer Edge (PE-CE)
Protocol, Section 5.2"; 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 Link State
Advertisements (LSAs) that the OSPF
instance will accept.";
} }
container authentication { container authentication {
description description
"Authentication configuration."; "Authentication configuration.";
leaf enable { leaf enable {
type boolean; type boolean;
default "false"; default "false";
description description
"Enables or disables authentication."; "Enables or disables authentication.";
} }
skipping to change at page 101, line 46 skipping to change at line 4663
"Container for describing how an OSPF "Container for describing how an OSPF
session is to be secured between a CE session is to be secured between a CE
and a PE."; and a PE.";
choice option { choice option {
description description
"Options for OSPF authentication."; "Options for OSPF authentication.";
case auth-key-chain { case auth-key-chain {
leaf key-chain { leaf key-chain {
type key-chain:key-chain-ref; type key-chain:key-chain-ref;
description description
"key-chain name."; "Name of the key chain.";
} }
} }
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.
This model only supports the subset This model only supports the
of keys that are representable as subset of keys that are
ASCII strings."; representable as ASCII
strings.";
} }
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
associated with the key."; algorithm associated with the
key.";
} }
} }
case ipsec { case ipsec {
leaf sa { leaf sa {
type string; type string;
description description
"Indicates the administrator-assigned "Indicates the
name of the SA."; administrator-assigned name
of the SA.";
reference reference
"RFC 4552: Authentication "RFC 4552: Authentication/
/Confidentiality for Confidentiality for
OSPFv3"; 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-routing')" { + "'vpn-common:isis-routing')" {
description description
"Only applies when protocol is IS-IS."; "Only applies when the protocol is
IS-IS.";
} }
description description
"IS-IS specific configuration."; "Configuration specific to IS-IS.";
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 area-address; 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 level-1, level-2, or level-1-2."; "Can be 'level-1', 'level-2', or
'level-1-2'.";
reference
"RFC 9181: A Common YANG Data Model for
Layer 2 and Layer 3 VPNs";
} }
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.";
} }
leaf mode { leaf mode {
type enumeration { type enumeration {
enum active { enum active {
description description
"Interface sends or receives IS-IS "The interface sends or receives
protocol control packets."; IS-IS protocol control packets.";
} }
enum passive { enum passive {
description description
"Suppresses the sending of IS-IS "Suppresses the sending of IS-IS
updates through the specified updates through the specified
interface."; interface.";
} }
} }
default "active"; default "active";
description description
skipping to change at page 104, line 22 skipping to change at line 4791
"Container for describing how an IS-IS "Container for describing how an IS-IS
session is to be secured between a CE session is to be secured between a CE
and a PE."; and a PE.";
choice option { choice option {
description description
"Options for IS-IS authentication."; "Options for IS-IS authentication.";
case auth-key-chain { case auth-key-chain {
leaf key-chain { leaf key-chain {
type key-chain:key-chain-ref; type key-chain:key-chain-ref;
description description
"key-chain name."; "Name of the key chain.";
} }
} }
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
"IS-IS authentication key. "IS-IS authentication key.
This model only supports the subset This model only supports the
of keys that are representable as subset of keys that are
ASCII strings."; representable as ASCII
strings.";
} }
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
associated with the key."; algorithm associated with the
key.";
} }
} }
} }
} }
} }
uses vpn-common:service-status; uses vpn-common:service-status;
} }
container rip { container rip {
when "derived-from-or-self(../type, " when "derived-from-or-self(../type, "
+ "'vpn-common:rip-routing')" { + "'vpn-common:rip-routing')" {
description description
"Only applies when the protocol is RIP. "Only applies when the protocol is RIP.
For IPv4, the model assumes that RIP For IPv4, the model assumes that RIP
version 2 is used."; version 2 is used.";
} }
description description
skipping to change at page 105, line 36 skipping to change at line 4854
"Indicates the RIP timers."; "Indicates the RIP timers.";
reference reference
"RFC 2453: RIP Version 2"; "RFC 2453: RIP Version 2";
leaf update-interval { leaf update-interval {
type uint16 { type uint16 {
range "1..32767"; range "1..32767";
} }
units "seconds"; units "seconds";
default "30"; default "30";
description description
"Indicates the RIP update time. "Indicates the RIP update time, i.e.,
That is, the amount of time for which the amount of time for which RIP
RIP updates are sent."; updates are sent.";
} }
leaf invalid-interval { leaf invalid-interval {
type uint16 { type uint16 {
range "1..32767"; range "1..32767";
} }
units "seconds"; units "seconds";
default "180"; default "180";
description description
"Is the interval before a route is declared "The interval before a route is
invalid after no updates are received. declared invalid after no updates are
This value is at least three times received. This value is at least
the value for the update-interval three times the value for the
argument."; 'update-interval' argument.";
} }
leaf holddown-interval { leaf holddown-interval {
type uint16 { type uint16 {
range "1..32767"; range "1..32767";
} }
units "seconds"; units "seconds";
default "180"; default "180";
description description
"Specifies the interval before better routes "Specifies the interval before better
are released."; routes are released.";
} }
leaf flush-interval { leaf flush-interval {
type uint16 { type uint16 {
range "1..32767"; range "1..32767";
} }
units "seconds"; units "seconds";
default "240"; default "240";
description description
"Indicates the RIP flush timer. That is, "Indicates the RIP flush timer, i.e.,
the amount of time that must elapse before the amount of time that must elapse
a route is removed from the routing before a route is removed from the
table."; routing table.";
} }
} }
leaf default-metric { leaf default-metric {
type uint8 { type uint8 {
range "0..16"; range "0..16";
} }
default "1"; default "1";
description description
"Sets the default metric."; "Sets the default metric.";
} }
skipping to change at page 107, line 4 skipping to change at line 4919
"Enables or disables authentication."; "Enables or disables authentication.";
} }
container keying-material { container keying-material {
when "../enable = 'true'"; when "../enable = 'true'";
description description
"Container for describing how a RIP "Container for describing how a RIP
session is to be secured between a CE session is to be secured between a CE
and a PE."; and a PE.";
choice option { choice option {
description description
"Specifies the authentication scheme."; "Specifies the authentication
scheme.";
case auth-key-chain { case auth-key-chain {
leaf key-chain { leaf key-chain {
type key-chain:key-chain-ref; type key-chain:key-chain-ref;
description description
"key-chain name."; "Name of the key chain.";
} }
} }
case auth-key-explicit { case auth-key-explicit {
leaf key { leaf key {
type string; type string;
description description
"RIP authentication key. "RIP authentication key.
This model only supports the subset This model only supports the
of keys that are representable as subset of keys that are
ASCII strings."; representable as ASCII
strings.";
} }
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
associated with the key."; 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-routing')" { + "'vpn-common:vrrp-routing')" {
description description
"Only applies when protocol is VRRP."; "Only applies when the protocol is the
Virtual Router Redundancy Protocol
(VRRP).";
} }
description description
"Configuration specific to VRRP."; "Configuration specific to VRRP.";
reference reference
"RFC 5798: Virtual Router Redundancy Protocol "RFC 5798: Virtual Router Redundancy
(VRRP) Version 3 for IPv4 and IPv6"; 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 {
skipping to change at page 108, line 24 skipping to change at line 4993
type inet:ip-address; type inet:ip-address;
description description
"Indicates the IP address of the peer."; "Indicates the IP address of the peer.";
} }
leaf-list virtual-ip-address { leaf-list virtual-ip-address {
type inet:ip-address; type inet:ip-address;
description description
"Virtual IP addresses for a single VRRP "Virtual IP addresses for a single VRRP
group."; group.";
reference reference
"RFC 5798: Virtual Router Redundancy Protocol "RFC 5798: Virtual Router Redundancy
(VRRP) Version 3 for IPv4 and Protocol (VRRP) Version 3 for
IPv6, Sections 1.2 and 1.3"; IPv4 and IPv6,
Sections 1.2 and 1.3";
} }
leaf priority { leaf priority {
type uint8 { type uint8 {
range "1..254"; range "1..254";
} }
default "100"; default "100";
description description
"Sets the local priority of the VRRP "Sets the local priority of the VRRP
speaker."; speaker.";
} }
leaf ping-reply { leaf ping-reply {
type boolean; type boolean;
default "false"; default "false";
description description
"Controls whether the VRRP speaker should "Controls whether the VRRP speaker
answer to ping requests."; should reply to ping requests.";
} }
uses vpn-common:service-status; uses vpn-common:service-status;
} }
} }
} }
container oam { container oam {
description description
"Defines the Operations, Administration, "Defines the Operations, Administration,
and Maintenance (OAM) mechanisms used. and Maintenance (OAM) mechanisms used.
skipping to change at page 109, line 25 skipping to change at line 5043
} }
default "vpn-common:classic-bfd"; default "vpn-common:classic-bfd";
description description
"Specifies the BFD session type."; "Specifies the BFD session type.";
} }
leaf desired-min-tx-interval { leaf desired-min-tx-interval {
type uint32; type uint32;
units "microseconds"; units "microseconds";
default "1000000"; default "1000000";
description description
"The minimum interval between transmission of "The minimum interval between
BFD control packets that the operator transmissions of BFD Control packets, as
desires."; desired by the operator.";
reference reference
"RFC 5880: Bidirectional Forwarding Detection "RFC 5880: Bidirectional Forwarding
(BFD), Section 6.8.7"; Detection (BFD),
Section 6.8.7";
} }
leaf required-min-rx-interval { leaf required-min-rx-interval {
type uint32; type uint32;
units "microseconds"; units "microseconds";
default "1000000"; default "1000000";
description description
"The minimum interval between received BFD "The minimum interval between received BFD
control packets that the PE should support."; Control packets that the PE should
support.";
reference reference
"RFC 5880: Bidirectional Forwarding Detection "RFC 5880: Bidirectional Forwarding
(BFD), Section 6.8.7"; Detection (BFD),
Section 6.8.7";
} }
leaf local-multiplier { leaf local-multiplier {
type uint8 { type uint8 {
range "1..255"; range "1..255";
} }
default "3"; default "3";
description description
"Specifies the detection multiplier that is "Specifies the detection multiplier that
transmitted to a BFD peer. is transmitted to a BFD peer.
The detection interval for the receiving The detection interval for the receiving
BFD peer is calculated by multiplying the value BFD peer is calculated by multiplying the
of the negotiated transmission interval by value of the negotiated transmission
the received detection multiplier value."; interval by the received detection
multiplier value.";
reference reference
"RFC 5880: Bidirectional Forwarding Detection "RFC 5880: Bidirectional Forwarding
(BFD), Section 6.8.7"; Detection (BFD),
Section 6.8.7";
} }
leaf holdtime { leaf holdtime {
type uint32; type uint32;
units "milliseconds"; units "milliseconds";
description description
"Expected BFD holdtime. "Expected BFD holdtime.
The customer may impose some fixed The customer may impose some fixed
values for the holdtime period if the values for the holdtime period if the
provider allows the customer use of provider allows the customer to use
this function. this function.
If the provider doesn't allow the If the provider doesn't allow the
customer to use this function, customer to use this function,
the fixed-value will not be set."; fixed values will not be set.";
reference reference
"RFC 5880: Bidirectional Forwarding Detection "RFC 5880: Bidirectional Forwarding
(BFD), Section 6.8.18"; Detection (BFD),
Section 6.8.18";
} }
leaf profile { leaf profile {
type leafref { type leafref {
path "/l3vpn-ntw/vpn-profiles" path "/l3vpn-ntw/vpn-profiles"
+ "/valid-provider-identifiers" + "/valid-provider-identifiers"
+ "/bfd-profile-identifier/id"; + "/bfd-profile-identifier/id";
} }
description description
"Well-known service provider profile name. "Well-known service provider profile name.
skipping to change at page 110, line 50 skipping to change at line 5123
service level the customer wants to service level the customer wants to
achieve."; achieve.";
} }
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
"RFC 5880: Bidirectional Forwarding "RFC 5880: Bidirectional Forwarding
Detection (BFD), Section 6.7"; 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";
description description
"Container for CE-PE security encryption."; "Container for CE-PE security encryption.";
leaf enabled { leaf enabled {
type boolean; type boolean;
default "false"; default "false";
description description
"If true, traffic encryption on the "If set to 'true', traffic encryption on
connection is required. Otherwise, it the connection is required. Otherwise,
is disabled."; it is disabled.";
} }
leaf layer { leaf layer {
when "../enabled = 'true'" { when "../enabled = 'true'" {
description description
"It is included only when encryption "Included only when encryption
is enabled."; is enabled.";
} }
type enumeration { type enumeration {
enum layer2 { enum layer2 {
description description
"Encryption occurs at Layer 2."; "Encryption occurs at Layer 2.";
} }
enum layer3 { enum layer3 {
description description
"Encryption occurs at Layer 3. "Encryption occurs at Layer 3.
skipping to change at page 112, line 14 skipping to change at line 5184
is applied."; is applied.";
} }
} }
container encryption-profile { container encryption-profile {
when "../encryption/enabled = 'true'" { when "../encryption/enabled = 'true'" {
description description
"Indicates the layer on which encryption "Indicates the layer on which encryption
is enabled."; is enabled.";
} }
description description
"Container for encryption profile."; "Container for the encryption profile.";
choice profile { choice profile {
description description
"Choice for the encryption profile."; "Choice for the encryption profile.";
case provider-profile { case provider-profile {
leaf profile-name { leaf profile-name {
type leafref { type leafref {
path "/l3vpn-ntw/vpn-profiles" path "/l3vpn-ntw/vpn-profiles"
+ "/valid-provider-identifiers" + "/valid-provider-identifiers"
+ "/encryption-profile-identifier/id"; + "/encryption-profile-identifier/id";
} }
description description
"Name of the service provider's profile "Name of the service provider's
to be applied."; profile to be applied.";
} }
} }
case customer-profile { case customer-profile {
leaf customer-key-chain { leaf customer-key-chain {
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 of the attachment."; "Service parameters of the attachment.";
leaf inbound-bandwidth { leaf pe-to-ce-bandwidth {
if-feature "vpn-common:inbound-bw"; if-feature "vpn-common:inbound-bw";
type uint64; type uint64;
units "bps"; units "bps";
description description
"From the customer site's perspective, the "From the customer site's perspective, the
service inbound bandwidth of the connection service inbound bandwidth of the connection
or download bandwidth from the SP to or download bandwidth from the SP to the
the site. Note that the L3SM uses 'input- site. Note that the L3SM uses
-bandwidth' to refer to the same concept."; 'input-bandwidth' to refer to the same
concept.";
} }
leaf outbound-bandwidth { leaf ce-to-pe-bandwidth {
if-feature "vpn-common:outbound-bw"; if-feature "vpn-common:outbound-bw";
type uint64; type uint64;
units "bps"; units "bps";
description description
"From the customer site's perspective, "From the customer site's perspective,
the service outbound bandwidth of the the service outbound bandwidth of the
connection or upload bandwidth from connection or upload bandwidth from
the site to the SP. Note that the L3SM uses the site to the SP. Note that the L3SM
'output-bandwidth' to refer to the same uses 'output-bandwidth' to refer to the
concept."; same concept.";
} }
leaf mtu { leaf mtu {
type uint32; type uint32;
units "bytes"; units "bytes";
description description
"MTU at service level. If the service is IP, "MTU at the service level. If the service
it refers to the IP MTU. If Carriers' is IP, it refers to the IP MTU. If
Carriers (CsC) is enabled, the requested MTU Carriers' Carriers (CsC) is enabled, the
will refer to the MPLS maximum labeled packet requested MTU will refer to the MPLS
size and not to the IP MTU."; maximum labeled packet size and not to the
IP MTU.";
} }
container qos { container qos {
if-feature "vpn-common:qos"; if-feature "vpn-common:qos";
description description
"QoS configuration."; "QoS configuration.";
container qos-classification-policy { container qos-classification-policy {
description description
"Configuration of the traffic classification "Configuration of the traffic
policy."; classification policy.";
uses vpn-common:qos-classification-policy; uses vpn-common:qos-classification-policy;
} }
container qos-action { container qos-action {
description description
"List of QoS action policies."; "List of QoS action policies.";
list rule { list rule {
key "id"; key "id";
description description
"List of QoS actions."; "List of QoS actions.";
leaf id { leaf id {
type string; type string;
description description
"An identifier of the QoS action rule."; "An identifier of the QoS action
rule.";
} }
leaf target-class-id { leaf target-class-id {
type string; type string;
description description
"Identification of the class of service. "Identification of the class of
This identifier is internal to the service. This identifier is internal
administration."; to the administration.";
} }
leaf inbound-rate-limit { leaf inbound-rate-limit {
type decimal64 { type decimal64 {
fraction-digits 5; fraction-digits 5;
range "0..100"; range "0..100";
} }
units "percent"; units "percent";
description description
"Specifies whether/how to rate-limit the "Specifies whether/how to rate-limit
inbound traffic matching this QoS policy. the inbound traffic matching this QoS
It is expressed as a percent of the value policy. It is expressed as a percent
that is indicated in 'input-bandwidth'."; of the value that is indicated in
'input-bandwidth'.";
} }
leaf outbound-rate-limit { leaf outbound-rate-limit {
type decimal64 { type decimal64 {
fraction-digits 5; fraction-digits 5;
range "0..100"; range "0..100";
} }
units "percent"; units "percent";
description description
"Specifies whether/how to rate-limit the "Specifies whether/how to rate-limit
outbound traffic matching this QoS policy. the outbound traffic matching this
It is expressed as a percent of the value QoS policy. It is expressed as a
that is indicated in 'output-bandwidth'."; percent of the value that is
indicated in 'output-bandwidth'.";
} }
} }
} }
container qos-profile { container qos-profile {
description description
"QoS profile configuration."; "QoS profile configuration.";
list qos-profile { list qos-profile {
key "profile"; key "profile";
description description
"QoS profile. "QoS profile.
Can be standard profile or customized Can be a standard profile or
profile."; a customized profile.";
leaf profile { leaf profile {
type leafref { type leafref {
path "/l3vpn-ntw/vpn-profiles" path "/l3vpn-ntw/vpn-profiles"
+ "/valid-provider-identifiers" + "/valid-provider-identifiers"
+ "/qos-profile-identifier/id"; + "/qos-profile-identifier/id";
} }
description description
"QoS profile to be used."; "QoS profile to be used.";
} }
leaf direction { leaf direction {
type identityref { type identityref {
base vpn-common:qos-profile-direction; base vpn-common:qos-profile-direction;
} }
default "vpn-common:both"; default "vpn-common:both";
description description
"The direction to which the QoS profile "The direction to which the QoS
is applied."; profile is applied.";
} }
} }
} }
} }
container carriers-carrier { container carriers-carrier {
if-feature "vpn-common:carriers-carrier"; if-feature "vpn-common:carriers-carrier";
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 MPLS service using an customer builds an MPLS service using an
IP VPN to carry its traffic)."; IP VPN to carry its traffic).";
leaf signaling-type { leaf signaling-type {
type enumeration { type enumeration {
enum ldp { enum ldp {
description description
"Use LDP as the signaling protocol "Uses LDP as the signaling 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 configured."; also be configured.";
} }
enum bgp { enum bgp {
description description
"Use BGP as the signaling protocol "Uses BGP as the signaling protocol
between the PE and the CE. between the PE and the CE.
In this case, BGP must also be configured In this case, BGP must also be
as the routing protocol."; configured as the routing protocol.";
reference reference
"RFC 8277: Using BGP to Bind MPLS Labels "RFC 8277: Using BGP to Bind MPLS
to Address Prefixes"; Labels to Address
Prefixes";
} }
} }
default "bgp"; default "bgp";
description description
"MPLS signaling type."; "MPLS signaling type.";
} }
} }
container ntp { container ntp {
description description
"Time synchronization may be needed in some "Time synchronization may be needed in some
VPNs such as infrastructure and Management VPNs, such as infrastructure and management
VPNs. This container includes parameters to VPNs. This container includes parameters
enable NTP service."; to enable the NTP service.";
reference reference
"RFC 5905: Network Time Protocol Version 4: "RFC 5905: Network Time Protocol Version 4:
Protocol and Algorithms Protocol and Algorithms
Specification"; Specification";
leaf broadcast { leaf broadcast {
type enumeration { type enumeration {
enum client { enum client {
description description
"The VPN node will listen to NTP broadcast "The VPN node will listen to NTP
messages on this VPN network access."; broadcast messages on this VPN
network access.";
} }
enum server { enum server {
description description
"The VPN node will behave as a broadcast "The VPN node will behave as a
server."; broadcast server.";
} }
} }
description description
"Indicates NTP broadcast mode to use for the "Indicates the NTP broadcast mode to use
VPN network access."; for the VPN network access.";
} }
container auth-profile { container auth-profile {
description description
"Pointer to a local profile."; "Pointer to a local profile.";
leaf profile-id { leaf profile-id {
type string; type string;
description description
"A pointer to a local authentication "A pointer to a local authentication
profile on the VPN node is provided."; profile on the VPN node is provided.";
} }
skipping to change at page 117, line 32 skipping to change at line 5449
description description
"Indicates the address family."; "Indicates the address family.";
} }
leaf protocol-type { leaf protocol-type {
type enumeration { type enumeration {
enum host { enum host {
description description
"Hosts are directly connected to the "Hosts are directly connected to the
provider network. provider network.
Host protocols such as IGMP or MLD are Host protocols, such as IGMP or MLD,
required."; are required.";
} }
enum router { enum router {
description description
"Hosts are behind a customer router. "Hosts are behind a customer router.
PIM will be implemented."; PIM will be implemented.";
} }
enum both { enum both {
description description
"Some hosts are behind a customer router, "Some hosts are behind a customer
and some others are directly connected router, and some others are directly
to the provider network. Both host and connected to the provider network.
routing protocols must be used. Both host and routing protocols must
be used.
Typically, IGMP and PIM will be Typically, IGMP and PIM will be
implemented."; implemented.";
} }
} }
default "both"; default "both";
description description
"Multicast protocol type to be used with "Multicast protocol type to be used with
the customer site."; the customer site.";
} }
leaf remote-source { leaf remote-source {
type boolean; type boolean;
default "false"; default "false";
description description
"A remote multicast source is a source that is "A remote multicast source is a source
not on the same subnet as the that is not on the same subnet as the
vpn-network-access. When set to 'true', the VPN network access. When set to 'true',
multicast traffic from a remote source is the multicast traffic from a remote
accepted."; source is accepted.";
} }
container igmp { container igmp {
when "../protocol-type = 'host' and " when "../protocol-type = 'host' and "
+ "../address-family = 'vpn-common:ipv4' or " + "../address-family = 'vpn-common:ipv4' "
+ "'vpn-common:dual-stack'"; + "or 'vpn-common:dual-stack'";
if-feature "vpn-common:igmp"; if-feature "vpn-common:igmp";
description description
"Includes IGMP-related parameters."; "Includes IGMP-related parameters.";
list static-group { list static-group {
key "group-addr"; key "group-addr";
description description
"Multicast static source/group associated to "Multicast static source/group
IGMP session"; associated with the IGMP session.";
leaf group-addr { leaf group-addr {
type rt-types:ipv4-multicast-group-address; type rt-types:ipv4-multicast-group-address;
description description
"Multicast group IPv4 address."; "Multicast group IPv4 address.";
} }
leaf source-addr { leaf source-addr {
type rt-types:ipv4-multicast-source-address; type rt-types:ipv4-multicast-source\
-address;
description description
"Multicast source IPv4 address."; "Multicast source IPv4 address.";
} }
} }
leaf max-groups { leaf max-groups {
type uint32; type uint32;
description description
"Indicates the maximum number of groups."; "Indicates the maximum number of
groups.";
} }
leaf max-entries { leaf max-entries {
type uint32; type uint32;
description description
"Indicates the maximum number of IGMP "Indicates the maximum number of IGMP
entries."; entries.";
} }
leaf max-group-sources { leaf max-group-sources {
type uint32; type uint32;
description description
"The maximum number of group sources."; "The maximum number of group sources.";
} }
leaf version { leaf version {
type identityref { type identityref {
base vpn-common:igmp-version; base vpn-common:igmp-version;
} }
default "vpn-common:igmpv2"; default "vpn-common:igmpv2";
description description
"Version of the IGMP."; "Indicates the IGMP version.";
} }
uses vpn-common:service-status; uses vpn-common:service-status;
} }
container mld { container mld {
when "../protocol-type = 'host' and " when "../protocol-type = 'host' and "
+ "../address-family = 'vpn-common:ipv6' or " + "../address-family = 'vpn-common:ipv6' "
+ "'vpn-common:dual-stack'"; + "or 'vpn-common:dual-stack'";
if-feature "vpn-common:mld"; if-feature "vpn-common:mld";
description description
"Includes MLD-related parameters."; "Includes MLD-related parameters.";
list static-group { list static-group {
key "group-addr"; key "group-addr";
description description
"Multicast static source/group associated to "Multicast static source/group associated
the MLD session"; with the MLD session.";
leaf group-addr { leaf group-addr {
type rt-types:ipv6-multicast-group-address; type rt-types:ipv6-multicast-group-address;
description description
"Multicast group IPv6 address."; "Multicast group IPv6 address.";
} }
leaf source-addr { leaf source-addr {
type rt-types:ipv6-multicast-source-address; type rt-types:ipv6-multicast-source\
-address;
description description
"Multicast source IPv6 address."; "Multicast source IPv6 address.";
} }
} }
leaf max-groups { leaf max-groups {
type uint32; type uint32;
description description
"Indicates the maximum number of groups."; "Indicates the maximum number of
groups.";
} }
leaf max-entries { leaf max-entries {
type uint32; type uint32;
description description
"Indicates the maximum number of MLD "Indicates the maximum number of MLD
entries."; entries.";
} }
leaf max-group-sources { leaf max-group-sources {
type uint32; type uint32;
description description
"The maximum number of group sources."; "The maximum number of group sources.";
} }
leaf version { leaf version {
type identityref { type identityref {
base vpn-common:mld-version; base vpn-common:mld-version;
} }
default "vpn-common:mldv2"; default "vpn-common:mldv2";
description description
"Version of the MLD protocol."; "Indicates the MLD protocol version.";
} }
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 the protocol type is
'pim'.";
leaf hello-interval { leaf hello-interval {
type rt-types:timer-value-seconds16; type rt-types:timer-value-seconds16;
default "30"; default "30";
description description
"PIM hello-messages interval. If set to "Interval between PIM Hello messages.
'infinity' or 'not-set', no periodic If set to 'infinity' or 'not-set',
Hello messages are sent."; no periodic Hello messages are sent.";
reference reference
"RFC 7761: Protocol Independent Multicast - "RFC 7761: Protocol Independent
Sparse Mode (PIM-SM): Protocol Multicast - Sparse Mode
(PIM-SM): Protocol
Specification (Revised), Specification (Revised),
Section 4.11"; Section 4.11
RFC 8294: Common YANG Data Types for
the Routing Area";
} }
leaf dr-priority { leaf dr-priority {
type uint32; type uint32;
default "1"; default "1";
description description
"Indicates the preference in the DR election "Indicates the preference associated
process. A larger value has a higher with the DR election process. A larger
priority over a smaller value."; value has a higher priority over a
smaller value.";
reference reference
"RFC 7761: Protocol Independent Multicast - "RFC 7761: Protocol Independent
Sparse Mode (PIM-SM): Protocol Multicast - Sparse Mode
(PIM-SM): Protocol
Specification (Revised), Specification (Revised),
Section 4.3.2"; Section 4.3.2";
} }
uses vpn-common:service-status; uses vpn-common:service-status;
} }
} }
} }
} }
} }
} }
} }
} }
} }
} }
} }
<CODE ENDS> <CODE ENDS>
9. Security Considerations 9. Security Considerations
The YANG module specified in this document defines schema for data The YANG module specified in this document defines a 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
[RFC8446]. [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
skipping to change at page 121, line 42 skipping to change at line 5661
There are a number of data nodes defined in this YANG module that are There are a number of data nodes defined in this YANG 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:
* 'vpn-profiles': This container includes a set of sensitive data 'vpn-profiles': This container includes a set of sensitive data that
that influence how the L3VPN service is delivered. For example, influence how the L3VPN service is delivered. For example, an
an attacker who has access to these data nodes may be able to attacker who has access to these data nodes may be able to
manipulate routing policies, QoS policies, or encryption manipulate routing policies, QoS policies, or encryption
properties. These data nodes are defined with "nacm:default-deny- properties. These data nodes are defined with "nacm:default-deny-
write" tagging [I-D.ietf-opsawg-vpn-common]. write" tagging [RFC9181].
* 'vpn-services': An attacker who is able to access network nodes 'vpn-services': An attacker who is able to access network nodes can
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, keying material), leading to QoS, bandwidth, routing protocols, keying material), leading to
malfunctioning of the service and therefore to SLA violations. In malfunctioning of the service and therefore to Service Level
addition, an attacker could attempt to create an L3VPN service or Agreement (SLA) violations. In addition, an attacker could
add a new network access. In addition to using NACM to prevent attempt to create an L3VPN service or add a new network access.
authorized access, such activity can be detected by adequately In addition to using NACM to prevent unauthorized access, such
monitoring and tracking network configuration changes. activity can be detected by adequately monitoring and tracking
network configuration changes.
Some readable data nodes in this YANG module may be considered Some of the readable data nodes in this YANG module may be considered
sensitive or vulnerable in some network environments. It is thus sensitive or vulnerable in some network environments. It is thus
important to control read access (e.g., via get, get-config, or important to control read access (e.g., via get, get-config, or
notification) to these data nodes. These are the subtrees and data notification) to these data nodes. These are the subtrees and data
nodes and their sensitivity/vulnerability: nodes and their sensitivity/vulnerability:
* 'customer-name' and 'ip-connection': An attacker can retrieve '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
Disclosing such information may be considered as a violation of customer. Disclosing such information may be considered a
the customer-provider trust relationship. violation of the customer-provider trust relationship.
* 'keying-material': An attacker can retrieve the cryptographic keys 'keying-material': An attacker can retrieve the cryptographic keys
protecting the underlying VPN service (CE-PE routing, in protecting the underlying VPN service (CE-PE routing, in
particular). These keys could be used to inject spoofed routing particular). These keys could be used to inject spoofed routing
advertisements. advertisements.
Several data nodes ('bgp', 'ospf', 'isis', 'rip', and 'bfd') rely Several data nodes ('bgp', 'ospf', 'isis', 'rip', and 'bfd') rely
upon [RFC8177] for authentication purposes. Therefore, this module upon [RFC8177] for authentication purposes. Therefore, this module
inherits the security considerations discussed in Section 5 of inherits the security considerations discussed in Section 5 of
[RFC8177]. Also, these data nodes support supplying explicit keys as [RFC8177]. Also, these data nodes support supplying explicit keys as
strings in ASCII format. The use of keys in hexadecimal string strings in ASCII format. The use of keys in hexadecimal string
format would afford greater key entropy with the same number of key- format would afford greater key entropy with the same number of key-
string octets. However, such format is not included in this version string octets. However, such a format is not included in this
of the L3NM because it is not supported by the underlying device version of the L3NM, because it is not supported by the underlying
modules (e.g., [RFC8695]). device modules (e.g., [RFC8695]).
As discussed in Section 7.6.3, the module supports MD5 to basically As discussed in Section 7.6.3, the module supports MD5 to basically
accommodate the installed BGP base. MD5 suffers from the security accommodate the installed BGP base. MD5 suffers from the security
weaknesses discussed in Section 2 of [RFC6151] or Section 2.1 of weaknesses discussed in Section 2 of [RFC6151] and Section 2.1 of
[RFC6952]. [RFC6952].
[RFC8633] describes best current practices to be considered in VPNs [RFC8633] describes best current practices to be considered in VPNs
making use of NTP. Moreover, a mechanism to provide cryptographic making use of NTP. Moreover, a mechanism to provide cryptographic
security for NTP is specified in [RFC8915]. security for NTP is specified in [RFC8915].
10. IANA Considerations 10. IANA Considerations
This document requests IANA to register the following URI in the "ns" IANA has registered the following URI in the "ns" subregistry within
subregistry within the "IETF XML Registry" [RFC3688]: the "IETF XML Registry" [RFC3688]:
URI: urn:ietf:params:xml:ns:yang:ietf-l3vpn-ntw URI: urn:ietf:params:xml:ns:yang:ietf-l3vpn-ntw
Registrant Contact: The IESG. Registrant Contact: The IESG.
XML: N/A; the requested URI is an XML namespace. XML: N/A; the requested URI is an XML namespace.
This document requests IANA to register the following YANG module in IANA has registered the following YANG module in the "YANG Module
the "YANG Module Names" subregistry [RFC6020] within the "YANG Names" subregistry [RFC6020] within the "YANG Parameters" registry.
Parameters" registry.
name: ietf-l3vpn-ntw Name: ietf-l3vpn-ntw
namespace: urn:ietf:params:xml:ns:yang:ietf-l3vpn-ntw Maintained by IANA? N
maintained by IANA: N Namespace: urn:ietf:params:xml:ns:yang:ietf-l3vpn-ntw
prefix: l3nm Prefix: l3nm
reference: RFC XXXX Reference: RFC 9182
11. References 11. References
11.1. Normative References 11.1. Normative References
[I-D.ietf-opsawg-vpn-common] [ISO10589] ISO, "Information technology - Telecommunications and
Barguil, S., Dios, O. G. D., Boucadair, M., and Q. Wu, "A information exchange between systems - Intermediate System
Layer 2/3 VPN Common YANG Model", Work in Progress, to Intermediate System intra-domain routeing information
Internet-Draft, draft-ietf-opsawg-vpn-common-11, 23 exchange protocol for use in conjunction with the protocol
September 2021, <https://www.ietf.org/archive/id/draft- for providing the connectionless-mode network service (ISO
ietf-opsawg-vpn-common-11.txt>. 8473)", ISO/IEC 10589:2002, 2002,
<https://www.iso.org/standard/30932.html>.
[ISO10589] ISO, "Intermediate System to Intermediate System intra-
domain routeing information exchange protocol for use in
conjunction with the protocol for providing the
connectionless-mode network service (ISO 8473)", 2002,
<International Standard 10589:2002, Second Edition>.
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5,
RFC 1112, DOI 10.17487/RFC1112, August 1989, RFC 1112, DOI 10.17487/RFC1112, August 1989,
<https://www.rfc-editor.org/info/rfc1112>. <https://www.rfc-editor.org/info/rfc1112>.
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
dual environments", RFC 1195, DOI 10.17487/RFC1195, dual environments", RFC 1195, DOI 10.17487/RFC1195,
December 1990, <https://www.rfc-editor.org/info/rfc1195>. December 1990, <https://www.rfc-editor.org/info/rfc1195>.
[RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, [RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080,
skipping to change at page 127, line 33 skipping to change at line 5931
[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>.
11.2. Informative References [RFC9181] Barguil, S., Gonzalez de Dios, O., Ed., Boucadair, M.,
Ed., and Q. Wu, "A Common YANG Data Model for Layer 2 and
[I-D.evenwu-opsawg-yang-composed-vpn] Layer 3 VPNs", RFC 9181, DOI 10.17487/RFC9181, February
Even, R., Wu, B., Wu, Q., and YingCheng, "YANG Data Model 2022, <https://www.rfc-editor.org/info/rfc9181>.
for Composed VPN Service Delivery", Work in Progress,
Internet-Draft, draft-evenwu-opsawg-yang-composed-vpn-03,
8 March 2019, <https://www.ietf.org/archive/id/draft-
evenwu-opsawg-yang-composed-vpn-03.txt>.
[I-D.ietf-bess-evpn-prefix-advertisement] 11.2. Informative References
Rabadan, J., Henderickx, W., Drake, J. E., Lin, W., and A.
Sajassi, "IP Prefix Advertisement in EVPN", Work in
Progress, Internet-Draft, draft-ietf-bess-evpn-prefix-
advertisement-11, 18 May 2018,
<https://www.ietf.org/archive/id/draft-ietf-bess-evpn-
prefix-advertisement-11.txt>.
[I-D.ietf-idr-bgp-model] [BGP-YANG] Jethanandani, M., Patel, K., Hares, S., and J. Haas, "BGP
Jethanandani, M., Patel, K., Hares, S., and J. Haas, "BGP
YANG Model for Service Provider Networks", Work in YANG Model for Service Provider Networks", Work in
Progress, Internet-Draft, draft-ietf-idr-bgp-model-11, 11 Progress, Internet-Draft, draft-ietf-idr-bgp-model-12, 25
July 2021, <https://www.ietf.org/archive/id/draft-ietf- October 2021, <https://datatracker.ietf.org/doc/html/
idr-bgp-model-11.txt>. draft-ietf-idr-bgp-model-12>.
[I-D.ietf-pim-yang]
Liu, X., McAllister, P., Peter, A., Sivakumar, M., Liu,
Y., and F. Hu, "A YANG Data Model for Protocol Independent
Multicast (PIM)", Work in Progress, Internet-Draft, draft-
ietf-pim-yang-17, 19 May 2018,
<https://www.ietf.org/archive/id/draft-ietf-pim-yang-
17.txt>.
[I-D.ietf-rtgwg-qos-model]
Choudhary, A., Jethanandani, M., Strahle, N., Aries, E.,
and I. Chen, "A YANG Data Model for Quality of Service
(QoS)", Work in Progress, Internet-Draft, draft-ietf-
rtgwg-qos-model-04, 12 July 2021,
<https://www.ietf.org/archive/id/draft-ietf-rtgwg-qos-
model-04.txt>.
[I-D.ietf-teas-enhanced-vpn] [Enhanced-VPN-Framework]
Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A
Framework for Enhanced Virtual Private Network (VPN+) Framework for Enhanced Virtual Private Network (VPN+)
Services", Work in Progress, Internet-Draft, draft-ietf- Services", Work in Progress, Internet-Draft, draft-ietf-
teas-enhanced-vpn-08, 12 July 2021, teas-enhanced-vpn-09, 25 October 2021,
<https://www.ietf.org/archive/id/draft-ietf-teas-enhanced- <https://datatracker.ietf.org/doc/html/draft-ietf-teas-
vpn-08.txt>. enhanced-vpn-09>.
[I-D.ietf-teas-ietf-network-slices] [IEEE802.1AX]
Farrel, A., Gray, E., Drake, J., Rokui, R., Homma, S., IEEE, "802.1AX-2020 - IEEE Standard for Local and
Makhijani, K., Contreras, L. M., and J. Tantsura, Metropolitan Area Networks--Link Aggregation", IEEE Std
"Framework for IETF Network Slices", Work in Progress, 802.1AX-2020,
Internet-Draft, draft-ietf-teas-ietf-network-slices-04, 23 <https://ieeexplore.ieee.org/document/9105034>.
August 2021, <https://www.ietf.org/archive/id/draft-ietf-
teas-ietf-network-slices-04.txt>.
[I-D.ogondio-opsawg-uni-topology] [Network-Slices-Framework]
Dios, O. G. D., Barguil, S., Wu, Q., and M. Boucadair, "A Farrel, A., Ed., Gray, E., Drake, J., Rokui, R., Homma,
YANG Model for User-Network Interface (UNI) Topologies", S., Makhijani, K., Contreras, LM., and J. Tantsura,
Work in Progress, Internet-Draft, draft-ogondio-opsawg- "Framework for IETF Network Slices", Work in Progress,
uni-topology-01, 2 April 2020, Internet-Draft, draft-ietf-teas-ietf-network-slices-05, 25
<https://www.ietf.org/archive/id/draft-ogondio-opsawg-uni- October 2021, <https://datatracker.ietf.org/doc/html/
topology-01.txt>. draft-ietf-teas-ietf-network-slices-05>.
[IEEE802.1AX] [PIM-YANG] Liu, X., McAllister, P., Peter, A., Sivakumar, M., Liu,
"Link Aggregation", IEEE Std 802.1AX-2020, 2020. Y., and F. Hu, "A YANG Data Model for Protocol Independent
Multicast (PIM)", Work in Progress, Internet-Draft, draft-
ietf-pim-yang-17, 19 May 2018,
<https://datatracker.ietf.org/doc/html/draft-ietf-pim-
yang-17>.
[PYANG] "pyang", November 2020, [PYANG] "pyang", commit 524cf61, December 2021,
<https://github.com/mbj4668/pyang>. <https://github.com/mbj4668/pyang>.
[QoS-YANG] Choudhary, A., Jethanandani, M., Aries, E., and I. Chen,
"A YANG Data Model for Quality of Service (QoS)", Work in
Progress, Internet-Draft, draft-ietf-rtgwg-qos-model-06, 8
November 2021, <https://datatracker.ietf.org/doc/html/
draft-ietf-rtgwg-qos-model-06>.
[RFC3618] Fenner, B., Ed. and D. Meyer, Ed., "Multicast Source [RFC3618] Fenner, B., Ed. and D. Meyer, Ed., "Multicast Source
Discovery Protocol (MSDP)", RFC 3618, Discovery Protocol (MSDP)", RFC 3618,
DOI 10.17487/RFC3618, October 2003, DOI 10.17487/RFC3618, October 2003,
<https://www.rfc-editor.org/info/rfc3618>. <https://www.rfc-editor.org/info/rfc3618>.
[RFC3644] Snir, Y., Ramberg, Y., Strassner, J., Cohen, R., and B. [RFC3644] Snir, Y., Ramberg, Y., Strassner, J., Cohen, R., and B.
Moore, "Policy Quality of Service (QoS) Information Moore, "Policy Quality of Service (QoS) Information
Model", RFC 3644, DOI 10.17487/RFC3644, November 2003, Model", RFC 3644, DOI 10.17487/RFC3644, November 2003,
<https://www.rfc-editor.org/info/rfc3644>. <https://www.rfc-editor.org/info/rfc3644>.
skipping to change at page 130, line 32 skipping to change at line 6050
Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software- Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software-
Defined Networking (SDN): Layers and Architecture Defined Networking (SDN): Layers and Architecture
Terminology", RFC 7426, DOI 10.17487/RFC7426, January Terminology", RFC 7426, DOI 10.17487/RFC7426, January
2015, <https://www.rfc-editor.org/info/rfc7426>. 2015, <https://www.rfc-editor.org/info/rfc7426>.
[RFC7880] Pignataro, C., Ward, D., Akiya, N., Bhatia, M., and S. [RFC7880] Pignataro, C., Ward, D., Akiya, N., Bhatia, M., and S.
Pallagatti, "Seamless Bidirectional Forwarding Detection Pallagatti, "Seamless Bidirectional Forwarding Detection
(S-BFD)", RFC 7880, DOI 10.17487/RFC7880, July 2016, (S-BFD)", RFC 7880, DOI 10.17487/RFC7880, July 2016,
<https://www.rfc-editor.org/info/rfc7880>. <https://www.rfc-editor.org/info/rfc7880>.
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205,
RFC 7942, DOI 10.17487/RFC7942, July 2016,
<https://www.rfc-editor.org/info/rfc7942>.
[RFC8077] Martini, L., Ed. and G. Heron, Ed., "Pseudowire Setup and [RFC8077] Martini, L., Ed. and G. Heron, Ed., "Pseudowire Setup and
Maintenance Using the Label Distribution Protocol (LDP)", Maintenance Using the Label Distribution Protocol (LDP)",
STD 84, RFC 8077, DOI 10.17487/RFC8077, February 2017, STD 84, RFC 8077, DOI 10.17487/RFC8077, February 2017,
<https://www.rfc-editor.org/info/rfc8077>. <https://www.rfc-editor.org/info/rfc8077>.
[RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address [RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address
Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017, Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017,
<https://www.rfc-editor.org/info/rfc8277>. <https://www.rfc-editor.org/info/rfc8277>.
[RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, [RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki,
skipping to change at page 131, line 49 skipping to change at line 6108
[RFC8633] Reilly, D., Stenn, H., and D. Sibold, "Network Time [RFC8633] Reilly, D., Stenn, H., and D. Sibold, "Network Time
Protocol Best Current Practices", BCP 223, RFC 8633, Protocol Best Current Practices", BCP 223, RFC 8633,
DOI 10.17487/RFC8633, July 2019, DOI 10.17487/RFC8633, July 2019,
<https://www.rfc-editor.org/info/rfc8633>. <https://www.rfc-editor.org/info/rfc8633>.
[RFC8695] Liu, X., Sarda, P., and V. Choudhary, "A YANG Data Model [RFC8695] Liu, X., Sarda, P., and V. Choudhary, "A YANG Data Model
for the Routing Information Protocol (RIP)", RFC 8695, for the Routing Information Protocol (RIP)", RFC 8695,
DOI 10.17487/RFC8695, February 2020, DOI 10.17487/RFC8695, February 2020,
<https://www.rfc-editor.org/info/rfc8695>. <https://www.rfc-editor.org/info/rfc8695>.
[RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu,
"Handling Long Lines in Content of Internet-Drafts and
RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020,
<https://www.rfc-editor.org/info/rfc8792>.
[RFC8915] Franke, D., Sibold, D., Teichel, K., Dansarie, M., and R. [RFC8915] Franke, D., Sibold, D., Teichel, K., Dansarie, M., and R.
Sundblad, "Network Time Security for the Network Time Sundblad, "Network Time Security for the Network Time
Protocol", RFC 8915, DOI 10.17487/RFC8915, September 2020, Protocol", RFC 8915, DOI 10.17487/RFC8915, September 2020,
<https://www.rfc-editor.org/info/rfc8915>. <https://www.rfc-editor.org/info/rfc8915>.
[RFC8969] Wu, Q., Ed., Boucadair, M., Ed., Lopez, D., Xie, C., and [RFC8969] Wu, Q., Ed., Boucadair, M., Ed., Lopez, D., Xie, C., and
L. Geng, "A Framework for Automating Service and Network L. Geng, "A Framework for Automating Service and Network
Management with YANG", RFC 8969, DOI 10.17487/RFC8969, Management with YANG", RFC 8969, DOI 10.17487/RFC8969,
January 2021, <https://www.rfc-editor.org/info/rfc8969>. January 2021, <https://www.rfc-editor.org/info/rfc8969>.
[RFC9136] Rabadan, J., Ed., Henderickx, W., Drake, J., Lin, W., and
A. Sajassi, "IP Prefix Advertisement in Ethernet VPN
(EVPN)", RFC 9136, DOI 10.17487/RFC9136, October 2021,
<https://www.rfc-editor.org/info/rfc9136>.
[YANG-Composed-VPN]
Even, R., Wu, B., Wu, Q., and Y. Cheng, "YANG Data Model
for Composed VPN Service Delivery", Work in Progress,
Internet-Draft, draft-evenwu-opsawg-yang-composed-vpn-03,
8 March 2019, <https://datatracker.ietf.org/doc/html/
draft-evenwu-opsawg-yang-composed-vpn-03>.
[YANG-SAPs]
Gonzalez de Dios, O., Barguil, S., Wu, Q., Boucadair, M.,
and V. Lopez, "A Network YANG Model for Service Attachment
Points", Work in Progress, Internet-Draft, draft-ietf-
opsawg-sap-00, 25 January 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-
sap-00>.
Appendix A. L3VPN Examples Appendix A. L3VPN Examples
A.1. 4G VPN Provisioning Example A.1. 4G VPN Provisioning Example
L3VPNs are widely used to deploy 3G/4G, fixed, and enterprise L3VPNs are widely used to deploy 3G/4G, fixed, and enterprise
services mainly because several traffic discrimination policies can services, mainly because several traffic discrimination policies can
be applied within the network to deliver to the mobile customers a be applied within the network to deliver to the mobile customers a
service that meets the SLA requirements. service that meets the SLA requirements.
As it is shown in the Figure 31, typically, an eNodeB (CE) is Typically, and as shown in Figure 31, an eNodeB (CE) is directly
directly connected to the access routers of the mobile backhaul and connected to the access routers of the mobile backhaul and their
their logical interfaces (one or many according to the service type) logical interfaces (one or many, according to the service type) are
are configured in a VPN that transports the packets to the mobile configured in a VPN that transports the packets to the mobile core
core platforms. In this example, a 'vpn-node' is created with two platforms. In this example, a 'vpn-node' is created with two 'vpn-
'vpn-network-accesses'. network-accesses'.
+-------------+ +------------------+ +-------------+ +------------------+
| | | PE | | | | PE |
| | | 198.51.100.1 | | | | 198.51.100.1 |
| eNodeB |>--------/------->|........... | | eNodeB |>--------/------->|........... |
| | vlan 1 | | | | | vlan 1 | | |
| |>--------/------->|...... | | | |>--------/------->|...... | |
| | vlan 2 | | | | | | vlan 2 | | | |
| | Direct | +-------------+ | | | Direct | +-------------+ |
+-------------+ Routing | | vpn-node-id | | +-------------+ Routing | | vpn-node-id | |
| | 44 | | | | 44 | |
| +-------------+ | | +-------------+ |
| | | |
+------------------+ +------------------+
Figure 31: Mobile Backhaul Example Figure 31: Mobile Backhaul Example
To create an L3VPN service using the L3NM, the following steps can be To create an L3VPN service using the L3NM, the following steps can be
followed. followed.
First: Create the 4G VPN service (Figure 32). First, create the 4G VPN service (Figure 32).
POST: /restconf/data/ietf-l3vpn-ntw:l3vpn-ntw/vpn-services POST: /restconf/data/ietf-l3vpn-ntw:l3vpn-ntw/vpn-services
Host: example.com Host: example.com
Content-Type: application/yang-data+json Content-Type: application/yang-data+json
{ {
"ietf-l3vpn-ntw:vpn-services": { "ietf-l3vpn-ntw:vpn-services": {
"vpn-service": [ "vpn-service": [
{ {
"vpn-id": "4G", "vpn-id": "4G",
"customer-name": "mycustomer", "vpn-description": "VPN to deploy 4G services",
"vpn-service-topology": "custom", "customer-name": "mycustomer",
"vpn-description": "VPN to deploy 4G services", "vpn-service-topology": "custom",
"vpn-instance-profiles": { "vpn-instance-profiles": {
"vpn-instance-profile": [ "vpn-instance-profile": [
{ {
"profile-id": "simple-profile", "profile-id": "simple-profile",
"local-as": 65550, "local-as": 65550,
"rd": "0:65550:1", "rd": "0:65550:1",
"address-family": [ "address-family": [
{ {
"address-family": "ietf-vpn-common:dual-stack", "address-family": "ietf-vpn-common:dual-stack",
"vpn-target": [ "vpn-targets": {
{ "vpn-target": [
"id": 1, {
"route-targets": [ "id": 1,
{ "route-targets": [
"route-target": "0:65550:1" {
} "route-target": "0:65550:1"
], }
"route-target-type": "both" ],
} "route-target-type": "both"
] }
} ]
] }
} }
] ]
} }
} ]
] }
} }
} ]
}
}
Figure 32: Create VPN Service Figure 32: Create VPN Service
Second: Create a VPN node as depicted in Figure 33. In this type of Second, create a VPN node, as depicted in Figure 33. In this type of
service, the VPN node is equivalent to the VRF configured in the service, the VPN node is equivalent to VRF configured in the physical
physical device ('ne-id'=198.51.100.1). device ('ne-id'=198.51.100.1). NOTE: '\' line wrapping in Figures 33
and 34 is implemented per [RFC8792].
=============== NOTE: '\' line wrapping per RFC 8792 ================
POST: /restconf/data/ietf-l3vpn-ntw:l3vpn-ntw/\ POST: /restconf/data/ietf-l3vpn-ntw:l3vpn-ntw/\
vpn-services/vpn-service=4G vpn-services/vpn-service=4G
Host: example.com Host: example.com
Content-Type: application/yang-data+json Content-Type: application/yang-data+json
{ {
"ietf-l3vpn-ntw:vpn-nodes": { "ietf-l3vpn-ntw:vpn-nodes": {
"vpn-node": [ "vpn-node": [
{ {
skipping to change at page 134, line 34 skipping to change at line 6258
} }
} }
] ]
} }
} }
Figure 33: Create VPN Node Figure 33: Create VPN Node
Finally, two VPN network accesses are created using the same physical Finally, two VPN network accesses are created using the same physical
port ('interface-id'=1/1/1). Each 'vpn-network-access' has a port ('interface-id'=1/1/1). Each 'vpn-network-access' has a
particular VLAN (1,2) to differentiate the traffic between: Sync and particular VLAN interface (1,2): "SYNC" and "DATA" (Figure 34).
data (Figure 34). These interfaces differentiate the traffic between them.
=============== NOTE: '\' line wrapping per RFC 8792 ================
POST: /restconf/data/ietf-l3vpn-ntw:l3vpn-ntw/\ POST: /restconf/data/ietf-l3vpn-ntw:l3vpn-ntw/\
vpn-services/vpn-service=4G/vpn-nodes/vpn-node=44 vpn-services/vpn-service=4G/vpn-nodes/vpn-node=44
content-type: application/yang-data+json content-type: application/yang-data+json
{ {
"ietf-l3vpn-ntw:vpn-network-accesses": { "ietf-l3vpn-ntw:vpn-network-accesses": {
"vpn-network-access": [ "vpn-network-access": [
{ {
"id": "1/1/1.1", "id": "1/1/1.1",
skipping to change at page 137, line 21 skipping to change at line 6388
} }
} }
] ]
} }
} }
Figure 34: Create VPN Network Access Figure 34: Create VPN Network Access
A.2. Loopback Interface A.2. Loopback Interface
An example of loopback interface is depicted in Figure 35. An example of a loopback interface is depicted in Figure 35.
{ {
"ietf-l3vpn-ntw:vpn-network-accesses": { "ietf-l3vpn-ntw:vpn-network-accesses": {
"vpn-network-access": [ "vpn-network-access": [
{ {
"id": "vpn-access-loopback", "id": "vpn-access-loopback",
"interface-id": "Loopback1", "interface-id": "Loopback1",
"description": "An example of loopback interface.", "description": "An example of a loopback interface.",
"vpn-network-access-type": "ietf-vpn-common:loopback", "vpn-network-access-type": "ietf-vpn-common:loopback",
"status": { "status": {
"admin-status": { "admin-status": {
"status": "ietf-vpn-common:admin-up" "status": "ietf-vpn-common:admin-up"
} }
}, },
"ip-connection": { "ip-connection": {
"ipv6": { "ipv6": {
"local-address": "2001:db8::4", "local-address": "2001:db8::4",
"prefix-length": 128 "prefix-length": 128
} }
} }
} }
] ]
} }
} }
Figure 35: VPN Network Access with a Loopback Interface (Message Figure 35: VPN Network Access with a Loopback Interface (Message
Body) Body)
A.3. Overriding VPN Instance Profile Parameters A.3. Overriding VPN Instance Profile Parameters
Figure 36 shows a simplified example to illustrate how some Figure 36 shows a simplified example to illustrate how some
information that is provided at the VPN service level (particularly information that is provided at the VPN service level (particularly
as part of the 'vpn-instance-profiles') can be overridden by the one as part of the 'vpn-instance-profiles') can be overridden by
configured at the VPN node level. In this example, PE3 and PE4 information configured at the VPN node level. In this example, PE3
inherit the 'vpn-instance-profiles' parameters that are specified at and PE4 inherit the 'vpn-instance-profiles' parameters that are
the VPN service level, but PE1 and PE2 are provided with "maximum- specified at the VPN service level, but PE1 and PE2 are provided with
routes" values at the VPN node level that override the ones that are "maximum-routes" values at the VPN node level that override the
specified at the VPN service level. values that are specified at the VPN service level.
{
"ietf-l3vpn-ntw:vpn-services": {
"vpn-service": [
{
"vpn-id": "override-example",
"vpn-service-topology": "ietf-vpn-common:hub-spoke",
"vpn-instance-profiles": {
"vpn-instance-profile": [
{
"profile-id": "HUB",
"role": "ietf-vpn-common:hub-role",
"local-as": 64510,
"rd-suffix": 1001,
"address-family": [
{
"address-family": "ietf-vpn-common:dual-stack",
"maximum-routes": [
{
"protocol": "ietf-vpn-common:any",
"maximum-routes": 100
}
]
}
]
},
{
"profile-id": "SPOKE",
"role": "ietf-vpn-common:spoke-role",
"local-as": 64510,
"address-family": [
{
"address-family": "ietf-vpn-common:dual-stack",
"maximum-routes": [
{
"protocol": "ietf-vpn-common:any",
"maximum-routes": 1000
}
] {
} "ietf-l3vpn-ntw:vpn-services": {
] "vpn-service": [
} {
] "vpn-id": "override-example",
}, "vpn-service-topology": "ietf-vpn-common:hub-spoke",
"vpn-nodes": { "vpn-instance-profiles": {
"vpn-node": [ "vpn-instance-profile": [
{ {
"vpn-node-id": "PE1", "profile-id": "HUB",
"ne-id": "pe1", "role": "ietf-vpn-common:hub-role",
"router-id": "198.51.100.1", "local-as": 64510,
"active-vpn-instance-profiles": { "rd-suffix": 1001,
"vpn-instance-profile": [ "address-family": [
{ {
"profile-id": "HUB", "address-family": "ietf-vpn-common:dual-stack",
"rd": "1:198.51.100.1:1001", "maximum-routes": [
"address-family": [
{ {
"address-family": "ietf-vpn-common:dual-stack", "protocol": "ietf-vpn-common:any",
"maximum-routes": [ "maximum-routes": 100
{
"protocol": "ietf-vpn-common:any",
"maximum-routes": 10
}
]
} }
] ]
} }
] ]
} },
}, {
{ "profile-id": "SPOKE",
"vpn-node-id": "PE2", "role": "ietf-vpn-common:spoke-role",
"ne-id": "pe2", "local-as": 64510,
"router-id": "198.51.100.2", "address-family": [
"active-vpn-instance-profiles": {
"vpn-instance-profile": [
{ {
"profile-id": "SPOKE", "address-family": "ietf-vpn-common:dual-stack",
"address-family": [ "maximum-routes": [
{ {
"address-family": "ietf-vpn-common:dual-stack", "protocol": "ietf-vpn-common:any",
"maximum-routes": [ "maximum-routes": 1000
{
"protocol": "ietf-vpn-common:any",
"maximum-routes": 100
}
]
} }
] ]
} }
] ]
} }
}, ]
{ },
"vpn-node-id": "PE3", "vpn-nodes": {
"ne-id": "pe3", "vpn-node": [
"router-id": "198.51.100.3", {
"active-vpn-instance-profiles": { "vpn-node-id": "PE1",
"vpn-instance-profile": [ "ne-id": "pe1",
{ "router-id": "198.51.100.1",
"profile-id": "SPOKE" "active-vpn-instance-profiles": {
} "vpn-instance-profile": [
] {
} "profile-id": "HUB",
}, "rd": "1:198.51.100.1:1001",
{ "address-family": [
"vpn-node-id": "PE4", {
"ne-id": "pe4", "address-family":
"router-id": "198.51.100.4", "ietf-vpn-common:dual-stack",
"active-vpn-instance-profiles": { "maximum-routes": [
"vpn-instance-profile": [ {
{ "protocol": "ietf-vpn-common:any",
"profile-id": "SPOKE" "maximum-routes": 10
} }
] ]
}
]
}
]
}
},
{
"vpn-node-id": "PE2",
"ne-id": "pe2",
"router-id": "198.51.100.2",
"active-vpn-instance-profiles": {
"vpn-instance-profile": [
{
"profile-id": "SPOKE",
"address-family": [
{
"address-family":
"ietf-vpn-common:dual-stack",
"maximum-routes": [
{
"protocol": "ietf-vpn-common:any",
"maximum-routes": 100
}
]
}
]
}
]
}
},
{
"vpn-node-id": "PE3",
"ne-id": "pe3",
"router-id": "198.51.100.3",
"active-vpn-instance-profiles": {
"vpn-instance-profile": [
{
"profile-id": "SPOKE"
}
]
}
},
{
"vpn-node-id": "PE4",
"ne-id": "pe4",
"router-id": "198.51.100.4",
"active-vpn-instance-profiles": {
"vpn-instance-profile": [
{
"profile-id": "SPOKE"
}
]
}
} }
} ]
] }
} }
} ]
] }
} }
}
Figure 36: VPN Instance Profile Example (Message Body) Figure 36: VPN Instance Profile Example (Message Body)
A.4. Multicast VPN Provisioning Example A.4. Multicast VPN Provisioning Example
IPTV is mainly distributed through multicast over the LANs. In the IPTV is mainly distributed through multicast over the LANs. In the
following example, PIM-SM is enabled and functional between the PE following example, PIM - Sparse Mode (PIM-SM) is enabled and
and the CE. The PE receives multicast traffic from a CE that is functional between the PE and the CE. The PE receives multicast
directly connected to the multicast source. The signaling between PE traffic from a CE that is directly connected to the multicast source.
and CE is achieved using BGP. Also, RP is statically configured for The signaling between the PE and the CE is achieved using BGP. Also,
a multicast group. the RP is statically configured for a multicast group.
+-----------+ +------+ +------+ +-----------+ +-----------+ +------+ +------+ +-----------+
| Multicast |---| CE |--/--| PE |----| Backbone | | Multicast |---| CE |--/--| PE |----| Backbone |
| source | +------+ +------+ | IP/MPLS | | source | +------+ +------+ | IP/MPLS |
+-----------+ +-----------+ +-----------+ +-----------+
Figure 37: Multicast L3VPN Service Example Figure 37: Multicast L3VPN Service Example
An example is provided below to illustrate how to configure a Figure 38 illustrates how to configure a multicast L3VPN service
multicast L3VPN service using the L3NM. using the L3NM.
First, the multicast service is created together with a generic VPN First, the multicast service is created together with a generic VPN
instance profile (see the excerpt of the request message body shown instance profile (see the excerpt of the request message body shown
in Figure 38) in Figure 38).
{ {
"ietf-l3vpn-ntw:vpn-services": { "ietf-l3vpn-ntw:vpn-services": {
"vpn-service": [ "vpn-service": [
{ {
"vpn-id": "Multicast-IPTV", "vpn-id": "Multicast-IPTV",
"vpn-description": "Multicast IPTV VPN service", "vpn-description": "Multicast IPTV VPN service",
"customer-name": "a-name", "customer-name": "a-name",
"vpn-service-topology": "ietf-vpn-common:hub-spoke", "vpn-service-topology": "ietf-vpn-common:hub-spoke",
"vpn-instance-profiles": { "vpn-instance-profiles": {
"vpn-instance-profile": [ "vpn-instance-profile": [
skipping to change at page 143, line 42 skipping to change at line 6663
the excerpt of the request message body shown in Figure 40). the excerpt of the request message body shown in Figure 40).
{ {
"ietf-l3vpn-ntw:vpn-network-access": { "ietf-l3vpn-ntw:vpn-network-access": {
"id": "1/1/1", "id": "1/1/1",
"description": "Connected-to-source", "description": "Connected-to-source",
"vpn-network-access-type": "ietf-vpn-common:point-to-point", "vpn-network-access-type": "ietf-vpn-common:point-to-point",
"vpn-instance-profile": "multicast", "vpn-instance-profile": "multicast",
"status": { "status": {
"admin-status": { "admin-status": {
"status": "vpn-common:admin-up" "status": "ietf-vpn-common:admin-up"
}, },
"ip-connection": { "ip-connection": {
"ipv4": { "ipv4": {
"local-address": "203.0.113.1", "local-address": "203.0.113.1",
"prefix-length": 30, "prefix-length": 30,
"address-allocation-type": "static-address", "address-allocation-type": "static-address",
"static-addresses": { "static-addresses": {
"primary-address": "1", "primary-address": "1",
"address": [ "address": [
{ {
skipping to change at page 144, line 26 skipping to change at line 6696
"bgp": { "bgp": {
"description": "Connected to CE", "description": "Connected to CE",
"peer-as": "65537", "peer-as": "65537",
"address-family": "ietf-vpn-common:ipv4", "address-family": "ietf-vpn-common:ipv4",
"neighbor": "203.0.113.2" "neighbor": "203.0.113.2"
} }
} }
] ]
}, },
"service": { "service": {
"inbound-bandwidth": "100000000", "pe-to-ce-bandwidth": "100000000",
"outbound-bandwidth": "100000000", "ce-to-pe-bandwidth": "100000000",
"mtu": 1500, "mtu": 1500,
"multicast": { "multicast": {
"access-type": "source-only", "access-type": "source-only",
"address-family": "ietf-vpn-common:ipv4", "address-family": "ietf-vpn-common:ipv4",
"protocol-type": "router", "protocol-type": "router",
"pim": { "pim": {
"hello-interval": 30, "hello-interval": 30,
"status": { "status": {
"admin-status": { "admin-status": {
"status": "ietf-vpn-common:admin-up" "status": "ietf-vpn-common:admin-up"
skipping to change at page 145, line 5 skipping to change at line 6720
} }
} }
} }
} }
} }
} }
Figure 40: Create VPN Network Access (Excerpt of the Message Figure 40: Create VPN Network Access (Excerpt of the Message
Request Body) Request Body)
Appendix B. Implementation Status
This section records the status of known implementations of the YANG
module defined by this specification at the time of posting of this
document and is based on a proposal described in [RFC7942]. The
description of implementations in this section is intended to assist
the IETF in its decision processes in progressing drafts to RFCs.
Please note that the listing of any individual implementation here
does not imply endorsement by the IETF. Furthermore, no effort has
been spent to verify the information presented here that was supplied
by IETF contributors. This is not intended as, and must not be
construed to be, a catalog of available implementations or their
features. Readers are advised to note that other implementations may
exist.
According to [RFC7942], "this will allow reviewers and working groups
to assign due consideration to documents that have the benefit of
running code, which may serve as evidence of valuable experimentation
and feedback that have made the implemented protocols more mature.
It is up to the individual working groups to use this information as
they see fit".
Note to the RFC Editor: As per [RFC7942] guidelines, please remove
this Implementation Status apendix prior publication.
B.1. Nokia Implementation
Details can be found at: https://github.com/IETF-OPSAWG-
WG/l3nm/blob/master/Implementattion/Nokia.txt
B.2. Huawei Implementation
Details can be found at: https://github.com/IETF-OPSAWG-
WG/l3nm/blob/master/Implementattion/Huawei.txt
B.3. Infinera Implementation
Details can be found at: https://github.com/IETF-OPSAWG-
WG/l3nm/blob/master/Implementattion/Infinera.txt
B.4. Ribbon-ECI Implementation
Details can be found at: https://github.com/IETF-OPSAWG-
WG/l3nm/blob/master/Implementattion/Ribbon-ECI.txt
B.5. Juniper Implementation
https://github.com/IETF-OPSAWG-WG/lxnm/blob/master/Implementattion/
Juniper
Acknowledgements Acknowledgements
During the discussions of this work, helpful comments, suggestions, During the discussions of this work, helpful comments, suggestions,
and reviews were received from (listed alphabetically): Raul Arco, and reviews were received from (listed alphabetically) Raul Arco,
Miguel Cros Cecilia, Joe Clarke, Dhruv Dhody, Adrian Farrel, Roque Miguel Cros Cecilia, Joe Clarke, Dhruv Dhody, Adrian Farrel, Roque
Gagliano, Christian Jacquenet, Kireeti Kompella, Julian Lucek, Greg Gagliano, Christian Jacquenet, Kireeti Kompella, Julian Lucek, Greg
Mirsky, and Tom Petch. Many thanks to them. Thanks to Philip Eardly Mirsky, and Tom Petch. Many thanks to them. Thanks to Philip
for the review of an early version of the document. Eardley for the review of an early draft version of the document.
Daniel King, Daniel Voyer, Luay Jalil, and Stephane Litkowski Daniel King, Daniel Voyer, Luay Jalil, and Stephane Litkowski
contributed to early version of the individual submission. Many contributed to early draft versions of this document. Many thanks to
thanks to Robert Wilton for the AD review. Thanks to Andrew Malis Robert Wilton for the AD review. Thanks to Andrew Malis for the
for the routing directorate review, Rifaat Shekh-Yusef for the routing directorate review, Rifaat Shekh-Yusef for the security
security directorate review, Qin Wu for the opsdir review, and Pete directorate review, Qin Wu for the opsdir review, and Pete Resnick
Resnick for the genart directorate review. Thanks to Michael Scharf for the genart directorate review. Thanks to Michael Scharf for the
for the discussion on TCP-AO. Thanks to Martin Duke, Lars Eagert, discussion on the TCP-AO. Thanks to Martin Duke, Lars Eggert,
Zaheduzzaman Sarker, Roman Danyliw, Erik Kline, Benjamin Kaduk, Zaheduzzaman Sarker, Roman Danyliw, Erik Kline, Benjamin Kaduk,
Francesca Palombini, and Eric Vyncke for the IESG review. Francesca Palombini, and Éric Vyncke for the IESG review.
This work was supported in part by the European Commission funded This work was supported in part by the European Commission-funded
H2020-ICT-2016-2 METRO-HAUL project (G.A. 761727) and Horizon 2020 H2020-ICT-2016-2 METRO-HAUL project (G.A. 761727) and Horizon 2020
Secured autonomic traffic management for a Tera of SDN flows Secured autonomic traffic management for a Tera of SDN flows
(Teraflow) project (G.A. 101015857). (Teraflow) project (G.A. 101015857).
Contributors Contributors
Victor Lopez Victor Lopez
Telefonica Nokia
Email: victor.lopezalvarez@telefonica.com Madrid
Spain
Email: victor.lopez@nokia.com
Qin Wu Qin Wu
Huawei Huawei
Email: bill.wu@huawei.com>
Manuel Julian Email: bill.wu@huawei.com
Manuel Lopez
Vodafone Vodafone
Spain
Email: manuel-julian.lopez@vodafone.com Email: manuel-julian.lopez@vodafone.com
Lucia Oliva Ballega Lucia Oliva Ballega
Telefonica Telefonica
Email: lucia.olivaballega.ext@telefonica.com Email: lucia.olivaballega.ext@telefonica.com
Erez Segev Erez Segev
ECI Telecom Ribbon Communications
Email: erez.segev@ecitele.com>
Email: erez.segev@rbbn.com
Paul Sherratt Paul Sherratt
Gamma Telecom Gamma Telecom
Email: paul.sherratt@gamma.co.uk Email: paul.sherratt@gamma.co.uk
Authors' Addresses Authors' Addresses
Samier Barguil Samier Barguil
Telefonica Telefonica
Madrid Madrid
Spain Spain
Email: samier.barguilgiraldo.ext@telefonica.com Email: samier.barguilgiraldo.ext@telefonica.com
Oscar Gonzalez de Dios (editor) Oscar Gonzalez de Dios (editor)
Telefonica Telefonica
Madrid Madrid
Spain Spain
Email: oscar.gonzalezdedios@telefonica.com Email: oscar.gonzalezdedios@telefonica.com
Mohamed Boucadair (editor) Mohamed Boucadair (editor)
Orange Orange
Rennes 35000 35000 Rennes
France France
Email: mohamed.boucadair@orange.com Email: mohamed.boucadair@orange.com
Luis Angel Munoz Luis Angel Munoz
Vodafone Vodafone
Spain Spain
Email: luis-angel.munoz@vodafone.com Email: luis-angel.munoz@vodafone.com
Alejandro Aguado Alejandro Aguado
Nokia Nokia
Madrid Madrid
Spain Spain
 End of changes. 613 change blocks. 
2327 lines changed or deleted 2396 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/