Network Instance ModelLabN Consulting, L.L.C.lberger@labn.netDeutsche Telekomchopps@chopps.orgCisco Systems301 Midenhall WayCaryNCUSA27513acee@cisco.comivandean@gmail.com
This document defines a network instance module. This module along
with the logical network element module can be used to manage the
logical and virtual resource representations that may be present on a
network device. Examples of common industry terms for logical resource
representations are Logical Systems or Logical Routers. Examples of
common industry terms for virtual resource representations are Virtual
Routing and Forwarding (VRF) instances and Virtual Switch Instances
(VSIs).
This document defines the second of two new modules that 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. Both make use of emerging
YANG functionality supported by YANG Schema Mount . This document is expected to use whatever
Schema Mount solution is agreed upon by the Netmod Working Group.
Two forms of resource partitioning are supported:
The first form, which is defined in ,
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, which is defined in this document, 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 below. 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 top open issues are:
This document will need to match the evolution and
standardization of or
by the Netmod WG.
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 . For more information on how these models
may be used within an overall device model structure, see .
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 and network-instance modules
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).
The network instance container is used to represent virtual routing
and forwarding instances (VRFs) and virtual switching instances
(VSIs), . VRFs and VSIs are commonly used to isolate
routing and switching domains, for example to create virtual private
networks, each with their own active protocols and routing/switching
policies. The model represents both core/provider and virtual
instances. Network instances reuse and build on
and are shown below:
A network instance is identified by a
`name` string. This string is used both as
an index within the network-instance module and to associate
resources with a network instance as shown above in the
interface augmentation. Type is used to indicate the type NI,
such as L3-VRF, VPLS, L2-VSI, etc. Network instance policy
and root are discussed in greater detail below.
Network instance policies are used to control how NI
information is represented at the device level, VRF routing
policies, and VRF/VSI identifiers. Examples include BGP route
targets (RTs) and route distinguishers (RDs), virtual network
identifiers (VN-IDs), VPLS neighbors, etc. The structure is
expected to be:
Modules that may be used to represent network instance
specific information will be available under
`root`. As with LNEs, actual module
availability is expected to be implementation dependent. The
yang library module
is expected to be the primary method
used to identify supported modules. Resource related control
and assignment is expected to be managed at the network-device
level, not the network instance level, based on the
`bind-network-instance-name` augmentation
mentioned above.
As an example, consider the case where a network instance with
a `name` of "green" is defined on a network
device. In this case the following structure might be made
available:
All modules that represent control-plane and data-plane
information may be present at the `root`,
and be accessible via paths modified per
. The list of available
modules is expected to be implementation dependent. As is the
method used by an implementation to support NIs.
TBD -- need to resolve if instantiation is based on new list entry
creation per the pending Schema Mount solution definition.
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 .
The structure of the model defined in this document is described
by the YANG module below.
Logical Network Element ModelLabN Consulting, L.L.C.Deutsche TelekomCisco SystemsNetwork Device YANG Organizational ModelsCisco SystemsLabN Consulting, L.L.C.Deutsche TelekomThe 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.The RFC text was produced using Marshall Rose's xml2rfc tool.