[NANOG] Questions about NETCONF
Simon Leinen
simon.leinen at switch.ch
Fri May 16 14:46:03 UTC 2008
Randy Bush writes:
[in response to John Payne <john at sackheads.org>:]
>> I've personally been waiting for the data modeling to be
>> standardized. Yes, it's great and wonderful to have a consistent
>> method of talking to network devices, but I also want a standard
>> data model along with it.
> does this not imply that all devices would need to be semantically
> congruent? if so, is this realistic?
Personally I don't think it is.
The way that configuration is structured is something that at least
some vendors use to differentiate themselves from each other. (Though
other vendors make a point of being compatible with some "industry
standard CLI".)
So if you think that configurations in NETCONF should be similar to
the "native" configuration language, that doesn't bode well for
industry-wide standardization of a NETCONF configuration data model.
It might still be possible to have a common NETCONF data model, but
then that would probably be quite different from the (all) "native"
configuration languages; much in the same way as SNMP MIBs are
(structurally) different from how information is presented at the
CLI. Personally I'm not sure that this would be a very useful
outcome, because there would necessarily be a large lag between when
features are implemented (with a "native" CLI to configure them of
course) and when they can be configured through NETCONF.
Maybe the best we can shoot for is this:
* A common language to describe parts of NETCONF configuration. The
newly chartered IETF NETMOD working group[1] is working on this.
Vendors can then describe their specific NETCONF data models using
this language, and tool writers can use these descriptions to
generate code for applications that want to manipulate device
configurations.
* Common data models for certain well-understood parts of NETCONF
configuration. This could include simple "atomic" things such as
how to write an IP address or a prefix in (NETCONF) XML, or
configuration of standardized protocols such as OSPF, IPFIX etc.
The problem is how well will this support migration from
vendor-specific configuration to standardized configuration - which,
as I said, is always bound to lag far behind. And even if/when an
aspect of a configuration model (let's say for OSPF) is
standardized, vendors are bound to extend that model to support
not-yet-standardized extensions (e.g. sub-second timers, BFD). This
will be another challenge to support. (But there are smart people
working on this :-)
--
Simon.
[1] http://www.ietf.org/html.charters/netmod-charter.html
More information about the NANOG
mailing list