Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

Comments inline... I generally like the approach of explaining the situation so that module writers can take an informed decision. I am struggling a bit with the strong recommendation given and I am not sure whether using two separate modules for /foo and /foo-state makes things really simpler.

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

Balazs, > On 2 Aug, 2016, at 10:29 AM, Balazs Lengyel > wrote: > I prefer a tight definition so even if we allow both 1) and 2) we should > state that other combinations e.g. trees spliting close to the leaves or a > mix of 1) and 2) in the same module are not

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

Watsen <kwat...@juniper.net>; netmod WG <netmod@ietf.org> Subject: Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

Hello, Later I will try to provide a text proposal as well, but some points: I prefer a tight definition so even if we allow both 1) and 2)  we should state that other combinations e.g. trees spliting close to the leaves or a mix of 1) and 2) in the

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

Following Lou’s recommendation, my proposed changes for rfc6087bis Section 5.23 follow: 5.23. Operational Data In YANG, any data that has a "config" statement value of "false" could be considered operational data. The relationship between configuration (i.e., "config" statement

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

On Fri, Jul 29, 2016 at 04:35:05PM +0100, Robert Wilton wrote: > I would like to know what should the common approach for IETF standard > models be? E.g. is it one of the following: > > 1) All config false leaves for foo must go under /foo-state. I think if you have /foo-state, then this is a

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

Hi, You said "automated code". Write some YANG extensions for your tools to manually assign the mapping. This has already been suggested several times. This approach can also address N:M mappings. Supporting 1:1 mappings and ignoring everything else doesn't really help. Andy On Fri, Jul 29,

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

Picking this message as it is the most recent on this thread - I'd like to "up level "the discussion. My read (as chair) on this topic is that in our Berlin meeting, see discussions related to slide on Section 5.23 of rfc6087bis, we were left with opinion in the room supporting the current text

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

Hi Andy, The main problem that I'm currently trying to solve, and get agreement on, is "where does the operator's automated code look to find the state nodes associated with a particular config node". E.g. for feature /foo, do they look for the config false nodes under /foo, or do the look

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

Hi, I am somewhat confused about this discussion. Apparently it is a hyge problem to put foo-counters under foo-state? Configuration must be used (and setup by the operator?) in order for foo-counters to exist? So what problem does this solve? The opstate solution proposal requires a config

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

Hi Andy, I think that it would be fair to say that the authors of draft-openconfig-netmod-opstate-01 think that it broken (e.g. sections 6.1, 8.1.2), particularly given that they have decided that it is better to have their own OpenConfig version of interfaces rather than augment RFC 7223.

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

Agreed. I’m not saying it isn’t possible to have a combined config/state tree. My previous point is that it represents a major shift and would be hard to reach consensus in the desired time frame. Thanks, Acee On 7/28/16, 10:57 AM, "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)"

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

On 7/28/16, 10:20 AM, "Ladislav Lhotka" wrote: > >> On 28 Jul 2016, at 15:57, Acee Lindem (acee) wrote: >> >> Hi Lada, >> >> On 7/28/16, 9:52 AM, "netmod on behalf of Ladislav Lhotka" >> wrote: >> >>>

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

Xufeng Liu <xufeng.liu.i...@gmail.com <mailto:xufeng.liu.i...@gmail.com>> Cc: netmod WG <netmod@ietf.org <mailto:netmod@ietf.org>> Subject: Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure Robert mentions IS-IS, and if I look at OSPF, I see a

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

> On 28 Jul 2016, at 16:48, Acee Lindem (acee) wrote: > > > > On 7/28/16, 10:42 AM, "Robert Wilton -X (rwilton - ENSOFT LIMITED at > Cisco)" wrote: > >> >> >> On 28/07/2016 15:20, Ladislav Lhotka wrote: On 28 Jul 2016, at 15:57, Acee Lindem (acee)

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

On 28/07/2016 15:48, Acee Lindem (acee) wrote: On 7/28/16, 10:42 AM, "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" wrote: On 28/07/2016 15:20, Ladislav Lhotka wrote: On 28 Jul 2016, at 15:57, Acee Lindem (acee) wrote: Hi Lada, On 7/28/16,

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

On 7/28/16, 10:42 AM, "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" wrote: > > >On 28/07/2016 15:20, Ladislav Lhotka wrote: >>> On 28 Jul 2016, at 15:57, Acee Lindem (acee) wrote: >>> >>> Hi Lada, >>> >>> On 7/28/16, 9:52 AM, "netmod on behalf of

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

On 28/07/2016 15:20, Ladislav Lhotka wrote: On 28 Jul 2016, at 15:57, Acee Lindem (acee) wrote: Hi Lada, On 7/28/16, 9:52 AM, "netmod on behalf of Ladislav Lhotka" wrote: Robert Wilton writes: On

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

> On 28 Jul 2016, at 15:57, Acee Lindem (acee) wrote: > > Hi Lada, > > On 7/28/16, 9:52 AM, "netmod on behalf of Ladislav Lhotka" > wrote: > >> Robert Wilton writes: >> >>> On 26/07/2016 21:36, Kent

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

Hi Lada, On 7/28/16, 9:52 AM, "netmod on behalf of Ladislav Lhotka" wrote: >Robert Wilton writes: > >> On 26/07/2016 21:36, Kent Watsen wrote: >>> >>> >>> >>> >>> So my thinking is that if we can't merge "foo-state" into

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

Robert Wilton writes: > On 26/07/2016 21:36, Kent Watsen wrote: >> >> >> >> >> So my thinking is that if we can't merge "foo-state" into "foo" then >> instead we should have consistent rules that explicitly state that for >> all IETF models "foo" and "foo-state" are

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

Hi, *Re: - Any models that augment RFC 7223 and have config false nodes will be impacted.* There are many such vendor modules already. They augment the /interfaces container with config and the /interfaces-state container with non-config. Nobody is complaining this is broken, AFAIK. If you tell

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

>> Firstly, I’m trying to get a sense of how big a problem this >> foo/foo-state thing is. [Note: by foo-state, I’m only referring >> to counters, not opstate]. RW: By counters, I think that we also mean any config false nodes that don't directly represent "applied configuration", right? E.g.

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

...@ietf.org] *On Behalf Of *Robert Wilton *Sent:* Wednesday, July 27, 2016 1:05 PM *To:* Kent Watsen <kwat...@juniper.net>; netmod WG <netmod@ietf.org> *Subject:* Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure On 26/07/2016 21:36, Kent

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

i...@gmail.com>> Cc: netmod WG <netmod@ietf.org<mailto:netmod@ietf.org>> Subject: Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure Robert mentions IS-IS, and if I look at OSPF, I see a clear separation of rw and ro nodes. Right - and this sepa

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

etf.org> > Subject: Re: [netmod] OpsState Direction Impact on Recommended IETF YANG > Model Structure > > > > > On 26/07/2016 21:36, Kent Watsen wrote: >> >> >> >> So my thinking is that if we can't merge "foo-state" into &

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

To: Kent Watsen <kwat...@juniper.net>; netmod WG <netmod@ietf.org> Subject: Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure On 26/07/2016 21:36, Kent Watsen wrote: So my thinking is that if we can't merge "foo-state" into

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

On 26/07/2016 21:36, Kent Watsen wrote: So my thinking is that if we can't merge "foo-state" into "foo" then instead we should have consistent rules that explicitly state that for all IETF models "foo" and "foo-state" are separate trees with a consistent naming convention and structure.

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

:rwil...@cisco.com>>, netmod WG <netmod@ietf.org<mailto:netmod@ietf.org>> Subject: Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure There are a number of issues here. The first is that you are now depending on the separate applied state data store b

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

There are a number of issues here. The first is that you are now depending on the separate applied state data store being implemented on every network device if you are going to eliminate the duplication of actual values in the OpState. The second is that OpsState is MUCH more than just

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

..@cisco.com<mailto:rwil...@cisco.com>>, netmod WG <netmod@ietf.org<mailto:netmod@ietf.org>> Subject: Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure So my thinking is that if we can't merge "foo-state" into "foo" then in

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

So my thinking is that if we can't merge "foo-state" into "foo" then instead we should have consistent rules that explicitly state that for all IETF models "foo" and "foo-state" are separate trees with a consistent naming convention and structure. That should hopefully allow tooling to

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

> On 26 Jul, 2016, at 9:52 AM, Robert Wilton wrote: > > What other alternatives are available? As a WG we need to tell the other WGs > how the IETF YANG models should be structured. An interested observer could note that the convention that was described in the initial

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

On 25/07/2016 21:03, Kent Watsen wrote: >> Juergen writes: >> Bottom line: I think we should continue to follow the model used by >> the ietf-interfaces model and the ietf-ip model until we have a better >> solution in place (and subsequently we can deprecate objects that >> became

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

>> Juergen writes: >> Bottom line: I think we should continue to follow the model used by >> the ietf-interfaces model and the ietf-ip model until we have a better >> solution in place (and subsequently we can deprecate objects that >> became redundant). > > Rob writes: > This is pretty much what

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

On 21/07/2016 19:40, Juergen Schoenwaelder wrote: On Thu, Jul 21, 2016 at 06:39:29PM +0200, Robert Wilton wrote: Hi, So after the various meetings and discussions this week, I think that the most important thing for IETF to do is to publish reviewed YANG models quickly, with the

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

On Thu, Jul 21, 2016 at 06:39:29PM +0200, Robert Wilton wrote: > Hi, > > So after the various meetings and discussions this week, I think that the > most important thing for IETF to do is to publish reviewed YANG models > quickly, with the understanding that it is better to publish imperfect >

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

Hi, So after the various meetings and discussions this week, I think that the most important thing for IETF to do is to publish reviewed YANG models quickly, with the understanding that it is better to publish imperfect models than to end up not publishing any models at all. This is with

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

On 7/15/16, 10:23 AM, "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" wrote: > > >On 15/07/2016 15:16, Acee Lindem (acee) wrote: >> >> On 7/14/16, 4:00 PM, "Kent Watsen" wrote: >> >>> [This thread took on a life of its own, so I’m replying to

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

On 7/14/16, 4:00 PM, "Kent Watsen" wrote: > >[This thread took on a life of its own, so I’m replying to this email >from two days ago] > >I had assumed the plan/recommendation would be: > - for works-in-progress, to evaluate if their models can be improved. > - for

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

On Wed, Jul 13, 2016 at 3:17 PM, Kent Watsen wrote: > > > > > > RW: > > Are you thinking of a single global notification of convergence? > > > > > > > No > > > > > > I think the client would request a notification for its edit. > > > There would be a long-form and short-form

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

> RW: > Are you thinking of a single global notification of convergence? > No > > I think the client would request a notification for its edit. > There would be a long-form and short-form notification. > > The interaction model is simple: > A) at the time of the request the client opt-in for

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

On Wed, Jul 13, 2016 at 2:43 AM, Robert Wilton wrote: > Please see RW: inline > > On 12/07/2016 20:15, Andy Bierman wrote: > > > > On Tue, Jul 12, 2016 at 12:07 PM, Juergen Schoenwaelder < > j.schoenwael...@jacobs-university.de > > wrote:

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

t; *Sent:* Wednesday, 13 July 2016 4:17 a.m. *To:* Lou Berger *Cc:* netmod WG *Subject:* Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure On Tue, Jul 12, 2016 at 8:23 AM, Lou Berger <lber...@labn.net <mailto:lber...

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

--- > *From:* netmod <netmod-boun...@ietf.org> <netmod-boun...@ietf.org> on > behalf of Andy Bierman <a...@yumaworks.com> <a...@yumaworks.com> > *Sent:* Wednesday, 13 July 2016 4:17 a.m. > *To:* Lou Berger > *Cc:* netmod WG > *Subject:* Re: [netmod] Ops

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

netmod <netmod-boun...@ietf.org> on behalf of Andy Bierman <a...@yumaworks.com> *Sent:* Wednesday, 13 July 2016 4:17 a.m. *To:* Lou Berger *Cc:* netmod WG *Subject:* Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure On Tue, Jul 12, 2016 at 8:23 AM, Lou Berger

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

behalf of Andy Bierman <a...@yumaworks.com> Sent: Wednesday, 13 July 2016 4:17 a.m. To: Lou Berger Cc: netmod WG Subject: Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure On Tue, Jul 12, 2016 at 8:23 AM, Lou Berger <lber...@labn.net<mailto:lber...@labn

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

Please see RW: inline On 12/07/2016 20:15, Andy Bierman wrote: On Tue, Jul 12, 2016 at 12:07 PM, Juergen Schoenwaelder > wrote: On Tue, Jul 12, 2016 at 11:36:03AM -0700, Andy Bierman wrote: > Yes

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

On 12/07/2016 20:07, Juergen Schoenwaelder wrote: I think it is worth to step back for a moment and to think about where we like to be in 5 or 10 years from now when we discuss architectural questions. RW: This makes sense, if we can do it in parallel to making progress on the opstate

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

On Tue, Jul 12, 2016 at 12:07 PM, Juergen Schoenwaelder < j.schoenwael...@jacobs-university.de> wrote: > On Tue, Jul 12, 2016 at 11:36:03AM -0700, Andy Bierman wrote: > > Yes there is value in modeling conventions in general. > > I am trying to understand the value of this specific convention. >

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

On Tue, Jul 12, 2016 at 11:36:03AM -0700, Andy Bierman wrote: > Yes there is value in modeling conventions in general. > I am trying to understand the value of this specific convention. > > If I have an RPC that asks for applied state, then it doesn't really matter > how the config and state is

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

Andy, This may be a bit OBE by the conversation on the list, but see below... On 7/12/2016 12:17 PM, Andy Bierman wrote: > > > On Tue, Jul 12, 2016 at 8:23 AM, Lou Berger > wrote: > > Acee, > > I personally was assuming we'd follow 3,

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

LIMITED at Cisco)" < > rwil...@cisco.com> > Cc: netmod WG <netmod@ietf.org> > Subject: Re: [netmod] OpsState Direction Impact on Recommended IETF YANG > Model Structure > > > > On Tue, Jul 12, 2016 at 10:22 AM, Robert Wilton <rwil...@cisco.com> wrote: &

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

sco.com<mailto:rwil...@cisco.com>> Cc: netmod WG <netmod@ietf.org<mailto:netmod@ietf.org>> Subject: Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure On Tue, Jul 12, 2016 at 10:22 AM, Robert Wilton <rwil...@cisco.com<mailto:rwil...@cisco.

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

On Tue, Jul 12, 2016 at 10:22 AM, Robert Wilton wrote: > > > On 12/07/2016 18:05, Andy Bierman wrote: > > > > On Tue, Jul 12, 2016 at 9:59 AM, Robert Wilton wrote: > >> Hi Andy, >> >> On 12/07/2016 17:17, Andy Bierman wrote: >> >> >> >> On Tue, Jul 12, 2016

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

On 12/07/2016 18:05, Andy Bierman wrote: On Tue, Jul 12, 2016 at 9:59 AM, Robert Wilton > wrote: Hi Andy, On 12/07/2016 17:17, Andy Bierman wrote: On Tue, Jul 12, 2016 at 8:23 AM, Lou Berger

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

s.com> >> Date: Tuesday, July 12, 2016 at 12:17 PM >> To: Lou Berger <lber...@labn.net> >> Cc: Acee Lindem <a...@cisco.com>, netmod WG <netmod@ietf.org> >> Subject: Re: [netmod] OpsState Direction Impact on Recommended IETF YANG >> Model Struct

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

Hi Andy, On 12/07/2016 17:17, Andy Bierman wrote: On Tue, Jul 12, 2016 at 8:23 AM, Lou Berger > wrote: Acee, I personally was assuming we'd follow 3, but I'd like to understand the implication of 2 as I'm not sure I really

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

rg<mailto:netmod@ietf.org>> Subject: Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure On Tue, Jul 12, 2016 at 9:30 AM, Acee Lindem (acee) <a...@cisco.com<mailto:a...@cisco.com>> wrote: Hi Andy, From: Andy Bierman <a...@yumaworks.com<mailto:a..

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

G <netmod@ietf.org> > Subject: Re: [netmod] OpsState Direction Impact on Recommended IETF YANG > Model Structure > > > > On Tue, Jul 12, 2016 at 8:23 AM, Lou Berger <lber...@labn.net> wrote: > >> Acee, >> >> I personally was assuming we'd fol

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

rg<mailto:netmod@ietf.org>> Subject: Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure On Tue, Jul 12, 2016 at 8:23 AM, Lou Berger <lber...@labn.net<mailto:lber...@labn.net>> wrote: Acee, I personally was assuming we'd follow 3, but I

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

On Tue, Jul 12, 2016 at 8:23 AM, Lou Berger wrote: > Acee, > > I personally was assuming we'd follow 3, but I'd like to understand > the implication of 2 as I'm not sure I really understand what you're > thinking here. Can you elaborate what you're thinking here? > >

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

Acee, I personally was assuming we'd follow 3, but I'd like to understand the implication of 2 as I'm not sure I really understand what you're thinking here. Can you elaborate what you're thinking here? Thanks, Lou On 7/11/2016 12:36 PM, Acee Lindem (acee) wrote: > While there are details

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

Hi Lou, I’m not advocating this #2. If you are going to rely on the revised data stores to obtain the information, you should go all the way to #3. For example, based on the control-plane-protocols in routing-cfg, we have separate top level containers for config state. +--rw routing +--rw