Subject: Re: [netmod] BBF extensions to ietf-entity

From: Martin Bjorklund <[email-masked]>
Date: Mon, 05 Sep 2016 12:40:38 +0200 (CEST)

"Bogaert, Bart (Nokia - BE)" <[email-masked]> wrote:
> "Bogaert, Bart (Nokia - BE)" <[email-masked]> 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?

/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-masked]]
> > Sent: 29 August 2016 11:06
> > To: Bogaert, Bart (Nokia - BE)
> > Cc: [email-masked]
> > 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-masked]> wrote:
> > > Martin Bjorklund <[email-masked]> wrote:
> > > "Bogaert, Bart (Nokia - BE)" <[email-masked]> 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.
> >

---

From: "Bogaert, Bart (Nokia - BE)" <[email-masked]>
Date: Mon, 5 Sep 2016 10:44:57 +0000

From: Martin Bjorklund [mailto:[email-masked]] 
Sent: 05 September 2016 12:41
To: Bogaert, Bart (Nokia - BE)
Cc: [email-masked]
Subject: Re: [netmod] BBF extensions to ietf-entity

"Bogaert, Bart (Nokia - BE)" <[email-masked]> wrote:
> 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] 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

> false) [1], and have config true pointers from the higher-level 
> concepts back to the hardware [2].  Possibly with config false
back-pointers.
> > Best regards - Vriendelijke groeten, Bart Bogaert Broadband-Access 
> > System Architect Data Contact number +32 3 2408310
> > (+32 477 673952)
> > 
> > NOKIA
> > delete this message. Any disclosure, copying, or distribution of 
> > this message, or the taking of any action based on it, is strictly 
> > > > that when an operator (via a NC client) configures a plugable 
> > > > item it is required to define the entity type.  For this reason 
> > > 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 
> > > [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:
> > > 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
> > > Can you explain in more detail what this means, and provide some 
> > > use cases?
> > >
> > > "ripple through" to the MDF.  So assume we again have a system 
> > > with plugable
> > slots.
> > > 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.
> > > 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

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 05 Sep 2016 12:47:14 +0200 (CEST)

> the lower layer.  That is the reason why the reference is from the interface

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

---

From: "Bogaert, Bart (Nokia - BE)" <[email-masked]>
Date: Mon, 5 Sep 2016 10:56:51 +0000

Hi Martin,

"Bogaert, Bart (Nokia - BE)" <[email-masked]> wrote:
> "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"?

/martin

> > > 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.
> > > >> 
> > > 
> > > 
> > > [We had mail server problems during the weekend, so this reply 
> > > might not get the thread's history right.]
> > > 
> > > > > 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).
> > > > > 
> > > > 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 
> > > > 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:
> > > > 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.
> > > > 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).
> > > 
> > > really present, and other models that need to refer to this 
> > > hardware (like
> > > 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
> > > 
> > > 
> > > 
> > > > 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
> > > > 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 
> > > > 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

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 05 Sep 2016 13:33:46 +0200 (CEST)

> 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:

    as the service that can be offered depends on the board being inserted.

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?

/martin

---

From: "Bogaert, Bart (Nokia - BE)" <[email-masked]>
Date: Mon, 5 Sep 2016 11:59:59 +0000

"Bogaert, Bart (Nokia - BE)" <[email-masked]> wrote:
> > > > 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] 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.
> 
better.
> [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:

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)

/Bart

/martin

> > > [2] this pointer is (as noted) often implicit in the interface 
> > > name
> today.
> > > 
> > > 
> > > /martin
> > > 
> > > 
> > > 
> > > 
> > > 
> > > > 
> > > > Best regards - Vriendelijke groeten, Bart Bogaert 
> > > > information intended for a specific individual and purpose, and 
> > > > is protected by law. If you are not the intended recipient, you 
> > > > distribution of this message, or the taking of any action based 
> > > > on it, is strictly prohibited without the prior consent of its
author.
> > > > > > 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.
> > > > > > 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?
> > > > > 

> > > > > 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.
> > > > > 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
> > > > > > -          contained-in: for plugable items contained-in
requires
> to
> > > > > Can you explain in more detail what this means, and provide 
> > > > > some use cases?
> > > > >
> > > > > 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

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 05 Sep 2016 14:24:52 +0200 (CEST)

> entity will be created (so reflecting in setting of a contained-in leaf in

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.

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.

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?

/martin

---

From: "Bogaert, Bart (Nokia - BE)" <[email-masked]>
Date: Mon, 5 Sep 2016 12:34:26 +0000

"Bogaert, Bart (Nokia - BE)" <[email-masked]> wrote:
> > > the higher to the lower layer.  That is the reason why the 
> > > reference is from the interface to the entity.
> > 
> > So then my question remains; why isn't the pre-provisioning handled 
> > in the interface layer, and the hardware list is purely for monitoring?
> > 
inserted.
> [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).

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

> > > > > 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.
> > > > > >> 
> > > > > 
> > > > > 
> > > > > > > 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.
> > > > > > > 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.
> > > > > > 
> > > > > > 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:
> > > > > > this case an operator has to wait configuring user services 
> > > > > > on these cards until they are
> > > > > inserted.
> > > > > > 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.
> > > > > 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
> > > > > > There are customers using method 1 and other customers use 
> > > > > > method
> 2.
> > > > > > 
> > > > > > > mandatory too as a plugable item can't be "floating" in 
> > > > > > > the
> > device.
> > > > > > 
> > > > > > [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.
> > > > > > 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

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 05 Sep 2016 14:45:05 +0200 (CEST)

> 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.

/martin

---

From: "Bogaert, Bart (Nokia - BE)" <[email-masked]>
Date: Mon, 5 Sep 2016 13:01:48 +0000

> > > > > > 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] 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 
> > > So then my question remains; why isn't the pre-provisioning 
> > > handled in the interface layer, and the hardware list is purely for
monitoring?
> > (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)
> 
applied.
> 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.
> [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>

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

> > > > > false) [1], and have config true pointers from the 
> > > > > higher-level concepts back to the hardware [2].  Possibly with 
> > > > > config false
> > > > back-pointers.
> > > > > 
> > > > > > 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.
> > > > > > >> 
> > > > > > 
> > > > > > 
> > > > > > [We had mail server problems during the weekend, so this 
> > > > > > reply might not get the thread's history right.]
> > > > > > 
> > > > > > > > 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?
> > > > > > > 
> > > > > > > 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:
> > > > > > > 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.
> > > > > > > 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.
> > > > > > 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
> > > > > > > Can you explain in more detail what this means, and 
> > > > > > > provide some use cases?
> > > > > > >
> > > > > > > that "ripple through" to the MDF.  So assume we again have 
> > > > > > > a system with plugable
> > > > > > slots.
> > > > > > > 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

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 05 Sep 2016 15:17:57 +0200 (CEST)

Hi,

Trimming the citations a bit.

"Bogaert, Bart (Nokia - BE)" <[email-masked]> wrote:
> A more realistic (at least in my
> that card.

Can you go through this example in some more details, e.g. show the
data that the operator set (like the XML I showed)?

> The system is able to retrieve this information from an onboard

/martin

---

From: "Bogaert, Bart (Nokia - BE)" <[email-masked]>
Date: Tue, 6 Sep 2016 06:50:02 +0000

"Bogaert, Bart (Nokia - BE)" <[email-masked]> wrote:
> 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.

Can you go through this example in some more details, e.g. show the data
that the operator set (like the XML I showed)?

[Bart Bogaert] Assume we have the following in the device already:
 <entity>
   <physical-entity>
     <model-name>system-1</model-name>
     <class>ianaent:chassis</class>
   </physical-entity>
 </entity>

And assume the following is sent as pre-configuration:
 <entity>
   <physical-entity>
     <model-name>dsl-brd-type1</model-name>
     <class>ianaent:module</class>
     <parent-rel-pos>2</parent-rel-pos>
     <contained-in>system-1</contained-in>
   </physical-entity>
 </entity>

When at a later stage, a board is plugged in the position corresponding to
parent-rel-pos 2, the system is able to detect whether the model-name
corresponds to dsl-brd-type-1 and accepts the pre-configured values.  In
case a different model name is detected (e.g. eth-brd-type-1) a mismatch
alarm is to be raised indicating that an eth-brd-type-1 has been detected
while a dsl-brd-type-1 was expected as the pre-configuration does not match
with the actual configuration.

/Bart

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 06 Sep 2016 08:57:30 +0200 (CEST)

> with the actual configuration.

In these examples, you don't have the <name> key leaf.  It seems that
in the case of containment, you want to be able to use <contained-in>
and <parent-rel-pos> as identification leafs (probably regardless of
which <name> is assigned by the system), and <mode-name> and <class>
as matching leafs?  What about the non-containment case, how would you
do pre-configuration in that case?  Use the <name> anyway?

/martin

---

From: "Bogaert, Bart (Nokia - BE)" <[email-masked]>
Date: Tue, 6 Sep 2016 07:05:49 +0000

"Bogaert, Bart (Nokia - BE)" <[email-masked]> wrote:
> > 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.
> 
> When at a later stage, a board is plugged in the position 
> corresponding to parent-rel-pos 2, the system is able to detect 
> whether the model-name corresponds to dsl-brd-type-1 and accepts the 
> pre-configured values.  In case a different model name is detected 
> (e.g. eth-brd-type-1) a mismatch alarm is to be raised indicating that 
> an eth-brd-type-1 has been detected while a dsl-brd-type-1 was 
> expected as the pre-configuration does not match with the actual
configuration.

In these examples, you don't have the <name> key leaf.  It seems that in the
case of containment, you want to be able to use <contained-in> and
<parent-rel-pos> as identification leafs (probably regardless of which
<name> is assigned by the system), and <mode-name> and <class> as matching
leafs?  What about the non-containment case, how would you do
pre-configuration in that case?  Use the <name> anyway?

[Bart Bogaert] The name leaf has been left out in this example as it is not
"relevant" in this discussion (name can be allocated by the operator or can
be system-generated in some way if needed).  In this example the containment
is relevant as we want subscriber interfaces that will be created to be
linked to the correct port of the correct board.

Not sure what you mean with the "non-containment case" but in that case the
object is referred to by its name (in most cases this will be a key in the
list) but somehow the resource will be part of some kind of stack (be in the
same part of the data tree or in a linked case e.g. using the back-pointer
from the object in the interfaces space to a port in the entity space.

/Bart

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 06 Sep 2016 09:22:29 +0200 (CEST)

> linked to the correct port of the correct board.

The 'name' is relevant since it is the unique identifier of a
component.   In fact, your example is a bit misleading.  In the
current model, the 'contained-in' leaf is a leafref to another
physical-entity's 'name', but in your example it seems it refers to
the 'model-name'.  Note that there can be several physical-entities
with the same 'model-name', so it cannot be used as a unique
identifier.

> from the object in the interfaces space to a port in the entity space.

If the component that we want to (pre)configure is not contained in
anything, we need to use some kind of unique identifier, which
currently is the 'name'.  This requires the operator to be able to
predict the 'name' of any component that he'd like to pre-configure.

If the component is contained in some other component that already is
known, the operator needs to predict the 'parent-rel-pos' of the new
component, but I assume this is ok.

/martin

---

From: "Bogaert, Bart (Nokia - BE)" <[email-masked]>
Date: Tue, 6 Sep 2016 07:31:42 +0000

"Bogaert, Bart (Nokia - BE)" <[email-masked]> wrote:
> > > 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.
> > 
> > (e.g. eth-brd-type-1) a mismatch alarm is to be raised indicating 
> > that an eth-brd-type-1 has been detected while a dsl-brd-type-1 was 
> [Bart Bogaert] The name leaf has been left out in this example as it 
> is not "relevant" in this discussion (name can be allocated by the 
> operator or can be system-generated in some way if needed).  In this 
> example the containment is relevant as we want subscriber interfaces 
> that will be created to be linked to the correct port of the correct
board.

The 'name' is relevant since it is the unique identifier of a
component.   In fact, your example is a bit misleading.  In the
current model, the 'contained-in' leaf is a leafref to another
physical-entity's 'name', but in your example it seems it refers to the
'model-name'.  Note that there can be several physical-entities with the
same 'model-name', so it cannot be used as a unique identifier.
[Bart Bogaert] You are correct, it should have been the name and not the
model-name so as below.  Note that the new leafs in the entity-model are
augmentations proposed by BBF, they are not in the standard entity model.

  <entity>
   <physical-entity>
     <name>system-1</name>
     <model-name>some-model</model-name>
     <class>ianaent:chassis</class>
   </physical-entity>
 </entity>

     <name>dsl-board-1</name>

> Not sure what you mean with the "non-containment case" but in that 
> case the object is referred to by its name (in most cases this will be 
> a key in the
> list) but somehow the resource will be part of some kind of stack (be 
> in the same part of the data tree or in a linked case e.g. using the 
> back-pointer from the object in the interfaces space to a port in the
entity space.

If the component that we want to (pre)configure is not contained in
anything, we need to use some kind of unique identifier, which currently is
the 'name'.  This requires the operator to be able to predict the 'name' of
any component that he'd like to pre-configure.

[Bart Bogaert] I currently can't think of a case like that right now.

/Bart

If the component is contained in some other component that already is known,
the operator needs to predict the 'parent-rel-pos' of the new component, but
I assume this is ok.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 6 Sep 2016 09:37:22 +0200

> with the actual configuration.

What I see here is an attempt to provide a constraint on operational
state which may trigger an alarm from the device if the operational
state is present but different from what was provided as a
constraint. I do not see pre-configuration here.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "Bogaert, Bart (Nokia - BE)" <[email-masked]>
Date: Tue, 6 Sep 2016 07:50:47 +0000

configuration.

What I see here is an attempt to provide a constraint on operational state
which may trigger an alarm from the device if the operational state is
present but different from what was provided as a constraint. I do not see
pre-configuration here.

[Bart Bogaert] When sending a configuration request to a device while there
is no HW physically present yet is what we call pre-provisioning meaning
that the configuration is made up-front in attendance of the HW being
plugged at a later stage.  When the plugged HW does not meet the
pre-configured data I think it is normal that an alarm is raised but that
does not take away the fact that the device was configured in advance.

/Bart

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 06 Sep 2016 09:51:08 +0200 (CEST)

> constraint. I do not see pre-configuration here.

I assumed (maybe incorrectly; Bart?) that the example should have been
something like:

  <entity>
   <physical-entity>
     <name>system-1</name>

 <entity>
   <physical-entity>
     <name>dsl-board-1</name>

     // pre-configuration leafs here

   </physical-entity>
 </entity>

/martin

---

From: "Bogaert, Bart (Nokia - BE)" <[email-masked]>
Date: Tue, 6 Sep 2016 07:57:55 +0000

configuration.
> state is present but different from what was provided as a constraint. 
> I do not see pre-configuration here.

  <entity>
   <physical-entity>
     <name>system-1</name>

 <entity>
   <physical-entity>
     <name>dsl-board-1</name>

   </physical-entity>
 </entity>

[Bart Bogaert] Indeed I did not include more but normally a board contains a
number of ports, these can be part of the pre-configuration too.  All this
data is part of the pre-configuration of a device.  This all depends on the
use case of an operator but there operators working in this mode (at least
we encountered such a way of operating/extending a network with our
SNMP-based devices).

/Bart

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 6 Sep 2016 10:01:13 +0200

> does not take away the fact that the device was configured in advance.

In your example, there is nothing configured as far as I can tell.

The way the interfaces data model supports pre-configuration is by
having a _name binding_; a pre-configured interface is applied once
the name of the pre-configured interfaces matches the name of a
(physical) interface. I think Martin is asking the question whether
the same model of using name bindings can be applied in your case and
if not why not.

/js

---

From: "Bogaert, Bart (Nokia - BE)" <[email-masked]>
Date: Tue, 6 Sep 2016 09:03:38 +0000

On Tue, Sep 06, 2016 at 07:50:47AM +0000, Bogaert, Bart (Nokia - BE) wrote:
> 
> [Bart Bogaert] When sending a configuration request to a device while 
> there is no HW physically present yet is what we call pre-provisioning 
> meaning that the configuration is made up-front in attendance of the 
> HW being plugged at a later stage.  When the plugged HW does not meet 
> the pre-configured data I think it is normal that an alarm is raised 
> but that does not take away the fact that the device was configured in
advance.

The way the interfaces data model supports pre-configuration is by having a
_name binding_; a pre-configured interface is applied once the name of the
pre-configured interfaces matches the name of a
(physical) interface. I think Martin is asking the question whether the same
model of using name bindings can be applied in your case and if not why not.

[Bart Bogaert] I'm afraid I am lost in the names being used here.  Whether
it's called name binding or pre-configuration or still something else, the
key point is that we configure objects in the device prior to them being
physically present, nothing more, nothing less.  The consequence of this
being that these objects should be present in the data tree of the device
and once the HW gets plugged all operational data linked to that comes into
existence too.  I do not know of another way to explain what is intended
with what we call 'pre-configuration'.

/Bart

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 06 Sep 2016 11:38:03 +0200 (CEST)

> with what we call 'pre-configuration'.

I think there are two things that I am trying to understand:

  (i) Identification

      In order to be able to pre configure a component, the operator
      needs a deterministic way to idenfity the component.  How
      exactly is this done?

      One way is to rely on the name of the to-be-present component.
      Another way is to identify its parent by name, and provide a
      parent-rel-pos integer.  (The latter assumes that the parent's
      name is known...)

  (ii) Configuration

      Once a component is identified, what parameters can you
      pre-configure?

      One answer could be "none", which I think is what the examples
      you have provided so far have.  This then would not really be
      pre-configuration, but rather a constraint, as Juergen
      indictated.

/martin

---

From: "Bogaert, Bart (Nokia - BE)" <[email-masked]>
Date: Tue, 6 Sep 2016 10:46:24 +0000

"Bogaert, Bart (Nokia - BE)" <[email-masked]> wrote:
> > [Bart Bogaert] When sending a configuration request to a device 
> > while there is no HW physically present yet is what we call 
> > pre-provisioning meaning that the configuration is made up-front in 
> > attendance of the HW being plugged at a later stage.  When the 
> > plugged HW does not meet the pre-configured data I think it is 
> > normal that an alarm is raised but that does not take away the fact 
> > that the device was configured in
> advance.
> > 
> 
> the same model of using name bindings can be applied in your case and if
not why not.
> 
> [Bart Bogaert] I'm afraid I am lost in the names being used here.  
> Whether it's called name binding or pre-configuration or still 
> something else, the key point is that we configure objects in the 
> device prior to them being physically present, nothing more, nothing 
> less.  The consequence of this being that these objects should be 
> present in the data tree of the device and once the HW gets plugged 
> all operational data linked to that comes into existence too.  I do 
> not know of another way to explain what is intended with what we call
'pre-configuration'.

  (i) Identification

[Bart Bogaert] If we stick to the use case of equipment the
pre-configuration is based on containment and names attributed to the
entities by the operator.  I tried to explain that so far names attributed
to entities have no other meaning then identifying the entity and, as
allocated by the operator, there is nothing to be predicted: it is known.  I
agree that in the case of entities there will be no other special leafs that
require to be configured.

  (ii) Configuration

[Bart Bogaert] As indicated above that might be true for equipment (entity)
objects but pre-configuration could also include definition on top of these
pre-configured ports and in this case there will certainly be configuration
of leafs that are characteristic for the to-be offered service and which
will be defined on top of a port (hence the augment of interfaces with
back-pointer to the port entity).  Also in this case the operator knows
exactly on top of which port the interface will be created.  The name
attributed to the interface has no special meaning to the SW of the device
apart from giving it a unique reference.  The name is set by the network
operator and can basically be anything (that is why I say that it has no
special meaning to the SW in the device).  As the names are set by the
operator there is nothing that requires prediction.  The name-binding as it
is referred to here comes from the model where the leafrefs point to the
name of underlying resource (be it entity or interface).

Maybe we have a different understand of "pre-configuration"?  For me it
simply means that an operator is able to create a configuration in the
device without the HW supporting this configuration being physically present
but is getting stored in the database of the device (I'm explaining it as it
is in our SNMP-based devices).  The configuration gets applied once the
supporting HW is plugged in the device (given the fact that the plugged HW
matches what was previously configured).

/Bart

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 6 Sep 2016 12:56:00 +0200

>       parent-rel-pos integer.  (The latter assumes that the parent's

For interfaces, some implementations carry the information where an
interface is physically located in the interface name. Others generate
(almost) dynamic interface names with no specific meaning (in the
worst case these names change on every reboot). I assume that the
first option works better in many cases. Of course, there are
conceivable situations where you like to bind pre-configuration to an
interface using other properties (e.g., here is an interface
pre-configuration that should be applied to whatever interface has a
certain MAC address) but to support such things one would need a way
more expressive binding mechanism (or a way to rename interfaces on
the fly, i.e., another layer of indirection).

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 06 Sep 2016 13:20:48 +0200 (CEST)

"Bogaert, Bart (Nokia - BE)" <[email-masked]> wrote:
> allocated by the operator, there is nothing to be predicted: it is
> known.

Dut even in your example of simple containment, it works b/c the
operators knows the name of the parent, and the parent-rel-pos.
Right?  So what if you need to pre-configue two levels of containment?
You know the name of the top-level component, so you can pre-configure
the first child.  But then you'll have to know the name of this first
child in order to pre-configure the grand child.

Or are you saying that the system always creates and gives names to
all top-level components, and then the operator or system can given
name to sub-components?

> I

I have a hard time trying to understand what you actually need.  It
now seems that you want to pre-configure some physical entity in order
to be able to refer to it from higher-level models.  Is this correct?
Thus, you don't really want to pre-configure any leafs in the entity
model, except for the name.

Remember that the thread started with a request to have the 'class' and
'contained-in' leafs in the config list physical-entity, and 'class'
being mandatory.

> matches what was previously configured).

Right, this is also my understanding of pre-configuration.

/martin

---

From: "Bogaert, Bart (Nokia - BE)" <[email-masked]>
Date: Tue, 6 Sep 2016 11:30:35 +0000

--- snip ---

> entities by the operator.  I tried to explain that so far names 
> attributed to entities have no other meaning then identifying the 
> entity and, as allocated by the operator, there is nothing to be 
> predicted: it is known.

Dut even in your example of simple containment, it works b/c the operators
knows the name of the parent, and the parent-rel-pos.
Right?  So what if you need to pre-configue two levels of containment?

[Bart Bogaert] As the operator assigns the names, he knows them on all
layers

You know the name of the top-level component, so you can pre-configure the
first child.  But then you'll have to know the name of this first child in
order to pre-configure the grand child.

Or are you saying that the system always creates and gives names to all
top-level components, and then the operator or system can given name to
sub-components?

--- snip ---

> [Bart Bogaert] As indicated above that might be true for equipment 
> (entity) objects but pre-configuration could also include definition 
> on top of these pre-configured ports and in this case there will 
> certainly be configuration of leafs that are characteristic for the 
> to-be offered service and which will be defined on top of a port 
> (hence the augment of interfaces with back-pointer to the port 
> entity).  Also in this case the operator knows exactly on top of which 
> port the interface will be created.  The name attributed to the 
> interface has no special meaning to the SW of the device apart from 
> giving it a unique reference.  The name is set by the network operator 
> and can basically be anything (that is why I say that it has no 
> operator there is nothing that requires prediction.  The name-binding 
> as it is referred to here comes from the model where the leafrefs point to
the name of underlying resource (be it entity or interface).

I have a hard time trying to understand what you actually need.  It now
seems that you want to pre-configure some physical entity in order to be
able to refer to it from higher-level models.  Is this correct?
Thus, you don't really want to pre-configure any leafs in the entity model,
except for the name.

[Bart Bogaert] I agree but these leafs are added with the pre-configuration
use case in mind maybe it drifted a bit off...  I think we can end this
thread here.

/Bart

> Maybe we have a different understand of "pre-configuration"?  For me 
> it simply means that an operator is able to create a configuration in 
> the device without the HW supporting this configuration being 
> physically present but is getting stored in the database of the device 
> (I'm explaining it as it is in our SNMP-based devices).  The 
> configuration gets applied once the supporting HW is plugged in the 
> device (given the fact that the plugged HW matches what was previously
configured).

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 06 Sep 2016 14:24:44 +0200 (CEST)

> [Bart Bogaert] As the operator assigns the names, he knows them on all

Even for the top-level objects?  How would that work?

> use case in mind maybe it drifted a bit off...  I think we can end this

Note that I am trying to understand your use case so that we can add
the required nodes to the data model and the corresponding text.  The
goal is to be able to support your use case.  At this time, I can't
say that I know what to add.

/martin

---

From: "Bogaert, Bart (Nokia - BE)" <[email-masked]>
Date: Tue, 6 Sep 2016 13:23:58 +0000

Martin,

Currently BBF has extended the entity config true part with a number of
leafs allowing the operator to configure entities which are currently
available in the config false section.  The augmentation in the interfaces
model is to allow a coupling between the entity and the interface worlds.
As far as I can see it, we have the required leafs present in the model
allowing the configuration of plugable entities (pre-configuration is not
really relevant in that matter).  The only point of discussion was that some
assumed that the e.g. the class leaf would be mandatory but you can't just
make a leaf mandatory in an augment.  If you include the new leafs in a
container one could use a presence statement to allow the mandatory keyword.

Best regards, Bart

-----Original Message-----
From: Martin Bjorklund [mailto:[email-masked]] 
Sent: 06 September 2016 14:25
To: Bogaert, Bart (Nokia - BE)
Cc: [email-masked]; [email-masked]
Subject: Re: [netmod] BBF extensions to ietf-entity

"Bogaert, Bart (Nokia - BE)" <[email-masked]> wrote:
> > pre-configuration is based on containment and names attributed to 
> > the entities by the operator.  I tried to explain that so far names 

> > entity).  Also in this case the operator knows exactly on top of 
> > which port the interface will be created.  The name attributed to 
> > the interface has no special meaning to the SW of the device apart 
> > from giving it a unique reference.  The name is set by the network 
> > operator and can basically be anything (that is why I say that it 
> > has no special meaning to the SW in the device).  As the names are 
> > set by the operator there is nothing that requires prediction.  The 
> > name-binding as it is referred to here comes from the model where 
> > the leafrefs point to
> Remember that the thread started with a request to have the 'class' 
> and 'contained-in' leafs in the config list physical-entity, and 'class'
> being mandatory.
> 
> [Bart Bogaert] I agree but these leafs are added with the 
> pre-configuration use case in mind maybe it drifted a bit off...  I 
> think we can end this thread here.

Note that I am trying to understand your use case so that we can add the
required nodes to the data model and the corresponding text.  The goal is to
be able to support your use case.  At this time, I can't say that I know
what to add.

/martin

> > it simply means that an operator is able to create a configuration 
> > in the device without the HW supporting this configuration being 
> > physically present but is getting stored in the database of the 
> > device (I'm explaining it as it is in our SNMP-based devices).  The

---

From: Randy Presuhn <[email-masked]>
Date: Tue, 6 Sep 2016 13:09:20 -0700

Hi -

>       parent-rel-pos integer.  (The latter assumes that the parent's

I the systems I worked on, naming was within the context of the
containing object. But an important point was that in those systems,
we considered slots (even empty ones) to be objects.  One could write
a surprising amount on the advantages of doing so.

The names of the provisioned objects (within the context of their
container) were in generally administratively assigned, that is,
they were configuration data.

>       Once a component is identified, what parameters can you

Anything that could be configured.

>       pre-configuration, but rather a constraint, as Juergen

In the context of those products I worked on (telephony multiplexors,
X.25 switches, SNA gateways, etc.) there were generally oodles of
configurable parameters for every port on every line card.  Since we
had hot-swappable line cards and even hot-insertion extension chassis,
anything that could be configured had to be provisionable.  Of course, 
that was thirty years, and times change.

Randy

---

From: Andy Bierman <[email-masked]>
Date: Tue, 6 Sep 2016 17:06:38 -0700

Hi,

I don't think the WG should be that concerned with other modules
that configure hardware.  If there are individual leafs that we should
standardize for configuration in the IETF module then they can be discussed
on the mailing list.

An external module can use leafref instead of augment, which has no
restriction against adding mandatory configuration parameters.

Andy

On Tue, Sep 6, 2016 at 6:23 AM, Bogaert, Bart (Nokia - BE) <
[email-masked]> wrote:

> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>
>

---

From: Dan Romascanu <[email-masked]>
Date: Wed, 7 Sep 2016 09:27:45 +0300

Just to add to what Andy and other said. I also believe that we should
keep the entity module simpler. The discussions currently taking place
remind me similar discussions two decades ago, when we started from a
more complex MIB module that included physical and logical entities
and the mapping in-between, and we reached the conclusion that
focusing on configuration and state of the physical entities is a more
pragmatic way of progressing that work (and this happened before the
era of virtualization, pre-configuration, etc). We may want to do the
same now, and work individual leafs separately.

Regards,

Dan

On Wed, Sep 7, 2016 at 3:06 AM, Andy Bierman <[email-masked]> wrote:
> On Tue, Sep 6, 2016 at 6:23 AM, Bogaert, Bart (Nokia - BE)
> <[email-masked]> wrote:
>>
>> Martin,
>>

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 07 Sep 2016 08:53:12 +0200 (CEST)

Andy Bierman <[email-masked]> wrote:
> that configure hardware.

Agreed.  But the current discussion is about getting the base model
right so that it allows for such other modules to augment/leafref the
base model.  The question right now is if the base model should
support pre-configuration.  If the answer is "no", we're done (maybe
make this decision explicit in the document).  If the answer is "yes",
we need to solve the "identification" part.

/martin

> If there are individual leafs that we should