Re: Management Requirements

Hi Adrian,

Thanks for your feedback.
>
> Hi Benoit,
>
> This is a reasonable start, but does omit the whole "information 
> model" thing.
>
I'm not sure how we could have some sort of data models consistency 
without a common information model.
>
> 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.
>
I'll investigate if this is the case...
>
> (Yes, that gives the YANG module an unfair advantage).
>
That would be nice.
>
> BTW, I really wish we didn't always write "NETCONF/YANG". They are 
> separate entities and one could use one without the other.
>
What was meant is: define your data model in YANG, and manage your boxes 
with the NETCONF protocol

Regards, Benoit.
>
> 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]  <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