Subject: Re: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-snmp-cfg-00

From: "Andy Bierman" <[email-masked]>
Date: Wed, 20 Oct 2010 13:19:30 -0700

SNMP is configured via CLI,
and the config is simple and rather limited in scope.  A standard that forced us to implement lots more SNMP config knobs is not a priority.

----- Reply message -----
From: "Juergen Schoenwaelder" <[email-masked]>
Date: Wed, Oct 20, 2010 13:06
Subject: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-snmp-cfg-00
To: "Andy Bierman" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>

On Wed, Oct 20, 2010 at 10:37:59AM -0700, Andy Bierman wrote:

> I don't agree that the IETF needs to provide NETCONF write access to any SNMP data.
> These objects have been available in SNMP.  If they were that important,
> they would be implemented by now.
> 
> I suppose if people want to implement this as a standard they should
> work on this draft.  

Give me a honest answer: How do you configure your SNMP agent? Via
SNMPv3 sets or via a CLI or config file? Shall we ask operators?

/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/>
_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 20 Oct 2010 22:45:11 +0200

On Wed, Oct 20, 2010 at 01:19:30PM -0700, Andy Bierman wrote:

> SNMP is configured via CLI, and the config is simple and rather
> limited in scope.

So you are saying there is no need for NETCONF since there is always a
proprietary CLI that does the job. Interesting late insights?

> A standard that forced us to implement lots more SNMP config knobs
> is not a priority.

We do not claim this is a priority work item. I personally would
appreciate to see more YANG data models popping up in individual IDs.
But perhaps this is not welcome by everyone.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 20 Oct 2010 22:47:51 +0200 (CEST)

"Andy Bierman" <[email-masked]> wrote:
> and the config is simple and rather limited in scope.  A standard that forced
> us to implement lots more SNMP config knobs is not a priority.

FWIW, some rather big router vendors do support more or less full SNMP
config (like the one presented in this draft) via their CLIs.

And you are not forced to implement this ;-)

/martin

---

From: Andy Bierman <[email-masked]>
Date: Wed, 20 Oct 2010 14:24:54 -0700

Hi,

I think NETCONF configuration of the SNMP agent is a low priority for my company.
Besides configuring community strings, there is not much we need to support.
This represents a few CLI commands out of 1000s.

The small number of knobs we currently need to support SNMP Get operations are
already done, and this limited configurability is not holding back any of our
NMS developers.  

The tradition in the IETF is to let people have their sandbox, so if others
want to work on this, then that's great.  We don't have to agree on the
relative priority.  The IESG needs to worry about enough resources, proper review,
etc., but that's not usually a problem.

Looking forward, the operational data that SNMP provides is going to become
NETCONF data (via your SMIv2 mapping or N proprietary mappings), so the
SNMP agent is going to be less and less important over time.

I agree that configuring the SNMP agent is a self-contained problem,
and knowing how well NETCONF/YANG addresses self-contained modeling problems
is useful to know.  To that end, I would prefer configuring NTP or OSPF
as an exercise, rather than baggage-laden SNMP.

Andy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
Sent: Wednesday, October 20, 2010 1:45 PM
To: Andy Bierman
Cc: Andy Bierman; [email-masked]
Subject: Re: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-snmp-cfg-00

/js

---

From: "David Harrington" <[email-masked]>
Date: Thu, 21 Oct 2010 11:30:54 -0400

Hi,

So the operators explained that one of the major problems with the MIB
approach is that the MIB data models did not allow configuring
**everything** on a target device, whereas CLI gave them access to
everything.

If YANG modeling is going to be more useful than MIB modeling, it has
a long way to go to make everything on the box configurable using
Netconf. Certainly some things might be more important than others,
but I am with Juergen that individual YANG models are better than
none. 

If you want to prioritize IETF efforts at standardizing YANG models,
then it would be wise to focus on widely-deployed IETF standard
technologies that operators find fairly complex to configure. SNMP is
one of the IETF standards that fit that description. Of course, many
deployments of widely-deployed IETF technolgies are based on toolkits
or licensed stacks, so convincing the toolkit producers to support
configuration using Netconif and YANG will be fairly important to
encouraging Netconf/YANG deployment. Some of the major SNMP toolkit
vendors are actively participating in, or actively monitoring the
progress of, YANG so the SNMP toolkit environment might be a pretty
good priority. 

If you attend NANOG, a tremendous amount of discussion is about
routing protocols like BGP, so that would also be a reasonable
priority. Are the leading vendors of routing stacks active in netmod? 

dbh

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
> Sent: Wednesday, October 20, 2010 4:45 PM
> To: Andy Bierman

---

From: Andy Bierman <[email-masked]>
Date: Thu, 21 Oct 2010 10:34:57 -0700

Hi,

I recall that the operators present at that meeting almost 10 years ago did not
even agree all the time, or about all the details.

Getting 'CLI access to everything' vs. 'NETCONF access to everything'
is an implementation detail.  In the end, this is becomes a business
decision by each vendor.

There will never be a data model that has both sufficient scope and
WG consensus as a complete solution -- ever.  The problem is that
product differentiation will always get in the way.

The success of standard data models depends mostly on the ability of
individual vendors to integrate the standard with their own
proprietary models.  Unlike multiple readers, supporting multiple
writers (i.e., more than 1 config=true object for the same knob)
requires real work and planning.

But we keep insisting (for 20 years now) that the only thing that matters
is the quality of the content written by the IETF.  Complete solutions only,
even if that makes implementation for vendors difficult or impractical.
Even if it takes many years to complete the standard.

XML makes it easy to combine content from multiple namespaces into a single
retrieval or edit operation.  Unlike SMIv2 OIDs, the identifier for a NETCONF
database node has semantics (the node's ancestors).  It is easy to get
everything related to a particular protocol or service in 1 operation,
without knowing a priori every 'place' to look for related data.
The line between vendor data and standard data gets blurred.

The biggest problem facing a meaningful standards effort is time.
A vendor can knock out a data model in a few months.  The same
effort takes 2 - 3 years in the IETF.  This is just a non-starter
from a business POV.  Waiting for the RFC to come out is not
an option.  Adding the standard later is the most likely option,
and it is much harder to do that for writable objects than read-only
objects.

The NETMOD WG already agreed on 3 areas for new work:
   - system
   - interfaces
   - routing

That is why I think we need to get a simple framework done in 4 - 6 months.
    1) The SNMP system group as starting point
    2) interface table has only 'name' and 'ifIndex' (maybe a few more
       details ala IF-STACK-MIB)
    3) A routing framework data model (and maybe protocol-specific modules
       if writers and reviewers are available)

Andy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of David Harrington
Sent: Thursday, October 21, 2010 8:31 AM
To: 'Juergen Schoenwaelder'; 'Andy Bierman'
Cc: Andy Bierman; [email-masked]
Subject: Re: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-snmp-cfg-00

Hi,

dbh

---

From: Phil Shafer <[email-masked]>
Date: Thu, 21 Oct 2010 13:46:36 -0400

>**everything** on a target device, whereas CLI gave them access to

With NETCONF/YANG, the argument is a little different.  So let's
say I want to make an application to configure PWE tunnels thru my
network, and the standard defines 80% of what I need.  If I can use
NETCONF to access non-YANG-modeled data or proprietary YANG-modeled
data to get the other 20%, then I'm happy.  If I need to resort to
screen scraping to get to data, then I might as well use the screen
scraping method to get the whole kit-n-kaboodle.

>but I am with Juergen that individual YANG models are better than

With NETCONF/YANG we have built a smaller hill, since the only
requirement is that the device expose all configuration via NETCONF,
which is required to have a functional NETCONF implementation.

Once that burden has been met, it works as an "escape hatch" for
data that is not YANG'd yet.  SNMP had no such mechanism, so the
fall back was screen scraping.

>one of the IETF standards that fit that description.

I've written some words recently about when automation is a win.
Here's a snippet:

-------

* Conditions for Automation

We've looked at a number of on-box features that make automation more
robust and reliable.  Let's look briefly at when automation can pay
maximum dividends.  When is automation and flow-through provisioning an
appropriate solution?  There are four qualities that a problem must
have to be a good candidate:

- complexity -- Is is a hard problem?
- frequency -- Do changes happen often?
- importance -- Will failures matter?
- scale -- Is the rate of change relatively high?

If the answer to these four is "yes", then the problem is a good
candidate and the cost of using automation will be paid for by the
increase in the robustness, ease of use, certainty, assurance, and
scaling that automation can provide.

A change that's needed once a year on ten boxes is likely not a
candidate, but one made once a month on a thousand boxes would be.  If
changes are complex, where a minor mistake is hard to diagnose, and it
has an impact on customer SLAs or has been a significant source of
network outages, the problem would be important enough to target for
automation.

The details of the formula may vary by provider, but the basic idea is
that went the cost of getting it wrong exceeds the cost of doing it
right, the right way should win.  Automation can provide concrete
benefits to network stability, customer satisfaction, and employee
productivity.

-------

So to my mind, SNMP does not hit any of these thresholds.  PWs
or BGPVPNs hit them all, so I think those are the problem
domains that will let YANG models shine.  If we could become
the standard configuration mechanism for "hot" technologies
like this, then we'll be livin' the dream.

>priority. Are the leading vendors of routing stacks active in netmod? 

BGP doesn't have the change rate that would make automation give a
reasonable yield.  On the other hand, BGP is well understood and
widely deployed, so perhaps as a "technology demonstration" it
would make sense.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Thu, 21 Oct 2010 11:31:10 -0700

Hi Phil,

Your Conditions for Automation is excellent.
Can we get it on the NETCONF Wiki?
It would really help to remind people of the use cases.

Only the 'interfaces' work item meets your criteria.

The 'commonality' factor is independent of the automation factors.
Every protocol/service that has per-interface config is going to need
to identify the interface.  We cannot have more than 1 way to do this
in the standard.  We cannot leave it as a vendor detail.

IMO, NACM is a critical component related to your 'is it important' point.
Is it important to prevent malicious and/or unintended alteration of the
configuration?  Depends on the network, but generally this is important.

In order for NACM to be deployed, the standardization of 'users' must also
be done.  I think Juergen is right about putting that in its own document,
instead of NACM.  This is important config, even if NACM is not supported.

IMO, the 2 most valuable config modules would be bare-interfaces and
user login authentication.

Andy

-----Original Message-----
From: Phil Shafer [mailto:[email-masked]] 
Sent: Thursday, October 21, 2010 10:47 AM
To: David Harrington
Cc: 'Juergen Schoenwaelder'; 'Andy Bierman'; Andy Bierman; [email-masked]
Subject: Re: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-snmp-cfg-00 

-------

-------

Thanks,
 Phil

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 21 Oct 2010 20:44:08 +0200

> widely deployed, so perhaps as a "technology demonstration" it

Martin and I never claimed SNMP config is important. Initially, we
started looking at it because this is the only technology I am aware
of where the IETF has a standard configuration model. This made this
excercise easier for us than dealing with say BGP VPNs. (And we also
happen to understand SNMP config better than BGP VPN config. ;-)

I believe we need technology demonstrations. The more the better. 
In my view, we should _encourage_ people to post YANG technology
demonstrations as individual IDs for whatever configuration model
they are familiar with.

/js