[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
- [NGO] Why NETCONF needs a data modeling language Andy Bierman
- [NGO] Re: Why NETCONF needs a data modeling langu… Juergen Schoenwaelder
- [NGO] Re: Why NETCONF needs a data modeling langu… Phil Shafer
- [NGO] Re: Why NETCONF needs a data modeling langu… Rohan Mahy
- Re: [NGO] Re: Why NETCONF needs a data modeling l… Ladislav Lhotka
- Re: [NGO] Re: Why NETCONF needs a data modeling l… Juergen Schoenwaelder
- Re: [NGO] Re: Why NETCONF needs a data modeling l… Andy Bierman
- Re: [NGO] Re: Why NETCONF needs a data modeling l… Ladislav Lhotka
- Re: [NGO] Re: Why NETCONF needs a data modeling l… Balazs Lengyel
- RE: [NGO] Re: Why NETCONF needs a data modeling l… Romascanu, Dan (Dan)
- [NGO] Re: Why NETCONF needs a data modeling langu… Rohan Mahy
- Re: [NGO] Re: Why NETCONF needs a data modeling l… Ladislav Lhotka
- Re: [NGO] Re: Why NETCONF needs a data modeling l… Ladislav Lhotka
- [NGO] Re: Why NETCONF needs a data modeling langu… Chris Cross
- [NGO] Re: Why NETCONF needs a data modeling langu… Phil Shafer
- [NGO] RE: [YANG] Re: Why NETCONF needs a data mod… David Harrington
- [NGO] Why NETCONF needs a data modeling language David Harrington
- [NGO] Re: Why NETCONF needs a data modeling langu… Martin Bjorklund
- [NGO] Re: Why NETCONF needs a data modeling langu… Andy Bierman
- [NGO] Re: Why NETCONF needs a data modeling langu… Balazs Lengyel
- [NGO] Re: Why NETCONF needs a data modeling langu… Jon Saperia
- [NGO] Re: Why NETCONF needs a data modeling langu… Balazs Lengyel
- [NGO] Re: Why NETCONF needs a data modeling langu… Jon Saperia