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

Andy Bierman <biermana@Brocade.com> Thu, 21 October 2010 17:33 UTC

Return-Path: <biermana@Brocade.com>
X-Original-To: netmod@core3.amsl.com
Delivered-To: netmod@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFBE63A6A81 for <netmod@core3.amsl.com>; Thu, 21 Oct 2010 10:33:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.785
X-Spam-Level:
X-Spam-Status: No, score=-1.785 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_64=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5YN0pMtCKI4r for <netmod@core3.amsl.com>; Thu, 21 Oct 2010 10:33:29 -0700 (PDT)
Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [67.231.144.122]) by core3.amsl.com (Postfix) with ESMTP id 2B8D43A6A7C for <netmod@ietf.org>; Thu, 21 Oct 2010 10:33:29 -0700 (PDT)
Received: from pps.filterd (m0000542 [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.4/8.14.4) with SMTP id o9LHVY6E001117; Thu, 21 Oct 2010 10:35:04 -0700
Received: from hq1-exedge.brocade.com (hq1-exedge.brocade.com [144.49.141.11]) by mx0a-000f0801.pphosted.com with ESMTP id s2sd6r0jd-2 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 21 Oct 2010 10:35:03 -0700
Received: from HQ1WP-EXHUB01.corp.brocade.com (10.70.36.14) by HQ1WP-EXEDGE02.corp.brocade.com (144.49.141.11) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 21 Oct 2010 10:39:21 -0700
Received: from HQ1-EXCH01.corp.brocade.com ([fe80::ed42:173e:fe7d:d0a6]) by HQ1WP-EXHUB01.corp.brocade.com ([::1]) with mapi; Thu, 21 Oct 2010 10:35:02 -0700
From: Andy Bierman <biermana@Brocade.com>
To: David Harrington <ietfdbh@comcast.net>, 'Juergen Schoenwaelder' <j.schoenwaelder@jacobs-university.de>
Date: Thu, 21 Oct 2010 10:34:57 -0700
Thread-Topic: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-snmp-cfg-00
Thread-Index: Actwl8qASxlCijNvSdO/VjdG9t+C5gAmfRKgAAPl0vA=
Message-ID: <B11AB91666F22D498EEC66410EB3D3C4F412BEC771@HQ1-EXCH01.corp.brocade.com>
References: <DC.BB.11475.2CE4FBC4@cm-omr7> <20101020204511.GA24577@elstar.local> <D9517EE782D0430980284B65E0487973@23FX1C1>
In-Reply-To: <D9517EE782D0430980284B65E0487973@23FX1C1>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2010-10-21_08:2010-10-21, 2010-10-21, 1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=5 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1004200000 definitions=main-1010210129
X-Proofpoint-SSN: Sensitivity2
Cc: "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-snmp-cfg-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Oct 2010 17:33:31 -0000

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: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf Of David Harrington
Sent: Thursday, October 21, 2010 8:31 AM
To: 'Juergen Schoenwaelder'; 'Andy Bierman'
Cc: Andy Bierman; netmod@ietf.org
Subject: Re: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-snmp-cfg-00

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

> -----Original Message-----
> From: netmod-bounces@ietf.org 
> [mailto:netmod-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder
> Sent: Wednesday, October 20, 2010 4:45 PM
> To: Andy Bierman
> Cc: Andy Bierman; netmod@ietf.org
> Subject: Re: [netmod] Fw: New Version Notification for 
> draft-bjorklund-netmod-snmp-cfg-00
> 
> 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
> 
> -- 
> 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
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod