From: Martin Bjorklund [mailto:[email protected]] Sent: 05 September 2016 12:41 To: Bogaert, Bart (Nokia - BE) Cc: [email protected] Subject: Re: [netmod] BBF extensions to ietf-entity
"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? [Bart Bogaert] So you mean from entity to interfaces? Similar to the "stack" in interfaces we assumed it more logical to point from the higher to the lower layer. That is the reason why the reference is from the interface to the entity. Bart /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. > >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
