Re: [netmod] BBF extensions to ietf-entity

["Bogaert, Bart (Nokia - BE)" <[e-mail]>]

"Bogaert, Bart (Nokia - BE)" <[e-mail]> 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...)

[Bart Bogaert] If we stick to the use case of equipment the
pre-configuration is based on containment and names attributed to the
entities by the operator.  I tried to explain that so far names attributed
to entities have no other meaning then identifying the entity and, as
allocated by the operator, there is nothing to be predicted: it is known.  I
agree that in the case of entities there will be no other special leafs that
require to be configured.

  (ii) Configuration

      Once a component is identified, what parameters can you
      pre-configure?

      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.

[Bart Bogaert] As indicated above that might be true for equipment (entity)
objects but pre-configuration could also include definition on top of these
pre-configured ports and in this case there will certainly be configuration
of leafs that are characteristic for the to-be offered service and which
will be defined on top of a port (hence the augment of interfaces with
back-pointer to the port entity).  Also in this case the operator knows
exactly on top of which port the interface will be created.  The name
attributed to the interface has no special meaning to the SW of the device
apart from giving it a unique reference.  The name is set by the network
operator and can basically be anything (that is why I say that it has no
special meaning to the SW in the device).  As the names are set by the
operator there is nothing that requires prediction.  The name-binding as it
is referred to here comes from the model where the leafrefs point to the
name of underlying resource (be it entity or interface).

Maybe we have a different understand of "pre-configuration"?  For me it
simply means that an operator is able to create a configuration in the
device without the HW supporting this configuration being physically present
but is getting stored in the database of the device (I'm explaining it as it
is in our SNMP-based devices).  The configuration gets applied once the
supporting HW is plugged in the device (given the fact that the plugged HW
matches what was previously configured).

/Bart


/martin