Re: [netmod] BBF extensions to ietf-entity

["Bogaert, Bart (Nokia - BE)" <[e-mail]>]

> "Bogaert, Bart (Nokia - BE)" <[e-mail]> wrote:
> > "Bogaert, Bart (Nokia - BE)" <[e-mail]> wrote:
> > > Hi Martin,
> > > 
> > > "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?
> > > 
> > > [Bart Bogaert] Can you explain exactly what you mean by this 
> > > statement?  The link is there to connect the HW to the logical 
> > > interfaces defined on top of this HW.  It also allows "visualization"
> > > on management GUIs to which HW an interface is linked.  Is this 
> > > what you
> > mean by "monitoring"?
> > 
> > You explained that the reason for making the hardware list 
> > configurable was to allow pre-provisioning:
> > 
> >     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
> > 
> > My comment was that pre-provisioning can be handled by the interface 
> > layer, rather than the hardware layer.
> > 
> > But maybe you are right in the sense that if we support any config 
> > true parameters for the hardware, we should also support 
> > pre-provisioning of these parameters.
> > 
> > What kind of data do you expect the operator to be able to 
> > pre-configure in this list?
> > 
> > [Bart Bogaert] Assume you would have a node with a number of slots 
> > (which are currently empty - so no board has been plugged yet) then 
> > it should be possible for an operator to plan a configuration 
> > meaning that a board can planned to be present in the first slot and
that e.g.
> > mgf-name, model-name, parent-rel-pos and may be other parameters 
> > could be configured by the operator.  In case there is a more 
> > "extensive" HW stacking we may also have to allow setting of the 
> > class of an entity, indicate in which entity the new entity will be 
> > created (so reflecting in setting of a contained-in leaf in the RW 
> > section)
> 
> Here's my view of how pre-configuration would work.  Let me know if 
> you agree or not.
> 
> We have a list of components that can be (pre)configured.  Each entry 
> has a set of leafs that identifies the component somehow, and a set of 
> configuration parameters to be applied to the component.  If the 
> system finds a physical component that matches the identification 
> criteria leafs, then the corresponding configuration parameters are
applied.
> [Bart Bogaert] More or less but it could be that a system is initially 
> deployed with a minimum set of boards and the system gets extended 
> when the request for services grows (so boards are planned and get 
> inserted some time after).  For boards that are present when the 
> systems starts I agree that the system is able to detect what has been
inserted.
> 
> In the simplest case (which is what we have today in ietf-entity), the 
> identification leaf is just the name of the component.  This means 
> that in order to do pre-provisioning, the operator needs to be able to 
> predict the name of the component.
> [Bart Bogaert] Indeed, but in case of pre-provisioning it is not 
> predicting, the network operator actually tells what the configuration 
> has to look like (and in case the detected configuration differs from 
> what was intended, the system generates a mismatch alarm).

Hmm, do you mean that there is yet another type of leaf involved; one set
for identification, one set for values that MUST match, and one set for
things to configure?

For example, let's assume that 'name' is used for identification and 'class'
as one that MUST match.  If the operator sets:

   <component>
     <name>dev3</name>
     <class>ianaent:port</class>
     <asset-id>42</asset-id>
   </component>

and then the system detects a piece of hardware that it calls 'dev3'.
Now the system checks the config, and finds the entry above, and checks the
class of the new hardware.  If the class is 'port', it will use the
asset-id.  If the class is something else, the corresponding config is not
used, and maybe even an alarm is set.

[Bart Bogaert] In the above example the operator pre-configures an entity (a
port in this case).  If the port would have information contained that
includes the name then indeed the system will generate an alarm if the name
that the operator intended does not match.  A more realistic (at least in my
opinion) is the case where you can insert different cards in a slot of a
system.  If the operator plans that a certain slot will contain a board
offering e.g. DSL lines then the model-name could reflect the HW name of
that card.  The system is able to retrieve this information from an onboard
inventory and can verify that this board is indeed the intended board.  If
not it will raise an alarm.  It is then up to the network operator to act
upon this (the pre-configuration could also have included configuration of
the ports supported by this board).  It all depends on the use-case.

/Bart

/martin


> By also adding the leaf 'class' I suspect that this would be used as 
> an identification leaf, so that both the 'name' and 'class' have to 
> match in order for the rest of the parameters to be applied?
> [Bart Bogaert] This could be indeed a possible intention.
> 
> /Bart
> 
> 
> /martin
> 
> 
> 
> > 
> > /Bart
> > 
> > /martin
> > 
> > 
> > 
> > > 
> > > 
> > > /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
> > > > > > ([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.
> > > > > >