"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 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. >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
