"Bogaert, Bart (Nokia - BE)" <[email protected]> wrote: > "Bogaert, Bart (Nokia - BE)" <[email protected]> wrote: > > Hi Martin, > > > > In BBF this pointer from HW to interface will be available (it has > > been proposed in the Berling BBF meeting already). > > I assume this is done as an augmentation? Is it an augmentation to the > interface list, or to the hardware list? I.e., is it a pointer from an > interface to the hardware, or the other way around? > [Bart Bogaert] It is an augmentation to the hardware list
Ok. Would it be possible to have the pointer the other way around? If not, why? /martin > > Bart > > I would prefer to view the hardware list as just monitoring (config > false) [1], and have config true pointers from the higher-level concepts > back to the hardware [2]. Possibly with config false back-pointers. > > [1] this doesn't preclude the config true list in current ietf-entity. > > [2] this pointer is (as noted) often implicit in the interface name today. > > > /martin > > > > > > > > > Best regards - Vriendelijke groeten, > > Bart Bogaert > > Broadband-Access System Architect Data Contact number +32 3 2408310 > > (+32 477 673952) > > > > NOKIA > > Copernicuslaan 50, 2018 Antwerp, Belgium Fortis 220-0002334-42 VAT BE > > 0404 621 642 Register of Legal Entities Antwerp > > > > << > > This message (including any attachments) contains confidential > > information intended for a specific individual and purpose, and is > > protected by law. If you are not the intended recipient, you should > > delete this message. Any disclosure, copying, or distribution of this > > message, or the taking of any action based on it, is strictly > > prohibited without the prior consent of its author. > > >> > > > > > > -----Original Message----- > > From: Martin Bjorklund [mailto:[email protected]] > > Sent: 29 August 2016 11:06 > > To: Bogaert, Bart (Nokia - BE) > > Cc: [email protected] > > Subject: Re: [netmod] BBF extensions to ietf-entity > > > > Hi, > > > > [We had mail server problems during the weekend, so this reply might > > not get the thread's history right.] > > > > "Bogaert, Bart (Nokia - BE)" <[email protected]> wrote: > > > Martin Bjorklund <[email protected]> wrote: > > > "Bogaert, Bart (Nokia - BE)" <[email protected]> wrote: > > > > I would like to bring this to the ietf-entity group. Currently > > > > BBF is proposing to add new RW leafs to the entity object. This > > > > is done in the context of plugable entities and hence it means > > > > that when an operator (via a NC client) configures a plugable item > > > > it is required to define the entity type. For this reason > > > > additional RW attributes are needed. Two of the new leafs are > > > > class and contained-in (same as > > the RO class leaf). > > > > > > > > - class: we think that the class leaf needs to be mandatory > but > > > > adding this via an augment is not possible as we can't add a > > > > mandatory leaf via an augment. Making class implicit for the > > > > client based on "some information" exchanged between device > > > > vendors and management applications is maybe not such a sound > approach. > > > > > > Can you explain in more detail how this would be used? The idea is > > > that 'class' is a property of the physical hw, and that the > > > underlying system provides this info. I can see that it could be > > > useful for the client to set this if the system can't do the > > > classification (i.e., the system-set value is 'unknown'). But > > > that's probably not the use case you had in mind? > > > > > > [Bart Bogaert] Assume you have a system with a number of slots that > > > can hold several different cards and the system was deployed in the > > > field with some cards inserted and some other slots that were still > > > left empty. When an operator wants to extend the system we can have > > > 2 > > ways of doing this: > > > 1. a field engineer goes 'on-site' and plugs cards in the system. > > > If done this way, the system itself can detect what has been > > > inserted and we do not really need the RW leafs. However in this > > > case an operator has to wait configuring user services on these > > > cards until they are > > inserted. > > > 2. the network operator determines that a node will "run out" of > > > available ports and hence wants to start planning new configuration > > > and hence he wants to configure some boards in the empty slots and > > > even may want to start to pre-configure certain data of the ports > > > contained by these boards. In that case we need the RW leaf to > > > indicate which board type will be inserted as the service that can > > > be offered depends on the board being inserted. When the board is > > > inserted, the planned configuration can directly be applied to the > > > newly inserted board (given the fact that the detected class is the > > > same > > as the planned class). > > > > Shouldn't this be handled by the support for pre-configuration in the > > interfaces data model? I.e., the general model would be that the > > entity/hardware list is monitoring of the hardware that is really > > present, and other models that need to refer to this hardware (like > > interfaces) support pre-configuration. > > > > The interface model lacks an explicit pointer to the entity/hardware > > model; but in many systems this reference is implicit in the name of the > interface. > > > > > > /martin > > > > > > > > > There are customers using method 1 and other customers use method 2. > > > > > > > - contained-in: for plugable items contained-in requires to > be > > > > mandatory too as a plugable item can't be "floating" in the device. > > > > > > Can you explain in more detail what this means, and provide some use > > > cases? > > > > > > [Bart Bogaert] For DSL we are faced with "wiring" aspects that > > > "ripple through" to the MDF. So assume we again have a system with > > > plugable > > slots. > > > If we have 2 slots containing the same type of board (same class) > > > and the operator is applying the pre-configuration mode of working > > > (method > > > 2 in above), we have to be sure that user A, connected to the first > > > port of the board plugged in the first slot will really be in slot 1. > > > If the NC client has no means to detect which board is plugged in > > > which slot (they are both of the same class) we need other means to > > > ensure the containment is as intended (and user A being connected to > > > the first port of the board in slot A is also visualized as such on > > > the GUI of the NC client). Using the serial number of the board > > > seems not very practical as board may break and are sent to repair > > > or replaced by another board of the same type but with a different > > > serial number. I do not think operators will like it a lot to > > > manage a system in a manual way based on these attributes hence also > > > a need to plan > > a board in a specific slot. > > _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
