"Bogaert, Bart (Nokia - BE)" <bart.boga...@nokia.com> wrote: > From: Martin Bjorklund [mailto:m...@tail-f.com] > Sent: 05 September 2016 12:41 > To: Bogaert, Bart (Nokia - BE) > Cc: netmod@ietf.org > Subject: Re: [netmod] BBF extensions to ietf-entity > > "Bogaert, Bart (Nokia - BE)" <bart.boga...@nokia.com> wrote: > > "Bogaert, Bart (Nokia - BE)" <bart.boga...@nokia.com> 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.
Aha, I mis-read your text "augemntation to the hardware list" as meaning that the augment target was the hardware list. Good, I agree that the pointer from the high-level to lower-level is better. So then my question remains; why isn't the pre-provisioning handled in the interface layer, and the hardware list is purely for monitoring? /martin > > 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:m...@tail-f.com] > > > Sent: 29 August 2016 11:06 > > > To: Bogaert, Bart (Nokia - BE) > > > Cc: netmod@ietf.org > > > 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)" <bart.boga...@nokia.com> wrote: > > > > Martin Bjorklund <m...@tail-f.com> wrote: > > > > "Bogaert, Bart (Nokia - BE)" <bart.boga...@nokia.com> 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 netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
