Just to add to what Andy and other said. I also believe that we should keep the entity module simpler. The discussions currently taking place remind me similar discussions two decades ago, when we started from a more complex MIB module that included physical and logical entities and the mapping in-between, and we reached the conclusion that focusing on configuration and state of the physical entities is a more pragmatic way of progressing that work (and this happened before the era of virtualization, pre-configuration, etc). We may want to do the same now, and work individual leafs separately.
Regards, Dan On Wed, Sep 7, 2016 at 3:06 AM, Andy Bierman <[email protected]> wrote: > Hi, > > > I don't think the WG should be that concerned with other modules > that configure hardware. 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 > _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
