Re: Management Requirements

Benoit,

IMHO, our first priority should be to provide concrete guidance to BEHAVE. The BEHAVE WG will become grumpy if we ask them to wait while OPS debates abstractions.

Our second priority should be to issue general guidance to WGs. Guidance should answer the following questions:


-          Does the WG need model managed data?

-          Can managed data be divided into categories? If so, how? (Configuration versus operational state?  candidate versus current versus previous state? Data that is sampled versus data that is retained completely? Data that must be retained versus data that can be lost?)

-          What protocol does the IETF recommend for each category?

-          Does the IETF recommendation give implementers latitude to use a protocol other than that which is recommended? How much latitude?

-          How should data be modeled? Using an abstract notation or a protocol specific notation?

Comments?

                    Ron


From: Benoit Claise [mailto:[email protected]]
Sent: Thursday, August 09, 2012 9:55 AM
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]<mailto:[email protected]>

https://www.ietf.org/mailman/listinfo/ops-area

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