Subject: [netmod] Modelling capabilities in YANG

From: Robert Wilton <[email-masked]>
Date: Thu, 17 Dec 2015 23:17:21 +0000

Hi,

For the Ethernet interface model that we are working on, the question 
has come up on how best to model capabilities of a physical item of 
hardware.

In this particular case of Ethernet interfaces there are various 
capabilities that we would like to model, but to give some concrete 
examples:
  - whether a particular Ethernet interface supports auto-negotiation 
configuration
  - what speed values may be configured on a particular interface
  - whether the interface supports half duplex in addition to full duplex
  - what modes of flow control are supported on the interface.

All of these properties may change depending on what hardware is 
currently inserted (e.g. this could be as coarse as a linecard or as 
granular as a pluggable optics module).  I.e. it is not the case that 
the capabilities for all interfaces on a device would be the same, and 
hence YANG features don't appear to help with this scenario.

The current assumption is that we would model these dynamic capabilities 
as operational state leaves.  However, there is a general question as to 
where these leaves should be placed.  Should they be inline in the 
interface config tree, or should there be a separate capabilities 
container to hold them somewhere?

Further, in an ideal world it would be desirable to constrain the 
allowed configuration values to those that are supported by the 
capabilities, although writing such must statements on the config node 
that reference state data  is not allowed.

We can't be the first people to want to model dynamic capabilities, is 
there a best practice on how they should be handled?

Any advice would be gratefully appreciated!

Thanks,
Rob

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 18 Dec 2015 07:37:58 +0100

> container to hold them somewhere?

Inline in the config tree means that config must exist for the
capabilities to be able to exist and I do not think this is the case
here. Hence, this is operational state data that should exist in the
state tree.

> that reference state data  is not allowed.

The RFC 7223 model is that interface configuration is applied to
matching interfaces and there is the possibility that this does not
work out (e.g., interface types or interface properties do not match).
Constraining the config by the (dynamic) interface properties would
imply that configurations may become invalid spontaneously, which is
something YANG does not allow. In other words, there can be a mismatch
between 'intended config' and 'applied config' in such situations.

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