Relationship with RFC8348

italobusi commented 3 years ago

IETF has already published a YANG Data Model for Hardware Management:

https://datatracker.ietf.org/doc/html/rfc8348

More analysis is needed to decide whether RFC8348 is suitable for network inventory or whether a new draft is needed and what will be the relationship between the new draft and RFC8348

italobusi commented 3 years ago

We have reviewed RFC8348: our understanding is that RFC8348 applies to SBI (“YANG data model for the management of hardware on a single server”) and not to the NBI to report the hardware configuration retrieved from multiple NEs

However, it seems possible to define an Inventory YANG model augmenting the network model with similar information as defined in RFC8348:

augment network/node:
   +--ro ne-name                       string
   +--ro rack?                         uint8
   +--ro shelf?                        uint8
   +--ro last-change?   yang:date-and-time
   +--ro component* [name]
      +--ro name              string
      +--ro class             identityref
      +--ro description?      string
      +--ro parent?           -> ../../component/name
      +--ro parent-rel-pos?   int32
      +--ro contains-child*   -> ../../component/name
      +--ro hardware-rev?     string
      +--ro firmware-rev?     string
      +--ro software-rev?     string
      +--ro serial-num?       string
      +--ro mfg-name?         string
      +--ro model-name?       string
      +--ro alias?            string
      +--ro asset-id?         string
      +--ro is-fru?           boolean
      +--ro mfg-date?         yang:date-and-time
      +--ro uri*              inet:uri
      +--ro uuid?             yang:uuid
      +--ro state {hardware-state}?
      |  +--ro state-last-changed?   yang:date-and-time
      |  +--ro admin-state?          admin-state
      |  +--ro oper-state?           oper-state
      |  +--ro usage-state?          usage-state
      |  +--ro alarm-state?          alarm-state
      |  +--ro standby-state?        standby-state
      +--ro sensor-data {hardware-sensor}?
         +--ro value?               sensor-value
         +--ro value-type?          sensor-value-type
         +--ro value-scale?         sensor-value-scale
         +--ro value-precision?     sensor-value-precision
         +--ro oper-status?         sensor-status
         +--ro units-display?       string
         +--ro value-timestamp?     yang:date-and-time
         +--ro value-update-rate?   uint32

The advantages of this approach, compared with the straw man proposal in ietf-ccamp-wg/ietf-network-inventory#1, are:

no need to redefine the attributes which have been already defined in RFC8348
simplify the task of an SDN controller managing the NEs using RFC8348 to report inventory information at the NBI
extends the applicability of the inventory model applicable to any IP networks using RFC8348 for IP routers' hardware management

We think that the class, parent, parent-rel-pos should be sufficient to infer the absolute position (ne/rack/shelf/sub-shelf/slot/sub-slot/port) of sub-components. The rack and shelf attributes are needed to infer the absolute position of the top-level component (assuming there is only one top-level component per NE/node)

To be further evaluated:

whether all the attributes defined in RFC8348 needs to be reported in the Inventory model
whether there are attributes missing in RFC8348 which are needed to be reported in the Inventory model
the assumption that there is only one top-level component per NE/node

Co-authored-by: agva123 agva123@gmail.com

oscargdd commented 2 years ago

My undestanding is similar, it is a device model. You have two main choices:

A) Augment IETF Network and include the information explicitly

B) Augment IETF Network with mount points for the device information (and mount RFC 8348 on top of it).

oscargdd commented 2 years ago

About "whether all the attributes defined in RFC8348 needs to be reported in the Inventory model"

At least the following part, related to performance, is not needed:

+--ro state {hardware-state}? | +--ro state-last-changed? yang:date-and-time | +--ro admin-state? admin-state | +--ro oper-state? oper-state | +--ro usage-state? usage-state | +--ro alarm-state? alarm-state | +--ro standby-state? standby-state +--ro sensor-data {hardware-sensor}? +--ro value? sensor-value +--ro value-type? sensor-value-type +--ro value-scale? sensor-value-scale +--ro value-precision? sensor-value-precision +--ro oper-status? sensor-status +--ro units-display? string +--ro value-timestamp? yang:date-and-time +--ro value-update-rate? uint32

italobusi commented 2 years ago

To be further evaluated:

whether all the attributes defined in RFC8348 needs to be reported in the Inventory model

See ietf-ccamp-wg/ietf-network-inventory#17

whether there are attributes missing in RFC8348 which are needed to be reported in the Inventory model

See ietf-ccamp-wg/network-inventory-yang#11

the assumption that there is only one top-level component per NE/node

See ietf-ccamp-wg/ietf-network-inventory#19

italobusi commented 2 years ago

Network Inventory weekly call (October 13, 2021)

For the -00 draft we can target an high-level structure with equipment-room and component lists and relationships, copying from RFC8348

A solution based on schema mount can be evaluated for a future update

Detailed list attributes can be added later.

italobusi commented 2 years ago

Replaced by issues ietf-ccamp-wg/ietf-network-inventory#17, ietf-ccamp-wg/network-inventory-yang#11 and ietf-ccamp-wg/ietf-network-inventory#19

ietf-ccamp-wg / ietf-network-inventory

Relationship with RFC8348 #2