Subject: Re: [netmod] I-D Action: draft-ietf-netmod-entity-02.txt

From: Martin Bjorklund <[email-masked]>
Date: Tue, 07 Mar 2017 19:41:47 +0100 (CET)

"Bogaert, Bart (Nokia - BE)" <[email-masked]> wrote:
> -----Original Message-----
> From: Martin Bjorklund [mailto:[email-masked]] 
> Sent: 24 January 2017 11:37
> To: Bogaert, Bart (Nokia - BE) <[email-masked]>
> Cc: [email-masked]; [email-masked]
> Subject: Re: [netmod] I-D Action: draft-ietf-netmod-entity-02.txt
> 
> "Bogaert, Bart (Nokia - BE)" <[email-masked]> wrote:
> > One more comment: 
> > 
> > The BBF proposal defines 'contained-in' as a leafref, the current 
> > version of the hardware model has defined 'parent' as a string.  In 
> > the state container parent is defined as a leafref.  Parent type 
> > should be the same in both config and state container.
> 
> The reason for the 'string' in the config tree is that when it is
> pre-configured, it doesn't really refer to a component in the state tree.
> If it eventually matches a real component, the server will instantiate an
> entry in the state tree, and at this point the parent
> *is* a proper reference to another component.
> 
> Note that the underlying type is the same in both cases.
> [Bart Bogaert] Having it as leafref allows to verify that the parent being
> configured is actually existing in the entity model (or defined in the same
> transaction).  Why would we remove the modelling capability to check this
> consistency?

Do you mean a leafref to /hardware/component/name or
/hardware-state/component/name?

If we pick the former, it will not be possible to configure a
component with a system controlled parent (unless you also add the
system controlled parent to the configuration).

If we pick the latter you will not get any validation (since it has to
be require-instance false).

It is fine w/ me to change the type string to a leafref of the former
type.

/martin

---

From: "Bogaert, Bart (Nokia - BE)" <[email-masked]>
Date: Wed, 8 Mar 2017 10:18:07 +0000

Hi Martin,

> If it eventually matches a real component, the server will instantiate 
> an entry in the state tree, and at this point the parent
> [Bart Bogaert] Having it as leafref allows to verify that the parent 
> being configured is actually existing in the entity model (or defined 
> in the same transaction).  Why would we remove the modelling 
> capability to check this consistency?

Do you mean a leafref to /hardware/component/name or
/hardware-state/component/name?
[Bart Bogaert] I was referring to /hardware/component, so parent is a
leafref to /hardware/component/name.  In /hardware-state it is a leafref to
/hardware-state/component/name

If we pick the former, it will not be possible to configure a component with
a system controlled parent (unless you also add the system controlled parent
to the configuration).
[Bart Bogaert] Is there a reason to only have this parent in the state tree
and not in the config tree?

If we pick the latter you will not get any validation (since it has to be
require-instance false).

It is fine w/ me to change the type string to a leafref of the former type.
[Bart Bogaert] If we leave it as a string it would mean that an external
application would have to check whether the value of the string actually
corresponds to a component that should exist (in the case of a
non-system-controlled parent)?

Regards, Bart

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 08 Mar 2017 14:07:30 +0100 (CET)

> /hardware-state/component/name

Ok.

> and not in the config tree?

I am not sure I understand the question.  Suppose the config tree is
empty, and the system boots and populates the state tree with all
detected harwdare.  Next, a client would like to pre-provision a
module in a chassis that exists in state.  If the leafref is to the
config tree, the client would have to create both the chassis and the
module in the config tree, since the leafef would otherwise fail to
validate.

> It is fine w/ me to change the type string to a leafref of the former type.

Correction: I am fine with changing the string to a leafref to state.

> non-system-controlled parent)?

So are you ok with a leafref to state?

/martin

---

From: Kent Watsen <[email-masked]>
Date: Wed, 8 Mar 2017 14:06:25 +0000

> Correction: I am fine with changing the string to a leafref to state.

This conversation seems to mirrors the we had regarding the i2rs 
topologoy model, where we landed on a leafref in 'running' could
point to a config true node in 'operational-state', as to apply 
configuration to, for instance, system-discovered underlays...or
do I misunderstand, is the intention here for the leafref to point
to a config false node?

Kent  // contributor

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 08 Mar 2017 15:12:37 +0100 (CET)

Kent Watsen <[email-masked]> wrote:
> topologoy model

Yes.

>, where we landed on a leafref in 'running' could
> point to a config true node in 'operational-state'

With 'require-instance false'?  That doesn't really mean that it
points to anything in operational state.

> as to apply 

Yes.  If we had revised datastores, this model would probably look
different. 

/martin

---

From: "Bogaert, Bart (Nokia - BE)" <[email-masked]>
Date: Wed, 8 Mar 2017 14:48:15 +0000

Hi,

> [Bart Bogaert] Is there a reason to only have this parent in the state
> tree and not in the config tree?

I am not sure I understand the question.  Suppose the config tree is empty,
and the system boots and populates the state tree with all detected
harwdare.  Next, a client would like to pre-provision a module in a chassis
that exists in state.  If the leafref is to the config tree, the client
would have to create both the chassis and the module in the config tree,
since the leafef would otherwise fail to validate.

[Bart Bogaert] Ok, so you are looking for a solution that refers to an entry
in the state tree.  I always thought that one could not refer from config to
state but it seems I misunderstood this since this is exactly what you are
proposing. 

type.

> [Bart Bogaert] If we leave it as a string it would mean that an
> external application would have to check whether the value of the
> string actually corresponds to a component that should exist (in the
> case of a non-system-controlled parent)?

[Bart Bogaert] Since that seems possible this would solve the problem.  I'm
checking this with our people.

Regards, Bart

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 8 Mar 2017 15:51:33 +0100

> checking this with our people.

Are you discussing leafref to a config false node with require
instance false? I am not sure this is valid YANG.

/js

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

---

From: "Bogaert, Bart (Nokia - BE)" <[email-masked]>
Date: Wed, 8 Mar 2017 15:00:07 +0000

On Wed, Mar 08, 2017 at 02:48:15PM +0000, Bogaert, Bart (Nokia - BE) wrote:
> > [Bart Bogaert] Is there a reason to only have this parent in the 
> > state tree and not in the config tree?
> 
validate.
> 
> [Bart Bogaert] Ok, so you are looking for a solution that refers to an 
> entry in the state tree.  I always thought that one could not refer 
> from config to state but it seems I misunderstood this since this is 
> exactly what you are proposing.
> 
> > If we pick the latter you will not get any validation (since it has 
> > to be require-instance false).
> >
> [Bart Bogaert] Since that seems possible this would solve the problem.  
> I'm checking this with our people.

Are you discussing leafref to a config false node with require instance
false? I am not sure this is valid YANG.

[Bart Bogaert] Well this is what I was thinking too but this was suggested
by Martin.

Regards, Bart
/js

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 08 Mar 2017 16:25:42 +0100 (CET)

Juergen Schoenwaelder <[email-masked]> wrote:
> instance false?

Yes.

> I am not sure this is valid YANG.

It is valid,  section 9.9 on leafref says:

   If the referring node represents configuration data and the
   "require-instance" property (Section 9.9.3) is "true", the referred
   node MUST also represent configuration.

/martin

---

From: "Bogaert, Bart (Nokia - BE)" <[email-masked]>
Date: Thu, 9 Mar 2017 11:46:40 +0000

So; to make this work the YANG property of the parent leaf in the config
data tree should be set to false to allow a reference to hardware-state,
correct?

Regards, Bart
 
Juergen Schoenwaelder <[email-masked]> wrote:
> > config tree, the client would have to create both the chassis and 
> > the module in the config tree, since the leafef would otherwise fail to
validate.
> > 
> > [Bart Bogaert] Ok, so you are looking for a solution that refers to 
> > an entry in the state tree.  I always thought that one could not 
> > refer from config to state but it seems I misunderstood this since 
> > this is exactly what you are proposing.
> > 
> > > If we pick the latter you will not get any validation (since it 
> > > has to be require-instance false).
> > >
> > > string actually corresponds to a component that should exist (in 
> > > the case of a non-system-controlled parent)?
> > 
> > [Bart Bogaert] Since that seems possible this would solve the 
> > problem.  I'm checking this with our people.
> 

Yes.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 09 Mar 2017 14:31:35 +0100 (CET)

> data tree should be set to false to allow a reference to hardware-state,

It would be:

      leaf parent {
        type leafref {
          path "/hardware-state/component/name";
          require-instance false;
        }

/martin