[netmod] What is the best way to HW identities

["Bogaert, Bart (Nokia - BE/Antwerp)" <[e-mail]>]

Hello,

 

Within BBF we have had a discussion on the use of
draft-ietf-netmod-entity-03, and we would appreciate to hear the opinion of
IETF. More specific the discussion is on the use of the leaf 'class' and the
leaf 'parent-rel-pos'.

 

First some BBF context:

- the systems for which BBF specifies YANG models can be built with various
'types of hardware', e.g. as pluggable item (module) it can contain boards
and it can contain SFP/XFPs. As 'type of port' it can have connectors to
terminate fastdsl links (supported over copper wires), and it can have
positions to insert optical fibers (e.g. the position in the SFP in which
one can plug the optical fiber).

 

- in the data model we have the need for some conditional data: e.g. an
SFP/XFP has some data that is defined in SFF-8472. This data is not
applicable to boards. Hence we need to distinguish between these 2 types of
pluggable items. A 2nd example: for the optical fibers terminated by an
SFP/XFP, we have specific data that is also defined in SFF-8472, e.g. the
wavelength. This data is not applicable to fastdsl ports. On fastdsl ports
we have specific data that relates to remote power feeding. Obviously there
is no power feeding over the optical fiber. There might be other ports with
(for now) no specific data, e.g. an rj45. Conclusion: need data conditional
to the port type.

 

In draft-ietf-netmod-entity-03 we read

- "The "class" leaf is a YANG identity that describes the type of the
hardware.  Vendors are encouraged to either directly use one of the common
IANA-defined identities, or derive a more specific identity from one of
them.

 

- As description for 'parent-rel-pos': "An indication of the relative
position of this child component among all its sibling components.  Sibling
components are defined as components that share the same instance values of
each of the 'parent' and 'class' nodes.

 

Based on what we read in the first bullet a thought was to specialize the
various hardware-class identities. Examples:

 

  identity board {

    base ianahw:module;

    description

      "A board is a special type of module that represents a physical item,
commonly known as a board or a card.";

  }

 

  identity transceiver {

    base ianahw:module;

    description

      "A transceiver is a special type of module that represents a physical
item like a pluggable SFP, an SFP+, or an XFP; or a soldered SFF.";

  }

 

  identity transceiver-link {

    base ianahw:port;

    description

      "A transceiver-link is a special type of port that terminates an
optical fiber.";

  }

 

  identity rj45 {

    base ianahw:port;

    description

      "A RJ45 is a special type of port that terminates an electrical
Ethernet link.";

  }

  identity fastdsl {

    base ianahw:port;

    description

      "A fastdsl is a special type of port that terminates a copper wire
supporting a FAST or one of the DSL types link.";

  }

 

The intention with this approach: the 'class' leaf is used to distinguish
between all types of hardware. If hardware specific data is augmented to the
hardware model, then it is using a 'when' condition referring to the value
of the leaf 'class'.

 

Based on the description of the parent-rel-pos it is understood that the
value of this leaf is relative to the value of the class, so numbering of
e.g. the various types of port supported by one board is independent of each
other.

 

Then the worry starts: 

- some of the BBF members understand this concept of specializing the
hardware identities and use these values for the leaf class as the way to
go, and take the impact on the numbering as a given.

 

- Others think this impact on the parent-rel-pos is not the intention and
assume a flat numbering of all childs within a parent, hence do not want to
use the class leaf for further specialization, hence want to introduce a new
separate leaf to contain the more detailed information, hence the
conditional data for the various types of hardware shall be defined with a
'when statement' referring to this new separate leaf.

 

The feedback we would appreciate from IETF: 

- did IETF consider the need for additional conditional data?

- which approach is the IETF preference?

- in case the IETF preference is to specialize the hardware identities, does
IETF think it is worth to standardize them in IANA, or is the preference to
keep these identities within BBF?

 

Regards,

Bart