Re: [netmod] BBF extensions to ietf-entity

[Martin Bjorklund]

Andy Bierman  wrote:
> Hi,
> 
> 
> I don't think the WG should be that concerned with other modules
> 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
> 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) <
> bart.boga...@nokia.com> wrote:
> 
> > 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:m...@tail-f.com]
> > Sent: 06 September 2016 14:25
> > To: Bogaert, Bart (Nokia - BE)
> > Cc: j.schoenwael...@jacobs-university.de; netmod@ietf.org
> > Subject: Re: [netmod] BBF extensions to ietf-entity
> >
> > "Bogaert, Bart (Nokia - BE)"  wrote:
> > > --- snip ---
> > >
> > > > [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.
> > >
> > > 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
> >
> > Even for the top-level objects?  How would that work?
> >
> > > 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 special meaning to the SW in the device).  As the names are
> > > > set by the operator there is nothing that requires pr

Re: [netmod] BBF extensions to ietf-entity

[Dan Romascanu]

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  wrote:
> 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)
>  wrote:
>>
>> 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:m...@tail-f.com]
>> Sent: 06 September 2016 14:25
>> To: Bogaert, Bart (Nokia - BE)
>> Cc: j.schoenwael...@jacobs-university.de; netmod@ietf.org
>> Subject: Re: [netmod] BBF extensions to ietf-entity
>>
>> "Bogaert, Bart (Nokia - BE)"  wrote:
>> > --- snip ---
>> >
>> > > [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.
>> >
>> > 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
>>
>> Even for the top-level objects?  How would that work?
>>
>> > 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 special meaning to the SW in the 

Re: [netmod] BBF extensions to ietf-entity

[Andy Bierman]

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) <
bart.boga...@nokia.com> wrote:

> 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:m...@tail-f.com]
> Sent: 06 September 2016 14:25
> To: Bogaert, Bart (Nokia - BE)
> Cc: j.schoenwael...@jacobs-university.de; netmod@ietf.org
> Subject: Re: [netmod] BBF extensions to ietf-entity
>
> "Bogaert, Bart (Nokia - BE)"  wrote:
> > --- snip ---
> >
> > > [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.
> >
> > 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
>
> Even for the top-level objects?  How would that work?
>
> > 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 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).
> >
> > 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.
> >
> > [Bart Bogaert] I agree but these leafs are added with the
> > pre-configuratio

Re: [netmod] BBF extensions to ietf-entity

[Randy Presuhn]

Hi -

On 9/6/2016 2:38 AM, Martin Bjorklund wrote:

"Bogaert, Bart (Nokia - BE)"  wrote:

On Tue, Sep 06, 2016 at 07:50:47AM +, 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.




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.

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


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.


  (ii) Configuration

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


Anything that could be configured.


  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.


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

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] BBF extensions to ietf-entity

[Bogaert, Bart (Nokia - BE)]

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:m...@tail-f.com] 
Sent: 06 September 2016 14:25
To: Bogaert, Bart (Nokia - BE)
Cc: j.schoenwael...@jacobs-university.de; netmod@ietf.org
Subject: Re: [netmod] BBF extensions to ietf-entity

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

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

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




> 
> /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).
> 
> Right, this is also my understanding of pre-configuration.
> 
> 
> /martin


smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] BBF extensions to ietf-entity

[Martin Bjorklund]

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

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

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




> 
> /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).
> 
> Right, this is also my understanding of pre-configuration.
> 
> 
> /martin

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] BBF extensions to ietf-entity

[Bogaert, Bart (Nokia - BE)]

--- snip ---

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

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

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.

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

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


/martin


smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] BBF extensions to ietf-entity

[Martin Bjorklund]

"Bogaert, Bart (Nokia - BE)"  wrote:
> "Bogaert, Bart (Nokia - BE)"  wrote:
> > On Tue, Sep 06, 2016 at 07:50:47AM +, 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.
> > > 
> > 
> > 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.
> > 
> > [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 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...)
> 
> [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.

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
> agree that in the case of entities there will be no other special leafs that
> require to be configured.
> 
>   (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.
> 
> [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).

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

Re: [netmod] BBF extensions to ietf-entity

[Juergen Schoenwaelder]

On Tue, Sep 06, 2016 at 11:38:03AM +0200, Martin Bjorklund wrote:
> 
> 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...)

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

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] BBF extensions to ietf-entity

[Bogaert, Bart (Nokia - BE)]

"Bogaert, Bart (Nokia - BE)"  wrote:
> On Tue, Sep 06, 2016 at 07:50:47AM +, 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.
> > 
> 
> 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.
> 
> [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 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...)

[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

  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.

[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


smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] BBF extensions to ietf-entity

[Martin Bjorklund]

"Bogaert, Bart (Nokia - BE)"  wrote:
> On Tue, Sep 06, 2016 at 07:50:47AM +, 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.
> > 
> 
> 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.
> 
> [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 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

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] BBF extensions to ietf-entity

[Bogaert, Bart (Nokia - BE)]

On Tue, Sep 06, 2016 at 07:50:47AM +, 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.
> 

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.

[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

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 


smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] BBF extensions to ietf-entity

[Juergen Schoenwaelder]

On Tue, Sep 06, 2016 at 07:50:47AM +, 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.
> 

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

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] BBF extensions to ietf-entity

[Bogaert, Bart (Nokia - BE)]

Juergen Schoenwaelder  wrote:
> On Tue, Sep 06, 2016 at 06:50:02AM +, Bogaert, Bart (Nokia - BE)
wrote:
> > 
> > [Bart Bogaert] Assume we have the following in the device already:
> >  
> >
> >  system-1
> >  ianaent:chassis
> >
> >  
> > 
> > And assume the following is sent as pre-configuration:
> >  
> >
> >  dsl-brd-type1
> >  ianaent:module
> >  2
> >  system-1
> >
> >  
> > 
> > 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.
> 
> 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.

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

  
   
 system-1
 some-model
 ianaent:chassis
   
 

 
   
 dsl-board-1
 dsl-brd-type1
 ianaent:module
 2
 system-1

 // pre-configuration leafs here

   
 

[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


smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] BBF extensions to ietf-entity

[Martin Bjorklund]

Juergen Schoenwaelder  wrote:
> On Tue, Sep 06, 2016 at 06:50:02AM +, Bogaert, Bart (Nokia - BE) wrote:
> > 
> > [Bart Bogaert] Assume we have the following in the device already:
> >  
> >
> >  system-1
> >  ianaent:chassis
> >
> >  
> > 
> > And assume the following is sent as pre-configuration:
> >  
> >
> >  dsl-brd-type1
> >  ianaent:module
> >  2
> >  system-1
> >
> >  
> > 
> > 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.
> 
> 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.

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

  
   
 system-1
 some-model
 ianaent:chassis
   
 

 
   
 dsl-board-1
 dsl-brd-type1
 ianaent:module
 2
 system-1

 // pre-configuration leafs here

   
 


/martin

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] BBF extensions to ietf-entity

[Bogaert, Bart (Nokia - BE)]

> 
> [Bart Bogaert] Assume we have the following in the device already:
>  
>
>  system-1
>  ianaent:chassis
>
>  
> 
> And assume the following is sent as pre-configuration:
>  
>
>  dsl-brd-type1
>  ianaent:module
>  2
>  system-1
>
>  
> 
> 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.

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

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 


smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] BBF extensions to ietf-entity

[Juergen Schoenwaelder]

On Tue, Sep 06, 2016 at 06:50:02AM +, Bogaert, Bart (Nokia - BE) wrote:
> 
> [Bart Bogaert] Assume we have the following in the device already:
>  
>
>  system-1
>  ianaent:chassis
>
>  
> 
> And assume the following is sent as pre-configuration:
>  
>
>  dsl-brd-type1
>  ianaent:module
>  2
>  system-1
>
>  
> 
> 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.

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 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] BBF extensions to ietf-entity

[Bogaert, Bart (Nokia - BE)]

"Bogaert, Bart (Nokia - BE)"  wrote:
> "Bogaert, Bart (Nokia - BE)"  wrote:
> > "Bogaert, Bart (Nokia - BE)"  wrote:
> > > 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.
> > 
> > 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:
> >  
> >
> >  system-1
> >  ianaent:chassis
> >
> >  
> > 
> > And assume the following is sent as pre-configuration:
> >  
> >
> >  dsl-brd-type1
> >  ianaent:module
> >  2
> >  system-1
> >
> >  
> > 
> > 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  key leaf.  It seems that 
> in the case of containment, you want to be able to use  
> and  as identification leafs (probably regardless of 
> which  is assigned by the system), and  and  
> as matching leafs?  What about the non-containment case, how would you 
> do pre-configuration in that case?  Use the  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.

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.

  
   
 system-1
 some-model
 ianaent:chassis
   
 

And assume the following is sent as pre-configuration:
 
   
 dsl-board-1
 dsl-brd-type1
 ianaent:module
 2
 system-1
   
 

> 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


smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] BBF extensions to ietf-entity

[Martin Bjorklund]

"Bogaert, Bart (Nokia - BE)"  wrote:
> "Bogaert, Bart (Nokia - BE)"  wrote:
> > "Bogaert, Bart (Nokia - BE)"  wrote:
> > > 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.
> > 
> > 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:
> >  
> >
> >  system-1
> >  ianaent:chassis
> >
> >  
> > 
> > And assume the following is sent as pre-configuration:
> >  
> >
> >  dsl-brd-type1
> >  ianaent:module
> >  2
> >  system-1
> >
> >  
> > 
> > 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  key leaf.  It seems that in the
> case of containment, you want to be able to use  and
>  as identification leafs (probably regardless of which
>  is assigned by the system), and  and  as matching
> leafs?  What about the non-containment case, how would you do
> pre-configuration in that case?  Use the  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.

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.

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

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

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] BBF extensions to ietf-entity

[Bogaert, Bart (Nokia - BE)]

"Bogaert, Bart (Nokia - BE)"  wrote:
> "Bogaert, Bart (Nokia - BE)"  wrote:
> > 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.
> 
> 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:
>  
>
>  system-1
>  ianaent:chassis
>
>  
> 
> And assume the following is sent as pre-configuration:
>  
>
>  dsl-brd-type1
>  ianaent:module
>  2
>  system-1
>
>  
> 
> 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  key leaf.  It seems that in the
case of containment, you want to be able to use  and
 as identification leafs (probably regardless of which
 is assigned by the system), and  and  as matching
leafs?  What about the non-containment case, how would you do
pre-configuration in that case?  Use the  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


smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] BBF extensions to ietf-entity

[Martin Bjorklund]

"Bogaert, Bart (Nokia - BE)"  wrote:
> "Bogaert, Bart (Nokia - BE)"  wrote:
> > 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.
> 
> 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:
>  
>
>  system-1
>  ianaent:chassis
>
>  
> 
> And assume the following is sent as pre-configuration:
>  
>
>  dsl-brd-type1
>  ianaent:module
>  2
>  system-1
>
>  
> 
> 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  key leaf.  It seems that
in the case of containment, you want to be able to use 
and  as identification leafs (probably regardless of
which  is assigned by the system), and  and 
as matching leafs?  What about the non-containment case, how would you
do pre-configuration in that case?  Use the  anyway?


/martin

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] BBF extensions to ietf-entity

[Bogaert, Bart (Nokia - BE)]

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

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:
 
   
 system-1
 ianaent:chassis
   
 

And assume the following is sent as pre-configuration:
 
   
 dsl-brd-type1
 ianaent:module
 2
 system-1
   
 

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


smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] BBF extensions to ietf-entity

[Martin Bjorklund]

Hi,

Trimming the citations a bit.

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

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


/martin

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] BBF extensions to ietf-entity

[Bogaert, Bart (Nokia - BE)]

> "Bogaert, Bart (Nokia - BE)"  wrote:
> > "Bogaert, Bart (Nokia - BE)"  wrote:
> > > Hi Martin,
> > > 
> > > "Bogaert, Bart (Nokia - BE)"  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)"  wrote:
> > > > > "Bogaert, Bart (Nokia - BE)"  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 

Re: [netmod] BBF extensions to ietf-entity

[Martin Bjorklund]

"Bogaert, Bart (Nokia - BE)"  wrote:
> "Bogaert, Bart (Nokia - BE)"  wrote:
> > "Bogaert, Bart (Nokia - BE)"  wrote:
> > > Hi Martin,
> > > 
> > > "Bogaert, Bart (Nokia - BE)"  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)"  wrote:
> > > > > "Bogaert, Bart (Nokia - BE)"  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 

Re: [netmod] BBF extensions to ietf-entity

[Bogaert, Bart (Nokia - BE)]

"Bogaert, Bart (Nokia - BE)"  wrote:
> "Bogaert, Bart (Nokia - BE)"  wrote:
> > Hi Martin,
> > 
> > "Bogaert, Bart (Nokia - BE)"  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)"  wrote:
> > > > "Bogaert, Bart (Nokia - BE)"  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 servic

Re: [netmod] BBF extensions to ietf-entity

[Martin Bjorklund]

"Bogaert, Bart (Nokia - BE)"  wrote:
> "Bogaert, Bart (Nokia - BE)"  wrote:
> > Hi Martin,
> > 
> > "Bogaert, Bart (Nokia - BE)"  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)"  wrote:
> > > > "Bogaert, Bart (Nokia - BE)"  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.

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 nee

Re: [netmod] BBF extensions to ietf-entity

[Bogaert, Bart (Nokia - BE)]

"Bogaert, Bart (Nokia - BE)"  wrote:
> Hi Martin,
> 
> "Bogaert, Bart (Nokia - BE)"  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)"  wrote:
> > > "Bogaert, Bart (Nokia - BE)"  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)

/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

Re: [netmod] BBF extensions to ietf-entity

[Martin Bjorklund]

"Bogaert, Bart (Nokia - BE)"  wrote:
> Hi Martin,
> 
> "Bogaert, Bart (Nokia - BE)"  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)"  wrote:
> > > "Bogaert, Bart (Nokia - BE)"  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?


/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
> > > > (+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 o

Re: [netmod] BBF extensions to ietf-entity

[Bogaert, Bart (Nokia - BE)]

Hi Martin,

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


/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)"  wrote:
> > > > Martin Bjorklund  wrote:
> > > > "Bogaert, Bart (Nokia - BE)"  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
> > > > > addi

Re: [netmod] BBF extensions to ietf-entity

[Martin Bjorklund]

"Bogaert, Bart (Nokia - BE)"  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)"  wrote:
> > "Bogaert, Bart (Nokia - BE)"  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)"  wrote:
> > > > Martin Bjorklund  wrote:
> > > > "Bogaert, Bart (Nokia - BE)"  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

Re: [netmod] BBF extensions to ietf-entity

[Bogaert, Bart (Nokia - BE)]

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)"  wrote:
> "Bogaert, Bart (Nokia - BE)"  wrote:
> > Hi Martin,
> > 
> > In BBF this pointer from HW to interface will be available (it has 
> > been proposed in the Berling BBF meeting already).
> 
> I assume this is done as an augmentation?  Is it an augmentation to 
> the interface list, or to the hardware list?  I.e., is it a pointer 
> from an interface to the hardware, or the other way around?
> [Bart Bogaert] It is an augmentation to the hardware list

Ok.  Would it be possible to have the pointer the other way around?
If not, why?

[Bart Bogaert] So you mean from entity to interfaces?  Similar to the
"stack" in interfaces we assumed it more logical to point from the higher to
the lower layer.  That is the reason why the reference is from the interface
to the entity.

Bart


/martin


> 
> Bart
> 
> I would prefer to view the hardware list as just monitoring (config
> false) [1], and have config true pointers from the higher-level 
> concepts back to the hardware [2].  Possibly with config false
back-pointers.
> 
> [1] this doesn't preclude the config true list in current ietf-entity.
> 
> [2] this pointer is (as noted) often implicit in the interface name today.
> 
> 
> /martin
> 
> 
> 
> 
> 
> > 
> > Best regards - Vriendelijke groeten, Bart Bogaert Broadband-Access 
> > System Architect Data Contact number +32 3 2408310
> > (+32 477 673952)
> > 
> > NOKIA
> > Copernicuslaan 50, 2018 Antwerp, Belgium Fortis 220-0002334-42 VAT 
> > BE
> > 0404 621 642 Register of Legal Entities Antwerp
> > 
> > <<
> > This message (including any attachments) contains confidential 
> > information intended for a specific individual and purpose, and is 
> > protected by law. If you are not the intended recipient, you should 
> > delete this message. Any disclosure, copying, or distribution of 
> > this message, or the taking of any action based on it, is strictly 
> > prohibited without the prior consent of its author.
> > >> 
> > 
> > 
> > -Original Message-
> > From: Martin Bjorklund [mailto: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)"  wrote:
> > > Martin Bjorklund  wrote:
> > > "Bogaert, Bart (Nokia - BE)"  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
> > > 

Re: [netmod] BBF extensions to ietf-entity

[Martin Bjorklund]

"Bogaert, Bart (Nokia - BE)"  wrote:
> "Bogaert, Bart (Nokia - BE)"  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: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)"  wrote:
> > > Martin Bjorklund  wrote:
> > > "Bogaert, Bart (Nokia - BE)"  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 d

Re: [netmod] BBF extensions to ietf-entity

[Athanasios Kyparlis]

Configuring hardware entities is the pre-provisioning use case. 
As Bart described, it's quite important for rollouts and field operations.

I support the addition of stacking capability in the config=true /entity branch.

Thanks,
Athanasios Kyparlis

-Original Message-
From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Juergen Schoenwaelder
Sent: Monday, August 1, 2016 5:53 AM
To: William Lupton 
Cc: netmod@ietf.org
Subject: Re: [netmod] BBF extensions to ietf-entity

On Mon, Aug 01, 2016 at 10:48:01AM +0100, William Lupton wrote:
> Sorry, I was talking only about the interface _stack_ configuration. Ref RFC 
> 7223 Section 3.3:
> 
> While the interface layering is configured in interface-type-specific models, 
> two generic state data leaf-lists, "higher-layer-if” and "lower-layer-if", 
> represent a read-only view of the interface layering hierarchy.
> 
> I was just wondering whether configuration of entity relationships might be 
> analogous.
> 

Once question is what does it means to configure hardware entities.

Or to ask the question differently, perhaps BBF really intents to configure 
interfaces instead of phsyical ports.

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

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] BBF extensions to ietf-entity

[Athanasios Kyparlis]

>"But we then hit a problem for the 'top-level' entity which not contained in 
>anything (and 'fooling' >the model by having it pointing to itself is not 
>allowed).  "
One possible solution is to have a list of top elements:

  augment "/ent:entity-state" {
description "Adding the list of root nodes in HW hierarchy";
leaf-list top-elems {
  type leafref {
path "/ent:entity-state/ent:physical-entity/ent:name";
  }
  description "The list of root elements in the entity hierarchy";
}
  }

  augment "/ent:entity" {
description "Adding the list of root nodes in HW hierarchy";
leaf-list top-elems {
  type leafref {
path "/ent:entity/ent:physical-entity/ent:name";
  }
  description "The list of root elements in the entity hierarchy";
}
  }

In addition, this allows one to traverse the HW hierarchy without a search.

Thanks,
Athanasios Kyparlis

From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Bogaert, Bart (Nokia 
- BE)
Sent: Friday, July 29, 2016 10:05 AM
To: netmod@ietf.org
Subject: [netmod] BBF extensions to ietf-entity

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.

-contained-in: for plugable items contained-in requires to be mandatory 
too as a plugable item can't be "floating" in the device.  But we then hit a 
problem for the 'top-level' entity which not contained in anything (and 
'fooling' the model by having it pointing to itself is not allowed).  
Contained-in can't be derived by the NC server: what to do if 2 entities of the 
same class are preprovisioned (together with ports and interfaces related to 
subscribers)?  We need to be sure that the subscribers are on the intended 
ports.

This would mean that the ietf-entity model would require a revision to add 
leafs for these plugable items.  What is the best way to address this?

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

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] BBF extensions to ietf-entity

[Bogaert, Bart (Nokia - BE)]

"Bogaert, Bart (Nokia - BE)"  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

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)"  wrote:
> > Martin Bjorklund  wrote:
> > "Bogaert, Bart (Nokia - BE)"  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 

Re: [netmod] BBF extensions to ietf-entity

[Martin Bjorklund]

"Bogaert, Bart (Nokia - BE)"  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?

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)"  wrote:
> > Martin Bjorklund  wrote:
> > "Bogaert, Bart (Nokia - BE)"  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 

Re: [netmod] BBF extensions to ietf-entity

[Bogaert, Bart (Nokia - BE)]

Hi Martin,

In BBF this pointer from HW to interface will be available (it has been
proposed in the Berling BBF meeting already).

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)"  wrote:
> Martin Bjorklund  wrote:
> "Bogaert, Bart (Nokia - BE)"  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

Re: [netmod] BBF extensions to ietf-entity

[Martin Bjorklund]

Hi,

[We had mail server problems during the weekend, so this reply might
not get the thread's history right.]

"Bogaert, Bart (Nokia - BE)"  wrote:
> Martin Bjorklund  wrote:
> "Bogaert, Bart (Nokia - BE)"  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

Re: [netmod] BBF extensions to ietf-entity

[Bogaert, Bart (Nokia - BE)]

HI Martin,


"Bogaert, Bart (Nokia - BE)"  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).

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.

Hope this clarifies a bit more.

Best regards,

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


smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] BBF extensions to ietf-entity

[Martin Bjorklund]

Hi,

"Bogaert, Bart (Nokia - BE)"  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?

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


/martin

> But we
> then hit a problem for the 'top-level' entity which not contained in
> anything (and 'fooling' the model by having it pointing to itself is not
> allowed).  Contained-in can't be derived by the NC server: what to do if 2
> entities of the same class are preprovisioned (together with ports and
> interfaces related to subscribers)?  We need to be sure that the subscribers
> are on the intended ports.
> 
>  
> 
> This would mean that the ietf-entity model would require a revision to add
> leafs for these plugable items.  What is the best way to address this?
> 
>  
> 
> 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.
> >> 
> 
>  
> 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] BBF extensions to ietf-entity

[Juergen Schoenwaelder]

On Mon, Aug 01, 2016 at 10:48:01AM +0100, William Lupton wrote:
> Sorry, I was talking only about the interface _stack_ configuration. Ref RFC 
> 7223 Section 3.3:
> 
> While the interface layering is configured in interface-type-specific models, 
> two generic state data leaf-lists, "higher-layer-if” and "lower-layer-if", 
> represent a read-only view of the interface layering hierarchy.
> 
> I was just wondering whether configuration of entity relationships might be 
> analogous.
> 

Once question is what does it means to configure hardware entities.

Or to ask the question differently, perhaps BBF really intents to
configure interfaces instead of phsyical ports.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] BBF extensions to ietf-entity

[William Lupton]

Sorry, I was talking only about the interface _stack_ configuration. Ref RFC 
7223 Section 3.3:

While the interface layering is configured in interface-type-specific models, 
two generic state data leaf-lists, "higher-layer-if” and "lower-layer-if", 
represent a read-only view of the interface layering hierarchy.

I was just wondering whether configuration of entity relationships might be 
analogous.

> On 1 Aug 2016, at 10:42, Juergen Schoenwaelder 
>  wrote:
> 
> On Mon, Aug 01, 2016 at 10:13:38AM +0100, William Lupton wrote:
>> 
>> There seems to be an analogy with interfaces here. The ietf-interfaces 
>> module provides only a read-only view of the interface stack, and interface 
>> type-specific modules are expected to provide a means of configuring the 
>> stack for interfaces of that type (where necessary).
> 
> This is not correct. The ietf-interfaces modules allows you to
> configure/create interfaces, including interfaces that are not
> currently present.

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] BBF extensions to ietf-entity

[Juergen Schoenwaelder]

On Mon, Aug 01, 2016 at 10:13:38AM +0100, William Lupton wrote:
> 
> There seems to be an analogy with interfaces here. The ietf-interfaces module 
> provides only a read-only view of the interface stack, and interface 
> type-specific modules are expected to provide a means of configuring the 
> stack for interfaces of that type (where necessary).
>

This is not correct. The ietf-interfaces modules allows you to
configure/create interfaces, including interfaces that are not
currently present.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] BBF extensions to ietf-entity

[Bogaert, Bart (Nokia - BE)]

William,

 

Not sure how this can be done in all cases.  Assume we have a box that allows 
‘n’ boards to be plugged in slots 1..n.  During pre-provisioning we configure 2 
boards of the same type, one in slot 1 and another in slot 2.  We also 
pre-provision the ports and allocate subscriber interfaces and assign data 
specific to these subscribers (so in a way this will be related to e.g. how the 
ports are wired via an MDF).  The device is not really able to determine by 
itself which board is contained in slot 1 (supporting the subscribers that are 
wired via MDF to terminate on this board) and the other to the board in slot 2. 
 The only way the device would be able to do so autonomously would be when e.g. 
a serial number related to the boards is provided by the operator when 
pre-provisioning the board.  The serial number is retrievable from the 
inventory information present in the board and hence the device could relate a 
board to a specific slot.  However… when the board gets broken it is 
temporarily (or even permanently in case the board is really broken) replaced 
by another board of the same type but with a different serial number.  This 
would then mean that the operator also needs to modify that serial number since 
the serial number in the inventory no longer matches the one entered by the 
operator when configuring the board (it is not really expected/allowed that the 
NC server would modify the RW data for that board).

 

Not really sure this is an elegant way of exposing this serial number 
management to a network operator.  So don’t we need a mechanism via 
configuration (i.e. R/W leafs) to configure this “containment” ?

 

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

 

From: William Lupton [mailto:wlup...@broadband-forum.org] 
Sent: 01 August 2016 11:14
To: Bogaert, Bart (Nokia - BE)
Cc: netmod@ietf.org
Subject: Re: [netmod] BBF extensions to ietf-entity

 

Maybe configuration of the entity tree for pluggable items should be handled 
via augmentations that are specific to pluggable items?

 

There seems to be an analogy with interfaces here. The ietf-interfaces module 
provides only a read-only view of the interface stack, and interface 
type-specific modules are expected to provide a means of configuring the stack 
for interfaces of that type (where necessary).

 

William

 

On 29 Jul 2016, at 15:04, Bogaert, Bart (Nokia - BE)  
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.

-  contained-in: for plugable items contained-in requires to be 
mandatory too as a plugable item can’t be “floating” in the device.  But we 
then hit a problem for the ‘top-level’ entity which not contained in anything 
(and ‘fooling’ the model by having it pointing to itself is not allowed).  
Contained-in can’t be derived by the NC server: what to do if 2 entities of the 
same class are preprovisioned (together with ports and interfaces related to 
subscribers)?  We need to be sure that the subscribers are on the intended 
ports.

 

This would mean that the ietf-entity model would require a revision to add 
leafs for these plugable items.  What is the best way to address this?

 

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 

Re: [netmod] BBF extensions to ietf-entity

[William Lupton]

Maybe configuration of the entity tree for pluggable items should be handled 
via augmentations that are specific to pluggable items?

There seems to be an analogy with interfaces here. The ietf-interfaces module 
provides only a read-only view of the interface stack, and interface 
type-specific modules are expected to provide a means of configuring the stack 
for interfaces of that type (where necessary).

William

> On 29 Jul 2016, at 15:04, Bogaert, Bart (Nokia - BE)  
> 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.
> -  contained-in: for plugable items contained-in requires to be 
> mandatory too as a plugable item can’t be “floating” in the device.  But we 
> then hit a problem for the ‘top-level’ entity which not contained in anything 
> (and ‘fooling’ the model by having it pointing to itself is not allowed).  
> Contained-in can’t be derived by the NC server: what to do if 2 entities of 
> the same class are preprovisioned (together with ports and interfaces related 
> to subscribers)?  We need to be sure that the subscribers are on the intended 
> ports.
>  
> This would mean that the ietf-entity model would require a revision to add 
> leafs for these plugable items.  What is the best way to address this?
>  
> 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.
> >>
>  
> ___
> netmod mailing list
> netmod@ietf.org 
> https://www.ietf.org/mailman/listinfo/netmod 
> 
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod