[NGO] RE: [YANG] Re: Why NETCONF needs a data modeling language

"David Harrington" <ietfdbh@comcast.net> Fri, 30 November 2007 14:31 UTC

Return-path: <ngo-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy6uN-0004j7-TY; Fri, 30 Nov 2007 09:31:59 -0500
Received: from ngo by megatron.ietf.org with local (Exim 4.43) id 1Iy6uM-0004iq-Rc for ngo-confirm+ok@megatron.ietf.org; Fri, 30 Nov 2007 09:31:58 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy6uM-0004iO-Bm for ngo@ietf.org; Fri, 30 Nov 2007 09:31:58 -0500
Received: from qmta08.emeryville.ca.mail.comcast.net ([76.96.30.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iy6uJ-0002AJ-2t for ngo@ietf.org; Fri, 30 Nov 2007 09:31:58 -0500
Received: from OMTA13.emeryville.ca.mail.comcast.net ([76.96.30.52]) by QMTA08.emeryville.ca.mail.comcast.net with comcast id Jziu1Y00317UAYk0A0CN00; Fri, 30 Nov 2007 14:31:58 +0000
Received: from Harrington73653 ([24.128.104.207]) by OMTA13.emeryville.ca.mail.comcast.net with comcast id K2Xs1Y00A4UVsHU0800000; Fri, 30 Nov 2007 14:31:58 +0000
X-Authority-Analysis: v=1.0 c=1 a=I0y0xKm2-w0A:10 a=j3Z76cjpAAAA:8 a=48vgC7mUAAAA:8 a=m7Gx0nXtxD0cURmhWtoA:9 a=Jbp6iasmxlNv7zYQp5EA:7 a=p7ZV2XQxOjHVSLzO9rel6YhuadgA:4 a=lZB815dzVvQA:10 a=FvgKqOQ44qUA:10 a=JrSEOxZJtCQA:10 a=50e4U0PicR4A:10
From: David Harrington <ietfdbh@comcast.net>
To: j.schoenwaelder@jacobs-university.de, 'Rohan Mahy' <rohan.mahy@gmail.com>
References: <474E0F71.2050003@andybierman.com><953beacc0711282017p3ad865abw19920b4e68e82e80@mail.gmail.com> <20071129113446.GB10751@elstar.local>
Date: Fri, 30 Nov 2007 09:31:37 -0500
Message-ID: <241101c8335d$b84c1c70$6502a8c0@china.huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <20071129113446.GB10751@elstar.local>
Thread-Index: Acgye+QkPsKmhiGtRFyLmsSo6IbADwA17LEA
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 03fb21b15d5177c512a4caa19876f30a
Cc: yang@ietf.org, discuss@apps.ietf.org, 'NETCONF Goes On' <ngo@ietf.org>
Subject: [NGO] RE: [YANG] Re: Why NETCONF needs a data modeling language
X-BeenThere: ngo@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: NETCONF Goes On - discussions on future work and extensions to NETCONF <ngo.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ngo>, <mailto:ngo-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ngo>
List-Post: <mailto:ngo@ietf.org>
List-Help: <mailto:ngo-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ngo>, <mailto:ngo-request@ietf.org?subject=subscribe>
Errors-To: ngo-bounces@ietf.org

Hi comments inline. 

> -----Original Message-----
> From: Juergen Schoenwaelder 
> [mailto:j.schoenwaelder@jacobs-university.de] 
> Sent: Thursday, November 29, 2007 6:35 AM
> To: Rohan Mahy
> Cc: yang@ietf.org; discuss@apps.ietf.org; NETCONF Goes On
> Subject: [YANG] Re: Why NETCONF needs a data modeling language
> 
> On Wed, Nov 28, 2007 at 08:17:04PM -0800, Rohan Mahy wrote:
> 
> > > NETCONF needs
> > > its own MIB language, just like SNMP needs SMIv2.
> > 
> > I don't think you've made a strong case here. You might be 
> right, but your
> > statements above do not strongly motivate a new language.
> 
> NETCONF needs a new language; whether it is a domain specific
language
> like YANG or an "adapted subset" of some existing XML schema
language
> does not change that fact that we will need a NETCONF data modeling
> language and that we will need tools to understand that language.

+1. 
Since this discussion goes outside the Network Management community in
the IETF, I think some background is important.

ASN.1 was a general-purpose modeling langugae that did not meet the
requirements of network management. For network management standards,
it is important to limit the required resources (code footprint,
memory, CPU usage) to make implementtions feasible for
resource-constrained devices like set-top boxes. That's why SMI is a
subset of ASN.1, rather than all of ASN.1. 

There are aspects of the data models needed for network management
that are not necessaily needed for all ASN.1 modeling. Some examples
are given below. That's why SMI is an "adapted" subset of ASN.1

Now we are looking to move from the binary ASN.1 to the textual XML as
the base language, to meet operators' requests (see RFC3535). Network
management still needs an "adapted subset" of a general purpose
modeling language or a domain-specific language.

>  
> > I don't think we can take it on blind faith that we need to 
> do things in
> > Netconf the way SNMP did them. 

I think the way SNMP did things is very inappropriate for
configuration purposes (and so most operators apparently). While I
strongly support reuse, especially reuse of existing standards, we
need to choose the right tools for the job to be done. SNMP is not a
viable candidate for confguration in most networks, for reasos
described below.

>I think it is very important 
> to look at the
> > reasons we thought that SNMP needed to be a certain way, 
> but we also need to
> > acknowledge that SNMP was hardly a success as a 
> configuration protocol, and
> > try to find out why. It is possible that the data model was 
> too rigid for
> > practical configuration use.
> 
> There has been a long discussion about why SNMP failed before the
> NETCONF effort was started, all going back to IAB workshop [RFC
3535]
> and lots of followup email discussions. I am not sure it is terrible
> useful to redo this exercise. From what I recall, the rigidity of
the
> SMI was never mentioned as a major issue why SNMP failed to be a
good
> configuration protocol.

+1. Let me do a quick review for those who haven't followed those
discussions, so we don't have to redo all these discussions from
scratch. 

SNMP was not the only approach for configuration that failed, but we
can start there. The 2002 IAB Workshop was toward the end of long
discussions about configuration, not the beginning. COPS-PR, SNMPCONF,
the Dilbert mailing list, the ops-nm mailing list, and many other
discussions focused a lot on configuration requirements. The IAB
Workshop achieved consesnus to explore an XML-based approach. 

The "SNMP standard" has three parts - the protocol, the MIB, and the
SMI.

The SNMP protocol was found inadequate for configuration for a number
of reasons. SNMPv1 lacked security, so many vendors did not support
SETs, so operators could not manipulate the configuration of many
vendors' devices with SNMP. Even when SET was supported, SNMP was
designed to run over unfragmented UDP, which limited message sizes so
much it would be impossible to configure a large device in a
reasonable amount of time.

The major issue with MIBs for configuration was lack of vendor support
for MIB modules for all features in their products, which left SNMP
without MIB modules to configure everything in a device. And if the
CLI could configure everything, and the CLI was needed to configure
those things without MIB modules, then it made sense to simply use CLI
for everything. A related issue was the long time it takes to get a
standard MIB module for a new protocol versus developing a proprietary
CLI command set for a new protocol; the delay made the MIB module
irrelevant since the problem of configuring the feature would have
been already resolved using the CLI.

There were some discussions of the rigidity of the SMI, mostly around
complex data structures such as nested tables, but there are
workarounds for this. AFAIK, relational databases typically do not
support nested tables either, so I never considered this a major
fault; it just makes it harder to represent structures that can be
expressed easily in C, which was the preferred language for agent
developers.

I think the biggest problem with the SMI is that everybody hates OIDs
and wants something more human-readable. But that's not just about
configuration.

See RFC3535 for more detailed summaries of the IAB Workshop
discussions.

> 
> > Look at the following Relax NG in compact form, 
> side-by-side with YANG.
> > 
> > container aaa {
> >    container bbb {
> >       leaf foo { type string; }
> >       leaf bar { type uint32; }
> >    }
> > }
> > 
> > element aaa {
> >    element bbb {
> >       element foo { xsd:string },
> >       element bar { xsd:unsignedInt }
> >    }
> > }
> > 
> > This hardly seems like a big difference to me.
> 
> I am not sure which point you are trying to make using examples that
> ignore almost all NETCONF specifics. But even then, if you spell out
> the additional NETCONF specific semantics which are hidden because
> there are suitable defaults for the most common cases, then the YANG
> example above actually expands to the following:
> 
>  container aaa {
>     config true;
>     status current;
>     container bbb {
>        status current;
>        config true;
>        leaf foo { 
>           type string; 
>           config true;
> 	  status current;
> 	  mandatory false;
>        }
>        leaf bar { 
>           type uint32; 
>           config true;
> 	  status current;
> 	  mandatory false;
>        }
>     }
>  }
> 
> Statements like 'config true;' are essential for the processing of
> NETCONF messages and also for validating content exchanged in
NETCONF
> messages (and this is why for example generic XML validation tools
are
> only of limited value for NETCONF implementors).
> 
> I am sure one can define an adapted subset of RNG which takes care
of
> all this and then at the end this adapted subset likely works like
> YANG. However, given the SMI and ASN.1 experience, I do question
> 
> a) that doing so will lead to a large reuse of available RNG tools
for
>    processing NETCONF data models (since they don't know the RNG
>    subset nor the semantic additions)

+1. Tools for XSD or RNG will only be able to do partial validation
and processing. Additional validation will be needed that is
domain-specific. If XSD forces us to put much of the "adapted" stuff
into app-notes, we will need special tools that can validate the
content of the app-notes.

> 
> b) that the effort to specify such an extended subset will be less
>    than the effort for defining a domain specific language like YANG

+1; I think it might take longer to develop a RNG-standard-compliant
extended subset than working with a domain specific language, because
we will constantly be faced with finding workarounds for the
constraints imposed by the RNG standard.

> 
> c) that the effort to implement tools understanding the adapted
subset
>    of RNG will be less than writing proper tools for a domain
specific
>    language from scratch

+1.

> 
> d) that there will be long term (say 20 year) reliable change
control
>    exercised by the organization that has change control over
NETCONF

+1. ASN.1 changed a lot after the SMI was developed as an adapted
subset of ASN.1-1988. I think ASN.1 became more complex, adding new
features for additional uses, and changed in ways that made the SMI no
longer compatible with the ASN.1 standard. The separation of the SMI
from the underlying langauge has allowed the SMI to remain stable for
twenty years. That stability is critically important to motivating
vendors to utilize our standards, since they are not faced with a
constantly-changing base language.

The SMING WG tried to update the SMI, and found that, even with strong
pressures to remain backwards compatible with SMIv1 and SMIv2, there
is a need to move forward to a new base language that is more
human-readable than SMIv1 or SMIv2 (and ASN.1). But whether XML or
something else, the solution needs to be able to address the
requirements of network management, especially human-readability.

> 
> /js
> 
> -- 
> 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/>
> 
> 
> _______________________________________________
> YANG mailing list
> YANG@ietf.org
> https://www1.ietf.org/mailman/listinfo/yang
> 




_______________________________________________
NGO mailing list
NGO@ietf.org
https://www1.ietf.org/mailman/listinfo/ngo