"Bogaert, Bart (Nokia - BE)" <[email protected]> wrote:
> Hi,
>
> --- snip ---
> >
> > 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
>
> I think it would help to see the YANG definition for this action.
>
> [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";
> }
What other types of resets do you envision?
> 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 Added a parent/child entity capability for physical entities
>
> Is this different from contained-id/contains-child that already exist?
>
> [Bart Bogaert] It is available in the RO -state data but is added as RW data
>
> to allow planning of pluggable equipment
>
> > 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?
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.
> 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 mfg-name? string
> > +--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
> > transceiver
>
> 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:
> > +--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
>
> 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.
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?
> 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.
/martin
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
