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

Andy Bierman <biermana@Brocade.com> Fri, 22 October 2010 15:53 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 83C463A68A8 for <netmod@core3.amsl.com>; Fri, 22 Oct 2010 08:53:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.103
X-Spam-Level:
X-Spam-Status: No, score=-2.103 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334]
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 1al5cVO+9A3e for <netmod@core3.amsl.com>; Fri, 22 Oct 2010 08:53:46 -0700 (PDT)
Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [67.231.144.122]) by core3.amsl.com (Postfix) with ESMTP id 98D583A6897 for <netmod@ietf.org>; Fri, 22 Oct 2010 08:53:46 -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 o9MFljp7024117; Fri, 22 Oct 2010 08:55:20 -0700
Received: from hq1-exedge.brocade.com (hq1-exedge.brocade.com [144.49.141.11]) by mx0a-000f0801.pphosted.com with ESMTP id s3cp300xk-22 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 22 Oct 2010 08:55:20 -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; Fri, 22 Oct 2010 08:59:20 -0700
Received: from HQ1-EXCH01.corp.brocade.com ([fe80::ed42:173e:fe7d:d0a6]) by HQ1WP-EXHUB01.corp.brocade.com ([::1]) with mapi; Fri, 22 Oct 2010 08:55:01 -0700
From: Andy Bierman <biermana@Brocade.com>
To: Martin Bjorklund <mbj@tail-f.com>, "netmod@ietf.org" <netmod@ietf.org>, "spakes@snmp.com" <spakes@snmp.com>
Date: Fri, 22 Oct 2010 08:55:00 -0700
Thread-Topic: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-snmp-cfg-00
Thread-Index: ActxyRIjfFjW6EPOQCii7zPfyMMrAQANDfoQ
Message-ID: <B11AB91666F22D498EEC66410EB3D3C4F412BEC7F0@HQ1-EXCH01.corp.brocade.com>
References: <sdd3r3se5r.fsf@wjh.hardakers.net> <4CC09A7C.6020506@andybierman.com> <Pine.GSU.4.58.1010211717010.1644@adminfs> <20101022.111104.235838872.mbj@tail-f.com>
In-Reply-To: <20101022.111104.235838872.mbj@tail-f.com>
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-22_09:2010-10-22, 2010-10-22, 1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=1 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1004200000 definitions=main-1010220103
X-Proofpoint-SSN: Sensitivity2
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: Fri, 22 Oct 2010 15:53:47 -0000

Hi,

I agree with Martin.
There should be a new interfaces table that contains a mapping to ifIndex
so monitoring MIBs like RMON-MIB can be used with SNMP, even though the
config may be done through NETCONF.  RMON is an example that supports complete
self-configuration through SNMP, but vendors has decided to configure it through
CLI anyway.

To understand the framework, we have to understand (at least) how an individual
feature would be realized within that framework.

Some requirements (IMO):
  1) Ability to support easy to use YANG module for any service or feature.
     Global and per-interface inter-related components are the norm.
     This must be clear in the data model.
  2) Ability to continue retrieving interface-related operational data with SNMP
  3) Ability to also retrieve operational data with NETCONF
     - mapping algorithm automatically translates any SMIv2 read-only
       OBJECT-TYPE macro into functionally equivalent YANG module, such that
       predictable top-level YANG data nodes, suitable for <get> retrieval,
       are defined.
  4) Ability to let vendors continue using their own interface identification strings
     - Provide optional YANG extension to let vendors describe identifier string components
  5) Ability to identify/configure parent and child interface relationships, 
     if there is some hierarchy within the interfaces. 
     - other interface relationships such as hot-standby, load-balancing, trunking 
       should also be supported
  6) Ability to pre-provision interfaces which are not currently present.
  7) Ability to enable or disable an interface
  8) Ability to move child nodes from one interface to another
     (e.g., move a service, replicate a service, line-card changes slot)


Andy

-----Original Message-----
From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf Of Martin Bjorklund
Sent: Friday, October 22, 2010 2:11 AM
To: netmod@ietf.org; spakes@snmp.com
Subject: Re: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-snmp-cfg-00

Hi,

David Spakes <spakes@snmp.com> wrote:
> At the very least, the working group should
> produce a document that is the YANG equivalent to RFC 2863.  IMHO,
> it should exactly mirror the existing objects, at least the ones
> that are not deprecated.

I disagree.  If all we do is put YANG syntax around existing MIB
objects, we haven't achieved anything.  We should concentrate on
interface configuration.  It is not important to duplicate all
interface counters etc.  One thing that *is* important though is how a
YANG interface configuration model relates to the MIB.  (For example, 
how the interface name maps to ifIndex.)


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