Martin, Currently BBF has extended the entity config true part with a number of leafs allowing the operator to configure entities which are currently available in the config false section. The augmentation in the interfaces model is to allow a coupling between the entity and the interface worlds. As far as I can see it, we have the required leafs present in the model allowing the configuration of plugable entities (pre-configuration is not really relevant in that matter). The only point of discussion was that some assumed that the e.g. the class leaf would be mandatory but you can't just make a leaf mandatory in an augment. If you include the new leafs in a container one could use a presence statement to allow the mandatory keyword.
Best regards, Bart -----Original Message----- From: Martin Bjorklund [mailto:[email protected]] Sent: 06 September 2016 14:25 To: Bogaert, Bart (Nokia - BE) Cc: [email protected]; [email protected] Subject: Re: [netmod] BBF extensions to ietf-entity "Bogaert, Bart (Nokia - BE)" <[email protected]> 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
