Andy Bierman <[email protected]> wrote: > Hi, > > > I don't think the WG should be that concerned with other modules > that configure hardware.
Agreed. But the current discussion is about getting the base model right so that it allows for such other modules to augment/leafref the base model. The question right now is if the base model should support pre-configuration. If the answer is "no", we're done (maybe make this decision explicit in the document). If the answer is "yes", we need to solve the "identification" part. /martin > If there are individual leafs that we should > standardize for configuration in the IETF module then they can be discussed > on the mailing list. > > An external module can use leafref instead of augment, which has no > restriction against adding mandatory configuration parameters. > > > Andy > > > > On Tue, Sep 6, 2016 at 6:23 AM, Bogaert, Bart (Nokia - BE) < > [email protected]> wrote: > > > 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 > > > > _______________________________________________ > > netmod mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/netmod > > > > _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
