A YANG Network Data Model for Layer 3 VPNsTelefonicaMadridSpainsamier.barguilgiraldo.ext@telefonica.comTelefonicaMadridSpainoscar.gonzalezdedios@telefonica.comOrangeRennes35000Francemohamed.boucadair@orange.comVodafoneSpainluis-angel.munoz@vodafone.comNokiaMadridSpainalejandro.aguado_martin@nokia.com
ops
OPSAWGl3vpnAutomationService ProvisioningNetwork AutomationService OrchestrationService DeliveryNETCONFRESTCONFSlicesnetwork slicingAs a complement to the Layer 3 Virtual Private Network Service Model (L3SM), which is used for communication between customers and service
providers, this document defines an L3VPN Network Model (L3NM) that
can be used for the provisioning of Layer 3 Virtual Private Network
(L3VPN) services within a service provider network. The model provides a
network-centric view of L3VPN services.The L3NM is meant to be used by a network controller to derive the
configuration information that will be sent to relevant network devices.
The model can also facilitate communication between a service
orchestrator and a network controller/orchestrator.Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by
the Internet Engineering Steering Group (IESG). Further
information on Internet Standards is available in Section 2 of
RFC 7841.
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
.
Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
() in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Revised BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Revised BSD License.
Table of Contents
. Introduction
. Terminology
. Acronyms and Abbreviations
. L3NM Reference Architecture
. Relationship to Other YANG Data Models
. Sample Uses of the L3NM Data Model
. Enterprise Layer 3 VPN Services
. Multi-Domain Resource Management
. Management of Multicast Services
. Description of the L3NM YANG Module
. Overall Structure of the Module
. VPN Profiles
. VPN Services
. VPN Instance Profiles
. VPN Nodes
. VPN Network Accesses
. Connection
. IP Connection
. CE-PE Routing Protocols
. Static Routing
. BGP
. OSPF
. IS-IS
. RIP
. VRRP
. OAM
. Security
. Services
. Overview
. QoS
. Multicast
. L3NM YANG Module
. Security Considerations
. IANA Considerations
. References
. Normative References
. Informative References
. L3VPN Examples
. 4G VPN Provisioning Example
. Loopback Interface
. Overriding VPN Instance Profile Parameters
. Multicast VPN Provisioning Example
Acknowledgements
Contributors
Authors' Addresses
Introduction defines a YANG Layer 3 Virtual Private
Network Service Model (L3SM) that can be used for
communication between customers and service providers. Such a model
focuses on describing the customer view of the Virtual Private Network
(VPN) services and provides an abstracted view of the customer's
requested services. That approach limits the usage of the L3SM to the
role of a customer service model (as per ).This document defines a YANG module called the "L3VPN Network Model"
(L3NM). The L3NM is aimed at providing a network-centric view of Layer 3
(L3) VPN services. This data model can be used to facilitate
communication between the service orchestrator and the network
controller/orchestrator by allowing more network-centric information
to be included. It enables such additional capabilities as resource
management, or it serves as a multi-domain orchestration interface where
logical resources (such as route targets or route distinguishers) must
be coordinated.This document uses the common VPN YANG module defined in .This document does not obsolete . These
two modules are used for similar objectives but with different scopes
and views.The L3NM YANG module was initially built with a "prune and extend"
approach, taking as a starting point the YANG module described in . Nevertheless, the L3NM is not defined as an
augment to the L3SM, because a specific structure is required to meet
network-oriented L3 needs.Some information captured in the L3SM can be passed by the
orchestrator in the L3NM (e.g., customer) or be used to feed some L3NM
attributes (e.g., actual forwarding policies). Also, some information
captured in the L3SM may be maintained locally within the orchestrator,
which is in charge of maintaining the correlation between a customer
view and its network instantiation. Likewise, some information captured
and exposed using the L3NM can feed the service layer (e.g.,
capabilities) to drive VPN service order handling and thus the
L3SM. illustrates how the
L3NM can be used within the network management automation
architecture.The L3NM does not attempt to address all deployment cases, especially
those where L3VPN connectivity is supported through the coordination
of different VPNs in different underlying networks. More complex
deployment scenarios involving the coordination of different VPN
instances and different technologies to provide end-to-end VPN
connectivity are addressed by complementary YANG modules, e.g., .The L3NM focuses on Layer 3 VPNs based on BGP Provider Edges (PEs) as
described in , , and ; and Multicast
VPNs as described in and .The YANG data model in this document conforms to the Network
Management Datastore Architecture (NMDA) defined in .TerminologyThe key words "MUST", "MUST NOT",
"REQUIRED", "SHALL",
"SHALL NOT", "SHOULD",
"SHOULD NOT",
"RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document
are to be interpreted as described in BCP 14
when, and only
when, they appear in all capitals, as shown here.This document assumes that the reader is familiar with the contents
of , , , , and and uses the terminology defined in those
documents.This document uses the term "network model" as defined in .The meanings of the symbols in the tree diagrams are defined in .This document makes use of the following terms:
Layer 3 VPN Service Model (L3SM):
A YANG data model that describes the service requirements of an L3VPN that
interconnects a set of sites from the point of view of the customer.
The customer service model does not provide details on the service
provider network. The L3VPN customer service model is defined in
.
Layer 3 VPN Network Model (L3NM):
A YANG data model that describes a VPN service in the service provider network.
It contains information on the service provider network and might
include allocated resources. It can be used by network controllers
to manage and control the VPN service configuration in the service
provider network. The corresponding YANG module can be used by a service
orchestrator to request a VPN service to a network controller.
Service orchestrator:
A functional entity that
interacts with the customer of an L3VPN. The service orchestrator
interacts with the customer using the L3SM. The service orchestrator
is responsible for the Customer Edge to Provider Edge (CE-PE)
attachment circuits, the PE selection, and requesting the VPN
service to the network controller.
Network orchestrator:
A functional entity that is
hierarchically intermediate between a service orchestrator and
network controllers. A network orchestrator can manage one or
several network controllers.
Network controller:
A functional entity responsible
for the control and management of the service provider network.
VPN node:
An abstraction that represents a set of
policies applied 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 network controller will decide how to implement a VPN node. For
example, in a BGP-based VPN, a VPN node could typically be mapped
to a Virtual Routing and Forwarding (VRF) instance.
VPN network access:
An abstraction that represents the
network interfaces that are associated with a given VPN node. Traffic
coming from the VPN network access belongs to the VPN. The
attachment circuits (bearers) between CEs and PEs are terminated in
the VPN network access. A reference to the bearer is maintained to
allow keeping the link between the L3SM and L3NM when both models are
used in a given deployment.
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 VPN .
VPN service provider:
A service provider that offers
VPN-related services .
Service provider network:
A network that is able to
provide VPN-related services.
This document is aimed at modeling BGP PE-based VPNs in a service
provider network, so the terms defined in
and are used in this document as well.Acronyms and AbbreviationsThe following acronyms and abbreviations are used in this document:
ACL
Access Control List
AS
Autonomous System
ASM
Any-Source Multicast
ASN
AS Number
BFD
Bidirectional Forwarding Detection
BGP
Border Gateway Protocol
BSR
Bootstrap Router
CE
Customer Edge
CsC
Carriers' Carriers
IGMP
Internet Group Management Protocol
L3NM
L3VPN Network Model
L3SM
L3VPN Service Model
L3VPN
Layer 3 Virtual Private Network
MLD
Multicast Listener Discovery
MSDP
Multicast Source Discovery Protocol
MVPN
Multicast VPN
NAT
Network Address Translation
OAM
Operations, Administration, and Maintenance
OSPF
Open Shortest Path First
PE
Provider Edge
PIM
Protocol Independent Multicast
QoS
Quality of Service
RD
Route Distinguisher
RP
Rendezvous Point
RT
Route Target
SA
Security Association
SSM
Source-Specific Multicast
VPN
Virtual Private Network
VRF
Virtual Routing and Forwarding
L3NM Reference Architecture depicts the reference architecture
for the L3NM. The figure is an expansion of the architecture presented
in ; it decomposes the box
marked "orchestration" in that section into three separate functional
components: service orchestration, network orchestration, and domain
orchestration.Although some deployments may choose to construct a monolithic
orchestration component (covering both service and network matters),
this document advocates for a clear separation between service and
network orchestration components for the sake of better flexibility.
Such a design adheres to the L3VPN reference architecture defined in
. This separation relies
upon a dedicated communication interface between these components and
appropriate YANG modules that reflect network-related information. Such
information is hidden from customers.The intelligence for translating customer-facing information into
network-centric information (and vice versa) is implementation specific.The terminology from is used here to
show the distinction between the customer service model, the service
delivery model, the network configuration model, and the device
configuration model. In that context, the "domain orchestration" and
"config manager" roles may be performed by "controllers".The customer may use a variety of means to request a service that may
trigger the instantiation of an L3NM. The customer may use the L3SM or
more abstract models to request a service that relies upon an L3VPN
service. For example, the customer may supply an IP Connectivity
Provisioning Profile (CPP) that characterizes the requested service
, an enhanced VPN (VPN+) service , or an IETF network slice
service .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 . shows the
Customer Network Controller (CNC), the Multi-Domain Service Coordinator
(MDSC), the Provisioning Network Controller (PNC) components, and the
interfaces where the L3SM and L3NM are used.Relationship to Other YANG Data ModelsThe "ietf-vpn-common" module includes a set of
identities, types, and groupings that are meant to be reused by
VPN-related YANG modules independently of the layer (e.g., Layer 2,
Layer 3) and the type of the module (e.g., network model, service model),
including future revisions of existing models (e.g., or ). The L3NM
reuses these common types and groupings.In order to avoid data duplication and to ease passing data between
layers when required (service layer to network layer and vice versa),
early versions of the L3NM reused many of the data nodes that are
defined in . Nevertheless, that approach
was abandoned in favor of the "ietf-vpn-common" module because that
initial design was interpreted as if the deployment of the L3NM depends on the
L3SM, while this is not the case. For example, a service provider may
decide to use the L3NM to build its L3VPN services without exposing the
L3SM.As discussed in , the L3NM is meant to
manage L3VPN services within a service provider network. The module
provides a network view of the service. Such a view is only visible
within the service provider and is not exposed outside (to customers,
for example). The items below discuss how the L3NM interfaces with other YANG modules:
L3SM:
The L3NM is not a customer service model.The internal view of the service (i.e., the L3NM) may
be mapped to an external view that is visible to customers: the L3VPN
Service Model (L3SM) .
The L3NM can be fed with inputs that are
requested by customers. Such requests typically rely upon an L3SM template.
Concretely, some parts of the L3SM module can be directly mapped
to the L3NM, while other parts are generated as a function of the
requested service and local guidelines. Some other parts are local
to the service provider and do not map directly to the L3SM.Note that using the L3NM within a service provider does not
assume, nor does it preclude, exposing the VPN service via the L3SM.
This is deployment specific. Nevertheless, the design of the L3NM tries
to align as much as possible with the features supported by the L3SM
to ease the grafting of both the L3NM and 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 topology managed by the service provider network. The
topology can be represented using the network topology YANG module
defined in or its extension, such as a
network YANG module for Service Attachment Points (SAPs) .
Device Modules:
The L3NM is not a device model.Once a global VPN service is captured by means of the
L3NM, the actual activation and provisioning of the VPN service will
involve a variety of device modules to tweak the required functions
for the delivery of the service. These functions are supported by
the VPN nodes and can be managed using device YANG modules. A
non-comprehensive list of such device YANG modules is provided
below:
Routing management .
BGP .
PIM .
NAT management .
QoS management .
ACLs .
How the L3NM is used to derive
device-specific actions is implementation specific.
Sample Uses of the L3NM Data ModelThis section provides a non-exhaustive list of examples that illustrate
contexts where the L3NM can be used.Enterprise Layer 3 VPN ServicesEnterprise L3VPNs are one of the most demanded services for
carriers; therefore, L3NM can be useful for automating the
provisioning and maintenance of these VPNs. Templates and batch
processes can be built, and as a result many parameters are needed for
the creation from scratch of a VPN that can be abstracted to the upper
Software-Defined Networking (SDN) layer , but some manual intervention will
still be required.A common function that is supported by VPNs is the addition or
removal of VPN nodes. Workflows can use the L3NM in these scenarios to
add or prune nodes from the network data model as required.Multi-Domain Resource ManagementThe implementation of L3VPN services that span
administratively separated domains (i.e., that are under the
administration of different management systems or controllers)
requires some network resources to be synchronized between systems.
Particularly, resources must be adequately managed in each domain to
avoid broken configurations.For example, route targets (RTs) shall be synchronized between PEs.
When all PEs are controlled by the same management system, RT
allocation can be performed by that management system. In cases where
the service spans multiple management systems, the task of
allocating RTs has to be aligned across the domains; therefore, the
network model must provide a way to specify RTs. In addition, route
distinguishers (RDs) must also be synchronized to avoid collisions of
RD allocations between separate management systems. An incorrect
allocation might lead to the same RD and IP prefixes being exported by
different PEs.Management of Multicast ServicesMulticast services over L3VPNs can be implemented using dual PIM
MVPNs (also known as the draft-rosen model)
or MVPNs based on Multiprotocol BGP (MP-BGP) . Both
methods are supported and equally effective, but the main difference
is that MP-BGP-based MVPNs do not require multicast configuration on
the service provider network. MP-BGP MVPNs employ the intra-AS BGP control plane and PIM Sparse Mode as the data plane. The
PIM state information is maintained between PEs using the same
architecture that is used for unicast VPNs.On the other hand, has limitations,
such as reduced options for transport, control plane scalability,
availability, operational inconsistency, and the need to maintain
state in the backbone. Because of these limitations, MP-BGP MVPNs provide the
architectural model that has been taken as the base for implementing
multicast services in L3VPNs. In this scenario, BGP is used to
autodiscover MVPN PE members and the customer PIM signaling is sent
across the provider's core through MP-BGP. The multicast traffic is
transported on MPLS Point-to-Multipoint (P2MP) Label Switched Paths (LSPs).Description of the L3NM YANG ModuleThe L3NM ("ietf-l3vpn-ntw") is defined to manage L3VPNs in a service
provider network. In particular, the "ietf-l3vpn-ntw" module can be used
to create, modify, and retrieve L3VPN services of a network.The full tree diagram of the module can be generated using the
"pyang" tool . That tree is not included
here because it is too long (). Instead, subtrees are provided for the
reader's convenience.Overall Structure of the ModuleThe "ietf-l3vpn-ntw" module uses two main containers:
'vpn-profiles' and 'vpn-services' (see ).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
().The 'vpn-services' container maintains the set of VPN services
managed within the service provider network. The 'vpn-service' is the data
structure that abstracts a VPN service ().Some of the data nodes are keyed by the address family. For the
sake of data representation compactness, it is RECOMMENDED to use the
dual-stack address family for data nodes that have the same value for
both IPv4 and IPv6. If, for some reason, a data node is present for
both dual-stack and IPv4 (or IPv6), the value that is indicated under
dual-stack takes precedence over the value that is indicated under IPv4
(or IPv6).VPN ProfilesThe 'vpn-profiles' container () allows the VPN service provider to
define and maintain a set of VPN profiles that apply to one or
several VPN services.This document does not make any assumption about the exact
definition of these profiles. The exact definition of the profiles is
local to each VPN service provider. The model only includes an
identifier for these profiles in order to facilitate identifying and
binding local policies when building a VPN service. As shown in , the following identifiers can be
included:
'external-connectivity-identifier':
This identifier
refers to a profile that defines the external connectivity
provided to a VPN service (or a subset of VPN sites). External
connectivity may be access to the Internet or restricted
connectivity, such as access to a public/private cloud.
'encryption-profile-identifier':
An encryption
profile refers to a set of policies related to the encryption
schemes and setup that can be applied when building and offering a
VPN service.
'qos-profile-identifier':
A Quality of Service (QoS)
profile refers to a set of policies, such as classification,
marking, and actions (e.g., ).
'bfd-profile-identifier':
A Bidirectional Forwarding
Detection (BFD) profile refers to a set of BFD policies that can be invoked when
building a VPN service.
'forwarding-profile-identifier':
A forwarding
profile refers to the policies that apply to the forwarding of
packets conveyed within a VPN. Such policies may consist, for
example, of applying Access Control Lists (ACLs).
'routing-profile-identifier':
A routing profile
refers to a set of routing policies that will be invoked (e.g.,
BGP policies) when delivering the VPN service.
VPN ServicesThe 'vpn-service' is the data structure that abstracts a VPN
service in the service provider network. Each 'vpn-service' is
uniquely identified by an identifier: 'vpn-id'. Such a 'vpn-id' is only
meaningful locally (e.g., the network controller). The subtree of the
'vpn-services' is shown in .The descriptions of the VPN service data nodes that are depicted in
are as follows:
'vpn-id':
An identifier that is used to uniquely
identify the L3VPN service within the L3NM scope.
'vpn-name':
Associates a name with the service in
order to facilitate the identification of the service.
'vpn-description':
Includes a textual description of
the service. The internal structure of a
VPN description is local to each VPN service provider.
'customer-name':
Indicates the name of the customer
who ordered the service.
'parent-service-id':
Refers to an identifier of the
parent service (e.g., L3SM, IETF network slice, VPN+) that
triggered the creation of the VPN service. This identifier is used
to easily correlate the (network) service as built in the network
with a service order. A controller can use that correlation to
enrich or populate some fields (e.g., description fields) as a
function of local deployments.
'vpn-type':
Indicates the VPN type. The values are
taken from . For
the L3NM, this is typically set to "BGP/MPLS L3VPN", but other
values may be defined to support specific Layer 3
VPN capabilities (e.g., ).
'vpn-service-topology':
Indicates the network
topology for the service: 'hub-spoke', 'any-to-any', or 'custom'. The
network implementation of this attribute is defined by the correct
usage of import and export targets ().
'status':
Used to track the service status of a
given VPN service. Both operational status and administrative status are
maintained together with a timestamp. For example, a service can
be created but not put into effect.Administrative status and operational status can be used
as a trigger to detect service anomalies. For example, a service
that is declared active at the service layer but is still
inactive at the network layer may be an indication that network
provision actions are needed to align the observed service status
with the expected service status.
'vpn-instance-profiles':
Defines reusable parameters
for the same 'vpn-service'. More details
are provided in .
'underlay-transport':
Describes the preference for
the transport technology to carry the traffic of the VPN service.
This preference is especially useful in networks with multiple
domains and Network-to-Network Interface (NNI) types. The underlay
transport can be expressed as an abstract transport instance
(e.g., an identifier of a VPN+ instance, a virtual network
identifier, or a network slice name) or as an ordered list of the
actual protocols to be enabled in the network. A rich set of protocol identifiers that can be
used to refer to an underlay transport are defined in .
'external-connectivity':
Indicates whether/how
external connectivity is provided to the VPN service. For example,
a service provider may provide external connectivity to a VPN
customer (e.g., to a public cloud). Such a service may involve
tweaking both filtering and NAT rules (e.g., binding a Virtual
Routing and Forwarding (VRF) interface with a NAT instance as
discussed in ).
These value-added features may be bound to all, or a subset of,
network accesses. Some of these value-added features 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). Only a pointer to a local profile that defines
the external-connectivity feature is supported in this
document.
'vpn-node':
An abstraction that represents a set
of policies applied to a network node and belonging to a single
'vpn-service'. A VPN service is typically built by adding
instances of 'vpn-node' to the 'vpn-nodes' container. A 'vpn-node' contains 'vpn-network-accesses',
which are the interfaces attached to the VPN by which the customer
traffic is received. Therefore, the customer sites are connected
to the 'vpn-network-accesses'.Note that
because this is a network data model, information about customers'
sites is not required in the model. Rather, such information is
relevant in the L3SM. Whether that information is included in the
L3NM, e.g., to populate the various 'description' data nodes, is
implementation specific. More details are
provided in .
VPN Instance ProfilesVPN instance profiles are meant to factorize data nodes that are
used 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
VPN network access levels. Each VPN instance profile is identified by
'profile-id'. This identifier is then referenced for one or multiple
VPN nodes () so that the controller can
identify generic resources (e.g., RTs and RDs) to be configured for a
given VRF instance.The subtree of the 'vpn-instance-profiles' is shown in .The descriptions of the listed data nodes are as follows:
'profile-id':
Used to uniquely identify a VPN
instance profile.
'role':
Indicates the role of the VPN instance
profile in the VPN. Role values are defined in (e.g.,
'any-to-any-role', 'spoke-role', 'hub-role').
'local-as':
Indicates the Autonomous System Number
(ASN) that is configured for the VPN node.
'rd':
As defined in , the following RD
assignment modes are supported: direct assignment, full automatic
assignment, automatic assignment from a given pool, and no
assignment. For illustration purposes, the following modes can be
used in the deployment cases:
'directly-assigned':
The VPN service provider
(service orchestrator) assigns RDs explicitly. This case will
fit with a brownfield scenario where some existing services
need to be updated by the VPN service provider.
'full-auto':
The network controller auto-assigns
RDs. This can apply for the deployment of new services.
'no-rd':
The VPN service provider (service
orchestrator) explicitly wants no RD to be assigned. This case
can be used for CE testing within the network or for
troubleshooting proposes.
Also, the module accommodates deployments where only the
Assigned Number subfield of RDs () is assigned from a pool while the
Administrator subfield is set to, for example, the Router ID that is
assigned to a VPN node. The module supports these modes for
managing the Assigned Number subfield: explicit assignment,
auto-assignment from a pool, and full auto-assignment.
'address-family':
Includes a set of data nodes per address family:
'address-family':
Identifies the address family.
It can be set to 'ipv4', 'ipv6', or 'dual-stack'.
'vpn-targets':
Specifies RT import/export rules
for the VPN service ().
'maximum-routes':
Indicates the maximum number
of prefixes that the VPN node can accept for a given routing
protocol. If 'protocol' is set to 'any', this means that the
maximum value applies to each active routing protocol.
'multicast':
Enables multicast traffic in the VPN
service. Refer to .
VPN NodesThe 'vpn-node' is an abstraction that represents a set of common
policies applied on a given network node (typically, a PE) and belonging
to one L3VPN service. The 'vpn-node' includes a parameter to indicate
the network node on which it is applied. In the case that the 'ne-id'
points to a specific PE, the 'vpn-node' will likely be mapped to a
VRF instance in the node. However, the model also allows pointing to an
abstract node. In this case, the network controller will decide how to
split the 'vpn-node' into VRF instances.The VPN node subtree structure is shown in .The descriptions of the 'vpn-node' data nodes () are as follows:
'vpn-node-id':
An identifier that uniquely
identifies a node that enables a VPN network access.
'description':
Provides a textual description of the
VPN node.
'ne-id':
Includes a unique identifier of the network
element where the VPN node is deployed.
'local-as':
Indicates the ASN that is
configured for the VPN node.
'router-id':
Indicates a 32-bit number that is used
to uniquely identify a router within an AS.
'active-vpn-instance-profiles':
Lists the set of
active VPN instance profiles for this VPN node. Concretely, one or
more VPN instance profiles that are defined at the VPN service
level can be enabled at the VPN node level; each of these profiles
is uniquely identified by means of 'profile-id'. The structure of
'active-vpn-instance-profiles' is the same as the structure discussed in
, except that the structure of
'active-vpn-instance-profiles' includes 'router-id' but does not include the 'role' leaf. The value
of 'router-id' indicated under 'active-vpn-instance-profiles'
takes precedence over the 'router-id' under the 'vpn-node' for the
indicated address family. For example, Router IDs can be
configured per address family. This capability can be used, for
example, to configure an IPv6 address as a Router ID when such a
capability is supported by involved routers. Values defined in 'active-vpn-instance-profiles'
override the values defined at the VPN service level. An example is
shown in .
'msdp':
For redundancy purposes, the Multicast Source
Discovery Protocol (MSDP) may be
enabled and used to share state information about sources between multiple
Rendezvous Points (RPs). The purpose of MSDP in this context is to
enhance the robustness of the multicast service. MSDP may be
configured on non-RP routers; this is useful in a domain that
does not support multicast sources but does support multicast
transit.
'groups':
Lists the groups to which a VPN node
belongs . For example, the
'group-id' is used to associate redundancy or protection
constraints with VPN nodes.
'status':
Tracks the status of a node involved in a
VPN service. Both operational status and administrative status are
maintained. A mismatch between the administrative status vs. the
operational status can be used as a trigger to detect
anomalies.
'vpn-network-accesses':
Represents the point to
which sites are connected. Note that
unlike the L3SM, the L3NM does not need to model the customer
site -- only the points that receive traffic from the site
(i.e., the PE side of Provider Edge to Customer Edge (PE-CE) connections). Hence, the VPN network
access contains the connectivity information between the
provider's network and the customer premises. The VPN profiles
('vpn-profiles') have a set of routing policies that can be
applied during the service creation. See
for more details.
VPN Network AccessesThe 'vpn-network-access' includes a set of data nodes that describe
the access information for the traffic that belongs to a particular
L3VPN ().A 'vpn-network-access' () includes the following data nodes:
'id':
An identifier of the VPN network
access.
'interface-id':
Indicates the physical or logical
interface on which the VPN network access is bound.
'description':
Includes a textual description of the
VPN network access.
'vpn-network-access-type':
Used to select the
type of network interface to be deployed in the devices. The
available defined values are as follows:
'point-to-point':
Represents a direct connection
between the endpoints. The controller must keep the
association between a logical or physical interface on the
device with the 'id' of the 'vpn-network-access'.
'multipoint':
Represents a multipoint connection
between the customer site and the PEs. The controller must
keep the association between a logical or physical interface
on the device with the 'id' of the 'vpn-network-access'.
'irb':
Represents a connection coming from an
L2VPN service. An identifier of such a service ('l2vpn-id') may
be included in the 'connection' container, as depicted in (). The controller must keep
the relationship between the logical tunnels or bridges on the
devices with the 'id' of the 'vpn-network-access'.
'loopback':
Represents the creation of a logical
interface on a device. An example that illustrates how a loopback
interface can be used in the L3NM is provided in .
'vpn-instance-profile':
Provides a pointer to an
active VPN instance profile at the VPN node level. Referencing an
active VPN instance profile implies that all associated data nodes
will be inherited by the VPN network access. However, some
inherited data nodes (e.g., multicast) can be overridden at the
VPN network access level. In such a case, adjusted values take
precedence over inherited values.
'status':
Indicates both operational status and
administrative status of a VPN network access.
'connection':
Represents and groups the set of Layer
2 connectivity from where the traffic of the L3VPN in a particular
VPN network access is coming. See .
'ip-connection':
Contains Layer 3 connectivity
information on a VPN network access (e.g., IP addressing). See
.
'routing-protocols':
Includes the CE-PE routing
configuration information. See .
'oam':
Specifies the Operations, Administration, and
Maintenance (OAM) mechanisms used for a VPN network access. See
.
'security':
Specifies the authentication and the
encryption to be applied for a given VPN network access. See .
'service':
Specifies the service parameters (e.g.,
QoS, multicast) to apply for a given VPN network access. See .
ConnectionThe 'connection' container represents the Layer 2 connectivity to
the L3VPN for a particular VPN network access. As shown in the tree
depicted in , the
'connection' container defines protocols and parameters to enable
such connectivity at Layer 2.The traffic can enter the VPN with or without encapsulation
(e.g., VLAN, QinQ). The 'encapsulation' container specifies the
Layer 2 encapsulation to use (if any) and allows the configuration of the
relevant tags.The interface that is attached to the L3VPN is identified by the
'interface-id' at the 'vpn-network-access' level. From a network
model perspective, it is expected that the 'interface-id' is
sufficient to identify the interface. However, specific Layer 2
sub-interfaces may be required to be configured in some
implementations/deployments. Such a Layer-2-specific interface can
be included in 'l2-termination-point'.If a Layer 2 tunnel is needed to terminate the service in the
CE-PE connection, the 'l2-tunnel-service' container is used to
specify the required parameters to set such a tunneling service (e.g.,
a Virtual 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 ().As discussed in , 'l2vpn-id' is used to
identify the L2VPN service that is associated with an Integrated Routing and Bridging (IRB)
interface.To accommodate implementations that require internal bridging, a
local bridge reference can be specified in 'local-bridge-reference'.
Such a reference may be a local bridge domain.A site, as per , represents a VPN
customer's location that is connected to the service provider
network via a CE-PE link, which can access at least one VPN. The
connection from the site to the service provider network is the
bearer. Every site is associated with a list of bearers. A bearer is
the Layer 2 connection with the site. In the L3NM, it is assumed
that the bearer has been allocated by the service provider at the
service orchestration stage. The bearer is associated with a network
element and a port. Hence, a bearer is just a 'bearer-reference' to
allow the association between a service request (e.g., the L3SM) and
the L3NM.The L3NM can be used to create a Link Aggregation Group (LAG) interface for a given L3VPN
service ('lag-interface') . Such a
LAG interface can be referenced under 'interface-id' ().IP ConnectionThis container is used to group Layer 3 connectivity information,
particularly the IP addressing information, of a VPN network access.
The allocated address represents the PE interface address
configuration. Note that a distinct Layer 3 interface other than the
interface indicated under the 'connection' container may be needed to
terminate the Layer 3 service. The identifier of such an interface is
included in 'l3-termination-point'. For example, this data node can
be used to carry the identifier of a bridge domain interface.As shown in , the
'ip-connection' container can include IPv4, IPv6, or both if
dual-stack is enabled.For both IPv4 and IPv6, the IP connection supports three IP
address assignment modes for customer addresses: provider DHCP, DHCP
relay, and static addressing. Note that for the IPv6 case, Stateless Address Autoconfiguration (SLAAC)
can be used. For both IPv4 and IPv6,
'address-allocation-type' is used to indicate the IP address
allocation mode to activate for a given VPN network access.When 'address-allocation-type' is set to 'provider-dhcp', DHCP
assignments can be made locally or by an external DHCP server. Such
behavior is controlled by setting 'dhcp-service-type'. shows the structure of the
dynamic IPv4 address assignment (i.e., by means of DHCP). shows the structure of the
dynamic IPv6 address assignment (i.e., DHCPv6 and/or SLAAC). Note
that if 'address-allocation-type' is set to 'slaac', the Prefix
Information option of Router Advertisements that will be issued for
SLAAC purposes will carry the IPv6 prefix that is determined by
'local-address' and 'prefix-length'. For example, if 'local-address'
is set to '2001:db8:0:1::1' and 'prefix-length' is set to '64', the
IPv6 prefix that will be used is '2001:db8:0:1::/64'.In the case of static addressing (), the model supports the
assignment of several IP addresses in the same 'vpn-network-access'.
To identify which of the addresses is the primary address of a
connection, the 'primary-address' reference MUST be set with the
corresponding 'address-id'.CE-PE Routing ProtocolsA VPN service provider can configure one or more routing
protocols associated with a particular 'vpn-network-access'. Such
routing protocols are enabled between the PE and the CE. Each
instance is uniquely identified to accommodate scenarios where
multiple instances of the same routing protocol have to be
configured on the same link.The subtree of the 'routing-protocols' is shown in .Multiple routing instances can be defined, each uniquely
identified by an 'id'. The type of routing instance is indicated in
'type'. The values of these attributes are those defined in (the 'routing-protocol-type'
identity).Configuring multiple instances of the same routing protocol does
not automatically imply that, from a device configuration
perspective, there will be parallel instances (e.g., multiple
processes) running on the PE-CE link. It is up to each
implementation (typically, network orchestration, as shown in ) to decide on the appropriate
configuration as a function of underlying capabilities and service
provider operational guidelines. As an example, when multiple BGP
peers need to be implemented, multiple instances of BGP must be
configured as part of this model. However, from a device
configuration point of view, this could be implemented as:
Multiple BGP processes with a single neighbor running in each
process.
A single BGP process with multiple neighbors running.
A combination thereof.
Routing configuration does not include low-level policies. Such
policies are handled at the device configuration level. Local
policies of a service provider (e.g., filtering) are implemented as
part of the device configuration; these are not captured in the
L3NM, but the model allows local profiles to be associated with
routing instances ('routing-profiles'). Note that these routing
profiles can be scoped to capture parameters that are globally
applied to all L3VPN services within a service provider network,
while customized L3VPN parameters are captured by means of the L3NM.
The provisioning of an L3VPN service will thus rely upon the
instantiation of these global routing profiles and the customized
L3NM.Static RoutingThe L3NM supports the configuration of one or more IPv4/IPv6
static routes. Since the same structure is used for both IPv4 and
IPv6, using one single container to group both
static entries independently of their address family was considered at one time, but that
design was abandoned to ease the mapping, using the structure provided in
.The static routing subtree structure is shown in .As depicted in , the
following data nodes can be defined for a given IP prefix:
'lan-tag':
Indicates a local tag (e.g.,
"myfavorite-lan") that is used to enforce local policies.
'next-hop':
Indicates the next hop to be used
for the static route. It can be identified by an IP address,
a predefined next-hop type (e.g., 'discard' or 'local-link'), etc.
'bfd-enable':
Indicates whether BFD is enabled
or disabled for this static route entry.
'metric':
Indicates the metric associated with
the static route entry. This metric is used when the route is exported
into an IGP.
'preference':
Indicates the preference
associated with the static route entry. This preference is
used to select a preferred route among routes to the same
destination prefix.
'status':
Used to convey the status of a static
route entry. This data node can also be used to control the
(de)activation of individual static route entries.
BGPThe L3NM allows the configuration of a BGP neighbor, including
a set of parameters that are pertinent to be tweaked at the
network level for service customization purposes. The 'bgp' container does not aim to include every
BGP parameter; a comprehensive set of parameters belongs more to
the BGP device model.The BGP routing subtree structure is shown in .The following data nodes are captured in . It is up to the implementation
(e.g., network orchestrator) to derive the corresponding BGP
device configuration:
'description':
Includes a description of the BGP
session.
'local-as':
Indicates a local AS Number (ASN), if
a distinct ASN is required other than the ASN configured at
the VPN node level.
'peer-as':
Conveys the customer's ASN.
'address-family':
Indicates the address family
of the peer. It can be set to 'ipv4', 'ipv6', or 'dual-stack'.
This address family will be used
together with the 'vpn-type' to derive the appropriate Address
Family Identifiers (AFIs) / Subsequent Address Family
Identifiers (SAFIs) that will be part of the derived device
configurations (e.g., unicast IPv4 MPLS L3VPN (AFI,SAFI =
1,128) as defined in ).
'local-address':
Specifies an address or a
reference to an interface to use when establishing the BGP
transport session.
'neighbor':
Can indicate two neighbors (each for
a given address family) or one neighbor (if the 'address-family'
attribute is set to 'dual-stack'). A list of IP address(es) of
the BGP neighbor(s) can then be conveyed in this data node.
'multihop':
Indicates the number of allowed IP
hops between a PE and its BGP peer.
'as-override':
If set, this parameter indicates
whether ASN override is enabled, i.e., replacing the ASN of the
customer specified in the AS_PATH BGP attribute with the ASN
identified in the 'local-as' attribute.
'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 attribute received from a CE.
Loops are prevented by setting 'allow-own-as' to a maximum
number of the provider's ASN occurrences. By default, this parameter is set to '0' (that is, reject any AS_PATH attribute that
includes the provider's ASN).
'prepend-global-as':
When distinct ASNs are
configured at the VPN node and network access levels, this
parameter controls whether the ASN provided at the VPN node
level is prepended to the AS_PATH attribute.
'send-default-route':
Controls whether default
routes can be advertised to the peer.
'site-of-origin':
Meant to uniquely identify
the set of routes learned from a site via a particular CE-PE
connection. It is used to prevent routing loops (). The Site of Origin attribute
is encoded as a Route Origin Extended Community.
'ipv6-site-of-origin':
Carries an IPv6 Address
Specific BGP Extended Community that is used to indicate the
Site of Origin for VRF information . It is used to prevent routing
loops.
'redistribute-connected':
Controls whether the
PE-CE link is advertised to other PEs.
'bgp-max-prefix':
Controls the behavior when a
prefix maximum is reached.
'max-prefix':
Indicates the maximum number
of BGP prefixes allowed in the BGP session. If the limit
is reached, the action indicated in 'violate-action' will
be followed.
'warning-threshold':
A warning notification
is triggered when this limit is reached.
'violate-action':
Indicates which action to
execute when the maximum number of BGP prefixes is
reached. Examples of such actions include sending a warning
message, discarding extra paths from the peer, or restarting the
session.
'restart-timer':
Indicates, in seconds, the
time interval after which the BGP session will be
reestablished.
'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 Timer () when establishing a BGP session and (2)
'keepalive', which is the time interval for the KeepaliveTimer
between a PE and a BGP peer (). Both timers are expressed in seconds.
'authentication':
The module adheres to the
recommendations in , as it allows enabling the TCP Authentication Option (TCP-AO) and accommodates the installed base
that makes use of MD5. In addition, the module includes a
provision for using IPsec.This
version of the L3NM assumes that parameters specific to the TCP-AO are preconfigured as part of the key chain that is referenced
in the L3NM. No assumption is made about how such a key chain
is preconfigured. However, the structure of the key chain
should cover data nodes beyond those in , mainly SendID and RecvID ().
'status':
Indicates the status of the BGP
routing instance.
OSPFOSPF can be configured to run as a routing protocol on the
'vpn-network-access'.The OSPF routing subtree structure is shown in .The following data nodes are captured in :
'address-family':
Indicates whether IPv4, IPv6,
or both address families are to be activated. When the IPv4 or dual-stack address family is
requested, it is up to the implementation (e.g., network
orchestrator) to decide whether OSPFv2 or OSPFv3 is used to announce IPv4 routes. Such a
decision will typically be reflected in the device
configurations that will be derived to implement the
L3VPN.
'area-id':
Indicates the OSPF Area ID.
'metric':
Associates a metric with OSPF
routes.
'sham-links':
Used to create OSPF sham links
between two VPN network accesses sharing the same area and
having a backdoor link ( and ).
'max-lsa':
Sets the maximum number of Link State Advertisements (LSAs) that
the OSPF instance will accept.
'authentication':
Controls the authentication
schemes to be enabled for the OSPF instance. The following
options are supported: IPsec for OSPFv3 authentication , and the Authentication Trailer for OSPFv2
and OSPFv3 .
'status':
Indicates the status of the OSPF
routing instance.
IS-ISThe model allows the user
to configure IS-IS to run on
the 'vpn-network-access' interface. See .The following IS-IS data nodes are supported:
'address-family':
Indicates whether IPv4, IPv6,
or both address families are to be activated.
'area-address':
Indicates the IS-IS area
address.
'level':
Indicates the IS-IS level: Level 1,
Level 2, or both.
'metric':
Associates a metric with IS-IS
routes.
'mode':
Indicates the IS-IS interface mode type.
It can be set to 'active' (that is, send or receive IS-IS
protocol control packets) or 'passive' (that is, suppress the
sending of IS-IS updates through the interface).
'authentication':
Controls the authentication
schemes to be enabled for the IS-IS instance. Both the
specification of a key chain
and the direct specification of key and authentication
algorithms are supported.
'status':
Indicates the status of the IS-IS
routing instance.
RIPThe model allows the user to
configure RIP to run on the 'vpn-network-access' interface. See
.As shown in , the following RIP data
nodes are supported:
'address-family':
Indicates whether IPv4, IPv6,
or both address families are to be activated. This parameter
is used to determine whether RIPv2 , RIP Next Generation (RIPng), or both are to be enabled .
'timers':
Indicates the following timers:
'update-interval':
The interval at which
RIP updates are sent.
'invalid-interval':
The interval before a
RIP route is declared invalid.
'holddown-interval':
The interval before
better RIP routes are released.
'flush-interval':
The interval before a
route is removed from the routing table.
These timers are expressed in seconds.
'default-metric':
Sets the default RIP
metric.
'authentication':
Controls the authentication
schemes to be enabled for the RIP instance.
'status':
Indicates the status of the RIP
routing instance.
VRRPThe model allows enabling the Virtual Router Redundancy Protocol (VRRP) on
the 'vpn-network-access' interface. See .The following data nodes are supported:
'address-family':
Indicates whether IPv4, IPv6,
or both address families are to be activated. Note that VRRP
version 3 supports both IPv4
and IPv6.
'vrrp-group':
Used to identify the VRRP
group.
'backup-peer':
Carries the IP address of the
peer.
'virtual-ip-address':
Includes virtual IP
addresses for a single VRRP group.
'priority':
Assigns the VRRP election priority
for the backup virtual router.
'ping-reply':
Controls whether the VRRP speaker should
reply to ping requests.
'status':
Indicates the status of the VRRP
instance.
Note that no authentication data node is included for
VRRP, as there isn't any type of VRRP authentication at this time (see
).OAMThis container () defines the
Operations, Administration, and Maintenance (OAM) mechanisms used
for a VPN network access. In the current version of the L3NM, only
BFD is supported.The following OAM data nodes can be specified:
'session-type':
Indicates which BFD flavor is used
to set up the session (e.g., classic BFD , Seamless BFD ). By default, it is assumed that the BFD session will
follow the behavior specified in .
'desired-min-tx-interval':
The minimum
interval, in microseconds, that a PE would like to use when
transmitting BFD Control packets, less any jitter applied.
'required-min-rx-interval':
The minimum
interval, in microseconds, between received BFD Control packets
that a PE is capable of supporting, less any jitter applied by
the sender.
'local-multiplier':
The negotiated transmit
interval, multiplied by this value, provides the detection time
for the peer.
'holdtime':
Used to indicate the expected BFD
holddown time, in milliseconds. This value may be inherited from
the service request (see ).
'profile':
Refers to a BFD profile (). Such a profile can be set by the
provider or inherited from the service request (see ).
'authentication':
Includes the required
information to enable the BFD authentication modes discussed in
. In particular,
'meticulous' controls the activation of meticulous mode as
discussed in Sections and of .
'status':
Indicates the status of BFD.
SecurityThe 'security' container specifies the authentication and the
encryption to be applied to traffic for a given VPN network access. As
depicted in the subtree shown in ,
the L3NM can be used to directly control the encryption to be
applied (e.g., Layer 2 or Layer 3 encryption) or invoke a local
encryption profile.ServicesOverviewThe 'service' container specifies the service parameters to
apply for a given VPN network access ().The following data nodes are defined:
'pe-to-ce-bandwidth':
Indicates, in bits per
second (bps), the inbound bandwidth of the connection (i.e., the
download bandwidth from the service provider to the site).
'ce-to-pe-bandwidth':
Indicates, in bps, the
outbound bandwidth of the connection (i.e., the upload bandwidth
from the site to the service provider).
'mtu':
Indicates the MTU at the service
level.
'qos':
Used to define a set of QoS policies
to apply on a given connection (refer to for more details).
'carriers-carrier':
Groups a set of parameters
that are used when Carriers' Carriers (CsC) is enabled, such as
using BGP for signaling purposes .
'ntp':
Time synchronization may be needed in
some VPNs, such as infrastructure and management VPNs. This
container is used to enable the NTP service .
'multicast':
Specifies the multicast mode and
other data nodes, such as the address family. Refer to .
QoSThe 'qos' container is used to define a set of QoS policies to
apply on a given connection (). A
QoS policy may be a classification or an action policy. For
example, a QoS action can be defined to rate-limit
inbound/outbound traffic of a given class of service. QoS classification can be based on many criteria, such as the following:
Layer 3:
As shown in , classification can be based on
any IP header field or a combination thereof. Both IPv4 and
IPv6 are supported.
Layer 4:
As discussed in , any Layer 4
protocol can be indicated in the 'protocol' data node under
'l3' (), but only TCP- and
UDP-specific match criteria are elaborated in this version, as
these protocols are widely used in the context of VPN
services. Augmentations can be considered in the future to add
other Layer-4-specific data nodes, if needed.TCP- or UDP-related match criteria can be
specified in the L3NM, as shown in . As
discussed in , some transport
protocols use existing protocols (e.g., TCP or UDP) as the
substrate. The match criteria for such protocols may rely upon
the 'protocol' setting under 'l3', TCP/UDP match criteria as shown in
, part of the TCP/UDP
payload, or a combination thereof. This version of the module
does not support such advanced match criteria. Future
revisions of the VPN common module or augmentations to the
L3NM may consider adding match criteria based on the transport
protocol payload (e.g., by means of a bitmask match).
Application match:
Relies upon
application-specific classification ().
MulticastMulticast may be enabled for a particular VPN at the VPN node and
VPN network access levels (see ).
Some data nodes (e.g., max-groups ()) can be controlled at various
levels: VPN service, VPN node level, or VPN network access.Multicast-related data nodes at the VPN instance profile level have
the structure shown in .
The model supports a single type of tree per VPN access
('tree-flavor'): Any-Source Multicast (ASM), Source-Specific Multicast
(SSM), or bidirectional.When ASM is used, the model supports the configuration of
Rendezvous Points (RPs). RP discovery may be 'static', 'bsr-rp', or
'auto-rp'. When set to 'static', RP-to-multicast-group mappings
MUST be configured as part of the 'rp-group-mappings' container. The
RP MAY be a provider node or a customer node. When the RP is a
customer node, the RP address must be configured using the
'rp-address' leaf.The model supports RP redundancy through the 'rp-redundancy' leaf.
How the redundancy is achieved is out of scope.When a particular VPN using ASM requires traffic
delivery that is more optimal (e.g., requested per the guidance in ),
'optimal-traffic-delivery' can be set. When set to 'true', the
implementation must use any mechanism to provide
traffic delivery that is more optimal for the customer. For example, anycast is one of the
mechanisms for enhancing RP redundancy, providing resilience against failures, and
recovering from failures quickly.
When configuring multicast-related parameters at the VPN node level
(), the same structure as the structure depicted in
is used. When defined at the VPN node level, Internet Group Management Protocol (IGMP) parameters , Multicast
Listener Discovery (MLD) parameters , and Protocol Independent Multicast (PIM) parameters are applicable to all VPN
network accesses of that VPN node unless corresponding nodes are
overridden at the VPN network access level.Multicast-related data nodes at the VPN network access level are
shown in . The values configured
at the VPN network access level override the values configured for the
corresponding data nodes at other levels.L3NM YANG ModuleThis module uses types defined in ,
, and . It also uses groupings defined in , , and .
module ietf-l3vpn-ntw {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-l3vpn-ntw";
prefix l3nm;
import ietf-vpn-common {
prefix vpn-common;
reference
"RFC 9181: A Common YANG Data Model for Layer 2 and Layer 3
VPNs";
}
import ietf-inet-types {
prefix inet;
reference
"RFC 6991: Common YANG Data Types, Section 4";
}
import ietf-yang-types {
prefix yang;
reference
"RFC 6991: Common YANG Data Types, Section 3";
}
import ietf-key-chain {
prefix key-chain;
reference
"RFC 8177: YANG Data Model for Key Chains";
}
import ietf-routing-types {
prefix rt-types;
reference
"RFC 8294: Common YANG Data Types for the Routing Area";
}
import ietf-interfaces {
prefix if;
reference
"RFC 8343: A YANG Data Model for Interface Management";
}
organization
"IETF OPSAWG (Operations and Management Area Working Group)";
contact
"WG Web: <https://datatracker.ietf.org/wg/opsawg/>
WG List: <mailto:opsawg@ietf.org>
Author: Samier Barguil
<mailto:samier.barguilgiraldo.ext@telefonica.com>
Editor: Oscar Gonzalez de Dios
<mailto:oscar.gonzalezdedios@telefonica.com>
Editor: Mohamed Boucadair
<mailto:mohamed.boucadair@orange.com>
Author: Luis Angel Munoz
<mailto:luis-angel.munoz@vodafone.com>
Author: Alejandro Aguado
<mailto:alejandro.aguado_martin@nokia.com>";
description
"This YANG module defines a generic network-oriented model
for the configuration of Layer 3 Virtual Private Networks.
Copyright (c) 2022 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject
to the license terms contained in, the Revised BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC 9182; see the
RFC itself for full legal notices.";
revision 2022-02-14 {
description
"Initial revision.";
reference
"RFC 9182: A YANG Network Data Model for Layer 3 VPNs";
}
/* Features */
feature msdp {
description
"This feature indicates that Multicast Source Discovery
Protocol (MSDP) capabilities are supported by the VPN.";
reference
"RFC 3618: Multicast Source Discovery Protocol (MSDP)";
}
/* Identities */
identity address-allocation-type {
description
"Base identity for address allocation type in the
Provider Edge to Customer Edge (PE-CE) link.";
}
identity provider-dhcp {
base address-allocation-type;
description
"The provider's network provides a DHCP service to the
customer.";
}
identity provider-dhcp-relay {
base address-allocation-type;
description
"The provider's network provides a DHCP relay service to the
customer.";
}
identity provider-dhcp-slaac {
if-feature "vpn-common:ipv6";
base address-allocation-type;
description
"The provider's network provides a DHCP service to the
customer as well as IPv6 Stateless Address
Autoconfiguration (SLAAC).";
reference
"RFC 4862: IPv6 Stateless Address Autoconfiguration";
}
identity static-address {
base address-allocation-type;
description
"The provider's network provides static IP addressing to the
customer.";
}
identity slaac {
if-feature "vpn-common:ipv6";
base address-allocation-type;
description
"The provider's network uses IPv6 SLAAC to provide
addressing to the customer.";
reference
"RFC 4862: IPv6 Stateless Address Autoconfiguration";
}
identity local-defined-next-hop {
description
"Base identity of local defined next hops.";
}
identity discard {
base local-defined-next-hop;
description
"Indicates an action to discard traffic for the
corresponding destination.
For example, this can be used to black-hole traffic.";
}
identity local-link {
base local-defined-next-hop;
description
"Treat traffic towards addresses within the specified
next-hop prefix as though they are connected to a local
link.";
}
identity l2-tunnel-type {
description
"Base identity for Layer 2 tunnel selection under the VPN
network access.";
}
identity pseudowire {
base l2-tunnel-type;
description
"Pseudowire tunnel termination in the VPN network access.";
}
identity vpls {
base l2-tunnel-type;
description
"Virtual Private LAN Service (VPLS) tunnel termination in
the VPN network access.";
}
identity vxlan {
base l2-tunnel-type;
description
"Virtual eXtensible Local Area Network (VXLAN) tunnel
termination in the VPN network access.";
}
/* Typedefs */
typedef predefined-next-hop {
type identityref {
base local-defined-next-hop;
}
description
"Predefined next-hop designation for locally generated
routes.";
}
typedef area-address {
type string {
pattern '[0-9A-Fa-f]{2}(\.[0-9A-Fa-f]{4}){0,6}';
}
description
"This type defines the area address format.";
}
/* Groupings */
grouping vpn-instance-profile {
description
"Grouping for data nodes that may be factorized
among many levels of the model. The grouping can
be used to define generic profiles at the VPN service
level and then referenced at the VPN node and VPN
network access levels.";
leaf local-as {
if-feature "vpn-common:rtg-bgp";
type inet:as-number;
description
"Provider's Autonomous System (AS) number. Used if the
customer requests BGP routing.";
}
uses vpn-common:route-distinguisher;
list address-family {
key "address-family";
description
"Set of parameters per address family.";
leaf address-family {
type identityref {
base vpn-common:address-family;
}
description
"Indicates the address family (IPv4 and/or IPv6).";
}
container vpn-targets {
description
"Set of route targets to match for import and export
routes to/from VRF.";
uses vpn-common:vpn-route-targets;
}
list maximum-routes {
key "protocol";
description
"Defines the maximum number of routes for VRF.";
leaf protocol {
type identityref {
base vpn-common:routing-protocol-type;
}
description
"Indicates the routing protocol. A value of 'any'
can be used to identify a limit that will apply for
each active routing protocol.";
}
leaf maximum-routes {
type uint32;
description
"Indicates the maximum number of prefixes that VRF can
accept for this address family and protocol.";
}
}
}
container multicast {
if-feature "vpn-common:multicast";
description
"Global multicast parameters.";
leaf tree-flavor {
type identityref {
base vpn-common:multicast-tree-type;
}
description
"Type of the multicast tree to be used.";
}
container rp {
description
"Rendezvous Point (RP) parameters.";
container rp-group-mappings {
description
"RP-to-group mapping parameters.";
list rp-group-mapping {
key "id";
description
"List of RP-to-group mappings.";
leaf id {
type uint16;
description
"Unique identifier for the mapping.";
}
container provider-managed {
description
"Parameters for a provider-managed RP.";
leaf enabled {
type boolean;
default "false";
description
"Set to 'true' if the RP must be a
provider-managed node. Set to 'false' if it is
a customer-managed node.";
}
leaf rp-redundancy {
type boolean;
default "false";
description
"If set to 'true', it indicates that a
redundancy mechanism for the RP is required.";
}
leaf optimal-traffic-delivery {
type boolean;
default "false";
description
"If set to 'true', the service provider (SP)
must ensure that the traffic uses an optimal
path. An SP may use Anycast RP or
RP-tree-to-SPT ('SPT' is 'shortest path tree')
switchover architectures.";
}
container anycast {
when "../rp-redundancy = 'true' and
../optimal-traffic-delivery = 'true'" {
description
"Only applicable if both RP redundancy and
delivery through an optimal path are
activated.";
}
description
"PIM Anycast-RP parameters.";
leaf local-address {
type inet:ip-address;
description
"IP local address for the PIM RP. Usually
corresponds to the Router ID or the
primary address.";
}
leaf-list rp-set-address {
type inet:ip-address;
description
"Specifies the IP address of other RP routers
that share the same RP IP address.";
}
}
}
leaf rp-address {
when "../provider-managed/enabled = 'false'" {
description
"Relevant when the RP is not managed by the
provider.";
}
type inet:ip-address;
mandatory true;
description
"Defines the address of the RP.
Used if the RP is managed by the customer.";
}
container groups {
description
"Multicast groups associated with the RP.";
list group {
key "id";
description
"List of multicast groups.";
leaf id {
type uint16;
description
"Identifier for the group.";
}
choice group-format {
mandatory true;
description
"Choice for multicast group format.";
case group-prefix {
leaf group-address {
type inet:ip-prefix;
description
"A single multicast group prefix.";
}
}
case startend {
leaf group-start {
type inet:ip-address;
description
"The first multicast group address in
the multicast group address range.";
}
leaf group-end {
type inet:ip-address;
description
"The last multicast group address in
the multicast group address range.";
}
}
}
}
}
}
}
container rp-discovery {
description
"RP discovery parameters.";
leaf rp-discovery-type {
type identityref {
base vpn-common:multicast-rp-discovery-type;
}
default "vpn-common:static-rp";
description
"Type of RP discovery used.";
}
container bsr-candidates {
when "derived-from-or-self(../rp-discovery-type, "
+ "'vpn-common:bsr-rp')" {
description
"Only applicable if the discovery type
is 'bsr-rp'.";
}
description
"Container for the customer Bootstrap Router (BSR)
candidate's addresses.";
leaf-list bsr-candidate-address {
type inet:ip-address;
description
"Specifies the address of the candidate BSR.";
}
}
}
}
container igmp {
if-feature "vpn-common:igmp and vpn-common:ipv4";
description
"Includes IGMP-related parameters.";
list static-group {
key "group-addr";
description
"Multicast static source/group associated with the
IGMP session.";
leaf group-addr {
type rt-types:ipv4-multicast-group-address;
description
"Multicast group IPv4 address.";
}
leaf source-addr {
type rt-types:ipv4-multicast-source-address;
description
"Multicast source IPv4 address.";
}
}
leaf max-groups {
type uint32;
description
"Indicates the maximum number of groups.";
}
leaf max-entries {
type uint32;
description
"Indicates the maximum number of IGMP entries.";
}
leaf version {
type identityref {
base vpn-common:igmp-version;
}
default "vpn-common:igmpv2";
description
"Indicates the IGMP version.";
reference
"RFC 1112: Host Extensions for IP Multicasting
RFC 2236: Internet Group Management Protocol,
Version 2
RFC 3376: Internet Group Management Protocol,
Version 3";
}
}
container mld {
if-feature "vpn-common:mld and vpn-common:ipv6";
description
"Includes MLD-related parameters.";
list static-group {
key "group-addr";
description
"Multicast static source/group associated with the
MLD session.";
leaf group-addr {
type rt-types:ipv6-multicast-group-address;
description
"Multicast group IPv6 address.";
}
leaf source-addr {
type rt-types:ipv6-multicast-source-address;
description
"Multicast source IPv6 address.";
}
}
leaf max-groups {
type uint32;
description
"Indicates the maximum number of groups.";
}
leaf max-entries {
type uint32;
description
"Indicates the maximum number of MLD entries.";
}
leaf version {
type identityref {
base vpn-common:mld-version;
}
default "vpn-common:mldv2";
description
"Indicates the MLD protocol version.";
reference
"RFC 2710: Multicast Listener Discovery (MLD) for IPv6
RFC 3810: Multicast Listener Discovery Version 2
(MLDv2) for IPv6";
}
}
container pim {
if-feature "vpn-common:pim";
description
"Only applies when the protocol type is 'pim'.";
leaf hello-interval {
type rt-types:timer-value-seconds16;
default "30";
description
"Interval between PIM Hello messages. If set to
'infinity' or 'not-set', no periodic Hello messages
are sent.";
reference
"RFC 7761: Protocol Independent Multicast - Sparse
Mode (PIM-SM): Protocol Specification
(Revised), Section 4.11
RFC 8294: Common YANG Data Types for the Routing
Area";
}
leaf dr-priority {
type uint32;
default "1";
description
"Indicates the preference associated with the
Designated Router (DR) election process. A larger
value has a higher priority over a smaller value.";
reference
"RFC 7761: Protocol Independent Multicast - Sparse
Mode (PIM-SM): Protocol Specification
(Revised), Section 4.3.2";
}
}
}
}
/* Main Blocks */
/* Main l3vpn-ntw */
container l3vpn-ntw {
description
"Main container for management of Layer 3 Virtual Private
Network (L3VPN) services.";
container vpn-profiles {
description
"Contains a set of valid VPN profiles to reference
in the VPN service.";
uses vpn-common:vpn-profile-cfg;
}
container vpn-services {
description
"Container for the VPN services.";
list vpn-service {
key "vpn-id";
description
"List of VPN services.";
uses vpn-common:vpn-description;
leaf parent-service-id {
type vpn-common:vpn-id;
description
"Pointer to the parent service, if any.
A parent service can be an L3SM, a slice request,
a VPN+ service, etc.";
}
leaf vpn-type {
type identityref {
base vpn-common:service-type;
}
description
"Indicates the service type.";
}
leaf vpn-service-topology {
type identityref {
base vpn-common:vpn-topology;
}
default "vpn-common:any-to-any";
description
"VPN service topology.";
}
uses vpn-common:service-status;
container vpn-instance-profiles {
description
"Container for a list of VPN instance profiles.";
list vpn-instance-profile {
key "profile-id";
description
"List of VPN instance profiles.";
leaf profile-id {
type string;
description
"VPN instance profile identifier.";
}
leaf role {
type identityref {
base vpn-common:role;
}
default "vpn-common:any-to-any-role";
description
"Role of the VPN node in the VPN.";
}
uses vpn-instance-profile;
}
}
container underlay-transport {
description
"Container for the underlay transport.";
uses vpn-common:underlay-transport;
}
container external-connectivity {
if-feature "vpn-common:external-connectivity";
description
"Container for external connectivity.";
choice profile {
description
"Choice for the external connectivity profile.";
case profile {
leaf profile-name {
type leafref {
path "/l3vpn-ntw/vpn-profiles"
+ "/valid-provider-identifiers"
+ "/external-connectivity-identifier/id";
}
description
"Name of the service provider's profile to be
applied at the VPN service level.";
}
}
}
}
container vpn-nodes {
description
"Container for VPN nodes.";
list vpn-node {
key "vpn-node-id";
description
"Includes a list of VPN nodes.";
leaf vpn-node-id {
type vpn-common:vpn-id;
description
"An identifier of the VPN node.";
}
leaf description {
type string;
description
"Textual description of the VPN node.";
}
leaf ne-id {
type string;
description
"Unique identifier of the network element where
the VPN node is deployed.";
}
leaf local-as {
if-feature "vpn-common:rtg-bgp";
type inet:as-number;
description
"Provider's AS number. Used if the customer
requests BGP routing.";
}
leaf router-id {
type rt-types:router-id;
description
"A 32-bit number in the dotted-quad format that is
used to uniquely identify a node within an AS.
This identifier is used for both IPv4 and IPv6.";
}
container active-vpn-instance-profiles {
description
"Container for active VPN instance profiles.";
list vpn-instance-profile {
key "profile-id";
description
"Includes a list of active VPN instance
profiles.";
leaf profile-id {
type leafref {
path "/l3vpn-ntw/vpn-services/vpn-service"
+ "/vpn-instance-profiles"
+ "/vpn-instance-profile/profile-id";
}
description
"Node's active VPN instance profile.";
}
list router-id {
key "address-family";
description
"Router ID per address family.";
leaf address-family {
type identityref {
base vpn-common:address-family;
}
description
"Indicates the address family for which the
Router ID applies.";
}
leaf router-id {
type inet:ip-address;
description
"The 'router-id' information can be an IPv4
or IPv6 address. This can be used,
for example, to configure an IPv6 address
as a Router ID when such a capability is
supported by underlay routers. In such a
case, the configured value overrides the
generic value defined at the VPN node
level.";
}
}
uses vpn-instance-profile;
}
}
container msdp {
if-feature "msdp";
description
"Includes MSDP-related parameters.";
leaf peer {
type inet:ipv4-address;
description
"Indicates the IPv4 address of the MSDP peer.";
}
leaf local-address {
type inet:ipv4-address;
description
"Indicates the IPv4 address of the local end.
This local address must be configured on
the node.";
}
uses vpn-common:service-status;
}
uses vpn-common:vpn-components-group;
uses vpn-common:service-status;
container vpn-network-accesses {
description
"List of network accesses.";
list vpn-network-access {
key "id";
description
"List of network accesses.";
leaf id {
type vpn-common:vpn-id;
description
"Identifier for the network access.";
}
leaf interface-id {
type string;
description
"Identifier for the physical or logical
interface.
The identification of the sub-interface
is provided at the connection level and/or
the IP connection level.";
}
leaf description {
type string;
description
"Textual description of the network access.";
}
leaf vpn-network-access-type {
type identityref {
base vpn-common:site-network-access-type;
}
default "vpn-common:point-to-point";
description
"Describes the type of connection, e.g.,
point to point.";
}
leaf vpn-instance-profile {
type leafref {
path "/l3vpn-ntw/vpn-services/vpn-service"
+ "/vpn-nodes/vpn-node"
+ "/active-vpn-instance-profiles"
+ "/vpn-instance-profile/profile-id";
}
description
"An identifier of an active VPN instance
profile.";
}
uses vpn-common:service-status;
container connection {
description
"Defines Layer 2 protocols and parameters that
are required to enable connectivity between
the PE and the CE.";
container encapsulation {
description
"Container for Layer 2 encapsulation.";
leaf type {
type identityref {
base vpn-common:encapsulation-type;
}
default "vpn-common:priority-tagged";
description
"Encapsulation type. By default, the type
of the tagged interface is
'priority-tagged'.";
}
container dot1q {
when "derived-from-or-self(../type, "
+ "'vpn-common:dot1q')" {
description
"Only applies when the type of the
tagged interface is 'dot1q'.";
}
description
"Tagged interface.";
leaf tag-type {
type identityref {
base vpn-common:tag-type;
}
default "vpn-common:c-vlan";
description
"Tag type. By default, the tag type is
'c-vlan'.";
}
leaf cvlan-id {
type uint16 {
range "1..4094";
}
description
"VLAN identifier.";
}
}
container priority-tagged {
when "derived-from-or-self(../type, "
+ "'vpn-common:priority-tagged')" {
description
"Only applies when the type of
the tagged interface is
'priority-tagged'.";
}
description
"Priority tagged.";
leaf tag-type {
type identityref {
base vpn-common:tag-type;
}
default "vpn-common:c-vlan";
description
"Tag type. By default, the tag type is
'c-vlan'.";
}
}
container qinq {
when "derived-from-or-self(../type, "
+ "'vpn-common:qinq')" {
description
"Only applies when the type of the
tagged interface is 'qinq'.";
}
description
"Includes QinQ parameters.";
leaf tag-type {
type identityref {
base vpn-common:tag-type;
}
default "vpn-common:s-c-vlan";
description
"Tag type.";
}
leaf svlan-id {
type uint16;
mandatory true;
description
"Service VLAN (S-VLAN) identifier.";
}
leaf cvlan-id {
type uint16;
mandatory true;
description
"Customer VLAN (C-VLAN) identifier.";
}
}
}
choice l2-service {
description
"The Layer 2 connectivity service can be
provided by indicating a pointer to an
L2VPN or by specifying a Layer 2 tunnel
service.";
container l2-tunnel-service {
description
"Defines a Layer 2 tunnel termination.
It is only applicable when a tunnel is
required. The supported values are
'pseudowire', 'vpls', and 'vxlan'. Other
values may be defined, if needed.";
leaf type {
type identityref {
base l2-tunnel-type;
}
description
"Selects the tunnel termination option
for each VPN network access.";
}
container pseudowire {
when "derived-from-or-self(../type, "
+ "'pseudowire')" {
description
"Only applies when the Layer 2 service
type is 'pseudowire'.";
}
description
"Includes pseudowire termination
parameters.";
leaf vcid {
type uint32;
description
"Indicates a pseudowire (PW) or
virtual circuit (VC) identifier.";
}
leaf far-end {
type union {
type uint32;
type inet:ip-address;
}
description
"Neighbor reference.";
reference
"RFC 8077: Pseudowire Setup and
Maintenance Using the Label
Distribution Protocol
(LDP), Section 6.1";
}
}
container vpls {
when "derived-from-or-self(../type, "
+ "'vpls')" {
description
"Only applies when the Layer 2 service
type is 'vpls'.";
}
description
"VPLS termination parameters.";
leaf vcid {
type uint32;
description
"VC identifier.";
}
leaf-list far-end {
type union {
type uint32;
type inet:ip-address;
}
description
"Neighbor reference.";
}
}
container vxlan {
when "derived-from-or-self(../type, "
+ "'vxlan')" {
description
"Only applies when the Layer 2 service
type is 'vxlan'.";
}
description
"VXLAN termination parameters.";
leaf vni-id {
type uint32;
mandatory true;
description
"VXLAN Network Identifier (VNI).";
}
leaf peer-mode {
type identityref {
base vpn-common:vxlan-peer-mode;
}
default "vpn-common:static-mode";
description
"Specifies the VXLAN access mode. By
default, the peer mode is set to
'static-mode'.";
}
leaf-list peer-ip-address {
type inet:ip-address;
description
"List of a peer's IP addresses.";
}
}
}
case l2vpn {
leaf l2vpn-id {
type vpn-common:vpn-id;
description
"Indicates the L2VPN service associated
with an Integrated Routing and Bridging
(IRB) interface.";
}
}
}
leaf l2-termination-point {
type string;
description
"Specifies a reference to a local Layer 2
termination point, such as a Layer 2
sub-interface.";
}
leaf local-bridge-reference {
type string;
description
"Specifies a local bridge reference to
accommodate, for example, implementations
that require internal bridging.
A reference may be a local bridge domain.";
}
leaf bearer-reference {
if-feature "vpn-common:bearer-reference";
type string;
description
"This is an internal reference for the
service provider to identify the bearer
associated with this VPN.";
}
container lag-interface {
if-feature "vpn-common:lag-interface";
description
"Container for configuration of Link
Aggregation Group (LAG) interface
attributes.";
leaf lag-interface-id {
type string;
description
"LAG interface identifier.";
}
container member-link-list {
description
"Container for the member link list.";
list member-link {
key "name";
description
"Member link.";
leaf name {
type string;
description
"Member link name.";
}
}
}
}
}
container ip-connection {
description
"Defines IP connection parameters.";
leaf l3-termination-point {
type string;
description
"Specifies a reference to a local Layer 3
termination point, such as a bridge domain
interface.";
}
container ipv4 {
if-feature "vpn-common:ipv4";
description
"IPv4-specific parameters.";
leaf local-address {
type inet:ipv4-address;
description
"The IP address used at the provider's
interface.";
}
leaf prefix-length {
type uint8 {
range "0..32";
}
description
"Subnet prefix length expressed in bits.
It is applied to both local and customer
addresses.";
}
leaf address-allocation-type {
type identityref {
base address-allocation-type;
}
must "not(derived-from-or-self(current(), "
+ "'slaac') or "
+ "derived-from-or-self(current(), "
+ "'provider-dhcp-slaac'))" {
error-message "SLAAC is only applicable "
+ "to IPv6.";
}
description
"Defines how addresses are allocated to
the peer site.
If there is no value for the address
allocation type, then IPv4 addressing
is not enabled.";
}
choice allocation-type {
description
"Choice of the IPv4 address allocation.";
case provider-dhcp {
description
"Parameters related to DHCP-allocated
addresses. IP addresses are allocated
by DHCP, which is provided by the
operator.";
leaf dhcp-service-type {
type enumeration {
enum server {
description
"Local DHCP server.";
}
enum relay {
description
"Local DHCP relay. DHCP requests
are relayed to a provider's
server.";
}
}
description
"Indicates the type of DHCP service to
be enabled on this access.";
}
choice service-type {
description
"Choice based on the DHCP service
type.";
case relay {
description
"Container for a list of the
provider's DHCP servers (i.e.,
'dhcp-service-type' is set to
'relay').";
leaf-list server-ip-address {
type inet:ipv4-address;
description
"IPv4 addresses of the provider's
DHCP server, for use by the local
DHCP relay.";
}
}
case server {
description
"A choice for how addresses are
assigned when a local DHCP server
is enabled.";
choice address-assign {
default "number";
description
"A choice for how IPv4 addresses
are assigned.";
case number {
leaf number-of-dynamic-address {
type uint16;
default "1";
description
"Specifies the number of IP
addresses to be assigned to
the customer on this
access.";
}
}
case explicit {
container customer-addresses {
description
"Container for customer
addresses to be allocated
using DHCP.";
list address-pool {
key "pool-id";
description
"Describes IP addresses to
be allocated by DHCP.
When only 'start-address'
is present, it represents a
single address.
When both 'start-address'
and 'end-address' are
specified, it implies a
range inclusive of both
addresses.";
leaf pool-id {
type string;
description
"A pool identifier for the
address range from
'start-address' to
'end-address'.";
}
leaf start-address {
type inet:ipv4-address;
mandatory true;
description
"Indicates the first
address in the pool.";
}
leaf end-address {
type inet:ipv4-address;
description
"Indicates the last
address in the pool.";
}
}
}
}
}
}
}
}
case dhcp-relay {
description
"The DHCP relay is provided by the
operator.";
container customer-dhcp-servers {
description
"Container for a list of the
customer's DHCP servers.";
leaf-list server-ip-address {
type inet:ipv4-address;
description
"IPv4 addresses of the customer's
DHCP server.";
}
}
}
case static-addresses {
description
"Lists the IPv4 addresses that are
used.";
leaf primary-address {
type leafref {
path "../address/address-id";
}
description
"Primary address of the connection.";
}
list address {
key "address-id";
description
"Lists the IPv4 addresses that are
used.";
leaf address-id {
type string;
description
"An identifier of the static IPv4
address.";
}
leaf customer-address {
type inet:ipv4-address;
description
"IPv4 address of the customer
side.";
}
}
}
}
}
container ipv6 {
if-feature "vpn-common:ipv6";
description
"IPv6-specific parameters.";
leaf local-address {
type inet:ipv6-address;
description
"IPv6 address of the provider side.";
}
leaf prefix-length {
type uint8 {
range "0..128";
}
description
"Subnet prefix length expressed in bits.
It is applied to both local and customer
addresses.";
}
leaf address-allocation-type {
type identityref {
base address-allocation-type;
}
description
"Defines how addresses are allocated.
If there is no value for the address
allocation type, then IPv6 addressing is
disabled.";
}
choice allocation-type {
description
"A choice based on the IPv6 allocation
type.";
container provider-dhcp {
when "derived-from-or-self(../address-allo"
+ "cation-type, 'provider-dhcp') or "
+ "derived-from-or-self(../address-allo"
+ "cation-type, 'provider-dhcp-slaac')" {
description
"Only applies when addresses are
allocated by DHCPv6 as provided by
the operator.";
}
description
"Parameters related to DHCP-allocated
addresses.";
leaf dhcp-service-type {
type enumeration {
enum server {
description
"Local DHCPv6 server.";
}
enum relay {
description
"DHCPv6 relay.";
}
}
description
"Indicates the type of the DHCPv6
service to be enabled on this
access.";
}
choice service-type {
description
"Choice based on the DHCPv6 service
type.";
case relay {
leaf-list server-ip-address {
type inet:ipv6-address;
description
"IPv6 addresses of the provider's
DHCPv6 server.";
}
}
case server {
choice address-assign {
default "number";
description
"Choice for how IPv6 prefixes are
assigned by the DHCPv6 server.";
case number {
leaf number-of-dynamic-address {
type uint16;
default "1";
description
"Describes the number of IPv6
prefixes that are allocated
to the customer on this
access.";
}
}
case explicit {
container customer-addresses {
description
"Container for customer IPv6
addresses allocated by
DHCPv6.";
list address-pool {
key "pool-id";
description
"Describes IPv6 addresses
allocated by DHCPv6.
When only 'start-address'
is present, it represents a
single address.
When both 'start-address'
and 'end-address' are
specified, it implies a
range inclusive of both
addresses.";
leaf pool-id {
type string;
description
"A pool identifier for the
address range from
'start-address' to
'end-address'.";
}
leaf start-address {
type inet:ipv6-address;
mandatory true;
description
"Indicates the first
address.";
}
leaf end-address {
type inet:ipv6-address;
description
"Indicates the last
address.";
}
}
}
}
}
}
}
}
case dhcp-relay {
description
"DHCPv6 relay provided by the
operator.";
container customer-dhcp-servers {
description
"Container for a list of the
customer's DHCP servers.";
leaf-list server-ip-address {
type inet:ipv6-address;
description
"Contains the IP addresses of the
customer's DHCPv6 server.";
}
}
}
case static-addresses {
description
"IPv6-specific parameters for static
allocation.";
leaf primary-address {
type leafref {
path "../address/address-id";
}
description
"Principal address of the
connection.";
}
list address {
key "address-id";
description
"Describes IPv6 addresses that are
used.";
leaf address-id {
type string;
description
"An identifier of an IPv6 address.";
}
leaf customer-address {
type inet:ipv6-address;
description
"An IPv6 address of the customer
side.";
}
}
}
}
}
}
container routing-protocols {
description
"Defines routing protocols.";
list routing-protocol {
key "id";
description
"List of routing protocols used on the
CE-PE link. This list can be augmented.";
leaf id {
type string;
description
"Unique identifier for the routing
protocol.";
}
leaf type {
type identityref {
base vpn-common:routing-protocol-type;
}
description
"Type of routing protocol.";
}
list routing-profiles {
key "id";
description
"Routing profiles.";
leaf id {
type leafref {
path "/l3vpn-ntw/vpn-profiles"
+ "/valid-provider-identifiers"
+ "/routing-profile-identifier/id";
}
description
"Routing profile to be used.";
}
leaf type {
type identityref {
base vpn-common:ie-type;
}
description
"Import, export, or both.";
}
}
container static {
when "derived-from-or-self(../type, "
+ "'vpn-common:static-routing')" {
description
"Only applies when the protocol is a
static routing protocol.";
}
description
"Configuration specific to static
routing.";
container cascaded-lan-prefixes {
description
"LAN prefixes from the customer.";
list ipv4-lan-prefixes {
if-feature "vpn-common:ipv4";
key "lan next-hop";
description
"List of LAN prefixes for the site.";
leaf lan {
type inet:ipv4-prefix;
description
"LAN prefixes.";
}
leaf lan-tag {
type string;
description
"Internal tag to be used in VPN
policies.";
}
leaf next-hop {
type union {
type inet:ip-address;
type predefined-next-hop;
}
description
"The next hop that is to be used
for the static route. This may be
specified as an IP address or a
predefined next-hop type (e.g.,
'discard' or 'local-link').";
}
leaf bfd-enable {
if-feature "vpn-common:bfd";
type boolean;
description
"Enables Bidirectional Forwarding
Detection (BFD).";
}
leaf metric {
type uint32;
description
"Indicates the metric associated
with the static route.";
}
leaf preference {
type uint32;
description
"Indicates the preference associated
with the static route.";
}
uses vpn-common:service-status;
}
list ipv6-lan-prefixes {
if-feature "vpn-common:ipv6";
key "lan next-hop";
description
"List of LAN prefixes for the site.";
leaf lan {
type inet:ipv6-prefix;
description
"LAN prefixes.";
}
leaf lan-tag {
type string;
description
"Internal tag to be used in VPN
policies.";
}
leaf next-hop {
type union {
type inet:ip-address;
type predefined-next-hop;
}
description
"The next hop that is to be used for
the static route. This may be
specified as an IP address or a
predefined next-hop type (e.g.,
'discard' or 'local-link').";
}
leaf bfd-enable {
if-feature "vpn-common:bfd";
type boolean;
description
"Enables BFD.";
}
leaf metric {
type uint32;
description
"Indicates the metric associated
with the static route.";
}
leaf preference {
type uint32;
description
"Indicates the preference associated
with the static route.";
}
uses vpn-common:service-status;
}
}
}
container bgp {
when "derived-from-or-self(../type, "
+ "'vpn-common:bgp-routing')" {
description
"Only applies when the protocol is
BGP.";
}
description
"Configuration specific to BGP.";
leaf description {
type string;
description
"Includes a description of the BGP
session.
This description is meant to be used
for diagnostic purposes. The semantic
of the description is local to an
implementation.";
}
leaf local-as {
type inet:as-number;
description
"Indicates a local AS Number (ASN), if
an ASN distinct from the ASN configured
at the VPN node level is needed.";
}
leaf peer-as {
type inet:as-number;
mandatory true;
description
"Indicates the customer's ASN when
the customer requests BGP routing.";
}
leaf address-family {
type identityref {
base vpn-common:address-family;
}
description
"This node contains the address families
to be activated. 'dual-stack' means
that both IPv4 and IPv6 will be
activated.";
}
leaf local-address {
type union {
type inet:ip-address;
type if:interface-ref;
}
description
"Sets the local IP address to use for
the BGP transport session. This may be
expressed as either an IP address or a
reference to an interface.";
}
leaf-list neighbor {
type inet:ip-address;
description
"IP address(es) of the BGP neighbor.
IPv4 and IPv6 neighbors may be
indicated if two sessions will be used
for IPv4 and IPv6.";
}
leaf multihop {
type uint8;
description
"Describes the number of IP hops allowed
between a given BGP neighbor and
the PE.";
}
leaf as-override {
type boolean;
default "false";
description
"Defines whether ASN override is
enabled, i.e., replacing the ASN of
the customer specified in the AS_PATH
attribute with the local ASN.";
}
leaf allow-own-as {
type uint8;
default "0";
description
"If set, specifies the maximum number of
occurrences of the provider's ASN that
are permitted within the AS_PATH
before it is rejected.";
}
leaf prepend-global-as {
type boolean;
default "false";
description
"In some situations, the ASN that is
provided at the VPN node level may be
distinct from the ASN configured at the
VPN network access level. When such
ASNs are provided, they are both
prepended to the BGP route updates
for this access. To disable that
behavior, 'prepend-global-as'
must be set to 'false'. In such a
case, the ASN that is provided at
the VPN node level is not prepended
to the BGP route updates for
this access.";
}
leaf send-default-route {
type boolean;
default "false";
description
"Defines whether default routes can be
advertised to a peer. If set, the
default routes are advertised to a
peer.";
}
leaf site-of-origin {
when "../address-family = 'vpn-common:ipv4' "
+ "or 'vpn-common:dual-stack'" {
description
"Only applies if IPv4 is activated.";
}
type rt-types:route-origin;
description
"The Site of Origin attribute is encoded
as a Route Origin Extended Community.
It is meant to uniquely identify the
set of routes learned from a site via a
particular CE-PE connection and is used
to prevent routing loops.";
reference
"RFC 4364: BGP/MPLS IP Virtual Private
Networks (VPNs), Section 7";
}
leaf ipv6-site-of-origin {
when "../address-family = 'vpn-common:ipv6' "
+ "or 'vpn-common:dual-stack'" {
description
"Only applies if IPv6 is activated.";
}
type rt-types:ipv6-route-origin;
description
"The IPv6 Site of Origin attribute is
encoded as an IPv6 Route Origin
Extended Community. It is meant to
uniquely identify the set of routes
learned from a site via VRF
information.";
reference
"RFC 5701: IPv6 Address Specific BGP
Extended Community
Attribute";
}
list redistribute-connected {
key "address-family";
description
"Indicates, per address family, the
policy to follow for connected
routes.";
leaf address-family {
type identityref {
base vpn-common:address-family;
}
description
"Indicates the address family.";
}
leaf enable {
type boolean;
description
"Enables the redistribution of
connected routes.";
}
}
container bgp-max-prefix {
description
"Controls the behavior when a prefix
maximum is reached.";
leaf max-prefix {
type uint32;
default "5000";
description
"Indicates the maximum number of BGP
prefixes allowed in the BGP session.
It allows control of how many
prefixes can be received from a
neighbor.
If the limit is exceeded, the action
indicated in 'violate-action' will be
followed.";
reference
"RFC 4271: A Border Gateway Protocol 4
(BGP-4), Section 8.2.2";
}
leaf warning-threshold {
type decimal64 {
fraction-digits 5;
range "0..100";
}
units "percent";
default "75";
description
"When this value is reached, a warning
notification will be triggered.";
}
leaf violate-action {
type enumeration {
enum warning {
description
"Only a warning message is sent to
the peer when the limit is
exceeded.";
}
enum discard-extra-paths {
description
"Discards extra paths when the
limit is exceeded.";
}
enum restart {
description
"The BGP session restarts after
the indicated time interval.";
}
}
description
"If the BGP neighbor 'max-prefix'
limit is reached, the action
indicated in 'violate-action'
will be followed.";
}
leaf restart-timer {
type uint32;
units "seconds";
description
"Time interval after which the BGP
session will be reestablished.";
}
}
container bgp-timers {
description
"Includes two BGP timers that can be
customized when building a VPN service
with BGP used as the CE-PE routing
protocol.";
leaf keepalive {
type uint16 {
range "0..21845";
}
units "seconds";
default "30";
description
"This timer indicates the KEEPALIVE
messages' frequency between a PE
and a BGP peer.
If set to '0', it indicates that
KEEPALIVE messages are disabled.
It is suggested that the maximum
time between KEEPALIVE messages be
one-third of the Hold Time
interval.";
reference
"RFC 4271: A Border Gateway Protocol 4
(BGP-4), Section 4.4";
}
leaf hold-time {
type uint16 {
range "0 | 3..65535";
}
units "seconds";
default "90";
description
"Indicates the maximum number of
seconds that may elapse between the
receipt of successive KEEPALIVE
and/or UPDATE messages from the peer.
The Hold Time must be either zero or
at least three seconds.";
reference
"RFC 4271: A Border Gateway Protocol 4
(BGP-4), Section 4.2";
}
}
container authentication {
description
"Container for BGP authentication
parameters between a PE and a CE.";
leaf enable {
type boolean;
default "false";
description
"Enables or disables authentication.";
}
container keying-material {
when "../enable = 'true'";
description
"Container for describing how a BGP
routing session is to be secured
between a PE and a CE.";
choice option {
description
"Choice of authentication options.";
case ao {
description
"Uses the TCP Authentication
Option (TCP-AO).";
reference
"RFC 5925: The TCP Authentication
Option";
leaf enable-ao {
type boolean;
description
"Enables the TCP-AO.";
}
leaf ao-keychain {
type key-chain:key-chain-ref;
description
"Reference to the TCP-AO key
chain.";
reference
"RFC 8177: YANG Data Model for
Key Chains";
}
}
case md5 {
description
"Uses MD5 to secure the session.";
reference
"RFC 4364: BGP/MPLS IP Virtual
Private Networks
(VPNs), Section 13.2";
leaf md5-keychain {
type key-chain:key-chain-ref;
description
"Reference to the MD5 key
chain.";
reference
"RFC 8177: YANG Data Model for
Key Chains";
}
}
case explicit {
leaf key-id {
type uint32;
description
"Key identifier.";
}
leaf key {
type string;
description
"BGP authentication key.
This model only supports the
subset of keys that are
representable as ASCII
strings.";
}
leaf crypto-algorithm {
type identityref {
base key-chain:crypto-algorithm;
}
description
"Indicates the cryptographic
algorithm associated with the
key.";
}
}
case ipsec {
description
"Specifies a reference to an
Internet Key Exchange Protocol
(IKE) Security Association
(SA).";
leaf sa {
type string;
description
"Indicates the
administrator-assigned name
of the SA.";
}
}
}
}
}
uses vpn-common:service-status;
}
container ospf {
when "derived-from-or-self(../type, "
+ "'vpn-common:ospf-routing')" {
description
"Only applies when the protocol is
OSPF.";
}
description
"Configuration specific to OSPF.";
leaf address-family {
type identityref {
base vpn-common:address-family;
}
description
"Indicates whether IPv4, IPv6, or
both are to be activated.";
}
leaf area-id {
type yang:dotted-quad;
mandatory true;
description
"Area ID.";
reference
"RFC 4577: OSPF as the Provider/Customer
Edge Protocol for BGP/MPLS IP
Virtual Private Networks
(VPNs), Section 4.2.3
RFC 6565: OSPFv3 as a Provider Edge to
Customer Edge (PE-CE) Routing
Protocol, Section 4.2";
}
leaf metric {
type uint16;
default "1";
description
"Metric of the PE-CE link. It is used
in the routing state calculation and
path selection.";
}
container sham-links {
if-feature "vpn-common:rtg-ospf-sham-link";
description
"List of sham links.";
reference
"RFC 4577: OSPF as the Provider/Customer
Edge Protocol for BGP/MPLS IP
Virtual Private Networks
(VPNs), Section 4.2.7
RFC 6565: OSPFv3 as a Provider Edge to
Customer Edge (PE-CE) Routing
Protocol, Section 5";
list sham-link {
key "target-site";
description
"Creates a sham link with another
site.";
leaf target-site {
type string;
description
"Target site for the sham link
connection. The site is referred
to by its identifier.";
}
leaf metric {
type uint16;
default "1";
description
"Metric of the sham link. It is
used in the routing state
calculation and path selection.
The default value is set to '1'.";
reference
"RFC 4577: OSPF as the
Provider/Customer Edge
Protocol for BGP/MPLS IP
Virtual Private Networks
(VPNs), Section 4.2.7.3
RFC 6565: OSPFv3 as a Provider Edge
to Customer Edge (PE-CE)
Routing Protocol,
Section 5.2";
}
}
}
leaf max-lsa {
type uint32 {
range "1..4294967294";
}
description
"Maximum number of allowed Link State
Advertisements (LSAs) that the OSPF
instance will accept.";
}
container authentication {
description
"Authentication configuration.";
leaf enable {
type boolean;
default "false";
description
"Enables or disables authentication.";
}
container keying-material {
when "../enable = 'true'";
description
"Container for describing how an OSPF
session is to be secured between a CE
and a PE.";
choice option {
description
"Options for OSPF authentication.";
case auth-key-chain {
leaf key-chain {
type key-chain:key-chain-ref;
description
"Name of the key chain.";
}
}
case auth-key-explicit {
leaf key-id {
type uint32;
description
"Key identifier.";
}
leaf key {
type string;
description
"OSPF authentication key.
This model only supports the
subset of keys that are
representable as ASCII
strings.";
}
leaf crypto-algorithm {
type identityref {
base key-chain:crypto-algorithm;
}
description
"Indicates the cryptographic
algorithm associated with the
key.";
}
}
case ipsec {
leaf sa {
type string;
description
"Indicates the
administrator-assigned name
of the SA.";
reference
"RFC 4552: Authentication/
Confidentiality for
OSPFv3";
}
}
}
}
}
uses vpn-common:service-status;
}
container isis {
when "derived-from-or-self(../type, "
+ "'vpn-common:isis-routing')" {
description
"Only applies when the protocol is
IS-IS.";
}
description
"Configuration specific to IS-IS.";
leaf address-family {
type identityref {
base vpn-common:address-family;
}
description
"Indicates whether IPv4, IPv6, or both
are to be activated.";
}
leaf area-address {
type area-address;
mandatory true;
description
"Area address.";
}
leaf level {
type identityref {
base vpn-common:isis-level;
}
description
"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 {
type uint16;
default "1";
description
"Metric of the PE-CE link. It is used
in the routing state calculation and
path selection.";
}
leaf mode {
type enumeration {
enum active {
description
"The interface sends or receives
IS-IS protocol control packets.";
}
enum passive {
description
"Suppresses the sending of IS-IS
updates through the specified
interface.";
}
}
default "active";
description
"IS-IS interface mode type.";
}
container authentication {
description
"Authentication configuration.";
leaf enable {
type boolean;
default "false";
description
"Enables or disables authentication.";
}
container keying-material {
when "../enable = 'true'";
description
"Container for describing how an IS-IS
session is to be secured between a CE
and a PE.";
choice option {
description
"Options for IS-IS authentication.";
case auth-key-chain {
leaf key-chain {
type key-chain:key-chain-ref;
description
"Name of the key chain.";
}
}
case auth-key-explicit {
leaf key-id {
type uint32;
description
"Key identifier.";
}
leaf key {
type string;
description
"IS-IS authentication key.
This model only supports the
subset of keys that are
representable as ASCII
strings.";
}
leaf crypto-algorithm {
type identityref {
base key-chain:crypto-algorithm;
}
description
"Indicates the cryptographic
algorithm associated with the
key.";
}
}
}
}
}
uses vpn-common:service-status;
}
container rip {
when "derived-from-or-self(../type, "
+ "'vpn-common:rip-routing')" {
description
"Only applies when the protocol is RIP.
For IPv4, the model assumes that RIP
version 2 is used.";
}
description
"Configuration specific to RIP routing.";
leaf address-family {
type identityref {
base vpn-common:address-family;
}
description
"Indicates whether IPv4, IPv6, or both
address families are to be activated.";
}
container timers {
description
"Indicates the RIP timers.";
reference
"RFC 2453: RIP Version 2";
leaf update-interval {
type uint16 {
range "1..32767";
}
units "seconds";
default "30";
description
"Indicates the RIP update time, i.e.,
the amount of time for which RIP
updates are sent.";
}
leaf invalid-interval {
type uint16 {
range "1..32767";
}
units "seconds";
default "180";
description
"The interval before a route is
declared invalid after no updates are
received. This value is at least
three times the value for the
'update-interval' argument.";
}
leaf holddown-interval {
type uint16 {
range "1..32767";
}
units "seconds";
default "180";
description
"Specifies the interval before better
routes are released.";
}
leaf flush-interval {
type uint16 {
range "1..32767";
}
units "seconds";
default "240";
description
"Indicates the RIP flush timer, i.e.,
the amount of time that must elapse
before a route is removed from the
routing table.";
}
}
leaf default-metric {
type uint8 {
range "0..16";
}
default "1";
description
"Sets the default metric.";
}
container authentication {
description
"Authentication configuration.";
leaf enable {
type boolean;
default "false";
description
"Enables or disables authentication.";
}
container keying-material {
when "../enable = 'true'";
description
"Container for describing how a RIP
session is to be secured between a CE
and a PE.";
choice option {
description
"Specifies the authentication
scheme.";
case auth-key-chain {
leaf key-chain {
type key-chain:key-chain-ref;
description
"Name of the key chain.";
}
}
case auth-key-explicit {
leaf key {
type string;
description
"RIP authentication key.
This model only supports the
subset of keys that are
representable as ASCII
strings.";
}
leaf crypto-algorithm {
type identityref {
base key-chain:crypto-algorithm;
}
description
"Indicates the cryptographic
algorithm associated with the
key.";
}
}
}
}
}
uses vpn-common:service-status;
}
container vrrp {
when "derived-from-or-self(../type, "
+ "'vpn-common:vrrp-routing')" {
description
"Only applies when the protocol is the
Virtual Router Redundancy Protocol
(VRRP).";
}
description
"Configuration specific to VRRP.";
reference
"RFC 5798: Virtual Router Redundancy
Protocol (VRRP) Version 3 for
IPv4 and IPv6";
leaf address-family {
type identityref {
base vpn-common:address-family;
}
description
"Indicates whether IPv4, IPv6, or both
address families are to be enabled.";
}
leaf vrrp-group {
type uint8 {
range "1..255";
}
description
"Includes the VRRP group identifier.";
}
leaf backup-peer {
type inet:ip-address;
description
"Indicates the IP address of the peer.";
}
leaf-list virtual-ip-address {
type inet:ip-address;
description
"Virtual IP addresses for a single VRRP
group.";
reference
"RFC 5798: Virtual Router Redundancy
Protocol (VRRP) Version 3 for
IPv4 and IPv6,
Sections 1.2 and 1.3";
}
leaf priority {
type uint8 {
range "1..254";
}
default "100";
description
"Sets the local priority of the VRRP
speaker.";
}
leaf ping-reply {
type boolean;
default "false";
description
"Controls whether the VRRP speaker
should reply to ping requests.";
}
uses vpn-common:service-status;
}
}
}
container oam {
description
"Defines the Operations, Administration,
and Maintenance (OAM) mechanisms used.
BFD is set as a fault detection mechanism,
but other mechanisms can be defined in the
future.";
container bfd {
if-feature "vpn-common:bfd";
description
"Container for BFD.";
leaf session-type {
type identityref {
base vpn-common:bfd-session-type;
}
default "vpn-common:classic-bfd";
description
"Specifies the BFD session type.";
}
leaf desired-min-tx-interval {
type uint32;
units "microseconds";
default "1000000";
description
"The minimum interval between
transmissions of BFD Control packets, as
desired by the operator.";
reference
"RFC 5880: Bidirectional Forwarding
Detection (BFD),
Section 6.8.7";
}
leaf required-min-rx-interval {
type uint32;
units "microseconds";
default "1000000";
description
"The minimum interval between received BFD
Control packets that the PE should
support.";
reference
"RFC 5880: Bidirectional Forwarding
Detection (BFD),
Section 6.8.7";
}
leaf local-multiplier {
type uint8 {
range "1..255";
}
default "3";
description
"Specifies the detection multiplier that
is transmitted to a BFD peer.
The detection interval for the receiving
BFD peer is calculated by multiplying the
value of the negotiated transmission
interval by the received detection
multiplier value.";
reference
"RFC 5880: Bidirectional Forwarding
Detection (BFD),
Section 6.8.7";
}
leaf holdtime {
type uint32;
units "milliseconds";
description
"Expected BFD holdtime.
The customer may impose some fixed
values for the holdtime period if the
provider allows the customer to use
this function.
If the provider doesn't allow the
customer to use this function,
fixed values will not be set.";
reference
"RFC 5880: Bidirectional Forwarding
Detection (BFD),
Section 6.8.18";
}
leaf profile {
type leafref {
path "/l3vpn-ntw/vpn-profiles"
+ "/valid-provider-identifiers"
+ "/bfd-profile-identifier/id";
}
description
"Well-known service provider profile name.
The provider can propose some profiles
to the customer, depending on the
service level the customer wants to
achieve.";
}
container authentication {
presence "Enables BFD authentication";
description
"Parameters for BFD authentication.";
leaf key-chain {
type key-chain:key-chain-ref;
description
"Name of the key chain.";
}
leaf meticulous {
type boolean;
description
"Enables meticulous mode.";
reference
"RFC 5880: Bidirectional Forwarding
Detection (BFD),
Section 6.7";
}
}
uses vpn-common:service-status;
}
}
container security {
description
"Site-specific security parameters.";
container encryption {
if-feature "vpn-common:encryption";
description
"Container for CE-PE security encryption.";
leaf enabled {
type boolean;
default "false";
description
"If set to 'true', traffic encryption on
the connection is required. Otherwise,
it is disabled.";
}
leaf layer {
when "../enabled = 'true'" {
description
"Included only when encryption
is enabled.";
}
type enumeration {
enum layer2 {
description
"Encryption occurs at Layer 2.";
}
enum layer3 {
description
"Encryption occurs at Layer 3.
For example, IPsec may be used when
a customer requests Layer 3
encryption.";
}
}
description
"Indicates the layer on which encryption
is applied.";
}
}
container encryption-profile {
when "../encryption/enabled = 'true'" {
description
"Indicates the layer on which encryption
is enabled.";
}
description
"Container for the encryption profile.";
choice profile {
description
"Choice for the encryption profile.";
case provider-profile {
leaf profile-name {
type leafref {
path "/l3vpn-ntw/vpn-profiles"
+ "/valid-provider-identifiers"
+ "/encryption-profile-identifier/id";
}
description
"Name of the service provider's
profile to be applied.";
}
}
case customer-profile {
leaf customer-key-chain {
type key-chain:key-chain-ref;
description
"Customer-supplied key chain.";
}
}
}
}
}
container service {
description
"Service parameters of the attachment.";
leaf pe-to-ce-bandwidth {
if-feature "vpn-common:inbound-bw";
type uint64;
units "bps";
description
"From the customer site's perspective, the
service inbound bandwidth of the connection
or download bandwidth from the SP to the
site. Note that the L3SM uses
'input-bandwidth' to refer to the same
concept.";
}
leaf ce-to-pe-bandwidth {
if-feature "vpn-common:outbound-bw";
type uint64;
units "bps";
description
"From the customer site's perspective,
the service outbound bandwidth of the
connection or upload bandwidth from
the site to the SP. Note that the L3SM
uses 'output-bandwidth' to refer to the
same concept.";
}
leaf mtu {
type uint32;
units "bytes";
description
"MTU at the service level. If the service
is IP, it refers to the IP MTU. If
Carriers' Carriers (CsC) is enabled, the
requested MTU will refer to the MPLS
maximum labeled packet size and not to the
IP MTU.";
}
container qos {
if-feature "vpn-common:qos";
description
"QoS configuration.";
container qos-classification-policy {
description
"Configuration of the traffic
classification policy.";
uses vpn-common:qos-classification-policy;
}
container qos-action {
description
"List of QoS action policies.";
list rule {
key "id";
description
"List of QoS actions.";
leaf id {
type string;
description
"An identifier of the QoS action
rule.";
}
leaf target-class-id {
type string;
description
"Identification of the class of
service. This identifier is internal
to the administration.";
}
leaf inbound-rate-limit {
type decimal64 {
fraction-digits 5;
range "0..100";
}
units "percent";
description
"Specifies whether/how to rate-limit
the inbound traffic matching this QoS
policy. It is expressed as a percent
of the value that is indicated in
'input-bandwidth'.";
}
leaf outbound-rate-limit {
type decimal64 {
fraction-digits 5;
range "0..100";
}
units "percent";
description
"Specifies whether/how to rate-limit
the outbound traffic matching this
QoS policy. It is expressed as a
percent of the value that is
indicated in 'output-bandwidth'.";
}
}
}
container qos-profile {
description
"QoS profile configuration.";
list qos-profile {
key "profile";
description
"QoS profile.
Can be a standard profile or
a customized profile.";
leaf profile {
type leafref {
path "/l3vpn-ntw/vpn-profiles"
+ "/valid-provider-identifiers"
+ "/qos-profile-identifier/id";
}
description
"QoS profile to be used.";
}
leaf direction {
type identityref {
base vpn-common:qos-profile-direction;
}
default "vpn-common:both";
description
"The direction to which the QoS
profile is applied.";
}
}
}
}
container carriers-carrier {
if-feature "vpn-common:carriers-carrier";
description
"This container is used when the customer
provides MPLS-based services. This is
only used in the case of CsC (i.e., a
customer builds an MPLS service using an
IP VPN to carry its traffic).";
leaf signaling-type {
type enumeration {
enum ldp {
description
"Uses LDP as the signaling protocol
between the PE and the CE. In this
case, an IGP routing protocol must
also be configured.";
}
enum bgp {
description
"Uses BGP as the signaling protocol
between the PE and the CE.
In this case, BGP must also be
configured as the routing protocol.";
reference
"RFC 8277: Using BGP to Bind MPLS
Labels to Address
Prefixes";
}
}
default "bgp";
description
"MPLS signaling type.";
}
}
container ntp {
description
"Time synchronization may be needed in some
VPNs, such as infrastructure and management
VPNs. This container includes parameters
to enable the NTP service.";
reference
"RFC 5905: Network Time Protocol Version 4:
Protocol and Algorithms
Specification";
leaf broadcast {
type enumeration {
enum client {
description
"The VPN node will listen to NTP
broadcast messages on this VPN
network access.";
}
enum server {
description
"The VPN node will behave as a
broadcast server.";
}
}
description
"Indicates the NTP broadcast mode to use
for the VPN network access.";
}
container auth-profile {
description
"Pointer to a local profile.";
leaf profile-id {
type string;
description
"A pointer to a local authentication
profile on the VPN node is provided.";
}
}
uses vpn-common:service-status;
}
container multicast {
if-feature "vpn-common:multicast";
description
"Multicast parameters for the network
access.";
leaf access-type {
type enumeration {
enum receiver-only {
description
"The peer site only has receivers.";
}
enum source-only {
description
"The peer site only has sources.";
}
enum source-receiver {
description
"The peer site has both sources and
receivers.";
}
}
default "source-receiver";
description
"Type of multicast site.";
}
leaf address-family {
type identityref {
base vpn-common:address-family;
}
description
"Indicates the address family.";
}
leaf protocol-type {
type enumeration {
enum host {
description
"Hosts are directly connected to the
provider network.
Host protocols, such as IGMP or MLD,
are required.";
}
enum router {
description
"Hosts are behind a customer router.
PIM will be implemented.";
}
enum both {
description
"Some hosts are behind a customer
router, and some others are directly
connected to the provider network.
Both host and routing protocols must
be used.
Typically, IGMP and PIM will be
implemented.";
}
}
default "both";
description
"Multicast protocol type to be used with
the customer site.";
}
leaf remote-source {
type boolean;
default "false";
description
"A remote multicast source is a source
that is not on the same subnet as the
VPN network access. When set to 'true',
the multicast traffic from a remote
source is accepted.";
}
container igmp {
when "../protocol-type = 'host' and "
+ "../address-family = 'vpn-common:ipv4' "
+ "or 'vpn-common:dual-stack'";
if-feature "vpn-common:igmp";
description
"Includes IGMP-related parameters.";
list static-group {
key "group-addr";
description
"Multicast static source/group
associated with the IGMP session.";
leaf group-addr {
type rt-types:ipv4-multicast-group-address;
description
"Multicast group IPv4 address.";
}
leaf source-addr {
type
rt-types:ipv4-multicast-source-address;
description
"Multicast source IPv4 address.";
}
}
leaf max-groups {
type uint32;
description
"Indicates the maximum number of
groups.";
}
leaf max-entries {
type uint32;
description
"Indicates the maximum number of IGMP
entries.";
}
leaf max-group-sources {
type uint32;
description
"The maximum number of group sources.";
}
leaf version {
type identityref {
base vpn-common:igmp-version;
}
default "vpn-common:igmpv2";
description
"Indicates the IGMP version.";
}
uses vpn-common:service-status;
}
container mld {
when "../protocol-type = 'host' and "
+ "../address-family = 'vpn-common:ipv6' "
+ "or 'vpn-common:dual-stack'";
if-feature "vpn-common:mld";
description
"Includes MLD-related parameters.";
list static-group {
key "group-addr";
description
"Multicast static source/group associated
with the MLD session.";
leaf group-addr {
type rt-types:ipv6-multicast-group-address;
description
"Multicast group IPv6 address.";
}
leaf source-addr {
type
rt-types:ipv6-multicast-source-address;
description
"Multicast source IPv6 address.";
}
}
leaf max-groups {
type uint32;
description
"Indicates the maximum number of
groups.";
}
leaf max-entries {
type uint32;
description
"Indicates the maximum number of MLD
entries.";
}
leaf max-group-sources {
type uint32;
description
"The maximum number of group sources.";
}
leaf version {
type identityref {
base vpn-common:mld-version;
}
default "vpn-common:mldv2";
description
"Indicates the MLD protocol version.";
}
uses vpn-common:service-status;
}
container pim {
when "../protocol-type = 'router'";
if-feature "vpn-common:pim";
description
"Only applies when the protocol type is
'pim'.";
leaf hello-interval {
type rt-types:timer-value-seconds16;
default "30";
description
"Interval between PIM Hello messages.
If set to 'infinity' or 'not-set',
no periodic Hello messages are sent.";
reference
"RFC 7761: Protocol Independent
Multicast - Sparse Mode
(PIM-SM): Protocol
Specification (Revised),
Section 4.11
RFC 8294: Common YANG Data Types for
the Routing Area";
}
leaf dr-priority {
type uint32;
default "1";
description
"Indicates the preference associated
with the DR election process. A larger
value has a higher priority over a
smaller value.";
reference
"RFC 7761: Protocol Independent
Multicast - Sparse Mode
(PIM-SM): Protocol
Specification (Revised),
Section 4.3.2";
}
uses vpn-common:service-status;
}
}
}
}
}
}
}
}
}
}
}
Security ConsiderationsThe YANG module specified in this document defines a schema for data
that is designed to be accessed via network management protocols such
as NETCONF or RESTCONF .
The lowest NETCONF layer is the secure transport layer, and the
mandatory-to-implement secure transport is Secure Shell (SSH)
. The lowest RESTCONF layer is HTTPS, and the
mandatory-to-implement secure transport is TLS .The Network Configuration Access Control Model (NACM)
provides the means to restrict access for particular NETCONF or RESTCONF users
to a preconfigured subset of all available NETCONF or RESTCONF protocol
operations and content.There are a number of data nodes defined in this YANG module that are
writable/creatable/deletable (i.e., config true, which is the default). These
data nodes may be considered sensitive or vulnerable in some network
environments. Write operations (e.g., edit-config) and delete operations to these data nodes without
proper protection or authentication can have a negative effect on network operations. These are
the subtrees and data nodes and their sensitivity/vulnerability in
the "ietf-l3vpn-ntw" module:
'vpn-profiles':
This container includes a set of sensitive data
that influence how the L3VPN service is delivered. For example, an
attacker who has access to these data nodes may be able to
manipulate routing policies, QoS policies, or encryption properties.
These data nodes are defined with "nacm:default-deny-write" tagging
.
'vpn-services':
An attacker who is able to access network nodes
can undertake various attacks, such as deleting a running L3VPN
service, interrupting all the traffic of a client. In addition, an
attacker may modify the attributes of a running service (e.g., QoS,
bandwidth, routing protocols, keying material), leading to
malfunctioning of the service and therefore to Service Level Agreement (SLA) violations. In
addition, an attacker could attempt to create an L3VPN service or
add a new network access. In addition to using NACM to prevent
unauthorized access, such activity can be detected by adequately
monitoring and tracking network configuration changes.
Some of the readable data nodes in this YANG module may be considered
sensitive or vulnerable in some network environments. It is thus important to
control read access (e.g., via get, get-config, or notification) to these data
nodes. These are the subtrees and data nodes and their
sensitivity/vulnerability:
'customer-name' and 'ip-connection':
An attacker can retrieve
privacy-related information, which can be used to track a customer.
Disclosing such information may be considered a violation of the
customer-provider trust relationship.
'keying-material':
An attacker can retrieve the cryptographic
keys protecting the underlying VPN service (CE-PE routing, in
particular). These keys could be used to inject spoofed routing
advertisements.
Several data nodes ('bgp', 'ospf', 'isis', 'rip', and 'bfd') rely
upon for authentication purposes.
Therefore, this module inherits the security considerations discussed in
. Also, these data nodes
support supplying explicit keys as strings in ASCII format. The use of
keys in hexadecimal string format would afford greater key entropy with
the same number of key-string octets. However, such a format is not
included in this version of the L3NM, because it is not supported by the
underlying device modules (e.g., ).As discussed in , the module supports MD5
to basically accommodate the installed BGP base. MD5 suffers from the
security weaknesses discussed in and . describes best current practices to be
considered in VPNs making use of NTP. Moreover, a mechanism to provide
cryptographic security for NTP is specified in .IANA ConsiderationsIANA has registered the following URI in the "ns"
subregistry within the "IETF XML Registry" :
URI:
urn:ietf:params:xml:ns:yang:ietf-l3vpn-ntw
Registrant Contact:
The IESG.
XML:
N/A; the requested URI is an XML namespace.
IANA has registered the following YANG module in
the "YANG Module Names" subregistry
within the "YANG Parameters" registry.
Name:
ietf-l3vpn-ntw
Maintained by IANA?
N
Namespace:
urn:ietf:params:xml:ns:yang:ietf-l3vpn-ntw
Prefix:
l3nm
Reference:
RFC 9182
ReferencesNormative ReferencesInformation technology - Telecommunications and information exchange between systems - 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)ISOISO/IEC 10589:2002Host extensions for IP multicastingThis memo specifies the extensions required of a host implementation of the Internet Protocol (IP) to support multicasting. Recommended procedure for IP multicasting in the Internet. This RFC obsoletes RFCs 998 and 1054. [STANDARDS-TRACK]Use of OSI IS-IS for routing in TCP/IP and dual environmentsThis memo specifies an integrated routing protocol, based on the OSI Intra-Domain IS-IS Routing Protocol, which may be used as an interior gateway protocol (IGP) to support TCP/IP as well as OSI. This allows a single routing protocol to be used to support pure IP environments, pure OSI environments, and dual environments. This specification was developed by the IS-IS working group of the Internet Engineering Task Force. [STANDARDS-TRACK]RIPng for IPv6This document specifies a routing protocol for an IPv6 internet. It is based on protocols and algorithms currently in wide use in the IPv4 Internet [STANDARDS-TRACK]Key words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Internet Group Management Protocol, Version 2This memo documents IGMPv2, used by IP hosts to report their multicast group memberships to routers. It updates STD 5, RFC 1112. [STANDARDS-TRACK]RIP Version 2This document specifies an extension of the Routing Information Protocol (RIP) to expand the amount of useful information carried in RIP messages and to add a measure of security. [STANDARDS-TRACK]Multicast Listener Discovery (MLD) for IPv6This document specifies the protocol used by an IPv6 router to discover the presence of multicast listeners (that is, nodes wishing to receive multicast packets) on its directly attached links, and to discover specifically which multicast addresses are of interest to those neighboring nodes. [STANDARDS-TRACK]Internet Group Management Protocol, Version 3The IETF XML RegistryThis document describes an IANA maintained registry for IETF standards which use Extensible Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Description Framework (RDF) Schemas.Multicast Listener Discovery Version 2 (MLDv2) for IPv6This document updates RFC 2710, and it specifies Version 2 of the ulticast Listener Discovery Protocol (MLDv2). MLD is used by an IPv6 router to discover the presence of multicast listeners on directly attached links, and to discover which multicast addresses are of interest to those neighboring nodes. MLDv2 is designed to be interoperable with MLDv1. MLDv2 adds the ability for a node to report interest in listening to packets with a particular multicast address only from specific source addresses or from all sources except for specific source addresses. [STANDARDS-TRACK]A Border Gateway Protocol 4 (BGP-4)This document discusses the Border Gateway Protocol (BGP), which is an inter-Autonomous System routing protocol.The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems (ASes) that reachability information traverses. This information is sufficient for constructing a graph of AS connectivity for this reachability from which routing loops may be pruned, and, at the AS level, some policy decisions may be enforced.BGP-4 provides a set of mechanisms for supporting Classless Inter-Domain Routing (CIDR). These mechanisms include support for advertising a set of destinations as an IP prefix, and eliminating the concept of network "class" within BGP. BGP-4 also introduces mechanisms that allow aggregation of routes, including aggregation of AS paths.This document obsoletes RFC 1771. [STANDARDS-TRACK]BGP/MPLS IP Virtual Private Networks (VPNs)This document describes a method by which a Service Provider may use an IP backbone to provide IP Virtual Private Networks (VPNs) for its customers. This method uses a "peer model", in which the customers' edge routers (CE routers) send their routes to the Service Provider's edge routers (PE routers); there is no "overlay" visible to the customer's routing algorithm, and CE routers at different sites do not peer with each other. Data packets are tunneled through the backbone, so that the core routers do not need to know the VPN routes. [STANDARDS-TRACK]Authentication/Confidentiality for OSPFv3This document describes means and mechanisms to provide authentication/confidentiality to OSPFv3 using an IPv6 Authentication Header/Encapsulating Security Payload (AH/ESP) extension header. [STANDARDS-TRACK]OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)Many Service Providers offer Virtual Private Network (VPN) services to their customers, using a technique in which customer edge routers (CE routers) are routing peers of provider edge routers (PE routers). The Border Gateway Protocol (BGP) is used to distribute the customer's routes across the provider's IP backbone network, and Multiprotocol Label Switching (MPLS) is used to tunnel customer packets across the provider's backbone. This is known as a "BGP/MPLS IP VPN". The base specification for BGP/MPLS IP VPNs presumes that the routing protocol on the interface between a PE router and a CE router is BGP. This document extends that specification by allowing the routing protocol on the PE/CE interface to be the Open Shortest Path First (OSPF) protocol.This document updates RFC 4364. [STANDARDS-TRACK]Routing IPv6 with IS-ISThis document specifies a method for exchanging IPv6 routing information using the IS-IS routing protocol. The described method utilizes two new TLVs: a reachability TLV and an interface address TLV to distribute the necessary IPv6 information throughout a routing domain. Using this method, one can route IPv6 along with IPv4 and OSI using a single intra-domain routing protocol. [STANDARDS-TRACK]IPv6 Address Specific BGP Extended Community AttributeCurrent specifications of BGP Extended Communities (RFC 4360) support the IPv4 Address Specific Extended Community, but do not support an IPv6 Address Specific Extended Community. The lack of an IPv6 Address Specific Extended Community may be a problem when an application uses the IPv4 Address Specific Extended Community, and one wants to use this application in a pure IPv6 environment. This document defines a new BGP attribute, the IPv6 Address Specific Extended Community, that addresses this problem. The IPv6 Address Specific Extended Community is similar to the IPv4 Address Specific Extended Community, except that it carries an IPv6 address rather than an IPv4 address. [STANDARDS TRACK]OSPFv2 HMAC-SHA Cryptographic AuthenticationThis document describes how the National Institute of Standards and Technology (NIST) Secure Hash Standard family of algorithms can be used with OSPF version 2's built-in, cryptographic authentication mechanism. This updates, but does not supercede, the cryptographic authentication mechanism specified in RFC 2328. [STANDARDS-TRACK]Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6This memo defines the Virtual Router Redundancy Protocol (VRRP) for IPv4 and IPv6. It is version three (3) of the protocol, and it is based on VRRP (version 2) for IPv4 that is defined in RFC 3768 and in "Virtual Router Redundancy Protocol for IPv6". VRRP specifies an election protocol that dynamically assigns responsibility for a virtual router to one of the VRRP routers on a LAN. The VRRP router controlling the IPv4 or IPv6 address(es) associated with a virtual router is called the Master, and it forwards packets sent to these IPv4 or IPv6 addresses. VRRP Master routers are configured with virtual IPv4 or IPv6 addresses, and VRRP Backup routers infer the address family of the virtual addresses being carried based on the transport protocol. Within a VRRP router, the virtual routers in each of the IPv4 and IPv6 address families are a domain unto themselves and do not overlap. The election process provides dynamic failover in the forwarding responsibility should the Master become unavailable. For IPv4, the advantage gained from using VRRP is a higher-availability default path without requiring configuration of dynamic routing or router discovery protocols on every end-host. For IPv6, the advantage gained from using VRRP for IPv6 is a quicker switchover to Backup routers than can be obtained with standard IPv6 Neighbor Discovery mechanisms. [STANDARDS-TRACK]Bidirectional Forwarding Detection (BFD)This document describes a protocol intended to detect faults in the bidirectional path between two forwarding engines, including interfaces, data link(s), and to the extent possible the forwarding engines themselves, with potentially very low latency. It operates independently of media, data protocols, and routing protocols. [STANDARDS-TRACK]Network Time Protocol Version 4: Protocol and Algorithms SpecificationThe Network Time Protocol (NTP) is widely used to synchronize computer clocks in the Internet. This document describes NTP version 4 (NTPv4), which is backwards compatible with NTP version 3 (NTPv3), described in RFC 1305, as well as previous versions of the protocol. NTPv4 includes a modified protocol header to accommodate the Internet Protocol version 6 address family. NTPv4 includes fundamental improvements in the mitigation and discipline algorithms that extend the potential accuracy to the tens of microseconds with modern workstations and fast LANs. It includes a dynamic server discovery scheme, so that in many cases, specific server configuration is not required. It corrects certain errors in the NTPv3 design and implementation and includes an optional extension mechanism. [STANDARDS-TRACK]The TCP Authentication OptionThis document specifies the TCP Authentication Option (TCP-AO), which obsoletes the TCP MD5 Signature option of RFC 2385 (TCP MD5). TCP-AO specifies the use of stronger Message Authentication Codes (MACs), protects against replays even for long-lived TCP connections, and provides more details on the association of security with TCP connections than TCP MD5. TCP-AO is compatible with either a static Master Key Tuple (MKT) configuration or an external, out-of-band MKT management mechanism; in either case, TCP-AO also protects connections when using the same MKT across repeated instances of a connection, using traffic keys derived from the MKT, and coordinates MKT changes between endpoints. The result is intended to support current infrastructure uses of TCP MD5, such as to protect long-lived connections (as used, e.g., in BGP and LDP), and to support a larger set of MACs with minimal other system and operational changes. TCP-AO uses a different option identifier than TCP MD5, even though TCP-AO and TCP MD5 are never permitted to be used simultaneously. TCP-AO supports IPv6, and is fully compatible with the proposed requirements for the replacement of TCP MD5. [STANDARDS-TRACK]YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK]Network Configuration Protocol (NETCONF)The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK]Using the NETCONF Protocol over Secure Shell (SSH)This document describes a method for invoking and running the Network Configuration Protocol (NETCONF) within a Secure Shell (SSH) session as an SSH subsystem. This document obsoletes RFC 4742. [STANDARDS-TRACK]Multicast in MPLS/BGP IP VPNsIn order for IP multicast traffic within a BGP/MPLS IP VPN (Virtual Private Network) to travel from one VPN site to another, special protocols and procedures must be implemented by the VPN Service Provider. These protocols and procedures are specified in this document. [STANDARDS-TRACK]BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNsThis document describes the BGP encodings and procedures for exchanging the information elements required by Multicast in MPLS/BGP IP VPNs, as specified in RFC 6513. [STANDARDS-TRACK]OSPFv3 as a Provider Edge to Customer Edge (PE-CE) Routing ProtocolMany Service Providers (SPs) offer Virtual Private Network (VPN) services to their customers using a technique in which Customer Edge (CE) routers are routing peers of Provider Edge (PE) routers. The Border Gateway Protocol (BGP) is used to distribute the customer's routes across the provider's IP backbone network, and Multiprotocol Label Switching (MPLS) is used to tunnel customer packets across the provider's backbone. Support currently exists for both IPv4 and IPv6 VPNs; however, only Open Shortest Path First version 2 (OSPFv2) as PE-CE protocol is specified. This document extends those specifications to support OSPF version 3 (OSPFv3) as a PE-CE routing protocol. The OSPFv3 PE-CE functionality is identical to that of OSPFv2 except for the differences described in this document. [STANDARDS-TRACK]Common YANG Data TypesThis document introduces a collection of common data types to be used with the YANG data modeling language. This document obsoletes RFC 6021.Supporting Authentication Trailer for OSPFv3Currently, OSPF for IPv6 (OSPFv3) uses IPsec as the only mechanism for authenticating protocol packets. This behavior is different from authentication mechanisms present in other routing protocols (OSPFv2, Intermediate System to Intermediate System (IS-IS), RIP, and Routing Information Protocol Next Generation (RIPng)). In some environments, it has been found that IPsec is difficult to configure and maintain and thus cannot be used. This document defines an alternative mechanism to authenticate OSPFv3 protocol packets so that OSPFv3 does not depend only upon IPsec for authentication.The OSPFv3 Authentication Trailer was originally defined in RFC 6506. This document obsoletes RFC 6506 by providing a revised definition, including clarifications and refinements of the procedures.Security Extension for OSPFv2 When Using Manual Key ManagementThe current OSPFv2 cryptographic authentication mechanism as defined in RFCs 2328 and 5709 is vulnerable to both inter-session and intra- session replay attacks when using manual keying. Additionally, the existing cryptographic authentication mechanism does not cover the IP header. This omission can be exploited to carry out various types of attacks.This document defines changes to the authentication sequence number mechanism that will protect OSPFv2 from both inter-session and intra- session replay attacks when using manual keys for securing OSPFv2 protocol packets. Additionally, we also describe some changes in the cryptographic hash computation that will eliminate attacks resulting from OSPFv2 not protecting the IP header.Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)This document specifies Protocol Independent Multicast - Sparse Mode (PIM-SM). PIM-SM is a multicast routing protocol that can use the underlying unicast routing information base or a separate multicast-capable routing information base. It builds unidirectional shared trees rooted at a Rendezvous Point (RP) per group, and it optionally creates shortest-path trees per source.This document obsoletes RFC 4601 by replacing it, addresses the errata filed against it, removes the optional (*,*,RP), PIM Multicast Border Router features and authentication using IPsec that lack sufficient deployment experience (see Appendix A), and moves the PIM specification to Internet Standard.The YANG 1.1 Data Modeling LanguageYANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols. This document describes the syntax and semantics of version 1.1 of the YANG language. YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification. There are a small number of backward incompatibilities from YANG version 1. This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF).RESTCONF ProtocolThis document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol (NETCONF).Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.YANG Data Model for Key ChainsThis document describes the key chain YANG data model. Key chains are commonly used for routing protocol authentication and other applications requiring symmetric keys. A key chain is a list containing one or more elements containing a Key ID, key string, send/accept lifetimes, and the associated authentication or encryption algorithm. By properly overlapping the send and accept lifetimes of multiple key chain elements, key strings and algorithms may be gracefully updated. By representing them in a YANG data model, key distribution can be automated.Common YANG Data Types for the Routing AreaThis document defines a collection of common data types using the YANG data modeling language. These derived common types are designed to be imported by other modules defined in the routing area.Network Configuration Access Control ModelThe standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) or the RESTCONF protocol requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF or RESTCONF protocol access for particular users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. This document defines such an access control model.This document obsoletes RFC 6536.A YANG Data Model for Interface ManagementThis document defines a YANG data model for the management of network interfaces. It is expected that interface-type-specific data models augment the generic interfaces data model defined in this document. The data model includes definitions for configuration and system state (status information and counters for the collection of statistics).The YANG data model in this document conforms to the Network Management Datastore Architecture (NMDA) defined in RFC 8342.This document obsoletes RFC 7223.The Transport Layer Security (TLS) Protocol Version 1.3This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.A YANG Data Model for Layer 2 Virtual Private Network (L2VPN) Service DeliveryThis document defines a YANG data model that can be used to configure a Layer 2 provider-provisioned VPN service. It is up to a management system to take this as an input and generate specific configuration models to configure the different network elements to deliver the service. How this configuration of network elements is done is out of scope for this document.The YANG data model defined in this document includes support for point-to-point Virtual Private Wire Services (VPWSs) and multipoint Virtual Private LAN Services (VPLSs) that use Pseudowires signaled using the Label Distribution Protocol (LDP) and the Border Gateway Protocol (BGP) as described in RFCs 4761 and 6624.The YANG data model defined in this document conforms to the Network Management Datastore Architecture defined in RFC 8342.YANG Data Model for Network Access Control Lists (ACLs)This document defines a data model for Access Control Lists (ACLs). An ACL is a user-ordered set of rules used to configure the forwarding behavior in a device. Each rule is used to find a match on a packet and define actions that will be performed on the packet.A Common YANG Data Model for Layer 2 and Layer 3 VPNsInformative ReferencesBGP YANG Model for Service Provider NetworksKloud ServicesArrcusHuaweiJuniper Networks This document defines a YANG data model for configuring and managing
BGP, including protocol, policy, and operational aspects, such as
RIB, based on data center, carrier, and content provider operational
requirements.
Work in ProgressA Framework for Enhanced Virtual Private Network (VPN+) ServicesHuaweiUniversity of SurreyChina MobileKDDI CorporationSamsung This document describes the framework for Enhanced Virtual Private
Network (VPN+) services. The purpose of enhanced VPNs is to support
the needs of new applications, particularly applications that are
associated with 5G services, by utilizing an approach that is based
on existing VPN and Traffic Engineering (TE) technologies and adds
characteristics that specific services require over those provided by
traditional VPNs.
Typically, VPN+ will be used to underpin network slicing, but could
also be of use in its own right providing enhanced connectivity
services between customer sites.
It is envisaged that enhanced VPNs will be delivered using a
combination of existing, modified, and new networking technologies.
This document provides an overview of relevant technologies and
identifies some areas for potential new work.
Work in Progress802.1AX-2020 - IEEE Standard for Local and Metropolitan Area Networks--Link AggregationIEEEIEEE Std 802.1AX-2020Framework for IETF Network SlicesWork in ProgressA YANG Data Model for Protocol Independent Multicast (PIM)Work in Progresspyangcommit 524cf61A YANG Data Model for Quality of Service (QoS)Cisco SystemsVMwareJuniper NetworksThe MITRE Corporation This document describes a YANG Data model for Quality of Service
(QoS) configuration in network devices. This document doesn't
describe QoS statistics counters.
Work in ProgressMulticast Source Discovery Protocol (MSDP)The Multicast Source Discovery Protocol (MSDP) describes a mechanism to connect multiple IP Version 4 Protocol Independent Multicast Sparse-Mode (PIM-SM) domains together. Each PIM-SM domain uses its own independent Rendezvous Point (RP) and does not have to depend on RPs in other domains. This document reflects existing MSDP implementations.Policy Quality of Service (QoS) Information ModelThis document presents an object-oriented information model for representing Quality of Service (QoS) network management policies. This document is based on the IETF Policy Core Information Model and its extensions. It defines an information model for QoS enforcement for differentiated and integrated services using policy. It is important to note that this document defines an information model, which by definition is independent of any particular data storage mechanism and access protocol.Provider Provisioned Virtual Private Network (VPN) TerminologyThe widespread interest in provider-provisioned Virtual Private Network (VPN) solutions lead to memos proposing different and overlapping solutions. The IETF working groups (first Provider Provisioned VPNs and later Layer 2 VPNs and Layer 3 VPNs) have discussed these proposals and documented specifications. This has lead to the development of a partially new set of concepts used to describe the set of VPN services. To a certain extent, more than one term covers the same concept, and sometimes the same term covers more than one concept. This document seeks to make the terminology in the area clearer and more intuitive. This memo provides information for the Internet community.A Framework for Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs)This document provides a framework for Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs). This framework is intended to aid in the standardization of protocols and mechanisms for support of layer 3 PPVPNs. It is the intent of this document to produce a coherent description of the significant technical issues that are important in the design of layer 3 PPVPN solutions. Selection of specific approaches, making choices regarding engineering tradeoffs, and detailed protocol specification, are outside of the scope of this framework document. This memo provides information for the Internet community.Framework for Layer 3 Virtual Private Networks (L3VPN) Operations and ManagementThis document provides a framework for the operation and management of Layer 3 Virtual Private Networks (L3VPNs). This framework intends to produce a coherent description of the significant technical issues that are important in the design of L3VPN management solutions. The selection of specific approaches, and making choices among information models and protocols are outside the scope of this document. This memo provides information for the Internet community.IPv6 Stateless Address AutoconfigurationThis document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6. The autoconfiguration process includes generating a link-local address, generating global addresses via stateless address autoconfiguration, and the Duplicate Address Detection procedure to verify the uniqueness of the addresses on a link. [STANDARDS-TRACK]Cisco Systems' Solution for Multicast in BGP/MPLS IP VPNsThis document describes the MVPN (Multicast in BGP/MPLS IP VPNs) solution designed and deployed by Cisco Systems. The procedures specified in this document are largely a subset of the generalized MVPN framework recently standardized by the IETF. However, as the deployment of the procedures specified herein predates the publication of IETF standards (in some cases by over five years), an implementation based on these procedures differs in some respects from a fully standards-compliant implementation. These differences are pointed out in the document. This document defines a Historic Document for the Internet community.Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 AlgorithmsThis document updates the security considerations for the MD5 message digest algorithm. It also updates the security considerations for HMAC-MD5. This document is not an Internet Standards Track specification; it is published for informational purposes.Analysis of BGP, LDP, PCEP, and MSDP Issues According to the Keying and Authentication for Routing Protocols (KARP) Design GuideThis document analyzes TCP-based routing protocols, the Border Gateway Protocol (BGP), the Label Distribution Protocol (LDP), the Path Computation Element Communication Protocol (PCEP), and the Multicast Source Distribution Protocol (MSDP), according to guidelines set forth in Section 4.2 of "Keying and Authentication for Routing Protocols Design Guidelines", RFC 6518.Software-Defined Networking: A Perspective from within a Service Provider EnvironmentSoftware-Defined Networking (SDN) has been one of the major buzz words of the networking industry for the past couple of years. And yet, no clear definition of what SDN actually covers has been broadly admitted so far. This document aims to clarify the SDN landscape by providing a perspective on requirements, issues, and other considerations about SDN, as seen from within a service provider environment.It is not meant to endlessly discuss what SDN truly means but rather to suggest a functional taxonomy of the techniques that can be used under an SDN umbrella and to elaborate on the various pending issues the combined activation of such techniques inevitably raises. As such, a definition of SDN is only mentioned for the sake of clarification.IP Connectivity Provisioning Profile (CPP)This document describes the Connectivity Provisioning Profile (CPP) and proposes a CPP template to capture IP/MPLS connectivity requirements to be met within a service delivery context (e.g., Voice over IP or IP TV). The CPP defines the set of IP transfer parameters to be supported by the underlying transport network together with a reachability scope and bandwidth/capacity needs. Appropriate performance metrics, such as one-way delay or one-way delay variation, are used to characterize an IP transfer service. Both global and restricted reachability scopes can be captured in the CPP.Such a generic CPP template is meant to (1) facilitate the automation of the service negotiation and activation procedures, thus accelerating service provisioning, (2) set (traffic) objectives of Traffic Engineering functions and service management functions, and (3) improve service and network management systems with 'decision- making' capabilities based upon negotiated/offered CPPs.Software-Defined Networking (SDN): Layers and Architecture TerminologySoftware-Defined Networking (SDN) refers to a new approach for network programmability, that is, the capacity to initialize, control, change, and manage network behavior dynamically via open interfaces. SDN emphasizes the role of software in running networks through the introduction of an abstraction for the data forwarding plane and, by doing so, separates it from the control plane. This separation allows faster innovation cycles at both planes as experience has already shown. However, there is increasing confusion as to what exactly SDN is, what the layer structure is in an SDN architecture, and how layers interface with each other. This document, a product of the IRTF Software-Defined Networking Research Group (SDNRG), addresses these questions and provides a concise reference for the SDN research community based on relevant peer-reviewed literature, the RFC series, and relevant documents by other standards organizations.Seamless Bidirectional Forwarding Detection (S-BFD)This document defines Seamless Bidirectional Forwarding Detection (S-BFD), a simplified mechanism for using BFD with a large proportion of negotiation aspects eliminated, thus providing benefits such as quick provisioning, as well as improved control and flexibility for network nodes initiating path monitoring.This document updates RFC 5880.Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)Layer 2 services (such as Frame Relay, Asynchronous Transfer Mode, and Ethernet) can be emulated over an MPLS backbone by encapsulating the Layer 2 Protocol Data Units (PDUs) and then transmitting them over pseudowires (PWs). It is also possible to use pseudowires to provide low-rate Time-Division Multiplexed and Synchronous Optical NETworking circuit emulation over an MPLS-enabled network. This document specifies a protocol for establishing and maintaining the pseudowires, using extensions to the Label Distribution Protocol (LDP). Procedures for encapsulating Layer 2 PDUs are specified in other documents.This document is a rewrite of RFC 4447 for publication as an Internet Standard.Using BGP to Bind MPLS Labels to Address PrefixesThis document specifies a set of procedures for using BGP to advertise that a specified router has bound a specified MPLS label (or a specified sequence of MPLS labels organized as a contiguous part of a label stack) to a specified address prefix. This can be done by sending a BGP UPDATE message whose Network Layer Reachability Information field contains both the prefix and the MPLS label(s) and whose Next Hop field identifies the node at which said prefix is bound to said label(s). This document obsoletes RFC 3107.YANG Data Model for L3VPN Service DeliveryThis document defines a YANG data model that can be used for communication between customers and network operators and to deliver a Layer 3 provider-provisioned VPN service. This document is limited to BGP PE-based VPNs as described in RFCs 4026, 4110, and 4364. This model is intended to be instantiated at the management system to deliver the overall service. It is not a configuration model to be used directly on network elements. This model provides an abstracted view of the Layer 3 IP VPN service configuration components. It will be up to the management system to take this model as input and use specific configuration models to configure the different network elements to deliver the service. How the configuration of network elements is done is out of scope for this document.This document obsoletes RFC 8049; it replaces the unimplementable module in that RFC with a new module with the same name that is not backward compatible. The changes are a series of small fixes to the YANG module and some clarifications to the text.Service Models ExplainedThe IETF has produced many modules in the YANG modeling language. The majority of these modules are used to construct data models to model devices or monolithic functions.A small number of YANG modules have been defined to model services (for example, the Layer 3 Virtual Private Network Service Model (L3SM) produced by the L3SM working group and documented in RFC 8049).This document describes service models as used within the IETF and also shows where a service model might fit into a software-defined networking architecture. Note that service models do not make any assumption of how a service is actually engineered and delivered for a customer; details of how network protocols and devices are engineered to deliver a service are captured in other modules that are not exposed through the interface between the customer and the provider.YANG Tree DiagramsThis document captures the current syntax used in YANG module tree diagrams. The purpose of this document is to provide a single location for this definition. This syntax may be updated from time to time based on the evolution of the YANG language.Network Management Datastore Architecture (NMDA)Datastores are a fundamental concept binding the data models written in the YANG data modeling language to network management protocols such as the Network Configuration Protocol (NETCONF) and RESTCONF. This document defines an architectural framework for datastores based on the experience gained with the initial simpler model, addressing requirements that were not well supported in the initial model. This document updates RFC 7950.A YANG Data Model for Network TopologiesThis document defines an abstract (generic, or base) YANG data model for network/service topologies and inventories. The data model serves as a base model that is augmented with technology-specific details in other, more specific topology and inventory data models.A YANG Data Model for Routing Management (NMDA Version)This document specifies three YANG modules and one submodule. Together, they form the core routing data model that serves as a framework for configuring and managing a routing subsystem. It is expected that these modules will be augmented by additional YANG modules defining data models for control-plane protocols, route filters, and other functions. The core routing data model provides common building blocks for such extensions -- routes, Routing Information Bases (RIBs), and control-plane protocols.The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA). This document obsoletes RFC 8022.Framework for Abstraction and Control of TE Networks (ACTN)Traffic Engineered (TE) networks have a variety of mechanisms to facilitate the separation of the data plane and control plane. They also have a range of management and provisioning protocols to configure and activate network resources. These mechanisms represent key technologies for enabling flexible and dynamic networking. The term "Traffic Engineered network" refers to a network that uses any connection-oriented technology under the control of a distributed or centralized control plane to support dynamic provisioning of end-to- end connectivity.Abstraction of network resources is a technique that can be applied to a single network domain or across multiple domains to create a single virtualized network that is under the control of a network operator or the customer of the operator that actually owns the network resources.This document provides a framework for Abstraction and Control of TE Networks (ACTN) to support virtual network services and connectivity services.A YANG Module for Network Address Translation (NAT) and Network Prefix Translation (NPT)This document defines a YANG module for the Network Address Translation (NAT) function.Network Address Translation from IPv4 to IPv4 (NAT44), Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers (NAT64), customer-side translator (CLAT), Stateless IP/ICMP Translation (SIIT), Explicit Address Mappings (EAM) for SIIT, IPv6-to-IPv6 Network Prefix Translation (NPTv6), and Destination NAT are covered in this document.Network Time Protocol Best Current PracticesThe Network Time Protocol (NTP) is one of the oldest protocols on the Internet and has been widely used since its initial publication. This document is a collection of best practices for the general operation of NTP servers and clients on the Internet. It includes recommendations for the stable, accurate, and secure operation of NTP infrastructure. This document is targeted at NTP version 4 as described in RFC 5905.A YANG Data Model for the Routing Information Protocol (RIP)This document describes a data model for the management of the Routing Information Protocol (RIP). Both RIP version 2 and RIPng are covered. The data model includes definitions for configuration, operational state, and Remote Procedure Calls (RPCs).The YANG data model in this document conforms to the Network Management Datastore Architecture (NMDA).Handling Long Lines in Content of Internet-Drafts and RFCsThis document defines two strategies for handling long lines in width-bounded text content. One strategy, called the "single backslash" strategy, is based on the historical use of a single backslash ('\') character to indicate where line-folding has occurred, with the continuation occurring with the first character that is not a space character (' ') on the next line. The second strategy, called the "double backslash" strategy, extends the first strategy by adding a second backslash character to identify where the continuation begins and is thereby able to handle cases not supported by the first strategy. Both strategies use a self-describing header enabling automated reconstitution of the original content.Network Time Security for the Network Time ProtocolThis memo specifies Network Time Security (NTS), a mechanism for using Transport Layer Security (TLS) and Authenticated Encryption with Associated Data (AEAD) to provide cryptographic security for the client-server mode of the Network Time Protocol (NTP). NTS is structured as a suite of two loosely coupled sub-protocols. The first (NTS Key Establishment (NTS-KE)) handles initial authentication and key establishment over TLS. The second (NTS Extension Fields for NTPv4) handles encryption and authentication during NTP time synchronization via extension fields in the NTP packets, and holds all required state only on the client via opaque cookies.A Framework for Automating Service and Network Management with YANGData models provide a programmatic approach to represent services and networks. Concretely, they can be used to derive configuration information for network and service components, and state information that will be monitored and tracked. Data models can be used during the service and network management life cycle (e.g., service instantiation, service provisioning, service optimization, service monitoring, service diagnosing, and service assurance). Data models are also instrumental in the automation of network management, and they can provide closed-loop control for adaptive and deterministic service creation, delivery, and maintenance.This document describes a framework for service and network management automation that takes advantage of YANG modeling technologies. This framework is drawn from a network operator perspective irrespective of the origin of a data model; thus, it can accommodate YANG modules that are developed outside the IETF.IP Prefix Advertisement in Ethernet VPN (EVPN)The BGP MPLS-based Ethernet VPN (EVPN) (RFC 7432) mechanism provides a flexible control plane that allows intra-subnet connectivity in an MPLS and/or Network Virtualization Overlay (NVO) (RFC 7365) network. In some networks, there is also a need for dynamic and efficient inter-subnet connectivity across Tenant Systems and end devices that can be physical or virtual and do not necessarily participate in dynamic routing protocols. This document defines a new EVPN route type for the advertisement of IP prefixes and explains some use-case examples where this new route type is used.YANG Data Model for Composed VPN Service DeliveryWork in ProgressA Network YANG Model for Service Attachment PointsWork in ProgressL3VPN Examples4G VPN Provisioning ExampleL3VPNs are widely used to deploy 3G/4G, fixed, and enterprise
services, mainly because several traffic discrimination policies can be
applied within the network to deliver to the mobile customers a
service that meets the SLA requirements.Typically, and as shown in ,
an eNodeB (CE) is directly connected to the access routers
of the mobile backhaul and their logical interfaces (one or many,
according to the service type) are configured in a VPN that transports
the packets to the mobile core platforms. In this example, a
'vpn-node' is created with two 'vpn-network-accesses'.To create an L3VPN service using the L3NM, the following steps can
be followed.First, create the 4G VPN service ().Second, create a VPN node, as depicted in . In this type of service, the VPN node
is equivalent to VRF configured in the physical device
('ne-id'=198.51.100.1). NOTE: '\' line wrapping in Figures and is implemented per .Finally, two VPN network accesses are created using the same
physical port ('interface-id'=1/1/1). Each 'vpn-network-access' has a
particular VLAN interface (1,2): "SYNC" and "DATA" (). These interfaces differentiate the traffic between them.Loopback InterfaceAn example of a loopback interface is depicted in .Overriding VPN Instance Profile Parameters shows a simplified example to
illustrate how some information that is provided at the VPN service
level (particularly as part of the 'vpn-instance-profiles') can be
overridden by information configured at the VPN node level. In this
example, PE3 and PE4 inherit the 'vpn-instance-profiles' parameters
that are specified at the VPN service level, but PE1 and PE2 are
provided with "maximum-routes" values at the VPN node level that
override the values that are specified at the VPN service level.Multicast VPN Provisioning ExampleIPTV is mainly distributed through multicast over the LANs. In the
following example, PIM - Sparse Mode (PIM-SM) is enabled and functional between the PE and
the CE. The PE receives multicast traffic from a CE that is directly
connected to the multicast source. The signaling between the PE and the CE is
achieved using BGP. Also, the RP is statically configured for a multicast
group. illustrates how to configure a
multicast L3VPN service using the L3NM.First, the multicast service is created together with a generic VPN
instance profile (see the excerpt of the request message body shown in
).Then, the VPN nodes are created (see the excerpt of the request
message body shown in ). In this
example, the VPN node will represent VRF configured in the physical
device.Finally, create the VPN network access with multicast enabled (see
the excerpt of the request message body shown in ).AcknowledgementsDuring the discussions of this work, helpful comments, suggestions,
and reviews were received from (listed alphabetically) ,
, , , , , , , , , and . Many thanks to them. Thanks to for
the review of an early draft version of the document., , , and
contributed to early draft versions of this document. Many thanks to for the AD review. Thanks to for the routing directorate
review, for the security directorate review,
for the opsdir review, and for the genart directorate
review. Thanks to for the discussion on the TCP-AO. Thanks to , , , , , , ,
and for the IESG review.This work was supported in part by the European Commission-funded
H2020-ICT-2016-2 METRO-HAUL project (G.A. 761727) and Horizon 2020
Secured autonomic traffic management for a Tera of SDN flows (Teraflow)
project (G.A. 101015857).ContributorsNokiaMadridSpainvictor.lopez@nokia.comHuaweibill.wu@huawei.comVodafoneSpainmanuel-julian.lopez@vodafone.comTelefonicalucia.olivaballega.ext@telefonica.comRibbon Communicationserez.segev@rbbn.comGamma Telecompaul.sherratt@gamma.co.ukAuthors' AddressesTelefonicaMadridSpainsamier.barguilgiraldo.ext@telefonica.comTelefonicaMadridSpainoscar.gonzalezdedios@telefonica.comOrangeRennes35000Francemohamed.boucadair@orange.comVodafoneSpainluis-angel.munoz@vodafone.comNokiaMadridSpainalejandro.aguado_martin@nokia.com