Subject: [netmod] draft-ietf-netmod-entity issue #13

From: Martin Bjorklund <[email-masked]>
Date: Thu, 15 Dec 2016 16:15:00 +0100 (CET)

Hi,

Issue https://github.com/netmod-wg/entity/issues/13

  Should the model support pre-configuration of hardware components?
  The current model supports pre-configuration of components provided
  the operator knows the name of the component to be installed. A more
  useful model would use the parent component, class, and
  parent-rel-pos as identification. If the system detects a component
  and there is configuration available for the parent component,
  class, and parent-rel-pos then the system would instatiate the
  component with the provided name, and optionally additional
  parameters.

See also various mails from Timothy Carey and Bart Bogaert on this
issue.

Personally, I think that we should add these nodes, since the ML
comments indicated that pre configuration is pretty useful.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 15 Dec 2016 17:14:36 +0100

> comments indicated that pre configuration is pretty useful.

I am still not sure what exactly this will do. I have been looking at
<https://www.ietf.org/mail-archive/web/netmod/current/msg17039.html>.
I am provisioning mfg-name (Preferred value is the manufacturer name
string actually printed on the component itself (if present).) but all
I have is that something of a certain expected class has been plugged
into a certain position of the parent container. Also note that
mfg-name scopes comparisons of other properties. I would have similar
questions concerning the model-name; how can a provisioning system
predict the 'vendor-specific model name identifier'? Or is the whole
idea that if I plug something that does not match, the component is
left in a special state (which one)? If this is the intention, then
this needs to be spelled out clearly somewhere.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 15 Dec 2016 17:26:09 +0100 (CET)

> this needs to be spelled out clearly somewhere.

The current model works fine if the user looks into the state list and
finds a component that he wants to configure.  To do this, he uses the
name of the component as found in the state list, and writes the
config for this component.

The current model also supports pre-configuration if the user somehow
can predict the name of a component to-be-inserted.  In this case he
can write the config, and when the component is plugged in, the system
will derive the component name, and check the config list for this
name.  This is a fragile model.

In the proposed model, the user can provide configuration for a tuple
(parent, class, parent-rel-pos).   If the server finds a component in
the state list (or such a component is later plugged in), then the
corresponding config leafs are used for the state of this component
(including the name).

If you plug in something that doesn't match the config list, well that
just means that nothing has been configured for this component, and
the system will populate the state list accordingly.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 15 Dec 2016 17:30:27 +0100

> the system will populate the state list accordingly.

Well, this is not what I read out of

https://www.ietf.org/mail-archive/web/netmod/current/msg17039.html

since there are leafs like mfg-name and model-name that seem to be
hardware component properties. And the config list is still indexed by
a name; so for list elements that have a (class, parent, position)
triple, the name would be arbitrary and not necessarily matching the
component name.

Well, if you understand the edits,...

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 16 Dec 2016 10:31:31 +0100 (CET)

Juergen Schoenwaelder <[email-masked]> wrote:
> hardware component properties.

The description statements in this email are just copied from the
corresponding config false nodes.  I think they need to be rewritten;
compare with serial-num.  This text can probably be further improved.
The idea is that the user probably would configure say mfg-name only
if the system cannot detect it automatically.

> And the config list is still indexed by

I think that the idea is that if there is a matching triple, then the
system MUST use the configured 'name' as the 'name' also in the state
list.  One reason for pre-confiugring these components is to be able
to refer to them in other config.

> Well, if you understand the edits,...

I think the idea would be explained along these lines:

The sytem conceptually behaves like this:

1.  When a physical component is detected, the system will initialize
    an entry in the /hardware-state/component list.

    If there is an entry in /hardare/component list with a matching
    (class,parent,parent-rel-pos) triple, then the state entry is
    initialized with the configured values for all configured leafs
    (name, mfg-name, ...).

    If there is no such matching entry, the system assigns a 'name'
    in an implementation-specific manner.

    If there is an entry in /hardare/component list with a matching
    'name' and where the triple (class,parent,parent-rel-pos) is not
    set, then the state entry is initialized with the configured
    values for all configured leafs (name, mfg-name, ...).

    Otherwise, the state entry is initialized with the detected values
    for all leafs.

2.  If the /hardware/component list is modified (i.e., someone changed
    the config), then the system MUST behave as if it was restarted
    and followed the procedure in (1).

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 16 Dec 2016 12:27:28 +0100

> if the system cannot detect it automatically.

I still wonder why it could be useful to provision things like the
mfg-name or the serial-num. I would rather like to know what is really
there instead of overwriting these properties.
 
> to refer to them in other config.

This may make sense.

>     and followed the procedure in (1).

This way of pre-configuring that name may indeed make sense. Lets see
if this is what BBF really wanted.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 16 Dec 2016 12:38:17 +0100 (CET)

> there instead of overwriting these properties.

Note that entPhysicalSerialNum is read-write in the MIB.  I assume
that the reason for this is that operators can use this as an
inventory list, and manually enter the values that the system cannot
detect automatically.

/martin

---

From: "Bogaert, Bart (Nokia - BE)" <[email-masked]>
Date: Wed, 21 Dec 2016 08:32:18 +0000

Hi,

--- snip ---

> if the system cannot detect it automatically.

I still wonder why it could be useful to provision things like the mfg-name
or the serial-num. I would rather like to know what is really there instead
of overwriting these properties.
[Bart Bogaert] BBF did not propose to add serial-num, this is in the base
ietf-entity YANG model.  For pluggable items it makes sense to add the model
name and mfg-name.  In case of pre-provisioning (so preparing and sending a
configuration to the device while the HW entity is actually not there yet)
it makes sense to indicate what is the intended configuration.  When the HW
entity is inserted at a later point in time the device could raise a
mismatch alarm in case another entity is detected then the one that was
"predicted" to be inserted at that position.

Best regards,
Bart
 
> > And the config list is still indexed by a name; so for list elements 
> > that have a (class, parent, position) triple, the name would be 
> > arbitrary and not necessarily matching the component name.
> 

This may make sense.

>     and followed the procedure in (1).

This way of pre-configuring that name may indeed make sense. Lets see if
this is what BBF really wanted.

/js

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

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 21 Dec 2016 14:08:34 +0100 (CET)

> "predicted" to be inserted at that position.

It would be very useful if you could comment explicitly on the
pre-provisioning algorithm I described in 
https://mailarchive.ietf.org/arch/msg/netmod/j0lbdkul9f_jJFVGz3aAAmqrEzs
(also cited below).

>From you text above it seems that you do not agree with my algorithm.

/martin

---

From: "Bogaert, Bart (Nokia - BE)" <[email-masked]>
Date: Wed, 21 Dec 2016 13:36:15 +0000

Please find response interleaved

--- snip ---

/martin

> Best regards,
> Bart
>  
> > > And the config list is still indexed by a name; so for list 
> > > elements that have a (class, parent, position) triple, the name 
> > > would be arbitrary and not necessarily matching the component name.
> > 
> > I think that the idea is that if there is a matching triple, then 
> > the system MUST use the configured 'name' as the 'name' also in the 
> > state list.  One reason for pre-confiugring these components is to 
> > be able to refer to them in other config.
> 
> This may make sense.
> 
[Bart Bogaert] this is correct
> >     in an implementation-specific manner.
[Bart Bogaert] This is correct
> >     values for all configured leafs (name, mfg-name, ...).
[Bart Bogaert] We currently expect that these leafs contain meaningful
values but we will not copy the leaf values from config to state but
populate the state fields with what is detected from the HW and raise a
mismatch alarm.  Possibly the operational state is set to disabled.  So when
a mismatch Is found between what is set in /hardware/component and what is
detected a mismatch alarm is raised.
> >     Otherwise, the state entry is initialized with the detected values
[Bart Bogaert] This is correct
> >     and followed the procedure in (1).
[Bart Bogaert] This is correct

Regards,
Bart

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 21 Dec 2016 15:56:56 +0100 (CET)

> [Bart Bogaert] this is correct

I assume that you do the validation check that you describe below also
in this case?

> mismatch alarm.

Do you expect all configured leafs to contain meaningful values, i.e.,
do you validate that all leafs (serial-num, mfg-name, model-name)
match?

This procedure would change how serial-num currently is handled.  I
don't have a strong opinion on this, but I note that serial-num is
writable in the ENTITY-MIB.  Maybe someone can comment on why it is
writable in the MIB, and if this is a use case that we want to
support?

> Possibly the operational state is set to disabled.  So when

/martin

---

From: "Bogaert, Bart (Nokia - BE)" <[email-masked]>
Date: Wed, 21 Dec 2016 15:28:59 +0000

--- snip ---

> [Bart Bogaert] this is correct

I assume that you do the validation check that you describe below also in
this case?
[Bart Bogaert] Indeed

> populate the state fields with what is detected from the HW and raise 
> a mismatch alarm.

Do you expect all configured leafs to contain meaningful values, i.e., do
you validate that all leafs (serial-num, mfg-name, model-name) match?

This procedure would change how serial-num currently is handled.  I don't
have a strong opinion on this, but I note that serial-num is writable in the
ENTITY-MIB.  Maybe someone can comment on why it is writable in the MIB, and
if this is a use case that we want to support?
[Bart Bogaert] No, in this case we expect the triplet to be meaningful
(class,parent,parent-rel-pos) as this identifies the HW entity and on top of
that the mfg-name and model-name are checked.  In case there is a mismatch
an alarm is generated.  The other leafs (defined in ietf-entity) are
implemented as described in the entity YANG model.

Regards, Bart

> Possibly the operational state is set to disabled.  So when a mismatch 
> Is found between what is set in /hardware/component and what is 
> > This way of pre-configuring that name may indeed make sense. Lets 
> > see if this is what BBF really wanted.
> > 
> > /js

/martin

---

From: Randy Presuhn <[email-masked]>
Date: Wed, 21 Dec 2016 21:14:16 -0800

Hi -

On 12/21/2016 6:56 AM, Martin Bjorklund wrote:
...
> writable in the MIB, and if this is a use case that we want to

I *think* this is an example of what were known as "post-it note"
objects.  Their values could be set by management action
to accommodate implementations in which, for example, the hardware
provided no way for software to access the information printed on an
inventory sticker affixed to a card.

Randy

---

From: William Lupton <[email-masked]>
Date: Thu, 22 Dec 2016 10:12:54 +0000

So could “being writable” be associated with a feature (which might potentially apply to multiple such nodes)? W.

(and if so, what’s the cleanest way to achieve this? it seems that “if-feature” can’t be used with “config” but that it could be used by refining a grouping?)

> On 22 Dec 2016, at 05:14, Randy Presuhn <[email-masked]> wrote:
> 
> Hi -
>

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 22 Dec 2016 11:41:34 +0100 (CET)

William Lupton <[email-masked]> wrote:
> So could “being writable” be associated with a feature (which might
> potentially apply to multiple such nodes)? W.

We can put a if-feature statement on the node 'mfg-name' in the config
tree, but not in the state tree.

But the issue is that there are two conflicting use cases:

  1)  use the writable nodes for validation with the real hw
  2)  use the writable nodes as a "post-it" function

Currently the only such node is 'serial-num', and it is used as (2).

But maybe we can actually combine these two cases.

  If the node has a value in the config, and the system can detect the
  real value from the hardware, then they MUST be equal, otherwise the
  config is not applied. (case (1) above)

  If the node has a value in the config, and the system cannot detect
  the real value from the hardware, the config is applied and the
  state value will be the config value. (case (2) above)

Maybe this violates the principle of least astonishment though...

/martin

> 
> (and if so, what’s the cleanest way to achieve this? it seems that
> “if-feature” can’t be used with “config” but that it could be used by
> refining a grouping?)
> 
> > On 22 Dec 2016, at 05:14, Randy Presuhn
> > <[email-masked]> wrote:
> > 
> > Hi -
> >