Skip to main content

Network Inventory YANG

Document Charter Network Inventory YANG WG (ivy)
Title Network Inventory YANG
Last updated 2023-06-23
State Approved
WG State Active
IESG Responsible AD Mahesh Jethanandani
Charter edit AD Robert Wilton
Send notices to (None)


Network inventory is a foundation for network management in all types
of networks: Network operators need to keep a record of what equipment
is planned and installed in their networks (including a variety of
information such as product name, vendor, product series, embedded
software, and hardware/software versions). Network inventories may
be constructed from management system data to represent the expected
devices present in the network, and also be used to audit and catalog
what devices are discovered in the network, and to expose that
information in a consistent way.

The purpose of the IVY WG is to provide a venue for discussion of
inventory YANG models from across IETF Areas under a common umbrella
to facilitate distribution of the work, clarify the scope of each
model, and minimize overlap between them. The Working Group may
also dispatch some inventory work towards Working Groups in the
Operations and Management Area as well as other Areas, if appropriate.

An objective of this effort is to derive common building-blocks for
inventory modeling that can be augmented, imported, or reused by other
IETF models. The WG will also identify a set of requirements and
guidelines to ensure consistency across models related to inventory.

The scope of the work extends to the inventory of network elements,
with a primary focus on those that operate at layers 0-3, and includes
both hardware and software inventory. Mapping the inventory models
that will be produced by the WG into existing IETF models (e.g.,
ietf-network-topology) is also in scope.

The Working Group will consider existing IETF work, including RFC 8348
and RFC 8345.

Work specifying the use of inventory content is outside the scope of
the Working Group, but informative examples describing how the
inventory data may be used is within scope.

The IVY WG will initially focus on developing a core network inventory
model that can be used as a foundation by other models to establish
inventory models that are specific to different hardware technologies.
The following activities will be used to help achieve this goal. It
is expected that many of these items will not lead to the publication
of RFCs, although Internet-Drafts may be used to track discussions and
establish consensus:

A. Terminology and Scope: Definition of the scope of inventory as
well as a common architecture and terminology. An effort will be
made to keep terminology aligned with, or mapped to,
industry-wide activities including initiatives in the IEEE, ITU-T,
TMF, MEF, Openconfig, ONF, and 3GPP.

B. Hardware/Software components including licenses: Hardware and
Software component management to allow network operators to keep
track of which physical/virtual devices are deployed in the
network, including software and hardware versions as well as

C. Physical locations: Indicate the physical position of the network
elements (such as, site, room, rack, shelf, slot) to provide
precise location information.

D. Multi-domain and multi-layer: Consistent representation and
reporting of network inventory to maintain a centralized view of
all network element component types across multiple network
segments and layers of the underlying network under the same
management and ownership.

E. Mapping and correlation semantics: Correlating the inventory with
existing IETF models e.g., topology, service attachment points
(SAP), etc.

F. Security and privacy issues: The information in a network
inventory is highly sensitive as it potentially exposes critical
information about the internal topology, characterization of the
components that are used to build that topology, and precise
device location information that could indirectly identify user
locations. Standard protocol mechanisms, e.g., the use of NACM
[RFC 8341], are expected to be used to prevent unauthorized
access. However, the Working Group must consider whether
additional security mechanisms (such as specific operational
guidance, or data minimization of precise location data) are
needed to protect this information from unauthorized access,
manipulation, or the indirect exposition of private user
identifying data.