Subject: [netmod] Clarification Question on draft-dsdt-nmda-guidelines-01

From: Xufeng Liu <[email-masked]>
Date: Tue, 13 Jun 2017 19:53:32 +0000

During discussing the adoption of this guidelines, a question came up w.r.t. the semantics of the non-NMDA "-state" module during the transitioning period:

What kind of state do the leaves in the "-state" module represent? The applied configuration or the actually used operational data?
Since only of the two types can be represented, what is the guideline to model the other type?

Thanks,
- Xufeng

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 13 Jun 2017 22:09:31 +0200

Hi,

the typical -state tree consists of config false nodes and hence it
represents operational state. This is not a transitioning period
question, this is how -state trees were designed. Note also that the
applied configuration is part of the operational state in NMDA - for
config true objects, there is no difference between the applied
configuration value and the operationally used value - they are the
same.

/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: Xufeng Liu <[email-masked]>
Date: Wed, 14 Jun 2017 13:01:39 +0000

Hi Juergen,

Thanks for the confirmation.
As for the distinction between applied configuration and operational, I think that it has been determined to be useful in some use cases. We can create a separate leaf in such a case.

Regards,
- Xufeng

> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:[email-masked]]
> Sent: Tuesday, June 13, 2017 4:10 PM
> To: Xufeng Liu <[email-masked]>
> Cc: [email-masked]; [email-masked]
> Subject: Re: Clarification Question on draft-dsdt-nmda-guidelines-01
> 
> Hi,
> 
> the typical -state tree consists of config false nodes and hence it represents
> operational state. This is not a transitioning period question, this is how -state
> trees were designed. Note also that the applied configuration is part of the
> operational state in NMDA - for config true objects, there is no difference
> between the applied configuration value and the operationally used value - they
> are the same.
> 
> /js
> 
> > During discussing the adoption of this guidelines, a question came up w.r.t. the
> semantics of the non-NMDA "-state" module during the transitioning period:
> >
> > What kind of state do the leaves in the "-state" module represent? The applied
> configuration or the actually used operational data?

---

From: Robert Wilton <[email-masked]>
Date: Wed, 14 Jun 2017 16:10:32 +0100

Hi Xufeng,

> As for the distinction between applied configuration and operational, I think that it has been determined to be useful in some use cases. We can create a separate leaf in such a case.
Yes, I think that this is exactly the right approach.

In the general case, a single leaf for applied configuration and the 
operational value is normally sufficient.

But in some cases (e.g. where a value could be configured and/or 
negotiated via protocol) then it sometimes useful to both see the input 
into the protocol negotiation and also the resultant output value.

Here, there is a choice to be made to decide whether the extra config 
false leaf represents the input value into the negotiation, or the 
output value.  I think that the decision probably depends on the 
protocol semantics, but all things being equal, there is a benefit if 
the configured value and actual operational value end up being 
represented by the same leaf/path (since this in the case in the 
mainline case where extra config false leaves are not required).

Thanks,
Rob

> .

---

From: Mahesh Jethanandani <[email-masked]>
Date: Wed, 14 Jun 2017 08:23:54 -0700

> On Jun 14, 2017, at 8:10 AM, Robert Wilton <[email-masked]> wrote:
> 
> Hi Xufeng,
> 
> 
> In the general case, a single leaf for applied configuration and the operational value is normally sufficient.
> 
> But in some cases (e.g. where a value could be configured and/or negotiated via protocol) then it sometimes useful to both see the input into the protocol negotiation and also the resultant output value.
> 
> Here, there is a choice to be made to decide whether the extra config false leaf represents the input value into the negotiation, or the output value.  I think that the decision probably depends on the protocol semantics, but all things being equal, there is a benefit if the configured value and actual operational value end up being represented by the same leaf/path (since this in the case in the mainline case where extra config false leaves are not required).

Another way to look at it is whether the input value is truly different from the output value. For example, if the input value is auto-negotiation, a boolean, but the output value is a speed of 10/100/1000/10000, a uint32, then a separate leaf makes sense.

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

Mahesh Jethanandani
[email-masked]

---

From: Robert Wilton <[email-masked]>
Date: Wed, 14 Jun 2017 16:54:02 +0100

> Another way to look at it is whether the input value is truly different from the output value. For example, if the input value is auto-negotiation, a boolean, but the output value is a speed of 10/…
Yes, agreed.

For cases like these (e.g. Ethernet auto-negotiation) a good approach 
seem to be to model the leaf "enabling auto" as a separate leaf from the 
explicitly configured/operational value.

Thanks,
Rob