Re: Why NETCONF needs a data modeling language

[Jon Saperia <[e-mail]>]

Thanks
/jon
----------------------
Jon Saperia
TSP NM
(mobil) 617-201-2655
(office) 978-461-0249
[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]
>> [e-mail]
>
>