Re: 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