Re: [netmod] Modelling different "levels" of data in YANG

[Robert Wilton]

Hi,

A variant on your suggestion:

Rather than "diagnostics true;" a potentially more general way of 
handling this could be a generalized schema flag to indicate that a 
particular node (and its children) is never returned unless explicitly 
requested.  E.g. "hidden: true" instead of "diagnostics: true".  The 
data would only be returned if either (i) the filter explicitly 
indicated that hidden data should be returned (as per Kent's 
suggestion), or possibly also (ii) if the request path (or filter) 
explicitly specified the hidden node(s).


Thanks,
Rob


On 15/12/2016 19:23, Vladimir Vassilev wrote:

Hi,

Here is a summary of the proposed solutions so far:

* The solution with introduction of YANG statement "diagnostics 
true;", additional datastore and NETCONF protocol change. IMO that 
sounds heavy but valid solution.
* The solution with RPC returning the data as output. IMO has the 
limitation of not presenting the diagnostics data in the data tree (no 
valid instance-identifiers to be used in notifications). But is the 
simplest to have in place.
* The solution with RPC enabling the containers only for a certain 
session.


I thought also of this alternative solution:  The solution is to avoid 
clobbering the replies to s without filter or s with filter 
matching only parent nodes of the "diagnostics state" container data  
and not return those nodes in the reply except in the cases the filter 
matches data nodes part of the diagnostics data explicitly.


Example for /interfaces-state/interfaces/diagnostics (using xpath 
filter for brevity but valid for the "subtree" case):


These skip "diagnostics":



These return "diagnostics":

select="/interfaces-state/interface/diagnostics"\>



This looks like a violation of RFC 6241 6.2.5 bullet 12 but IMO the 
container is non-mandatory diagnostics data so returning it only when 
someone really wants it and not otherwise is the definition of the 
solution to the problem.


/Vladimir

On 12/12/2016 05:47 PM, Kent Watsen wrote:


Hi Robert,

You’re right, it should’ve been the  (not ).   
However, I think that it’s better to use a flag on the 
 datastore, rather than to define a new 
datastore.  Not only would it mimic how with-defaults works, but it 
also seems more intuitive from a retrieval perspective, as the 
diagnostics nodes could be sprinkled throughout a data model, and a 
single  could return all nodes (not just the diagnostics) 
for a given subtree.Thoughts?


Separately, from a modelling perspective, presumably there would have 
to be an additional flag to go with the config false flag, something 
like the below.  Is this what you were envisioning?


container thermostat {

leaf configured-temperature {

type int8;

}

leaf current-temperature {

config false;

type int8;

}

container diagnostics {

config false;

diagnostics true;<-- new flag here

...

}

Is all this leading up to a draft?  ;)

Kent  // contributor

*From: *Robert Wilton <rwil...@cisco.com>
*Date: *Monday, December 12, 2016 at 6:10 AM
*To: *Kent Watsen <kwat...@juniper.net>, Andy Bierman 
<a...@yumaworks.com>

*Cc: *"netmod@ietf.org" <netmod@ietf.org>
*Subject: *Re: [netmod] Modelling different "levels" of data in YANG

Hi Kent,

On 10/12/2016 00:59, Kent Watsen wrote:

> I prefer not to use specialized  operations.

Agreed, I was thinking something more along the lines of:

   

  

 

  

<--- note this flag here

  

 http://example.com/schema/1.2/config;
<http://example.com/schema/1.2/config>>



  



 

  

   

Thus explicitly requesting all the extra stuff get returned...

Yes, that is roughly along the lines that I was thinking.

Or building on draft-nmdsdt-netmod-revised-datastores:
- presuming the existing of a  operation to generically 
return the contents of any datastore,
- defining a new  datastore that contains the contents 
of the  along with all config false schema nodes 
labelled as "diagnostics true".


   

  

 

  

  



  


Thanks,
Rob



> In the usage model that Rob described, the service tech will be

> setting diag-mode to 'system'  then retrieving the extra
'diag-stats',

>then setting diag-mode back to 'user'.

Right, but this does not seem ideal as the diag-mode toggle is a
global setting that would affect all clients for some window of
time, or do we envision diag-mode dropping the system down to
single-user mode?

Kent  // contributor


.



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

Re: [netmod] Modelling different "levels" of data in YANG

[Vladimir Vassilev]

Hi,

Here is a summary of the proposed solutions so far:

* The solution with introduction of YANG statement "diagnostics true;", 
additional datastore and NETCONF protocol change. IMO that sounds heavy 
but valid solution.
* The solution with RPC returning the data as output. IMO has the 
limitation of not presenting the diagnostics data in the data tree (no 
valid instance-identifiers to be used in notifications). But is the 
simplest to have in place.

* The solution with RPC enabling the containers only for a certain session.

I thought also of this alternative solution:  The solution is to avoid 
clobbering the replies to s without filter or s with filter 
matching only parent nodes of the "diagnostics state" container data  
and not return those nodes in the reply except in the cases the filter 
matches data nodes part of the diagnostics data explicitly.


Example for /interfaces-state/interfaces/diagnostics (using xpath filter 
for brevity but valid for the "subtree" case):


These skip "diagnostics":



These return "diagnostics":

select="/interfaces-state/interface/diagnostics"\>



This looks like a violation of RFC 6241 6.2.5 bullet 12 but IMO the 
container is non-mandatory diagnostics data so returning it only when 
someone really wants it and not otherwise is the definition of the 
solution to the problem.


/Vladimir

On 12/12/2016 05:47 PM, Kent Watsen wrote:


Hi Robert,

You’re right, it should’ve been the  (not ).   
However, I think that it’s better to use a flag on the 
 datastore, rather than to define a new datastore.  
Not only would it mimic how with-defaults works, but it also seems 
more intuitive from a retrieval perspective, as the diagnostics nodes 
could be sprinkled throughout a data model, and a single  
could return all nodes (not just the diagnostics) for a given 
subtree.Thoughts?


Separately, from a modelling perspective, presumably there would have 
to be an additional flag to go with the config false flag, something 
like the below.  Is this what you were envisioning?


container thermostat {

leaf configured-temperature {

type int8;

}

leaf current-temperature {

config false;

type int8;

}

container diagnostics {

config false;

diagnostics true;<-- new flag here

...

}

Is all this leading up to a draft?  ;)

Kent  // contributor

*From: *Robert Wilton <rwil...@cisco.com>
*Date: *Monday, December 12, 2016 at 6:10 AM
*To: *Kent Watsen <kwat...@juniper.net>, Andy Bierman <a...@yumaworks.com>
*Cc: *"netmod@ietf.org" <netmod@ietf.org>
*Subject: *Re: [netmod] Modelling different "levels" of data in YANG

Hi Kent,

On 10/12/2016 00:59, Kent Watsen wrote:

> I prefer not to use specialized  operations.

Agreed, I was thinking something more along the lines of:

   

  

 

  

<--- note this flag here

  

 http://example.com/schema/1.2/config;
<http://example.com/schema/1.2/config>>



  



 

  

   

Thus explicitly requesting all the extra stuff get returned...

Yes, that is roughly along the lines that I was thinking.

Or building on draft-nmdsdt-netmod-revised-datastores:
- presuming the existing of a  operation to generically 
return the contents of any datastore,
- defining a new  datastore that contains the contents of 
the  along with all config false schema nodes 
labelled as "diagnostics true".


   

  

 

  

  



  


Thanks,
Rob



> In the usage model that Rob described, the service tech will be

> setting diag-mode to 'system'  then retrieving the extra
'diag-stats',

>then setting diag-mode back to 'user'.

Right, but this does not seem ideal as the diag-mode toggle is a
global setting that would affect all clients for some window of
time, or do we envision diag-mode dropping the system down to
single-user mode?

Kent  // contributor



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

Re: [netmod] Modelling different "levels" of data in YANG

[Kent Watsen]

Hi Robert,

You’re right, it should’ve been the  (not ).   However, I 
think that it’s better to use a flag on the  datastore, 
rather than to define a new datastore.  Not only would it mimic how 
with-defaults works, but it also seems more intuitive from a retrieval 
perspective, as the diagnostics nodes could be sprinkled throughout a data 
model, and a single  could return all nodes (not just the 
diagnostics) for a given subtree.Thoughts?

Separately, from a modelling perspective, presumably there would have to be an 
additional flag to go with the config false flag, something like the below.  Is 
this what you were envisioning?

container thermostat {
leaf configured-temperature {
type int8;
}
leaf current-temperature {
config false;
type int8;
}
container diagnostics {
config false;
diagnostics true;<-- new flag here
...
}


Is all this leading up to a draft?  ;)

Kent  // contributor


From: Robert Wilton <rwil...@cisco.com>
Date: Monday, December 12, 2016 at 6:10 AM
To: Kent Watsen <kwat...@juniper.net>, Andy Bierman <a...@yumaworks.com>
Cc: "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] Modelling different "levels" of data in YANG


Hi Kent,

On 10/12/2016 00:59, Kent Watsen wrote:

> I prefer not to use specialized  operations.

Agreed, I was thinking something more along the lines of:

   
  
 
  
  <--- note this flag here
  
 http://example.com/schema/1.2/config;<http://example.com/schema/1.2/config>>

  

 
  
   

Thus explicitly requesting all the extra stuff get returned...
Yes, that is roughly along the lines that I was thinking.

Or building on draft-nmdsdt-netmod-revised-datastores:
- presuming the existing of a  operation to generically return the 
contents of any datastore,
- defining a new  datastore that contains the contents of the 
 along with all config false schema nodes labelled as 
"diagnostics true".
   
  
 
  
  

  

Thanks,
Rob





> In the usage model that Rob described, the service tech will be
> setting diag-mode to 'system'  then retrieving the extra 'diag-stats',
>then setting diag-mode back to 'user'.

Right, but this does not seem ideal as the diag-mode toggle is a global setting 
that would affect all clients for some window of time, or do we envision 
diag-mode dropping the system down to single-user mode?


Kent  // contributor








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

Re: [netmod] Modelling different "levels" of data in YANG

[Kent Watsen]

> Why can't you use a when-stmt?
>
> 
> system
> 
> ...
>
>// config false
>//  when  "/top/diag-mode = 'system'"
>
> 
> 


Can we have a solution that is session-oriented, like with-defaults?   Maybe 
the ‘when’ expression’s context could be extended to the client’s request, or 
otherwise be triggered by something in the request?

Kent // as a contributor


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

Re: [netmod] Modelling different "levels" of data in YANG

[Andy Bierman]

On Fri, Dec 9, 2016 at 10:10 AM, Robert Wilton  wrote:

>
>
> On 09/12/2016 15:17, Martin Bjorklund wrote:
>
>> Robert Wilton  wrote:
>>
>>>
>>> On 09/12/2016 12:06, Juergen Schoenwaelder wrote:
>>>
 On Fri, Dec 09, 2016 at 11:25:35AM +, Robert Wilton wrote:

> Even if they don't break, debug and diagnostics information can be
> very
> verbose.
>
> If a client had 4 connections to a device for monitoring different
> things,
> then you don't want to suddenly start sending a large amount of extra
> diagnostics data on each of the 4 connections when they have only
> requested
> it on one connection.  Generating this extra data could overload the
> client
> or the device, or certainly lead to degraded performance in some way
> or
> another.
>
> Then the client probably should have used a proper filter. Augments
 are a key feature of YANG. A client not interested in any additional
 data should not (implicitely) ask for it. (It does not matter whether
 the additional data is debugging or other information; if you do not
 need it, do not as for it if you want to be robust.)

>>> Given that an augmentation could be on any container, then I think
>>> that this ends up that every get request needs a potentially complex
>>> subtree filter to exclude diagnostics information that they wouldn't
>>> really expect to be returned in the first place.  Further, if the
>>> diagnostics information was controlled by a debug leaf then they
>>> probably won't ever see this problem during testing, only when someone
>>> needs to get diagnostics information for an Ethernet interface on a
>>> production system would the extra data start showing up.
>>>
>>> To me, this seems to be making YANG models easier for the 0.01% of
>>> client request at the expense of the 99.99% of client requests.
>>>
>> The problem is that it is a slippery slope.  Anyone that designs a
>> data model might think that some data probably not is interesting to
>> all clients, in all cases, so they might just create special RPCs
>> instead of modelling it as config false data.
>>
> I would say that a clear separation is fairly easy to define, and the
> industry has managed to do this fairly well for the last few decades:
> - If the information is necessary to manage or monitor a device then it
> should be included in opstate.
> - if the information is only required for an engineer to diagnose why the
> device isn't working to the specification then it isn't part of the opstate.
>
> There are lots of examples of this:
>  1) a simple car analogy:
>  - my car dashboard gives me the useful information that I need to safely
> drive the car, and to monitor that the car is behaving as designed.
>  - if the car stops working properly (perhaps it signals a fault on the
> dashboard), then I take it to garage, they connect it to a computer,
> download and analyze the diagnostics to figure out what is wrong (normally
> at large expense).
>  - as a user of the car, I do not want to see all of that internal
> diagnostics information on the dashboard all the time.  It would obscure
> the information that is actually important, and I probably wouldn't
> understand what it all means anyway.
>
> 2) My alarm system at home has a "User mode" and "Engineer mode", the
> information presented in each mode differs.  I think that this sort of
> example can probably be repeated for nearly all of the consumer electronics
> that I own.
>
> 3) The same is for network devices:
> As a operator of an Ethernet interface, I care:
>  - whether the port is up and able to forward packets, or it is down.
>  - if it is down, whether it is something that I can diagnose and fix
> (e.g. config error, dirty cable, missing PHY).
> But I don't personally want to know whether the "PHY XS provides
> information on transmit path data
> delay in registers 4.1801 through 4.1804" or whether "PHY XGXS is able to
> generate test patterns".  However, an engineer might find this information
> useful to diagnose why the Ethernet port isn't working the way that it
> should.
>
> I think that there is a clear split in the intent of this information, and
> what audience the information is targeted to.
>
> I can't see how always lumping these two discrete sets of data together
> really helps anyone.
>
>

Why can't you use a when-stmt?

 
 system
 
 ...

// config false
//  when  "/top/diag-mode = 'system'"

 
 


Thanks,
> Rob
>
>
Andy


> ___
> 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] Modelling different "levels" of data in YANG

[Robert Wilton]

On 09/12/2016 15:17, Martin Bjorklund wrote:

Robert Wilton  wrote:


On 09/12/2016 12:06, Juergen Schoenwaelder wrote:

On Fri, Dec 09, 2016 at 11:25:35AM +, Robert Wilton wrote:

Even if they don't break, debug and diagnostics information can be
very
verbose.

If a client had 4 connections to a device for monitoring different
things,
then you don't want to suddenly start sending a large amount of extra
diagnostics data on each of the 4 connections when they have only
requested
it on one connection.  Generating this extra data could overload the
client
or the device, or certainly lead to degraded performance in some way
or
another.


Then the client probably should have used a proper filter. Augments
are a key feature of YANG. A client not interested in any additional
data should not (implicitely) ask for it. (It does not matter whether
the additional data is debugging or other information; if you do not
need it, do not as for it if you want to be robust.)

Given that an augmentation could be on any container, then I think
that this ends up that every get request needs a potentially complex
subtree filter to exclude diagnostics information that they wouldn't
really expect to be returned in the first place.  Further, if the
diagnostics information was controlled by a debug leaf then they
probably won't ever see this problem during testing, only when someone
needs to get diagnostics information for an Ethernet interface on a
production system would the extra data start showing up.

To me, this seems to be making YANG models easier for the 0.01% of
client request at the expense of the 99.99% of client requests.

The problem is that it is a slippery slope.  Anyone that designs a
data model might think that some data probably not is interesting to
all clients, in all cases, so they might just create special RPCs
instead of modelling it as config false data.
I would say that a clear separation is fairly easy to define, and the 
industry has managed to do this fairly well for the last few decades:
- If the information is necessary to manage or monitor a device then it 
should be included in opstate.
- if the information is only required for an engineer to diagnose why 
the device isn't working to the specification then it isn't part of the 
opstate.


There are lots of examples of this:
 1) a simple car analogy:
 - my car dashboard gives me the useful information that I need to 
safely drive the car, and to monitor that the car is behaving as designed.
 - if the car stops working properly (perhaps it signals a fault on the 
dashboard), then I take it to garage, they connect it to a computer, 
download and analyze the diagnostics to figure out what is wrong 
(normally at large expense).
 - as a user of the car, I do not want to see all of that internal 
diagnostics information on the dashboard all the time.  It would obscure 
the information that is actually important, and I probably wouldn't 
understand what it all means anyway.


2) My alarm system at home has a "User mode" and "Engineer mode", the 
information presented in each mode differs.  I think that this sort of 
example can probably be repeated for nearly all of the consumer 
electronics that I own.


3) The same is for network devices:
As a operator of an Ethernet interface, I care:
 - whether the port is up and able to forward packets, or it is down.
 - if it is down, whether it is something that I can diagnose and fix 
(e.g. config error, dirty cable, missing PHY).
But I don't personally want to know whether the "PHY XS provides 
information on transmit path data
delay in registers 4.1801 through 4.1804" or whether "PHY XGXS is able 
to generate test patterns".  However, an engineer might find this 
information useful to diagnose why the Ethernet port isn't working the 
way that it should.


I think that there is a clear split in the intent of this information, 
and what audience the information is targeted to.


I can't see how always lumping these two discrete sets of data together 
really helps anyone.


Thanks,
Rob

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

Re: [netmod] Modelling different "levels" of data in YANG

[Martin Bjorklund]

Robert Wilton  wrote:
> 
> 
> On 09/12/2016 12:06, Juergen Schoenwaelder wrote:
> > On Fri, Dec 09, 2016 at 11:25:35AM +, Robert Wilton wrote:
> >> Even if they don't break, debug and diagnostics information can be
> >> very
> >> verbose.
> >>
> >> If a client had 4 connections to a device for monitoring different
> >> things,
> >> then you don't want to suddenly start sending a large amount of extra
> >> diagnostics data on each of the 4 connections when they have only
> >> requested
> >> it on one connection.  Generating this extra data could overload the
> >> client
> >> or the device, or certainly lead to degraded performance in some way
> >> or
> >> another.
> >>
> > Then the client probably should have used a proper filter. Augments
> > are a key feature of YANG. A client not interested in any additional
> > data should not (implicitely) ask for it. (It does not matter whether
> > the additional data is debugging or other information; if you do not
> > need it, do not as for it if you want to be robust.)
> Given that an augmentation could be on any container, then I think
> that this ends up that every get request needs a potentially complex
> subtree filter to exclude diagnostics information that they wouldn't
> really expect to be returned in the first place.  Further, if the
> diagnostics information was controlled by a debug leaf then they
> probably won't ever see this problem during testing, only when someone
> needs to get diagnostics information for an Ethernet interface on a
> production system would the extra data start showing up.
> 
> To me, this seems to be making YANG models easier for the 0.01% of
> client request at the expense of the 99.99% of client requests.

The problem is that it is a slippery slope.  Anyone that designs a
data model might think that some data probably not is interesting to
all clients, in all cases, so they might just create special RPCs
instead of modelling it as config false data.

It would be better to model it as config false and work on the
protocol to have better filters (like Andy's recently proposed
"topic-filter" maybe).


/martin

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

Re: [netmod] Modelling different "levels" of data in YANG

[Robert Wilton]

On 09/12/2016 12:06, Juergen Schoenwaelder wrote:

On Fri, Dec 09, 2016 at 11:25:35AM +, Robert Wilton wrote:

Even if they don't break, debug and diagnostics information can be very
verbose.

If a client had 4 connections to a device for monitoring different things,
then you don't want to suddenly start sending a large amount of extra
diagnostics data on each of the 4 connections when they have only requested
it on one connection.  Generating this extra data could overload the client
or the device, or certainly lead to degraded performance in some way or
another.


Then the client probably should have used a proper filter. Augments
are a key feature of YANG. A client not interested in any additional
data should not (implicitely) ask for it. (It does not matter whether
the additional data is debugging or other information; if you do not
need it, do not as for it if you want to be robust.)
Given that an augmentation could be on any container, then I think that 
this ends up that every get request needs a potentially complex subtree 
filter to exclude diagnostics information that they wouldn't really 
expect to be returned in the first place.  Further, if the diagnostics 
information was controlled by a debug leaf then they probably won't ever 
see this problem during testing, only when someone needs to get 
diagnostics information for an Ethernet interface on a production system 
would the extra data start showing up.


To me, this seems to be making YANG models easier for the 0.01% of 
client request at the expense of the 99.99% of client requests.


Thanks,
Rob




/js



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

Re: [netmod] Modelling different "levels" of data in YANG

[Juergen Schoenwaelder]

On Fri, Dec 09, 2016 at 11:46:39AM +, Robert Wilton wrote:
> Hi Juergen,
> 
> Please can you expand on your proposed solution if using just one NACM
> entry.

Perhaps we talk past each other because 'NACM entry' is ambiguous. I mean
one 'rule-list' entry, you probably mean N 'rule' entries.
 
> >   And why would N hard coded toggles
> > in data models be simpler and not a burden for the industry?
> 1. Because by default there is no additional filtering cost to excluding
> diagnostics data from get/push requests on the operational state datastore.
> 2. The names of the RPCs could be defined by convention, and hence handled
> in a generic way.

I generally dislike any solutions that relies on 'naming conventions'.

> 3. Defining RPCs isn't my preferred solution, but it feels like the most
> pragmatic one available today.  I think that diagnostics is a fundamentally
> different level of operational state data that may be better served using a
> separate datastore that sits below the operational state datastore.  I.e. it
> "sees" everything in the operational state datatstore but also contains the
> extra diagnostics information as well.  The diagnostic specific nodes would
> be marked in the schema, same as config, i2rs, etc, presumably defined in a
> YANG extension.

Perhaps you just want to dynamically enable/disable data models
supported by a device?

/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] Modelling different "levels" of data in YANG

[Ladislav Lhotka]

> On 9 Dec 2016, at 12:05, Robert Wilton  wrote:
> 
> 
> 
> On 09/12/2016 10:54, Ladislav Lhotka wrote:
>>> On 9 Dec 2016, at 11:48, Robert Wilton  wrote:
>>> 
>>> Hi Lada,
>>> 
>>> 
>>> On 09/12/2016 10:33, Ladislav Lhotka wrote:
 Hi Rob,
 
 I didn't follow the previous discussion closely but a natural solution
 seems to be to define a leaf like "debug" - it could be just boolean or
 an enumeration of debug levels. And then add the diagnostic
 data as an augment that conditionally depends on the value of the
 "debug" leaf.
 
 Would this work?
>>> I'm not sure.
>>> 
>>> Historically debug has been separate from configuration.  I.e. you wouldn't 
>>> normally expect debug settings to persist after rebooting the device.
>> Yes, good point. So what you can do is to have a "debug" RPC, show "debug" 
>> value in state data, and still make the augment with diagnostics 
>> conditionally dependent on the debug leaf.
> OK, so this is closer, but still would mean that enabling the debug flag via 
> RPC would potentially cause all clients to start to see the diagnostics 
> information (which may break them).

You can add finer granularity by making "debug" into an action on an interface, 
and then I think it's not a big deal. 

> 
> Hence I think that there is a requirement that the diagnostics data is 
> restricted to only the specific client session that it has been requested 
> on/enabled on.

Then an RPC returning the diagnostics, as Vladimir suggested, might be the best 
option.

Lada

> 
> Thanks,
> Rob

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




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

Re: [netmod] Modelling different "levels" of data in YANG

[Robert Wilton]

On 09/12/2016 11:16, Juergen Schoenwaelder wrote:

On Fri, Dec 09, 2016 at 11:05:47AM +, Robert Wilton wrote:

OK, so this is closer, but still would mean that enabling the debug flag via
RPC would potentially cause all clients to start to see the diagnostics
information (which may break them).


A client that breaks when receiving unknown data is a broken client. The
earlier they fall apart the better so that they get fixed.
Even if they don't break, debug and diagnostics information can be very 
verbose.


If a client had 4 connections to a device for monitoring different 
things, then you don't want to suddenly start sending a large amount of 
extra diagnostics data on each of the 4 connections when they have only 
requested it on one connection.  Generating this extra data could 
overload the client or the device, or certainly lead to degraded 
performance in some way or another.


Thanks,
Rob




/js



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

Re: [netmod] Modelling different "levels" of data in YANG

[Juergen Schoenwaelder]

On Fri, Dec 09, 2016 at 10:54:14AM +, Robert Wilton wrote:
> 
> Assuming that diagnostics information was specified for each of N different
> protocols on a device.  Then this would seem to mean that every device would
> have to install N default NACM deny entries (one for each supported
> protocol) to ensure that the device has sensible default operator semantics.
> This would seem to be quite a burden on the industry.
> 
> A solution that doesn't rely on every server inserting lots of NACM entries
> by default seems like a better choice to me.
>

Did I say that there need to be N? And why would N hard coded toggles
in data models be simpler and not a burden for the industry? What is
the definition of 'burden for the industry' anyway?

/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] Modelling different "levels" of data in YANG

[Juergen Schoenwaelder]

On Fri, Dec 09, 2016 at 11:05:47AM +, Robert Wilton wrote:
> 
> OK, so this is closer, but still would mean that enabling the debug flag via
> RPC would potentially cause all clients to start to see the diagnostics
> information (which may break them).
>

A client that breaks when receiving unknown data is a broken client. The
earlier they fall apart the better so that they get fixed.

/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] Modelling different "levels" of data in YANG

[Ladislav Lhotka]

> On 9 Dec 2016, at 11:48, Robert Wilton  wrote:
> 
> Hi Lada,
> 
> 
> On 09/12/2016 10:33, Ladislav Lhotka wrote:
>> Hi Rob,
>> 
>> I didn't follow the previous discussion closely but a natural solution
>> seems to be to define a leaf like "debug" - it could be just boolean or
>> an enumeration of debug levels. And then add the diagnostic
>> data as an augment that conditionally depends on the value of the
>> "debug" leaf.
>> 
>> Would this work?
> I'm not sure.
> 
> Historically debug has been separate from configuration.  I.e. you wouldn't 
> normally expect debug settings to persist after rebooting the device.

Yes, good point. So what you can do is to have a "debug" RPC, show "debug" 
value in state data, and still make the augment with diagnostics conditionally 
dependent on the debug leaf.

Lada

> Possibly debug could be modeled using I2RS, but that would be tying its fate 
> to I2RS, and I'm not sure whether I2RS will gain widespread adoption.
> 
> Although I raised my concern specification related to Ethernet clause 45 
> registers, I think that my question is really more general about whether 
> debug/diagnostics should be modeled in YANG and if so how that should be 
> done.   Perhaps, we should just concentrate on getting the basis config and 
> operational state models sorted out initially and then figure out how 
> diagnostics should be modeled at a later date?
> 
> Rob
> 
>> Lada
>> 
>> Robert Wilton  writes:
>> 
>>> On 07/12/2016 16:13, Juergen Schoenwaelder wrote:
 On Wed, Dec 07, 2016 at 02:39:00PM +, Robert Wilton wrote:
> Alas, xpath filtering is optional, and I'm not sure how many devices have
> implemented support for it.  Further, this still requires every client to 
> be
> coded to avoid receiving the information that they are very unlikely to be
> interested in.
> 
> I would much prefer a solution where the clients don't get this (mostly
> noise) data unless they explicitly ask for it.  Otherwise for an Ethernet
> interface you might return 10 leaves of potentially useful opstate
> information, along with 50+ leaves of quite low layer diagnostics
> information that is likely to be of very little use except for to the 
> select
> few people that are actively involved in trying to diagnose hardware 
> faults.
> 
 I expect that there will be many augmentations to lets say /interfaces
 (or /interfaces-state). How does a data model writer determine which
 ones are 'noise' and which ones are not? How does a a data model
 writer determine which ones are costly to implement and which ones are
 not (since this may vary widely between systems)?
>>> It isn't so much as it being noise. I see that the two quite different
>>> sets of config false nodes are:
>>> 
>>> (1) The first set of nodes are those that are useful to a client to
>>> manage a device and to determine whether the device's actual behaviour
>>> matches the expected behaviour based on the configuration.  This is the
>>> same set of data that has traditionally been modeled via SNMP, and I
>>> think of as being the operational state of the device.
>>> 
>>> (2) If it is determined from the nodes above that a device is behaving
>>> in an abnormal way, then the second set of nodes are aimed at device
>>> developers/engineers to ascertain why the device is not behaving as
>>> specified.  A lot of this internal diagnostics information may only be
>>> of use to a developer who is familiar with the code (or intricacies of
>>> the hardware), and/or has a deep level of understanding of how a
>>> particular feature works.  I would see that most of this information is
>>> very likely to be device specific, and presented in a device specific
>>> way, and may include internal debug and dumps of internal data-structures.
>>> 
>>> I believe that most of the time, operators are only interested in
>>> interacting with that first set of data because that is all that is
>>> useful and required to manage their devices, and hence that is what I
>>> think should be modeled in the operational state datastore. However, in
>>> many cases, having a standard automated way of fetching that second set
>>> of data is still useful, because it facilitates more efficient
>>> diagnostic tools to be created in the future.
>>> 
>>> Specifically for Ethernet, 802.3 specifies a clear separation between
>>> what they expect to be made available via a management protocol vs what
>>> is regarded as being an internal API, specifically:
>>>   -802.3 Clause 30 specifies the main management objects, that I would
>>> expect to be broadly accessible to management clients, and what we are
>>> planning on basing the Ethernet YANG on.  (This is consistent with what
>>> is available in the Ethernet related MIBs and the OpenConfig Ethernet
>>> model).
>>>   - the internal interface is defined as the MDIO registers in 802.3
>>> Clause 45.  Looking at these 

Re: [netmod] Modelling different "levels" of data in YANG

[Robert Wilton]

On 08/12/2016 19:11, Juergen Schoenwaelder wrote:

On Thu, Dec 08, 2016 at 05:49:11PM +, Robert Wilton wrote:

On 07/12/2016 16:13, Juergen Schoenwaelder wrote:

On Wed, Dec 07, 2016 at 02:39:00PM +, Robert Wilton wrote:

Alas, xpath filtering is optional, and I'm not sure how many devices have
implemented support for it.  Further, this still requires every client to be
coded to avoid receiving the information that they are very unlikely to be
interested in.

I would much prefer a solution where the clients don't get this (mostly
noise) data unless they explicitly ask for it.  Otherwise for an Ethernet
interface you might return 10 leaves of potentially useful opstate
information, along with 50+ leaves of quite low layer diagnostics
information that is likely to be of very little use except for to the select
few people that are actively involved in trying to diagnose hardware faults.


I expect that there will be many augmentations to lets say /interfaces
(or /interfaces-state). How does a data model writer determine which
ones are 'noise' and which ones are not? How does a a data model
writer determine which ones are costly to implement and which ones are
not (since this may vary widely between systems)?

It isn't so much as it being noise. I see that the two quite different sets
of config false nodes are:

(1) The first set of nodes are those that are useful to a client to manage a
device and to determine whether the device's actual behaviour matches the
expected behaviour based on the configuration.  This is the same set of data
that has traditionally been modeled via SNMP, and I think of as being the
operational state of the device.

(2) If it is determined from the nodes above that a device is behaving in an
abnormal way, then the second set of nodes are aimed at device
developers/engineers to ascertain why the device is not behaving as
specified.  A lot of this internal diagnostics information may only be of
use to a developer who is familiar with the code (or intricacies of the
hardware), and/or has a deep level of understanding of how a particular
feature works.  I would see that most of this information is very likely to
be device specific, and presented in a device specific way, and may include
internal debug and dumps of internal data-structures.

The simply disable this module on a production system.


Alas I don't think that this would help.  The aim is that the 
information is still available on production systems, just not returned 
by default.




I believe that most of the time, operators are only interested in
interacting with that first set of data because that is all that is useful
and required to manage their devices, and hence that is what I think should
be modeled in the operational state datastore. However, in many cases,
having a standard automated way of fetching that second set of data is still
useful, because it facilitates more efficient diagnostic tools to be created
in the future.

Than leave the data model active and make NACM grant access to this
data only for engineers.
Assuming that diagnostics information was specified for each of N 
different protocols on a device.  Then this would seem to mean that 
every device would have to install N default NACM deny entries (one for 
each supported protocol) to ensure that the device has sensible default 
operator semantics.  This would seem to be quite a burden on the industry.


A solution that doesn't rely on every server inserting lots of NACM 
entries by default seems like a better choice to me.


Thanks,
Rob




/js



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

Re: [netmod] Modelling different "levels" of data in YANG

[Robert Wilton]

Hi Lada,


On 09/12/2016 10:33, Ladislav Lhotka wrote:

Hi Rob,

I didn't follow the previous discussion closely but a natural solution
seems to be to define a leaf like "debug" - it could be just boolean or
an enumeration of debug levels. And then add the diagnostic
data as an augment that conditionally depends on the value of the
"debug" leaf.

Would this work?

I'm not sure.

Historically debug has been separate from configuration.  I.e. you 
wouldn't normally expect debug settings to persist after rebooting the 
device.  Possibly debug could be modeled using I2RS, but that would be 
tying its fate to I2RS, and I'm not sure whether I2RS will gain 
widespread adoption.


Although I raised my concern specification related to Ethernet clause 45 
registers, I think that my question is really more general about whether 
debug/diagnostics should be modeled in YANG and if so how that should be 
done.   Perhaps, we should just concentrate on getting the basis config 
and operational state models sorted out initially and then figure out 
how diagnostics should be modeled at a later date?


Rob


Lada

Robert Wilton  writes:


On 07/12/2016 16:13, Juergen Schoenwaelder wrote:

On Wed, Dec 07, 2016 at 02:39:00PM +, Robert Wilton wrote:

Alas, xpath filtering is optional, and I'm not sure how many devices have
implemented support for it.  Further, this still requires every client to be
coded to avoid receiving the information that they are very unlikely to be
interested in.

I would much prefer a solution where the clients don't get this (mostly
noise) data unless they explicitly ask for it.  Otherwise for an Ethernet
interface you might return 10 leaves of potentially useful opstate
information, along with 50+ leaves of quite low layer diagnostics
information that is likely to be of very little use except for to the select
few people that are actively involved in trying to diagnose hardware faults.


I expect that there will be many augmentations to lets say /interfaces
(or /interfaces-state). How does a data model writer determine which
ones are 'noise' and which ones are not? How does a a data model
writer determine which ones are costly to implement and which ones are
not (since this may vary widely between systems)?

It isn't so much as it being noise. I see that the two quite different
sets of config false nodes are:

(1) The first set of nodes are those that are useful to a client to
manage a device and to determine whether the device's actual behaviour
matches the expected behaviour based on the configuration.  This is the
same set of data that has traditionally been modeled via SNMP, and I
think of as being the operational state of the device.

(2) If it is determined from the nodes above that a device is behaving
in an abnormal way, then the second set of nodes are aimed at device
developers/engineers to ascertain why the device is not behaving as
specified.  A lot of this internal diagnostics information may only be
of use to a developer who is familiar with the code (or intricacies of
the hardware), and/or has a deep level of understanding of how a
particular feature works.  I would see that most of this information is
very likely to be device specific, and presented in a device specific
way, and may include internal debug and dumps of internal data-structures.

I believe that most of the time, operators are only interested in
interacting with that first set of data because that is all that is
useful and required to manage their devices, and hence that is what I
think should be modeled in the operational state datastore. However, in
many cases, having a standard automated way of fetching that second set
of data is still useful, because it facilitates more efficient
diagnostic tools to be created in the future.

Specifically for Ethernet, 802.3 specifies a clear separation between
what they expect to be made available via a management protocol vs what
is regarded as being an internal API, specifically:
   -802.3 Clause 30 specifies the main management objects, that I would
expect to be broadly accessible to management clients, and what we are
planning on basing the Ethernet YANG on.  (This is consistent with what
is available in the Ethernet related MIBs and the OpenConfig Ethernet
model).
   - the internal interface is defined as the MDIO registers in 802.3
Clause 45.  Looking at these register definitions, although the
registers themselves can be given meaningful names, the values
themselves would probably just be returned as opaque 16 bit register
values, since the YANG "bits" type isn't flexible enough to represent
the packed values they sometimes contain (specifically where they are
using a set of bits to represent an enumerated value).



Perhaps it is useful to tell client writers that well behaving clients
should ask for what they need (and understand) and that they should
avoid asking generic 'give me everything you have' questions.

I really think that there are two 

Re: [netmod] Modelling different "levels" of data in YANG

[Ladislav Lhotka]

Hi Rob,

I didn't follow the previous discussion closely but a natural solution
seems to be to define a leaf like "debug" - it could be just boolean or
an enumeration of debug levels. And then add the diagnostic
data as an augment that conditionally depends on the value of the
"debug" leaf.

Would this work?

Lada

Robert Wilton  writes:

> On 07/12/2016 16:13, Juergen Schoenwaelder wrote:
>> On Wed, Dec 07, 2016 at 02:39:00PM +, Robert Wilton wrote:
>>> Alas, xpath filtering is optional, and I'm not sure how many devices have
>>> implemented support for it.  Further, this still requires every client to be
>>> coded to avoid receiving the information that they are very unlikely to be
>>> interested in.
>>>
>>> I would much prefer a solution where the clients don't get this (mostly
>>> noise) data unless they explicitly ask for it.  Otherwise for an Ethernet
>>> interface you might return 10 leaves of potentially useful opstate
>>> information, along with 50+ leaves of quite low layer diagnostics
>>> information that is likely to be of very little use except for to the select
>>> few people that are actively involved in trying to diagnose hardware faults.
>>>
>> I expect that there will be many augmentations to lets say /interfaces
>> (or /interfaces-state). How does a data model writer determine which
>> ones are 'noise' and which ones are not? How does a a data model
>> writer determine which ones are costly to implement and which ones are
>> not (since this may vary widely between systems)?
> It isn't so much as it being noise. I see that the two quite different 
> sets of config false nodes are:
>
> (1) The first set of nodes are those that are useful to a client to 
> manage a device and to determine whether the device's actual behaviour 
> matches the expected behaviour based on the configuration.  This is the 
> same set of data that has traditionally been modeled via SNMP, and I 
> think of as being the operational state of the device.
>
> (2) If it is determined from the nodes above that a device is behaving 
> in an abnormal way, then the second set of nodes are aimed at device 
> developers/engineers to ascertain why the device is not behaving as 
> specified.  A lot of this internal diagnostics information may only be 
> of use to a developer who is familiar with the code (or intricacies of 
> the hardware), and/or has a deep level of understanding of how a 
> particular feature works.  I would see that most of this information is 
> very likely to be device specific, and presented in a device specific 
> way, and may include internal debug and dumps of internal data-structures.
>
> I believe that most of the time, operators are only interested in 
> interacting with that first set of data because that is all that is 
> useful and required to manage their devices, and hence that is what I 
> think should be modeled in the operational state datastore. However, in 
> many cases, having a standard automated way of fetching that second set 
> of data is still useful, because it facilitates more efficient 
> diagnostic tools to be created in the future.
>
> Specifically for Ethernet, 802.3 specifies a clear separation between 
> what they expect to be made available via a management protocol vs what 
> is regarded as being an internal API, specifically:
>   -802.3 Clause 30 specifies the main management objects, that I would 
> expect to be broadly accessible to management clients, and what we are 
> planning on basing the Ethernet YANG on.  (This is consistent with what 
> is available in the Ethernet related MIBs and the OpenConfig Ethernet 
> model).
>   - the internal interface is defined as the MDIO registers in 802.3 
> Clause 45.  Looking at these register definitions, although the 
> registers themselves can be given meaningful names, the values 
> themselves would probably just be returned as opaque 16 bit register 
> values, since the YANG "bits" type isn't flexible enough to represent 
> the packed values they sometimes contain (specifically where they are 
> using a set of bits to represent an enumerated value).
>
>
>>
>> Perhaps it is useful to tell client writers that well behaving clients
>> should ask for what they need (and understand) and that they should
>> avoid asking generic 'give me everything you have' questions.
> I really think that there are two separate classes of data here, and it 
> makes more sense to treat them as such.
>
> Defining RPCs to fetch the internal diagnostics data on demand seems OK 
> to me, or alternatively marking the nodes as being diagnostics related 
> and putting that in a separate datastore would seem to be reasonable.
>
>>
>> If you have to deal with lazy clients that like to grab everything,
>> you can control them via NACM. Simply exclude access to some branches.
> This will likely just mean that every device would have to support this 
> NACM to handle the mainline case.  That sounds like a lot of extra 
> unnecessary 

Re: [netmod] Modelling different "levels" of data in YANG

[Juergen Schoenwaelder]

On Thu, Dec 08, 2016 at 05:49:11PM +, Robert Wilton wrote:
> 
> On 07/12/2016 16:13, Juergen Schoenwaelder wrote:
> > On Wed, Dec 07, 2016 at 02:39:00PM +, Robert Wilton wrote:
> > > Alas, xpath filtering is optional, and I'm not sure how many devices have
> > > implemented support for it.  Further, this still requires every client to 
> > > be
> > > coded to avoid receiving the information that they are very unlikely to be
> > > interested in.
> > > 
> > > I would much prefer a solution where the clients don't get this (mostly
> > > noise) data unless they explicitly ask for it.  Otherwise for an Ethernet
> > > interface you might return 10 leaves of potentially useful opstate
> > > information, along with 50+ leaves of quite low layer diagnostics
> > > information that is likely to be of very little use except for to the 
> > > select
> > > few people that are actively involved in trying to diagnose hardware 
> > > faults.
> > > 
> > I expect that there will be many augmentations to lets say /interfaces
> > (or /interfaces-state). How does a data model writer determine which
> > ones are 'noise' and which ones are not? How does a a data model
> > writer determine which ones are costly to implement and which ones are
> > not (since this may vary widely between systems)?
> It isn't so much as it being noise. I see that the two quite different sets
> of config false nodes are:
> 
> (1) The first set of nodes are those that are useful to a client to manage a
> device and to determine whether the device's actual behaviour matches the
> expected behaviour based on the configuration.  This is the same set of data
> that has traditionally been modeled via SNMP, and I think of as being the
> operational state of the device.
> 
> (2) If it is determined from the nodes above that a device is behaving in an
> abnormal way, then the second set of nodes are aimed at device
> developers/engineers to ascertain why the device is not behaving as
> specified.  A lot of this internal diagnostics information may only be of
> use to a developer who is familiar with the code (or intricacies of the
> hardware), and/or has a deep level of understanding of how a particular
> feature works.  I would see that most of this information is very likely to
> be device specific, and presented in a device specific way, and may include
> internal debug and dumps of internal data-structures.

The simply disable this module on a production system.
 
> I believe that most of the time, operators are only interested in
> interacting with that first set of data because that is all that is useful
> and required to manage their devices, and hence that is what I think should
> be modeled in the operational state datastore. However, in many cases,
> having a standard automated way of fetching that second set of data is still
> useful, because it facilitates more efficient diagnostic tools to be created
> in the future.

Than leave the data model active and make NACM grant access to this
data only for engineers.

/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] Modelling different "levels" of data in YANG

[Robert Wilton]

On 07/12/2016 16:13, Juergen Schoenwaelder wrote:

On Wed, Dec 07, 2016 at 02:39:00PM +, Robert Wilton wrote:

Alas, xpath filtering is optional, and I'm not sure how many devices have
implemented support for it.  Further, this still requires every client to be
coded to avoid receiving the information that they are very unlikely to be
interested in.

I would much prefer a solution where the clients don't get this (mostly
noise) data unless they explicitly ask for it.  Otherwise for an Ethernet
interface you might return 10 leaves of potentially useful opstate
information, along with 50+ leaves of quite low layer diagnostics
information that is likely to be of very little use except for to the select
few people that are actively involved in trying to diagnose hardware faults.


I expect that there will be many augmentations to lets say /interfaces
(or /interfaces-state). How does a data model writer determine which
ones are 'noise' and which ones are not? How does a a data model
writer determine which ones are costly to implement and which ones are
not (since this may vary widely between systems)?
It isn't so much as it being noise. I see that the two quite different 
sets of config false nodes are:


(1) The first set of nodes are those that are useful to a client to 
manage a device and to determine whether the device's actual behaviour 
matches the expected behaviour based on the configuration.  This is the 
same set of data that has traditionally been modeled via SNMP, and I 
think of as being the operational state of the device.


(2) If it is determined from the nodes above that a device is behaving 
in an abnormal way, then the second set of nodes are aimed at device 
developers/engineers to ascertain why the device is not behaving as 
specified.  A lot of this internal diagnostics information may only be 
of use to a developer who is familiar with the code (or intricacies of 
the hardware), and/or has a deep level of understanding of how a 
particular feature works.  I would see that most of this information is 
very likely to be device specific, and presented in a device specific 
way, and may include internal debug and dumps of internal data-structures.


I believe that most of the time, operators are only interested in 
interacting with that first set of data because that is all that is 
useful and required to manage their devices, and hence that is what I 
think should be modeled in the operational state datastore. However, in 
many cases, having a standard automated way of fetching that second set 
of data is still useful, because it facilitates more efficient 
diagnostic tools to be created in the future.


Specifically for Ethernet, 802.3 specifies a clear separation between 
what they expect to be made available via a management protocol vs what 
is regarded as being an internal API, specifically:
 -802.3 Clause 30 specifies the main management objects, that I would 
expect to be broadly accessible to management clients, and what we are 
planning on basing the Ethernet YANG on.  (This is consistent with what 
is available in the Ethernet related MIBs and the OpenConfig Ethernet 
model).
 - the internal interface is defined as the MDIO registers in 802.3 
Clause 45.  Looking at these register definitions, although the 
registers themselves can be given meaningful names, the values 
themselves would probably just be returned as opaque 16 bit register 
values, since the YANG "bits" type isn't flexible enough to represent 
the packed values they sometimes contain (specifically where they are 
using a set of bits to represent an enumerated value).





Perhaps it is useful to tell client writers that well behaving clients
should ask for what they need (and understand) and that they should
avoid asking generic 'give me everything you have' questions.
I really think that there are two separate classes of data here, and it 
makes more sense to treat them as such.


Defining RPCs to fetch the internal diagnostics data on demand seems OK 
to me, or alternatively marking the nodes as being diagnostics related 
and putting that in a separate datastore would seem to be reasonable.




If you have to deal with lazy clients that like to grab everything,
you can control them via NACM. Simply exclude access to some branches.
This will likely just mean that every device would have to support this 
NACM to handle the mainline case.  That sounds like a lot of extra 
unnecessary work for everyone.


Thanks,
Rob



/js



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

Re: [netmod] Modelling different "levels" of data in YANG

[Juergen Schoenwaelder]

On Wed, Dec 07, 2016 at 02:39:00PM +, Robert Wilton wrote:
> 
> Alas, xpath filtering is optional, and I'm not sure how many devices have
> implemented support for it.  Further, this still requires every client to be
> coded to avoid receiving the information that they are very unlikely to be
> interested in.
> 
> I would much prefer a solution where the clients don't get this (mostly
> noise) data unless they explicitly ask for it.  Otherwise for an Ethernet
> interface you might return 10 leaves of potentially useful opstate
> information, along with 50+ leaves of quite low layer diagnostics
> information that is likely to be of very little use except for to the select
> few people that are actively involved in trying to diagnose hardware faults.
>

I expect that there will be many augmentations to lets say /interfaces
(or /interfaces-state). How does a data model writer determine which
ones are 'noise' and which ones are not? How does a a data model
writer determine which ones are costly to implement and which ones are
not (since this may vary widely between systems)?

Perhaps it is useful to tell client writers that well behaving clients
should ask for what they need (and understand) and that they should
avoid asking generic 'give me everything you have' questions.

If you have to deal with lazy clients that like to grab everything,
you can control them via NACM. Simply exclude access to some branches.

/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] Modelling different "levels" of data in YANG

[Robert Wilton]

Hi,


On 07/12/2016 13:30, Vladimir Vassilev wrote:

On 12/06/2016 10:03 PM, Alex Campbell wrote:

IMO using an action or rpc is an okay solution for now, certainly 
better than than not including the data at all.


If I have to chose between RPC with 'output' containing the state data 
for selected interface and mapping the data to a container/list not 
under /interfaces-state (e.g. another top level container) I prefer 
the second option since notifications and data models in general can 
refer to it as part of the data tree. It allows for simpler monitoring 
and implementation of alarms etc.


Given that there is a desire (draft-nmdsdt-netmod-revised-datastores-00, 
section 6.4) to deprecate "/foo-state" and to merge it with the 
configuration held under "/foo" then I would think that introducing a 
new top level "/foo-diagnostics" would seem to be heading in the wrong 
direction.


Athanasios' suggestion to just define RPCs for this information, and 
only make the information available via RPC operations, seems like a 
reasonable one.  Clients don't get spammed with stuff that they don't 
care about, but the information is still programmatically available if 
it is required.






Perhaps in the future the client could specify which YANG modules it 
cares about, in addition to a subtree filter. Then you could put the 
extended diagnostic information into another module (using 
"augment"), and clients that don't know about the extended diagnostic 
information wouldn't request it, and clients that do would know to 
only request it when they need it.
One can use xpath 1.0 filter. This option is already available. 
Example  RPC retrieving only state data of interest.


...
  
select="//*[namespace-uri()='urn:ietf:params:xml:ns:yang:ietf-interfaces' 
or namespace-uri()='urn:ietf:params:xml:ns:yang:ietf-system']"/>

  
...

Sane server implementations will skip the time consuming calbacks 
retrieving detailed data defined in other modules then ietf-intefaces 
and ietf-system.


Alas, xpath filtering is optional, and I'm not sure how many devices 
have implemented support for it.  Further, this still requires every 
client to be coded to avoid receiving the information that they are very 
unlikely to be interested in.


I would much prefer a solution where the clients don't get this (mostly 
noise) data unless they explicitly ask for it.  Otherwise for an 
Ethernet interface you might return 10 leaves of potentially useful 
opstate information, along with 50+ leaves of quite low layer 
diagnostics information that is likely to be of very little use except 
for to the select few people that are actively involved in trying to 
diagnose hardware faults.


Thanks,
Rob




/Vladimir

___
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] Modelling different "levels" of data in YANG

[Vladimir Vassilev]

On 12/06/2016 10:03 PM, Alex Campbell wrote:

IMO using an action or rpc is an okay solution for now, certainly 
better than than not including the data at all.


If I have to chose between RPC with 'output' containing the state data 
for selected interface and mapping the data to a container/list not 
under /interfaces-state (e.g. another top level container) I prefer the 
second option since notifications and data models in general can refer 
to it as part of the data tree. It allows for simpler monitoring and 
implementation of alarms etc.



Perhaps in the future the client could specify which YANG modules it 
cares about, in addition to a subtree filter. Then you could put the 
extended diagnostic information into another module (using "augment"), 
and clients that don't know about the extended diagnostic information 
wouldn't request it, and clients that do would know to only request it 
when they need it.
One can use xpath 1.0 filter. This option is already available. Example 
 RPC retrieving only state data of interest.


...
  
select="//*[namespace-uri()='urn:ietf:params:xml:ns:yang:ietf-interfaces' 
or namespace-uri()='urn:ietf:params:xml:ns:yang:ietf-system']"/>

  
...

Sane server implementations will skip the time consuming calbacks 
retrieving detailed data defined in other modules then ietf-intefaces 
and ietf-system.


/Vladimir

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

Re: [netmod] Modelling different "levels" of data in YANG

[Juergen Schoenwaelder]

On Wed, Dec 07, 2016 at 12:25:59PM +0100, Vladimir Vassilev wrote:
> On 12/06/2016 10:40 PM, Juergen Schoenwaelder wrote:
> 
> > I fear that a dumb client sending a  without a proper filter to
> > select the data that is relevant for the client will not necessarily
> > get smarter by defining additional operations.
> > 
> > Sometimes access control can help to control dumb clients that try to
> > get everything (and then ignore most of the data they receive); simply
> > make sure that only the information is accessible to a client that is
> > actually needed by a client. In other words, the filtering logic does
> > not have to be hard coded in the data model.
> +1
> 
> One additional solution for consideration is a new top level config=false
> container with a list e.g. /ethernet-interfaces-state/ethernet-interface/...
> where the key is leafref to /interfaces-state/interface/name With this
> solution IMO all requirements mentioned in the discussion so far are
> satisfied without the need to introduce any RPCs or hard coding filtering
> logic in the model.
>

This may help until the dumb client grabs /ethernet-interfaces-state
as well.

/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] Modelling different "levels" of data in YANG

[Vladimir Vassilev]

On 12/06/2016 10:40 PM, Juergen Schoenwaelder wrote:


I fear that a dumb client sending a  without a proper filter to
select the data that is relevant for the client will not necessarily
get smarter by defining additional operations.

Sometimes access control can help to control dumb clients that try to
get everything (and then ignore most of the data they receive); simply
make sure that only the information is accessible to a client that is
actually needed by a client. In other words, the filtering logic does
not have to be hard coded in the data model.

+1

One additional solution for consideration is a new top level 
config=false container with a list e.g. 
/ethernet-interfaces-state/ethernet-interface/... where the key is 
leafref to /interfaces-state/interface/name With this solution IMO all 
requirements mentioned in the discussion so far are satisfied without 
the need to introduce any RPCs or hard coding filtering logic in the model.


/Vladimir



/js


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

Re: [netmod] Modelling different "levels" of data in YANG

[Juergen Schoenwaelder]

I fear that a dumb client sending a  without a proper filter to
select the data that is relevant for the client will not necessarily
get smarter by defining additional operations.

Sometimes access control can help to control dumb clients that try to
get everything (and then ignore most of the data they receive); simply
make sure that only the information is accessible to a client that is
actually needed by a client. In other words, the filtering logic does
not have to be hard coded in the data model.

/js

On Tue, Dec 06, 2016 at 09:03:09PM +, Alex Campbell wrote:
> IMO using an action or rpc is an okay solution for now, certainly better than 
> than not including the data at all.
> 
> 
> Perhaps in the future the client could specify which YANG modules it cares 
> about, in addition to a subtree filter. Then you could put the extended 
> diagnostic information into another module (using "augment"), and clients 
> that don't know about the extended diagnostic information wouldn't request 
> it, and clients that do would know to only request it when they need it.
> 
> 
> The problem also makes me think of ConfD's "hide groups", but it's hard to 
> see how those would be extended to support programmatic interfaces.
> 
> 
> 
> From: netmod <netmod-boun...@ietf.org> on behalf of Robert Wilton 
> <rwil...@cisco.com>
> Sent: Wednesday, 7 December 2016 3:58 a.m.
> To: Athanasios Kyparlis; netmod@ietf.org
> Subject: Re: [netmod] Modelling different "levels" of data in YANG
> 
> 
> Hi Athanasios,
> 
> 
> Thanks for the suggestion.  As per my reply to Vladimir, I think that this 
> solves the question of how to get them, but doesn't really solve the issue of 
> how a client is expected to know that they wouldn't be included in a regular 
> get request.
> 
> 
> Thanks,
> Rob
> 
> 
> On 05/12/2016 18:25, Athanasios Kyparlis wrote:
> 
> Maybe not ideal, but could we use an action or rpc for them?
> 
> 
> From: netmod <netmod-boun...@ietf.org><mailto:netmod-boun...@ietf.org> on 
> behalf of Robert Wilton <rwil...@cisco.com><mailto:rwil...@cisco.com>
> Sent: Monday, December 5, 2016 1:10:47 PM
> To: netmod@ietf.org<mailto:netmod@ietf.org>
> Cc: Peter Jones
> Subject: [netmod] Modelling different "levels" of data in YANG
> 
> Hi,
> 
> We are currently working on modelling 802.3 Ethernet YANG within the
> 802.3 YANG study group.
> 
> One interesting issue that has come up is the scope of the operational
> state data that could be modeled:
> 
> At the top level, an operator may just want to know whether an Ethernet
> interface is up or down.
> 
> At a second level, if the Ethernet interface is down, then there is some
> high level diagnostics information that may be useful to an operator to
> diagnose why the interface isn't up (e.g. alarms information, optical
> power levels, auto-negotiation protocol status).
> 
> There is also a third level, of very detailed, 802.3 hardware register
> information defined in 802.3 Clause 45.  Such information is probably of
> most relevance to the engineers developing and programming Ethernet
> chips and PHYs, but is sometimes useful for resolving potential vendor
> inter-operation issues.  Retrieving this information out of the Ethernet
> chips can be comparatively slow.
> 
> The question that was being discussed is whether it is appropriate to
> model all three levels on information in the 802.3 Ethernet YANG models,
> or whether only the top level and second level information can/should be
> modeled via YANG?
> 
> If we were to model the third level information in YANG then it would
> seem highly desirable for that information to not be returned in
> response to a general NETCONF  request because the information is
> generally not of relevance and has potential performance issues in
> returning it.  Instead, it would seem desirable to only return this data
> if it was specifically requested (e.g. a  request on the node
> containing the third level information), or if a hypothetical filter
> extension was specified and used to explicitly include it in the
> response. Given that there doesn't seem to a great way to currently
> achieve this in YANG, this makes me think that it isn't sensible to
> model this third level of detailed information in YANG at this time.  Do
> others agree?
> 
> Have others faced similar issues, and if so, how have you solved them?
> 
> Input welcome.  Thanks,
> Rob
> 
> 
> ___
> netmod mailing list
> netmod@ietf.org<mailto:netmod@ietf.org>
> https

Re: [netmod] Modelling different "levels" of data in YANG

[Alex Campbell]

IMO using an action or rpc is an okay solution for now, certainly better than 
than not including the data at all.


Perhaps in the future the client could specify which YANG modules it cares 
about, in addition to a subtree filter. Then you could put the extended 
diagnostic information into another module (using "augment"), and clients that 
don't know about the extended diagnostic information wouldn't request it, and 
clients that do would know to only request it when they need it.


The problem also makes me think of ConfD's "hide groups", but it's hard to see 
how those would be extended to support programmatic interfaces.



From: netmod <netmod-boun...@ietf.org> on behalf of Robert Wilton 
<rwil...@cisco.com>
Sent: Wednesday, 7 December 2016 3:58 a.m.
To: Athanasios Kyparlis; netmod@ietf.org
Subject: Re: [netmod] Modelling different "levels" of data in YANG


Hi Athanasios,


Thanks for the suggestion.  As per my reply to Vladimir, I think that this 
solves the question of how to get them, but doesn't really solve the issue of 
how a client is expected to know that they wouldn't be included in a regular 
get request.


Thanks,
Rob


On 05/12/2016 18:25, Athanasios Kyparlis wrote:

Maybe not ideal, but could we use an action or rpc for them?


From: netmod <netmod-boun...@ietf.org><mailto:netmod-boun...@ietf.org> on 
behalf of Robert Wilton <rwil...@cisco.com><mailto:rwil...@cisco.com>
Sent: Monday, December 5, 2016 1:10:47 PM
To: netmod@ietf.org<mailto:netmod@ietf.org>
Cc: Peter Jones
Subject: [netmod] Modelling different "levels" of data in YANG

Hi,

We are currently working on modelling 802.3 Ethernet YANG within the
802.3 YANG study group.

One interesting issue that has come up is the scope of the operational
state data that could be modeled:

At the top level, an operator may just want to know whether an Ethernet
interface is up or down.

At a second level, if the Ethernet interface is down, then there is some
high level diagnostics information that may be useful to an operator to
diagnose why the interface isn't up (e.g. alarms information, optical
power levels, auto-negotiation protocol status).

There is also a third level, of very detailed, 802.3 hardware register
information defined in 802.3 Clause 45.  Such information is probably of
most relevance to the engineers developing and programming Ethernet
chips and PHYs, but is sometimes useful for resolving potential vendor
inter-operation issues.  Retrieving this information out of the Ethernet
chips can be comparatively slow.

The question that was being discussed is whether it is appropriate to
model all three levels on information in the 802.3 Ethernet YANG models,
or whether only the top level and second level information can/should be
modeled via YANG?

If we were to model the third level information in YANG then it would
seem highly desirable for that information to not be returned in
response to a general NETCONF  request because the information is
generally not of relevance and has potential performance issues in
returning it.  Instead, it would seem desirable to only return this data
if it was specifically requested (e.g. a  request on the node
containing the third level information), or if a hypothetical filter
extension was specified and used to explicitly include it in the
response. Given that there doesn't seem to a great way to currently
achieve this in YANG, this makes me think that it isn't sensible to
model this third level of detailed information in YANG at this time.  Do
others agree?

Have others faced similar issues, and if so, how have you solved them?

Input welcome.  Thanks,
Rob


___
netmod mailing list
netmod@ietf.org<mailto: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] Modelling different "levels" of data in YANG

[Robert Wilton]

Hi Vladimir,

Thanks for your suggestion.  Please see some comments inline ...

On 06/12/2016 10:34, Vladimir Vassilev wrote:

On 12/05/2016 07:10 PM, Robert Wilton wrote:


Hi,

We are currently working on modelling 802.3 Ethernet YANG within the 
802.3 YANG study group.


One interesting issue that has come up is the scope of the 
operational state data that could be modeled:


At the top level, an operator may just want to know whether an 
Ethernet interface is up or down.


At a second level, if the Ethernet interface is down, then there is 
some high level diagnostics information that may be useful to an 
operator to diagnose why the interface isn't up (e.g. alarms 
information, optical power levels, auto-negotiation protocol status).


There is also a third level, of very detailed, 802.3 hardware 
register information defined in 802.3 Clause 45.  Such information is 
probably of most relevance to the engineers developing and 
programming Ethernet chips and PHYs, but is sometimes useful for 
resolving potential vendor inter-operation issues.  Retrieving this 
information out of the Ethernet chips can be comparatively slow.


The question that was being discussed is whether it is appropriate to 
model all three levels on information in the 802.3 Ethernet YANG 
models, or whether only the top level and second level information 
can/should be modeled via YANG?


If we were to model the third level information in YANG then it would 
seem highly desirable for that information to not be returned in 
response to a general NETCONF  request because the information 
is generally not of relevance and has potential performance issues in 
returning it.  Instead, it would seem desirable to only return this 
data if it was specifically requested (e.g. a  request on the 
node containing the third level information), or if a hypothetical 
filter extension was specified and used to explicitly include it in 
the response. Given that there doesn't seem to a great way to 
currently achieve this in YANG, this makes me think that it isn't 
sensible to model this third level of detailed information in YANG at 
this time.  Do others agree?


Have others faced similar issues, and if so, how have you solved them?
How about having this state data reside under a config=true presence 
container e.g. /interfaces/interface/ethernet-detailed-state... . The 
user can then create the container for the interfaces he is interested 
in reading the detailed state data.


I'm not too keen on this approach.  This would mean that an operator 
would need to have NACM permissions to modify the configuration to be 
allowed to retrieve read-only diagnostics information.





Or have dedicated RPC in the model that enables/disables the presence 
of the detailed state information for certain interfaces. Since the 
state container is not mandatory.


This would sort of work, but then there is still some magic involved for 
the client and device to have the knowledge not to return the 
diagnostics information in a standard get request.  I was thinking that 
defining an extension to mark the leaves in the schema as being 
diagnostics information might be the right way forward.  However, I was 
also thinking that just getting the basic (non diagnostics) operational 
YANG specified would be a useful first step along the 802.3 Ethernet 
model path.




In any case a grouping with the 802.3 Clause 45 information data will 
definitely be usefull.


Given that there are a quite a lot of registers to define.  It is quite 
possible that defining YANG for all these registers would be deferred 
until a future phase - do you see any issue with this?


Thanks,
Rob




/Vladimir


Input welcome.  Thanks,
Rob


.



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

Re: [netmod] Modelling different "levels" of data in YANG

[Vladimir Vassilev]

On 12/05/2016 07:10 PM, Robert Wilton wrote:


Hi,

We are currently working on modelling 802.3 Ethernet YANG within the 
802.3 YANG study group.


One interesting issue that has come up is the scope of the operational 
state data that could be modeled:


At the top level, an operator may just want to know whether an 
Ethernet interface is up or down.


At a second level, if the Ethernet interface is down, then there is 
some high level diagnostics information that may be useful to an 
operator to diagnose why the interface isn't up (e.g. alarms 
information, optical power levels, auto-negotiation protocol status).


There is also a third level, of very detailed, 802.3 hardware register 
information defined in 802.3 Clause 45.  Such information is probably 
of most relevance to the engineers developing and programming Ethernet 
chips and PHYs, but is sometimes useful for resolving potential vendor 
inter-operation issues.  Retrieving this information out of the 
Ethernet chips can be comparatively slow.


The question that was being discussed is whether it is appropriate to 
model all three levels on information in the 802.3 Ethernet YANG 
models, or whether only the top level and second level information 
can/should be modeled via YANG?


If we were to model the third level information in YANG then it would 
seem highly desirable for that information to not be returned in 
response to a general NETCONF  request because the information 
is generally not of relevance and has potential performance issues in 
returning it.  Instead, it would seem desirable to only return this 
data if it was specifically requested (e.g. a  request on the 
node containing the third level information), or if a hypothetical 
filter extension was specified and used to explicitly include it in 
the response. Given that there doesn't seem to a great way to 
currently achieve this in YANG, this makes me think that it isn't 
sensible to model this third level of detailed information in YANG at 
this time.  Do others agree?


Have others faced similar issues, and if so, how have you solved them?
How about having this state data reside under a config=true presence 
container e.g. /interfaces/interface/ethernet-detailed-state... . The 
user can then create the container for the interfaces he is interested 
in reading the detailed state data.


Or have dedicated RPC in the model that enables/disables the presence of 
the detailed state information for certain interfaces. Since the state 
container is not mandatory.


In any case a grouping with the 802.3 Clause 45 information data will 
definitely be usefull.


/Vladimir


Input welcome.  Thanks,
Rob


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

[netmod] Modelling different "levels" of data in YANG

[Robert Wilton]

Hi,

We are currently working on modelling 802.3 Ethernet YANG within the 
802.3 YANG study group.


One interesting issue that has come up is the scope of the operational 
state data that could be modeled:


At the top level, an operator may just want to know whether an Ethernet 
interface is up or down.


At a second level, if the Ethernet interface is down, then there is some 
high level diagnostics information that may be useful to an operator to 
diagnose why the interface isn't up (e.g. alarms information, optical 
power levels, auto-negotiation protocol status).


There is also a third level, of very detailed, 802.3 hardware register 
information defined in 802.3 Clause 45.  Such information is probably of 
most relevance to the engineers developing and programming Ethernet 
chips and PHYs, but is sometimes useful for resolving potential vendor 
inter-operation issues.  Retrieving this information out of the Ethernet 
chips can be comparatively slow.


The question that was being discussed is whether it is appropriate to 
model all three levels on information in the 802.3 Ethernet YANG models, 
or whether only the top level and second level information can/should be 
modeled via YANG?


If we were to model the third level information in YANG then it would 
seem highly desirable for that information to not be returned in 
response to a general NETCONF  request because the information is 
generally not of relevance and has potential performance issues in 
returning it.  Instead, it would seem desirable to only return this data 
if it was specifically requested (e.g. a  request on the node 
containing the third level information), or if a hypothetical filter 
extension was specified and used to explicitly include it in the 
response. Given that there doesn't seem to a great way to currently 
achieve this in YANG, this makes me think that it isn't sensible to 
model this third level of detailed information in YANG at this time.  Do 
others agree?


Have others faced similar issues, and if so, how have you solved them?

Input welcome.  Thanks,
Rob


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