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

[Balazs Lengyel <[e-mail]>]

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
> [e-mail] <mailto:[e-mail]>
> 
> 
> 
> 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
>>> [e-mail] <mailto:[e-mail]>
>>> [e-mail] <mailto:[e-mail]>
>>
>>
> 


_______________________________________________
NGO mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ngo