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

[Andy Bierman <[e-mail]>]

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:[e-mail]] 
Sent: Thursday, October 21, 2010 10:47 AM
To: David Harrington
Cc: 'Juergen Schoenwaelder'; 'Andy Bierman'; Andy Bierman; [e-mail]
Subject: Re: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-snmp-cfg-00 

"David Harrington" writes:
>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.

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.

>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. 

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.

>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.

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.

>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? 

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