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.";
}
identity hardware-reset {
base reset-type;
description
"Hardware reset";
}
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 protected]] On Behalf Of Bogaert, Bart
(Nokia - BE)
Sent: 02 November 2016 09:12
To: Martin Bjorklund <[email protected]>
Cc: Carey, Timothy (Nokia - US) <[email protected]>; [email protected]
Subject: Re: [netmod] BBF Entity Augmentations
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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
