Subject: [netmod] BBF Entity Augmentations

From: "Carey, Timothy (Nokia - US)" <[email-masked]>
Date: Fri, 14 Oct 2016 11:56:14 +0000

Reposting to fix formatting errors in the original message - still looking for comments.

Hello,

In using the Entity module within the BBF, we have made several enhancements to the module that we would like the IETF to consider for inclusion in the next draft of the module as we consider these enhancements to be of use to the wider YANG community.

I have included the tree definitions in this email thread. If you like the actual YANG files please let us know and we can provide those to the authors.

Specifically we have done the following enhancements:

1    Added a new generic reset action for a physical entity
module: bbf-entity-reset-action
augment /ent:entity-state/ent:physical-entity:
+---x reset
+---w input
+---w reset-type? identityref

2    Added a parent/child entity capability for physical entities

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
+--rw mfg-name? string
+--rw model-name? string

4    Introduced a new type of identity and container for a pluggable transceiver
module: bbf-entity-pluggable-transceiver
augment /ent:entity-state/ent:physical-entity:
+--ro pluggable-transceiver-data
augment /ent:entity/ent:physical-entity:
+--rw pluggable-transceiver

5    Introduced a new reference between the interface and the port
module: bbf-interface-port-reference
augment /if:interfaces/if:interface:
+--rw port-layer-if entity-ref

BR,
Tim

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 24 Oct 2016 19:57:57 +0200 (CEST)

Hi,

"Carey, Timothy (Nokia - US)" <[email-masked]> wrote:
> In using the Entity module within the BBF, we have made several
> enhancements to the module that we would like the IETF to consider for
> inclusion in the next draft of the module as we consider these
> enhancements to be of use to the wider YANG community.
> 
> I have included the tree definitions in this email thread. If you like
> the actual YANG files please let us know and we can provide those to
> the authors.
> 

I think it would help to see the YANG definition for this action.

> 2    Added a parent/child entity capability for physical entities

Is this different from contained-id/contains-child that already exist?

> +--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.

> +--rw model-name? string

I can see that these would be useful.  I assume these are intended to
be used like the configurable serial-num?

> 4 Introduced a new type of identity and container for a pluggable

Should this identity be registered with IANA?  If it is not a standard
class registered with IANA the augmentations should probably not be
done here.

> +--rw port-layer-if entity-ref

I can see how a config false reference from interface to physical
entity makes sense.  If this is config true, I assume it works like
/interfaces/interface/type?

/martin

---

From: "Bogaert, Bart (Nokia - BE)" <[email-masked]>
Date: Tue, 25 Oct 2016 09:15:50 +0000

Hi,

--- snip ---

[Bart Bogaert] this is the YANG for the action:

  identity reset-type {
    description
      "Type of reset requested of entity";
  }

  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";
        }
      }
    }
  }

[Bart Bogaert] It is available in the RO -state data but is added as RW data

to allow planning of pluggable equipment

> +--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:

configure entity physical-entity board1 class module contained-in thisNode
configure entity physical-entity cage1 class container contained-in board1
parent-rel-pos 1
configure entity physical-entity cage2 class container contained-in board1
parent-rel-pos 2
configure entity physical-entity cage3 class container contained-in board1
parent-rel-pos 3
configure entity physical-entity cage4 class container contained-in board1
parent-rel-pos 4
configure entity physical-entity sfp1 class container contained-in cage1
parent-rel-pos 1
configure entity physical-entity sfp2 class container contained-in cage2
parent-rel-pos 1
configure entity physical-entity sfp3 class container contained-in cage3
parent-rel-pos 1
configure entity physical-entity sfp4 class container contained-in cage4
parent-rel-pos 1
configure entity physical-entity port1 class port contained-in sfp1
parent-rel-pos 1
configure entity physical-entity port2 class port contained-in sfp2
parent-rel-pos 1
configure entity physical-entity port3 class port contained-in sfp3
parent-rel-pos 1
configure entity physical-entity port4 class port contained-in sfp4
parent-rel-pos 1

> +--rw model-name? string

I can see that these would be useful.  I assume these are intended to be
used like the configurable serial-num?

> 4 Introduced a new type of identity and container for a pluggable

Should this identity be registered with IANA?  If it is not a standard class
registered with IANA the augmentations should probably not be done here.

[Bart Bogaert] I think it should be registered with IANA.

> module: bbf-entity-pluggable-transceiver augment
> /ent:entity-state/ent:physical-entity:

I can see how a config false reference from interface to physical entity
makes sense.  If this is config true, I assume it works like
/interfaces/interface/type?

[Bart Bogaert] The proposal is to provide RW data.
Purpose: from the moment pluggable equipment is involved there can be a
desire
/ is a need to plan this equipment and configure services on top.
This without the board being physically plugged.
There is no opportunity to restrict to get this data from the HW if the
equipment is not plugged as this would remove all configuration
possibilities
as long as the equipment is not plugged, and it would raise the issue on
what
to do with dependent configuration data if plugged equipment is unplugged
and
replaced by non-compatible equipment.
If later the equipment is plugged, then there is a need to compare
capabilities from plugged equipment with planned data, and generate an alarm
if there is a mismatch.

Bart

/martin

_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 26 Oct 2016 08:16:34 +0200 (CEST)

>   identity hardware-reset {

What other types of resets do you envision?

> '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?

The WG needs to decide if the document should support
pre-configuration or not.  I have added this as an open issue in the
next rev. of the document for now.

> [Bart Bogaert] The proposal is to provide RW data.

Note that the interface model supports devices that code the hw info
into the name of the interface.  For example 'ethernet-0/1/1'.  In
such a device, it would be pretty awkward if you also had to provide
the name of the physical-entity when you configure this interface
(compare w/ the type leaf).

So this feature (including pre-configuation of entities) is useful
for devices that support the YANG feature
"ietf-interfaces:arbitrary-names".  Do you agree?

/martin