"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? 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
