"Bogaert, Bart (Nokia - BE)" <[email protected]> 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...) > > [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.
Dut even in your example of simple containment, it works b/c the operators knows the name of the parent, and the parent-rel-pos. Right? So what if you need to pre-configue two levels of containment? You know the name of the top-level component, so you can pre-configure the first child. But then you'll have to know the name of this first child in order to pre-configure the grand child. Or are you saying that the system always creates and gives names to all top-level components, and then the operator or system can given name to sub-components? > 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). I have a hard time trying to understand what you actually need. It now seems that you want to pre-configure some physical entity in order to be able to refer to it from higher-level models. Is this correct? Thus, you don't really want to pre-configure any leafs in the entity model, except for the name. Remember that the thread started with a request to have the 'class' and 'contained-in' leafs in the config list physical-entity, and 'class' being mandatory. > 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). Right, this is also my understanding of pre-configuration. /martin _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
