"Bogaert, Bart (Nokia - BE)" <bart.boga...@nokia.com> wrote: > --- snip --- > > > [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? > > [Bart Bogaert] As the operator assigns the names, he knows them on all > layers
Even for the top-level objects? How would that work? > 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? > > > --- snip --- > > > [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. > > [Bart Bogaert] I agree but these leafs are added with the pre-configuration > use case in mind maybe it drifted a bit off... I think we can end this > thread here. Note that I am trying to understand your use case so that we can add the required nodes to the data model and the corresponding text. The goal is to be able to support your use case. At this time, I can't say that I know what to add. /martin > > /Bart > > > 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 netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
