Re: Management Requirements

Hi,

Inline ...
--
David Harrington
[email protected]
+1-603-828-1401





On 8/8/12 4:19 AM, "Juergen Schoenwaelder"
<[email protected]> wrote:

>On Tue, Aug 07, 2012 at 08:16:58PM -0400, David Harrington wrote:
>> 
>> 3) Standardized whole-box config is being addressed by netconf/yang
>> (partial config can be supported as well).
>> Netconf/YANG support is seriously constrained by a lack of standard YANG
>> models. 
>
>This sounds a bit like "do not write standard YANG data models because
>there
>are no standard data models". Anyway, NETMOD has core data models in WG
>last
>call. We are getting there, slowly by surely.

I'm sorry you saw this as being negative. The following sentences discuss
the active efforts to mitigate the issue.
And no where did I say standardized YANG data models shouldn't be written.

I strongly support the development of core models consistent with the MIB
information models (for consistency in management),
PLUS the development of new YANG modeling that MIB modules cannot do well,
such as routing technologies.
The MIB problem (a whole box cannot be managed using SNMP, largely because
there are not MIB modules representing everything in a box) is also a
problem for Netconf - the lack of YANG modeling for everything in a box.
Part of the MIB problem is that SMIv2 is not good for representing some
aspects of a box, such as nested tables; Hopefully YANG will overcome that
problem so more things in a box can be modeled reasonably.

>
>> Netconf is often implemented with proprietary data modeling approaches
>> (e.g., CLI commands with XML tags, not YANG).
>
>I can't let this "CLI commands with XML tags" pass uncommented. While
>some (IMHO broken) implementations might do this, there are router
>vendors who actually do ship implementations with structured data
>models.

Some vendors have used a CLI with XML tags proprietary approach; others
use structured data, such as proprietary XMLSchema models.
My observation is that currently implementations often use proprietary
data modeling approaches rather than YANG.
I would much rather see standardized YANG models widely deployed.
I just don't think that is the current state of deployment.

>
>> The IETF community is working on converting many MIB modules into YANG
>> format to provide core data models.
>
>Again, this is not very accurate. The NETMOD WG is not just converting
>MIBs.  

Where did I say they were JUST converting MIBs? Read the following
sentence in my email.
Please look at my whole comment; don't just react sentence by sentence.


>The routing data model goes far beyond anything out there in
>MIB land related to routing by providing a routing model. The IP
>configuration model is the first time the IETF every comes up with a
>standards-track way to configure IP interfaces.

And what does my next sentence say?

>
>> The IETF community is working on developing YANG models for technologies
>> not well supported by SMIv2 modeling.
>> Netconf was designed with eye toward operators logging in via SSH
>>sessions
>> to configure devices.
>> This approach can be automated by shell scripts.
>> I am not aware of much non-scripted application-support for netconf
>> automation yet. 
>
>This sounds a bit like NETCONF is designed for human operators messing
>around with devices. At least one big router vendor has reported to
>base its management system solely on NETCONF, providing adaptors for
>legacy interfaces where necessary.
>
>I think we should be careful not to place NETCONF/YANG into a certain
>corner at this point in time by drawing a picture that might not be
>adequate. YANG was published just in Octover 2010 and it is only since
>then that we are able to work on standard data models. Give the
>technology some more time before drawing conclusions like the above.

That is exactly my point. The YANG standard database needs "some more
time" to be expanded and to mature.

However, BEHAVE needs to be able to develop usable standardized management
NOW, 
In a few years, after YANG has had additional time for industry adoption
and standardized YANG modules are abundant, then using YANG would be a
good thing.
But NATs interact with multiple parts of systems. There are standardized
MIB modules for many of those core system parts available now, so MIB
modules to support BEHAVE technologies will likely find MIB modules that
support many of the core system features that NATs must interact with.
OTOH, many of those same core technologies do not yet have a standardized
YANG data module, so BEHAVE would need to either build support for those
other things into their YANG data models (where they are not necessarily
the experts) or wait for standardized YANG modules to be developed.

I don't think standardized configuration is mature enough YET, or widely
deployed enough YET, to justify BEHAVE allocating its scarce resources to
modeling YANG configurations, and then trying to convince the industry to
widely deploy Netconf and those data models. In the future, yes; now, no.
I think the Netconf/YANG technology needs "some more time" to mature and
for the Internet-industry's demand for cross-vendor standardized
configuration to grow.
In comparison, SNMP monitoring and Syslog logging are very mature, and
already supported by wide deployment both at the device and application
level.

I think SNMP and Syslog make sense NOW to meet the BEHAVE current
requirements for monitoring, eventing, and logging.
Standardized configuration for BEHAVE can come later  - which fits well
with the time needed for core+other YANG models to be developed and
deployed.

Dbh (ex-NETMOD co-chair, ex Syslog co-chair, ex SNMPv3 co-chair, ex BEHAVE
AD )

>
>/js (NETMOD co-chair)
>
>-- 
>Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
>Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>