YANG Logical Network ElementsLabN Consulting, L.L.C.lberger@labn.netDeutsche Telekomchopps@chopps.orgCisco Systems301 Midenhall WayCaryNCUSA27513acee@cisco.comivandean@gmail.comJabilXufeng_Liu@jabil.com
This document defines a logical network element module. This module
can be used to manage the
logical resource partitioning that may be present on a
network device. Examples of common industry terms for logical
resource partitioning are Logical Systems or Logical Routers.
This document defines a YANG module to
support the creation of logical network elements on a network
device. A logical network element (LNE) is an independently managed
virtual device made up of resources allocated to it from the host or
parent network device. An LNE running on a host network device
conceptually parallels a virtual machine running on a host system.
Using host-virtualization terminology one could refer to an LNE as
a "Guest", and the containing network-device as the "Host". While
LNEs may be implemented via host-virtualization technologies this
is not a requirement.
This document also defines the necessary augmentations for allocating
host resources to a given LNE. As the interface management model
is the only a module that currently defines
host resources, this document currently defines only a single
augmentation to cover the assignment of interfaces to an LNE. Future
modules that define support for the control of host device resources
are expected to, where appropriate, provide parallel support for the
assignment of controlled resources to LNEs.
As each LNE is an independently managed device, each will have its own
set of YANG modeled data that is independent of the host device and
other LNEs. For example, multiple LNEs may all have their own "Tunnel0"
interface defined which will not conflict with each other and will not
exist in the host's interface model. An LNE will have its own
management interfaces possibly including independent instances of
netconf/restconf/etc servers
to support configuration of their YANG models. As an example of
this independence, an implementation may choose to completely rename
assigned interfaces, so on the host the assigned interface might be
called "Ethernet0/1" while within the LNE it might be called "eth1".
In addition to standard management interfaces, a host device
implementation may support accessing LNE configuration and operational
YANG models directly from the host system. When supported, such access
is accomplished through a yang-schema-mount mount point
under which the root
level LNE YANG models may be accessed.
Examples of vendor terminology for an LNE include logical system or
logical router, and virtual switch, chassis, or fabric.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described
in .
Readers are expected to be familiar with terms and concepts of
YANG and YANG Schema Mount .
This document uses the graphical representation of data models
defined in .
In this document, we consider network devices that support protocols
and functions defined within the IETF Routing Area, e.g, routers,
firewalls, and hosts. Such devices may be physical or virtual, e.g., a
classic router with custom hardware or one residing within a
server-based virtual machine implementing a virtual network function
(VNF). Each device may sub-divide their resources into logical
network elements (LNEs), each of which provides a managed logical
device. Examples of vendor terminology for an LNE include logical
system or logical router, and virtual switch, chassis, or fabric. Each LNE
may also support virtual routing and forwarding (VRF) and virtual
switching instance (VSI) functions, which are referred to below as a
network instances (NIs). This breakdown is represented in
Figure 1.
,'''''''''''''''''''''''''''''''''''''''''''''''.
| Network Device (Physical or Virtual) |
| ..................... ..................... |
| : Logical Network : : Logical Network : |
| : Element : : Element : |
| :+-----+-----+-----+: :+-----+-----+-----+: |
| :| Net | Net | Net |: :| Net | Net | Net |: |
| :|Inst.|Inst.|Inst.|: :|Inst.|Inst.|Inst.|: |
| :+-----+-----+-----+: :+-----+-----+-----+: |
| : | | | | | | : : | | | | | | : |
| :..|.|...|.|...|.|..: :..|.|...|.|...|.|..: |
| | | | | | | | | | | | | |
''''|'|'''|'|'''|'|'''''''''|'|'''|'|'''|'|'''''
| | | | | | | | | | | |
Interfaces Interfaces
Figure 1: Module Element Relationships
A model for LNEs is described in and
the model for NIs is covered in .
The interface management model is an
existing model that is impacted by the definition of LNEs and
network instances. This document and
define augmentations to the interface module to support LNEs
and NIs. Similar elements, although perhaps only for LNEs, may
also need to be included as part of the definition of the
future hardware and QoS modules.
Interfaces are a crucial part of any network device's
configuration and operational state. They generally include a
combination of raw physical interfaces, link-layer interfaces,
addressing configuration, and logical interfaces that may not
be tied to any physical interface. Several system services,
and layer 2 and layer 3 protocols may also associate
configuration or operational state data with different types of
interfaces (these relationships are not shown for simplicity).
The interface management model is defined by .
The logical-network-element module
augments existing interface management model by adding an
identifier which is used on physical interface types to
identify an associated LNE.
The interface related augmentation is as follows:
module: ietf-logical-network-element
augment /if:interfaces/if:interface:
+--rw bind-lne-name? ->
/logical-network-elements/logical-network-element/name
The interface model defined in is
structured to include all interfaces in a flat list, without
regard to logical assignment of resources supported
on the device. The bind-lne-name and
leaf provides the association
between an interface and its associated LNE. Note that as currently
defined, to assign an interface to both an LNE and NI, the interface
would first be assigned to the LNE and then within that LNE's
interface module, the LNE's representation of that interface would be
assigned to an NI using the mechanisms defined in .
Logical network elements support the ability of some
devices to partition resources into independent logical routers
and/or switches. Device support for multiple logical network
elements is implementation specific. Systems without such
capabilities need not include support for the
logical-network-element module. In physical devices, some
hardware features are shared across partitions, but control
plane (e.g., routing) protocol instances, tables, and
configuration are managed separately. For example, in logical
routers or VNFs, this may correspond to establishing multiple
logical instances using a single software installation. The
model supports configuration of multiple instances on a single
device by creating a list of logical network elements, each
with their own configuration and operational state related to
routing and switching protocols.
The LNE model can be represented using the tree format defined in as:
module: ietf-logical-network-element
+--rw logical-network-elements
+--rw logical-network-element* [name]
+--rw name string
+--rw managed? boolean
+--rw description? string
+--mp root
augment /if:interfaces/if:interface:
+--rw bind-lne-name?
-> /logical-network-elements/logical-network-element/name
notifications:
+---n bind-lne-name-failed
+--ro name -> /if:interfaces/interface/name
+--ro bind-lne-name
| -> /if:interfaces/interface/lne:bind-lne-name
+--ro error-info? string
'name' identifies the logical network element. 'managed'
indicates if the server providing the host network device will
provide the client LNE information via the 'root' structure.
The root of an LNE's specific data is the schema mount point
'root'. bind-lne-name is used to associated an interface with an LNE
and bind-lne-name-failed is used in certain failure cases.
An LNE root MUST contain at least the YANG library and Interfaces modules.
Logical network elements may be controlled by clients using existing
list operations. When list entries are created, a new LNE is
instantiated. The models mounted under an LNE root are expected to be
dependent on the server implementation. When a list entry is
deleted, an existing LNE is destroyed. For more information, see
Section 7.8.6.
Once instantiated, host network device resources can be
associated with the new LNE. As previously mentioned, this
document augments ietf-interfaces with the bind-lne-name leaf
to support such associations for interfaces. When an
bind-lne-name is set to a valid LNE name, an implementation
MUST take whatever steps are internally necessary to assign
the interface to the LNE or provide an error message (defined
below) with an indication of why the assignment failed. It is
possible for the assignment to fail while processing the set, or
after asynchronous processing. Error notification in the latter
case is supported via a notification.
On a successful interface assignment to an LNE, an implementation
MUST also make the resource available to the LNE by providing
a system created interface to the LNE. The name of the system
created interface is a local matter and may be identical or
completely different, and mapped from and to, the name used in
the context of the host device. The system created interface
SHOULD be exposed via the LNE-specific instance of the
interfaces module .
Each LNE instance is expected to support management functions
from within the context of the LNE root, via a server that
provides information with the LNE's root exposed as device root.
Management functions operating within the context of an LNE are
accessed through the LNE's standard management interfaces, e.g.,
NETCONF and SNMP. Initial configuration, much like the initial
configuration of the host device, is a local implementation
matter.
When accessing an LNE via the LNE's management interface, a
network-device representation will be presented, but its scope
will be limited to the specific LNE. Normal YANG/NETCONF
mechanisms, together with the required YANG library instance, can be used to identify the
available modules. Each supported module will be presented as a
top level module. Only LNE associated resources will be
reflected in resource related modules, e.g., interfaces,
hardware, and perhaps QoS. From the management perspective, there
will be no difference between the available LNE view
(information) and a physical network device.
There are multiple implementation approaches possible to enable
a network device to support the logical-network-element
module and multiple LNEs. Some approaches will allow the
management functions operating at network device level to
access LNE configuration and operational information, while
others will not. Similarly, even when LNE management from the
network device is supported by the implementation, it may be
prohibited by user policy.
Independent of the method selected by an implementation, the
'managed' boolean mentioned above is used to indicate when LNE
management from the network device context is possible. When
the 'managed' boolean is 'false', the LNE cannot be managed by
the host system and can only be managed from within the context
of the LNE as described in the previous section, . Attempts to access information below a
root node whose associated 'managed' boolean is set to 'false'
MUST result in the error message indicated below. In some
implementations, it may not be possible to change this
value. For example, when an LNE is implemented using virtual
machine and traditional hypervisor technologies, it is likely
that this value will be restricted to a 'false' value.
It is an implementation choice if the information can be
accessed and modified from within the context of the LNE, or
even the context of the host device. When the 'managed'
boolean is 'true', LNE information SHALL be accessible from the
context of the host device. When the associated schema-mount
definition has the 'config' leaf set to 'true', then LNE
information SHALL also be modifiable from the context of the
host device. When LNE information is available from both the
host device and from within the context of the LNE, the same
information MUST be made available via the 'root' element, with
paths modified as described in .
An implementation MAY represent an LNE's schema using either the
'inline' or 'use-schema' approaches defined in . The choice of which to
use is completely an implementation choice. The inline case is
anticipated to be generally used in the cases where the 'managed'
will always be 'false'. The 'use-schema' approach is expected to be be
most useful in the case where all LNEs share the same
schema. When 'use-schema' is used with an LNE mount point, the
YANG library rooted in the LNE's mount point MUST match the
associated schema defined within the ietf-yang-schema-mount
module.
Beyond the two modules that will always be present for an LNE, as
an LNE is a network device itself, all modules that may be present
at the top level network device MAY also be present for the LNE.
The list of available modules is expected to be implementation
dependent. As is the method used by an implementation to support
LNEs. provide example uses of LNEs.
LNE information represents device and network configuration
information. As such, the security of this information is important,
but it is fundamentally no different than any other interface or
device configuration information that has already been covered in
other documents such as , and .
The vulnerable "config true" parameters and subtrees are the
following:
This list specifies the logical network element and the related
logical device configuration.
While this leaf is contained in the previous list, it is worth
particular attention as it controls whether information under the
LNE mount point is accessible by both the host device and within
the LNE context. There may be extra sensitivity to this leaf in
environments where an LNE is managed by a different party than
the host device, and that party does not wish to share LNE
information with the operator of the host device.
This leaf indicates the LNE instance to which an interface is
assigned.
Unauthorized access to any of these lists can adversely affect the
security of both the local device and the network. This
may lead to network malfunctions, delivery of packets to
inappropriate destinations, and other problems.
This document registers a URI in the IETF XML registry . Following the format in RFC 3688, the following
registration is requested to be made.
This document registers a YANG module in the YANG Module Names
registry .
The structure of the model defined in this document is described
by the YANG module below.
file "ietf-logical-network-element@2017-09-27.yang"
module ietf-logical-network-element {
yang-version 1.1;
// namespace
namespace "urn:ietf:params:xml:ns:yang:ietf-logical-network-element";
prefix lne;
// import some basic types
import ietf-interfaces {
prefix if;
reference "RFC 7223: A YANG Data Model for Interface Management";
}
import ietf-yang-schema-mount {
prefix yangmnt;
reference "draft-ietf-netmod-schema-mount: YANG Schema Mount";
// RFC Ed.: Please replace this draft name with the corresponding
// RFC number
}
organization
"IETF Routing Area (rtgwg) Working Group";
contact
"WG Web:
WG List:
Author: Lou Berger
Author: Christan Hopps
Author: Acee Lindem
Author: Dean Bogdanovic
";
description
"This module is used to support multiple logical network
elements on a single physical or virtual system.
Copyright (c) 2017 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 Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices.";
// RFC Ed.: replace XXXX with actual RFC number and remove
// this note
// RFC Ed.: please update TBD
revision 2017-09-27 {
description
"Initial revision.";
reference "RFC TBD";
}
// top level device definition statements
container logical-network-elements {
description
"Allows a network device to support multiple logical
network element (device) instances.";
list logical-network-element {
key "name";
description
"List of logical network elements.";
leaf name {
type string;
description
"Device-wide unique identifier for the
logical network element.";
}
leaf managed {
type boolean;
default "true";
description
"True if the host can access LNE information
using the root mount point. This value
my not be modifiable in all implementations.";
}
leaf description {
type string;
description
"Description of the logical network element.";
}
container "root" {
description
"Container for mount point.";
yangmnt:mount-point "root" {
description
"Root for models supported per logical
network element. This mount point will
may or may not be inline based on the server
implementation. It SHALL always contain a YANG
library and interfaces instance.
When the associated 'managed' leaf is 'false' any
operation that attempts to access information below
the root SHALL fail with an error-tag of
'access-denied' and an error-app-tag of
'lne-not-managed'.";
}
}
}
}
// augment statements
augment "/if:interfaces/if:interface" {
description
"Add a node for the identification of the logical network
element associated with an interface. Applies to interfaces
that can be assigned on a per logical network element basis.
Note that a standard error will be returned if the
identified leafref isn't present. If an interfaces cannot
be assigned for any other reason, the operation SHALL fail
with an error-tag of 'operation-failed' and an error-app-tag
of 'lne-assignment-failed'. A meaningful error-info that
indicates the source of the assignment failure SHOULD also
be provided.";
leaf bind-lne-name {
type leafref {
path "/logical-network-elements/logical-network-element/name";
}
description
"Logical network element ID to which interface is bound.";
}
}
// notification statements
notification bind-lne-name-failed {
description
"Indicates an error in the association of an interface to an
LNE. Only generated after success is initially returned when
bind-lne-name is set.";
leaf name {
type leafref {
path "/if:interfaces/if:interface/if:name";
}
mandatory true;
description
"Contains the interface name associated with the
failure.";
}
leaf bind-lne-name {
type leafref {
path "/if:interfaces/if:interface/lne:bind-lne-name";
}
mandatory true;
description
"Contains the bind-lne-name associated with the
failure.";
}
leaf error-info {
type string;
description
"Optionally, indicates the source of the assignment
failure.";
}
}
}
]]>The Routing Area Yang Architecture design team members included Acee
Lindem, Anees Shaikh, Christian Hopps, Dean Bogdanovic, Lou Berger,
Qin Wu, Rob Shakir, Stephane Litkowski, and Yan Gang. Useful review
comments were also received by Martin Bjorklund and John Scudder.
This document was motivated by, and derived from,
.
The RFC text was produced using Marshall Rose's xml2rfc tool.
The following subsections provide example uses of LNEs.
This section describes an example of the LNE model using schema
mount to achieve the parent management. An example
device supports multiple instances of LNEs
(logical routers), each of which supports features of layer 2 and
layer 3 interfaces , routing information base
, and OSPF protocol. Each of these features
is specified by a YANG model, and they are combined using YANG
Schema Mount as follows:
To realize the above schema, the example device implements the following schema mount instance:
By using the implementation of the YANG schema mount, an operator
can create instances of logical routers. An interface can be
assigned to a logical router, so that the logical router has the
permission to access this interface. The OSPF protocol can then be
enabled on this assigned interface.
For this implementation, a parent management session has access to
the schemas of both the parent hosting system and the child logical
routers. In addition, each child logical router can grant its own
management sessions, which have the following schema:
The following shows an example where two customer specific LNEs are configured:
The following shows possible state data associated the above
configuration data:
This section describes an example of the LNE model using schema
mount to achieve child independent management. An example device
supports multiple instances of LNEs (logical
routers), each of them has the features of layer 2 and layer 3
interfaces , routing information base
, and the OSPF
protocol. Each of these features is specified by a YANG model, and
they are put together by the YANG Schema Mount as following:
To realize the above schema, the device implements the
following schema mount instance:
By using the implementation of the YANG schema mount, an operator
can create instances of logical routers, each with their logical router
specific in-line modules. An interface can be assigned to a logical
router, so that the logical router has the permission to access this
interface. The OSPF protocol can then be enabled on this assigned
interface. Each logical router independently manages its own set of
modules, which may or may not be the same as other logical
routers. The following is an example of schema set implemented on
one particular logical router:
Each of the child virtual routers is managed through its own sessions and configuration data.
The following shows an example configuration data for the LNE
name "vnf1":
The following shows an example configuration data for the LNE
name "vnf2":
The following sections shows possible state data associated the above
configuration data. Note that there are three views: the host
device's, and each LNE's.
The following shows state data for the device hosting the
example LNEs:
The following shows state data for the example LNE with name "vnf1":
The following shows state data for the example LNE with name "vnf2":