Subject: [netmod] FW: New Version Notification for draft-chairs-netmod-opstate-reqs-00.txt

From: Kent Watsen <[email-masked]>
Date: Fri, 11 Sep 2015 22:16:40 +0000

The AD and chairs thought it best to formalize the consensus on the
requirements a bit more.  So we created the I-D listed below to track and
capture final consensus.

Additionally, we want to use this GitHub issue tracker to track issues:

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

Consistent with Tom's earlier email, we want to collect any issues with
these requirements before EOB Monday, September 14, 2015 at 5PM EST.  If
you have an issue, in addition to posting it to the list, please consider
adding it to the GitHub tracker, and let people know you did so.   Our
goal is to close the issues as quickly as possible, some will go to DEAD
while others may remain OPEN, based on WG consensus.

Thanks,
Kent & Tom

On 9/11/15, 5:36 PM, "[email-masked]" <[email-masked]>
wrote:

>
>A new version of I-D, draft-chairs-netmod-opstate-reqs-00.txt
>has been successfully submitted by Kent Watsen and posted to the
>IETF repository.
>
>Name:		draft-chairs-netmod-opstate-reqs
>Revision:	00
>Title:		NETMOD Operational State Requirements
>Document date:	2015-09-11
>Group:		Individual Submission
>Pages:		5
>URL:            
>https://www.ietf.org/internet-drafts/draft-chairs-netmod-opstate-reqs-00.t
>xt
>Status:         
>https://datatracker.ietf.org/doc/draft-chairs-netmod-opstate-reqs/
>Htmlized:       
>https://tools.ietf.org/html/draft-chairs-netmod-opstate-reqs-00
>
>
>Abstract:
>   This document captures consensus on operational state requirements by
>   the NETMOD working group.
>
>                  
>        
>
>
>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.
>
>The IETF Secretariat
>

---

From: "Jonathan Hansford" <[email-masked]>
Date: Mon, 14 Sep 2015 10:50:13 +0100

Looking in from outside the current problem domain I'm not sure I'm
sufficiently informed to comment, however I have a couple of queries:

	* The requirements talk about both synchronous and asynchronous
systems (1(D), 3, 3(A)) but really only address the behaviour for
asynchronous systems. Would it not be worth clarifying the
relationship between the intended and applied configurations for
synchronous systems (i.e. they are the same), hence there is no need
for synchronous requirements equivalent to 1(D) and 3(A)?
	* Why does 7(A) limit the scope to IETF-defined modules of others are
now defining YANG modules?

Thanks,
Jonathan

----- Original Message -----
From: "Kent Watsen" 
To:"[email-masked]" 
Cc:
Sent:Fri, 11 Sep 2015 22:16:40 +0000
Subject:[netmod] FW: New Version Notification for
draft-chairs-netmod-opstate-reqs-00.txt

 The AD and chairs thought it best to formalize the consensus on the
 requirements a bit more. So we created the I-D listed below to track
and
 capture final consensus.

 Additionally, we want to use this GitHub issue tracker to track
issues:

 Consistent with Tom's earlier email, we want to collect any issues
with
 these requirements before EOB Monday, September 14, 2015 at 5PM EST.
If
 you have an issue, in addition to posting it to the list, please
consider
 adding it to the GitHub tracker, and let people know you did so. Our
 goal is to close the issues as quickly as possible, some will go to
DEAD
 while others may remain OPEN, based on WG consensus.

 Thanks,
 Kent & Tom

 On 9/11/15, 5:36 PM, "[email-masked]" 
 wrote:

 >https://datatracker.ietforg/doc/draft-chairs-netmod-opstate-reqs/
 >Htmlized: 

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

---

From: Benoit Claise <[email-masked]>
Date: Mon, 14 Sep 2015 14:40:54 +0200

Jonathan,
>  1. The requirements talk about both synchronous and asynchronous
>     synchronous systems (i.e. they are the same), hence there is no
>     need for synchronous requirements equivalent to 1(D) and 3(A)?
>  2. Why does 7(A) limit the scope to IETF-defined modules of others
>     are now defining YANG modules?
>
Good point. We need to provide guidance for the other SDOs.

Regards, Benoit
>     From:
>     "Kent Watsen" <[email-masked]>
>
>     To:
>     "[email-masked]" <[email-masked]>
>     Cc:
>
>     Sent:
>     Subject:
>     [netmod] FW: New Version Notification for
>     <[email-masked]>
>     wrote:
>
>     >

---

From: Benoit Claise <[email-masked]>
Date: Mon, 14 Sep 2015 14:43:26 +0200

Dear all,

I have a clarification question wrt the requirement 6

   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

 From the appendix A, we can see that this requirement comes from 
draft-openconfig-netmod-opstate-01 
<https://tools.ietf.org/html/draft-openconfig-netmod-opstate-01>, 
Section 4.5 
<https://tools.ietf.org/html/draft-chairs-netmod-opstate-reqs-00#section-4.5>
Re-reading this section 4.5, I understand 6A and 6C, but is 6B also 
required?
Do we need to make the link between a config node and all the derived 
counters/statistics it influences, which might be in different YANG 
models btw?

Regards, Benoit

---

From: Rob Shakir <[email-masked]>
Date: Mon, 14 Sep 2015 10:16:51 -0400

> counters/statistics it influences, which might be in different YANG

Yes - we need to deterministically retrieve, for a particular configuration object (e.g., interface, BGP peer) the set set of derived state nodes associated with it, such that we do not need to maintain complex mapping tables on the client side for this - and can efficiently query the server for them.

For instance, knowing that we configured a BGP peer at $SOMEROOT/bgp/neighbors/neighbor[peer-address=‘192.0.2.1’]/config/{leaf-set} then we would find the counters at $SOMEROOT/bgp/neighbors/neighbor[peer-address=‘192.0.2.1’]/state/ - allows us to (based on the fact that we just configured a peer) retrieve the state and counters that a client application will likely want to check without having to map to some other (set of locations).

Note that in previous discussions, it was expressed that this implied that the model had knowledge of how the protocol operates such that it was known that leaf A corresponding to some other derived-state leaf B. However, this isn’t true. As I expressed before, the intention is that it is possible for a NMS layer to easily retrieve the set of state objects that an interested client may require, without many disparate queries, based on the configuration path. The actual meaning may be completely unknown to this layer.

The openconfig-opstate approach allows state and config to be defined in separate modules - since the ‘state’ module in this case can simply augment the relevant ‘state’ containers within the config model.

Regards,
r.

---

From: Robert Wilton <[email-masked]>
Date: Mon, 14 Sep 2015 18:20:31 +0100

Hi Kent, Tom,

I've added the 3 requirements issues that I raised on Friday.

I also added a further one based on some of the discussion over the weekend:

The definition of "applied configuration" is slightly vague, and there 
seems to be multiple interpretations of it on the WG alias, and hence a 
tighter specification of it would be useful.

In particular:

  * does it include support for templating (as per
    openconfig-netmod-opstate-01 section 7.3.)?
  * is it allowed to represent system created objects that have no
    corresponding configuration?
  * how does it relate to the state of the system after a equivalent
    synchronous config commit (if at all)?

Thanks,
Rob

---

From: Kent Watsen <[email-masked]>
Date: Mon, 14 Sep 2015 19:01:48 +0000

Rob, thanks for clarifying the need for 6B.

No new GitHub issues filed for this thread.

Kent

On 9/14/15, 10:16 AM, "Rob Shakir" <[email-masked]> wrote:

>Yes - we need to deterministically retrieve, for a particular
>configuration object (e.g., interface, BGP peer) the set set of derived
>state nodes associated with it, such that we do not need to maintain
>complex mapping tables on the client side for this - and can efficiently
>query the server for them.
>
>For instance, knowing that we configured a BGP peer at
>$SOMEROOT/bgp/neighbors/neighbor[peer-address=Œ192.0.2.1¹]/config/{leaf-se
>t} then we would find the counters at
>$SOMEROOT/bgp/neighbors/neighbor[peer-address=Œ192.0.2.1¹]/state/ -
>allows us to (based on the fact that we just configured a peer) retrieve
>the state and counters that a client application will likely want to
>check without having to map to some other (set of locations).
>
>Note that in previous discussions, it was expressed that this implied
>that the model had knowledge of how the protocol operates such that it
>was known that leaf A corresponding to some other derived-state leaf B.
>However, this isn¹t true. As I expressed before, the intention is that it
>is possible for a NMS layer to easily retrieve the set of state objects
>that an interested client may require, without many disparate queries,
>based on the configuration path. The actual meaning may be completely
>unknown to this layer.
>
>The openconfig-opstate approach allows state and config to be defined in
>separate modules - since the Œstate¹ module in this case can simply
>augment the relevant Œstate¹ containers within the config model.
>
>Regards,
>r.

---

From: Kent Watsen <[email-masked]>
Date: Mon, 14 Sep 2015 21:03:34 +0000

I added an issue to track each of Jonathan's points:

https://github.com/netmod-wg/opstate-reqs/issues/6
https://github.com/netmod-wg/opstate-reqs/issues/7

Cheers,
Kent

From: Benoit Claise <[email-masked]<mailto:[email-masked]>>
Date: Monday, September 14, 2015 at 8:40 AM
To: Jonathan Hansford <[email-masked]<mailto:[email-masked]>>, Kent Watsen <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [netmod] FW: New Version Notification for draft-chairs-netmod-opstate-reqs-00.txt

Jonathan,
Looking in from outside the current problem domain I'm not sure I'm sufficiently informed to comment, however I have a couple of queries:

  1.  The requirements talk about both synchronous and asynchronous systems (1(D), 3, 3(A)) but really only address the behaviour for asynchronous systems. Would it not be worth clarifying the relationship between the intended and applied configurations for synchronous systems (i.e. they are the same), hence there is no need for synchronous requirements equivalent to 1(D) and 3(A)?
  2.  Why does 7(A) limit the scope to IETF-defined modules of others are now defining YANG modules?

Regards, Benoit
Thanks,

Jonathan

----- Original Message -----
From:
"Kent Watsen" <[email-masked]><mailto:[email-masked]>

To:
"[email-masked]"<mailto:[email-masked]><[email-masked]><mailto:[email-masked]>
Cc:

Sent:
Fri, 11 Sep 2015 22:16:40 +0000
Subject:
[netmod] FW: New Version Notification for draft-chairs-netmod-opstate-reqs-00.txt

Thanks,
Kent & Tom

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

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

---

From: Benoit Claise <[email-masked]>
Date: Mon, 21 Sep 2015 14:47:26 +0200

Thanks Rob, that clarifies the situation for me.

Regards, Benoit
> .