[irs-discuss] IRS problem statement and NETCONF/YANG

[Juergen Schoenwaelder <[e-mail]>]

Hi,

reading through the problem statement posted at

http://lucidvision.com/draft-atlas-irs-problem-statement-00.txt

I noticed a number of statements concerning NETCONF and YANG that
probably need to be corrected. For more background where NETCONF and
YANG is, you may want to consult the tutorial slides posted at

http://cnds.eecs.jacobs-university.de/slides/2012-ietf-84-netconf-yang.pdf

and consult the documents referenced in the slides. Some more detailed
comments:

:   Finally, the IETF's Network Configuration (or NetConf) protocol has
:   made many strides at overcoming most of the limitations around
:   configuration that were just described.  However, the lack of
:   standard data models have hampered the adoption of NetConf.

The NETMOD working group has been chartered to work on common core
data models and currently has core data models for the configuration
of network interfaces, ip interfaces and a core routing configuration
data model in WG last call:

http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-04
http://tools.ietf.org/html/draft-ietf-netmod-ip-cfg-05
http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg-05

:   While NetConf has solved many of the deficiencies present in SNMP in
:   terms of configuration, it still does not satisfy a number of
:   requirements needed to manage today's routing information.  First,
:   the lack of standard data models have hampered the adoption of
:   NetConf; a significant amount of per-vendor customization is still
:   needed.  The transport mechanisms that are currently defined (e.g.,
:   SOAP/BEEP) for NetConf are not those commonly used by modern
:   applications (e.g., ReST or JSON).

The default to implement transport for NETCONF is SSH. There is
another transport over TLS. The BEEP and SOAP transports are on their
way to be declared historic. That said, there is work underway to
define a JSON / REST API to YANG modelled NETCONF data stores. 

http://tools.ietf.org/html/draft-bierman-netconf-yang-api-00
http://tools.ietf.org/html/draft-lhotka-yang-json-00

:   NetConf primarily facilitates configuration rather than reading of
:   state or handling asynchronous events.

Not sure what primarily facilitates means but NETCONF does support all
three functions. NETCONF allows read access to all existing SNMP
instrumentation of devices.

:   NetConf matches up to the key needed aspects as follows
:
:   Multiple Simultaneous Asynchronous Operations:   Not Possible

The NETCONF protocol tags RPC invocations with a message-id that is
echoed back in RPC replies, allowing asynchronous operations. NETCONF
also provides global and partial locks to properly deal concurrent
operations received via multiple channels.

:   Configuration Not Re-Processed:   Not Possible

I simply do not understand the definition of this aspect. You document
says:

:   Configuration Not Re-Processed:   When an IRS operation is processed,
:      it does not require that any of the configuration be processed.
:      I.e., the desired behavior is orthogonal to the static
:      configuration.

A clarficiation is needed what you mean with this. Anyway, NETCONF
distinguishes between different configuration data stores. If you want
to distinguish between changes that affect only the current behaviour
but not say the next startup behaviour (i.e. the changes do not
persist), then this is already supported by NETCONF.

Perhaps your concern is that making a change requires to reprocess the
whole configuration? In that case, this is clearly not required
anywhere by the NETCONF protocol specification. In fact, the
edit-config operation allows to send detailed configuration change
sets to a NETCONF server.

:   Duplex:   Not Possible - strict pull model.

NETCONF does have support for event notifications that are pushed by
the device. The initiation of the session is client to server for the
existing transports - but this is mostly a property of the transports.
Some vendors use non-standard extensions for the SSH transport to
support device initiated sessions.

:   High-Throughput:   Unlikely - Can depend on configuration size

Well, this is ill defined in the first place. Your definition is:

:   High-Throughput:   At a minimum, the IRS Agent and associated router
:      should be able to handle hundreds of simple operations per second.

So what is a "simple operation"? I am rather optimistic that it is
possible to do some "simple operation" in NETCONF at the requested
speed. To be useful, you really need to be more precise.

:   Responsive:   Unlikely - Can depend on configuration size

Again, this is under specified. Your definition is:

:   Responsive:   It should be possible to complete simple operations
:      within a sub-second time-scale.

I am sure NETCONF servers easily respond within a sub-second
time-scale. We have several implementors here at the IETF, I
am sure they can provide more concrete information about the
efficiency aspects.

:   Multi-Channel:   Not Possible

NETCONF allows to use multiple SSH or TLS sessions (hence multiple TCP
sessions) and it provides the needed coordination primitives. In
addition, the SSH transport can be used to run multiple SSH channels
multiplexed over a single TCP session.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1, 28759 Bremen, Germany
Fax:   [phone]         <http://www.jacobs-university.de/>