Re: Why NETCONF needs a data modeling language

Balazs Lengyel <balazs.lengyel@ericsson.com> Sun, 02 December 2007 20:19 UTC

Return-path: <discuss-bounces@apps.ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyvHW-0007Vg-HO; Sun, 02 Dec 2007 15:19:14 -0500
Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IyvHU-0007SR-Rg for discuss-confirm+ok@megatron.ietf.org; Sun, 02 Dec 2007 15:19:12 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyvHU-0007RD-Gy for discuss@apps.ietf.org; Sun, 02 Dec 2007 15:19:12 -0500
Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IyvHS-0000yC-7i for discuss@apps.ietf.org; Sun, 02 Dec 2007 15:19:12 -0500
Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 900C020FD1; Sun, 2 Dec 2007 21:19:09 +0100 (CET)
X-AuditID: c1b4fb3c-b0798bb0000030cf-c1-4753133da81f
Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 678C0205FE; Sun, 2 Dec 2007 21:19:09 +0100 (CET)
Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 2 Dec 2007 21:19:09 +0100
Received: from [127.0.0.1] ([159.107.148.22]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 2 Dec 2007 21:19:08 +0100
Message-ID: <47531335.9050800@ericsson.com>
Date: Sun, 02 Dec 2007 12:19:01 -0800
From: Balazs Lengyel <balazs.lengyel@ericsson.com>
User-Agent: Thunderbird 2.0.0.4 (X11/20070604)
MIME-Version: 1.0
To: Jon Saperia <saperia@jdscons.com>
Subject: Re: Why NETCONF needs a data modeling language
References: <474E0F71.2050003@andybierman.com> <241201c83366$9acf8070$6502a8c0@china.huawei.com> <4752F757.5030204@ericsson.com> <94673DD8-1AAB-4ED2-AD27-3AFB4C604F05@jdscons.com>
In-Reply-To: <94673DD8-1AAB-4ED2-AD27-3AFB4C604F05@jdscons.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 02 Dec 2007 20:19:08.0998 (UTC) FILETIME=[98458E60:01C83520]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: -1.0 (-)
X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a
Cc: yang@ietf.org, discuss@apps.ietf.org, 'NETCONF Goes On' <ngo@ietf.org>
X-BeenThere: discuss@apps.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: balazs.lengyel@ericsson.com
List-Id: general discussion of application-layer protocols <discuss.apps.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/discuss>, <mailto:discuss-request@apps.ietf.org?subject=unsubscribe>
List-Post: <mailto:discuss@apps.ietf.org>
List-Help: <mailto:discuss-request@apps.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/discuss>, <mailto:discuss-request@apps.ietf.org?subject=subscribe>
Errors-To: discuss-bounces@apps.ietf.org

Hello,
Naturally our aim is to develop standard NETCONF configuration models, and the more people 
use NETCONF the easier that will be.
Balazs


Jon Saperia wrote:
> 
> Thanks
> /jon
> ----------------------
> Jon Saperia
> TSP NM
> (mobil) 617-201-2655
> (office) 978-461-0249
> saperia@jdscons.com <mailto:saperia@jdscons.com>
> 
> 
> 
> On Dec 2, 2007, at 1:20 PM, Balazs Lengyel wrote:
> 
>> Hello,
>> >>    Q1) Why does NETCONF need a DML at all?
>>
>> If we have an IETF standard DML for NETCONF, device vendors (like my 
>> company) will be much more comfortable, much more willing to adapt 
>> NETCONF itself. With a standard DML we would see a better chance at 
>> having available 3rd party or even freeware toolkits for NETCONF.
> 
> Yes, but does that mean that we will begin to develop a standard 
> configuration objects for say, BGP or DiffServ that would work from one 
> vendor to the next?  It would be nice to think so, that would really 
> help interoperability and should be the target of 'our' collective efforts.
> /jon
>>
>> The above would be important even for a company which would not care 
>> about interoperability.
>>
>> Balazs
>>
>> David Harrington wrote:
>>>
>>>  
>>>
>>>> Hi,
>>>>
>>>> There are a few questions that the IESG and others have asked,
>>>> which I will try to address:
>>>>
>>>>    Q1) Why does NETCONF need a DML at all?
>>>>    Q2) Why is NETCONF special?
>>>>    Q3) Why won't lots of other WGs want to define their own
>>>>        protocol-specific DMLs?
>>>>    Q4) Why isn't XSD or RelaxNG good enough?
>>> I'll take a whack at answering the same questions.
>>> A1) Why does NETCONF need a DML at all?
>>> to promote vendor-neutral interoperable management. It is much easier 
>>> to develop standards when everybody uses the same
>>> basic language to communicate; this "common language for shared
>>> communication" is also reflected in the IETF decision to use English
>>> text and ASCII documents.
>>> This is not just about being able to standardize **device
>>> management**; it is a basic step to permit the standardization of
>>> **network management** and possibly **services management". The DML is
>>> a basic building block.
>>> A2) Why is NETCONF special?
>>> It is and it isn't. Netconf is only one protocol used for network
>>> management. It has some unique requirements, such as using a 
>>> document-based
>>> approach and differentiating the data for config versus state and for
>>> dealing with different time-defined contexts such as running and
>>> startup configs. This differs from other network management protocols,
>>> such as SNMP and syslog and ipfix, which use their own data formats,
>>> and usually deal only with the currently-running config. Netconf is a
>>> tool designed to meet the special requirements of configuration, and
>>> the DML needs to support special features not found in other NM-DMLs. 
>>> Netconf is not special, in that any language used for network
>>> management is likely to have certain common requirements. NM data
>>> models are commonly used directly by humans, in their raw form, such
>>> as when they troubleshoot problems using network sniffers. NM data
>>> models are also commonly used by NMS applications that can handle the
>>> translations into a more human-readable format. Designers of NM tools
>>> (e.g., protocols and data models) thus need to pay close attention to
>>> who will use the information, and to assume that the data will be used
>>> both directly by humans and by applications. Operators have complained
>>> strongly that OIDs are very hard to work with in raw form, yet
>>> operators frequently need to deal with the raw form of the data. A3) 
>>> Why won't lots of other WGs want to define their own
>>>         protocol-specific DMLs?
>>> To paraphrase a wise man from the SNMP community, when you fill a room
>>> with protocol designers and ask for a solution to a problem, is it a
>>> surprise when they recommend designing a new protocol?
>>> The decision about whether to use an existing protocol/DML or develop
>>> a new protocol/DML should be made after a careful analysis of the
>>> requirements of the solution. SNMP was designed when CMIP was found to
>>> not quite address the needs. The SMI was designed when ASN.1 was found
>>> to not quite address the needs. XML was designed when other DMLs were
>>> found to not quite address the needs.
>>> The decision to explore an XML-based DML and to explore a C-like DML
>>> follows years and years and years of debate over the requiremnts of
>>> network management, and configuration in particular. If every WG 
>>> spends as much time analyzing the requirements that the
>>> OPS area has spent considering this decision, it might be good for
>>> ensuring no new protoocls are designed that are not really needed, but
>>> the IETF would also grind to a halt, much as the OPS community has
>>> done over our many years of debate. And the delay caused by our
>>> debates has made IETF network management largely irrelevant to the
>>> operator community (our customers).
>>> As always, we need to be vigilant and determine whether enough thought
>>> has been given to reuse of existing protocols. We also need to
>>> consider the tradeoffs between new protocols and reusing existing
>>> protocols in ways they were not designed to be used.
>>> A4) Why isn't XSD or RelaxNG good enough?
>>> As mentioned in A2, NM data models need to be both machine- and
>>> human-readable. XSD is machine-readable, but it is a tough language
>>> for humans. RelaxNG seems better. As discussed further in a different 
>>> email, Netconf will almost
>>> certainly need a DML suited to its requirements, and if RelaxNG is
>>> found to be human-friendly-enough, we would almost certainly still
>>> need to select a subset and adapt it to meet configuration
>>> requirements. So the benefit of using RelaxNG over a domain-specific
>>> DML may be lost by using an adapted-subset of RelaxNG.
>>> Most operators already understand languages like Perl and C and
>>> Javascript, because they already need to write lots of scripts to
>>> manage their networks. Most implementers of NM support in
>>> internetworking devices work in C or a variant of C. It makes a lot of
>>> sense to use a language with a C-like syntax for these people, rather
>>> than forcing them to learn yet another language that was designed for
>>> some other purpose.
>>> [soap]
>>> somebody commented that the designers of XSD and RelaxNG really
>>> understand how to design DMLs, implying that the OPS community does
>>> not. Many of the people involved in the ongoing DML discussions over
>>> the years, and now, are MIB Doctors and operators and protocol
>>> designers, and have had years of experience designing and working with
>>> SMI and network management. They understand the requirements of a DML
>>> for NM far more than the designers of XSD or RelaxNG, who were not
>>> designing their DMLs for NM purposes.
>>> [end soap]
>>> David Harrington
>>> dbharrington@comcast.net <mailto:dbharrington@comcast.net>
>>> ietfdbh@comcast.net <mailto:ietfdbh@comcast.net>
>>
>>
>