Re: [netmod] BBF extensions to ietf-entity

[Martin Bjorklund <[e-mail]>]

"Bogaert, Bart (Nokia - BE)" <[e-mail]> wrote:
> From: Martin Bjorklund [mailto:[e-mail]] 
> Sent: 05 September 2016 12:41
> To: Bogaert, Bart (Nokia - BE)
> Cc: [e-mail]
> Subject: Re: [netmod] BBF extensions to ietf-entity
> 
> "Bogaert, Bart (Nokia - BE)" <[e-mail]> wrote:
> > "Bogaert, Bart (Nokia - BE)" <[e-mail]> 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 [phone]
> > > ([phone])
> > > 
> > > 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:[e-mail]]
> > > Sent: 29 August 2016 11:06
> > > To: Bogaert, Bart (Nokia - BE)
> > > Cc: [e-mail]
> > > 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)" <[e-mail]> wrote:
> > > > Martin Bjorklund <[e-mail]> wrote:
> > > > "Bogaert, Bart (Nokia - BE)" <[e-mail]> 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.
> > >