Re: OPSAREA strategy [was: Re: OPSAREA - preliminary minutes of the Hiroshima sessionuploaded]

Thanks, Balazs for changing the subject line. I suggest that we continue
this very important discussion under this subject, and leave the minutes
comments only be discussed under the older one.

More in-line. 

Dan
 

> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]] On Behalf Of Balazs Lengyel
> Sent: Thursday, December 03, 2009 11:44 AM
> To: Andy Bierman
> Cc: 'OPS Area (E-mail)'
> Subject: [OPS-AREA] OPSAREA strategy [was: Re: OPSAREA - 
> preliminary minutes of the Hiroshima sessionuploaded]
> 
> Hello,
> I agree that we need this debate. actually we have had a very 
> similar debate internally within my company.
> 
> As I see it we are already live in a multi-protocol OAM 
> world, that has been decided by the market.
> IMHO there should be a set of recommended protocols that any 
> WG/protocol developer in IETF should use for 
> configuration/logging/performance management/ fault management.
> All draft authors should have a good reason if they want to 
> use something else.

Until a few years ago the IESG was mandating that all WGs in the IETF
develop MIB modules for management. The results were mixed. A few WGs
developped MIB modules and they ended by being used. Other ignored the
IESG recommendation, or postponed writing the MIB modules, or did not
have enough MIB experts to write them and they were never written. Many
other WGs developped MIB modules (better or worse quality, smaller or
larger or huge) who were never used. The worst that happened in some
cases was that because of that directive some WGs did not think about
operational requirements and manageability, and did not bring the tools
used in real networks into the IETF standards track. Why do it if all
IESG was asking is writing a MIB module (actually a 'write a MIB module'
bullet in the WG charter)? 

Life was stronger than IESG directives and the IESG abandoned this
requirement a few years ago. The current requirement is that any
technology standardized in the IETF be managed, and that the
manageability considerations be documented and desirably standardized
using protocols and data modeling language from a standards toolkit.
This is documented to a certain extent in RFC 5706, but the IETF
community could not reach a consensus to make this a BCP, so it was
approved as Informational, at least at this phase. 

Operators will eventually use the tools that make sense for their
networks. The OPS area can make a great service to the community by
listening to operator needs and developing these tools and by
documenting what is available and how they are to be used. 

> An interesting point would be addressing/naming. As I see it 
> configuration is heading for Netconf while fault management 
> is using SNMP. These have very different naming systems.
> I have the basic use case:  I get an alarm/trap about some 
> resource in my node. I want to check the configuration/status 
> of the resource, however I can't just copy the SNMP OID into 
> a get/subtree-filter of a Netconf message. So what is the 
> recommended way?
> 
> I fully agree with Andy, that to make YANG/NETCONF work we 
> will need some basic stuff, like MIB2 system branch, 
> interface tables, else? This would be work for the OPS area.
> 
> Balazs
> 
> 
> 
> On 12/03/09 00:12, Andy Bierman wrote:
> > David Harrington wrote:
> > ...
> >    
> >> I don't think IESG commitment is that important. I think market 
> >> commitment is important. I think addressing real market needs is 
> >> important. I think we need to start the discussion to 
> understand what 
> >> the emerging needs are so we can begin to address them.
> >>
> >>      
> > Why would the market gravitate towards a standard that is just 
> > standard operations on proprietary data models?
> >
> > That is what I meant by a 5 year plan.
> > Is there going to be any standard data models (like 
> ipfix-psamp.yang) 
> > actually deployed?
> > If so, is there some coherence to the collective set of 
> YANG modules 
> > published by the IETF?
> >
> > If a domain-specific WG like IPFIX WG needs common data modeling 
> > components (like an interfaces table), then are they going 
> to wait for 
> > that work, do it themselves, invent some interim hack, or what?
> >
> > Isn't it up to the IESG to make sure the protocols they 
> approve have 
> > some development plan, or at least a stated direction wrt/ protocol 
> > work being deployed over a long period of time?

It is first of all to the NETMOD WG to finish the YANG definition work
:-) Then to assist IPFIX as this is probably the first 'customer' in the
IETF planning to make serious use of YANG. There will be more. If these
efforts will be successful the IESG may be convinced to turn the usage
of NETCONF or YANG into a recommendation for specific cases, but
direction statements alone are not sufficient. We are the IETF - running
code is our supreme arbiter. 



> >
> > The market is already using SNMP and NETCONF for proprietary data 
> > models.  Nobody needs YANG for that.
> > Now that the IETF is developing YANG, there is some 
> expectation that 
> > the IETF will do something with it.
> >
> >    
> >>> Andy
> >>>
> >>>        
> >    
> >>>> David Harrington
> >>>>          
> > Andy
> > _______________________________________________
> > OPS-AREA mailing list
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/ops-area
> >    
> 
> -- 
> Balazs Lengyel                       Ericsson Hungary Ltd.
> System Manager
> ECN: 831 7320                        Fax: +36 1 4377792
> Tel: +36-1-437-7320                  email: 
> [email protected]
> 
> _______________________________________________
> OPS-AREA mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ops-area
>