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
