Subject: Re: [netmod] WebEx meeting invitation: NETMOD Interm meeting on OpenConfig: tomorrow meeting

From: Benoit Claise <[email-masked]>
Date: Wed, 9 Sep 2015 22:16:06 +0200

Dear all,

There is a lot of passionate debates around YANG these days, which shows 
how important YANG became.

After the last IETF meeting, the openconfig group requested a call with me.
During that call, these operators re-explained their problem to me.

Let me decompose this into three parts, and again set the stage for this 
interim meeting tomorrow.

1. The problem statement.
When a group of operators come to the IETF with a problem, we should 
take this seriously and embrace it. In other words, nobody can dispute 
the operators problem statement.

2. The requirements.
If there are still clarifications needed around the requirements in 
draft-openconfig-netmod-opstate-01 section 4, or around the requirement 
that the YANG models need some sort of hierarchy 
(draft-openconfig-netmod-model-structure), like for the routing models, 
... tomorrow interim meeting is your chance, or between now and then on 
the mailing list.

3. The solution:
There are actually 3 different solutions for the operational state.
3.1 draft-openconfig-netmod-opstate-01, whose version 00 has already 
been presented/discussed
3.2 draft-kwatsen-netmod-opstate, not yet presented
3.3 draft-wilton-netmod-opstate-yang, not yet presented
Come prepared, and have read those drafts in advance.
This interim meeting should be about comparing solutions around the 
operational state solutions.

We also need understand whether solving those requirements within the 
context of NETCONF/RESTCONF (draft-kwatsen-netmod-opstate or 
draft-wilton-netmod-opstate-yang) is satisfactory.

Regards, Benoit (OPS AD)
> Dear all,
>
> Let me set the stage for this future interim.
>
> First of (and let me repeat), I'm happy that the operators gathered 
> and collectively worked on YANG models and related requirements.
>
> The previous two interim meetings in June on the openconfig issues 
> (draft-openconfig-netmod-opstate-01 
> <http://datatracker.ietf.org/doc/draft-openconfig-netmod-opstate/> and 
> draft-openconfig-netmod-model-structure-00 
> <http://datatracker.ietf.org/doc/draft-openconfig-netmod-model-structure/>) 
> were successful in the sense that the requirements are now understood.
>
> Unfortunately, some key players were not in Prague and we could not 
> finalize the discussion.
> How to represent the operational state is one important guidance from 
> RFC 6087bis that we must be providing to all existing and future YANG 
> models (and not only in the IETF).
>
> We need to bring closure on that topic, and this is the plan for that 
> interim meeting in September.
>
> http://datatracker.ietf.org/doc/draft-openconfig-netmod-opstate/ has 
> been updated. Please comment on this version.
> Also, any alternate proposals must be prepared for that interim in 
> September. They must be prepared with the same level of rigour as 
> draft-openconfig-netmod-opstate., i.e. must have the same level of 
> details.
>
> In the meeting in September, the goal is to take a decision.
>
> Regards, Benoit (OPS AD)
>
>> Hello,
>> NETMOD Working Group invites you to join this WebEx meeting.
>>
>> *NETMOD Interm meeting on OpenConfig*
>> Thursday, September 10, 2015
>> 11:00 am  |  Eastern Daylight Time (New York, GMT-04:00)  |  1 hr
>>
>> *Join WebEx meeting* 
>> <https://ietf.webex.com/ietf/j.php?MTID=m54c7bcbed84a08dc78fba128d500f8c0> 
>>
>>
>> Meeting number: 	645 732 277
>> Meeting password: 	1234
>>
>> *Join by phone*
>> *1-877-668-4493* Call-in toll free number (US/Canada)
>> *1-650-479-3208* Call-in toll number (US/Canada)
>> Access code: 645 732 277
>> Toll-free calling restrictions 
>> <http://www.webex.com/pdf/tollfree_restrictions.pdf>
>>
>> Add this meeting 
>> <https://ietf.webex.com/ietf/j.php?MTID=m17086d6b9810a2722c5dc8c64ec795b9> 
>> to your calendar.
>>
>> Can't join the meeting? Contact support. 
>> <https://ietf.webex.com/ietf/mc>
>>
>> IMPORTANT NOTICE: Please note that this WebEx service allows audio 
>> and other information sent during the session to be recorded, which 
>> may be discoverable in a legal matter. By joining this session, you 
>> automatically consent to such recordings. If you do not consent to 
>> being recorded, discuss your concerns with the host or do not join 
>> the session.
>>
>>
>>
>> _______________________________________________
>> netmod mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/netmod
>
>
>
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

---

From: Andy Bierman <[email-masked]>
Date: Wed, 9 Sep 2015 14:40:44 -0700

On Wed, Sep 9, 2015 at 1:16 PM, Benoit Claise <[email-masked]> wrote:

> When a group of operators come to the IETF with a problem, we should take
> this seriously and embrace it. In other words, nobody can dispute the
> operators problem statement.
>
> 2. The requirements.
> (draft-openconfig-netmod-model-structure), like for the routing models, ...
> tomorrow interim meeting is your chance, or between now and then on the
> mailing list.
>
>

My concern with the problem statement and the requirements in sec. 4 is
that they focus
on very large systems, yet these problems do not exist on small systems.
YANG is being considered in the CORE WG.  If and when the CoMI charter
addition
is approved then YANG will need to support constrained devices.

Common modules like ietf-interfaces need to scale well.  IMO the authors
of RFC 7223 did a great job of not imposing any requirements that assume
use-cases or platform resources.  All common modules need to be
designed the same way.

I have yet to hear a number wrt/ how many seconds or minutes does it
usually take
for intended config to become active config?  What percentage of all
devices that
use YANG have this problem?  How fast is the data expected to change while
the client is polling it?  The solution should not impact systems that do
not have
these problems that appear to be related to the very large or complex
configurations.

Andy

> 3.1 draft-openconfig-netmod-opstate-01, whose version 00 has already been
> presented/discussed
> First of (and let me repeat), I'm happy that the operators gathered and
> collectively worked on YANG models and related requirements.
>
> The previous two interim meetings in June on the openconfig issues (
> draft-openconfig-netmod-opstate-01
> How to represent the operational state is one important guidance from RFC
> 6087bis that we must be providing to all existing and future YANG models
> (and not only in the IETF).
>
> http://datatracker.ietf.org/doc/draft-openconfig-netmod-opstate/ has been
> updated. Please comment on this version.
> draft-openconfig-netmod-opstate., i.e. must have the same level of details.
>
> Hello, NETMOD Working Group invites you to join this WebEx meeting.   *NETMOD
> Interm meeting on OpenConfig* Thursday, September 10, 2015 11:00
> am  |  Eastern Daylight Time (New York, GMT-04:00)  |  1 hr   *Join WebEx
> meeting*
> <https://ietf.webex.com/ietf/j.php?MTID=m54c7bcbed84a08dc78fba128d500f8c0> Meeting
> number: 645 732 277 Meeting password: 1234   *Join by phone*
> *1-877-668-4493* Call-in toll free number (US/Canada) *1-650-479-3208* Call-in
> toll number (US/Canada) Access code: 645 732 277 Toll-free calling
> restrictions <http://www.webex.com/pdf/tollfree_restrictions.pdf>   Add
> this meeting
> to your calendar.   Can't join the meeting? Contact support.
> <https://ietf.webex.com/ietf/mc>   IMPORTANT NOTICE: Please note that
> this WebEx service allows audio and other information sent during the
> session to be recorded, which may be discoverable in a legal matter. By
> joining this session, you automatically consent to such recordings. If you
> do not consent to being recorded, discuss your concerns with the host or do
> not join the session.
>
> netmod mailing [email-masked]://www.ietf.org/mailman/listinfo/netmod
>
>
>
>
> netmod mailing [email-masked]://www.ietf.org/mailman/listinfo/netmod
>
>
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 10 Sep 2015 00:00:34 +0200

> ... tomorrow interim meeting is your chance, or between now and then on 

For the record (since I won't be able to join the call): I disagree
with some of the details in the description of the requirement in
section 4.5. I agree with the part that says that it should be
possible to 'easily' locate the operational state corresponding to
configuration state (and I would add that 'easily' means both for
humans and machines). I would go even further to say that it should
not just be 'easy' but also be 'robust'. What I disagree with is the
part that suggests every 'selector' should be encoded in the schema
path. Note that I am talking about the schema used on a device, I am
not talking about the schema used within an NMS.

/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: Lou Berger <[email-masked]>
Date: Wed, 09 Sep 2015 22:12:58 -0400

Juergen,

It sounds like you are agreeing with the requirements but not the solution. 
 I think this is a valuable distinction, i.e., that it's possible to agree 
with one but not the other.  I'd also like to point out that the first part 
of the discussion is limited to requirements only so we can focus on the 
former before delving in to the latter .

Lou

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 10 Sep 2015 08:32:48 +0200

Yes, in my view, section 4.5 goes a bit too far in making a certain
solution part of the requirement.

The solutions that have been written up have different properties in
terms of data modeling impact, device implementation impact, NMS
implementation impact and backwards compatibility impact. Furthermore,
we need to acknowledge that not all devices are asynchronous. These
aspects need to be taken into account when selecting a solution.

What is needed is clarity what the requirements are that we find
agreement on. I believe it is possible to tweak the text in section 4
to something people can agree on. But as it is written in -01, I do
not think we are there yet.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 10 Sep 2015 09:41:59 +0200 (CEST)

Hi,

Benoit Claise <[email-masked]> wrote:
> draft-openconfig-netmod-opstate-01 section 4

  4.1.  Applied configuration as part of operational state

Already in the title, this requirement mandates the solution.

I think the requirement is that if the device is "asynchronous", the
operator should (1) be able to learn this fact and (2) be able to
retrieve both intended and applied configuration.

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

If people say that they have systems that work like this, then ok.

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

Ok, but retrieval is going to be a protocol issue, not a language issue.

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

Ok, but retrieval is going to be a protocol issue, not a language issue.

  4.5.  Consistent schema locations for configuration and corresponding
      operational state data

This requirement also mandates the solution in the title.  I think
Juergen formulated this requirement better when he wrote that it
should be 'easy' to locate state related to config for humans and
machines, in a 'robust' way.

Also, in the introduction, the document says:

   These proposals are based on the assertion that YANG models should
   be usable via a number of protocols (not solely IETF-defined
   protocols such as NETCONF and RESTCONF)

I agree with this statement in priniciple, but only if the protocol is
suitable for YANG.  I do not agree that YANG should be changed
everytime someone says that they want to use YANG with protocol X
(especially when protocol X is unknown).  In fact, I believe it is not
possible to design a *data* modelling language (see RFC 3444) that can
be used for an arbitrary protocol (see
draft-schoenw-sming-lessons-01).

As an example, I know that some implementations are using YANG with
SNMP.  Does this imply that *all* models MUST have some statement to
assign an oid with every node?

> , or around the
> requirement that the YANG models need some sort of hierarchy
> (draft-openconfig-netmod-model-structure)

I don't think the requirements for this problem are described
anywhere?

/martin

---

From: Anees Shaikh <[email-masked]>
Date: Thu, 10 Sep 2015 01:31:07 -0700

hi -- some additional comments inline.  I think that the revisit on some of
the operator requirements is primarily due to some proposed solution's
inability to address them.

> retrieve both intended and applied configuration.

No, the title does not mandate a solution -- it just asserts that
configuration should be treated as part of the state, or,  in other words,
what a device is running at any given moment is part of its state -- I do
agree that it's a different perspective from the thinking that led to the
limited way in which YANG supports operational state modeling today.

> Ok, but retrieval is going to be a protocol issue, not a language issue.

Retrieval is not only about the protocol -- the model's structure (in this
case the ability to indicate state data clearly in the model ) also is
important.  Limiting this to a protocol issue also presupposes a solution.

> Ok, but retrieval is going to be a protocol issue, not a language issue.

Again, no -- not only a protocol issue -- same as above (this time you're
dictating a solution :-) ).   Certainly the model plays a part in
designating different data items as operational state that reflects applied
configuration vs. operational state that reflects device-generated data.

> machines, in a 'robust' way.

This alternate formulation is not better -- it's just a much vaguer version
of the requirement that is harder to define -- I think we've already seen
there are very different experiences and ideas about what makes a solution
easy or robust.   And prioritizing YANG modeling for consumption by humans
rather than NMSes, automation systems, programmatic interfaces, etc. risks
defeating the whole purpose of using it IMO.

> assign an oid with every node?

No.  Please note that our proposed solutions have so far required *no*
changes to YANG other than use of a single extension (which is a supported
language feature).  Not a single line of pyang was changed to successfully
compile models that follow the proposed structure.   Let's not confuse
proposing changes to YANG *models* and introducing conventions with
requiring changes to the YANG language.  This is not to say that some
language changes would not make things a bit more sensible -- we have
worked around those limitations, and most of the changes have been
identified as needed in other contexts as well (see observations from the
ODL project, for example).  I expect proposals to be forthcoming.

> I don't think the requirements for this problem are described

Well, you could re-read the thread that you actively participated in
(Motivations for Structuring Models)  :-)  My read of that discussion (and
the discussion at the June interim meeting on this topic) was that there
was no real disagreement on the need for a structure to help organize
related functionality across the growing set of models  (the ietf-routing
model is trying to do exactly this for a subset of functionality).  The
main issue was whether there is a need to anchor such a structure in an
additional layer on the device (i.e., /device) or whether such a layer
should be maintained solely by the NMS.

thanks.
-- Anees

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 10 Sep 2015 11:19:56 +0200 (CEST)

Hi,

Anees Shaikh <[email-masked]> wrote:
> what a device is running at any given moment is part of its state

Ok, as long as "part of operational state" does not mean "must be
modelled as config false in YANG".

> -- I do

Let me rephrase.  I agree that we need to be able to separate
configuration data from operational state data, and this is a language
issue.  However, the protocol needs to support retrieval of them
independently.

> configuration vs. operational state that reflects device-generated data.

Agreed.  See above.

> of the requirement that is harder to define

How about "ability to relate configuration with its corresponding
operational state"?   And not use terms like "easy", "robust" etc.

> -- I think we've already seen
> No.

Great, then we agree!

> Please note that our proposed solutions have so far required *no*
> requiring changes to the YANG language.

Sure, but the implications of these conventions are such that unless
my YANG module follow these conventions, it cannot be used (other than
in a closed proprietary environment).

> This is not to say that some
> (Motivations for Structuring Models)  :-)

If the goal of this meeting is to agree on requirements, wouldn't it
help if we had them summarized in one place?

> My read of that discussion (and
> model is trying to do exactly this for a subset of functionality).

Agreed, and this is a good way to handle this problem.  I.e., define
structure for one function at the time.

/martin

---

From: Nadeau Thomas <[email-masked]>
Date: Thu, 10 Sep 2015 08:20:05 -0400

> On Sep 10, 2015:2:32 AM, at 2:32 AM, Juergen Schoenwaelder <[email-masked]> wrote:
> 

	Is it that you disagree with the specifics of what is written
so that minor refinements would satisfy your need for clarity, or do you
believe there are entire requirements that either do not exist, or should
be removed from section 4.5?  If the case is the former, please be constructive
and provide proposed changes to the text; if the latter, please specify 
that as well.

	—Tom

---

From: Kent Watsen <[email-masked]>
Date: Thu, 10 Sep 2015 12:21:54 +0000

>help if we had them summarized in one place?

Yes, we must have a list of requirements that everyone agrees to.   We
will subsequently put it into an email to the WG for final on-list
consensus.   

Kent

---

From: Lou Berger <[email-masked]>
Date: Thu, 10 Sep 2015 08:26:38 -0400

I think another question is if the current *requirements* text good /close 
enough for a -00 wg document....

Lou

On September 10, 2015 8:20:34 AM Nadeau Thomas <[email-masked]> wrote:

>
>> On Sep 10, 2015:2:32 AM, at 2:32 AM, Juergen Schoenwaelder

---

From: Nadeau Thomas <[email-masked]>
Date: Thu, 10 Sep 2015 08:52:35 -0400

The desire from the co-chairs and AD anyways, is that we do not start a requirements draft
as a result of today’s meeting (and mailing list confirmation of the outcome). As Kent mentioned earlier 
in this thread, to document this list of detailed requirements on the mailing list.  The motivation for this 
versus a draft, is that waiting for a draft to completely is a drag on progress, and we don’t want to 
gate or slow things down.  Putting them in a place different from the existing draft also helps with
the perceptional issues that were raised earlier.

	—Tom

> On Sep 10, 2015:8:26 AM, at 8:26 AM, Lou Berger <[email-masked]> wrote:
> 
> I think another question is if the current *requirements* text good /close enough for a -00 wg document....
> 
> Lou
> 
>

---

From: Lou Berger <[email-masked]>
Date: Thu, 10 Sep 2015 09:45:41 -0400

Tom,

> the perceptional issues that were raised earlier.

This works as long as we break this seemingly endless requirements
discussion cycle that keeps coming up when try to discuss solutions.

>From my perspective we already have documented operator requirements
that seem to have at least have 'rough' consensus. Namely:
draft-openconfig-netmod-opstate-01: Sections 3, 4, 5.
    (note, which doesn't require specific convention-based or
protocol-based solution)
draft-openconfig-netmod-model-structure-00: Section 1.1
    (note, which does *not* include a requirement for /device)

> will subsequently put it into an email to the WG for final on-list

So should I/someone extract the mentioned section and send it to the
list now so that there's no ambiguity of what is being ased for folks to
agree to in the meeting?

Thanks,

Lou

PS The last time I tried to capture an issue on this list I was
basically told to write a requirements draft, now the answer is the
opposite...

---

From: Nadeau Thomas <[email-masked]>
Date: Thu, 10 Sep 2015 10:20:54 -0400

> On Sep 10, 2015:9:45 AM, at 9:45 AM, Lou Berger <[email-masked]> wrote:
> 
> Tom,
> 
> 

	That would be very helpful.  However, Kent/I agreed to keep a list
that we will put together (we could use your thread as the start) and push
that to the list after the meeting to which we will bring a call for
consensus on immediately.  The plan is to close on the requirements officially
ASAP.

	—Tom

---

From: Robert Wilton <[email-masked]>
Date: Thu, 10 Sep 2015 15:34:00 +0100

Hi Lou,

> draft-openconfig-netmod-opstate-01: Sections 3, 4, 5.
I was only reading sections 3 and 4 as listing requirements, and section 
5 as the preamble to a proposed solution.

Can you please clarify?

Thanks,
Rob

---

From: Kent Watsen <[email-masked]>
Date: Thu, 10 Sep 2015 14:46:02 +0000

[As co-chair]

To facilitate the meeting, following is a straw man list of requirements
based on what I've read.  Let's focus on refining this list during the
meeting.

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 for 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 aspects of operational state

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

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

    // this is a duplicate of # 3-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

Thanks,
Kent

---

From: Kent Watsen <[email-masked]>
Date: Thu, 10 Sep 2015 14:57:16 +0000

Typo:

- this is a duplicate of # 3-a
+ this is a duplicate of # 4-a

Kent

---

From: Kent Watsen <[email-masked]>
Date: Thu, 10 Sep 2015 16:51:17 +0000

Hi Anees,

I was hoping this was going to come up on the call, but since it didn't...

> hi -- some additional comments inline.  I think that the revisit on some of the operator requirements is primarily due to some proposed solution's inability to address them.

Can you elaborate on this?   Is it an "inability" to address them, or just that they don't address them currently?

Thanks,
Kent