Hi -
On 9/6/2016 2:38 AM, Martin Bjorklund wrote:
"Bogaert, Bart (Nokia - BE)" <[email protected]> wrote:
On Tue, Sep 06, 2016 at 07:50:47AM +0000, Bogaert, Bart (Nokia - BE) wrote:
[Bart Bogaert] When sending a configuration request to a device while
there is no HW physically present yet is what we call pre-provisioning
meaning that the configuration is made up-front in attendance of the
HW being plugged at a later stage. When the plugged HW does not meet
the pre-configured data I think it is normal that an alarm is raised
but that does not take away the fact that the device was configured in
advance.
In your example, there is nothing configured as far as I can tell.
The way the interfaces data model supports pre-configuration is by having a
_name binding_; a pre-configured interface is applied once the name of the
pre-configured interfaces matches the name of a
(physical) interface. I think Martin is asking the question whether the same
model of using name bindings can be applied in your case and if not why not.
[Bart Bogaert] I'm afraid I am lost in the names being used here. Whether
it's called name binding or pre-configuration or still something else, the
key point is that we configure objects in the device prior to them being
physically present, nothing more, nothing less. The consequence of this
being that these objects should be present in the data tree of the device
and once the HW gets plugged all operational data linked to that comes into
existence too. I do not know of another way to explain what is intended
with what we call 'pre-configuration'.
I think there are two things that I am trying to understand:
(i) Identification
In order to be able to pre configure a component, the operator
needs a deterministic way to idenfity the component. How
exactly is this done?
One way is to rely on the name of the to-be-present component.
Another way is to identify its parent by name, and provide a
parent-rel-pos integer. (The latter assumes that the parent's
name is known...)
I the systems I worked on, naming was within the context of the
containing object. But an important point was that in those systems,
we considered slots (even empty ones) to be objects. One could write
a surprising amount on the advantages of doing so.
The names of the provisioned objects (within the context of their
container) were in generally administratively assigned, that is,
they were configuration data.
(ii) Configuration
Once a component is identified, what parameters can you
pre-configure?
Anything that could be configured.
One answer could be "none", which I think is what the examples
you have provided so far have. This then would not really be
pre-configuration, but rather a constraint, as Juergen
indictated.
In the context of those products I worked on (telephony multiplexors,
X.25 switches, SNA gateways, etc.) there were generally oodles of
configurable parameters for every port on every line card. Since we
had hot-swappable line cards and even hot-insertion extension chassis,
anything that could be configured had to be provisionable. Of course,
that was thirty years, and times change.
Randy
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
