Re: [netmod] What is the best way to HW identities

[Martin Bjorklund <[e-mail]>]

Hi,

I think there are two separate issues here.

  1.  A more flexible way to handle how parent-rel-pos is assigned by an
      implementation.

  2.  Handling of sub-classes to ianahw:hardware-class.


For 1, I suggest we use this description for the parent-rel-class:

          "An indication of the relative position of this child
           component among all its sibling components.  Sibling
           components are defined as components that:

             o Share the same value of the 'parent' node; and

             o Share a common base identity for the 'class' node.

           Note that the last rule gives implementations flexibility
           in how components are numbered.  For example, some
           implementations might have a single number series for all
           components derived from 'ianahw:port', while some others
           might have different number series for different
           components with identities derived from 'ianahw:port' (for
           example, one for RJ45 and one for SFP).";


For 2, we (the WG) needs to decide if we want to allow for standard
hardware subclasses.  If so, we (just) need to inform IANA about the
procedure for doing this.


/martin




"Bogaert, Bart (Nokia - BE/Antwerp)" <[e-mail]> wrote:
> Hi Martin,
> 
> Using this feedback, there is a basis to continue the work in BBF
> 
> What is the best way to continue with the sub-classes w.r.t. IANA, who needs
> to initiate this?  Your reply seems to suggest that irrespective of this
> email, still something was required?  Anyhow, BBF can define sub-identities
> to continue and align later when there would be standardized HW
> sub-identities.
> 
> Best regards, Bart
> 
> -----Original Message-----
> From: Martin Bjorklund [mailto:[e-mail]] 
> Sent: Thursday, August 17, 2017 1:02 PM
> To: Bogaert, Bart (Nokia - BE/Antwerp) <[e-mail]>
> Cc: [e-mail]; [e-mail]; Pauwels, Ludwig (Nokia -
> BE/Antwerp) <[e-mail]>
> Subject: Re: [netmod] What is the best way to HW identities
> 
> Hi,
> 
> "Bogaert, Bart (Nokia - BE/Antwerp)" <[e-mail]> wrote:
> > 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
> 
> Good point.  In the original model (i.e. the MIB), with fixed values for the
> class, having separate numbering schemes for separate classes makes sense.
> For example, if a certain board has a set of ports, some fans and a power
> supply, it makes sense that these are numbered individually.
> 
> However, with specialized ports, this may or may not make sense.
> 
> It might be possible to define parent-rel-pos in a way that gives the
> implementation some flexibility.  For example, all ports could share the
> same numbering scheme.  The important thing in the current model is that
> there must not exist two components with the same values for 'parent',
> 'class', and 'parent-rel-pos'.  (strictly speaking, there is no requirement
> that the parent-rel-pos is always monotonically increasing amongst siblings,
> so maybe this is possible even today)
> 
> > , 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?
> 
> Yes, the idea was to use the 'class' leaf for this.
> 
> > - which approach is the IETF preference?
> 
> I would prefer to see if we can find a definition of parent-rel-pos that
> makes numbering work better so that the 'class' identity can be used for
> specialization.
> 
> > - 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?
> 
> I don't know the answer to this question, but if we want to allow for
> standardized sub-classes, we have to create a new IANA registry (or extend
> the current one), since the current one only contains the top-level class
> (hmm, I just realized that the document needs an updated IANA considerations
> section anyway; it needs to mimic RFC
> 7224 -- probably needs to create a common registry for hardware types from
> which the MIB and YANG module can be generated)
> 
> 
> /martin