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";
}
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:
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.
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 protected]
https://www.ietf.org/mailman/listinfo/netmod
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
