Hi,
"Bogaert, Bart (Nokia - BE/Antwerp)" <bart.boga...@nokia.com> wrote:
Hi,
--- snip ---
state.”, so the above sentence only applies for the second case below.
Ok.
2. The second case is that something is detected but it can’t be read.
We do not see a reason to use the value configured for the leafs
‘serial-num’, ‘mfg-name’ and ‘model-name’ of a matching entry in
the configuration data. These leafs are defined as optional so
why would we report something entered by an operator in the
operational datastore that intends to report on what is detected?
Is it not better to not report them at all? In an NMDA context it
would be possible to have a different value (or no value at all)
for certain leafs while there is something in the running/intended datastore.
The normal NMDA procedure for a configuration leaf is to repeat it
in operational state. This is then the "applied configuration".
I don't think we should have a special rule for these leafs.
This also means that a client that just wants to read all the serial
numbers can do so from one place, the operational state, regardless
of how they came into existance.
[Bogaert, Bart ]
We do understand that a target of NMDA is to read out the actually
applied data in one request. But the result should not be
confusion. A key word is “applied”.
Section 5.3 of draft-ietf-netmod-revised-datastores-09 also contains
(I put a part of the section between ***):
The datastore schema for <operational> MUST be a superset of the
combined datastore schema used in all configuration datastores
except that configuration data nodes supported in a configuration
datastore ***MAY be omitted from <operational> if a server is not
able to accurately report them ***.
Note that this text talks about the *schema*. It is intended for
servers to migrate to NMDA without having to instrument all config
nodes in <operational> immediately. If you apply this to
ietf-hardware, it could be a server that implements the node
"serial-num" in config, but not in <operational> (which would be
weird).
For example, it is expected that the value of multiple leafs need to
be a consistent set, e.g. the mfg-name, the model-name, and the
serial-num.
Suppose we have a use case in which a hardware component is
planned/configured (e.g. a board supporting DSL interfaces) but a
different one is plugged (e.g. a board supporting ethernet
interfaces).
Suppose it is possible to read some fields on the detected component
but due to an issue not to read other fields.
If in that case the operational datastore will be completed with the
data taken from the running datastore, then the presented view might
be inconsistent.
This is true for other similar nodes as well - "asset-id" and "uri".
The question is also: what data is applied? Our assumption: if there
is a mismatch between detected versus configured hardware, then the
interface/service related data that is configured consistently with
the planned hardware is not applied on the mismatching hardware.
I.e. the detected hardware is not brought in service so not
‘applied’, the operational datastore only (accurately) reports on
what is detected.
If there is a mismatch and the server doesn't apply the configured
values, then obviously the configured 'mfg-name' etc are not copied to
<operational>.
We do not see this as a special rule for this data but rather would
apply a general rule:
- if there is a ‘missing resource’, then the data is not reported in the
operational datastore.
- If the server is not able to report accurately, then the data is
omitted from the operational
I think that if you want complete separation between the values of
'mfg-name', 'model-name', and 'serial-num' in configuration and
operational state, then these should be modelled as separate leafs.
We should have a config false leaf 'serial-num' that only contains the
detected value (if found), and a config true leaf 'config-serial-num'
or something, that contains the configured serial number.
But if this is the case, I wonder if it wouldn't be better to leave
such additional config objects to vendors, and simply make these three
nodes config false in ietf-hardware.
/martin
Regards, Bart
/martin
Best regards, Bart
-----Original Message-----
From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Robert
Wilton
Sent: Thursday, December 21, 2017 4:14 PM
To: Martin Bjorklund <m...@tail-f.com>; netmod@ietf.org
Subject: Re: [netmod] AD review of draft-ietf-netmod-entity-06
Hi Martin,
On 21/12/2017 11:37, Martin Bjorklund wrote:
Hi,
I need WG input on this issue. The question is how to handle
'serial-num', 'mfg-name', and 'model-name'. I think they should
all be treated the same. Based on previous WG discussion (see
e.g. the mail thread "draft-ietf-netmod-entity issue #13"), I
think they should all be configurable, but the configured value
is only used in operational state if the system cannot read it from the
hardware.
I think that this approach is probably OK:
- The client can always see the real value if it is available.
- If it is not available then they can assign a value via
configuration.
I was also considering an alternative approach of having a
separate set of config false leaves for the "burnt in values".
And then having the configurable leaves always override the
default operational values. E.g. similar to how an interface MAC
address would expect to be handled.
But one set of leaves is probably sufficient.
Thanks,
Rob
So I suggest the following changes:
OLD:
leaf serial-num {
type string;
config false;
description
"The vendor-specific serial number string for the
component. The preferred value is the serial number
string actually printed on the component itself (if
present).";
reference "RFC 6933: entPhysicalSerialNum";
}
NEW:
leaf serial-num {
type string;
description
"The vendor-specific serial number string for the
component. The preferred value is the serial number
string actually printed on the component itself (if
present).
This leaf can be configured. There are two use cases for
this; as a 'post-it' note if the server cannot determine
this value from the component, or when pre-provisioning a
component.
If the server can determine the serial number from the
component, then that value is always used in operational
state, even if another value has been configured.";
reference "RFC 6933: entPhysicalSerialNum";
}
And corresponding text for 'mfg-name' and 'model-name'.
And also:
OLD:
When the server detects a new hardware component, it
initializes a list entry in the operational state.
If the server does not support configuration of hardware
components, list entries in the operational state are
initialized with values for all nodes as detected by the
implementation.
Otherwise, the following procedure is followed:
1. If there is an entry in the /hardware/component list in
the intended configuration with values for the nodes
'class', 'parent', 'parent-rel-pos' that are equal to
the detected values, then:
1a. If the configured entry has a value for 'mfg-name'
that is equal to the detected value, or if the
'mfg-name' value cannot be detected, then the list
entry in the operational state is initialized with the
configured values for all configured nodes, including
the 'name'.
Otherwise, the list entry in the operational state is
initialized with values for all nodes as detected by
the implementation. The implementation may raise an
alarm that informs about the 'mfg-name' mismatch
condition. How this is done is outside the scope of
this document.
1b. Otherwise (i.e., there is no matching configuration
entry), the list entry in the operational state is
initialized with values for all nodes as detected by
the implementation.
If the /hardware/component list in the intended
configuration is modified, then the system MUST behave as if
it re-initializes itself, and follow the procedure in
(1).";
NEW:
When the server detects a new hardware component, it
initializes a list entry in the operational state.
If the server does not support configuration of hardware
components, list entries in the operational state are
initialized with values for all nodes as detected by the
implementation.
Otherwise, the following procedure is followed:
1. If there is an entry in the /hardware/component list in
the intended configuration with values for the nodes
'class', 'parent', 'parent-rel-pos' that are equal to
the detected values, then the list entry in operational
state is initialized with the configured values,
including the 'name'. The leafs 'serial-num',
'mfg-name', and 'model-name' are treated specially; see
their descriptions for details.
2. Otherwise (i.e., there is no matching configuration
entry), the list entry in the operational state is
initialized with values for all nodes as detected by
the implementation.
If the /hardware/component list in the intended
configuration is modified, then the system MUST behave as if
it re-initializes itself, and follow the procedure in
(1).";
/martin
Benoit Claise <bcla...@cisco.com> wrote:
On 12/20/2017 4:00 PM, Martin Bjorklund wrote:
Benoit Claise <bcla...@cisco.com> wrote:
Hi Martin,
Thanks.
Only kept the relevant excerpts.
- Some objects are read-write in RFC6933:
entPhysicalSerialNum
entPhysicalAlias
entPhysicalAssetID
entPhysicalUris
For example, entPhysicalSerialNum being read-write always
bothered me.
serial-num is now "config false", which is a good news IMO.
Actually, this was not the intention. In
draft-ietf-netmod-entity-03 this is configurable. I missed
this in the conversion to NMDA.
Ah. So no good news in this case...
In the reverse direction, entPhysicalMfgName is read-only
in RFC6933, while it's "config true" in
draft-ietf-netmod-entity
Yes, this was added per request from the WG. See e.g. the
thread "draft-ietf-netmod-entity issue #13".
Sure. It was mainly an observation.
However, I think that what we have now is probably not correct.
I think that all nodes 'serial-num', 'mfg-name', and 'model-name'
should be config true, and the description of list 'component'
updated to reflect that all these tree leafs are handled the same way.
I would like to know what the WG thinks about this.
Talking as a contributor this time.
It seems that inventory management is kind of broken when
someone can change 'serial-num', 'mfg-name', and 'model-name.
They can't really change them. The configured values are only
used (i.e. visible in the operational state) if the device
cannot detect them automatically. I.e., they work as "post-it" notes only.
If I look at, for example, the mfg-name, description, this is
not what it says.
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 component 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 is not instantiated.";
reference "RFC 6933 <https://tools.ietf.org/html/rfc6933>:
entPhysicalMfgName";
Regards, Benoit
/martin
.
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
.
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
