Re: OPSAREA strategy

Romascanu, Dan (Dan) wrote:
>  
> 
>> -----Original Message-----
>> From: [email protected] 
>> [mailto:[email protected]] On Behalf Of Andy Bierman
>> Sent: Thursday, December 03, 2009 7:52 PM
>> To: David Harrington
>> Cc: 'OPS Area (E-mail)'
>> Subject: Re: [OPS-AREA] OPSAREA strategy
>>
>> David Harrington wrote:
>>> Agreed.
>>>
>>> Some operators told us there was a disconnect.
>>> So we deliberately sought feedback from a wide range of 
>> operators and 
>>> found agreement there was a disconnect.
>>> And we are moving to a multi-protocol approach because 
>> operators told 
>>> us there was a disconnect.
>>> We also got some suggestions about how to proceed to close the gap 
>>> between operators' needs and IETF NM solutions.
>>> But the operators haven't come home yet ...
>>>
>>> The IETF is now faced with a problem. We now have multiple 
>> protocols, 
>>> and most defined their own information models, data 
>> modeling language 
>>> and data models, and we are not sure how to correlate information 
>>> available from different protocols. And while some in the 
>> IETF think 
>>> that is an important problem to resolve, and standardization is the 
>>> obvious answer, real world operators have been using multiple 
>>> protocols successfully without vendor-neutral standards for 
>>> cross-protocol correlation.
>>>
>>> Prior to the 2002 workshop, the OPS area led an effort to meet with 
>>> operators at operator forums, such as NANOG.
>>> I recommend the OPS area drive an effort to get operator feedback 
>>> again.
>>> Let's get some feedback on IETF NM work since 2002, get suggestions 
>>> from operator experience on whether and how to standardize 
>> information 
>>> across multiple NM protocols, be sure we understand 
>> operators' needs 
>>> in today's networks, and get some suggestions for 
>> operators' emerging 
>>> needs that the IETF could better address over the next five to ten 
>>> years.
>>>
>>> Let's be sure we don't move down the disconnect road again.
>>>
>> I agree another workshop would be useful, but I think many 
>> issues are being addressed by NETCONF and YANG.
>> I prefer to just get more work done that we know needs to be done.
>>
>> The NETMOD WG has been working with the IPFIX WG and their 
>> development of the ipfix-psamp.yang data model has been very 
>> helpful in determining requirements for 'real-world' 
>> domain-specific models.  It will be interesting to compare 
>> configuration of IPFIX via CLI vs. SNMP vs. NETCONF/YANG and 
>> evaluate the strengths and weaknesses of each one.
>>
>> My original comment (as Balazs understood) is that we do not 
>> have any YANG infrastructure in place so domain-specific WGs 
>> like IPFIX have a reasonable chance of success using 
>> NETCONF/YANG.  Hopefully, this work will begin as soon as 
>> YANG is approved:
>>     * system group
>>     * interfaces group
>>     * entity group
>>     * access control model
>>
>> It took many years to agree to each one of these bullets for 
>> SNMP.  I am not patient enough to spend the next 20 years 
>> reinventing what SNMP already standardized over the last 25 
>> years.  Others are looking forward to starting from scratch.  
>> That is why I think rough consensus on a 5 year 
>> multi-protocol development plan would help.
>>
> 
> Let us be a little bit more specific here. 
> 
> How would such a 5 year plan look like? What would it include? What is
> the framework and the community it needs to get consensus from? 
> 

IMO, real coordination between the current data silos
is unrealistic, but if there is any real need then
spot solutions will crop up, like the Syslog over SNMP spec.

The issues important to me:
   - 5 year plan to publish all the infrastructure modules listed above
   - SYSLOG over NETCONF -- SYSLOG notification stream (is this needed?)
   - multi-protocol NETCONF database access and locking
   - YANG Doctors (pro-active training and early review)
   - YANG++ solutions planning (more OO features in YANG)
   - operator feedback and course correction

The plan would establish that there is rough consensus
on this approach, and there are people willing to do the work
needed to get the job done.  Currently, the market has no
idea what to expect from the IETF wrt/ network configuration.

> Dan
> 

Andy