Re: Management Requirements

Hi Benoit, 
 
This is a reasonable start, but does omit the whole "information model" thing.
I confess to finding UML diagrams not very useful. I prefer an information model
written in some form of semi-formal language. I am wondering whether YANG isn't
exactly that language. (Yes, that gives the YANG module an unfair advantage).
 
BTW, I really wish we didn't always write "NETCONF/YANG". They are separate
entities and one could use one without the other.
 
Cheers,
Adrian
 
From: [email protected] [mailto:[email protected]] On Behalf Of
Benoit Claise
Sent: 09 August 2012 14:55
To: Ronald Bonica
Cc: [email protected]; [email protected]; [email protected]
Subject: Re: [OPS-AREA] Management Requirements
 
Ron,

I read the entire email thread. So let me reply to this email with information
from different participants

I agree with Dan that there are two problems.
1. a set of guidance on how a WG (any WG, not only BEHAVE) should choose among
various protocols'
2. what to do specifically in the BEHAVE case

Let me focus on 1., it's time to update RFC1052, as Dan and Tom explained during
the OPS-AREA meeting
We should set the guidance for the entire community.
The fact that there are not many YANG modules today shouldn't play against
NETCONF/YANG. The guidance could still be: if you want to do configuration,
YANG/NETCONF is the way to go
What we need is a flowchart type of things, to make it very easy for non-OPS
group to follow
As an example :
- Document the operational requirements, and what information needs to be
configured/monitored/preserved. Ideally, use an information model language (see
the previous thread)
- Is there an existing data models you want to extend. If yes, extend it 
- Configuration? Use NETCONF/YANG
       no configuration now: do you plan on having configuration in the future?
       if "yes", investigate NETCONF/YANG
       if "maybe", use an information model language (see the previous thread) 
- Operational data? 
    If there is a MIB, feel free to extend it?
    If there is no MIB module so far, insert the operational data in the YANG
module
- you want to push some data at a high rate ? Investigate IPFIX
- you want some events
        if you have a MIB module, evaluate the SNMP notification
        if you have a YANG modue, evaluate the YANG notification
        if you want plain english text events, evaluate syslog
        if you want some structured events, evaluate syslog SDE
- etc...

Note: obviously, when comparing technologies, the pros/cons must be explained.

It's true that RFC 5706 and RFC 6632 will help, but we should really set some
guidance between the different OPS architectures.

This exercise will certainly require some discussions with the couple of first
requests, to make sure we document everything. So that's maybe what we should do
in the BEHAVE case: have a live discussion.

Regards, Benoit.
Folks,
 
The BEHAVE WG brings us a concrete example of a problem that we discussed in
Vancouver. According to their charter, the BEHAVE WG "creates documents to
enable IPv4/IPv4 and IPv6/IPv4 NATs to function in as deterministic a fashion as
possible." Also, according to their charter, the BEHAVE WG "will update the NAT
MIB (RFC 4008) to be
consistent with the management aspects of its IPv6/IPv4 NAT solutions, and
specify IPFIX information elements to meet logging requirements, reusing
existing elements, if possible."
 
Now BEHAVE is asking whether SNMP and IPFIX are the right tools. Maybe NETCONF
is the right tool for configuration? Maybe SNMP is right for fault monitoring?
Maybe syslog is right for maintaining a record of address mappings? Who knows?
 
My best guess follows......
 
- The BEHAVE WG knows what information needs to be
configured/monitored/preserved. They MUST specify that.
- The BEHAVE WG and the OPS Area have an equal stake in determining which tool
is recommended to manage each type of data. They should work together to make a
recommendation. In the best of all possible worlds, that decision would be
informed by a well-documented guideline. However, in the world that we inhabit,
that decision may need to be facilitated by a conversation.
- The BEHAVE WG MUST produce protocol-specific data models (SMI, YANG) for the
recommended protocols
- The BEHAVE WG MAY produce protocol-specific data models (SMI, YANG) for the
non-recommended protocols
 
Comments?
 
                                              Ron
 
 
 
_______________________________________________
OPS-AREA mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ops-area

_______________________________________________
OPS-AREA mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ops-area