[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: I-D draft-weijing-netconf-interface-01.txt
> "running" is the only target built into the base protocol; the
> others are added by capabilities. If a device does not support,
> say, the "startup" capability, it simply doesn't announce the
> relevant capability.
>
> The motivation for making explicit targets comes from the desire to
> make a protocol that allows the device to explicitly define and
> announce its native capabilities. This allows clients to discover
> these capabilities and treat the device appropriately.
>
> For instance a device with a distinct startup configuration needs to
> have the running configuration copied to the startup configuration for
> the changes to be permanent. The application has to know this in order
> to operate correctly, and the application can learn this via the
> capabilities announcement.
>
> We also feel that this expressiveness (here and elsewhere in the
> protocol) given an exactness and explicitness that helps both the
> application developer and the device programmer, since I will know
> when someone wants to perform a commit operation, not by guess work
> but by explicit command. The application writers will know that they
> need to send a commit operation because my software announces the
> "#candidate" capability. Future products have a mechanism for
> expressing their abilities without making implicit assumptions on what
> they think the application is trying to do.
>
A XML schema carrying the whole data model information is much more precise
and rich than protocol options.
> Having the set of available sources and targets be part of the
> protocol allows the manipulation of configuration to be separate from
> the information model. If you give me a chunk of configuration, I can
> put it on the router and activate it without understanding the
> configuration contents, based on what I learn about the device via the
> capabilities announcement.
It is dangeous to put it on the router without knowing what it is and
without proper defined data model. Managing system must have the full
knowledge of the device it plans to manage before actually touch it. Every
new device we deployed, we test it against the our managing system. If the
managing system does not support that particular device or particular
software release of that device, we give the device MIB or IDL or XML schema
to application developer to write the code.
> Device implementations naturally segregate configuration data into a
> separate mode or database. "Configuration mode" allows manipulation of
> configuration data and "operational mode" displays operational
> information about the device. We kept this distinction in netconf for
> two reasons. First it matches the way users (and applications) think
> about the device. If you are loading the configuration for a VPN, you
> don't need or what operational data. Second, it matches the way
> devices are implemented and reduces the cost of implementing netconf.
>
What about operational status of interface? What about route entries?
Performance statistical data may have separate datastore. But status
information of network resource is tightly coupled with configuration
information of network resource.
> The format element allows the application to retrieve the
> configuration in the device's native text-based format. This allows
> for archival, text-based diffing, human viewing and other applications
> for which xml is not suitable. For example, we download configuration
> files in text format for cvs archival, so 'cvs diff -u -Dyesterday'
> shows human-readable text.
In the XML world, every XML content should have corresponding XML schema or
DTD, even for plain text. One can use the following to describe the plain
text content:
<element name="text" type="string"/>.
For XML content, it is self-explanation and no need of <format> element.
> You've effectively hidden the real protocol operations (lock,
> validate, copy, etc) inside a small number of requests, making the
> intent opaque (and increasing the cost of implementation).
>
We are arguing the information belongs to the data model not the protocol
operation. To blend the network management information model with protocol
operation will only works for the device matching the model. For device not
matching the model, it either cannot re-use the protocol operation or
results complex and ugly hacking.
--
Weijing Chen
> -----Original Message-----
> From: Phil Shafer [mailto:phil@juniper.net]
> Sent: Tuesday, September 02, 2003 5:51 PM
> To: Allen, Keith
> Cc: netconf@ops.ietf.org
> Subject: Re: I-D draft-weijing-netconf-interface-01.txt
>
> "Allen, Keith" writes:
> >We felt discussing
> >an example would be easier than arguing abstract concepts
>
> Thanks for pulling your comments out in this email. It's much
> easier to understand the differences, problems, and motivations
> in this format.
>
> >1. Assumptions about a device's information model are being built into
> >the protocol. One way this is manifested is with the protocol's use of
> >"targets." The specification of "startup," "running," and "candidate"
> >targets presumes that the device supports these concepts.
>
> "running" is the only target built into the base protocol; the
> others are added by capabilities. If a device does not support,
> say, the "startup" capability, it simply doesn't announce the
> relevant capability.
>
> The motivation for making explicit targets comes from the desire to
> make a protocol that allows the device to explicitly define and
> announce its native capabilities. This allows clients to discover
> these capabilities and treat the device appropriately.
>
> For instance a device with a distinct startup configuration needs to
> have the running configuration copied to the startup configuration for
> the changes to be permanent. The application has to know this in order
> to operate correctly, and the application can learn this via the
> capabilities announcement.
>
> We also feel that this expressiveness (here and elsewhere in the
> protocol) given an exactness and explicitness that helps both the
> application developer and the device programmer, since I will know
> when someone wants to perform a commit operation, not by guess work
> but by explicit command. The application writers will know that they
> need to send a commit operation because my software announces the
> "#candidate" capability. Future products have a mechanism for
> expressing their abilities without making implicit assumptions on what
> they think the application is trying to do.
>
> >The specification of a
> >"running," "startup," or other target should be part of a device's
> >information model schema.
>
> Having the set of available sources and targets be part of the
> protocol allows the manipulation of configuration to be separate from
> the information model. If you give me a chunk of configuration, I can
> put it on the router and activate it without understanding the
> configuration contents, based on what I learn about the device via the
> capabilities announcement.
>
> >2. Another way that assumptions about the device's information model
> >are being built into the protocol is with many of the operations being
> >specified in the protocol, like "copy," "validate" and "lock."... Our
> >suggestion is to associate operations with elements in the information
> model
> >in what we consider to be a more object-oriented approach.
>
> The draft has locking available at any level of the configuration
> hierarchy. This is both expensive and increases the cost of locking,
> rollback, archival, and other tasks. A simple single short-lived lock
> for the full configuration should suffice.
>
> >The information model specified for a device must identify what
> >is state information and what is configurable without the need for
> separate
> >container elements.
>
> Device implementations naturally segregate configuration data into a
> separate mode or database. "Configuration mode" allows manipulation of
> configuration data and "operational mode" displays operational
> information about the device. We kept this distinction in netconf for
> two reasons. First it matches the way users (and applications) think
> about the device. If you are loading the configuration for a VPN, you
> don't need or what operational data. Second, it matches the way
> devices are implemented and reduces the cost of implementing netconf.
>
> >4. This is not a major point, but the "format" element in the WG text
> >is unnecessary. A more straightforward approach for devices that don't
> >support a true XML interface would be to enclose the CLI text supported
> by
> >the device with a single pair of XML tags.
>
> The format element allows the application to retrieve the
> configuration in the device's native text-based format. This allows
> for archival, text-based diffing, human viewing and other applications
> for which xml is not suitable. For example, we download configuration
> files in text format for cvs archival, so 'cvs diff -u -Dyesterday'
> shows human-readable text.
>
> >In our draft, we have just
> >four command messages and four responses to those messages: get, perform,
> >abort and notify.
>
> You've effectively hidden the real protocol operations (lock,
> validate, copy, etc) inside a small number of requests, making the
> intent opaque (and increasing the cost of implementation).
>
> Thanks,
> Phil
>
> --
> to unsubscribe send a message to netconf-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/netconf/>
--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>