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

The point Martin made about relating the SNMP Model with the YANG based one is important.  The issue is, at least in the SNMP universe, interface naming is not static/stable and not always predictable.  This has always been an issue for management applications even when not attempting to map to an alternate name space such as YANG so mapping counters for an interface with it's YANG based configuration information could be problematic.  Beyond this, most management systems will not keep the core data in either model (SNMP or YANG) they will have an internal data base that is based on their own internal model.  It is not clear to me based on applications I know that this extra mapping is all that helpful since it will have to be redone in the management software application.
/jon
On Oct 22, 2010, at 11:55 AM, Andy Bierman wrote:

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