Network Device YANG Organizational ModelsCisco Systems301 Midenhall WayCaryNCUSA27513acee@cisco.comLabN Consulting, L.L.C.lberger@labn.netivandean@gmail.comDeutsche Telekomchopps@chopps.org
This document presents an approach for organizing YANG models
in a comprehensive structure that may be used to configure and
operate network devices. The structure is itself represented
as a YANG model, with all of the related component models
logically organized in a way that is operationally intuitive,
but this model is not expected to be implemented. The
identified component modules are expected to be defined and
implemented on common network devices.
This document is derived from work submitted to the IETF by
members of the informal OpenConfig working group of network
operators and is a product of the Routing Area YANG
Architecture design team.
"Operational Structure and Organization of YANG Models"
, highlights the value of organizing
individual, self-standing YANG models
into a more comprehensive structure. This document builds on
that work and presents a derivative structure for use in
representing the networking infrastructure aspects of physical
and virtual devices. and earlier
versions of this document presented a single device-centric
model root, this document no longer contains this element.
Such an element would have translated to a single device
management model that would be the root of all other models and
was judged to be overly restrictive in terms of definition,
implementation, and operation.
The document presents a notional network device YANG
organizational structure that provides a conceptual framework
for the models that may be used to configure and operate
network devices. The structure is itself presented as a YANG
module, with all of the related component modules logically
organized in a way that is operationally intuitive. This
network device model is not expected to be implemented, but
rather provide as context for the identified representative
component modules with are expected to be defined, and
supported on typical network devices.
This document refers to two new modules that are expected to
be implemented. These models are defined to support the
configuration and operation of network-devices that allow for
the partitioning of resources from both, or either, management
and networking perspectives.
Two forms of resource partitioning are referenced:
The first form provides a logical partitioning of a network device
where each partition is separately managed as essentially an
independent network element which is 'hosted' by the base network
device. These hosted network elements are referred to as logical
network elements, or LNEs, and are supported by the
logical-network-element module defined in . The module is used to identify LNEs and
associate resources from the network-device with each LNE. LNEs
themselves are represented in YANG as independent network devices;
each accessed independently. Optionally, and when supported by the
implementation, they may also be accessed from the host system.
Examples of vendor terminology for an LNE include logical system or
logical router, and virtual switch, chassis, or fabric.
The second form provides support what is commonly referred to as
Virtual Routing and Forwarding (VRF) instances as well as Virtual
Switch Instances (VSI), see . In this form
of resource partitioning multiple control plane and
forwarding/bridging instances are provided by and managed via a
single (physical or logical) network device. This form of resource
partitioning is referred to as Network Instances and are supported
by the network-instance module defined in . Configuration and operation of each
network-instance is always via the network device and the
network-instance module.
This document was motivated by, and derived from,
. The requirements from that
document have been combined with the requirements from
"Consistent Modeling of Operational State Data in YANG",
, into "NETMOD Operational State
Requirements", . This document
is aimed at the requirement related to a common
model-structure, currently Requirement 7, and also aims to
provide a modeling base for Operational State representation.
The approach taken in this (and the original) document is to
organize the models describing various aspects of network
infrastructure, focusing on devices, their subsystems, and
relevant protocols operating at the link and network layers.
The proposal does not consider a common model for higher level
network services. We focus on the set of models that are
commonly used by network operators, and suggest a corresponding
organization.
A significant portion of the text and model contained in this
document was taken from the -00 of .
This version of the document and structure are a product of the
Routing Area YANG Architecture design team and is very much a work in
progress rather than a final proposal. This version is a major
change from the prior version and this change was enabled by
the work on the previously mentioned Schema Mount.
Schema Mount enables a dramatic simplification of the
presented device model, particularly for "lower-end" devices
which are unlikely to support multiple network instances or
logical network elements. Should structural-mount/YSDL not be
available, the more explicit tree structure presented in
earlier versions of this document will need to be utilized.
The top open issues are:
This document will need to match the evolution and
standardization of or
by the Netmod WG.
Interpretation of different policy containers requires clarification.It may make sense to use the identityref structuring with
hardware and QoS model.Which document(s) define the base System management,
network services, and oam protocols modules is TBD. This
includes the possibility of simply using RFC7317 in place of
the presented System management module.The model will be updated once the "opstate" requirements are
addressed.
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.
Figure 1: Module Element Relationships
A model for LNEs is described in and
the model for network instances is covered in
.
The presented notional network device module can itself be
thought of as a "meta-model" as it describes the relationships
between individual models. We choose to represent it also as a
simple YANG module consisting of other models, which are in
fact independent top level individual models. Although it is
never expected to be implemented.
The presented modules do not follow the hierarchy of any
Particular implementation, and hence is vendor-neutral.
Nevertheless, the structure should be familiar to network
operators and also readily mapped to vendor implementations.
The overall structure is:
The network device is composed of top level modules that can be
used to configure and operate a network device. (This is a
significant difference from earlier versions of this document
where there was a strict model hierarchy.) Importantly the
network device structure is the same for a physical network
device or a logical network device, such as those instantiated
via the logical-network-element model. Extra spacing is
included to denote different types of modules included.
YANG library is included as it
used to identify details of the top level modules supported by
the (physical or logical) network device. Th ability to
identify supported modules is particularly important for LNEs
which may have a set of supported modules which differs from
the set supported by the host network device.
The interface management model is
included at the top level. The hardware module is a placeholder
for a future device-specific configuration and operational
state data model. For example, a common structure for the
hardware model might include chassis, line cards, and ports,
but we leave this unspecified. The quality of service (QoS)
section is also a placeholder module for device configuration
and operational state data which relates to the treatment of
traffic across the device. This document references 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.
System management, network services, and oam protocols
represent new top level modules that are used to organize data
models of similar functions. Additional information on each
is provided below.
The routing and MPLS modules provide core support for the
configuration and operation of a devices control plane and data plane
functions. IEEE dot1Q is an example of
another module that provides similar functions for VLAN bridging,
and other similar modules are also possible. Each of these modules is
expected to be LNE and NI unaware, and to be instantiated as needed
as part of the LNE and NI configuration and operation supported by
the logical-network-element and network-instance modules. (Note
that this is a change from which is
currently defined with VRF/NI semantics.)
The access control list (ACL) and key chain modules are
included as examples of other top level modules that may
be supported by a network device.
The logical network element and network instance modules
enable LNEs and NIs respectively and are defined below.
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 and network-instance modules defined in
and augment
the existing interface management model in two ways: The first, by
the logical-network-element module, adds an identifier which is
used on physical interface types to identify an associated LNE.
The second, by the network-instance module, adds a name which is
used on interface or sub-interface types to identify an associated network
instance. Similarly, this name is also added for IPv4 and IPv6
types, as defined in .
The interface related augmentations are as follows:
The following is an example of envisioned combined usage. The
interfaces container includes a number of commonly used
components as examples:
The defined interface model is
structured to include all interfaces in a flat list, without
regard to logical or virtual instances (e.g., VRFs) supported
on the device. The bind-lne-name and
bind-network-instance-name leaves provide the association
between an interface and its associated LNE and NI (e.g., VRF
or VSI).
[Editor's note: need to discuss and resolve relationship
between this structure and RFC7317 and determine if 7317 is
close enough to simply use as is.]
System management is expected to reuse definitions contained in
. It is expected to be instantiated per
device and LNE. Its structure is shown below:
System-management-global is used for configuration information and
state that is independent of a particular management protocol.
System-management-protocol is a list of management protocol specific
elements. The type-specific sub-modules are expected to be defined.
The following is an example of envisioned usage:
A device may provide different network services to other devices, for
example a device my act as a DHCP server. The model may be
instantiated per device, LNE, and NI. An identityref is used
to identify the type of specific service being provided and its
associated configuration and state information. The defined structure
is as follows:
The following is an example of envisioned usage: Examples shown below
include a device-based Network Time Protocol (NTP) server, a Domain
Name System (DNS) server, and a Dynamic Host Configuration Protocol
(DHCP) server:
OAM protocols that may run within the context of a device are
grouped within the oam-protocols model. The model may be
instantiated per device, LNE, and NI. An identifyref is used to
identify the information and state that may relate to a
specific OAM protocol. The defined structure is as follows:
The following is an example of envisioned usage. Examples shown
below include Bi-directional Forwarding Detection (BFD), Ethernet
Connectivity Fault Management (CFM), and Two-Way Active Measurement
Protocol (TWAMP):
Routing protocol and IP forwarding configuration and operation
information is modeled via a routing model, such as the one
defined in .
The routing module is expected to include all IETF
defined control plane protocols, such as BGP, OSPF, LDP and
RSVP-TE. It is also expected to support configuration and
operation of or more routing information bases (RIB). A RIB
is a list of routes complemented with administrative
data. Finally, policy is expected to be represented within
each control plane protocol and RIB.
The anticipated structure is as follows:
MPLS data plane related information is grouped together, as
with the previously discussed modules, is unaware of
VRFs/NIs. The model may be instantiated per device, LNE, and
NI. MPLS control plane protocols are expected to be included
in . MPLS may reuse and build on
or other emerging models and has an
anticipated structure as follows:
Type refers to LSP type, such as static, traffic engineered or
routing congruent. The following is an example of such usage:
The network-device model structure described in this document
does not define actual configuration and state data, hence it
is not directly responsible for security risks.
Each of the component models that provide the corresponding
configuration and state data should be considered sensitive from a
security standpoint since they generally manipulate aspects of
network configurations. Each component model should be carefully
evaluated to determine its security risks, along with mitigations to
reduce such risks.
LNE portion is TBD
NI portion is TBD
This YANG model currently uses a temporary ad-hoc namespace. If it
is placed or redirected for the standards track, an appropriate
namespace URI will be registered in the "IETF XML Registry"
. The YANG structure modules will be registered in the
"YANG Module Names" registry .
Logical Network Element ModelLabN Consulting, L.L.C.Deutsche TelekomCisco SystemsNetwork Instance ModelLabN Consulting, L.L.C.Deutsche TelekomCisco SystemsIEEE 802.1Q YANG Module SpecificationsIEEEThis document is derived from
draft-openconfig-netmod-model-structure-00. We thank the Authors of
that document and acknowledge their indirect contribution to this
work. The authors include: Anees Shaikh, Rob Shakir, Kevin D'Souza,
Luyuan Fang, Qin Wu, Stephane Litkowski and Gang Yan.This work was discussed in and produced by the Routing Area Yang
Architecture design team. Members at the time of writing included
Acee Lindem, Anees Shaikh, Christian Hopps, Dean Bogdanovic, Lou
Berger, Qin Wu, Rob Shakir, Stephane Litkowski, and Gang Yan.The identityref approach was proposed by Mahesh Jethanandani.The RFC text was produced using Marshall Rose's xml2rfc tool.