Subject: [netmod] Consensus Call Note for Requirements

From: Nadeau Thomas <[email-masked]>
Date: Thu, 10 Sep 2015 16:44:29 -0400

This is an official NETMOD working group call for consensus around the requirements referenced 
below and discussed in detail at the interim meeting held Thursday, September 10, 2015. At that meeting, the
chairs went over each requirement in detail and called for any objections to each requirement (and sub-requirement). The question that was asked was “Are there any objections to requirement X in general meaning as it is currently written or with minor/editorial changes to how its written?” There were no objections to any of the requirements, as is detailed in the meeting minutes.  However, to confirm these statements the co-chairs are opening this question to the WG for period starting today, Thursday, September 10, 2015 at 5PM EST.  This period will close on Monday, September 14, 2015 at 5PM EST.  If you commented on the list previously, or at the meeting, there is no need to repeat yourself; we have your position on 

	We will make a call of consensus shortly thereafter. 

	For your reference, the requirements can be found at this URL:

http://etherpad.tools.ietf.org:9000/p/netmod-opstate-requirements

	but I will paste them into this message explicitly to be complete.

	—Tom (as co-chair)

Terminology

From: https://tools.ietf.org/html/draft-openconfig-netmod-opstate-01

  In order to understand the way in which a network operator or network
  management system may need to interact with a device, it is key to
  understand the different types of data that network elements may
  store or master:

  o  intended configuration - this data represents the state that the
     network operator intends the system to be in.  This data is
     colloquially referred to as the 'configuration' of the system.

  o  applied configuration - this data represents the state that the
     network element is actually in, i.e., that which is currently
     being run by particular software modules (e.g., the BGP daemon),
     or other systems within the device (e.g., a secondary control-
     plane, or line card).

  o  derived state - this data represents information which is
     generated as part of the system'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).

1. Ability to interact with both intended and applied configuration

  a. The ability to ask the operational components of a system
      (e.g., line cards) for the configuration that they are currently
      using. This is the "applied configuration".

  b. applied configuration is read-only

  c. The data model for the applied configuration is the same as
      the data model for the intended configuration (same leaves)

  d. For asynchronous systems, when fully synchronized, the data
      in the applied configuration is the same as the data in the
      intended configuration.

2. Applied configuration as part of operational state

   a. the ability to retrieve the applied configuration and
       derived state nodes in a single protocol operation.

3. Support for both transactional, synchronous management
  systems as well as distributed, asynchronous management
  systems

   a. For asynchronous systems, the ability to request a protocol
       operation to not return (i.e. block) until the intended
       configuration has been fully synchronized.

   b. The protocol operation's response would indicate the result
        of the operation (success, failure, partial, etc.)

4. Separation of configuration and operational state data; ability
  to retrieve them independently

   a. be able to retrieve only the derived state aspects of operational state

   b. be able to retrieve only the non-derived state aspects of operational
       state

5. Ability to retrieve operational state corresponding only to
  derived values, statistics, etc.

   // this is a duplicate of # 4-a

6. 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

7. Ability for distinct modules to leverage a common model-structure

 a. Scope is limited to IETF-defiend modules
 b. multiple domain-specific trees are okay
 c. multiple namespaces are okay

---

From: Robert Wilton <[email-masked]>
Date: Fri, 11 Sep 2015 11:48:39 +0100

Hi Kent, Tom,

I don't really want to slow down the consensus process, but after the 
discussion there are a couple of requirements that are not absolutely 
clear to me.  [Sorry for not raising them in the meeting yesterday, but 
we had already spent a lot of time discussing the requirements and I 
also think that you understandably went through the options quite fast 
at the end].

>        in the applied configuration is the same as the data in the
- I think that it would be useful to define what full synchronized 
means.  In this context, I think of it as meaning if none of the 
configuration failed to be applied for any reason (e.g. due to absence 
of hardware, or internal system error).

- Separately, this isn't specified in the openconfig-netmod-opstate 
draft, but is there any requirement to indicate why an intended cfg node 
isn't in the applied cfg?  In the solution that I've proposed, I've 
assumed that there is.  It would be good to get clarification on whether 
it is a genuine valid requirement or not.

>         configuration has been fully synchronized.
I'm not sure why 3 (a) is a requirement, or its unclear to me where this 
is specified in the openconfig-netmod-opstate draft.

Thanks,
Rob

---

From: Nadeau Thomas <[email-masked]>
Date: Fri, 11 Sep 2015 08:09:36 -0400

> On Sep 11, 2015:6:48 AM, at 6:48 AM, Robert Wilton <[email-masked]> wrote:
> 
> Hi Kent, Tom,
> 
> I don't really want to slow down the consensus process, but after the discussion there are a couple of requirements that are not absolutely clear to me.  [Sorry for not raising them in the meeting yesterday, but we had already spent a lot of time discussing the requirements and I also think that you understandably went through the options quite fast at the end].
> 
> - I think that it would be useful to define what full synchronized means.  In this context, I think of it as meaning if none of the configuration failed to be applied for any reason (e.g. due to absence of hardware, or internal system error).
> 
> - Separately, this isn't specified in the openconfig-netmod-opstate draft, but is there any requirement to indicate why an intended cfg node isn't in the applied cfg?  In the solution that I've proposed, I've assumed that there is.  It would be good to get clarification on whether it is a genuine valid requirement or not.
> 
>> 
> I'm not sure why 3 (a) is a requirement, or its unclear to me where this is specified in the openconfig-netmod-opstate draft.

	Anees/Rob, can you guys please add some color to the above descriptions to help clarify things for Robert?

	—Tom

---

From: Lou Berger <[email-masked]>
Date: Fri, 11 Sep 2015 09:28:59 -0400

> 	Anees/Rob, can you guys please add some color to the above descriptions to help clarify things for Robert?
I see (3) but not (3.a) in
http://tools.ietf.org/html/draft-openconfig-netmod-opstate-01#section-4.2
so am unsure how 3.a made it on the list.

also, I don't object to 3.a if *users* say they need it.

Lou

---

From: Kent Watsen <[email-masked]>
Date: Mon, 14 Sep 2015 18:14:29 +0000

These GitHub issues were opened per this thread:

  - https://github.com/netmod-wg/opstate-reqs/issues/1
  - https://github.com/netmod-wg/opstate-reqs/issues/2
  - https://github.com/netmod-wg/opstate-reqs/issues/3

Thank you Rob!

Kent

On 9/11/15, 9:28 AM, "Lou Berger" <[email-masked]> wrote:

>>> > I'm not sure why 3 (a) is a requirement, or its unclear to me where
>>>this is specified in the openconfig-netmod-opstate draft.
>> 	Anees/Rob, can you guys please add some color to the above
>>descriptions to help clarify things for Robert?
>_______________________________________________
>netmod mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/netmod