[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Goals for netconf - moving towards the charter description
HI,
The following is a clarification to what Margaret had in her message
to answer some of your questions....
1) what are the resources needed to run NETCONF?
In the "ideal" environment, only a single TCP connection is needed,
over which BEEP framing is used for the three NETCONF channels. And
depending on the security setup and needs, IPSEC or SSL(TLS) may also be
included (at the proper place). It is anticipated that were will be
no requirement to have a "complete" XML parser on a managed device,
and depending on the data model definitions, it should be possible
to hand craft a lightweight XML parser. I don't believe that there
is any requirement to support HTTP, since BEEP does not require it,
but there is probably a usage case that I've totally forgotten.
If BEEP is not available, then a separate TCP connection is used
to support each of the three needed channels. In this case,
the SSH can be used as an additional security mechanism.
2) Is the configuration content that is applied in NETCONF operations
the "complete" configuration for a device or a "partial" configuration?
The configuration content can be either, and the operation determines
if the configuration content replaces existing configuration or "merges"
with existing content.
3) Do you get back a single result (like in SNMP operations), or
can you get back multiple application level errors?
The NETCONF protocol allows multiple application level errors to be
returned. And note, the number and types you will see can depend on
strength of referential integrity that you have specified in your
data model! There are some vendors whose CLI allows you to reference
items that don't exist. Other CLIs require you to create an item
before it is referenced, and don't allow it to be deleted before
all references are removed.
Hope this helps.
At 05:56 PM 3/27/2003 -0800, Faye Ly wrote:
>Margaret,
>
>Thank you for the reply. I am really happy to see your statement: "
>XMLConf is a generic configuration protocol. It could be used to
>configure any type of protocol or device." As I kept getting emails
>stating XMLConf is for IP centric device only which is a bit frustrating
>for me.
>
>Please see my comments embedded in <FL> below.
>
>Best,
>
>-faye
>
>-----Original Message-----
>From: Margaret Wasserman [mailto:mrw@windriver.com]
>Sent: Thursday, March 27, 2003 8:23 AM
>To: Faye Ly
>Cc: xmlconf@ops.ietf.org
>Subject: RE: Goals for netconf - moving towards the charter description
>
>
>Hi Faye,
>
>We seem to have gotten way off-track here, and I'm not sure why.
>I think that we may be using the same terms differently, or
>something, as one message in this thread does not (to me) seem
>to follow from another.
>
>XMLConf is a generic configuration protocol. It could be used to
>configure any type of protocol or device. Within the IETF, our
>focus is on standardizing a protocol that will be useful to
>configure networking equipment, but that doesn't preclude its
>use for other types of equipment (industrial, consumer, etc.).
>
><FL> YES!
>
>In order to support the XMLConf protocol, a device will need to
>be reachable via IP, and will need to support three TCP connections.
>It will also need to include HTTP, BEEP, an XML parser and an
>implementation of XMLConf. XMLConf cannot be used to configure
>devices that do not support XMLConf. We've looked closely at the
>expected system resources needed to support XMLConf, and we
>do not believe that the costs are prohibitive.
>
><FL> I believe you 100%. Does protocol provide any LITE version so that
>only one TCP connection is sufficient given that only configuration
>request and configuration confirmation are needed?
>
>It is probably best if you think of XMLConf, not as a replacement
>for SNMP, but as a replacement for (some uses of) CLI. Today,
>many operators use CLI to configure devices, either manually or
>automatically. The ones who build automated configuration systems
>using CLI are forced to deal with many different command structures,
>"screen scraping" and non-compatible changes from one release to the
>other. Most of these problems are caused by a disconnect between
>their use of CLI (automated scripting) and the purpose for which
>CLI was designed/implemented (human interface). It is a primary
>goal of XMLConf to offer programmatic access to the same type of
>configuration data that can currently be manipulated using CLI.
>Operators who currently use CLI and scripting to configure devices
>have told us that their lives would be improved by the existence
>of a protocol like XMLConf.
>
><FL> I think we spent enough time at the BOF clarifying this and I
>totally agree. This is not a SNMP replacement but rather more towards
>CLI scripting replacement. One question though, What about downloading
>partial or even full configuration file to the network equipment and ask
>the NE to perform the file and return the results. This seems to match
>really well with the scripting. This also helps to simplify the
>interface between CLI and configuration file. Does XMLConf support this
>as the XMLConf protocol document indicates?
>
>XMLConf has several compelling (we hope!) benefits for folks currently
>using CLI for configuration, including (but not limited to):
>
> - The ability to deal with configuration data separate
> from state data (simplifies dump, compare, restore
> of complete or partial configurations).
> - The elimination of screen-scraping. While this may seem
> small, minor software changes between one sofware
> load and another are currently costing operators a
> lot of time and money.
> - The ability to configure networks, instead of just devices
> (i.e. external transactions -- lock, commit, etc.)
>
><FL> I guess you answered my question here that XMLConf does support
>full or partial configuration files. Please confirm though because I
>got a bit lost during last round of emails exchanged. Yes, my biggest
>argument in supporting XML configuration is that it fits configuration
>file like a glove. I have actually done it personally too ...
>
>XMLConf is also intended to retain the primary benefits of CLI that
>caused these people to choose it (over SNMP, etc.) in the first
>place:
>
> - All configuration data (standard and proprietary) will be
> available through a single mechanism. [The trick to
> this lies in making it very easy for vendors to make
> their proprietary information accessible via XMLConf.]
> - Maps well into configuration models where the canonical
> configuration is held in a centralized database.
> - Text-based. Operators can understand what is transmitted
> on the wire, and the output can be manipulated using
> widely-available (and free) tools.
>
><FL> I do hope we can replace TL1 with XML too one day!
>
>Operators who currently use SNMP-based systems to do configuration
>obviously have different requirements and trade-offs than those who
>are currently using CLI for configuration. The folks using SNMP
>may or may not find the benefits of XMLConf to be compelling, but
>either way is okay. If these folks would prefer to continue using SNMP
>for configuration, they are welcome to do so.
>
><FL> Another YES!
>
>XMLConf focuses entirely on _how_ systems and networks are configured,
>not on _what_ is configured. Other work may (and should) be undertaken
>to specify a standard XML schema (or other representation) to describe
>_what_ can be configured with XMLConf in a standard way, but that is
>not part of our initial work.
>
><FL> I like the 'should' very much. The _what_ don't have to be
>covering every possible data model but a good set of sanity check or
>examples ought to be provided as this is a configuration protocol and it
>needs to be able to deal with configuration model. Again thanks a lot
>for the detailed reply and that really answered a lot of my questions.
>
>Margaret
Regards,
/david t. perkins
--
to unsubscribe send a message to xmlconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/xmlconf/>