Subject: Re: [Netconf] New WGLC for a proposed new WG Charter - respond BEFORE Sept 1st

From: Benoit Claise <[email-masked]>
Date: Wed, 05 Sep 2012 16:38:33 +0200

+ 1

Regards, Benoit.
> We had agreed in our last f2f meeting that people would submit
> individual I-Ds, and based on that we would potentially
> consider work in this space. So by all means do submit
> such individual drafts and discuss them on the mailing list.
>
> But we do not have a good problem statement or starting I-D
> to base this work on, so cannot put it on the current charter.
>
> Bert Wijnen
>
> On 8/17/12 11:04 AM, Ladislav Lhotka wrote:
>> Hi,
>>
>> I had the impression that there was a reasonable agreement that work 
>> on operational state data is needed. Although this problem lies 
>> somewhere between NETCONF and NETMOD, I think the NETCONF WG is now 
>> in a better position to start this work because apparently NETMOD WG 
>> will have to continue the work on the core data models for some time.
>>
>> So I propose the following fourth item for the charter:
>>
>> 4. The WG will investigate the relationship and interactions between 
>> configurations and
>>     operational state data, propose their appropriate representation 
>> and semantics, and
>>     devise methods for effective data modeling of both configurations 
>> and operational state data.
>>     It is expected that this work will be carried out in a close 
>> sooperation with the NETMOD WG.
>>
>> Lada
>>
>> "Bert Wijnen (IETF)" <[email-masked]> writes:
>>
>>> Based on the comments and feedback and the positions
>>> expressed on the mailing list, it is clear that after all
>>> we did NOT have consensus on the new WG charter.
>>>
>>> Without further ado, this is another proposed WG charter.
>>> It focuses on the things that we do seme to have agreement on.
>>>
>>> Pls comment and/or express your support or objections
>>> no later than August 31, 2012.
>>>
>>> OK, new chapter text (omitting the description of what we have
>>> achieved sofar):
>>>
>>>     In the current phase of the incremental development of NETCONF the
>>>     workgroup will focus on following items:
>>>
>>>     1. Advance NETCONF over TLS to be in-line with NETCONF 1:1.
>>>        This means that RFC5593 needs to be updated.
>>>
>>>     2. Based on the implementation, deployment experience and 
>>> interoperability
>>>        testing, the WG will document the status of NETCONF in a report.
>>>        Based on this, the WG may decide to make some clarifications to
>>>        RFC6241 and RFC6242 (then also fixing any reported errata).
>>>
>>>     3. Since Netconf over BEEP and over SOAP seem not being deployed
>>>        the WG will write a document that makes those 2 protocols
>>>        (RFC4743 and RFC4744) HISTORIC.
>>>
>>> Goals and Milestones:
>>>     done     - Send with-defaults to IESG for consideration as 
>>> Proposed Standard
>>>     done     - WG Last Call on rfc4741bis
>>>     done     - rfc4741bis to IESG for consideration as Proposed 
>>> Standard
>>>     done     - Send rfc4742bis to IESG for consideration as proposed 
>>> Standard.
>>>     done     - first WG draft (rev 00) on NACM posted
>>>     done     - first WG draft (rev 00) on NETCONF specific YANG 
>>> modules posted
>>>     done     - WGLC for NACM document
>>>     done     - WGLC for NETCONF specific notifications document
>>>     done     - submit NACM document to IESG for consideration as 
>>> Proposed Standard
>>>     done     - submit NETCONF specific notifications  document to 
>>> IESG for
>>>                consideration as Proposed Standard
>>>     Aug 2012 - submit initial WG draft for rfc5539bis
>>>     Aug 2012 - submit initial WG draft for making RFC4743 and 
>>> RFC4744 historic.
>>>     Sep 2012 - WGLC for rfc5539bis
>>>     Sep 2012 - WGLC for RFC4743 and 4743 to historic
>>>     Oct 2012 - submit rfc5539bis to AD/IESG for consideration as 
>>> Proposed Standard
>>>     Oct 2012 - submit request to AD/IESG to make RFC4743 and 4744 
>>> historic
>>>     Nov 2012 - Collect Implementation/Deployment reports for RFC6241 
>>> and 6242
>>>     Dec 2012 - Initial I-D for RFC6241/6242 
>>> implementation/deployment experience
>>>     Jan 2013 - WGLC on RFC6241/6242 implementation/deployment 
>>> experience
>>>     Feb 2013 - submit RFC6241/6242 implementation/deployment 
>>> experience doc
>>>                to IESG for publication as Informational RFC.
>>>     Mar 2013 - Evaluate if more work needs to be done by NETCONF WG 
>>> or close WG
>>>
>>> Bert and Mehmet
>>> _______________________________________________
>>> Netconf mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/netconf
>>
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>
>

---

From: Benoit Claise <[email-masked]>
Date: Wed, 05 Sep 2012 17:46:42 +0200

Andy,

I cut and pasted your answer into the right email thread, for readability:

    Andy> I hope we follow a process where we articulate and agree on
    the problems we are attempting to solve, instead of the usual
    "here's my solution draft, standardize it".

No disagreement here. For the people interested in writing a draft on 
the operational data (I believe I've seen some interest from Martin and 
Lada), that's a good advice: let's define the problem statement.

    Andy> We also learned a thing or 2 about operational state with MIBs
    over 20+ years and I hope we don't ignore that.  E.g., we have to
    pick our discontinuity timestamp, such as /system/clock/current-datetime.
    Some NETCONF systems have no SNMP agent, so sysUpTime
    is not appropriate. Also <get> returns everything. That was a mistake
    from the start. We could have <get2> return just config=false.  Simple.

    IMO the WG is looking for an ocean to boil wrt/ operational state,
    and ignoring the little details that could make a difference right away.

Personally, one problem I see is: a WG charter including a entry for 
management
They might look at NETCONF/YANG, but then the next question is: I have 
config data, but also operational state and counters. So is NETCONF/YANG 
suitable?

Regards, Benoit

>>>     devise methods for effective data modeling of both 
>>> configurations and operational state data.
>>>>     done     - Send rfc4742bis to IESG for consideration as 
>>>> proposed Standard.
>>>>     Nov 2012 - Collect Implementation/Deployment reports for 
>>>> RFC6241 and 6242

---

From: Andy Bierman <[email-masked]>
Date: Wed, 5 Sep 2012 09:03:40 -0700

On Wed, Sep 5, 2012 at 8:46 AM, Benoit Claise <[email-masked]> wrote:
> No disagreement here. For the people interested in writing a draft on the
> operational data (I believe I've seen some interest from Martin and Lada),
> that's a good advice: let's define the problem statement.
>

Companies are taking 2 different approaches (or a mix of both)
  - mixing config=false data nodes with config=true nodes and using <get>
  - creating custom RPC <get-foo> operations to provide specific data,
    often matching CLI show commands

IMO NETCONF can be even better than SNMP for monitoring,
depending on the application and data model.  SNMP has no
real filtering like subtree or XPath. (SNMP doesn't have real
sub-trees, it has data scattered all over).  If the INDEX gets big
(e.g., RMON2) then SNMP performance is awful, as the naming
is 90% of the data, duplicated in every varbind.

I don't think replacing standard monitoring MIBs with YANG modules
is worth doing, but I would not classify SNMP as good for monitoring,
and NETCONF as inappropriate for monitoring.

> Regards, Benoit

Andy

> I had the impression that there was a reasonable agreement that work on
> operational state data is needed. Although this problem lies somewhere
> between NETCONF and NETMOD, I think the NETCONF WG is now in a better
> position to start this work because apparently NETMOD WG will have to
> continue the work on the core data models for some time.
>
>     operational state data, propose their appropriate representation and
> semantics, and
>     devise methods for effective data modeling of both configurations and
> operational state data.
>     It is expected that this work will be carried out in a close sooperation
> with the NETMOD WG.
>
> Lada
>
>     done     - Send with-defaults to IESG for consideration as Proposed
> Standard
>     done     - rfc4741bis to IESG for consideration as Proposed Standard
>     done     - first WG draft (rev 00) on NETCONF specific YANG modules
> posted
>     done     - submit NACM document to IESG for consideration as Proposed
> Standard
>     done     - submit NETCONF specific notifications  document to IESG for
>     Aug 2012 - submit initial WG draft for making RFC4743 and RFC4744
> historic.
>     Oct 2012 - submit rfc5539bis to AD/IESG for consideration as Proposed
> Standard
>     Oct 2012 - submit request to AD/IESG to make RFC4743 and 4744 historic
>     Nov 2012 - Collect Implementation/Deployment reports for RFC6241 and
> 6242
>     Dec 2012 - Initial I-D for RFC6241/6242 implementation/deployment
> experience
>     Jan 2013 - WGLC on RFC6241/6242 implementation/deployment experience
>     Feb 2013 - submit RFC6241/6242 implementation/deployment experience doc
>     Mar 2013 - Evaluate if more work needs to be done by NETCONF WG or close
> WG
>
> Bert and Mehmet

---

From: "Patrick Gili (pgili)" <[email-masked]>
Date: Wed, 5 Sep 2012 16:10:07 +0000

Benoit,

I fully support Andy's sentiments regarding NETCONF+YANG. I think it is fully capable of dealing with both configuration and operational data. However, the one point that I don't necessarily agree with his statement, "I don't think replacing standard monitoring MIBs with YANG modules is worth doing, but I would not classify SNMP as good for monitoring, and NETCONF as inappropriate for monitoring." We're receiving quite a different message from customers--in fact, we have customers expressing a desire to abandon everything for NETCONF, including syslog, SNMP, RADIUS, DHCP, RADIUS, and other protocols used today for the exchange of data.

Patrick

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Andy Bierman
Sent: Wednesday, September 05, 2012 12:04 PM
To: Benoit Claise (bclaise)
Cc: netconf
Subject: Re: [Netconf] Operational State: Re: New WGLC for a proposed new WG Charter - respond BEFORE Sept 1st

On Wed, Sep 5, 2012 at 8:46 AM, Benoit Claise <[email-masked]> wrote:
> the problems we are attempting to solve, instead of the usual "here's 
> my solution draft, standardize it".
>
> the operational data (I believe I've seen some interest from Martin 
> and Lada), that's a good advice: let's define the problem statement.
>
> over 20+ years and I hope we don't ignore that.  E.g., we have to pick 
> our discontinuity timestamp, such as /system/clock/current-datetime.
> Some NETCONF systems have no SNMP agent, so sysUpTime is not 
> appropriate. Also <get> returns everything. That was a mistake from 
> the start. We could have <get2> return just config=false.  Simple.
>
> IMO the WG is looking for an ocean to boil wrt/ operational state, and 
> ignoring the little details that could make a difference right away.
>
>
> management They might look at NETCONF/YANG, but then the next question 
> is: I have config data, but also operational state and counters. So is 
> NETCONF/YANG suitable?

IMO NETCONF can be even better than SNMP for monitoring, depending on the application and data model.  SNMP has no real filtering like subtree or XPath. (SNMP doesn't have real sub-trees, it has data scattered all over).  If the INDEX gets big (e.g., RMON2) then SNMP performance is awful, as the naming is 90% of the data, duplicated in every varbind.

I don't think replacing standard monitoring MIBs with YANG modules is worth doing, but I would not classify SNMP as good for monitoring, and NETCONF as inappropriate for monitoring.

Andy

> individual I-Ds, and based on that we would potentially consider work 
> in this space. So by all means do submit such individual drafts and 
> discuss them on the mailing list.
>
> But we do not have a good problem statement or starting I-D to base 
> this work on, so cannot put it on the current charter.
>
> Bert Wijnen
>
> somewhere between NETCONF and NETMOD, I think the NETCONF WG is now in 
> a better position to start this work because apparently NETMOD WG will 
> have to continue the work on the core data models for some time.
>
> Based on the comments and feedback and the positions expressed on the 
> mailing list, it is clear that after all we did NOT have consensus on 
> the new WG charter.
>
> Pls comment and/or express your support or objections no later than 
> August 31, 2012.
>
> and
>     Mar 2013 - Evaluate if more work needs to be done by NETCONF WG or 
> close WG
>
> Bert and Mehmet

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 5 Sep 2012 18:28:32 +0200

> IMO NETCONF can be even better than SNMP for monitoring, depending on
> the application and data model.  SNMP has no real filtering like
subtree
> or XPath. (SNMP doesn't have real sub-trees, it has data scattered all
> over).  If the INDEX gets big (e.g., RMON2) then SNMP performance is
> awful, as the naming is 90% of the data, duplicated in every varbind.
> 
> I don't think replacing standard monitoring MIBs with YANG modules is
> worth doing, but I would not classify SNMP as good for monitoring, and
> NETCONF as inappropriate for monitoring.
> 

Do we have information that can help us to compare performance for
retrieving monitoring information (and we need to be more specific here
- are we talking about large tables of counters, or something else?)
using the two protocols? The fact that SNMP is not efficient because of
the indexation scheme is not relevant, what is important is how it
compares on the wire with fetching the same amount of information using
NETCONF/YANG. 

Dan

---

From: "Alexander Clemm (alex)" <[email-masked]>
Date: Wed, 5 Sep 2012 17:28:41 +0000

+1 on the <get2>

One advantage in the context of Netconf/Yang vs SNMP is the inherent support for scoping.
For monitoring, I do think there are some additional requirements to consider that limit Netconf's (but not Yang's) appeal in certain scenarios, e.g. in managed service provider scenarios the requirement to maintain an association and have it initiated from the manager

--- Alex

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Andy Bierman
Sent: Wednesday, September 05, 2012 9:04 AM
To: Benoit Claise (bclaise)
Cc: netconf
Subject: Re: [Netconf] Operational State: Re: New WGLC for a proposed new WG Charter - respond BEFORE Sept 1st

Andy

---

From: Andy Bierman <[email-masked]>
Date: Wed, 5 Sep 2012 11:12:03 -0700

Interesting data point.

I meant that the SMI2YANG conversion of most MIB modules
is good enough, and a standards effort to rewrite them would take
too long.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 5 Sep 2012 20:40:24 +0200

> compares on the wire with fetching the same amount of information using

While such performance considerations are highly relevant in some
context, there are lots of contexts where the time to implement a
robust management solution is key, not just the on the wire efficiency.

That said, there have been academic studies comparing SNMP with
alternatives and the common pattern was that SNMP is always winning
for regular infrequent polls for little amounts of information while
it tends to loose on larger data transfers. A starting point to dig
into this is this survey.

@Article{AFLPS09,
  author =       "L. Andrey and O. Festor and A. Lahmadi and A. Pras and
                 J. Sch{\"o}nw{\"a}lder",
  title =        "{Survey of SNMP Performance Analysis Studies}",
  journal =      "International Journal of Network Management",
  volume =       "19",
  number =       "6",
  pages =        "527--548",
  publisher =    "Wiley",
  year =         "2009",
}

Of course, published in 2009, it does not cover newer papers on this
topic.

But once again, the efficiency with which one can build robust
applications is in certain environments more important than just the
plain on the wire efficiency.

/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: Ladislav Lhotka <[email-masked]>
Date: Wed, 5 Sep 2012 21:09:54 +0200

On Sep 5, 2012, at 5:46 PM, Benoit Claise <[email-masked]> wrote:

> No disagreement here. For the people interested in writing a draft on the operational data (I believe I've seen some interest from Martin and Lada), that's a good advice: let's define the problem statement.
> Personally, one problem I see is: a WG charter including a entry for management
> They might look at NETCONF/YANG, but then the next question is: I have config data, but also operational state and counters. So is NETCONF/YANG suitable?

Right, and it is also the problem statement you are asking for: The existing NETMOD core modules do not model, for the most part, operational state data, mainly because there is no easy way to do so with the existing YANG semantics.

For one, there has has to be a way for finding out, via NETCONF, IP addresses that are in operational use on an interface.  

Lada

>>>> I had the impression that there was a reasonable agreement that work on operational state data is needed. Although this problem lies somewhere between NETCONF and NETMOD, I think the NETCONF WG is now in a better position to start this work because apparently NETMOD WG will have to continue the work on the core data models for some time. 
>>>> 
>>>> 4. The WG will investigate the relationship and interactions between configurations and 
>>>>     operational state data, propose their appropriate representation and semantics, and 
>>>>     devise methods for effective data modeling of both configurations and operational state data. 
>>>>     It is expected that this work will be carried out in a close sooperation with the NETMOD WG. 
>>>> 
>>>> Lada 
>>>> 
>>>>>     2. Based on the implementation, deployment experience and interoperability 
>>>>>     done     - Send with-defaults to IESG for consideration as Proposed Standard 
>>>>>     done     - Send rfc4742bis to IESG for consideration as proposed Standard. 
>>>>>     done     - first WG draft (rev 00) on NETCONF specific YANG modules posted 
>>>>>     done     - submit NACM document to IESG for consideration as Proposed Standard 
>>>>>     Aug 2012 - submit initial WG draft for making RFC4743 and RFC4744 historic. 
>>>>>     Oct 2012 - submit rfc5539bis to AD/IESG for consideration as Proposed Standard 
>>>>>     Nov 2012 - Collect Implementation/Deployment reports for RFC6241 and 6242 
>>>>>     Dec 2012 - Initial I-D for RFC6241/6242 implementation/deployment experience 
>>>>>     Mar 2013 - Evaluate if more work needs to be done by NETCONF WG or close WG 
>>>>> 
>>>>> Bert and Mehmet 

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

---

From: Andy Bierman <[email-masked]>
Date: Wed, 5 Sep 2012 12:17:49 -0700

> For one, there has has to be a way for finding out, via NETCONF, IP addresses that are in operational use on an interface.

Why can't you just write a YANG list for that, or add a config=false
boolean leaf 'operational-use' to the config list?

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 06 Sep 2012 09:12:28 +0200

> boolean leaf 'operational-use' to the config list?

You can, but then you have some addresses in the configuration and some addresses in state data and the data model doesn't give you any information about how they are related, except perhaps in descriptions.

It is often the case that data nodes appear in pairs - once as configuration and once as state data, and these two may or may not be the same, depending on other circumstances. We could indeed model such a pair as two separate nodes, one being config=true and the other config=false, but then the data model would (i) get clumsy, and (ii) fail to communicate the important fact that the two nodes are closely related.

Lada