Subject: [netmod] New 6087bis issues

From: Martin Bjorklund <[email-masked]>
Date: Thu, 02 Apr 2015 14:47:00 +0200 (CEST)

Hi,

Here's a list of some things that maybe should be added to 6087bis.
Some of them are stylistic; I don't know if we should add those or
not.

3.6  References

  The RFC Editor prefers the style:

    reference
      "RFC <NNNN>: <title>";

    reference
      "RFC <NNNN>: <very long title that spans
        more than one line>";

  I think we should document this.

4.1

 Update this wrt. example modules.  Should they be marked with CODE at
 all?

5.1.  Module Naming Conventions

  Add: IETF modules SHOULD (MUST?) start with "ietf-".

  Example modules SHOULD start with "example-" or "ex-".

5.2.  Identifiers

  Add: avoid unnecessary prefixes on names.

  BAD:

    list interface {
      ...
      leaf interface-name { ... }
      leaf interface-type { ... }
    }

  GOOD:

    list interface {
      ...
      leaf name { ... }
      leaf type { ... }
    }

  use-hypened-names

5.8  Namespace Assignments

  OLD:

   The following examples of non-Standards-Track modules are only
   suggestions.  There are no guidelines for this type of URN in this
   document:

       http://example.com/ns/example-interfaces

       http://example.com/ns/example-system

  NEW:

   There are no guidelines for non-Standards-Track modules.

   Example modules SHOULD use RFC 6963 style URNs:

    urn:example:<module-name>

   Or 2606-style

    http://example.com/...

/martin

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 2 Apr 2015 15:52:43 +0200

Hello,
As indicated by operators in Dallas and as experienced by Ericsson as 
well, it is sometimes not easy to find the status data for a given bit 
of configuration (interface, route, etc.). Often the state and 
configuration are handled in parallel subtrees with the same structure. 
However this is not part of the guidelines. Also counters are often 
separated from state data again without a clear guideline to connect 
statistics with the config.
I believe 6087 should provide guidelines how to find state and staistics 
information for a give piece of configuration. E.g. how do find the 
number of outgoing packets for an interface?
regards Balazs

On 2015-04-02 14:47, Martin Bjorklund wrote:
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>
>

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
ECN: 831 7320
Mobile: +36-70-330-7909              email: [email-masked]

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 2 Apr 2015 16:29:06 +0200

> number of outgoing packets for an interface?

It is hard to believe this is a problem without knowing that data
models for which this is a problem. Since you mention interfaces, I am
even more confused what the problem is. RFC 7223 has a rather clear
structure - is it really difficult to find the proper counter there?

/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: Thu, 2 Apr 2015 07:49:36 -0700

Hi,

You need to read the description-stmts of the relevant data nodes
to find out where other related data nodes can be found.
IMO the sibling config/state approach should only
be used if the state can exist without the config.

If I have an ACL or some filter that may be nested within lists
with lots of keys, then it is extremely wasteful to replicate
all the scaffolding and keys, just to store a couple counters
for that ACL.  It is much better to just put the counters in the ACL
entry.

But many times the set of interesting objects related to some
config is far more complicated than that, so the description-stmt
is the only place to document this information.

Andy

On Thu, Apr 2, 2015 at 6:52 AM, Balazs Lengyel
<[email-masked]> wrote:
> Hello,
> As indicated by operators in Dallas and as experienced by Ericsson as well,
> it is sometimes not easy to find the status data for a given bit of
> configuration (interface, route, etc.). Often the state and configuration
> are handled in parallel subtrees with the same structure. However this is
> not part of the guidelines. Also counters are often separated from state
> data again without a clear guideline to connect statistics with the config.
> information for a give piece of configuration. E.g. how do find the number
> of outgoing packets for an interface?
> regards Balazs
>

---

From: Anees Shaikh <[email-masked]>
Date: Thu, 2 Apr 2015 10:41:04 -0700

We've laid out why this is a problem (even for existing RFC models) in
draft-openconfig-netmod-opstate-00
and summarized during the presentation in Dallas.  The problem is
exacerbated when trying to compose multiple models into a coherent whole --
clearly it's not possible to manage a service or device with an interfaces
model alone.

Reading the description statements to learn where different types of data
is stored is not a solution IMO -- we need to think how this will be use
programmatically by users.  And we made the deliberate tradeoff to
introduce some extra work in building a consistent model for the benefit of
a simple programming construct to set and retrieve the data.

thanks.
-- Anees

On Thu, Apr 2, 2015 at 7:49 AM, Andy Bierman <[email-masked]> wrote:

> well,

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 2 Apr 2015 19:48:53 +0200

Hi,

if you mean section 2.5, then I am not yet convinced I understand the
severity of the problem. Does the interface model present a problem?
If so, why? If not, what are the IETF models that demonstrate the
problem? The second paragraph seems to be talking about multiple
devices that implement different data models. Well, that problem we
can't solve other than standardizing viable models and pushing vendors
to implement them. Or am I reading the wrong section?

/js

---

From: Andy Bierman <[email-masked]>
Date: Thu, 2 Apr 2015 10:49:18 -0700

On Thu, Apr 2, 2015 at 10:41 AM, Anees Shaikh <[email-masked]> wrote:
> draft-openconfig-netmod-opstate-00 and summarized during the presentation in
> Dallas.  The problem is exacerbated when trying to compose multiple models
> into a coherent whole -- clearly it's not possible to manage a service or
> device with an interfaces model alone.
>
> Reading the description statements to learn where different types of data is
> stored is not a solution IMO -- we need to think how this will be use
> programmatically by users.  And we made the deliberate tradeoff to introduce
> some extra work in building a consistent model for the benefit of a simple
> programming construct to set and retrieve the data.
>

I disagree.
Many times the relationship between a config knob setting
and operational state is not simple.  There may be all kinds of
overlap and dynamic conditions that change the set of
interesting objects at the moment.  Forcing a certain structure
between config and operational nodes will not work as a general solution.
You should develop some YANG extensions if you think the
problem can be solved without description-stmts.

Andy