Subject: [netmod] Question on intefaces-state model

From: "Bogaert, Bart (Nokia - BE/Antwerp)" <[email-masked]>
Date: Fri, 9 Jun 2017 10:55:20 +0000

Hi,

We have a question regarding the statistics container as defined in the
interfaces-state model.  This container defines one mandatory leaf
(discontinuity-time) while all other leafs are optional.  What is the
rationale behind this leaf being mandatory and not an optional field?

It does not make a lot of sense to return a discontinuity-time value and no
counters if none of the counters are relevant for a specific interface.

Another alternative could be to add, via a deviation, a when clause to the
container indicating for which ifType(s) the container is (or is not)
present. But that would lead to not supporting the IETF interfaces model to
the full extent.

Regards, Bart

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 12 Jun 2017 19:21:42 +0200

> present. But that would lead to not supporting the IETF interfaces model to

The discontinuity-time is relevant for _any_ counter associated with
an interface, regardless whether the counter is defined in the
interfaces model or elsewhere. I have a hard time to imagine an
interface that has zero counters.

/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: Andy Bierman <[email-masked]>
Date: Mon, 12 Jun 2017 11:31:19 -0700

> interface that has zero counters.
The mandatory-stmt is very confusing for config=false nodes. Mandatory=true
means
an <rpc-reply> must contain an instance of the mandatory leaf.

Mandatory=false does not mean optional-to-implement although it sure
looks that way for config=false nodes.  Only if-feature can make a node
optional to implement.

 /js

Andy

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

---

From: Vladimir Vassilev <[email-masked]>
Date: Tue, 13 Jun 2017 11:15:11 +0200

On 06/12/2017 08:31 PM, Andy Bierman wrote:

>
>
> On Mon, Jun 12, 2017 at 10:21 AM, Juergen Schoenwaelder 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
The alternative which we use is to not have 
/interfaces-state/interface/statistics container for the interfaces 
without counters. The container is mandatory=false.
>     interface that has zero counters.
There are some though. Optical amplifiers and similar equipment that 
does not have counters - the status data is only signal levels.
>
> The mandatory-stmt is very confusing for config=false nodes. 
> Mandatory=true means
> looks that way for config=false nodes.  Only if-feature can make a 
> node optional to implement.
If we take serial interface with hardware that only has in-octets and 
out-octets counters I would expect to only find these two in 
/interfaces-state/interface/statistics +  discontinuity-time. Do you say 
the rest of the counters must be present (e.g. allways 0) for proper 
implementation of ietf-interfaces?

Vladimir
>     Fax:   +49 421 200 3103         <http://www.jacobs-university.de/
>     <http://www.jacobs-university.de/>>
>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/netmod>
>
>
>
>

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 13 Jun 2017 20:52:44 +0200

> an <rpc-reply> must contain an instance of the mandatory leaf.

I don't think it is that confusing. RFC 7950 defines what a valid data
tree means and "mandatory" are among the constraints.

I agree though that in terms of a management protocol it means different
things for config true and false data, but this is true also for default
values and maybe other YANG concepts as well. 

> looks that way for config=false nodes.  Only if-feature can make a node

I don't think this interpretation is supported by any text in the YANG
spec. State data nodes that are optional needn't be implemented.

Lada

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

---

From: Andy Bierman <[email-masked]>
Date: Tue, 13 Jun 2017 12:30:34 -0700

On Tue, Jun 13, 2017 at 11:52 AM, Ladislav Lhotka <[email-masked]> wrote:

> >> > It does not make a lot of sense to return a discontinuity-time value
> and
> >> no
> >> > present. But that would lead to not supporting the IETF interfaces
> model
> >> to
> >> > the full extent.
> >> >
> >>
> Mandatory=true
RFC 7950, sec 5.6  (Conformance) does not support your interpretation.
It defines basic behavior, optional (via features), and deviations as the
only mechanisms affecting conformance.

Lada

Andy

---

From: Alex Campbell <[email-masked]>
Date: Tue, 13 Jun 2017 22:35:23 +0000

Presumably a device is free to not implement an optional config=false node if that node would never be returned in a response anyway - as this will make no externally visible difference.

However, if the model states or implies that the node is present under certain conditions (for example, the node is always present for Ethernet ports), and the device can meet those conditions (i.e. it has an Ethernet port), then the device must implement the node or it does not conform to the model.

Alex

________________________________
From: netmod <[email-masked]> on behalf of Andy Bierman <[email-masked]>
Sent: Wednesday, 14 June 2017 7:30 a.m.
To: Ladislav Lhotka
Cc: [email-masked]
Subject: Re: [netmod] Question on intefaces-state model

On Tue, Jun 13, 2017 at 11:52 AM, Ladislav Lhotka <[email-masked]<mailto:[email-masked]>> wrote:
Andy Bierman <[email-masked]<mailto:[email-masked]>> writes:

> [email-masked]<mailto:[email-masked]>> wrote:
>

RFC 7950, sec 5.6  (Conformance) does not support your interpretation.
It defines basic behavior, optional (via features), and deviations as the only mechanisms affecting conformance.

Lada

Andy

>> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 14 Jun 2017 10:28:09 +0200

> On 14 Jun 2017, at 00:35, Alex Campbell <[email-masked]> wrote:
> 
> 

That's my view, too. However, this reasoning works if the parent container is being retrieved but it is not very clear what is supposed to happen if the client asks explicly for that optional parameter. This looks like a gap in the architecture – most of the time, YANG pretends to be something like a schema language in that it describes constraints on a valid data tree but conformance issues like what parameters a server needs to implement are something different.

> However, if the model states or implies that the node is present under certain conditions (for example, the node is always present for Ethernet ports), and the device can meet those conditions (i.e…

Right, this could be written in a description, but I've been assuming it is not the case.

Lada

---

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

>>     interface that has zero counters.
+1

> does not have counters - the status data is only signal levels.
For me the question is here is whether the objects being modelled by 
optical amplifiers are actually interfaces or something else, and I 
think that they are probably something else.

I appreciate that this may not be the universal view, but I think of an 
interface as something that forwards traffic at layer 2 or above.  I.e. 
it is something that is potentially meaningful to have a IP address on, 
assign a routing protocol to, have frame or packet statistics, etc.

I would rather IETF defines a separate list of objects (e.g. Cisco's IOS 
XR would call them 'controllers') for L1 forwarding objects, given that 
most of the configuration and properties of these L1 forwarding 
constructs is generally quite different from 'regular' interfaces.

> /interfaces-state/interface/statistics +  discontinuity-time. Do you 
> say the rest of the counters must be present (e.g. allways 0) for 
> proper implementation of ietf-interfaces?

Returning zero values here is not useful, in fact it is misleading. I 
think that if a server doesn't have a value to return for a particular 
node it is much better to return nothing than to return a false value.

As an aside, I think that this is also why default values for config 
false leaves aren't helpful because they can cause ambiguity as to 
whether a server has no value to return, or is instead returning the 
default value.

Rob

> .

---

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

> That's my view, too. However, this reasoning works if the parent container is being retrieved but it is not very clear what is supposed to happen if the client asks explicly for that optional param…
It would surely do the same thing as if a client requested any node in a 
YANG data tree that doesn't exist.

RESTCONF has special semantics if a GET request is for a specific leaf 
rather than a parent container, but I just regard this as a mistake in 
the specification (i.e. the "restconf default handling" thread on the 
NETCONF alias).

Rob

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 14 Jun 2017 11:39:43 +0200

On Wed, Jun 14, 2017 at 10:15:22AM +0100, Robert Wilton wrote:
> 
> Returning zero values here is not useful, in fact it is misleading. I think
> that if a server doesn't have a value to return for a particular node it is
> much better to return nothing than to return a false value.

+1.

It took us years to kill this attitude in SNMP land. Saying a counter
is zero and never changes is largely misleading if you actually have
no such counter. It is easy to waste hours of expensive engineering
time by given people fake counters.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 14 Jun 2017 11:46:14 +0200

> On 14 Jun 2017, at 11:21, Robert Wilton <[email-masked]> wrote:
> 
> 
> 
> It would surely do the same thing as if a client requested any node in a YANG data tree that doesn't exist.

So you are saying that one server can return the parameter but another may report "404 Not Found", correct?

> 
> RESTCONF has special semantics if a GET request is for a specific leaf rather than a parent container, but I just regard this as a mistake in the specification (i.e. the "restconf default handling" thread on the NETCONF alias).

Defaults are another can of worms. If we have an optional config false parameter with a default defined in YANG and the server doesn't implement the parameter (and hence doesn't send it), can the client assume that the server actually has the default value?

Lada

---

From: Robert Wilton <[email-masked]>
Date: Wed, 14 Jun 2017 11:35:33 +0100

> So you are saying that one server can return the parameter but another may report "404 Not Found", correct?
Yes.

> Defaults are another can of worms. If we have an optional config false parameter with a default defined in YANG and the server doesn't implement the parameter (and hence doesn't send it), can the c…
Not in any way that is reliable.  I.e. sometimes the client may make 
this assumption and just be wrong!

One of the key themes running through the NMDA work has been to try and 
get more integrity and consistence between the data that is being returned.

So, in the NMDA world, I think that there are really only two 
"with-default" options that are robust and most useful:

(1) For the candidate/running/status datastores, where the content of 
the datastore is controlled by the client, then the explicit mode is the 
sane default choice.  I.e. generally you should get out exactly what you 
put in.

(2) For the operational state datastore, the report-all mode is the sane 
choice, because this is the only one that allows a client to detect that 
a server is choosing to return no value rather than the default value.

I do appreciate that the other with-defaults options can be used to 
either minimize the amount of data being transferred (potentially at the 
expense of data accuracy), or provide a consolidated view of the 
configuration (e.g. to avoid the client constructing the same combined 
view itself).  But I think that the client should have to opt in if they 
want to see these, and the normal behaviour should be to favour 
correctness and explicitness.

Hence, I wish there had been more consistency with the normal choice of 
default mode in the standard rather that leaving it up to the server 
implementation to decide, thus requiring that clients have to cope with 
a mismash of default handling flavours.

Rob

---

From: "Bogaert, Bart (Nokia - BE/Antwerp)" <[email-masked]>
Date: Wed, 14 Jun 2017 11:18:13 +0000

That's why these counters are optional in the model: if there is nothing to
return we should indeed not return 0...

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: 14 June 2017 11:40
To: Robert Wilton <[email-masked]>
Cc: Vladimir Vassilev <[email-masked]>; Andy Bierman
<[email-masked]>; Bogaert, Bart (Nokia - BE/Antwerp)
<[email-masked]>; [email-masked]
Subject: Re: [netmod] Question on intefaces-state model

+1.

It took us years to kill this attitude in SNMP land. Saying a counter is
zero and never changes is largely misleading if you actually have no such
counter. It is easy to waste hours of expensive engineering time by given
people fake counters.

/js

---

From: Igor Bryskin <[email-masked]>
Date: Wed, 14 Jun 2017 13:13:29 +0000

Hi Franchesco,

To your point 1:
I was describing a very common use case when a client owns/ controls OTN TTPs, while the multi domain network provides connectivity betweeb access links across the network. In this cae network only deals with transit segments (neither head nor tail)
To your point 2
There is only one thing aboutb OTN transit segments that is  OTN specific  - bandwidth.
Because the configuration  of a transit OTN segment needs to include the exact ODUk container (to match the container on the opposite side of the incoming access/interdomain link) - said ODUk container is expected to be encoded as a generic label subobject that follows  the network side access/interdomain link subobject  - this alone tells the network controller everything it needs to know about the required bandwidth.
In short, for this use case you dont need OTN augmentation
to support client -network interface  - base /generic  TE tunnel model works just fine,

I do agree that every use case that requires provisioning by network OTN  TTPs does require the OTN augmentation.

Igor

From:Ladislav Lhotka
To:Alex Campbell,
Cc:[email-masked],
Date:2017-06-14 04:28:51
Subject:Re: [netmod] Question on intefaces-state model

Lada

---

From: Igor Bryskin <[email-masked]>
Date: Wed, 14 Jun 2017 13:23:32 +0000

I apologize for the email below - replied to the wrong one, please, disregard.

Igor

From: netmod [mailto:[email-masked]] On Behalf Of Igor Bryskin
Sent: Wednesday, June 14, 2017 9:13 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [netmod] Question on intefaces-state model

Hi Franchesco,

To your point 1:

Igor
From:Ladislav Lhotka
To:Alex Campbell,
Cc:[email-masked],
Date:2017-06-14 04:28:51

> Presumably a device is free to not implement an optional config=false node if that node would never be returned in a response anyway - as this will make no externally visible difference.

That's my view, too. However, this reasoning works if the parent container is being retrieved but it is not very clear what is supposed to happen if the client asks explicly for that optional parameter. This looks like a gap in the architecture - most of the time, YANG pretends to be something like a schema language in that it describes constraints on a valid data tree but conformance issues like what parameters a server needs to implement are something different.

Lada

---

From: Vladimir Vassilev <[email-masked]>
Date: Wed, 14 Jun 2017 16:36:53 +0200

Hello,

> counter. It is easy to waste hours of expensive engineering time by given

I agree that the statistics counter leafs as defined in ietf-interfaces 
are optional except the discontinuity-time ("mandatory true;") leaf. You 
were right it makes the entire /interfaces-state/interface/statistics 
container mandatory even if none of the optional counters are implemented.

The context of the example was the statement by Andy who seemed to 
differ on the counters being optional. I was not sure what he ment and 
added an example of device not implementing some of the counters without 
breaking conformity with ietf-interfaces:

On 06/13/2017 11:15 AM, Vladimir Vassilev wrote:
> On 06/12/2017 08:31 PM, Andy Bierman wrote: an <rpc-reply> must 
> contain an instance of the mandatory leaf.

That said you probably also agree that a model with optional leafs is 
equivalent to an employment contract where the monthly salary is 
optional. State data models should avoid the entropy of allowing 
implementations to either implement or not leafs without this being 
formal conformance deviation (this being especially valid for basic 
counters part of the base ietf model like ietf-interfaces). That causes 
greater waste of not only engineering time but runtime traffic as well. 
Management applications have to be designed to poll the leafs and make 
conditional decisions for each instance and handle missing leafs to 
conform to the model.

For example an option to do automated validation of all point to point 
links in a topology (by checking counters at source and destination 
ports - out-unicast-pkts=in-unicast-pkts ... etc.). All the devices 
implement the required capability - ietf-interfaces but some do not 
return out-unicast-pkts, out-broadcast-pkts, out-multicast-pkts since 
the hardware only provides them with out-total-pkts and in-total-pkts 
(not part of ietf-interfaces model).

With that example in mind I have another relevant question:

Is there consensus that this is valid YANG 1.1 and with a mandatory 
counters defined like that the stated conformance actually brings some 
guarantees the required counter will be implemented:

...

yang-version 1.1;

...

    augment "/if:interfaces-state/if:interface/if:statistics" {
         leaf in-total-pkts {
           mandatory true;
           type yang:counter64;
         }
         leaf out-total-pkts {
           mandatory true;
           type yang:counter64;
         }

     }

...

pyang does not like that ("cannot augment with mandatory node 
in-total-pkts") and I think it should be valid to add mandatory true 
counter leafs to /interfaces-state/interface/statistics

Vladimir