Subject: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-02.txt

From: [email-masked]
Date: Mon, 04 Jan 2016 14:17:00 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF.

        Title           : Terminology and Requirements for Enhanced Operational State Visibility and Control
        Authors         : Kent Watsen
                          Thomas Nadeau
	Filename        : draft-ietf-netmod-opstate-reqs-02.txt
	Pages           : 6
	Date            : 2016-01-04

Abstract:
   This document discusses the difference between intended configuration
   and applied configuration of a device and how intended and applied
   configuration relate to the operational state of a device.  The
   document defines the necessary terminology and identifies
   requirements enabling visibility into the difference of intended
   configuration and applied configuration.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-opstate-reqs/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-netmod-opstate-reqs-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-opstate-reqs-02

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Kent Watsen <[email-masked]>
Date: Mon, 4 Jan 2016 22:29:54 +0000

This update addresses comments received during the Last Call.

Warning!  - the Diff1 and Diff2 outputs somehow mangle the Applied Configuration term.  Please look at the draft itself for the correct text.

Kent

On 1/4/16, 5:17 PM, "netmod on behalf of [email-masked]" <[email-masked] on behalf of [email-masked]> wrote:

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

---

From: Kent Watsen <[email-masked]>
Date: Tue, 5 Jan 2016 18:08:44 +0000

There are a few editorial issues (see below) that I’d like to fix before Benoit gets back (tomorrow, I think).  Please let me know if you spot any other issues like these, today if possible.

Thanks,
Kent

- ensure that this inconsistency minimizes gaps in the application of

+ ensure that this process minimizes gaps in the application of
                   ^^^^^^^

- policies or not dependent on external input that an attacker might

+ policies are not dependent on external input that an attacker might
           ^^^

- Sterne, Jason
+ Jason Sterne

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 5 Jan 2016 21:02:14 +0100

> This update addresses comments received during the Last Call.

I not entirely happy with the new title:

               Terminology and Requirements for Enhanced
                Operational State Visibility and Control

Since the key contribution is the concept of intended configuration
and applied configuration, why not put these terms into the title
instead of "Enhanced Operational State Visibility and Control", which
is somewhat vague? What about this proposal:

	   Terminology and Requirements for Distinguishing
		  Intended and Applied Configuration

/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: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 5 Jan 2016 20:08:29 +0000

Juergen, 

As another non-author, I disagree with this characterization of the draft.
The intended/applied configuration is an important requirement but
certainly not the only one precisely articulated in the draft.

Acee 

On 1/5/16, 3:02 PM, "netmod on behalf of Juergen Schoenwaelder"
<[email-masked] on behalf of

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 6 Jan 2016 07:30:14 +0100

Acee,

for me the document is centered around the notion of intended /
applied config:

#1 is clearly about intended/applied cfg

#2 is about intended/applied cfg (since sync config operations is
   largely defined using intended/applied cfg)

#3 is about the relationship of applied config and derived state

#4 is about the relationship of intended / applied config and
   operational state

I find "Enhanced Operational State Visibility and Control" abstract
and somewhat confusing (what is visibility? what is control?).

/js

---

From: Kent Watsen <[email-masked]>
Date: Wed, 6 Jan 2016 18:18:46 +0000

It’s true that the draft is largely centered around the intended/applied config notion, but not exclusively.  Specifically, 4-B has "Ability to map intended config nodes to associated derived state nodes".  I think that this might be the only exclusion though and, if it weren’t for it I would’ve used your title suggestion from the LC review.   Should one requirement have such influence over the title is the question.  I was trying to be fair to it, but maybe it's going too far.

Regarding visibility and control, I was attempting to use common words (not normative terms) here.  My intent for them is something along the lines of:

	visibility: read/understand
	control: write/orchestrate

Thanks,

Kent

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 7 Jan 2016 17:05:21 +0100

> 	control: write/orchestrate

We do not write operational state. I have no clue how 'orchestrate'
helps me either. What is wrong with using defined terminology in
a title?

/js

---

From: Robert Wilton <[email-masked]>
Date: Thu, 7 Jan 2016 17:24:45 +0000

Hi Juergen,

> helps me either. What is wrong with using defined terminology in
I don't think that using defined terminology is a problem.  But I also 
think that the title that you have suggested seems to suggest a narrower 
scope that what the requirements articulate.

In particular, the draft places requirements relating the configuration 
to the derived state (I.e. Req 4B).

It also places further requirements on how management protocols are 
expected to handle synchronous and asynchronous config edit requests. 
(E.g. Req 2 A, B, C and associated definitions).

I don't have a particular problem with the current title, but if you 
don't like visibility/control, then perhaps "Terminology and 
Requirements for Enhanced Handling of Operational State"?

Thanks,
Rob

---

From: Kent Watsen <[email-masked]>
Date: Thu, 7 Jan 2016 20:24:58 +0000

>Requirements for Enhanced Handling of Operational State"?

This looks good to me.  If no objections are raised by tomorrow, I’ll post -03 using this title.

Kent

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 8 Jan 2016 09:37:00 +0100

On Thu, Jan 07, 2016 at 05:24:45PM +0000, Robert Wilton wrote:
> >>It’s true that the draft is largely centered around the 
> >>intended/applied config notion, but not exclusively.  Specifically, 4-B 
> >>has "Ability to map intended config nodes to associated derived state 
> >>nodes".  I think that this might be the only exclusion though and, if it 
> >>weren’t for it I would’ve used your title suggestion from the LC 
> >>review.   Should one requirement have such influence over the title is 
> >>the question.  I was trying to be fair to it, but maybe it's going too 
> >>far.
> >>
> >>Regarding visibility and control, I was attempting to use common words 
> >>(not normative terms) here.  My intent for them is something along the 
> >>lines of:
> >>

Note that synchronous and asynchronous are defined in terms of
intended / applied configuration.
 
> Requirements for Enhanced Handling of Operational State"?

Better but I still think this proposal is too broad given the content
of the document. I still believe my proposal is right to the point.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 08 Jan 2016 13:47:26 +0100

> of the document. I still believe my proposal is right to the point.

+1

The draft talks about introducing applied configuration and its
relationship to state data and intended configuration (which, I believe,
is the good old "running"). I don't see any enhanced handling of
operational state.

Lada

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

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 08 Jan 2016 13:53:11 +0100 (CET)

> is the good old "running"). I don't see any enhanced handling of

Well, the applied config is part of the operational state, and there
are requirements for retrieval of the operational state.  So it is
related.   I think the current title is fine.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 8 Jan 2016 14:06:06 +0100

> On 08 Jan 2016, at 13:53, Martin Bjorklund <[email-masked]> wrote:
> 

According to 6020bis, state data are tagged with "config false" in YANG modules. I don't think it is going to be the case of applied configuration.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 08 Jan 2016 14:17:42 +0100 (CET)

Ladislav Lhotka <[email-masked]> wrote:
> According to 6020bis, state data are tagged with "config false" in
> YANG modules. I don't think it is going to be the case of applied
> configuration.

Right; but this term "state data" is more like the new term "derived
state" (which I think is a bit unfortunate - derived from what?)

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 8 Jan 2016 14:28:16 +0100

> On 08 Jan 2016, at 14:17, Martin Bjorklund <[email-masked]> wrote:
> 

For me, operational state exists independently of management interfaces, applied configuration doesn't - it is an artefact.

Lada

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 8 Jan 2016 13:46:44 +0000

>is the good old "running"). I don't see any enhanced handling of

The draft is quite succinct and I’m not sure how you and Juergen do not
agree that there are requirements beyond intended/applied state. Perhaps
you do not agree with them? Refer to requirements 3.(B & C) and 4.(B & C).
For your convenience, I’ve excerpted them below:

   3.  Separation of the applied configuration and derived state aspects
       of operational state; ability to retrieve them independently and
       together

       A.  Be able to retrieve only the applied configuration aspects of
           operational state

       B.  Be able to retrieve only the derived state aspects of
           operational state

       C.  Be able to retrieve both the applied configuration and
           derived state aspects of operational state together

   4.  Ability to relate configuration with its corresponding
       operational state

       A.  Ability to map intended config nodes to corresponding applied
           config nodes

       B.  Ability to map intended config nodes to associated derived
           state nodes

       C.  The mappings needs to be programmatically consumable

Thanks,
Acee

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 8 Jan 2016 15:26:25 +0100

> On 08 Jan 2016, at 14:46, Acee Lindem (acee) <[email-masked]> wrote:
> 
> 
> 

Well, opstate-reqs defines applied configuration and *proclaims* it to be a part of operational state, whereas it is a new artefact that has to do with how the server processes configuration.

With two exceptions commented on below, the requirements really are directly related to the introduction of applied configuration.

In other words: for those who don't want to use applied configuration, there is very little benefit in terms of enhanced handling of operational state.
 
>       B.  Be able to retrieve only the derived state aspects of

Yes, the inability to retrieve state data separately is a known shortcoming of NETCONF, and Andy proposed a solution long ago. RESTCONF has this function out of the box.

>       B.  Ability to map intended config nodes to associated derived

This might be useful but I think it will only have a limited value because it can't capture all possible semantics of such associations. For example, we can indicate in the data model that static routes are associated with RIBs, but it won't be possible to specify how (formally). 

Lada

---

From: Kent Watsen <[email-masked]>
Date: Sat, 9 Jan 2016 00:33:02 +0000

[As a contributor]

As I count it, there are four in favor and two not in favor of the title proposed by Robert, so I’m going to post -03 with that one.

Kent

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 10 Jan 2016 12:21:22 +0100

>        B.  Be able to retrieve only the derived state aspects of

This is nothing new. See for example section 4.3.3.2 of RFC 6244.

>            derived state aspects of operational state together

Did you notice that 3.C talks about 'applied configuration'?
 
>        C.  The mappings needs to be programmatically consumable

I do not agree that 4.B and 4.C require to broaden the title.

In fact, I wonder why 4.B is useful. If we agree that the applied
config (an extended subset of the intended config) is the configration
that determines what the device is doing, then we likely should have a
mapping of the applied config to associated derived state.

/js

---

From: Robert Wilton <[email-masked]>
Date: Mon, 11 Jan 2016 11:02:30 +0000

> mapping of the applied config to associated derived state.
Yes, in essence the relationship is intended config => applied config => 
derived state.  So I would say that derived state has a transitive 
association with the intended config.

Personally, I think that the relationship should be expressed in the 
reverse direction.  I.e. a particular node of derived state should be 
allowed to refer back to the config (intended/applied) that is derived 
from.  This is presumably an implementation detail rather than a 
requirement.

However, I'm not sure that we actually need to change the text, I think 
that the requirement text is probably sufficiently clear to compare 
solutions.

Thanks,
Rob

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 11 Jan 2016 12:26:30 +0100

> association with the intended config.

Yes. But applied config might include something that is not intended
config, which would be lost if we map intended config => derived state.
 
> from.  This is presumably an implementation detail rather than a 

Yes, I wrote about this earlier - some several weeks ago. What is
really helpful for a managing system is to know the source of derived
state, be it applied config, be it a routing protocol daemon, be it a
dhcp server, be it a piece of tunneling software, be it an I2RS
agent. So yes, I agree with you that the reverse direction is
desirable (e.g., have meta data for derived state that explains where
the state if originating from). What I also explained back then is
that a standard Linux kernel does not track this context for many
resources, which makes this somewhat difficult (= expensive) to
implement. But yes, from a management point perspective, knowing the
source of derived state is truly helpful in my experience.

> that the requirement text is probably sufficiently clear to compare 

Perhaps. I just wanted to point out in my email that even 4.B involves
applied config if done right and hence the document really is grounded
on the distinction of applied config and intended config.

/js

---

From: Robert Wilton <[email-masked]>
Date: Fri, 15 Jan 2016 17:01:54 +0000

Hi Juergen,

> config, which would be lost if we map intended config => derived state.
I basically agree.  I also wonder whether it wouldn't be better to use 
the term "relate/relationships" instead of map/mappings because the way 
the text is written at the moment it implies that the binds only need to 
go from config to state, but as I think the relationship is really 
bijective.

This would be rewording this requirement text from:

to:

        A.  Ability to relate intended config nodes with corresponding applied
            config nodes

        B.  Ability to relate applied config nodes with associated derived
            state nodes

        C.  The relationships needs to be programmatically consumable

Are there any other views on whether this requirement text should be 
updated?

> source of derived state is truly helpful in my experience.

There seem to be two separate angles to this:

(1) Allowing the schema to express the relationship between derived 
state and config nodes.  This effectively allows the operator to know 
that if they change a particular config item, which derived state fields 
they may want to check to ensure that the config change has been enacted 
correctly.  My understanding is that this is what the requirements in 
section 4 of the requirements draft are addressing.

(2) Optional meta-data annotations to the derived state that indicates 
for a specific node in the data tree what is/are the sources for that 
nodes existence/value.  I agree that this does seem useful, but my hunch 
is that very few systems would be able to track or provide this 
information today.  My naive impression is that this would be more 
difficult for system vendors to implement than the applied configuration 
nodes.

Thanks,
Rob

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 15 Jan 2016 18:39:46 +0100

On Fri, Jan 15, 2016 at 05:01:54PM +0000, Robert Wilton wrote:

[...]
 
> Are there any other views on whether this requirement text should be 

I think the new wording is an improvement.

> section 4 of the requirements draft are addressing.

This direction of the relationship might in some cases be a relatively
trivial and predictable 1:1 relationship, in other cases it may be
more complex and in the worst case dynamically changing.

> difficult for system vendors to implement than the applied configuration 

If you can do 'applied config' -> 'associated derived state' then you
should be able to do 'derived state' -> 'applied config' for 'derived
state' associated with 'applied config'.

But yes, I agree that 'derived state' -> 'arbitrary source of derived
state' is unfortunately unrealistic (in the general case).

BTW, do we have a definition of 'associated derived state'? What is
the scope of the _associated_ derived state? My interpretation is that
it is any derived state that is a _direct_ consequence of some applied
config being active but it does not include any state indirectly
associated with some applied config. (For example, if I turn on a VPN
service, then the associated derived state are VPN service counters
etc. but not lets say interfaces dynamically created via the VPN
service operation.)

/js

---

From: Kent Watsen <[email-masked]>
Date: Fri, 15 Jan 2016 23:15:47 +0000

>I think the new wording is an improvement.

I agree and view this as an editorial fix.

>more complex and in the worst case dynamically changing.

It YANG module could support 1:N by having a list of associated derived state relationships.  I don’t get the dynamically changing part, are you saying the derived state can randomly appear anywhere?

>state' associated with 'applied config'.

I made this point before as well.   Given the forward mapping, a system could calculate the reverse mapping...

>etc. but not lets say interfaces dynamically created via the VPN

I think your interpretation is acceptable, but do we need to define a term other than “derived state”?

   Derived State:  This data represents information which is generated
       as part of the server's own interactions.  For example, derived
       state may consist of the results of protocol interactions (the
       negotiated duplex state of an Ethernet link), statistics (such as
       message queue depth), or counters (such as packet input or output
       bytes).

Separately, the term “derived state” seems poorly named.  I know that it is what the OpenConfig draft called it, but it begs the question as to what the state is derived from.  Thoughts on a better name?

Thanks,
Kent

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 16 Jan 2016 11:39:56 +0100

> It YANG module could support 1:N by having a list of associated derived state relationships.  I don’t get the dynamically changing part, are you saying the derived state can randomly appear anywher…

It all boils down to the definition of 'associated derived state'...

> Separately, the term “derived state” seems poorly named.  I know that it is what the OpenConfig draft called it, but it begs the question as to what the state is derived from.  Thoughts on a better…

The way I personally think about the various things and terms right
now is roughly as follows (warning ascii art):

     +-----------------+
     | intended config |
     +--------v--------+
              |
  +-----------|-----------------------------------------------+
  |           | (1)                         operational state |
  |           v                                               |
  |  +-------------------------------------------+            |
  |  | applied config (static operational state) |            |
  |  +---------------v---------------------------+            |
  |                  |                                        |
  |  +---------------|------------------------------------+   |
  |  |               | (2)      dynamic operational state |   |
  |  |               v                                    |   |
  |  |  - directly derived from applied config            |   |
  |  |                                                    |   |
  |  |  - provided by the system (system controlled)      |   |
  |  |                                                    |   |
  |  |  - obtained internally from system operation       |   |
  |  |                                                    |   |
  |  |  - obtained from interactions with other systems   |   |
  |  |                                                    |   |
  |  +----------------------------------------------------+   |
  +-----------------------------------------------------------+

It is difficult to find good and crisp terms for all of these little
different elements of dynamic operational state.

I think the scope of requirement 4.B should be limited to (2) in the
figure above.  For me, it does not make sense to tag stuff only
indirectly related to a config object as derived from it since this
would quickly get huge and then start to defeat its purpose.

Conerning requirement 4, I would be very happy if I could get metadata
telling me

- this dynamic operational state has been directly derived from
  that part of applied config (e.g, this state interface exists
  because it was configured over there)

- this dynamic operational state has been provided by the system and
  is system controlled (e.g., an interface not yet configured put
  part of the system's hardware)

- this dynamic operational state has been obtained by system operation
  (e.g., interface counters, certain interface parameters discovered
  via auto-negotiation via cable or signal properties)

- this dynamic operational state has been obtained from protocol
  interactions with other systems (e.g., IP addresses obtained via
  SLAAC or DHCP, interfaces created from a VPN service, ...), ideally
  with an indication which mechanism was used

There are still borderline cases where the above classification may be
debatable (and this is likely unavoidable). The guiding principle I
would use to take a decision is the question: "What is directly
responsible for the dynamic operational state to exist?"

/js

---

From: Robert Wilton <[email-masked]>
Date: Mon, 18 Jan 2016 09:47:31 +0000

>> Separately, the term “derived state” seems poorly named.  I know that it is what the OpenConfig draft called it, but it begs the question as to what the state is derived from.  Thoughts on a bette…
I think that it is meant to be state derived from particular 
configuration nodes.

> now is roughly as follows (warning ascii art):
I broadly agree with your diagram.  I don't think that applied config is 
truly static through, it could still change if say a linecard was pulled 
out (or failed).

> would quickly get huge and then start to defeat its purpose.

Yes, I think that this is probably right.

> responsible for the dynamic operational state to exist?"

As I understand it, what you are proposing here is not what the section 
4 requirements were intended to express.

The section 4 requirements are meant to be at the YANG schema level, 
i.e. illustrating possible relationships between YANG schema nodes. E.g. 
for a particular interface IP address they wouldn't be able to indicate 
whether it was actually configured by explicit IP address configuration 
or due to DHCP.  They would only be able to tell which configurations 
nodes could influence a particular derived state node.

I think that there are a couple of cases where this relationship is useful:
(1) If you modify a config node, it allows the client to know (in 
advance) which derived state nodes may be affected and hence should be 
retrieved to confirm the change.
(2) Conversely, if a derived state note has an unexpected value, it 
allows a client to know which configuration nodes it should retrieve to 
try and infer what the cause of the value is.

If I understand your proposal, then what you are proposing is meta-data 
annotations of the derived state nodes in the data tree. I.e. the 
annotations would allow you to tell you whether a particular interface 
IP address had that value due to explicit IP address configuration or 
because it was allocated by DHCP.  I agree that this is useful, but I 
think that it is very hard to implement (on the systems that I'm 
familiar with) and is also beyond the requirement as originally stated 
by the opstate requirements draft.

As such, I think that we should restrict the scope of the requirements 
draft (and proposed solutions) to YANG schema level annotations that are 
easier to solve.  If you agree, then do we need to tweak the text of 
requirement 4 to make this explicit?

Rob

---

From: Gert Grammel <[email-masked]>
Date: Mon, 18 Jan 2016 11:32:16 +0000

On 2016-18-01 10:47, "netmod on behalf of Robert Wilton"
<[email-masked] on behalf of [email-masked]> wrote:

>>> It YANG module could support 1:N by having a list of associated
>>>derived state relationships.  I don¹t get the dynamically changing
>>>part, are you saying the derived state can randomly appear anywhere?
>>>
>>> I think your interpretation is acceptable, but do we need to define a
>>>term other than ³derived state²?
>>>
>>> Separately, the term ³derived state² seems poorly named.  I know that
>>>it is what the OpenConfig draft called it, but it begs the question as
>>>to what the state is derived from.  Thoughts on a better name?
To me the term Œderived state¹ looks good enough as it makes it clear that
the state is captured (derived) from a set of sources where applied config
is only one of them. If it comes to ¹associated derived state¹ the example
above could provide clarity to the reader. Tagging from where state is
derived appears a bit impractical to me, as there are often many sources
and even sequences determining dynamic state.

>truly static through, it could still change if say a linecard was pulled
To me the diagram looks good. As discussed in other emails, an exchange of
HW would have to be reflected in applied config, as it describes the
static state of the server and HW is certainly Œapplied¹.

+1
>requirement 4 to make this explicit?
I have doubts on both options discussed.
What Juergen proposes appears to be useful for debugging purposes. Today
that state change information is usually found in log files. It¹s
certainly not a perfect implementation given the zillion of entries and
accelerated wrapping of ring buffers, but something is there. That said,
it appears to me that pulling it into the YANG schema will burden the
implementation, certainly the performance of operations quite a bit. I
would be inclined to accept such a proposal as an optional extension, but
not so much as a requirement. (and agree with Rob that it is not so easy
to implement).

On the other hand, trying to identify derived state that is *possibly*
affected by a config appears to me a quite ambitious.
1) If for example a line card is supposed to be put into a state Œdown¹,
there is probably a ton of derived state to be affected. What would a
client do with all that data other than concluding it is traffic affecting?
2) The second issue is the completeness of that information. Depending on
other state information, state change of e.g. a HW item on a server may
either bring the whole server down, or just parts of it. Always indicating
the worst case would probably render lots of actions "potentially
catastrophic² and the amount of data to link to operational state will
grow quite big. It doesn¹t appear to me that a client can do a lot to
digest this data other than picking few parameters and trying to monitor
them. Whether this is an adequate method to monitor the progress of a
complex state change is anyones guess.
3) When limiting relationship information to what usually is affected, it
would require some very educated guess, by whoever implements the schema
over what a client may see as important. Over time, everyone wants to be
on the safe side and we'll end up in 2)

On that ground I would prefer stay with requirement 4 as it is now,
without narrowing down a certain solution.

---

From: Robert Wilton <[email-masked]>
Date: Mon, 18 Jan 2016 13:56:19 +0000

> without narrowing down a certain solution.
I'm not trying to propose solutions here, only the requirements, and I'm 
not trying to narrow or broaden the scope of the requirements at all.

I'm just trying to ensure that the understanding of requirement 4 
accurately reflects the operators actual requirement.  My understanding 
is that their requirements only concern relating nodes in the YANG 
schema, not relating data nodes in the YANG datastore.

Given that this doesn't appear to be clear to all, then it might be a 
good idea for the requirement text to be clarified to make this point 
explicit to avoid any confusion:

I.e. old:

        A.  Ability to relate intended config nodes with corresponding
        applied config nodes

Proposed new:

        A.  Ability to relate intended config nodes with corresponding
        applied config nodes in the YANG schema.

        B.  Ability to relate applied config nodes with associated derived
            state nodes in the YANG schema.

Rob

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 26 Jan 2016 13:32:51 +0100

> nodes could influence a particular derived state node.

I am confused and I may not understand your example. My point is that
an operationally used IP address can be there for a variety of reasons
and the reasons depend on runtime state not on schema structure.

> by the opstate requirements draft.

I agree its hard to implement in general but I am not sure why the
other proposal would be any simpler to implement. Your instrumentation
is either able to keep track of 'why something has a certain value' or
it is not.

> requirement 4 to make this explicit?

But this approach requires to partition things artificially. For
example, I can't have a simple list of IP addresses used by the
interface anymore but instead I need to have a list of IP address
coming from static config, a list of IP addresses coming from DHCP, a
list of IP addresses coming from SLAAC and so on. I seriously can't
imagine that debugging network configurations becomes simpler if we
spread around the information one needs to look at in several branches
of the data model. [I hope I completely misunderstand requirement 4.]

/js

---

From: Robert Wilton <[email-masked]>
Date: Tue, 26 Jan 2016 14:19:00 +0000

Hi Juergen,

Hopefully my explanations below help clarify.

> and the reasons depend on runtime state not on schema structure.
Yes, exactly.

But this requirements draft is based on the improvements that the 
operators would like to see to YANG/NETCONF/etc to make it easier for 
them to use/deploy.

For this section 4 requirements, my understanding is that they are not 
asking to know why a particular operation node has a particular value, 
they are only asking for an indication of which configuration leaves 
could influence its value.  Solving the latter is easier and can be 
implemented at the schema level.

To support my interpretation I recall that Rob Shakir, at the first 
Netmod WG meeting IETF 94, indicated that their proposed opstate 
solution draft (e.g. draft-openconfig-netmod-opstate-01) met all the 
opstate requirements.  Their draft doesn't have any mechanism to 
indicate why a particular state leaf has a particular value, but it does 
provide a schema level relationship between the configuration and 
operation state nodes - i.e. the co-located config and state containers 
that they consistently use throughout the OpenConfig schema.

> is either able to keep track of 'why something has a certain value' or
I'm saying that there is no requirement (at least from the opstate 
draft) to generally track "why something has a certain value" at all.

> of the data model. [I hope I completely misunderstand requirement 4.]

I don't think that they are asking/suggesting separate lists of 
operational IP addresses.

Taking the OpenConfig IP YANG model as an example 
(https://github.com/openconfig/public/blob/master/release/models/interfaces/openconfig-if-ip.yang):

They have a list of IP addresses.  Each entry contains:
  - the configured IP address (if any),
  - the operational IP address,
  - an enum indicating the source of the operational IP address value 
(static, dhcp, link_layer, random or other).

Their schema doesn't completely follow the opstate draft requirements.  
In particular, they should have separate leaves for the applied 
configuration value vs the operational state value.  I presume that this 
will be fixed at some point.

In summary, I think that knowing the source of a piece of operational 
data is valuable in some circumstances (e.g. IP addresses), but probably 
isn't actually required for most operational values, and at least from 
an opstate perspective isn't a general requirement that needs to be 
solved with a generic solution.

Rob

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 26 Jan 2016 15:33:25 +0100 (CET)

Robert Wilton <[email-masked]> wrote:
> indicate why a particular state leaf has a particular value, but it
> does provide a schema level relationship between the configuration and
> operation state nodes - i.e. the co-located config and state
> containers that they consistently use throughout the OpenConfig
> schema.
> 
> >
>  - (static, dhcp, link_layer, random or other).

I assume you refer to this list:

      list address {
        key ip;
        description
         "The list of configured IPv4 addresses on the interface.";

        leaf ip {
          type leafref {
            path "../ocip:config/ocip:ip";
          }
          description "References the configured IP address";
        }

        container config {
          description "Configuration data for each configured IPv4
          address on the interface";

          uses ipv4-config-address;
        }

        container state {

          config false;
          description "Operational state data for each IPv4 address
          configured on the interface";

          uses ipv4-config-address;
          uses ipv4-state-address;
        }

      }

Note how the key contains the "configured IP address" (and it is a
config true list).   So this list cannot contain addresses that are
not configured.

/martin

> configuration value vs the operational state value.  I presume that
> this will be fixed at some point.
> 
> data is valuable in some circumstances (e.g. IP addresses), but
> probably isn't actually required for most operational values, and at
> least from an opstate perspective isn't a general requirement that
> needs to be solved with a generic solution.
> 
> Rob
> 
> 
> >
> > /js
> >
>

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 26 Jan 2016 15:50:43 +0100

> On 26 Jan 2016, at 15:19, Robert Wilton <[email-masked]> wrote:
> 
> Hi Juergen,
> 
> But this requirements draft is based on the improvements that the operators would like to see to YANG/NETCONF/etc to make it easier for them to use/deploy.
> 
> For this section 4 requirements, my understanding is that they are not asking to know why a particular operation node has a particular value, they are only asking for an indication of which configuration leaves could influence its value.  Solving the latter is easier and can be implemented at the schema level.
> 
> To support my interpretation I recall that Rob Shakir, at the first Netmod WG meeting IETF 94, indicated that their proposed opstate solution draft (e.g. draft-openconfig-netmod-opstate-01) met all the opstate requirements.  Their draft doesn't have any mechanism to indicate why a particular state leaf has a particular value, but it does provide a schema level relationship between the configuration and operation state nodes - i.e. the co-located config and state containers that they consistently use throughout the OpenConfig schema.

This can IMO work only if the schemas of configuration and state data are identical or very similar. As an example, take RIBs (state data) and a list of static routes (configuration). There is a certain relationship between them, but the exact outcome depends on a number of other factors. I don't see how they can be co-located, or how the relationship can otherwise be formally expressed.

Lada

> I'm saying that there is no requirement (at least from the opstate draft) to generally track "why something has a certain value" at all.
> 
> 
>> 
> I don't think that they are asking/suggesting separate lists of operational IP addresses.
> 
> Taking the OpenConfig IP YANG model as an example (https://github.com/openconfig/public/blob/master/release/models/interfaces/openconfig-if-ip.yang):
> 
> - an enum indicating the source of the operational IP address value (static, dhcp, link_layer, random or other).
> 
> Their schema doesn't completely follow the opstate draft requirements.  In particular, they should have separate leaves for the applied configuration value vs the operational state value.  I presume that this will be fixed at some point.
> 
> In summary, I think that knowing the source of a piece of operational data is valuable in some circumstances (e.g. IP addresses), but probably isn't actually required for most operational values, and at least from an opstate perspective isn't a general requirement that needs to be solved with a generic solution.
> 
> Rob
> 
> 
>> 
>> /js
>> 
>

---

From: Robert Wilton <[email-masked]>
Date: Tue, 26 Jan 2016 14:52:31 +0000

Hi Martin,

> I assume you refer to this list:
Yes.

> config true list).   So this list cannot contain addresses that are
OK, yes.  I had missed that.

I presume that they would ideally like this list to contain all IP 
addresses on an interface whether configured or operational. Otherwise 
if it contains just the list of configured addresses then the "origin" 
leaf in the ipv4-state-address grouping seems pretty pointless since the 
only sane value that it could hold is STATIC :-)

I suspect that this issue ties back to sections 8.1.2 and 9.2 of 
https://www.ietf.org/archive/id/draft-openconfig-netmod-opstate-01.txt 
(text reproduced below) where they would like the YANG schema to have a 
combined list of configured and state entries.

8.1.2.  Handling lists

    In YANG 1.0, lists have requirements that complicate the creation of
    the parallel configuration and state data structures.  First, keys
    must be children of the list; they cannot be further down the data
    hierarchy within a subsequent container.  For example, the
    'interface' list cannot be keyed by /interfaces/interface/config/
    name.  Second, YANG requires that the list key is part of the
    configuration or state data in each list member.

    We consider two possible approaches for lists:

    1.  list keys appear only at the top level of the list, i.e., not
        duplicated under the 'config' or 'state' containers within the
        list

    2.  the data represented by the list key appears in the config and
        state containers, and a key with type leafref is used in the top
        level of the list pointing to the corresponding data node in the
        config (or state) container.

    Option 1 has the advantage of not duplicating data, but treats the
    data item (or items) that are keys as special cases, i.e., not
    included in the config or state containers.  Option 2 is appealing in
    that configurable data always appears in the config container, but
    requires an arguably unnecessary key pointing to the data from the
    top level of the list.

    Appendix C shows a simple example of both options.

9.2.  YANG lists as maps

    YANG has two list constructs, the 'leaf-list' which is similar to a
    list of scalars (arrays) in other programming languages, and the
    'list' which allows a keyed list of complex structures, where the key
    is also part of the data values.  As described in Section 8.1.2, the
    current requirements on YANG list keys require either duplication of
    data, or treating some data (i.e., those that comprise list keys) as
    a special case.  One solution is to generalize lists to be more like
    map data structures found in most modern programming languages, where
    each list member has a key that is not required to part of the
    configuration or state data, and also not subject to existing
    "config-under-state limitations.  This allows list keys to be
    arbitrarily defined by the user if desired, or based on values of
    data nodes.  In the latter case, the specification of which data
    nodes are used in constructing the list key could be indicated in the
    meta-data associated with the key.

Rob

> .

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 26 Jan 2016 16:14:20 +0100

> (static, dhcp, link_layer, random or other).

But this ip-address-origin thing is exactly what I have been talking
about.  Now I am even more confused.
 
> solved with a generic solution.

See ip-address-origin.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 26 Jan 2016 16:21:11 +0100

> > solved with a generic solution.

Frankly, you either list all IP addresses of an interface in one place
and then you need additional information to indicate where they are
coming from (e.g., which config tweaks them) or you distribute the all
IP addresses of an interface into multiple places of the schema (which
I doubt operational people really want).

To track the origin, you can create ip-address-origin, ip-route-origin,
ip-foo-origin objects and stick them at appropriate places or you make
this metadata which you do not have to define everywhere.

This is my rather simple view of the world.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 26 Jan 2016 16:27:20 +0100 (CET)

Robert Wilton <[email-masked]> wrote:
> leaf in the ipv4-state-address grouping seems pretty pointless since
> the only sane value that it could hold is STATIC :-)

Exactly.  This is the core of the problem with their models, imo.

> (text reproduced below) where they would like the YANG schema to have
> a combined list of configured and state entries.

Like SNMP tables...

>        config (or state) container.

This doesn't solve the problem; it just creates a more complex model.

>    meta-data associated with the key.

I don't understand how this would solve the problem either, but in any
case, I don't think this idea has been presented in greater detail, so
I am not sure how it would actually work.

/martin

---

From: Robert Wilton <[email-masked]>
Date: Tue, 26 Jan 2016 15:36:17 +0000

> This is my rather simple view of the world.
I'm not disagreeing with any of this other than to point out that the 
opstate requirements drafts (either draft-ietf-netmod-opstate-reqs-04 or 
draft-openconfig-netmod-opstate-01 that it was based on) are not asking 
for a solution to this specific problem.  They are asking for a solution 
to relate the configuration and operational state nodes in the YANG schema.

Specifying a common way to track these "origin" objects using meta-data 
may well be worthwhile, but I think that it would be better achieved 
outside the discussions related to the opstate requirements/solutions.

Rob

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 26 Jan 2016 16:45:20 +0100

> outside the discussions related to the opstate requirements/solutions.

All fine. I am just still confused what "relate the configuration and
operational state nodes in the YANG schema" actually means. Does it
mean that an IP address coming via DHCP should be reported next to the
DHCP config? I guess not. So I am left puzzled.

/js

---

From: Kent Watsen <[email-masked]>
Date: Tue, 26 Jan 2016 18:42:49 +0000

>All fine. 

Okay, so no desire to change -04  (which is good, as -04 is being prepared for AD handoff)

>I am just still confused what "relate the configuration and

For what it’s worth, opstate-reqs-04 doesn’t say “in YANG schema”.  I believe the solution could also be via metadata or even other schema, so long as the solution is programmatically consumable.  

Also, my understanding is that there are no semantics tied to what the relationship regards.  It most likely regards origin, but it doesn’t have to. I asked about utility of the relationship without semantic a long time back and the response from Rob S. (I think) was because it would allow lower software component layers within their client/controller app to generically fetch data to pass to higher layers that have semantic awareness.  I take it that they want to separate the collection and analytics of the data for scalability reasons.

Kent  // as a contributor

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 26 Jan 2016 19:52:30 +0100

> Okay, so no desire to change -04  (which is good, as -04 is being prepared for AD handoff)

I do not understand all requirements but I have given up on it. It
might be my own stupidity. That said, some parties involved in this
effort do not seem to be responsive to questions and we often end up
collectively reading between lines, grabbing stuff out of some git
repositories etc. in order to gain hints for possible answers to our
questions. This all makes me curious how the work on solutions
addressing these requirements will work.

So, publish this document, I doubt it will get any better.

/js