Subject: Re: [netmod] BBF Entity Augmentations

From: "Bogaert, Bart (Nokia - BE)" <[email-masked]>
Date: Wed, 2 Nov 2016 08:12:26 +0000

Hi, 

-- snip --
> > 
> >   identity hardware-reset {
> >     base reset-type;
> >     description
> >       "Hardware reset";
> >   }
>
> What other types of resets do you envision?
>
Possible other reset types: reset-with/without-selftest, software-reset

-- snip --

> > > 3 Added a couple of common attributes for the manufacturer name and 
> > > model
> > > module: bbf-entity-extension
> > > augment /ent:entity/ent:physical-entity:
> > > +--rw class? identityref
> > > +--rw contained-in* -> ../../ent:physical-entity/name --rw 
> > > +parent-rel-pos? int32
> > 
> > These were discussed in the ML thread starting with 
> > https://www.ietf.org/mail-archive/web/netmod/current/msg16458.html.
> > However, it was never clear (at least not to me) how this would 
> > actually work.
> > 
> > [Bart Bogaert] Please find an example below (assuming physical entity 
> > 'thisNode' with class 'chassis' exists) using CLI notation:
>
> Ok; so the idea would be that a pre-configured component would be
identified
> by the (contained-in, class, parent-rel-pos).  This makes sense.  If the
> system detects some configuration for this tuple when a component is
> detected, it uses the additional config data (specifically the 'name')
when
> it instantiates the component in the physical-entity list?

That's correct, system will link state to config data using those leafs

Regards, Bart

---

From: "Bogaert, Bart (Nokia - BE)" <[email-masked]>
Date: Thu, 24 Nov 2016 07:48:39 +0000

As follow-up on this discussion I would like to summarize the extensions to
the IETF entity model as agreed within BBF (and which could be considered to
be included in a next revision of the IETF entity model).  These are mainly
concerned with
1. enabling a reset of the entity by means of an action
2. enable pre-provisioning of pluggable items by a NC client
3. an additional container to group data related to pluggable transceivers

The code fragments for the extensions is as follows given below.  When
considered as viable to be added to a new revision of the ietf-entity model,
these changes can be grouped differently.

1. Enabling a reset of an entity by means of an action

module bbf-entity-reset-action {
  yang-version 1.1;

  namespace "urn:broadband-forum-org:bbf-entity-reset-action";

  prefix "bbf-entity-reset-action";

  import ietf-entity {
    prefix ent;
  }
  ...

  identity reset-type {
    description
        "Type of reset requested of entity.  Examples of resets can be:
           hardware-reset, reset-with-selftest, reset-without-selftest,
           software-reset, possibly others.";
  }

  augment "/ent:entity-state/ent:physical-entity" {
    description
        "Augment entity model with an action to request a reset of the
          entity";
    action reset {
      description "Request a reset of the entity";
      input {
        leaf reset-type {
          type identityref {
            base "reset-type";
          }
            description
                "Type of reset requested of entity";
        }
      }
    }
  }
}

2. Enabling pre-provisioning (for pluggable items such as boards, SFP)

module bbf-entity-extension {
  yang-version 1.1;

  namespace "urn:broadband-forum-org:bbf-entity-extension";

  prefix bbf-ent-ext;

  import ietf-entity {
    prefix ent;
  }
  ...

  augment "/ent:entity/ent:physical-entity" {
    description
      "Configurational nodes for entities, as counterpart for operational
        nodes";

    leaf class {
      type identityref {
        base ent:entity-physical-class;
      }
      description
        "An indication of the general hardware type of the physical
          entity.";
      reference "RFC 6933: entPhysicalClass";
    }

    leaf-list contained-in {
        type leafref {
          path "../../ent:physical-entity/ent:name";
        }
        description
          "The name of the physical entity that 'contains' this physical
            entity.";
        reference "RFC 6933: entPhysicalContainedIn";
    }

    leaf parent-rel-pos {
      type int32 {
	    range "0 .. 2147483647";
      }
      description
        "An indication of the relative position of this child
         component among all its sibling components. Sibling components are
         defined as physical entities that share the same instance values of
         each of the contained-in and class elements.";
      reference "RFC 6933: entPhysicalParentRelPos";
   }

    leaf mfg-name {
      type string;
      description
        "The name of the manufacturer of this physical component. The
          Preferred value is the manufacturer name string actually printed
          on the component itself (if present). Note that comparisons
          between instances of the model-name, firmware-rev,
          software-rev, and the serial-num nodes are only meaningful
          amongst physical entities with the same value of mfg-name. If the
          manufacturer name string associated with the physical component
          is unknown to the server, then this node will contain a
zero-length
         string.";
      reference "RFC 6933: entPhysicalMfgName";
    }

    leaf model-name {
      type string;
      description
        "The vendor-specific model name identifier string associated with
          this physical component. The preferred value is the
customer-visible
          part number, which may be printed on the component itself. If the
          model name string associated with the physical component is
          unknown to the server, then this node will contain a zero-length
          string.";
      reference "RFC 6933: entPhysicalModelName";
    }
  }
}

3. Definition of a new identity based on ianaent:module for a pluggable
transceiver and the pluggable transceiver:

module bbf-entity {
//  yang-version 1.1; ConfD does not support v1.1

  namespace "urn:broadband-forum-org:bbf-entity";

  prefix bbf-ent;

  import iana-entity {
	  prefix ianaent;
  }
  ...

  identity pluggable-transceiver {
    base ianaent:module;
    description
        "This identity is applicable if the physical entity class is sort of
         compact pluggable transceiver such as SFP (small form factor
         pluggable) or XFP (10 Gigabit Small Form Factor Pluggable)";
  }
}

module bbf-entity-pluggable-transceiver {
  yang-version 1.1;

  namespace "urn:broadband-forum-org:bbf-entity-pluggable-transceiver";

  prefix bbf-ent-plg-xcvr;

  import ietf-entity {
    prefix ent;
  }

  import bbf-entity {
	  prefix bbf-ent;
  }
  ...

  augment "/ent:entity-state/ent:physical-entity" {
    when 'derived-from-or-self(../class, 
                "bbf-ent:pluggable-transceiver")';
    description
        "Data nodes for entities of identity type pluggable-transceiver";

    container pluggable-transceiver-data {
      description
            "Pluggable-transceiver data nodes for entities of identity type
              pluggable-transceiver";
    }
  }

  augment "/ent:entity/ent:physical-entity" {
    when 'derived-from-or-self(../class, 
               "bbf-ent:pluggable-transceiver")';
    description
        "Config nodes for entities of identity type pluggable-transceiver";

    container pluggable-transceiver {
      description
            "Pluggable-transceiver related nodes.";
    }
  }
}

The YANG tree for entity looks as follows (notification omitted):

module: ietf-entity
    +--ro entity-state
    |  +--ro last-change?       yang:date-and-time
    |  +--ro physical-entity* [name]
    |     +--ro name                                           string
    |     +--ro class                                          identityref
    |     +--ro physical-index?                                int32
{entity-mib}?
    |     +--ro description?                                   string
    |     +--ro contained-in*                                  ->
../../physical-entity/name
    |     +--ro contains-child*                                ->
../../physical-entity/name
    |     +--ro parent-rel-pos?                                int32
    |     +--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 {entity-state}?
    |     |  +--ro state-last-changed?   yang:date-and-time
    |     |  +--ro admin-state?          entity-admin-state
    |     |  +--ro oper-state?           entity-oper-state
    |     |  +--ro usage-state?          entity-usage-state
    |     |  +--ro alarm-status?         entity-alarm-status
    |     |  +--ro standby-status?       entity-standby-status
    |     +--ro sensor-data {entity-sensor}?
    |     |  +--ro data-type?              entity-sensor-data-type
    |     |  +--ro data-scale?             entity-sensor-data-scale
    |     |  +--ro precision?              entity-sensor-precision
    |     |  +--ro value?                  entity-sensor-value
    |     |  +--ro oper-status?            entity-sensor-status
    |     |  +--ro sensor-units-display?   string
    |     |  +--ro value-timestamp?        yang:date-and-time
    |     |  +--ro value-update-rate?      uint32
    |     +--ro bbf-ent-plg-xcvr:pluggable-transceiver-data
    |     +---x bbf-entity-reset-action:reset
    |        +---w bbf-entity-reset-action:input
    |           +---w bbf-entity-reset-action:reset-type?   identityref
    +--rw entity {entity-config}?
       +--rw physical-entity* [name]
          +--rw name                                      string
          +--rw serial-num?                               string
          +--rw alias?                                    string
          +--rw asset-id?                                 string
          +--rw uri*                                      inet:uri
          +--rw admin-state?                              entity-admin-state
{entity-state}?
          +--rw bbf-ent-ext:contained-in*                 ->
../../ent:physical-entity/name
          +--rw bbf-ent-ext:class?                        identityref
          +--rw bbf-ent-ext:mfg-name?                     string
          +--rw bbf-ent-ext:model-name?                   string
          +--rw bbf-ent-ext:parent-rel-pos?               int32
          +--rw bbf-ent-plg-xcvr:pluggable-transceiver

Best regards - Vriendelijke groeten,
Bart Bogaert
Broadband-Access System Architect Data
Contact number +32 3 2408310 (+32 477 673952)

NOKIA
Copernicuslaan 50, 2018 Antwerp, Belgium
Fortis 220-0002334-42
VAT BE 0404 621 642 Register of Legal Entities Antwerp

<<
This message (including any attachments) contains confidential information
intended for a specific individual and purpose, and is protected by law. If
you are not the intended recipient, you should delete this message. Any
disclosure, copying, or distribution of this message, or the taking of any
action based on it, is strictly prohibited without the prior consent of its
author.

-----Original Message-----
From: netmod [mailto:[email-masked]] On Behalf Of Bogaert, Bart
(Nokia - BE)
Sent: 02 November 2016 09:12
To: Martin Bjorklund <[email-masked]>
Cc: Carey, Timothy (Nokia - US) <[email-masked]>; [email-masked]
Subject: Re: [netmod] BBF Entity Augmentations

Hi,

-- snip --

-- snip --

> > > 3 Added a couple of common attributes for the manufacturer name
> > > and model
> > [Bart Bogaert] Please find an example below (assuming physical
> > entity 'thisNode' with class 'chassis' exists) using CLI notation:
>
identified
> by the (contained-in, class, parent-rel-pos).  This makes sense.  If
> the system detects some configuration for this tuple when a component
> is detected, it uses the additional config data (specifically the
> 'name')
when

Regards, Bart